On 6/21/16, 5:46 AM, "Sergey Didenko" <clojure@googlegroups.com on behalf of sergey.dide...@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 -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
