Comment by cultofmetatron
9 months ago
as someone who writes elixir all day, I really love what lisp is but I feel lisp's major weakness is that it makes everythign unergonomic in order to make macros very ergonomic. You will never find another language in which writing macros is easier. the problem is it comes at the cost of doing everything else a bit of a pain in the ass.
I love elixir because it feels like the syntax clojure would have if it had a syntax imho.
> major weakness is that it makes everythign unergonomic in order to make macros very ergonomic.
Generally Lisp has two main goals:
* allow code to be data and data to be code
* make coding and coding code (let code manipulate code) interactive
The s-expression based syntax was found to be useful for both. For the latter it means that code can be manipulated interactively for example by structure editors or in read-eval-print-loops which work with data. That makes interactive code writing very ergonomic.
> it makes everythign unergonomic in order to make macros very ergonomic
I think 'everything is unergonomic' is a too strong of a statement to be true.
I'd argue that lisp is very ergonomic for those who work with it regularly (and are into using Emacs). It sounds like you are beefing with the syntax (or lack thereof) and homoiconicity of Lisp. I can understand that. It is a very different language than others currently in the mainstream for that reason.
As far as overall ergonomics, I'd say the REPL/image-based development style and the macros that are enabled due to homoiconicity actually make it one of the most ergonomic languages in existence.
The biggest thing that prevents Lisp-likes from going mainstream is that it is too ergonomic, specifically, when you start reading a Lisp codebase, you essentially are signing up to learn a new project-specific dialect. Very ergonomic for writing code, but at the cost of understanding how that code operates.
> lisp's major weakness is that it makes everythign unergonomic in order to make macros very ergonomic.
That is simply false. The ergonomics of editing Lisp is also superb.
There is a consistent, logical way to break any Lisp expression into any number of lines of text. The more you break Lisp into multiple lines, the more clearly the tree structure of the code is revealed.
The absence of ambiguity helps readability: not having to guess which expressions are children of what operator.
Lisp code sometimes makes up for the parentheses by omitting superfluous punctuation like commas and semicolons. To add two terms, we need ( ) and +. But that's all we need to add 17 terms also.
Imagine if the Unix shell required commas between arguments:
that's how Lisp programmers feel when back in a non-Lisp.