Live data from Hacker News

The Tragedy of the Common Lisp: Why Large Languages Explode

medium.com

21–30 of 126 posts

Re: The Tragedy of the Common Lisp: Why Large Languages Explode

#21

> Once a language gets beyond a certain complexity — say LaTeX, Common Lisp, C++, PL/1, modern Java — the experience of programming in it is more like carving out a subset of features for one’s personal use out of what seems like an infinite sea of features, most of which we become resigned to never learning. This is how I felt about Racket, and I felt I had to do an opinionated pruning before I could use it for teac…

Last I checked, Racket literally has sublanguages defined for teaching and learning: "Beginning Student", "Beginning Student with List Abbreviations", etc. https://docs.racket-lang.org/htdp-langs/index.html

[deleted]

Re: The Tragedy of the Common Lisp: Why Large Languages Explode

#22

> Once a language gets beyond a certain complexity — say LaTeX, Common Lisp, C++, PL/1, modern Java — the experience of programming in it is more like carving out a subset of features for one’s personal use out of what seems like an infinite sea of features, most of which we become resigned to never learning. This is how I felt about Racket, and I felt I had to do an opinionated pruning before I could use it for teac…

Last I checked, Racket literally has sublanguages defined for teaching and learning: "Beginning Student", "Beginning Student with List Abbreviations", etc. https://docs.racket-lang.org/htdp-langs/index.html

Indeed. You can even MAKE your own language with Racket to suite teaching needs.

Re: The Tragedy of the Common Lisp: Why Large Languages Explode

#23

> 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…

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.

Re: The Tragedy of the Common Lisp: Why Large Languages Explode

#24
I get that the article used Common Lisp to create the punny title and much of its contents are broadly about why its important to keep languages relatively small, but I'm sort of disappointed most of the language-specific talk was about JS. I'm in the middle of learning CL at the moment (I have a mostly Java, Python, C++ background, in that order of experience) and would be interested to hear from experienced Lispers on why some other Lisp would be a better choice at a language level (so not based on convenience, tooling, popularity, etc... okay, maybe tooling).

Re: The Tragedy of the Common Lisp: Why Large Languages Explode

#25

> Once a language gets beyond a certain complexity — say LaTeX, Common Lisp, C++, PL/1, modern Java — the experience of programming in it is more like carving out a subset of features for one’s personal use out of what seems like an infinite sea of features, most of which we become resigned to never learning. This is how I felt about Racket, and I felt I had to do an opinionated pruning before I could use it for teac…

Last I checked, Racket literally has sublanguages defined for teaching and learning: "Beginning Student", "Beginning Student with List Abbreviations", etc. https://docs.racket-lang.org/htdp-langs/index.html

[deleted]

Re: The Tragedy of the Common Lisp: Why Large Languages Explode

#26

I get that the article used Common Lisp to create the punny title and much of its contents are broadly about why its important to keep languages relatively small, but I'm sort of disappointed most of the language-specific talk was about JS. I'm in the middle of learning CL at the moment (I have a mostly Java, Python, C++ background, in that order of experience) and would be interested to hear from experienced Lispers…

Racket seems to be favoured individuals who are using it to create a DSL or accomplish very specific tasks, but CL is definitely the most used Lisp (well, maybe apart from Clojure) to create 'big' applications.

Re: The Tragedy of the Common Lisp: Why Large Languages Explode

#29

> 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…

> > 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?".

Re: The Tragedy of the Common Lisp: Why Large Languages Explode

#30
post #27

What exactly is the link with the tragedy of the commons? https://en.wikipedia.org/wiki/Tragedy_of_the_commons

I think it's just a fun name. But maybe it's allegorical in that everyone "took what they wanted from the commons" (got their preferred features implemented), leaving the whole thing a mess (bloated language).
Post reply on HN