4 ms·

> The Algol, Smalltalk, Pascal, and early Scheme languages were prized for being small and beautiful. But they did not achieve widespread adoption. Widely us

> The Algol, Smalltalk, Pascal, and early Scheme languages were prized for being small and beautiful. But they did not achieve widespread adoption. Widely used languages need to apply to a wide range of use cases. For example the fat arrow(=>) class syntax that binds this. class Foo { bar = (baz) => { // do something } } For entry level JavaScript developers working in React, this made one of the most common hangups go away for them due to the automatic binding of `this`. But for a some other situations, that might end up an anti-pattern. That's always the issue with small, clean implementations. They work when they only apply to one domain. Once they need to be used for different things, they then need to add new features. It is no different for software, blenders, bicycles etc. Once something is used for multiple domains, it now needs to become larger and more complex. Its basically a rule of nature.

protomyth 7y ago
Pascal was pretty popular. Turbo Pascal sold a lot of copies for good reasons.
stcredzero 7y ago
But they did not achieve widespread adoption. That's always the issue with small, clean implementations. They work when they only apply to one domain. Sorry, but this is pure BS with regards to Smalltalk. I worked for a Smalltalk vendor for 5 years, then consulted in the language for several years after that. I had a front row seat to these issues. Having a small language does not make it suitable for only one domain. The primary reason for Smalltalk not achieving widespread adoption was due to a series of decisions which, in retrospect, were highly anti-adoption. It started with no operator precedence in the language design, which acted to alienate engineers and scientists. Then the industry went through a "we're the boutique language of the Fortune 500" phase with $5000 and $10000 per-seat licenses. It is no different for software, blenders, bicycles etc. Once something is used for multiple domains, it now needs to become larger and more complex. Its basically a rule of nature. That just doesn't work for software. The reason why Python is so popular with certain scientific communities isn't at all specific language features to support them. It's general utility plus specific libraries. The reason why Smalltalk got popular at one time in finance and energy trading didn't have anything to do with specific language features or libraries. It was purely rapid development! There is something which a small language can be prone to: fragmentation. It was so easy to roll your own Smalltalk. This, combined with a toothless language standard meant that the community got balkanized into multiple communities with incompatible code.
sdegutis 7y ago
For what it's worth, that class-field syntax proposal never settled well with many JavaScript and React developers, and now that Hooks are out, a significant number of us have abandoned class syntax altogether in favor of functions with hooks. (There are other proposals that add to the class syntax that overall just don't seem to mesh well together and seem to create as many issues as they solve, like #private_variables, and the @decorators.)
NeedMoreTea 7y ago
Algol was huge - for the scope of its era, and the ancestor of many modern languages so its influence was outsize too. Where modern books that aren't language specific might express ideas and algorithms in C, most books used to use Algol. There was an entire generation of later languages that were called Algol-like: B, C, Pascal, Ada, Modula 2. Probably others.
dbcurtis 7y ago
> > The Algol, Smalltalk, Pascal, and early Scheme languages were prized for being small and beautiful. > But they did not achieve widespread adoption. > Widely used languages need to apply to a wide range of use cases. A long time ago, an old-timer, even more old-time than me (and I did CS home works on punch cards in PL/I...) was a C fanatic, and was dragging his mainframe colleagues into Unix, said it best: "C does not get in your way." He (and I) came from an era when eventually pretty much every language eventually "got in your way" and you had to learn the assembly language calling and linking conventions and implement a few nuts & bolts to get your job done. C was the first popular language that didn't eventually knee-cap you like that. That is why C won and Pascal was an intense but passing fad. To me, that is the essential message for language designers, more important than "keeping it small". Stay out of the programmer's way. Of course, there are different ways of staying out of the way.... Python's "duck typing" is a way of keeping the type checker out of your way. Rust's "unsafe" is a way of keeping the borrow checker out of your way when you really, really, need to carve with your sharpest knife. So I would argue that "applies to a wide variety of use cases" simplifies to: does not get in your way no matter what your application is. As an aside: The old timer was a role model to me in one important aspect: Learning to recognize progress when you see it. He not only lived through the transition from core to solid state memory, he lived through the transition from transistor logic to integrated circuits. But he was evangelizing C and Unix when many his age thought the list of interesting programming languages had len()==3: FORTRAN, COBOL, assembly. I took that lesson to heart, and try very hard to answer the question: "Is this progress, or is this just different?".
- nostrademons 7y ago
  Go does this really, really well. I'm not a huge fan of Go-the-language (largely because I enjoy having a little more abstractive power), but I have to admit that one of its huge strengths is that it's a language designed to take the focus off the language and onto the program you're writing. It avoided several of the pitfalls of more "advanced" languages (eg. Common Lisp, Haskell, even Rust and Python 3.5+) in the process, which is perhaps why it's seen more mainstream adoption. Kotlin's another language that looked at say Scala (which is an immensely powerful language, but easily lets you get lost in abstractions), decided "We don't need that feature unless it actively helps remove friction when writing programs", and ended up with a lot more real-world programs written in it.

protomyth 7y ago

Pascal was pretty popular. Turbo Pascal sold a lot of copies for good reasons.

stcredzero 7y ago

But they did not achieve widespread adoption. That's always the issue with small, clean implementations. They work when they only apply to one domain. Sorry, but this is pure BS with regards to Smalltalk. I worked for a Smalltalk vendor for 5 years, then consulted in the language for several years after that. I had a front row seat to these issues. Having a small language does not make it suitable for only one domain. The primary reason for Smalltalk not achieving widespread adoption was due to a series of decisions which, in retrospect, were highly anti-adoption. It started with no operator precedence in the language design, which acted to alienate engineers and scientists. Then the industry went through a "we're the boutique language of the Fortune 500" phase with $5000 and $10000 per-seat licenses. It is no different for software, blenders, bicycles etc. Once something is used for multiple domains, it now needs to become larger and more complex. Its basically a rule of nature. That just doesn't work for software. The reason why Python is so popular with certain scientific communities isn't at all specific language features to support them. It's general utility plus specific libraries. The reason why Smalltalk got popular at one time in finance and energy trading didn't have anything to do with specific language features or libraries. It was purely rapid development! There is something which a small language can be prone to: fragmentation. It was so easy to roll your own Smalltalk. This, combined with a toothless language standard meant that the community got balkanized into multiple communities with incompatible code.

sdegutis 7y ago

For what it's worth, that class-field syntax proposal never settled well with many JavaScript and React developers, and now that Hooks are out, a significant number of us have abandoned class syntax altogether in favor of functions with hooks. (There are other proposals that add to the class syntax that overall just don't seem to mesh well together and seem to create as many issues as they solve, like #private_variables, and the @decorators.)

NeedMoreTea 7y ago

Algol was huge - for the scope of its era, and the ancestor of many modern languages so its influence was outsize too. Where modern books that aren't language specific might express ideas and algorithms in C, most books used to use Algol. There was an entire generation of later languages that were called Algol-like: B, C, Pascal, Ada, Modula 2. Probably others.

dbcurtis 7y ago

> > The Algol, Smalltalk, Pascal, and early Scheme languages were prized for being small and beautiful. > But they did not achieve widespread adoption. > Widely used languages need to apply to a wide range of use cases. A long time ago, an old-timer, even more old-time than me (and I did CS home works on punch cards in PL/I...) was a C fanatic, and was dragging his mainframe colleagues into Unix, said it best: "C does not get in your way." He (and I) came from an era when eventually pretty much every language eventually "got in your way" and you had to learn the assembly language calling and linking conventions and implement a few nuts & bolts to get your job done. C was the first popular language that didn't eventually knee-cap you like that. That is why C won and Pascal was an intense but passing fad. To me, that is the essential message for language designers, more important than "keeping it small". Stay out of the programmer's way. Of course, there are different ways of staying out of the way.... Python's "duck typing" is a way of keeping the type checker out of your way. Rust's "unsafe" is a way of keeping the borrow checker out of your way when you really, really, need to carve with your sharpest knife. So I would argue that "applies to a wide variety of use cases" simplifies to: does not get in your way no matter what your application is. As an aside: The old timer was a role model to me in one important aspect: Learning to recognize progress when you see it. He not only lived through the transition from core to solid state memory, he lived through the transition from transistor logic to integrated circuits. But he was evangelizing C and Unix when many his age thought the list of interesting programming languages had len()==3: FORTRAN, COBOL, assembly. I took that lesson to heart, and try very hard to answer the question: "Is this progress, or is this just different?".

nostrademons 7y ago
Go does this really, really well. I'm not a huge fan of Go-the-language (largely because I enjoy having a little more abstractive power), but I have to admit that one of its huge strengths is that it's a language designed to take the focus off the language and onto the program you're writing. It avoided several of the pitfalls of more "advanced" languages (eg. Common Lisp, Haskell, even Rust and Python 3.5+) in the process, which is perhaps why it's seen more mainstream adoption. Kotlin's another language that looked at say Scala (which is an immensely powerful language, but easily lets you get lost in abstractions), decided "We don't need that feature unless it actively helps remove friction when writing programs", and ended up with a lot more real-world programs written in it.