Clojure continues to grow well. In the long run, it will be just fine. But I often worry about the number of jobs available in the short run. Will Clojure hit an inflection point where the number of Clojure jobs make it worth learning just for the economic benefits? Does Clojure need a killer application? What are your thoughts? I'd love to have a discussion about this.
Please hit reply and send me your thoughts.
Sponsor: PurelyFunctional.tv Online Mentoring
Step-by-step online mentoring from Clojure Dabbler to Professional
You're looking into a career change. But you worry that you will face difficulty trying to get your first job in Clojure. PurelyFunctional.tv Online Mentoring is designed to smooth out the learning curve, get you programming as soon as possible, and fit into your busy schedule. The lessons cover a broad range of topics, from beginner skills, to libraries, to deploying production code. You get the skills to succeed with Clojure. Subscribe here.
Reginald Braithwaite gives an excellent talk about what combinators are and why we should use them.
Alex Yakushev explains the different
list?-like predicates (
sequential?, etc.) and offers a nice truth table for different arguments.
CIDER is looking nicer all the time. The install just got easier. And now, it looks like the debugger is getting some new, useful features. Artur Malabarba, who writes a lot about Emacs, talks about those debugger features.
Daniel Higginbotham (author of Clojure for the Brave and True) has created a new site for listing Clojure jobs. Please do check it out. If you'd like to hire Clojure devs, please post your job here while the site is still free.
Bret Young tells the story of REPL exploration of music data.
Metabase explains why they chose Clojure for a rewrite of a Python service. Spoiler alert: it was easy to install and deploy.
Alan Kay and Adele Goldberg wrote this summary of their work on the Dynabook back in 1977. So much awesome stuff was produced in Alan Kay's team back then.
Samir Talwar explores the Smalltalk conditional (which is just a method on booleans) and compares it to Racket. I think he's onto something very profound: the designers of Smalltalk learned quite a lot from Lisp and so had the opportunity to improve on it.
Phil Nash explores the notion of simplicity, nodding to Rich Hickey but going well beyond.