Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Tragedy of the Common Lisp: Why Large Languages Explode

medium.com

Post reply on HN
Print view View original

71–80 of 126 posts

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

#71

Post by ferbivore »

a1369209993 wrote: post #59
kerkeslager wrote: post #39

I 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"

len() counts code points, not abstract characters. Your "ẅ" contains two of them, U+77 and U+0308.

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

#72

Post by btilly »

tempguy9999 wrote: post #69
btilly wrote: post #66

Earlier quoted context omitted.

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…

A simple example of an abstraction for which this is not true is the MVC design. If you don't understand how it works, you don't know where to begin looking to make a change to the system.

And yes, some abstractions truly are basic tools. And the more experience you have, the more basic they seem, and the more such tools you have.

I am not arguing against abstraction per se. What I am arguing is that abstractions bring a cost, and that cost adds up. A project needs to find an appropriate balance, and there is a tendency for experienced programmers to draw that balance at a point that may or may not be appropriate for the people who have to maintain the system after them.

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

#73

Post by braythwayt »

darkpuma wrote: post #33
btilly wrote: post #32

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…

> "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." 'Lisp programmers know the value of everything and the cost of nothing.'

Underrated comment!

Here’s the footnote:

“Perlisisms: EPIGRAMS IN PROGRAMMING by Alan J. Perlis”

http://www.cs.yale.edu/homes/perlis-alan/quotes.html

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

#74

Post by braythwayt »

lacker wrote: post #40

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

Programming languages can be categorized in a number of ways: imperative, applicative, logic-based, problem-oriented, etc. But they all seem to be either an “agglutination of features” or a “crystallization of style.” COBOL, PL/1, Ada, etc., belong to the first kind; LISP, APL– and Smalltalk–are the second kind. It is probably not an accident that the agglutinative languages all seem to have been instigated by committees, and the crystallization languages by a single person.

Alan Kay's "The Early History of Smalltalk:"

http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html

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

#75

Post by neilv »

threatofrain wrote: post #34
gmfawcett wrote: post #18

Earlier quoted context omitted.

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

I wouldn't call those sub-languages, I think they're rightly different languages (of eerie similarity) born from specific pedagogical or academic vision. So the upkeep in dealing with the mismatch between proper Racket and these student languages wasn't something I was interested in. Students should be able to consult general Racket resources.

Exactly, I think that the Racket teaching languages were started to support teaching young/new students (and not necessarily people who are or will be CS majors) a particular way of approaching program design problems.

Racket itself arose from building a cross-platform toolset to support building those programming tools. It also became a toolset and testbed for PL research.

I appreciate what you're saying about Racket having a big library. I was recently talking about how to to teach Racket to experienced programmers. I'd put them down in front of a full `#lang racket/base`, but start with teaching them only a specific subset of R7RS, and incrementally introduce a few more concepts and exercises to try for a day or more (things you can practice while writing your own real code, even if it briefly seems harder than something we told you that you could use before). If instead I just dumped the full Guide and Reference on experienced people, they'd become productive pretty quickly, albeit colored heavily by what they previously knew, and they might have a much longer path to becoming strong in some unfamiliar fundamentals.

BTW, another educational thing that Rackets `#lang` does is support students working through SICP use DrRacket. It emulates the particular older Scheme variant used in SICP, gives an IDE maybe a bit easier for new students, and runs on the student's own modern computer.

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

#76

Post by dalyons »

tempguy9999 wrote: post #65
tempguy9999 wrote: post #55

Earlier 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

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…

haha did your successors think it was worth the cost?

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

#77

Post by a1369209993 »

zephyrfalcon wrote: post #64
a1369209993 wrote: post #59

Earlier quoted context omitted.

> 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.)

> they all use the same faulty algorithm

Well, yes. To be fair, it's not like any of them make a secret of the fact that they're mistakenly counting unicode code points instead of characters.

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

#78

Post by amelius »

btilly wrote: post #36
amelius wrote: post #27

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

The word "Common" is a reference to the language Common Lisp: https://en.wikipedia.org/wiki/Common_Lisp . 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. F…

> No explicit link with the tragedy of the commons was implied.

Okay, but the article says:

> Adapted from a 2015 es-discuss thread. “Common Lisp” is not the topic. It serves only as one of many illustrative counter-examples.

So if "Common Lisp" is not the topic, and the tragedy of the commons is not the topic, then it seems the title is not very well chosen.

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

#79

Post by jkachmar »

btilly wrote: post #68
GorgeRonde wrote: post #60

Earlier quoted context omitted.

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.

This is exactly the kind of pseudo-wisdom that I read the GP as referring to, though.

In the case of Go, the core team saw the pain of indirection-masquerading-as-abstraction in complex Java/C++ codebases and considered the whole thing to be a boondoggle. As a result of this we’ve been saddled with a popular language in which two massive projects (gvisor and kubernetes) have had to hack their own expressivity into the language just to build complex software (i.e. codegen’d generics)

I worry about the cyclic nature of progress in our industry, where wonderful advancements can be made and then walked back or under-utilized because we aren’t patient enough to learn them thoroughly.

Post reply on HN