4 ms·
I've done it, now I hate Lisp. I've read On Lisp and Let Over Lambda, I've used Clojure in production, and I still hate Lisp, any and all of them. What am I doi
by LessDmesg 7y ago
I've done it, now I hate Lisp. I've read On Lisp and Let Over Lambda, I've used Clojure in production, and I still hate Lisp, any and all of them. What am I doing wrong? Perhaps it's that reading code is more important than being clever when writing it. Or maybe that Lisp syntax doesn't pass the squint test[0] because it makes the wrong tradeoff of catering to the machine instead of us good ole' humans?
When I make my own language, I'll make sure to make macro calls as clumsy and hideous as possible to discourage their unexpanded use. I'll also make the whole language available at compile time but without syntax manipulation (a la Zig) to make most macros unnecessary.
So no, Lisp is far from "the language to end all languages" or whatever it is you smug Lithp weenies imagine it to be.
[0] https://www.teamten.com/lawrence/writings/the_language_squint_test.html https://www.teamten.com/lawrence/writings/the_language_squin...
- aganame 7y ago> When I make my own language, I'll make sure to make macro calls as clumsy and hideous as possible to discourage their unexpanded use. Sounds like Rust beat you to it.
- TurboHaskal 7y agoMaybe instead of reading On Lisp and Let Over Lambda you should have started with something that explains and encourages the use of CLOS, because that's where Common Lisp really shines.
- LessDmesg 7y agoI know about CLOS, multi-methods, the meta-object protocol. It's a nice, dynamic OOP system (though I'm not a fan of dynamic languages). The thing is, CLOS isn't Lisp-specific: it can easily be recreated in a language with a normal syntax, e. g. Smalltalk. So there's no reason, ultimately, to sacrifice readability and maintainability to the demons of Parenthethes and Pervathive Macroth like the Lithp acolytes would have us do. Lisp is just a bad tradeoff from the get-go: reading code is more important than writing, language simplicity is more important than extensibility, and macro-writing is secondary to regular code writing.
- TurboHaskal 7y agoNice, but I think you are exaggerating a bit. Not every Lisper is a smug Lisp weenie. Actually I don't see many of those these days so I don't get the hate. Most of the annoying tribalist folks jumped ship to the Rust and Haskell camp. Syntax is highly subjective, and funny that you mention Smalltalk, as I had a hard time selling that to some developer friends of mine because the method based syntax really put them off. I also prefer statically typed languages, at least in the context of professional work with developers with various degrees of expertise contributing to the codebase. Then again, if I have to work in a dynamic language, I definitely take something image based with great tooling and feedback loop such as Pharo or LispWorks over Python or Ruby any day of the week.
- lispm 7y agoSince people have different needs and tastes, there is no single type of syntax mechanism agreed upon. Lisp generally favors flexibility, easy code generation/transformation, code as simple data structures, extensibility... that's attractive and useful for some.
- ken 7y agoI'm not sure what the Language Squint Test is supposed to tell me here. I can clearly see the structure of the Lisp code, too. It's only half as long as the Java one, which is great for reading. A single character can completely change the meaning of an entire block of Java code, too -- that has nothing to do with macros. > I claim that this squint test is important, and that languages should deliberately make different constructs look different. For your example, you just happened to pick a programming language you already know well. If this is a beneficial goal, why pick that particular point on the spectrum? Java and Lisp aren't the only games in town. It would be a remarkable coincidence if the language you already know were the optimal point. COBOL's constructs look even more distinct from each other. A COBOL programmer probably thinks your Java methods all look the same despite having completely different calling conventions. After all, COBOL was definitely designed for "us good ole' humans".