4 ms·
This experience is extremely common. I have lost track of the number of people who have formed a negative opinion of Clojure because they were forced to pick up
by venantius 10y ago
This experience is extremely common. I have lost track of the number of people who have formed a negative opinion of Clojure because they were forced to pick up the pieces of a half-baked project written by someone who wasn't familiar with Clojure or its idioms.
It should go without saying that this should not actually reflect poorly on Clojure as a language.
- cle 10y ago> this should not actually reflect poorly on Clojure as a language. Why not? If a language's goal is to be practical (as is Clojure's), then it should take practical concerns into consideration. This is something that the Java community definitely gets right.
- sova 10y ago>Why not? Because someone who has never heard of map/reduce/filter/partial will need to do some studying to leverage the spine of the language in order to make living, breathing code-organisms.
- jug 10y agoI have a feeling this issue can be made more abstract and cover more languages, more paradigms than just that of Clojure. The real problem here does not seem to be Clojure, but finding developers as well as faith in new (or small) languages to build that solid, big project that has stood the test of time before you abandon it for something you have an easier time finding developers for, or faith in.
- yogthos 10y agoMy team does code reviews and pair programming, especially when onboarding new devs. This helps new hires get comfortable with the style the team uses, and ensures we have clean code in our project. We've hired a number of devs for our Clojure projects, and none of them knew Clojure when they started. We found that this process has worked very well for us.
- shadowmint 10y agoThe problem is that problem clojure code is the gift that keeps on giving, and it boils down to the problem I have with clojure in general: Bad clojure code is unmaintainable spaghetti code; which gets worse over time, as people attempt to 'patch on' fixes without doing the heavy lifting of trying to figure out: - What was the original author actually trying to do? - Why the heck did they do it like this? - How do we create the same functionality and prove it works with these rubbish tests that only test the individual units of work, not the application function? - Why is it all in one giant file? I've never seen code bases descend into chaos as fast as our clojure ones have. Nice, elegant clojure is a pleasure to work with for personal projects, but I'm never using it professionally again. You might argue it doesn't reflect on the language, but I think it does. Given what I've seen, I'd argue that clojure has an inherent complexity that results in poor code quality outcomes during the software maintenance cycle. ...specifically, sections of bad code have a disproportionately negative effect (compared to other languages) on the surrounding code and negatively impact the entire project's code quality. You hack something out for a deadline? You better go back and clean it up, because if you don't that codebase is screwed. shrug That's just been my experience over the last year on three different code bases.
- bootload 10y ago"I've never seen code bases descend into chaos as fast as our clojure ones have." Is this a function of the teams or the language?
- shadowmint 10y agoPossibly, but there's nothing particularly wrong the other code they maintain in our case.
- abecedarius 10y agoI've only played with Clojure a little bit. Can you explain what makes bad Clojure code especially bad? Or why the badness leaks into the surrounding code? (The impression I've gotten is that the persistent data structures are very nice, and the language has some good ideas to go with them, but overall it didn't entice me away from Scheme or Common Lisp. But that impression doesn't explain why you had this bad experience with troublesome Clojure code.)