Interestingly hardly anybody uses Algol, Smalltalk, Pascal and early Scheme anymore, while people still use Common Lisp. Perhaps "being small and beautiful" is actually a bad thing for a programming language?
"Historically, languages designed for other people to use have been bad: Cobol, PL/I, Pascal, Ada, C++. The good languages have been those that were designed for their own creators: C, Perl, Smalltalk, Lisp."
They might not be the most beautiful languages ever invented, but they power a great deal of real-world applications. If people managed to write useful software with those, I consider that a success.
On the other hand, I probably never used or depended on any software written in Smalltalk in my life.
Haha. What a poorly reasoned article. Smalltalk and lisp - seriously??? Java was designed for the average programmer, nothing complex, all simple stuff, and it's been very successful. Meanwhile, smalltalk and lisp are minority languages that appeal to very few. Other than emacs can anyone think of any successful app that is written in either?
Good design has nothing to do with users and its easy, as this article does, mix aesthetics for design.
The 911 was expensive, hard to drive with its engine hanging out over the rear end and not even comparable with the caddy.
Even c, who uses that much anymore? Software development (unlike the 911) has evolved, today the level of abstraction is much higher. There is still c development of course, but java, python, ruby, and php are the dominant languages.
Little languages are the past and yes, the future. We just don't recognise them.
It was common in the 60s and 70s to have the hardware manufacturer ship all the OS and languages with their hardware. The languages were often designed for specific problem domains. The idea of general purpose languages (FORTRAN, PL/1, etc) was uncommon. You can see this in K&R (the original edition anyway) where they justify the idea of a general purpose language, even though C itself derived from prior general languages (B & BCPL) and they had gotten the idea from their experience on Multics (written in PL/1, a radical idea at the time). So a 20 year old idea was still barely diffused into the computing Zeitgeist.
Most Lisp development (since the early 70s at least) is writing a domain-specific representation (data structures and functions) and then writing your actual problem in it. I used both Lisp and Smalltalk this way at PARC in the early 80s.
More rigid languages (the more modern algolish languages like python, c++, rust, C, js etc -- almost every one of them) doesn't have these kind of affordances but instead do the same via APIs. Every API is itself a "little language"
What are called little languages in the Bently sense is simply a direct interface for domain experts. And after all what was a language like, say, Macsyma but a (large) "little language"?
I don't buy the basic premise that CL is too large. Languages get popular if they allow programmers to achieve what they want to achieve with minimum effort. It doesn't matter whether they are large or small. CL never had many good GUI options (except very expensive commercial implementations) and until recently many programmers wanted to create GUI applications. So CL was a bad choice. It's still a big minus. CL lacked a good package manager, which was very inconvenient. Now that there is Quicklisp, a big plus. CL has no concurrency support in the language and the quasi-standard Bordeaux-threads has disadvantages over concurrency primitives of other languages.
Here you go, three reasons why CL is less popular than it could be that have nothing to do with the size of the language, and these are just examples. A language doesn't need to be big but it needs to offer what programmers need in one way or another. It's irrelevant whether that's part of the language or part of an ecosystem.
Fair enough, and Python is a good example, but I'm guessing Scheme and Smalltalk managed to stay relatively simple over time, although I don't know how much of that would be chalked up to lack of mainstream support.
I also prefer the minimalist approach to language design and even though I like Pascal, the modern incarnation of the language in FreePascal is simply too large. I feel the same about many popular languages. Perhaps it's inevitable as developers demand more features and the language accrues more features with each release. Even languages that start small(ish) over time grow to be quite large (e.g. Python).
I don't see why it's one of the worst offenders. I always found that it made more sense that PHP and Javascript, and was a bit more consistent than Python and Java.
What is your standard for non-offender? Certainly not C++ or Common Lisp. Scheme, Smalltalk, Go?
agreed. after i learned common lisp and smalltalk, i realized that since there has hardly been any innovation in programming since the first languages half a century ago.
My point was that I don't think Smalltalk was ever more popular in the industry than C regardless of the time frame. By the mid 90's lisp machines were pretty long gone, betting on Lisp instead of C if employability is the metric seems rather bold.
MIPS I concede, it was remained fairly popular for a long time.
I guess my overall point is that the subjective choices made by this university back then don't really mean much by now. The fact that they taught Pascal instead of C alone proves that they weren't particularly prescient.
>Regarding language comparisons, actually C++ is Italian and C Latin.
I thought about that while writing this bad analogy but I couldn't come up with a better one. I wasn't really talking about the historical relationship between C and C++ but rather about their relative complexities. Learning C++ is vastly more complicated than learning C. On top of that the coding style of a modern C++ application (which generally involves a lot of metaprogramming, OOP and even some functional constructs) is fairly different from a standard C codebase. You don't write C like you write C++ and vice-versa.
People like to fantasize about how things would’ve been better if the industry was dominated by X language.
I feel they forget to acknowledge that most programmers rarely adopt the design patterns and overall styles that make languages like SmallTalk and Lisp so highly praised.
Looking back at ALGOL-68, it looks like comparatively small language compared to many of our current languages, e.g. Java, C++ and Python. I loved the definition of it, but never got to use it.
People are still using the same screwdrivers and screws they used a hundred years ago. Phillips head isn't even that good - you can easily strip the head over a few uses, or even one, if you don't know what you're doing. There have been innovations in big machines (analogy parallel would be Hadoop or whatever). But at the small level, people are still using the basic hand implements they've always used because they always work, they work everywhere, everyone else knows them, and it's pretty hard to get the design for new ones wrong.
Like the author says, his ideas don't mean you should use Smalltalk or Lisp. Just that you should demand features, like how it took until Rust for sum types to escape functional. But the reason you shouldn't use Smalltalk is also the reason why languages like Smalltalk aren't going to get made: because when you're making a general-purpose language, it is extraordinarily hard to paradigmatically improve on what came before, and it's very easy to just get it all wrong and make a pile of trash that makes developers at the few companies that adopt it mad at you. Even Rust is not that amazing in this regard; its wild and new data model is in fact the exact same one you were supposed to be using in C++, just minus the ability to refuse.
Everyone smart who was able to make these things has been snapped up by big data where their talents produce the most direct value.
The growth of language size in the past 30 years is even more stunning when you compare today's C++ to C, or Java to Pascal (or Object Pascal) from 1990. No modern language can be taught in less than a thousand page textbook. And if you include the standard templates and libraries the book size can double again.
The evolution of any language inevitably adds reams of extensions, variations, and libraries. This makes the tool not only a lot more heavyweight, but much slower and harder to master, and personally, a lot less fun to use. Give me a tiny simple language (e.g. C) any time over a giant language that requires me to navigate multiple programming paradigms and layers of abstraction (e.g. C++).
Modern languages are like having to speak in Latin. You spend all your time trying to please an nazi grammarian, rather than speaking simply and naturally.
Lazarus ( Free Pascal ) seems to be thriving actually. APL is probably as big as it ever was. COBOL will shrink over time but it may still outlast me. I have no insight into SmallTalk but my University curriculum included it and it would not surprise me at all to see it used academically today. I was also taught Scheme and Fortran and those are still going strong. If I wanted to use any of these, I know I can find both free and commercial dev environments easily that run on platforms I still use.
Is ALGOL still in use anywhere though? Is there a compiler available that runs on anything modern? I genuinely curious.
Short-comings are intrinsingly related to its general purposeness. Tiny standard library is one of them. Not being able to put things into production is another.
I guess I see general purpose languages such as Python and Go as rock solid. They have warts but they're well understood and wrinkles have been ironed out.
"Worse is Better" is just an inaccurate way of saying it. More accurately, "It's the Culture, Stupid!"
If a language fits a group's culture better, it will be adopted more. Smalltalk lacked operator precedence for algebras -- big lose for the non CS sci/tech crowd. At first Java had some of what Smalltalk had, but fit general programming culture better in terms of C-like syntax, free (beer) tools, and static types.
Lisp is close to timeless mathematics, but a bit farther away from everything else than everything else. I don't think it's a coincidence that the AI field gravitated towards Lisp -- those guys were used to meta-abstraction.
Perl just threw every Unix tool there was into a burgeoning scripting Swiss-Army knife. As a result, everyone in the Unix camp could relate to it instantly.
Worse is not better. Better is better. But designing to fit existing cultures has a big short-term payoff for a programming language. This means a bigger user base, which means more eyeballs, more libraries, and other dynamics that also get you lots of Better.
The Best would be: a programming language that has a high fit with non-CS/programming sci/tech types and elegant design, first-rate implementation, and mathematical universality.
There is absolutely nothing whatsoever intuitive about the C flavor of Algol syntax.
Popularity is familiarity, not intuition. To my aesthetic taste the Kotlin looks hideous and the Smalltalk elegant and light; but then, I'm able to read them both.
Hmm. "Languages and systems that are of sound design will persist, to be supplanted only by better ones." I wonder if the author still thinks that, looking at the programming language landscape today. (Either he would have to say "it didn't work out that way", or to say that C++ and Java were better than Smalltalk.)
reply