5 ms·

Ha. I personally have sat in a meeting where a clojure enthusiast was explaining how he had quickly built a system. He could not explain the code he had writt

Ha. I personally have sat in a meeting where a clojure enthusiast was explaining how he had quickly built a system. He could not explain the code he had written only three weeks before. Clojure suffers heavily from a “less code is good code, write clever code not verbose code” culture. For newcomers this creates dumpster fires that are quick to create and impossible to maintain. Anywaaay, long story short: no. It doesn’t. Specifically, I’ve seen it be a dumpster fire three times. Perhaps your experience has been different; but you are flat out wrong in your generalisation; and that arrogant attitude has been the root cause of all three failures I have personally had to clean up after.

elric 2y ago
People who complain about verbosity and boilerplate in Java generally fall in 1 of 2 categories: people who haven't used Java for anything non-trivial in a very long time, or people who are bad at designing abstractions. Less code can be good code, but they largely are orthogonal axes. Without good abstractions, it doesn't matter whether code is dense or verbose, it will be bad and difficult to grok.
- deleted 2y ago
  [deleted]
- puredanger 2y ago
  Having done substantial work in both Java and Clojure, my experience with abstraction in both is that in Java, making things more abstract almost always involves making the code larger (adding more interfaces, extending existing types to those interfaces, etc) whereas in Clojure making things more abstract typically means they get smaller. Over time and at scale, this matters quite a lot. Java code grows and grows at a super linear rate as it handles new and changing requirements. This is ultimately not sustainable. Clojure code typically grows at a more linear rate (accretion of attributes in data or operations on data), but has more tools to create abstraction that can actually (if wielded well), be sub linear instead. This kind of change is not free or easy in any language, but in Clojure it is at least possible.

elric 2y ago

People who complain about verbosity and boilerplate in Java generally fall in 1 of 2 categories: people who haven't used Java for anything non-trivial in a very long time, or people who are bad at designing abstractions. Less code can be good code, but they largely are orthogonal axes. Without good abstractions, it doesn't matter whether code is dense or verbose, it will be bad and difficult to grok.

deleted 2y ago
[deleted]
puredanger 2y ago
Having done substantial work in both Java and Clojure, my experience with abstraction in both is that in Java, making things more abstract almost always involves making the code larger (adding more interfaces, extending existing types to those interfaces, etc) whereas in Clojure making things more abstract typically means they get smaller. Over time and at scale, this matters quite a lot. Java code grows and grows at a super linear rate as it handles new and changing requirements. This is ultimately not sustainable. Clojure code typically grows at a more linear rate (accretion of attributes in data or operations on data), but has more tools to create abstraction that can actually (if wielded well), be sub linear instead. This kind of change is not free or easy in any language, but in Clojure it is at least possible.