LISP is a family of programming languages that have a very limited set of syntax based off of "s-expressions", for example:
(+ 1 1)
(map f '(1 2 3 4))
-
I am dyslexic. to me, when I'm reading code I use the general shape and syntax of the program to help me understand the structure before I go into the details. lisp is super unreadable to me!!!! the "single syntax structure" that it has does not help to distinguish between different constructs at all. this isn't a problem that only lisp has, heavy operator usage in haskell has the same problem for me.
-
quoting is confusing. lisp doesn't actually have "only one syntax" like a lot of people seem to say when they introduce lisp to other ppl. lisp has function calls `(+ 1 2)` AND lisp also has quoted expressions `'(1 2 3 4)`.
not only does this add to a lack of readability but it puts more mental labor on the programmer for remembering if the structure they're writing is going to be evaluated or not.
there's also UNquoting where an unquoted s-expr will actually be evaluated if put in a quoted s-expr. but unquoting is only allowed in specific quasiquoting expressions (this is specific to racket MAYBE???) I ain't reading all that bestie, btw this makes the dyslexia problem so much fucking worse lmao it's a mess!! absolutely not necessary -
relying on macros is generally a bad pattern and lisp doesn't give developers enough tools to make good macros
I will eventually make a post about why macros are an antipattern imo but it comes down to documentation. language designers put a lot of effort into making syntax well defined, behave soundly, and well documented. macros are very easy to make into awful code or unsound code, passing around code instead of values is a level of detail that only language/library developers should be doing. this comes from the irl experience of seeing programmers make poorly documented macros that should have just been functions.
personally I think rust treads this line pretty well where its macros are largely meant to be made by language/library devs and software engineers are steered away from making macros in my experience. even with this in mind, having used the rust parsing library `nom` when it was still macro-based, that was an awful dev experience and I was really appreciative when they moved to parser combinator functions -
lists/tuples as the default data structure actually sucks, and objects win every time. "give your variables readable names" is the first bit of advice given to new programmers.
having lists and tuples as the default datastructure in a language encourages programmers to create datastructures with unnamed fields.
let's look at a beginner code example: animals. in javascript code examples I have seen `{species: "dog", name: "fido", age: 5}`. in lisp the same data structure could be defined in the following ways: `'(:dog "fido" 5)` `'((:species :dog) (:name "fido") (:age 5))`. having multiple ways to do one thing isn't necessarily bad, but in lisp using an assoc list (an object) has more friction than a tuple or list with unnamed fields. ppl can say "just do it right, use an assoc list" but people in the real world don't do that! from seeing beginners use lisp dialects I have seen that they routinely fall into using unnamed tuples in lisp but naturally tend to name fields in javascript or python
if lisp has 99 haters I am one of those haters, if lisp has 1 hater I am that hater, if lisp has 0 haters I am dead
edit: comment section on this post has an even more fucked example of why quoting is so awful
from @pommicket
> (define-syntax-rule (a x) '(x))
> (a 3)
'(3)
> (define (a x) '(x))
> (a 3)
'(x)
