4 ms·
But the author does not elaborate on the "objectively bad" statement explicitly, leaving it to the reader to discern what makes Emacs Lisp bad. And I think "wor
by DonaldPShimoda 6y ago
But the author does not elaborate on the "objectively bad" statement explicitly, leaving it to the reader to discern what makes Emacs Lisp bad. And I think "worse" makes less sense, because it is not being directly contrasted against any other language. The author simply takes it for granted that readers will agree Emacs Lisp is "bad" and leaves it at that, which I think is unfortunate.
Your example wrt. JS's two null types doesn't exactly generalize. What are Emacs Lisp's "sharp edges", as you say? What does it prevent people from doing? In what way could it be made more ergonomic? I would argue that its long-term proven stability is an indicator that the language does not have sharp edges; at least, not ones which discourage its use significantly. When you go into discussions about programming languages, you can't throw a stone without hearing somebody bemoan Javascript or PHP, but I never hear Emacs Lisp being brought up (and people who do bring up Lisp are often just upset about the abundance of parentheses, it seems).
I dunno, it just strikes me as the author acting as though this is a given assumption, and I don't quite see it. I'm not saying they're wrong (because, of course, the entire article is an opinion piece and the author is entitled to their opinion), but rather that I just wish this claim had gotten a bit more justification.
- matklad 6y agoYeah, I agree that not elaborating on this was unfortunate (but elaborating would be tangential, as relatively few people are familiar with Emacs Lisp). I think Emacs Lisp is in the "easy to improve upon" category because of: * lack of namespaces * dynamic binding by default * spartan standard library I do love parenthesis though :)