I wrote an article back in 2015 entitled The Case for Lisp . It lays out a simple argument, founded on expressiveness, for choosing Lisp.
Now I would like to lay out some reasons why one might not choose Lisp for a project. Focusing on Common Lisp for this article.
- The very s-expression syntax which enables structural macros which gives lisp some extra expressiveness power vs most other programming languages, also serves to make the code harder to read for the vast majority of people. Perhaps the flexibility of s-expression syntax is overweighed by the increased cognitive overhead required to read the code. Even after I spent quite a lot of time reading and writing lisp over a period of several years, I would still find it a bit more challenging to read lisp code than to read, for example, java code.
- I think in the age of autocomplete and ide-assisted coding, lisp's OOP model and function comes before object mentality is less ergonomic than the dominant object.method paradigm. Consider `(bark dog)` vs dog.bark() to see what I mean. The latter syntax is extremely amenable to autocomplete in an IDE and provides some "namespacing" to the bark() method where it won't pollute the global autocomplete context but instead only comes up in the context of the dog object.