PurelyFunctional.tv Newsletter 225: Spec, Deep Learning, New Orleans
Issue 225 - May 15, 2017
Hi Clojurists,
I was reminded this week by Arne Brasseur that business is hard. There are occasional runaway successes, but in general, building a business is a longterm project. Arne's story parallels my own. And, like Arne, I still don't make a fulltime income from my videos.
There are many reasons for the lack of a runaway success, but the main one is the size of the Clojure community. That may seem obvious, but it wasn't to me. Like Arne, I counted on 200 paying members "so I could quit my job". When you look at which language communities have successful subscription offerings, you see PHP, JavaScript, and Ruby bringing in lots of money. I've heard of one PHP tutorial service making $1 million per year selling screencasts. They probably have more subscribers than there are paid Clojure programmers (by my informal reckoning).
Which leads to some questions: is there anything inhibiting Clojure growth? How fast is it growing? What might make it grow faster? Where is the growth coming from (new programmers or programmers from particular languages)?
But I'd like to bring up a different issue: do people have a burning
need for training in the Clojure world? Let me put it this way: not only
are PHP and JavaScript very popular languages. They are also languages
with obvious and well-understood flaws. Most of a developer's attention
and knowledge is dedicated to working around them. There is a market for
lessons in "style" (another word for avoiding flaws). For example, the
book Refactoring to
Collections is
about teaching map, filter, and reduce to PHP programmers who are
tired of imperative loops. The pain is real (buggy loops), the value is
clear (faster development and reduced maintenance cost), and there are
m
any customers are willing to pay (freelance web developers trying to
pay the bills).
Do we have that in Clojure? Do we have a real pain? I'm betting that a pain is the learning curve. People also complain about the error messages. Is the value clear? I'm not so sure. People want to learn, but will they pay to learn more quickly? And as much as people complain about the error messages, how much would they pay to make them better? And are there customers? That's similar to the growth question from before.
I ask these questions all the time looking for opportunities. And you can do this too: What do you think are the problems with Clojure? They don't have to be with the language itself, but could be anywhere in the Clojure experience. Then ask, is the value clear?
Hit reply and let me know what you came up with. I'm looking forward to your answers.
Please enjoy the issue.
Rock on!
PS Want to get this in your email? Subscribe!
Dear Paddy Cosgrave Facebook
You'll need some context before you read this letter. Collision Conference was recently held here in New Orleans. It's a big event compared to the size of the tech industry here in New Orleans. And they do it between the two Jazz Fest weekends. It's easy to see why they do this---tack a weekend onto your business trip and you get to see Jazz Fest. But it's also a hard time in the city---the hotels are double or triple the price, the city is full, and transportation is difficult. This was the second year it was here, and apparently it could have been the last.
I share this with you because I love New Orleans. I was born here and I grew up here, and I choose to live here. Robert Scoble, in his plea to keep the conference in New Orleans, shows that he really gets what makes New Orleans special. We're lucky to have him on our side.
BTW, a short time after this letter made the rounds on Facebook, tickets went on sale for Collision 2018, in New Orleans.
PS I'm still gungho about a Clojure conference in New Orleans. I got a lot of positive responses (thanks, everybody) and there are other people here excited about the idea. But I don't think it will happen this year. You have to plan these things far in advance to book venues and such.
James Reeves on Defn Podcast
James Reeves is better known as @weavejester. He's the creator of Compojure and Hiccup and the maintainer of Ring. His code is quite consistently styled and of high quality. This interview with him was really great. Kudos to the folks behind defn for doing a great job on this.
How to push past the trolls and get the help you need on Stack Overflow
Billed as a guide for coding newbies, this article gives the best advice for asking questions on Stack Overflow I have seen. Kim Crayton reveals that she is a gifted teacher and can work both sides (expert and newbie) of the developer community.
Clojure Spec
Rich Hickey gave a talk at LispNYC about clojure.spec. This one shows the "why" of the library from another angle: the experienced Lisp crowd's perspective. I never tire of Hickey talks and this one is no different.
How to be a compiler --- make a compiler with JavaScript
Mariko Kosaka breaks down the traditional steps of compilation in a functional style of JavaScript.
-------------------------------------------------------------------
Intro to Deep Learning w/ Clojure
Julio Barros shares his slides from a talk he gave on Deep Learning in Clojure. There's an introduction to Deep Learning and a bit of Clojure code using Cortex.
Why your programmers just want to code
Boy did my friend Marcus Blankenship really nail this one. Have you ever felt like you're thinking less about why you're coding and more about how you're coding? From the article:
[The] concern that "We aren't building the right thing" will be replaced with "We aren't building the thing right."
This article explains, from a manager's perspective, how our culture can slowly lead us down to the path of focusing only on our work, and not how work impacts the business and others.
clojure.spec: a lisp-flavoured type system
Simon Belak presents clojure.spec to a functional programming audience. Spec has some deep ideas in it, so we need a lot of these "introductions". And Belak adds a lot of perspective to it, including how spec will impact live coding and how we code in the near future.
Reuse
Jessica Kerr brings up an important issue: reusing code has a cost. Pulling out common code into a library introduces a shared dependency between two systems. Before, they could evolve independently. But once they have a common dependency, they will be coupled together.