|
|
|
|
|
|
by jb1991
1279 days ago
|
|
|
I worked on a large Clojure app for a small company for a few years and it eventually died for similar reasons as you describe. Then, I was hired to work for a startup also developing a large Clojure app, and I must say, it was a very challenging onboarding. The main problem is that "anything goes" in a language like Clojure, which can be great or devastating. My personal take is that the lack of types makes it very hard to understand a large codebase you are exposed to for the first time, unless, as you say, it is structured in a way that was very clear and strict from the outset. Trying to trace the ideas through a large Clojure codebase can become extremely difficult when all they are is a bunch of functions with untyped parameters. Liberal use of spec can help to some degree (though that is also a challenge to enforce, much like optional typing in some languages) but it doesn't change this fundamental paradigm of the language, and I've seen more businesses sunset Clojure than move to it. It's a shame, really, since the language is vastly more flexible and powerful than most, but it goes to show that there are some things that have, in the wild, outsized influence on productivity for the 80%. |
|
|
Another is -- lack of good IDE support (which is connected to lack of strong typing). In something like Java you can always understand what is the thing under your cursor.
But an experienced developer knows how to deal with these problems. Lack of strong types means you have to be building clean, well specified interfaces. Lack of strong typing in language does not mean you don't have types in your program -- it just means that it is now on you to make sure it is easy to figure out what is the exact specification of piece of data at any point in the program.
I also found that spec rarely helps. One of the major points of something like Clojure is to be able to create general purpose functions that can do useful operations on very wide range of data and then use those functions to compose your program. Spec really hinders your possibilities here.
> It's a shame, really, since the language is vastly more flexible and powerful than most, but it goes to show that there are some things that have, in the wild, outsized influence on productivity for the 80%.
It is the curse of Lisp. It is the most powerful language that can exist and yet it will never be mainstream because it requires a whole other level of development mastery to really get the productivity benefits.
I personally use Clojure for my rapid prototyping which is to say -- "as long as I am sure nobody else will ever need to work on it with me".
I did a very efficient algorithmic trading framework proof of concept in Common Lisp and it was a joy to work with. But then when it came to actually productionising it I was forced to rewrite it in Java at the cost to performance and heaps of boilerplate code.