You must log in or register 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.
deleted by creator
Looks like a typical Js/Ts codebase to me. :)
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
Oof. Is that the official plugin language? Siemens NX uses “grip” which is a fork of TCL. And they require purchase of a pricy package to sign and compile code so NX will run it, so we only had one programmer for our custom grip functions.
Having worked with Clojure for over a decade now, I find it far easier to refactor than most other languages I’ve touched.
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!
Reverse Polish notation, right? Operand operand operator?
That’s the one. The Wikipedia article has some extensive examples, too.
Its weird syntax prepared us well to face the horror of assembly language later on, so I have a certain fondness for it. That and I had absolutely no point of comparison at the time, haha!
It makes sense if you just think of everything as a function.
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.
