A sadly typical flavor of essay: a lisp enthusiast who believes that learning lisp has made them into a uniquely Very Smart Boy who can think thoughts denied from programmers who use other languages. The "blub" paper asserts that there exists a linear hierarchy of goodness and expressiveness in languages, where lisp, by virtue of its shapelessness, exemplifies the pinnacle of expressiveness.

This is a profound misapprehension of the nature of language design. Languages exist within contexts, and embody tradeoffs. It is possible- common, even- to fully grasp the capabilities of a language like lisp and still find it inappropriate or undesirable for a given task. Pick any given context- safety-critical medical applications, constrained programming for microcontrollers or GPUs, livecoding environments where saving keystrokes is king- and you can find specialized languages with novel tools, execution models, and affordances. Perhaps it never crossed Paul Graham's mind that lisp itself might be a "blub" to others, in other situations.

The idea of a linear hierarchy in languages is the true flatlander mindset.

▲

rented_mule 7 hours ago | parent | next [-]

> The idea of a linear hierarchy in languages is the true flatlander mindset.

100% this. I think you can replace "languages" in that sentence with many things (employee levels is another big one that is relevant to this forum - employee value comes in many, many shapes). Reducing complicated things to one dimension can be a useful shortcut in a pinch, but it's rarely the best way to make complicated choices among things.

▲

chihuahua 7 hours ago | parent | prev | next [-]

It would also be a lot more persuasive if the article provided even a single example of how Lisp enables superior solutions.

Instead, it's just an ad-hominem attack based on the idea that non-Lisp programmers are too limited in their thinking to appreciate Lisp.

Show me a convincing example of something that's simple/clear/elegant/superior in Lisp, and how difficult/complicated/ugly/impossible it would be to do the same thing in Java/C++/Ruby/Python.

In the absence of that, the entire article can be refuted by quoting The Big Lebowski: "Yeah, well, you know, that's just, like, your opinion, man."

▲

wrs 6 hours ago | parent | next [-]

It’s amazing how people are reading this to say the opposite of what it says. The end of the essay literally tells the reader they can appreciate Lisp if they just take the time to understand it, and they should make the effort. Not “if you don’t already know this, you must be stupid.”

If someone writes code based on an algorithm out of a 1985 textbook, and I tell them that they could make it go 20X faster if they learned more about processor architecture (out-of-order execution, cache coherency, NUMA, etc.) — a new dimension of programming to them — am I making an ad hominem attack?

Once I made somebody’s SQL query 100X faster by explaining what an index was. Fortunately they didn’t think I was attacking their intelligence.

▲

evdubs 5 hours ago | parent | prev | next [-]

> Show me a convincing example of something that's simple/clear/elegant/superior in Lisp, and how difficult/complicated/ugly/impossible it would be to do the same thing in Java/C++/Ruby/Python.

Serialize and deserialize data. You're currently using something like XML or JSON for a human readable data serialization format in those languages. JSON and XML are not first class components of those languages. S-expressions are a better version of JSON and are first class components of Lisp.

▲

bccdee 4 hours ago | parent [-]

That's a bad thing, though. You should not be `eval`-ing your config file, much less untrusted messages.

▲

attila-lendvai 3 hours ago | parent | next [-]

you don't need to call eval for the usual config file setup, only read.

(but you often get something much better when config files are plain lisp code; i.e. they are eval'ed, assuming that the threat model allows it)

▲

evdubs 4 hours ago | parent | prev [-]

I am not so sure how it works, but you can define your own evaluation handler for `eval` which, I assume, can be as restrictive as you need if you're dealing with untrusted data.

	▲	bccdee 4 hours ago \| parent [-]
		Seems simpler just to use `json.load`.

▲

didibus 4 hours ago | parent | prev | next [-]

I don't think the article argues for superior solutions, but I understand how it can feel as such.

I think it's just trying to say there's another dimension, the meta-level enabled by macros and Lisp's syntax that opens up the possibility of new solutions, which may or may not be better, as that's so context dependent.

But what I feel it's saying is you can't even begin to imagine solutions that leverage this new dimension without learning about it and getting to grip with it mentally.

In that sense, it's saying when you don't know, you can't even explore the space of solutions at that higher dimension, not necessarily that they're better for all problems.

▲

wrs 7 hours ago | parent | prev [-]

The example that comes to mind immediately is that inline assembly is a Lisp macro.

You can also read anybody ranting about how great Zig comptime is if you want more contemporary examples.

▲

wrs 7 hours ago | parent | prev [-]

“Common, even”? Citation needed. I’ve worked closely with hundreds of developers over the years and maybe two of them made a conscious, knowledgeable choice whether to use Lisp for something.

You’re even sort of making the same point. Specialized problems need specialized tools. How do you write those specialized tools? Start from scratch, or just make a Lisp package?