Wrote a little followup to the post from last week based on the conversation with @Jonathan Frederickson and @D. Schmudde: https://worksonmymachine.ai/p/safe-is-what-we-call-things-later

Nice article! Minor quibble: > You can tell what type of programmer you were taught by based on which part of object-oriented programming they teach first. Did your teacher start with inheritance? Class hierarchies, abstract base classes, the whole "a Dog is-a Mammal is-an Animal" taxonomy? Then you were taught by what we call a formalist. They showed you the blueprints before they showed you the building. I was taught by a formalist, but I just wasn't taught OO for the longest time! I learned programming with functions and records. Fortran then COBOL then Pascal then C in the first couple of years. I don't know, is this uncommon? Perhaps because of this educational trajectory, I tend to associate what you call the formalist camp with Fortran and Algol, and the informalist camp with Lisp. Lisp was the original fun thing that empowered people to try things out without thinking too hard about failure. The different kinds of OO just attached to camps that already existed. (My prejudice: OO is just not that important. A hype cycle among many, 25 years from anything interesting in either direction.)

Huh that's super interesting...you know...I left Lisp out because I'm not super familiar with all the details there (or would have known that Fortran/Algol would be the Formalist camp languages)...but I guess one way of looking at that was just the previous pendulum swing before where my story started 🙂

> it looks like its trajectory rhymes with javascript/typescript...where it comes out as this informalist, fun empowering thing and then changed based on the businesses built up around it into something a bit more formal? At least from a popular usage standpoint? > Absolutely. It's before my time as well, but my impression after immersing in it for a while is that it started out in academia, where people were experimenting with extremely out-there programs. Then the greater interactivity qualitatively changes outcomes, helps you get to programs you would just never be able to write for the first time. (After you've done it the first time, you know something is possible, that this particular place is interesting enough to chew through glass to get to, then you can get there with Fortran or Algol.) Since this sort of research was happening in academia, there was less pressure to chase performance. As Lisp went more mainstream it encountered people who need performance. And after the initial, justifiable critiques Lisp performance also became a meme, an easy soft spot to punch it at even from lay programmers who don't actually need performance, who would actually benefit from it if they had been more open-minded. The critique/meme of performance nerdsniped the Lisp community, who all seem to have thought that they could convince narrow-minded people just by being better. And they built amazing compiler tech but I think were never in with a chance. What they did manage to do using the emphasis on compilers was hobble Lisp's late bound nature to some extent. In trying to protect against critiques of Lisp's weaknesses, they squandered some its strengths, the interactivity. It is still there, but it feels less accessible. This is speculation, but I think the first generation of Lisp programmers had an easier time seeing the benefit of interactivity than someone coming to Common Lisp today. Or maybe I'm just one of the brain-damaged ones never quite able to see the light even though I do see the promise of Lisp in other places like macros. Anyway, going mainstream did change it, though I think the rhetoric back then was about performance vs flexibility. Rigor was a bit of an independent axis. There were rigorous people on both sides; Dijsktra saved his best disses for the functional programming camp, which was trying to do to Lisp some of the same things he was trying to do to Fortran and Algol.

First of all: nice article! Good observations, well written. Next: Lisp. It has been used by both formalists and informalists. Today, its informalist side is probably more visible. It's much like you describe Smalltalk. But serious formalist work has been done in Lisp as well. ACL2 is a good example. And you can see Scheme, compared to the Lisps of the 1960s, as a step towards formalist preferences. Something that Lispers got right, in my opinion, is that informalist is the right default. Formal systems are always embedded in informal ones, whereas the opposite is not possible. You can embed ACL2 in Common Lisp and make formal subsystems that interact with its Lisp environment. You can implement but not embed an informalist system such as Smalltalk in a formalist language such as Haskell.

Like @Konrad Hinsen, I also pre-date OO-oriented pedagogy. What I learnt as a student, and what I still believe, is basically what Sussman says at 3:34 of this video:

Thanks @Konrad Hinsen! Interested to dig more into the paper! Can you share more about the distinction you make there between implement vs embed?

Most people really enjoy joining cults, so you can expect to be on many more such teams. Personally, I think identifying as, say, a “JavaScript programmer” is like identifying as a “hammer carpenter”. There are many tools for many situations…

@Konrad Hinsen It's interesting thinking of Scheme as a step towards formalism given how informal it is compared to a lot of the other languages I'm familiar with, but I suppose everything is relative 🙂 (will have to read your paper in more detail later)

@Scott Embedding means building a subsystem that can interact with its surrounding system. Implementing means creating a new isolated system. All programs end up embedded into something bigger, typically an OS. That something bigger must therefore follow informalist principles. The Unix shell does it, for example. But that embedding is very limited. Unix offers three character streams per process, plus the file system. I'd much prefer formalist subsystems to be embedded in a richer informalist language, and that's what happens in Lisp. Also in Scheme, for example with Typed Racket.