Awesome to see Mark S. Miller on the front page. One of my favorite computer nerd jokes: Ted Nelson points out that Mark Miller's name is his vocation. :D Get it? He's a symbol grinder, a mark miller. I love it.
The Tragedy of the Common Lisp: Why Large Languages Explode
61–70 of 126 posts
Re: The Tragedy of the Common Lisp: Why Large Languages Explode
#62The 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. Perhaps "small and beautiful" are not the right metrics to optimize programming languages for.
Perhaps popularity isn't.
Re: The Tragedy of the Common Lisp: Why Large Languages Explode
#63I 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…
I don't think this is really true of python, often the "correct" (pythonic, theoretically best performance) way to do something involves using more complicated language constructs than most people are familiar with. For example, when to use list/dict comprehensions, when to use reduce functions, when to use generators. Most beginner programmers and people coming from C-inspired languages will do things the "obvious"…
I think that python is in general more cohesive than other languages. I like that perl has both "if" and "unless", which is expressive, but it give multiple ways to do the same thing.
I also think pythonic and theoretically best performance might not need to correlate.
I would personally stick to for-loops for general but tricky code and leave things complications like nested comprehensions to places like the guts of libraries or classes that make the tradeoff to have simplified externals.
(for example argparse - very nice externals, tricky tricky guts)
Re: The Tragedy of the Common Lisp: Why Large Languages Explode
#64I 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"
Apparently yes. A quick inspection suggests that this is the same in Ruby, Haskell, SWI-Prolog, Gauche Scheme, SBCL and D. (I might not have the latest version of everything, so maybe this has been fixed in some of them... assuming it needs fixing. Maybe there's a reason for the answer to be 2 if so many language implementations insist on it. Or, they all use the same faulty algorithm. I don't know.)
Re: The Tragedy of the Common Lisp: Why Large Languages Explode
#65After 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
Replying to myself as I thought of an example from my own past which is relevant.
After discovering the eye-opening expressivity of functional programming years ago with Dylan and Haskell, I had a substantial project in javascript. I found JS supported first class closures and lambdas, which allowed me to make iterators.
The novelty was they were iterators not over lists but over trees (DOM trees in this case but of course any tree could be made iterable).
I understood there would be a learning cost for anyone who took over from me so I left plenty of docs and pointers. It would not be a small cost either, my successors would have to learn to think differently, at a higher level and possibly rather alien (to them) way.
But was it worth the cost, bloody hell yes! Not having that iterable and rather declarative abstraction over DOM trees would have greatly bloated the code and consequently brought in bugs by the bagful. I would do in a couple of lines what would have taken half a page to do, in many locations.
So it had a human cost but if you could overcome that, a seriously huge human benefit.
Re: The Tragedy of the Common Lisp: Why Large Languages Explode
#66After 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
Any and all abstractions. The cost is usually in all of the above.
Examples that I commonly encounter include OO, closures, dependency injection frameworks, complex configuration systems, various code generation systems, and on and on and on.
In general the tradeoff is this. For those who have internalized the abstraction, they can think about more complex things. Those who have not internalized the abstraction find it hard to figure out how the system works at all until they internalize it. So when you work on code that has a lot of abstractions under the hood it becomes either a black box (that occasionally you dig into) or (very often) a requirement that you understand X before you can even start to work on the code.
A rule of thumb that I use is how long the stack backtrace is. If every bug creates a stack backtrace that is dozens of frames, there are a lot of abstraction layers in place. And when all of the layers are actively being worked on, it adds up - quickly.
Deciding whether given abstractions are worthwhile for a given problem involves a judgment call. Unfortunately the people who are in the best position to make those calls tend to be the most senior, and tend to be the least aware of the costs of the abstractions that they add.
Re: The Tragedy of the Common Lisp: Why Large Languages Explode
#67The 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…
Pascal also cheated on size, by omitting some facilities that were almost indispensable for practical programs, leading pretty much all implementations do add them in incompatible ways.
Re: The Tragedy of the Common Lisp: Why Large Languages Explode
#68After 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…
Before dismissing it out of hand, take a look at the Go language. It was designed to make specific kinds of common abstractions hard exactly because, when working at scale, programmers routinely create disasters by layering abstractions in a way that nobody can understand the consequences of.
Re: The Tragedy of the Common Lisp: Why Large Languages Explode
#69Earlier quoted context omitted.
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
Any and all abstractions. The cost is usually in all of the above. Examples that I commonly encounter include OO, closures, dependency injection frameworks, complex configuration systems, various code generation systems, and on and on and on. In general the tradeoff is this. For those who have internalized the abstraction, they can think about more complex things. Those who have not internalized the abstraction find…
A nice reply, upvoted.
I would note that if you start your list with OO then you're including abstractions that almost all professional programmers would consider not abstractions but basic tools. It's impossible to work without such abstractions, except by working in purely procedural code, and even then...
I would add that if "a requirement that you understand X before you can even start to work on the code" is the case then your abstraction has - arguably, I may be wrong! - failed. My DOM iterator abstraction would take some effort of understanding to maintain, which was my concern, but it was a very simple black box to use.
Re: The Tragedy of the Common Lisp: Why Large Languages Explode
#70This 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 i…
> the goal was to unify several different Lisp dialects
the goal was to unify several similar Lisp dialects as a Maclisp successor