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