This comparison is inappropriate. When Common Lisp was standardized, the goal was to unify several different Lisp dialects, not to make the language "small." Furthermore, there was no standard library for Common Lisp. The language itself is its standard library. If anything, the language by itself is too small for a lot of modern applications. (The situation is different now; there are hundreds of libraries to fill in the missing pieces of Common Lisp. But they're not standardized like the core language is.)
The Tragedy of the Common Lisp: Why Large Languages Explode
51–60 of 126 posts
Re: The Tragedy of the Common Lisp: Why Large Languages Explode
#52Earlier quoted context omitted.
Common lisp is large-ish at least.
Common Lisp is small enough that one person could write a reasonably complete test suite for it in his spare time.
I'm not sure too many people could write a test suite for LOOP in his spare time. Never mind the rest of the trickier parts of the language such as MOP, CLOS, packages, conditions, restarts, etc. etc.
Re: The Tragedy of the Common Lisp: Why Large Languages Explode
#53The Algol, Smalltalk, Pascal, and early Scheme languages were prized for being small and beautiful. 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, someth…
> Those languages are also not very popular at all today. But yet, C (arguably 'current algol') and Python (arguably 'current scheme' ) are.. yes: python is verry loosely like scheme, this is meant in the sense of a 'dynamic loosely typed language you can interact with in a repl'
Lua is a far better counter-example as a successful small and (conceptually) beautiful language.
Re: The Tragedy of the Common Lisp: Why Large Languages Explode
#54Isn't c++ a large language? And yet it's still used.
C++ is only slightly larger than any other language if you subtract the standard libraries that make a language useful. If you add standard libraries C++ is a tiny language.
C++ does have a lot of weird, inconsistent warts that make it tricky to learn/use everything. Which is why most people who advocate to use C++ talk about modern C++ which is C++ where you stay away from those warts.
Re: The Tragedy of the Common Lisp: Why Large Languages Explode
#55After 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…
Your criticism of abstractions is very much in the abstract.
What abstractions?
What costs of these? In human comprehension, in runtime, in reliability, in mem/cpu?
Can you give examples which I can usefully learn so as to avoid?
TIA
Re: The Tragedy of the Common Lisp: Why Large Languages Explode
#56The Algol, Smalltalk, Pascal, and early Scheme languages were prized for being small and beautiful. 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, someth…
I quite strongly disagree. My favourite languages, Scheme, C, Go, share precisely the "small and focused" philosophy, and its a big reason why I like them so much. Your point about javascript is not very strong either, I imagine the real reason is its origins as a browser-embedded language meant that the same style of imports in Node.js were not feasible. Even if this is not true, I would then shift the blame to the implementor of Node.
Scheme in particular deserves so much more attention, it is so capable and it is a joy to write.
Re: The Tragedy of the Common Lisp: Why Large Languages Explode
#57Earlier quoted context omitted.
Why not just use a smarter compiler/linker that trims out unused library code?
Some CL implementations do this ("tree shaking", as it is called). But some of the more popular open-source implementations (SBCL, Clozure CL) do not.
It can also be error prone. Analysising arbitrary lisp code to see which functions could conceivably ever be called isn't as trivial as it might first seems.
Re: The Tragedy of the Common Lisp: Why Large Languages Explode
#58Earlier quoted context omitted.
Common Lisp is small enough that one person could write a reasonably complete test suite for it in his spare time.
I'm not sure too many people could write a test suite for LOOP in his spare time. Never mind the rest of the trickier parts of the language such as MOP, CLOS, packages, conditions, restarts, etc. etc.
Re: The Tragedy of the Common Lisp: Why Large Languages Explode
#59I feel like this is the real success of Python: the "one and preferably only one obvious way to do it" idea means that new ways of doing something are rarely added, and when new they are added, old ones are likely deprecated. Complain all you want about the 2 to 3 transition, but it's resulted in a simpler, easier-to-use language. If the community really feels a different way is better, they add it in libraries. My o…
> Complain all you want about the 2 to 3 transition
Okay.
> it's resulted in a simpler, easier-to-use language.
Does `print(len("ẅ"))`[0] still produce a value (2) that is neither the number of characters (1) nor the number of bytes (3)?
0: "print\x28len\x28\x22\x77\xCC\x88\x22\x29\x29"
Re: The Tragedy of the Common Lisp: Why Large Languages Explode
#60After 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…
The absence of abstraction being what exactly ?
Also beware of that kind of pseudo-wise thinking. Is there a point in climbing up a learning curve anymore ? Maybe you have a constant and massive stream of fresh bodies to throw at your "simple" solutions before laying them aside once those abstractions have clogged up their heads ... And maybe if you can unskilled workers at such a scale, it's because you have massive fundings as well...
More a question of financial optimization than software engineering I think