PurelyFunctional.tv Newsletter 212: Clojure's simple bravery
Sign up for weekly Clojure tips, software design, and a Clojure coding challenge.
Issue 212 - February 13, 2017
And I also just calculated that I have over 37 hours of video on the site right now. The number surprised me. I didn't think I had so much. The JVM course is by far the longest. It's over five hours of video.
Please enjoy the issue.
PS Want to get this in your email? Subscribe!
Justin Gehtland of Cognitect interprets the data from the multiple choice questions in the survey. Clojure adoption is on the rise!
Daniel Compton has read through all of the free text responses, like he did last year, and gives his interpretation.
I've been enjoying Daniel Compton's Clojure-oriented newsletter quite a lot. Yes, he's the competition, but there's plenty of room right now for two Clojure newsletters.
Mike Fikes' Planck has been rewritten in C (instead of Objective C) and now is available on more platforms, including Linux. Planck is a ClojureScript REPL useful for running code and scripting.
Simon Belak gave a talk at Clojure Remote last week. The videos aren't online yet (unless you attended the conference), but he gave a nice interview about it.
Joseph Wilk has created visual representations of many of Clojure's core functions. While I don't think they will help other remember how functions work, I do think Joseph will remember them better having made this guide. I believe in a constructionist model of learning. We learn well by building something we can share with others. You should try to build something similar in the same vein.
I've been reading this book off and on for a few months. I find it full of platitudes and unhelpful productivity buzzwords. But then someone I respect recommended it to me again, so I gave it another shot. Upon re-interpreting the ideas, amidst the dregs, I think there is a valuable lesson in it that does apply to how Clojure is developed.
People have complained about Clojure's error messages for a long time. They're bad in general and sometimes incomprehensible. Errors in macro usage are particularly bad. People also get into trouble with passing generic data structures around. It's often hard to know what data you have. These two problems seem totally separate. Except they're not when code is data. They're two facets of the same problem: being able to declare what data you expect and have a system tell you when the expectation is not met.
clojure.spec is a specific example of a more general principle. Instead of spending lots of effort solving the individual problems that appear in front of us, of dealing with one bug report at a time, we should look for a thing that will make the bugs irrelevant.
From the outside, it may appear that you are lazy. People have real problems that you are not working on. Bug reports go unfixed for months or years. You could solve bad error messages by brute force. Each possible way to mess up the syntax could have a custom message written, with recommendations for what you should do instead. However, brute force is a kind of laziness itself. If you listen for deeper patterns, you can find something that makes all of the bugs disappear at once. The future does not have to be incremental. This is the kind of bravery we see in Clojure development.
Looking back on the history of Lisp, this has been one of the patterns that has recurred again and again. Solve memory management once and for all with garbage collection. Solve syntax once and for all with s-expressions. The book asks us to answer one question: What's the one thing you can do such that by doing it everything else will be easier or unnecessary? What is the answer in your life?