The language dilemma for production software

November 15, 2010

Right now, I'm feeling enthused about the idea of writing some things in one of the interesting new languages and environments, such as Go or node.js. But here's where things collide with my problems with learning languages; if I'm going to write any significant amount of code in these new languages, it has to do something real. And most of the real things that I have to do are not personal projects but software that I would want to use in our environment here.

Which leads to my dilemma: how can I justify inflicting production software written in a peculiar language on my co-workers? I don't exactly want to gift them with a black-box program that's important to our systems, one that only I can possibly work on. Thus, if I'm going to use a new language for some piece of software I need to be able to make a reasonably convincing case that it provides some compelling benefit over writing the software in a language that my co-workers are already familiar with, and that I'm not just complicating my co-workers' lives because I like shiny new stuff.

Unfortunately, so far I haven't been able to come up with very compelling justifications, not even of the 'this is by far the most productive language for me to write this in' sort. Possibly this is because I don't know these languages well enough, but this is sort of a chicken and egg problem.

(At least not for Go or node.js; there is a killer feature that I could use in some language, but I don't think that either has it.)

As a side note, this means that languages being well supported in our Linux distributions is especially important, because I can just imagine my co-workers' faces if the instructions for maintaining one of my programs start with 'first, download the language source code and compile it'. Sadly, this is an area that neither Go nor node.js seem to be doing very well on at the moment.

A corollary to this is that the best sort of real programs for me to write in a new language are things that do essentially offline processing of data, such as log scanning and summarization. If I want to crunch weeks of mail logs to analyze delivery delays or spam levels, most of the time it doesn't matter what language I write it in because it doesn't matter if it breaks. (In fact such log analysis may only be done by hand once in a while in the first place.)

Sadly (you saw this one coming) I don't currently have any such work that needs anything more than awk, or maybe Python.

(Doing log analysis on our DNS query logs was my first use of the bstring library for C, precisely because I had enough data to go through that Python or awk didn't cut it any more.)

PS: to be utterly clear: I am not saying that production software shouldn't be written in new languages, or that it should only be written in new languages when they provide a compelling benefit.


Comments on this page:

From 118.209.42.80 at 2010-11-16 02:15:24:

I'm reminded of Ted Dziuba's recent entry, in case you don't read his blog: http://teddziuba.com/2010/10/taco-bell-programming.html

From 66.57.45.106 at 2010-11-16 11:24:17:

Concerning that "killer feature": have you looked at Erlang's support for bit strings?

By cks at 2010-11-19 16:38:13:

I hadn't heard of Erlang's bit strings before now, but a scan through the documentation has gotten my attention; they look quite interesting and the pattern matching seems likely to be just the sort of thing for this. I'll have to poke around Erlang some.

(I should probably also look around CPAN, since people seem to have written Perl modules for just about everything under the sun and this is not exactly a new problem; someone using Perl has to have run into it before. I may not like Perl, but doing something easily has a lot of appeal.)

Written on 15 November 2010.
« Four reasons to have a firewall
When good ideas go bad: how not to do a file chooser dialog »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Nov 15 23:51:42 2010
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.