Exploration Through Example

In the Agile2011 fringe, I’ll be doing a session with that title. Here’s my blurb:

One of the characteristics of Agile is that it favors the reactive over the proactive. For example, you grow the program in response to new feature requests rather than needing to know all the features in advance. Programmers regularly talk of reacting to “code smells” or paying attention to “what the code’s telling us”.

Being appropriately reactive is a skill. You’re not born knowing how to attend to subtle details, or how to react in a graceful, helpful way.

Skills can be taught. All over the world, people are learning the complementary skills of leading and following in tango, an incredibly improvisational and reactive dance. I believe the learning techniques tango instructors use can be adapted to learning other kinds of reaction—like the reactions of pair programmers to each other and to the code.

In the first part of this session, I’ll teach you some simple tango moves. We’ll concentrate both on learning the moves and also on how we’re learning the moves.

In the second part of the session, we’ll break out computers and write programs or tests (or collaborate on some other task of your choice). Will you be able to react more appropriately to your pair? Will you give off better signals? Will consciously practicing the skill of pairing help you be better at it? We’ll see!

Important note: In my experience, most people are more comfortable learning to dance with someone of the opposite sex. I’ve also noticed that there are a lot more male programmers than female programmers. I worry the title will attract only programmers, leading to a big imbalance. So I encourage everyone to encourage women at the conference to attend at least the first half of the session. They’ll get something out of it (beyond an introduction to tango).

Here is a draft blurb for a course I’d like to teach, possibly in Valladolid, Spain, in September. I’d like to see if enough people are interested in it, either there or somewhere else. (There’s a link to a survey after the description.)

Short version

• Target audience: Programmers who know Java, C#, C++, or another object-oriented language. Those who know languages like Ruby, Python, or JavaScript will already know some—but not all!—of the material.

• The goal: To make you a better object-oriented programmer by giving you hands-on experience with the ideas behind functional languages. The course will use Clojure and JavaScript for its examples. You’ll learn enough of Clojure to work through exercises, but this is not a “Learn Clojure” course.

• After the course: I expect you to return to your job programming in Java or Ruby or whatever, not to switch to Clojure. To help put the ideas into practice, you’ll get a copy of Dean Wampler’s Functional Programming for Java Developers.

Syllabus

• Just enough Clojure
• Multimethods as a generalization of methods attached to objects
• Protocols as a different approach to interfaces
• Functions as objects, objects as functions
• Mapping and folding in contrast to iteration
• Functions that create functions
• Laziness and infinite sequences
• Time as a sequence of events
• Generic datatypes with many functions versus many small classes
• Immutable data structures and programs as truth-statements about functions

Longer version

Many, many of the legendary programmers know many programming languages. What they know from one language helps them write better code in another one. But it’s not really the language that matters: adding knowledge of C# to your knowledge of Java doesn’t make you much better. The languages are too similar—they encourage you to look at problems in pretty much the same way. You need to know languages that conceptualize problems and solutions in substantially different ways.

Once upon a time, object-oriented programming was a radical departure from what most programmers knew. So learning it was both hard and mind-expanding. Nowadays, the OO style is the dominant one, so ambitious people need to proactively seek out different styles.

The functional programming style is nicely different from the OO style, but there are many interesting points of comparison between them. This course aims to teach you key elements of the functional style, helping you take them back to your OO language (probably Java or C#).

There’s a bit more, though: although the functional style has been around for many years, it’s recently become trendy, partly because language implementations keep improving, and partly because functional languages are better suited for solving the multicore problem^* than are other languages. Some trends with a lot of excitement behind them wither, but others (like object-oriented programming) succeed immensely. If the functional style becomes commonplace, this course will position you to be on the leading edge of that wave.

There are many functional languages. There are arguments for learning the purest of them (Haskell, probably). But it’s also worthwhile to learn a slightly-less-pure language if there are more jobs available for it or more opportunities to fold it into your existing projects. According that standard, Clojure and Scala—both hosted on the JVM—stand out. This course will be taught mainly in Clojure. Where appropriate, I’ll also illustrate the ideas in JavaScript, a language whose good parts were strongly influenced by the functional style.

While this particular course will concentrate on what you can do in Clojure, it’d be unfair to make you do all the work of translating these ideas into your everyday language. To help you with that, every participant will get a copy of Dean Wampler’s Functional Programming for Java Developers, which shows how functional ideas work in Java.

Your instructor

Brian Marick was first exposed to the functional style in 1983, when the accident of knowing a little bit of Lisp tossed him into the job of technical lead on a project to port Common Lisp to a now-defunct computer architecture. That led him to a reading spree about all things Lisp, the language from which the functional style arguably originated. He’s been a language geek ever since, despite making most of his living as a software process consultant. He’s the author of the popular Midje testing library for Clojure and has written two books (Everyday Scripting with Ruby and Programming Cocoa with Ruby).

For examples of Marick’s teaching style, read his explanations of the Zipper and Enlive libraries or watch his videos on Top-down TDD in Clojure and Monads.

^*The multicore problem is that chip manufacturers have hit the wall making single CPUs faster. The days of steadily increasing clock rates are over. Cache sizes are no longer the bottleneck. The big gains from clever hardware tricks have been gotten. So we programmers are getting more cores instead of faster cores, and we have to figure out how to use multiple cores in a single program. That’s a tough problem.

Enlive is a templating library for Clojure. Instead of the usual substitute-into-delimited-text approach, it works by editing node trees selected by CSS selectors. I’ve written a tutorial for it. Comments welcome.

As novice user of Hiccup, a Clojure HTML-layout format, I wanted to write a form that gathered information about N animals. Each animal had a name, a nickname, etc. I wanted to use Ring’s ring.middleware.nested-params so that I could iterate over new animals.

I had some trouble getting it to work, so perhaps this note will help someone else. Note that this applies to hiccup-0.3.5.

My first attempt was something like this:

This was derived from the description of with-group here. However, this didn’t work. Only the last text-field appears in the HTML page. [Note: I was using Noir to render pages.]

Having written a builder-style renderer like Hiccup before, I thought. “Ah. I must make a vector of the rendered functions”:

That lead to a scary exception:

java.lang.RuntimeException: java.lang.RuntimeException: java.lang.IllegalArgumentException: [:label {:for “animal1-true-name”} “Name: “] is not a valid tag name.

The solution I found was to wrap the sub-form inside another element, in this case a :p:

It’s ironic that I’d do something like that as a matter of course, except that I was exploring the API. Which led me astray.

UPDATE: Chris Granger points out “Hiccup treats any vector as a tag, but any other seq will work. Vectors have semantic meaning, the others don’t.” Instead of wrapping the separate steps in a vector, I should have used a list:

I should have realized that in the beginning (though one could argue that the two uses for a vector are distinguishable so why not make a vector work as well as a list?).

Chris also writes “In my experience the best solution is to wrap the block in (html … ). Then you never worry.” That is: