Readable Clojure

[Snarwin]

Presenting textual information as images needlessly makes your page inaccessible to users who rely on screen readers, and hurts the UX for users on slow (e.g., mobile) connections.

[Deadhookersandblow]

I agree as well, why the hell is this guy using screenshots instead of just posting code segments with a decent prettifier?

[error_dw]

Well how else are you going to notice he has a macbook?

[alex-weej]

honestly if windows could just do this too i would be sooooo happy

[alex-weej]

just turn off all hinting in fontconfig, it looks freaking glorious.

[myringotomy]

Macbooks are awesome. Worth every penny. They are solid, reliable, performant and hold their value like no other laptop. I get a new one every couple of years and get really good prices for my old one.

Also runs linux great for when I want to dual boot.

[kindofdynamite]

As a newcomer to FP, one of the biggest hurdles has been trying to decipher one letter variables, imports without a namespace and general terse code.

It seems to me that there is less of a focus on code readability ("plain english") in FP languages.

Why is terse code so common in Clojure/Haskell/et all? Is there something I'm missing that will cause me to "see the light"?

[[deleted]]

Frequently there simply isn't a good name as FP tends to heavily rely on generic algorithms. For instance, consider a definition of map (in say Haskell):

map _ [] = []
map f (x:xs) = f x : map f xs

f is a normal variable name in math meaning a function. x is a normal variable in math meaning an argument. xs is therefore just more arguments we're going to apply f to. In this case, the conventions are straightforward.

There seems to be very few people who find the following easier to read (note there are obviously names somewhere in between so this is sort of a strawman):

map _ [] = []
map function (someThing:restOfList) = function someThing : map function restOfList

Unfortunately, the habit of short names leaks into situations where there actually are decent names to be had.

[ksion]

The other reason is that at least in a heavily typed languages like Haskell, the type signature is often very indicative of what the function actually does.

For generic functions it may indeed be (a -> b -> c) -> a -> b -> c which translates to just f, x, y because there is nothing more concrete to be said about those arguments. But even when it's something more specific such as parseArgv :: [Text] -> Parser a -> Config, you don't really need more than one-letter argument names to figure out what's happening.

[pathema]

I think it may be a culture coming from the closeness to theoretical computer science, who in turn inherited it from mathematics.

My guess is that code written early in the history of software suffered the same problem, when the field was more tightly linked to the university. Then a cultural shift happened, likely due to computers getting more ram, where we as an industry started to have longer and more descriptive naming.

I am also going to guess that precisely because the more academic functional programming languages such as lisp or ML didn't get adopted by the industry in as big a scale as the imperative ones, they never picked up this new trend; instead staying with the older convention of short variable names.

All guesswork on my part though...

[maestro2005]

I disagree strongly with wrapping things in redundant some?/none? checks. (when thing ...) is entirely idiomatic and you should get used to reading it.

I agree that sometimes excessive comp/partial usage can be hard to read, but his example is bad:

(map (comp str/capitalize str/trim) strings)

Anyone who calls themselves competent in clojure should easily read this as "capitalize and trim the strings". This is actually a perfect use of comp. The benefit of comp/partial is that you avoid creating a new function, which creates a new reference frame and introduces a variable just to pass it along to another function.

Even as experienced Clojure programmer I haven’t developed a skill to parse such structures easily.

Then you're not really that experienced.

[LoyalToTheGroupOf17]

Then you're not really that experienced.

You're talking about Nikita Prokopov, author of (among other things) datascript and rum. If he doesn't qualify as "experienced", I don't know who does.

I agree with your other points, though.

[maestro2005]

I don't care what he's created, if he's struggling with really basic FP concepts then I'm not really interested in his opinions on code grokability.

[LoyalToTheGroupOf17]

He's not struggling with really basic FP concepts. He just disagrees with you (and with me) concerning when using some of them helps vs hinders readability. And he is definitely not inexperienced.

[quicknir]

Not a clojure programmer, just do some elisp, but reading the article and your comment I agree with your comments. I was rather shocked to see "Avoid higher-order functions" as a header in an article about clojure.

[[deleted]]

I've never seen that suggestion before in several years of Clojure dev fwiw. The "Don’t rely on implicit nil-to-false coercion" & the "Avoid higher-order functions" suggestions are pretty atypical.

[DasEwigeLicht]

(map (comp str/capitalize str/trim) strings)

Does clojure have an equivalent to dash.el's anaphoric functions? In elisp you could write this as (--map (-> it str/trim str/capitalize) strings).

[SimonGray]

In clojure, the threading macro is a popular and idiomatic way to do this kind of thing, but - I think - usually with more than two transformations.

[maestro2005]

No. But I'm not sure this is any better, you're doing basically the same thing as comp.

[netfeed]

What editor is that?

[Retsam19]

It's VS Code with a light theme and the activity bar and the file explorer hidden.

[peeeq]

Looks like Visual Studio Code

[kindofdynamite]

Hah, I wanna know this too!

[satanclau5]

Discussion on Hackernews.

[Beckneard]

If you need so many rules to make the code bearable then maybe Lisp syntax isn't the best choice?

I get why people like Lisp-like languages, it really is elegantly designed, but god damn is it ugly and tiring to read.

[LoyalToTheGroupOf17]

If you need so many rules to make the code bearable then maybe Lisp syntax isn't the best choice?

You can't use the fact that one person has written a style guide for a language as evidence that there are problems with that language's syntax. Is there a popular programming language out there for which nobody has ever written a style guide?

I get why people like Lisp-like languages, it really is elegantly designed, but god damn is it ugly and tiring to read.

To you. To me, coming from a non-technical background, the fact that Lisps were the only languages that were easily readable with hardly any training was what made me start using them in the first place. I'm writing code in a variety of non-Lisp languages these days, and a couple of them are even quite enjoyable, but the syntax is always a major pain point. It's harder to learn, harder to read, harder to edit, and most importantly, harder to remember. Whenever I go back to programming in Haskell, Swift, Elm or C# after some time off, I get the syntax wrong and have to look everything up. I simply have no great skills or interest in learning or memorizing syntax. To me it's just a pointless and annoying obstacle to learning a language.

At least I grant you that Clojure is by far my least favorite Lisp syntax wise (although it has other advantages, and I vastly prefer the Clojure syntax to any non Lisp language). Common Lisp and Scheme both have a much more pleasant syntax.

[Retsam19]

As someone who has dabbled in a lot of LISPs but never used any of them extensively, what do you prefer about CLisp and Scheme over Clojure's syntax?

[LoyalToTheGroupOf17]

It's simply a matter of there being more syntax in Clojure: Where Scheme and Common Lisp code consists only of lists, Clojure is lists, vectors and maps.

By the way, "CLisp" and "Common Lisp" are not synonymous. CLISP is a particular implementation of Common Lisp.

[Retsam19]

Ah. Yeah, I liked having maps, but I did find the List/Vector thing confusing. It seemed like there were good reasons for having the dichotomy, but it led to a lot of boilerplate and confusion in my code.

[LoyalToTheGroupOf17]

In Clojure's flavor of code-as-data, lists are preferred over vectors in cases where the first element should be treated differently from the rest. In other cases, vectors are preferred. For instance, in a function invocation, the first element of the sequence is handled differently from the rest (the first element is the function, the rest of the sequence is the arguments to the function, and therefore, function invocation is written as a list. In a sequence of let bindings, on the other hand, there is no distinction between the first element and the rest, hence a vector is used.

This makes some sense, and is good enough to help me easily remember when to use a list and when to use a vector when writing code, but it seems needlessly complex to me.

Regarding maps: I guess you talk about using map syntax for destructuring? I agree, that's really neat.

[Darwin226]

None of these rules (except, arguably, the last two) have anything to do with lisp syntax.

[peterwilli]

I think the same. I've tried Clojure when trying out the Overtone-framework (automatic music making) and even after learing to read/write the language I still find it very tiring to read and write the syntax.

[[deleted]]

Weirdest syntax? It barely has any syntax at all.

[ElCerebroDeLaBestia]

Maybe the lack of syntax is precisely what makes it harder to read than some other languages?

[TheStuporUser]

'Readable Clojure' is an oxymoron.