You must log in or # to comment.
))))))))))))))))))))))))))))))))))))))))))))))
I love how much of a kamikaze this is: “yeah that thing LISP does terribly? Non-LISP languages do it too!”
Also this just looks like bad code, not a limiting feature of the language.
Except LISP doesn’t do it terribly, and in my experience there are a lot less parens and other separators than in most languages.
Ok… but the comic doesn’t say that…
The comic doesn’t say anything about Lisp doing it terribly either. It’s saying that people who complain about parens are dealing with far worse in mainstream languages.
It quite literally says “LISP is ugly and confusing with those endless parentheses” and then fails to refute that claim
It’s making fun of people who say that lisp is ugly and confusing. There’s nothing to refute there either since the claim is nonsensical as anybody who’s actually used lisp knows.
I mean if you have that many indents you’re probably writing bad code.
Looks like a typical Js/Ts codebase to me. :)
Then there’s Haskell where arguments to a function are given with spaces
I have fond memories of RPL on the HP48 calculators where you would give arguments as a stack, then call the function. Something like (a+b)*c could be written C A B + * Such fun!
As a parentheses hater my personal hell would be having to audit and refactor a lisp codebase
My work maintains a legacy AutoCAD addin written in Lisp… we are considering dropping support because it’s so difficult to maintain with the original dev gone
Having worked with Clojure for over a decade now, I find it far easier to refactor than most other languages I’ve touched.
The real interesting debate is between
((f) 1)andf()(1).I personally find
((f) 1)easier to read. You just go inside out, evaluatef, then pass1as the argument to the output off. There’s no ambiguity regarding order of evaluation there.
