I appreciated the look into ClojureScript as someone who's never touched it (and whose interest is definitely piqued now), but I'm baffled by the article's initial hook of 'let's compare how many characters it takes to accomplish the same task'. Is this really a meaningful metric? There's value in comparing the relative clarity and expressibility of each language, but that's not necessarily synonymous with brevity. I get that it's not the heart of the piece, but starting with such pedantry seems to detract from the point.
>I get that it's not the heart of the piece, but starting with such pedantry seems to detract from the point.
I'm guessing it's there to persuade people that have preconceptions about lisps verbosity/readability to read the article instead of immediately dismissing it.
Brevity is not orthogonal to clarity; it is clear that overly verbose code is not as readable, just because e.g. it doesn't fit on your screen (or in your head) all at once.
Brevity is a feature of clarity, and clarity usually attends very powerful notions like reuse and application to a new domain.
What's truly orthogonal is some notion of "expressiveness" or "teachability" or otherwise being-able-to-read-and-understand.
The example that you should think of here is mathematics papers. The ideas are stated in their clearest form, which usually is absurdly brief: lemma, theorem, proof. You can then spend about an hour poring over each line to figure out what the heck it's expressing, before suddenly a moment of clarity dawns on you and you see all of the connections together.
Why would they write incomprehensibly? It's not because they don't want to be understood; these are peer-reviewed journals we're talking about here, and someone else must read and OK your work. But it's because when they make the fewest assumptions and the most broad argument, their work maximizes power and usability and robustness.
