We had a small group (~20 devs all together) that decided they wanted to do a lot with clojure. So they started several projects throughout the company and, for the most part, they all very much enjoyed using clojure.
However, as those projects shifted into maintenance mode and that group moved on to greener pastures, we were left with a bunch of projects that were inscrutable. The big issue we ran into is that lisp LOVES to give programmers the ability to metaprogram and programmers love metaprogramming. However, when it comes to maintaining a metaprogrammed monster... that's basically just learning a new language used by nobody but this single project.
The end result was that people dreaded taking charge of lisp projects. They were hard to ramp up on. Hard to maintain. And they had really strange and hard to diagnose bugs. We've since spent the money rewriting most of the projects in java. I believe there are 2 that were simply too big and complex to do such rewrites against.
My takeaway is that lisp is much like perl. When you know what you are doing it can be a lot of fun, but heaven help the person that has to later read what you wrote.
> that's basically just learning a new language used by nobody but this single project
and there is no source to learn the language from. other than the "self-documenting" code, which often isn't.
I am not opposed to using abstraction. Sometimes abstractions are powerful. But the more abstract you go, the more effort you need to spend to make sure you communicated it properly to the rest of the team -- including its future members.
Are you sure you didn't just Google up the Lisp Curse and use it as an excuse to avoid engaging what was mostly idiomatic Clojure?
Rampant metaprogramming is not that common in Lisp codebases, and what of there is will tend to be pretty shallow, like bits of syntactic sugar here and there.
Do you have some example of the inscrutable metaprogramming?
One dev came up with their own macro that linked together the http client and json parsing into one magic macro which allowed them to also format the json, log it, and a bunch of other conveniences mostly for that dev. Unfortunately, the function was highly tailored to where it existed (with hard coded params and such). It's invocation ended up looking something like `(ht-j g foo 'log')` (because this dev also liked shortening everything).
Another example of this is some devs wanted to make a super generic data fetching... thingy... so they came up with this wild macro where you could feed in http urls and a custom configuration and it'd expose calls to that downstream services. It allowed for a sql like interface into several different microservices. Interesting in concept, impossible to maintain. That project was ultimately scrapped.
I was unaware of "the lisp curse" before my comment. This was just what my company experienced.
Something like (ht-j g foo 'log') could be a function. Someone could do that in Javascript like htj.(g, foo, 'log') or whatever, which is no more or less clear. You wouldn't have a code generation step to deal with, but you can expand macro calls in situations when the macro body isn't readable.
We had a small group (~20 devs all together) that decided they wanted to do a lot with clojure. So they started several projects throughout the company and, for the most part, they all very much enjoyed using clojure.
However, as those projects shifted into maintenance mode and that group moved on to greener pastures, we were left with a bunch of projects that were inscrutable. The big issue we ran into is that lisp LOVES to give programmers the ability to metaprogram and programmers love metaprogramming. However, when it comes to maintaining a metaprogrammed monster... that's basically just learning a new language used by nobody but this single project.
The end result was that people dreaded taking charge of lisp projects. They were hard to ramp up on. Hard to maintain. And they had really strange and hard to diagnose bugs. We've since spent the money rewriting most of the projects in java. I believe there are 2 that were simply too big and complex to do such rewrites against.
My takeaway is that lisp is much like perl. When you know what you are doing it can be a lot of fun, but heaven help the person that has to later read what you wrote.