Clojure is cool

And in the general case verbosity and cleverness are orthogonal properties.

Is there some particular aspect of the Clojure code here that you think is overly clever, or hard to understand? This Clojure code uses only one lambda, and in a straightforward way.

I've written a lot of Java, and a moderate amount of Clojure, and if I had to place a wager on which version had fewer bugs, I'd definitely bet on the Clojure. Especially if there were the possibility that it was related to threads.

We could write this in assembly language, and it'd take 50,000 lines, and probably have lots of bugs. The salient point is not (just) the lower line count, but that when code is shorter, that's a good indicator that it's written at a level of abstraction that fits the problem.

Clojure code is far easier to maintain for a number of reasons. The code is declarative, so it separates what's being done from the implementation details. The first step of code maintenance is to understand the intent, and it's much easier to do that with declarative code. Immutability means that the code is largely referentially transparent, so the cognitive load of understanding a particular piece of code remains constant as the project size grows. This is not the case for imperative languages where you pass references to shared mutable state all over the place. The syntax is much smaller and more consistent, meaning that you have to learn less rules and quirks to understand the code. There are less chances of code being misinterpreted. Finally, you have the REPL, so you're able to run any code you're not clear about right from the editor in the context of your application.

My team moved from Java to Clojure about 8 years ago, and we find that it's much easier to maintain Clojure projects than it was for similar scope Java projects. We deliver faster, we have far less defects, and we're able to make changes much more reliably than we ever could with Java.

Comments are fine when the code is doing something unexpected or that is very terse. In other scenarios, comments are just a land mine to be armed when the code changes and the comment isn't perfectly updated. Bugs largely come from developer expectations being broken (mostly by one of: misunderstanding data shape, some API detail, some language feature, or miscommunication on the feature with the owner) and stale comments are a contributor to this which can be avoided in many cases.

Docstrings for trivial, well-named functions just get in the way, and if you feel the need to add a docstring to a complex function just after you've defined it, then I think that might be a hint that you should refactor the code to make it more clear and readable instead.

An ns docstring that describes the intent of the api and docstrings for the major public interface functions are a good idea, but a blanket "docstring for every function" rule is a crutch to make up for unreadable, poorly-written code.

Comments are a useful for explaining the implementation logic of a function or method, for instance. Or for generating API documentation. And file-level comments explaining the purpose of the class or module are always handy.

IMHO structure editing emphasizes the wrong part of code development. In practice collapsing graph structure is less important in code as opposed to, say, JSON. Whereas you want to be able to use your eye to hop around, and free-form alignment sometimes helps to show parallel constructs.

Remember also that in a structure editor even your comments have to be part of the code and can only be inserted in places where an expression won't change the flow of control (e.g. you can't do (if (* this is a comment*) some-condition result))

In a very OO language, where you're encouraged to create a complex type for every function/method contract (i.e., I have a type of RoomMeasurement, that internally contains a list of Measurement interfaces, each of which is in fact implemented as a MeterMeasurement, which wraps a double), static typing is very, very necessary, because it's not at all obvious what a function takes. And you need thorough API documentation because how another developer has chosen to represent things is not obvious (that is, you are trying to interoperate with a library that doesn't understand your RoomMeasurement, but does work with just a list of measurements, but they have to be in imperial, not metric, and how do you get the list of measurements from your RoomMeasurement, and convert them? Do you have to write a function, is there one already, does it take the RoomMeasurement, does it take the list of MeterMeasurement, does it just take a single MeterMeasurement? Etc)

When sticking with simple types, though, it becomes a lot easier to reason about, and you can get away with just comments, or very slightly more complicated types. A list of measurements is just a list of ints...but maybe dropped into a tuple where the first arg is the type (i.e., roomMeasurements = {meter, [4.22, 5.7, 3.1]} ). And all you have to find/write (and since it's just data it doesn't matter which because there's no hidden stuff that needs tweaking) a meterToFoot function, and apply it as a map. I.e. (pseudocode), ->

feet = {foot, map(roomMeasurements[1], meterToFoot)}

Now, is that perfect? No; even if you as a developer choose to apply type information, another developer can choose to ignore it. But I think that's rarer; more common is when people don't think to supply type information at all, and pass around just (per the example), an array of doubles. You can do that in a statically typed language too, though.

I think the key difference is that people coming from a statically typed, OO language, to a dynamically typed FP language, can either end up creating the same complex data types (which are a nightmare to deal with even with static typing, but doubly so without), or they see all the examples, embrace the simpler data structures...and then don't actually supply the necessary typing information.

The reason, then, that I think static typing -is- good, is because it makes it harder for me to ignore/forget to handle the typing I have provided. That is, I may have a 'metricToImperial' function, that takes in a type tagged array of doubles, and a desired type, and determines and applies the appropriate function. But I can still forget to include a necessary conversion in the resulting case statement ('whoops, I called it with a lb to g conversion over here, and I forgot to implement that one'). It's times like that I really like optional/inferred typing; many places I don't need to check for typing, because it's obvious, both to the developer, and to the compiler if it can infer types...but I can still make mistakes, per that. Of course, that brings me to unit testing...

If you want proper static typing though, ReasonML might be a good choice. Static, compiles to js and native, super easy to learn, and there’s an experimental Lisp frontend with Clojure-like syntax if you can’t live without paredit.

[1] https://github.com/gnl/ghostwheel

I'm unsure of a good way to represent optionality in a dynamic language without a static type system. Or rather, doing so with the tools available -- core.match vs real pattern matching -- seems rather un-ergonomic.

I'm curious about your thoughts of what would be better.

https://clojure.org/community/success_stories

The current de facto tech stack for building SPAs in ClojureScript seems to be Reagent + Re-frame (or something built on top of them). It's conceptually so close to React + Redux that I have a really hard time imagining a Redux guru who wouldn't be productive with Re-frame in two weeks.

Then of course you can have jQuery developers who absolutely cannot work with React and probably never will, and possibly vice versa (never seen that tested). Back in the day AngularJS was cool but much of the code written with it was horrible, because people wouldn't work through the tutorial which explained how to use it as a tool, not a footgun.