31–40 of 126 posts
Lisp isn't a large language, it's a small language with a large library.
But even with the all those 'libraries' COMMON-LISP package has just 978 external symbols.
The result is that programmers introduce complexity lightly, and when they walk into a new language/organization/etc are inclined to add random abstractions that they are used to from past experience.
And yes, I am not immune.
After programming for 20 years, I've noticed that programmers are aware of the potential benefits of any abstraction that they have internalized, and blithely unaware of the costs. Because, having climbed that learning curve, it is now free to them. The result is that programmers introduce complexity lightly, and when they walk into a new language/organization/etc are inclined to add random abstractions that they are…
'Lisp programmers know the value of everything and the cost of nothing.'
> 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
> 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…
What exactly is the link with the tragedy of the commons? https://en.wikipedia.org/wiki/Tragedy_of_the_commons
No explicit link with the tragedy of the commons was implied. Implicitly, of course, it applies - there are many participants, each of which is aware of their own gain and unaware of how their actions cost everyone else. The result is that when they all get their changes in, the result is terrible for everyone.
For another example, C++ is a terrible language, but it contains many good ones.
> 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 doe…
Kotlin's another language that looked at say Scala (which is an immensely powerful language, but easily lets you get lost in abstractions), decided "We don't need that feature unless it actively helps remove friction when writing programs", and ended up with a lot more real-world programs written in it.
Common Lisp isn't even close to the most complicated language out there. Every
Those languages are also not very popular at all today. Perhaps "small and beautiful" are not the right metrics to optimize programming languages for.
In many ways, keeping the core JavaScript language small has led to the JavaScript ecosystem being too large and sprawling. For example, look at module importing, something which is a fairly normal part of most programming languages. It still works in a completely different way in Node.js and in browsers. I think if there had been a standard way to handle JavaScript imports years ago, the practical experience of working in JavaScript would be simpler today.