3 ms·

I assume that the author, like many people, has an allergy to parentheses or something like that. As far as I'm aware, there is no way to measure whether a lan

I assume that the author, like many people, has an allergy to parentheses or something like that. As far as I'm aware, there is no way to measure whether a language is "objectively bad" except if that language does not allow you to do what you want to do (or, maybe, if the language makes doing what you want to do unreasonably difficult). Emacs Lisp has been successful for decades and by all appearances is going to continue being successful, which in my mind makes it objectively good by any empirical measure. (By this measure, we could consider languages like the assembly languages, ALGOL, etc as "bad", so long as the context for analysis is "writing modern high-level software." They are mostly no longer used except when necessary, which seems to me the only measure worth considering until we develop a theory of language usability analysis.) I wish the author had not been so vague in this dismissal. While their article is certainly allowed/encouraged to be full of opinionated conjecture (as they defend in the opening), I think such a strong position is deserving of at least a little more justification.

gamegoblin 6y ago
I think the quibble here is about "objectively bad" vs. "objectively worse". I believe the author somewhat elaborates on what he means by "objectively bad" with his example of Javascript having two "null" sort of values, which under a reasonable definition is objectively worse than a theoretical Javascript with a single null. So if we read the author charitably, taking into account his example of Javascript having two nulls being objectively worse than a theoretical Javascript with one null, we can interpret his statement as "Emacs Lisp is objectively worse than other Lisps, which have essentially identical functionality and fewer sharp edges".
- 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 ago
    Yeah, 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 :)

gamegoblin 6y ago

I think the quibble here is about "objectively bad" vs. "objectively worse". I believe the author somewhat elaborates on what he means by "objectively bad" with his example of Javascript having two "null" sort of values, which under a reasonable definition is objectively worse than a theoretical Javascript with a single null. So if we read the author charitably, taking into account his example of Javascript having two nulls being objectively worse than a theoretical Javascript with one null, we can interpret his statement as "Emacs Lisp is objectively worse than other Lisps, which have essentially identical functionality and fewer sharp edges".

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 ago
  Yeah, 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 :)