Wandering Thoughts archives

2010-11-15

The language dilemma for production software

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.

programming/ProductionLanguages written at 23:51:42; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.