tips on writing modern idiomatic code

295 views
Skip to first unread message

Sergey Didenko

unread,
Jun 21, 2016, 8:46:22 AM6/21/16
to clo...@googlegroups.com
Hi,

What would you advise for writing-rewriting your Clojure code in MODERN idiomatic way?

Using Kibit?

Pasting your code samples on some review site?

Asking help in IRC channel?

Asking here?

Reading some noticeable open source projects?

Reading some new Clojure book?

I ask about the latest Clojure specifically.

I have not given very focused attention to Clojure since version 1.4 and would like to grasp the WHOLE PICTURE of "good" modern Clojure. Currently it feels like a lot of latest knowledge is located in different pieces all over the internet. Or may be I just don't know where to look.


Leon Grapenthin

unread,
Jun 21, 2016, 10:20:05 AM6/21/16
to Clojure

Sean Corfield

unread,
Jun 21, 2016, 2:02:29 PM6/21/16
to Clojure Mailing List
On 6/21/16, 5:46 AM, "Sergey Didenko" <clo...@googlegroups.com on behalf of sergey....@gmail.com> wrote:
> What would you advise for writing-rewriting your Clojure code in MODERN idiomatic way?

It’s a good question and I get the impression that a) it’s constantly evolving as we all gain more experience building large systems with Clojure(Script) and b) different people / companies have inherently different approaches to what is “modern and idiomatic”.

Leon suggested the clojure-style-guide and that’s good for the basics but I don’t think it really goes deep enough into idiom “in the large” (and I doubt it can, because of the two points above). It’s the basis for our in-house coding guidelines, which add company-specific guidelines too, as they pertain to our code base.

I’d also recommend Zach Tellman’s work-in-progress Elements of Clojure:

http://elementsofclojure.com

I think this is an interesting blog post to read, for idiom:

https://rasterize.io/blog/clojure-the-good-parts.html

I’m not sure I agree with all the details of it but mostly it seems like reasonable advice (and we opened a number of tickets at work to review where we’re out of line with it).

> Using Kibit?

Haven’t used it so I can’t comment. We used Eastwood for a while but found too many “false positives” so it slowly fell out of favor at work.

> Pasting your code samples on some review site?

Maybe, but I personally don’t know of good sites for that. I’ll be interested to hear recommendations.

> Asking help in IRC channel?

Or the clojurians.net Slack channel. That has a great #beginners channel with lots of helpful people, and the main #clojure channel also fields a lot of style / review questions for more advanced stuff.

> Asking here?

Folks sometimes post links to code and ask for feedback so that seems like a good avenue too.

> Reading some noticeable open source projects?

This question comes up fairly regularly but I don’t recall there being much consensus on what constitutes good, idiomatic, modern Clojure in OSS projects – I think that’s partly because many OSS projects are libraries that have to either do something gnarly (and non-idiomatic) or have to pander to performance concerns (in non-idiomatic ways)?

> Reading some new Clojure book?

Read all of them! ☺ Books take a while to write and usually by the time they come out, Clojure has moved on a bit. I’ve tended to stick with recommending Clojure Programming (Emerick, Carper, Grand; O’Reilly) even tho’ it’s now four years old and was written for Clojure 1.3 (but tested against 1.4) but there are certainly several more modern books that target more recent versions of Clojure.

As an example of the problems that authors face, Clojure in Action (Ed 1) was hampered by covering Clojure 1.2 yet wasn’t released until after Clojure 1.3 was released (with massive changes in contrib that made it hard to follow all the examples in the book). Ed 2 appeared late last year and targets Clojure 1.6 but we’re already in the alpha builds of Clojure 1.9. The authors discussed the book in the Java Ranch forums and were sad that they hadn’t been able to include transducers from Clojure 1.7 (which also brought us reader conditionals).

Last year also saw the release of Clojure Applied and Living Clojure. Of the former, the authors say:

“While we believe the style and forms we describe are in wide use, it’s difficult to say what is and isn’t idiomatic, especially among members of an innovative and opinionated community.”

I think that really sums up the issue.

Since 1.4, we’ve had:

• Reducers
• Reader literal enhancements
• New threading macros
• EDN reader
• Destructuring with namespaced keys
• “some” functions
• Transducers
• Reader conditionals
• More string functions
• Socket server/REPL
• clojure.spec and a raft of new predicate functions

…as well as many other minor enhancements along the way. Some of those have _definitely_ changed the way we write code at World Singles to varying degrees (primarily the threading macros, EDN reader, “some” functions, and string functions).

We have written one transducer – but haven’t yet adopted the built-in transducers wholesale.

We’re reviewing clojure.spec (after having invested quite a bit of time in the past working with both Schema and core.typed).

We recently switched from Leiningen to Boot (which had a massive impact on our build/test processes and how we think about tooling).

We also recently adopted Stuart Sierra’s Component library and are working toward his “Reloaded” workflow (legacy global state prevents full adoption – and we’re working aggressively to eliminate this).

We’re just starting back down the path of a serious investigation of core.async (after using it a year or two back for a proof of concept Clojure(Script) application with Reagent and Sente).

I think the big shifts for us, in terms of idiom, over the next year will be:

• More transducer usage, maybe more reducer usage too (parallel fold)
• Namespaced keywords and clojure.spec usage
• Wholesale adoption of core.async

I hope that’s helpful?

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood





Rangel Spasov

unread,
Jun 22, 2016, 6:30:03 PM6/22/16
to Clojure
Great book resources, IMO:

Clojure Programming (Emerick, Carper, Grand; O’Reilly) - book
Clojure Applied (Alex Miller, Ben Vandgrift) - book

If you understand the majority of what those books say and why, read Zach's Elements of Clojure.

General recommendations:
- understand why transducers, use them where appropriate (Rich's talks are good intros to 'why')
- understand why core.async, CSP in general, use it where appropriate (Rich's talks again)
- understand clojure.spec

In terms of code readability and documentation, I would aspire to one day write as much documentation as Aphyr does here:


I think there isn't a single idiomatic way to write Clojure. If there's a "way", it's probably the "Out of the tar pit paper" http://shaffner.us/cs/papers/tarpit.pdf 

My general code quality test is can you explain/draw your code decisions to a stranger on a piece of paper in 60 seconds. 

Cheers,
Rangel

Sergey Didenko

unread,
Jun 23, 2016, 3:51:58 AM6/23/16
to clo...@googlegroups.com
Thank you for your answers!

That would be interesting to read.

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply all
Reply to author
Forward
0 new messages