An interesting Clojure question came up on Quora recently and I decided that my answer to "how do you use clojure.spec" there should probably be a blog post so that folks without a Quora account can still read it. [If you do have a Quora account, feel free to read it there instead and upvote it!]

The original question on Quora was:

Lots of Releases

Over the last week or so I've released minor updates to several of the projects I maintain, so I thought it would be nice to have a summary blog post rather than a scattering of minor announcements.

next.jdbc 1.0.0 and 1.0.1

First off, seancorfield/next.jdbc 1.0.0 was released on June 13th, 2019 (and I announced it on ClojureVerse but did not blog about it), and yesterday I released seancorfield/next.jdbc 1.0.1 which is mostly documentation improvements.

seancorfield/next.jdbc 1.0.0-rc1

next.jdbc -- the "next generation" of clojure.java.jdbc -- is a modern Clojure wrapper for JDBC. The first Release Candidate is now available to test -- containing only accretive and fixative changes from Beta 1. The API should be considered stable enough for production usage.

seancorfield/next.jdbc 1.0.0-beta1

next.jdbc -- the "next generation" of clojure.java.jdbc -- is a modern Clojure wrapper for JDBC. Beta 1 is now available to test -- only accretive and fixative changes will be made from this point on, so the API should be considered stable enough for production usage.

seancorfield/next.jdbc 1.0.0-alpha8

I've talked about this in a few groups -- it's been a long time coming. This is the "next generation" of clojure.java.jdbc -- a modern wrapper for JDBC, that focuses on reduce/transducers, qualified-keywords, and datafy/nav support (so, yes, it requires Clojure 1.10).

Daniel Compton has continued his excellent trend of writing an analysis of the State of Clojure survey comments and one of the comments in his Community section stood out for me:

"I suggest moving off of slack to a more accessible chat system. Losing history is a bad thing. Check out discord or matrix or gitter or mattermark or any other number of tools made for this purpose."

About a month ago, I was praising Chlorine, the new Clojure package for Atom and I've been using it, day-in, day-out, for all my Clojure development. On a Mac, that's straightforward because I start a Socket REPL on the Mac and I run Atom on the Mac so when I connect via Chlorine and issue the Chlorine: Load File command (via Ctrl-, f in my keymap), it sends (load-file "/path/to/file.clj") to the REPL, for the file being edited, and that is evaluated and loads the source from disk and compiles it. On Windows... Well, on Windows there are a few obstacles to this workflow.

The first obstacle (for me) is that clj doesn't run on Windows and that's what I use for everything Clojure on a Mac and on Linux now. There's a PowerShell implementation in progress but Windows has always been a bit of a second-class citizen so it's still a ways off. But Windows has WSL (Windows Subsystem for Linux) so I can and do run (user-mode) Ubuntu on my Windows laptop and I do all of my Clojure work on that...

I've been using the Atom editor for about two years now. I switched from Emacs after Clojure/conj 2016, having seen Jason Gilman's talk about ProtoREPL [video]. It may sound like heresy, but I'd never been happy with Emacs -- not 17.x back when I first started using it, not 18.x, not 19.x when I first stopped using it, nor 24.x onward when I came back to it after learning Clojure a few decades later. I built several configurations from scratch, I tried several "curated" configurations, none of them felt like "home". Emacs just leeched too much of my development time for my tastes. I wanted a simple, modern text editor, that offered a wide variety of "plugins" and supported all the languages I used, with a sane set of defaults. Atom -- with ProtoREPL -- seemed to be exactly what I was looking for!

And for two years, it has been my day-to-day development environment.

Rich Hickey gave a very thought-provoking talk at Clojure/conj 2018 called Maybe Not, where he mused on optionality and how we represent the absence of a value.

His talk covered many things, including how clojure.spec/keys currently complects both structure and optionality (and his thoughts on fixing that in a future version of clojure.spec), but his mention of s/nilable was what triggered an "ah-ha!" moment for me.