> 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
The Tragedy of the Common Lisp: Why Large Languages Explode
21–30 of 126 posts
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
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…
Re: The Tragedy of the Common Lisp: Why Large Languages Explode
#24Re: 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
Re: The Tragedy of the Common Lisp: Why Large Languages Explode
#26I 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…
Re: The Tragedy of the Common Lisp: Why Large Languages Explode
#27Re: The Tragedy of the Common Lisp: Why Large Languages Explode
#28Lisp isn't a large language, it's a small language with a large library.
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…
> 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
#30What exactly is the link with the tragedy of the commons? https://en.wikipedia.org/wiki/Tragedy_of_the_commons