Clojure Survey

Way back in 2010, Chas Emerick had the excellent idea to take a survey of Clojure developers and then keep doing it every year. In 2014, we took over doing and reporting the survey, but kept many of the same questions, giving us some really great longitudinal data. This week we opened the 2019 edition of the survey and we will keep it open until January 22nd. If you haven’t completed it yet, we’d love to have your input - it takes about 5 minutes. After the survey closes we’ll do some light analysis and release all of the data. If you could post this to places where people may not have seen it, like local meetup mailing lists or internal chat rooms, that would be a huge help.

spec

I’ve spent the vast majority of the week working on the next rev of spec. None of this is publicly visible yet, but optimistically I’ll get it pushed up next week. I made a big push on the first pass of this back in November. That first pass was targeted at splitting the spec “op” macros (s/coll-of, s/keys, etc) into a lower function layer, which is the first step towards making specs more programmable and data-oriented.

In “spec 1”, these op macros expanded to an invocation function that took a mixture of forms and resolved forms. These internal construction functions needed to be public in the namespace to be targetable by the macroexpansion. In spec 2, these macros do nothing more than fully-qualify (explicate in the code) the form and expand to an invocation to spec*, which takes only forms. spec* is a function that converts from forms (data) by handling some special cases (like keywords, symbols, and sets) and routes the construction through a multimethod, create-spec, keyed by the spec op name. Sticking to only forms means we have a straightforward functional API (spec*) that can be called directly, makes the op space extensible via the multimethod, and allows us to hide the implementations more. So that was work done last November.

Back then I started on refactoring the code into multiple namespaces to better clarify the public API, the spec implementor’s SPI, and the parts that are the built-in impl. In continuing my work on that we’ve been further wrestling with a number of fundamental issues in the implementation. In particular, there has long been a split between “specs” and “regex ops” to allow for regex ops to “combine” with other regex ops in describing a single sequential context. We’ve put together a plan to greatly simplify how all that’s done so that regex ops are specs, which reduces a lot of extra work in needing to “specize” things that could be either. The one special case we’ve handled in the past is embedding a nested regex collection with s/spec. s/spec is going to be removed as there’s really no need for it anymore but we will add a new s/nest op that has the same effect, specifically for this use case (take a regex op and remove it’s ability to join with adjacent regex ops).

We’ve also spent a lot of time working through the semantics of the op “language”, particularly around symbols and functions. Because we are moving to this data-oriented focus, there are a few places in the spec API that will need to be called a little different. I’ll defer discussing the details till we have a working thing there.

This work is messy - we’ve done a lot of drawing (and re-drawing and re-re-drawing) of diagrams this week as we think through the fine details, then verify assumptions and detect gaps. But the trend is really good - things feel like they are starting to click into place and leave correctly-shaped holes for future plans.

Misc

As the survey results come in, I’ve been reading people’s free-form responses and watching the trends. There are a few clear areas that people see as a priority. Probably the highest is working on spec and implementing some of the ideas Rich talked about in his Conj keynote. And that is indeed where I’m spending almost all of my time right now, so that’s good.

Another item mentioned by many people is getting to a working and released clj for Windows. As I’ve mentioned a bunch of times, I have worked on this starting from a great Powershell port from Konrad Mrożek. I made a lot of updates to that and even got within sight of having it minimally working but have just not had the time since then. At this point, it would probably be better if some community members wanted to pick it up and take it the next step of the way. I would be happy to guide it so we get to something that can stay in sync with the official release cycle but maybe this would let things make progress at least. If you’re interested, ping me on #tools-deps in Clojurians slack, in particular it would be great to have someone moderately well versed in Powershell.

Took care of a few other odds and ends this week like renewing the SSL cert for clojure.org and some minor site edits.

Non Clojure stuff I enjoyed this week…

Twenty years ago this week, I started doing a weekly radio show with one of my best friends, Nick Cowan. It was on our local community radio station KDHX 88.1 FM and ran 4-6 am every Thursday morning. I did it for three years and I was no longer able to do a great job on it every week due to time spent on other things (like my girlfriend, now my wife!). Shockingly, Nick is STILL doing a show every week, 20 years later (there was a brief lapse, but he’s been on most of that time). But for old time’s sake I sat in this week (now 3-5 am!) and we had a great time playing stuff old and new.

Our original show was called It’s Late, named after the Queen song of the same name from News of the World. Still a great song. Here’s a pretty good live version from the Jazz tour. If you haven’t seen the new Queen film, it’s historically inaccurate and in a few places a little silly, and I don’t care at all - it was totally fun. For my money, I want a Brian May biopic. Brian’s one of my all-time favorite guitar players and just as important to the success of Queen as Freddie was.