[RodgerTheGreat]

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]

> 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]

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]

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.

[hu3]

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

Next time try calling them a "2D programmer who lives in flatland" for not knowing about indexes and tell me how it goes.

[wrs]

I honestly don’t understand how that’s offensive. It’s just a metaphor, and a pretty good one. Why are you taking it as some kind of value judgement? Do you feel like people who don’t know something are lesser beings?

The book was originally written as a metaphor for understanding a fourth spatial dimension, and as far as I know the metaphor is generally taken as helpful, not demeaning. The flatlanders are never described in an unflattering way.

[evdubs]

> 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]

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

[attila-lendvai]

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]

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]

Seems simpler just to use `json.load`.

[wrs]

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.

[chamomeal]

For me macros are a power user tool that are useful in libraries to seriously upgrade UX of your public functions. Kinda like how crazy complex typescript generics can seriously upgrade the UX of your lib.

It’s hard to explain without explaining a bunch of what a specific library does. But many clojure libraries expose macros that let you interact with them in much more readable/terse ways.

I’m on my phone but a good one to google is core.logic. It exposes a macro to define a “logic function”, which lets you define logical expressions using pattern matching. You can come up with rules that would be many more LOC and less readable as a normal function. You can of course define them as a normal function too, which is useful when the pattern matching doesn’t express the problem well!

[didibus]

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.

[DeadEarnest]

Two extremely powerful things that would be awful not in Lisp:

1) Electric Clojure 2) Rama

[wrs]

“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?

[anthk]

PicoLisp exists for microcontrollers.