Thursday, May 1, 2008

Stop Being an Extremist Programmer!

It can be difficult to be an open-minded programmer. There are usually too many forces pulling you this way and that. I expect that the diligent programmer must occasionally sip the Kool-Aid, if only to quench the thirst. And so goes my recent switch from UNIX to Windows.

Initially I was filled with dread. Could I stand to be called a "Windows Programmer(TM)". Could I stand the humiliation of defeat; switching from the purity of UNIX to the sloppy thinking and marketing hype of Windows. Well, yes actually. And it was quite easy. More than ever I realise that computing is temporal. The world changes so fast and completely that it's difficult to keep up. Especially getting ever-older. Adapting to new environments takes nothing more than a change of perspective.

Extremist Programmers

If I've had one gripe with Extremist Programmers, it's that they seldom produce anything of value. There are, of course, some notable exceptions: Richard Stallman for one. I admire his vision even while doubting it's reality. We need these extremists; even if only to get a glimpse of an idealistic future that could be realised. These are not the extremists I'm talking about. The programmers I am talking about are those that act as empty vessels. Loudly proclaiming their one-true-way and producing little in the way of working code. Academia is littered with them. Especially in the softer sciences. These people diligently work away on obscure languages in guarded niches, convincing themselves they're changing the world.

Extremist Programmers learn much but use little. This is probably the crux of the fallibility of this philosophy. Often they're too busy being purists to see the forest for the trees. It's an easy trap to fall into. Take learning about machine learning. There is a wealth of acquired academic knowledge on machine learning, function prediction, classifiers, clustering, reasoning, and whatnot. These subjects are difficult to learn, if only for the mathematical prerequisites. Now suppose we've learned all these things and never actually use any of them. We don't use them because we can't write the system in Haskell, or Lisp, or Erlang (with MapReduce please).

To me, this entirely misses the point. It is true, those languages are better, easier, faster, have lambda calculus, and a host of other advantages. The problem is, nobody outside of academia and a handful of visionary companies gives a rat's ass. Commerce has problems to solve right now, today. There is no time for kvetching about technology and which language can do the job better; the job needs to be done. Is this a possible reason it takes so long for technology to seep out of Universities and into industry? Is it all the energy being focused on issues of language expression rather than the problems at hand? Are the extremist programmers the grammar police in disguise - never adding any value to a subject; only noise.

Take the friend we all have who is perpetually learning the next language. The sheer mental energy devoted to acquiring all this knowledge is honestly stunning. Few of these people realise that to truly absorb a language one needs to fully understand its utility for problem expression - and that means implementing something real. Oh and it had best be chunky too. The only problems worth solving are the chunky ones after all. Writing 1200 line programs is all good and well, but it's hardly representative of actually writing software - software with features for people that want them. I invariably find that your average language zealot has the antipathetic mindset for reasoning soundly about much of anything.

Moving Forward

Thus my switch from UNIX to Windows development. Other than the initial dread and loathing, it's been utterly painless. Even though I went from the elegance and wonder of functional programming to imperative, object-oriented, state-bound programming; I've managed. Mostly because I'm still doing what I wanted to do. Learning about Machine Learning. Except now it is expressed in C# and F# rather than Lisp, Erlang, or what-have-you. Hell, I'll have the occasional sip of Kool-Aid too. I take solace in the fact that F# derives from a decent language such as OCaml. I take further solace in C# being similar enough to C++ and Java to make the transition easy.

These are practical concerns. Irrelevant bends in the road on the path to learning about Machine Learning. In the course of writing, I hope to provide useful, interesting, and practical information about my journey through machine learning, practical application of artificial intelligence, and the tools that let you express those solutions. I will also provide source code. Knowledge must be free and communal. Please clobber me on the head when I start being an Extremist Programmer. I will usually thank you for it.