• arachnid studios.

• services.

• blog.

• contact.

archives

• Aug 2019 (1)
• Jul 2018 (1)
• May 2017 (1)
• Oct 2015 (1)
• Jul 2015 (1)
• Sep 2013 (1)
• Feb 2013 (1)

tags

• clojure (4)
• linux (2)
• steamos (1)
• jvm (1)
• hiccup (1)
• neanderthal (1)
• gaming (1)
• mongodb (1)
• rebl (1)
• rm16 (1)
• aemo (1)
• zipper (1)
• mac (1)

• rss
• rss clojure

clojure 7 years in

This is my opinionated take on the current state of Clojure in 2018. To help appreciate the angle I'm coming from I'm a Generic Enterprise Developer. I work mainly in the Energy Industry with RHEL, Java, Spring, Oracle etc (I actually like all those technologies, shameful I know). I've never had the chance to write Clojure for production code but there is the odd covert offering that I made to the Lisp Gods in my prior employer's repo. To complete the stereotype, I'm white, middle-aged, have 3 kids, like Star Wars and Metal.

Right so I'm 7 years in and it doesn't really seem I've really achieved 7 years worth of Lisp enlightenment. I have purchased a lot of books, read a lot of blogs, dabbled with the functional competition and even helped to fund a few kickstarters. Yet, sometimes when I'm reading Clojure libraries I still feel like I could make more sense out of cat'ing a png.

Lets cat a png to solidify the imagery...

And compare that to a like sized snippet from clojure.core...

So Clojure wins but geez they both have a lot of symbols. Anyway, I'm not here to bash the language, there are good bits and bad bits. Let's start with some good.

the community - cognitect

The community is easily the best I've encountered in my tech career. From the top down communications are civil and helpful and they don't seem interested in bashing other techs. I think Cognitech do a great job setting the tone for the community as the stewards of the language. Alex Miller especially rates a mention, he seems to be everywhere in the community and appears to have a very level-headed approach.

As a language designer Rich Hickey is a great Tech Jesus. The way he articulates his ideas in his conference talks is an annual highlight. He has an amazing command of the English language. More importantly than that though, he seems to like modern metal. In two of the episodes of the Cognicast I heard he asked for Mars Volta and Baroness. Two bands I actually like. No Bach or Mozart in Clojure thanks, we'll take our music with some nuts.

In 2018 it does seem that some of the community has become somewhat disenfranchised with the direction of the language and community growth looks to have stagnated. From reading the Planet Clojure feed and listening to Clojure podcasts it seems that many people held out hope that Spec might improve the state of Clojure error messages and lead to a new wave of innovation in the community. So far that hasn't been the case and as of Clojure 1.9 the error messages aren't really much better than they were pre-Spec, they may actually be worse.

That being said the Spec library seems to hold a lot of promise and it is a good base from which to build. I like the idea of having reusable snippets of validation that can be composed together. As a code base grows I could see the same Spec being used at many layers of the application, from cljs all the way down to the DAO. Eric Normand sent out a recent post about the state of Clojure error messages and where Spec might fit. He describes Clojure error messages as 'non-existent' or 'accidental' and that Clojure by default is assuming the happy path instead of asserting that is, in fact, the case. It is worth reading the post, it is in the links section below.

In all Cognitect have done some great work, they are a commercial entity, and need to make money so can't spend all their time on the language or tools for the community. They have produced Clojure, ClojureScript and Datomic. All have been successful even if they still feel a bit rough around the edges (Clojure itself only got a command line launcher as part of the 1.9 release and Windows still isn't supported). Cognitect is trying to improve things as is evidenced by Spec, the new deps format and the command line launchers. Things may not be perfect but as Stroustrup said:

links

the community - outside of cognitect

Some of the community has started to try to take further ownership of the direction of the language. I think we were all guilty there for a while of waiting in frustration for the next big thing to roll out of Cognitect and fix all the rough edges of the language. That hasn't happened, though as mentioned above they are making attempts to smooth things out. The defn podcast has been a good rallying point for this alternative voice in the community. It took a few episodes to find its legs and it is still a bit sweary at times but overall it was really good in-depth content. The episode length of over an hour allows for deep discussions and they are getting the main players in the open-source community involved. They are not in direct competition with Cognitect but they did provide a stage for some alternate views in the Clojure world when I think the community really needed it.

A number of the recent guests on the podcast have had interesting insights on the state of the language as it is now. In particular, Zach Tellman, Peter Taoussanis and Malcolm Sparks were articulate speakers who have given the community some great open source projects. I recommend listening to their episodes if you get the chance.

Zach Tellman might be Rich Hickey 2. He sounds like he thinks deeply about problems and has a clear, concise way of conveying his ideas. His Leanpub book 'Elements of Clojure' is a great attempt at an Effective style book for the Clojure world.

I don't think we're going to see the community grow much more but I do think it will start to mature around a few libraries that will hopefully make the overall experience of writing code that much easier. Following the discussions over on Clojureverse it sounds like the community has a real appetite to address Clojure's error messages and documentation problems. Fingers crossed.

Overall all the community has maintained that diverse feel from its early days but now with a slightly older, practical user base. There has certainly been more grumbling in the blogosphere over the last 18 months but the community is too rooted in a pragmatic practicality to fracture over a few flameout posts.

links

cutting code

The language is both liberating and frustrating at the same time. I find it quite easy to write, working inside out with functions is natural. You start with a small snippet of code, then wrap the result to perform your next computation. Unfortunately, this style of coding is very hard to read back later. It might be closer to mathematics but in the Western world, our brains are trained to read from left to right from a very young age. So we end up with let blocks binding a sequence of results to operate on or we use the threading macros to transform collections in a top-down fashion. This works well with me and can end up very readable with well-named functions and variables. The language leads me to a pipeline of small functions for solving most problems.

When I first got into Clojure I was expecting to write mini business focused DSLs, such was the promise of LISP, buuuttt that hasn't been the case. The community is much more about data first, sometimes to a fault. People end up writing interpreters for vectors and sets with keywords encoding some meaning where standard S-expressions would have done just fine. I was quite pleased when I heard Rich Hickey talking about Spec and that it should be constructed with a language as opposed to being fully data descriptive as its primary audience was programmers. The Racket language still has a focus on DSLs and user-written macros, perhaps I should explore this further.

Munging data between libraries is easy when the data structures on the edges are all Maps/Lists etc. The compiler doesn't get in the way and the transformation functions in Clojure are very rich. However, working out what format to munge from and to can be more difficult. Usually, lib doco is lacking so it boils down to firing up a REPL session, looking at what is getting output from your source lib and then poke the destination API a few times until something works. Honestly, this doesn't feel like the most productive way to code. It is exploratory and immersive but well-designed type hierarchies do provide a lot of documentation and guidance out of the box. Its a trade off but I'd like a bit more formalism in some of the library APIs. Again Spec may win here.

One of the areas this explorative style of programming really works is data science and analytics. I thought Clojure would end up shining here and one of the first well-known libraries on the scene was Incanter, a tool for data analysis. It is still alive today but there hasn't been much new in the space since then, nothing that has really made the community stand up and say wow. I do think something will come up here, Clojure's immutability, great first class data structures and live environments are too good a combo to pass up for analytics. I have run numpy with Jupyter notebooks but I found the expressions in Clojure a much more natural fit for set orientated analysis.

I value readability in a language but unfortunately, I find library code in Clojure very hard to grok. The statements are often dense and without types to guide the intended shape of data between functions it can be very hard to replicate the mental model the author had in mind when they wrote it.

All this said it is an interesting language from which I have picked up many fresh ideas. Not since University, where I got my degree in Starcraft (Minor Comp Sci), have I encountered so many new and useful concepts. Even if I was to move on from the language I'm much richer for having found it.

favourite books

The Clojure community loves writing books. We must nearly have the highest published author count per capita of any programming community. Most of the books I've read have been good but none that were really amazing. Here are the top 3 that I've read since starting Clojure

This was a missing 201 style book for Clojure, it dealt with domain modeling in Clojure and how to structure an application through use of channels. It referenced some contemporary libraries so those chapters may age quickly but overall it is the best Clojure book out there. Alex Millar's clear style again shines through.

This was the original book that I purchased way back when the initial hype began. It was a dense book at the time and would still be the most weighty Clojure book available today. I think its best sections are those that deal with Java interop and Performance considerations, I will still go back and refer to those now. They're the most thorough text available on those subjects.

I'd had mixed results with Packt published books in the past but this one was a real winner. It acted as a great introduction to reactive programming and core async. The ideas were well presented and the author had a very clear writing style. Some of the libraries referenced in the text haven't been maintained but overall it's still well worth a look for the core async intro alone.

favourite libraries

Clojure is very focused on small libs doing a job. The community could probably benefit from the odd opinionated framework but not here, not today, not on this list.

Does one thing and does it well, generates HTML from Clojure data structures. This has been the simplest and most powerful HTML templating experience that I've encountered in any language.

I'm a big fan of SQL and relational databases, HugSQL puts SQL front and center. You write your SQL statements in .sql files. Annotate them with a couple of comments and then bam you have a DAO operating on plain old Clojure maps.

Compojure is a simple web request routing library. It was the first one I used in Clojure and in conjunction with Hiccup its dead easy to knock out a server generated webapp.

Copyright Arachnid Studios 2024