CodeStock 2012

First of all, kudos to Michael Neel and everyone that put on CodeStock.  This was my first time attending CodeStock and to see such a well-run conference is always a pleasure. I know from experience that there’s a lot of work that goes in to making things run that smoothly.

I got to attend a few very interesting sessions.  Mike Falanga’s session on using F# and MongoDB for analysis of large datasets was very interesting.  Daniel Mohl’s session on F# and Web Development was also good—and it was really nice to meet Daniel in person and get a chance to gab with him a bit.  There were a few folks from the Nashville area at the conference and they must have some major-league brain power out that way.

Also Rob Gillen’s talk on how buffer overflow attacks work was both fascinating and a bit scary. I can just imagine how many unpatched vulnerabilities there are running around in all the publicly deployed sites I regularly depend on.

Finally, here’s the slide deck for my F# Shell Scripting Talk.  I’ll edit this post later to share sample code.  I’ve posted the slide deck as a PDF file to maximize the number of people that can see it.

Note: Thanks to Dennis for pointing out to me that I got the name of the presenter for the buffer overflow attack talk incorrect. 

Why The Defaults Matter

I often think of why I feel that it’s important to have a functional language—not just write code that’s pseudo-functional in an imperative language.  As I think this through, I wanted to record some of my ideas on the subject.

Even the best developers I’ve known are almost always inclined to take the defaults.  I mean if the default string type is ASCII then you’re very unlikely to see Unicode strings in the app unless someone specifies that this is needed.  This is not laziness; it’s simply that these developers have other issues to concentrate upon.

Why is this important?  Simply this: I’ve come to realize that default mutability is an accidental complexity–in the sense that Fred Brooks used that term in his “No Silver Bullet” essay.  Don’t misunderstand what I’m saying–mutability is necessary and appropriate.  But having all values in software mutable by default is an invitation to lots of unexpected side effects.  And this is why I really believe that functional languages will continue to gain in use.  Functional languages are immutable by default.  Impure functional languages (OCaml, F#, Clojure, and Scala among others) do allow a programmer to specify mutable quantities where it’s appropriate due to performance considerations but they default to quantities being immutable–and that’s why they’re important.  If things default to being immutable, developers will learn to work with immutable quantities and become accustomed to them in the same way they’re now accustomed to thinking in Objects.  People seem to forget that 30 years ago, OO was as much an academic discipline as Functional is now.

Every developer knows they should mark quantities as constant (or final or readonly or whichever keyword expresses immutability) but most do this only as an afterthought and they do it incompletely.  Default immutability could eliminate a whole class of side-effect errors and therefore reduce errors in our code by a large fraction of all errors present. The issue is not the question of does “const correctness” (for lack of a better way of phrasing it) make software less error-prone; the issue is getting developers who are always under impossible deadlines to use constants by default.  Languages that default to constant, immutable quantities are a large step in that direction.  This is why functional programming is important and this is why you’re going to inevitably see more and more developers gravitating toward these functional languages.

Why I Don’t Care If You Think Functional Programming Matters

Jon Harrop, who is a strong advocate for functional programming, recently tweeted some links to questions on programmers.stackexchange.com (here and here) I’m generalizing a bit (not much though) but the basic substance of these questions amounted to “Why Should I Learn Functional Programming?”  

It’s a fair question.  I’ve been a developer and around developers long enough that I’ve long ago learned that most of them won’t take anything on faith—and justifiably so.  I’ve even coined a term—“Missouri Developers.”  For those who wonder what that means, the state of Missouri in the United States has the nickname “The ‘Show Me’ State”.  A lot of developers, when they feel comfortable with the subject they’re discussing are very much in the “Show Me” crowd; skeptics in the most pejorative sense of that word.

But, honestly, I’m sort of tired of hearing the question because I hear a common subtext; an unstated question.  “If I learn functional programming will I be able to work on cool new technology?”  I’ve been developing software long enough to remember when there was serious debate as to whether or not Java would take off.  I remember reading articles about how foolish Sun was to try to build a VM because Microsoft had so much expertise in building VM’s (VB6 anyone)? The same kind of question came up about Java—”Why Should I Learn Java?”—with the same subtext.  And before that I can recall reading debates in software development magazines about whether or not it was worthwhile to learn C++.

Some people who learned Java back in the early 90’s got to work on some cool tech—some did not. 

The fact of the matter is that any cutting edge technology has certain risks built into learning it.  If you’re trying to decide whether or not you should learn a new technology based on whether or not you might be able to land a cool job if you learn it—do us both a favor and find another career.  The developers I’ve known over the years who I have the deepest respect for are those developers who love to learn.  They don’t need anyone to tell them to learn new technologies and new ideas; they do so because they love to do it.  And they don’t worry about what kind of cool new jobs might open up to them if they learn a new technology—they learn because they want to know. 

I’ve been playing with functional for about two years now.  I can empathize with those developers with years of experience in C and Pascal about the time of the early 90’s—seeing the large shift from procedural to OO had to have been hard to adjust to.  But I can also see some real strides forward that you can get by adopting functional programming—just as the adoption of OO brought about a lot of strides forward in development. 

Now I know some of you will read this and think to yourselves—wow, he drank the whole pitcher of the kool-aid.  I don’t think functional programming is a panacea.  On the other hand I never thought of OO as a panacea either but it seems that many of the Java and C# programmers in the world cannot conceive of software without objects.  And I don’t think of improving software engineering as a zero-sum game either; that is, I don’t believe that if we improve one area of software engineering that another area must necessarily suffer.  Default mutability in a language is an accidental complexity.  Mutability has its place but it should not be the default.

Either way, if you want to learn and expand your mind, then I’ll be glad to share anything I’ve learned with you.  I love talking tech with others who are intellectually curious.  Otherwise, if you aren’t willing to play with functional until you’re convinced there will be plentiful jobs in cool technologies for those who learn functional—then don’t play with functional; I don’t care.  But stop asking me why you should take the time to learn functional.  If you don’t possess any intellectual curiosity feel free to sit on the sidelines and watch the revolution.