1. 94
  1.  

  2. 16

    Mostly dead is still slightly alive!

    1. 2

      Are they languages people should truly love and learn from? Or should we look through their backers’ pants for loose change before moving onto the next failure?

      All depends on what’s really important to people running into them. If I told them, they might try to call my bluff or trick me into using the right languages. ;)

      1. 7

        I think that ML is an eye opener and should be learned. The book ML for the Working Programmer is quite good.

        Pascal will forever have a warm spot in my heart and some days I wish I would go back into it. I don’t know if it would change your mind much these days but when I was starting out in the early 90s it was marvelous.

        1. 9

          ML is very much alive in its OCaml variant! Arguably a more powerful and more modern version, too (GADTs, applicative functors, and a package manager, LSP, etc.)

          1. 7

            Ada, which borrows a lot from Pascal, is still marvelous in many ways. Once you’re used to the things it does differently from mainstream languages, you start realising how truly cohesive and well-designed it is. I did not fully understand object-oriented programming until I used Ada, because all other “object-oriented” languages I used implemented all separate aspects of object-oriented programming in the class. Ada clearly distinguishes between them and lets you pick and choose which of them you want.

      2. 10

        Both ML and Smalltalk are definitely not dead, they’ve just evolved into language families whose members have different names. The ML family has Standard ML, OCaml, and Haskell, and the Smalltalk family has Pharo, GemStone, GNU Smalltalk, and others. These all may not have hugely wide adoption, but they are actively used in both academia and industry, and continue to grow and evolve.

        1. 6

          One I like (not mentioned in the article) is cyclone, an earlier experiment with formally proven safety.

          1. 5

            Is it just me, or is “cause of death” largely based on speculation (and often wrong)? (See text for ML and SmallTalk).

            I’d also argue that Scala should also be on this list, and Pascal shouldn’t – there is shit-ton of Pascal/Delphi/FreePascal code out there that is actively maintained and developed.

            1. 14

              Is it just me, or is “cause of death” largely based on speculation (and often wrong)? (See text for ML and SmallTalk).

              The ML I’m shakier on, but I’m pretty confident about SmallTalk. My arguments there are based on interviews with several contemporaries and reading a lot of primary texts. I can’t overstate just how much Java dominated the OO world. If you read OOP books from before 1995 they’re in a mix of Smalltalk, C++, Eiffel, and Ada. Past 1995 it’s all Java.

              1. 7

                Something that I think might have done Smalltalk and APL in is the image/workspace model not playing well with other tools. If you wanted to write Smalltalk code, most environments required you to live entirely in Smalltalk. There were amazing version control systems, and editors, and what-have-you in Smalltalk…but if you wanted to use your own VCS, or text editor, or whatever…well, sometimes it could be done and sometimes it couldn’t.

                1. 2

                  Supporting your point, I’ve seen people in past few years say that about Squeak. They didn’t want to ditch existing environments.

                  1. 3

                    Yep. And a big focus of Pharo (a Squeak fork) has been on better integrating with existing tools, such as Git, GitHub, external editors, and so on. It’s a work-in-progress, but it’s been fun to watch.

                    1. 2

                      Do you happen to if they’ve landed better support for external editors in 8.0, or where I’d be able to read up on that?

                      Last time, the only think that kept me from spending a lot more time trying out Pharo was that I was missing Vim keybindings, being able to edit from an external editor would be really nice.

                2. 6

                  I think the cause of SmallTalk’s demise was that IBM pretty much took its SmallTalk devs with their SmallTalk IDE and retargeted it to Java.

                  So it’s not that Java just overtook SmallTalk, it’s that the most experienced SmallTalk devs were paid to not write SmallTalk and their IDE was turned into a Java IDE within a short time-frame, and the remaining ecosystem never recovered.

                  1. 3

                    It’s “Smalltalk”, not “SmallTalk”. (i know it’s a trivial difference, but this has always bugged me…)

              2. 5

                SML came out the same year as Haskell, which was a much “purer” example of a typed FP language.

                Well, that’s just not true. “A Proposal for Standard ML” first came out in 1983, and “The Standard ML Core Language” was 1984. Implementations resulted from each.

                Both of those are prior even to Miranda’s first release (the lazy predecessor to Haskell).

                Even if you wait until “The Definition of Standard ML (SML ‘90)”, that was actually completed in 1989, before Haskell’s first release. And SML ’90 is closer in concept and maturity to the Haskell 98 effort – standardizing an existing language in a consistent and portable way.

                1. 3

                  I was going on the “Definition of SML” the release of the first Haskell, but yeah, it seems like that’s incorrect. Will go ahead do a bit more reading. If you have any resources for why SML didn’t get as popular as OCaml, I’d love to read them.

                  1.  

                    No resources to point you to, but I can give you my take.

                    SML didn’t want to change. Milner was on the record as thinking SML was completed. It’s much harder to change than most languages, because of the formal verification requirement.

                    That resistence to change meant that it took a very long time for a standard library to materialize. It finally did with the ‘97 standard (the Basis). You can see that the library is low-level and limited, especially given the rise of the web at that time. It hasn’t changed since then.

                    Compare ocaml, which had its first release in 1996. By 1997 (possibly earlier – this was the earliest doc I was able to find), its standard library included threading, graphics, a file-based DB interface, lex/yacc parsers, and more robust unix interfacing. The libraries were messier than the Basis, but they were there, and they improved and expanded over time.

                2. 4

                  Have you read Jean Sammet’s Programming Languages: History and Fundamentals?

                  It has a lot of great information on earlier languages.

                  Here are a couple of features that first showed up in Algol 68.

                  • pragmas
                  • operator definition

                  Sammet says that MAD is the origin of constants.

                  I wouldn’t say that PL/I is a better language than Algol 68; it has more than its share of quirks.
                  Here is an example from John Levine.

                  PL/I suffers from a lot of features that individually make sense but do silly things in combination. My favorite example is this one:

                  DCL (A,B,C) CHAR(3); A = ‘123’; B = ‘456’; C = A+B;

                  The value of C is three spaces, because the arithmetic result is converted to a default length string ’ 579’ and then truncated from the right.

                  1. 1

                    Have you read Jean Sammet’s Programming Languages: History and Fundamentals?

                    That’s a recommendation to go read it?

                    1. 2

                      It’s a comprehensive survey of programming languages from the 1950s to 1969.
                      It’s well written but I would read it only if you are quite interested in older programming languages.

                  2. 4

                    Great article, but I don’t understand the selection process. Why were FORTRAN and LISP omitted? Because they’re still in use? But BASIC and COBOL are still in use too…

                    And I know COBOL was important, but influential? It seems so different from everything else, especially in syntax, and the article itself points out that academics weren’t using it so it didn’t get absorbed into new languages.

                    1. 3

                      An excellent article.

                      One typographic nit: if you can implement program names like SNOBOL in smallcaps, please consider doing so.

                      1. 4

                        Not that I am against it, but is there some source or reasoning that names written like are actually supposed to be written in smallcaps? Or simply to distinguish from acronyms? Is SNOBOL some special case? (I’m not asking for the specifics of use of smallcaps, but this application to names of things, stylized like the authors intended. Or.. did they?)

                        1. 5

                          For those speaking German:

                          The book Technisches Schreiben by Peter Rechenberg contains a funny correspondence between an author and his publisher whether “FORTRAN” or “Fortran” is correct. The publisher wants it to be “FORTRAN” whereas the author insists on “Fortran”. Reading their arguments was quite entertaining.

                          1. 2

                            Great question. For me it’s because ALL CAPS looks jarring in normal text, especially for situation where you have a string of them: COBOL, SNOBOL, BCPL etc.

                            But I do think it’s more of a style thing, no real rules. Also I don’t know if HTML/CSS can handle it natively.

                            1. 3

                              I’ve seen this same advice from typographers. When I make web pages I put all-caps abbreviations in <abbr> elements and I have a CSS rule like

                              abbr { font-size: 0.92em; }
                              

                              (For an example, look at how “API” and “JSON” are rendered in the first two paragraphs of this article on my blog.) It’s fairly subtle but I do think it makes the text look nicer.

                              1. 4

                                There’s actually native CSS support for small caps, which will (try to) use the font’s native small-caps glyphs instead of just shrinking the font-size of the regular capitals. If you look at the small-caps demo at the top of that MDN page, you should see that the small-caps glyphs have the same line-thickness as the initial capital D. If you just take the regular caps and scale down, the line-thickness gets smaller too. That can look reasonable in small text, where 0.92 of a pixel-width rounds back up to a full pixel, but tends to look weird in larger sizes.

                                1. 1

                                  Interesting, thank you!

                        2. 3

                          Fun article, Hillel.

                          From the APL/J section:

                          You can’t store both strings and numbers in the same data structure (unless you use boxes, which is a whole other can of worms) and working with strings is generally a nightmare.

                          The “non-homogeneity requires a special structure” actually seems pretty common for strictly typed languages. I’m thinking of Haskell Lists for example – with tuples or another special data structure required to mix types.

                          Do you see this as fundamentally different from boxing in J?

                          1. 3

                            Haskell has record types, right? Like you can have a struct with string keys and integer values. You can’t do that with J.

                            1. 1

                              Not having records was also one of my frustrations with J. I recently learned that you can have object-like records, called instances, but they kind of really suck to use. Indexing looks like fieldName__myInstance. Assignment looks like fieldName__myInstance =. myValue. It sucks because the __ construct is not a verb, so I’m pretty sure you can’t nest indexing, like a__b__obj, and you can’t index with a variable (well, maybe you can with some eval-like string magic?).

                          2. 2

                            Wow, I consider myself quite a plt nerd but I did not know about CLU.

                            I think at least one scripting language should be in there. Maybe Unix sh or awk? Maybe TCL or whoever invented the embedding? Who had the first dynamic types?

                            1. 2

                              Sh, AWK and TCL are nowhere near mostly dead, I think. Well, I don’t know about TCL, but if it wasn’t a forefather either it’s not on the list for that reason.

                              1. 2

                                I think at least one scripting language should be in there.

                                This isn’t just a list of influential programming languages; it’s a list of influential and mostly dead programming languages. So the fact that there aren’t any scripting languages is really interesting! Shell, Awk, Perl—these are solidly entrenched even though we could probably make better versions (at least by some criteria). I wonder if that’s because POSIX standardization preserved them somehow, or whether it’s just because they’re all “good enough” and have enough momentum that replacing them wouldn’t be worth it.

                              2. 2

                                Having studied COBOL, my impression is that it is far from complex — it completely lacks functions and scoping. Mostly it feels like a big heap of assembly macros.

                                1. 3

                                  Quite the opposite. It was designed to be closer to how people described solving the problems on computers. Also, it was meant to be understood by business people instead of just programmers. It had some success in that, too. It’s more like an executable subset of English designed for computers and programming methods that are decades old. Many restrictions might have come from how hard it was to design a compiler for it at the time.

                                  Languages such as COBOL, PL/I, Ada, and C++ taught hard lessons to some other language designers who made sure they designed theirs for easier compilation. Niklaus Wirth (Modula-2/Oberon) and Walter Bright (D) are two examples who make blazing fast compilers.

                                2. 1

                                  Glad to see they included CLU. Ruby’s beautiful iterators&block syntax comes from CLU.

                                  1. 0

                                    The article should distinguish Pascal from Object Pascal and also give Standard ML more cred. Otherwise not too bad.

                                    1. 1

                                      Why does SML deserve more cred? Seems like it kinda went nowhere compared to OCaml…

                                      1. 1

                                        Because it’s a research language that is actively used in academia.