Moving beyond language

· by Steve · Read in about 4 min · (823 Words)

When you’re talking with some programmers, particularly younger ones, you can’t help but run into the ‘great language debate’ at some point or another. That is, that many programmers have a language which they feel is superior to all the others, and they’ll put up a ton of resistence should you suggest that they use something else. It happens in other areas too of course - preferred operating systems, databases, apps etc, but as coders the language issue always tends to come up most, closely followed by IDEs.

I’m increasingly finding myself thoroughly tired of those discussions. Over the years, I’ve used a lot of languages - the main ones in approximate order of ‘first encounter’ (excluding assembly, which I don’t count as comparable): BASIC, C, C++, COBOL, Smalltalk, Visual Basic, Java, Prolog, Javascript, Python, Perl, PHP, C#, Lua, Ruby, Actionscript. At one point in my career, I would have obsessed over things like the verbosity of COBOL and Visual Basic (with all those superfluous Dim, As and line continuation bits), how useful closures are, how C++’s template system exceeds ‘generics’ systems, or Perl’s regular expression integration. But over the years while I still have elements I like and dislike about one language or another, and appreciate it when some ‘nice to have’ features are present, I’ve come to the conclusion that none of it really matters. I reckon I could pick up just about any modern programming language and be productive and content with it, because at the end of the day, language nuances are mostly icing - they don’t fundamentally affect the development process at the macro level at all.

Of course, that’s not to say that you’d want to pick up any random language for a given problem; of course not. Each has its own strengths and weaknesses for particular tasks, and crucially most often that’s not even related to the language itself but rather the surrounding ecosystem; platform / operating system support, availability of libraries and frameworks, performance characteristics at build and runtime, integration with existing software etc. This fact is what makes language allegiance so inappropriate in fact, along with unqualified, generalised statements like ‘language A is so much better than language B’. As engineers, which all good programmers should be at heart, we should recognise that each tool has its strengths and weaknesses.

Personally, if I’m looking to do a system automation tool or other portable scripted system, I’d probably look at Python or Perl, or maybe Ruby (except that I’m not as familiar with it), because they’re suited to that kind of task. If I’m looking to do something very intensive where performance and memory footprint is paramount, C or C++ would likely be a good choice. For an ultra-simple web app, PHP might be fastest, or moving up a little Ruby (on rails) might be good. If I need to make a moderately complex Windows-based tool fast, C# might attract me. If I want to make a more complex portable web app, Java is likely to be my choice. Horses for courses.

I think many programmers expend too much emotional energy on the languages that they like. Languages are just a way of expressing the implementation - they’re the very lowest level consideration of any software project. Sure, it’s what the programmer works with every day so maybe they’re entitled to obsess over it a bit, but in my mind that’s short sighted. Really your choice of language should be based based on the surrounding environmental conditions (like requirements for portability, speed, memory usage, deployment, integration, framework needs etc), not preferance for given syntax, since most syntax elements can be expressed in different ways anyway. Let those needs guide / boundary your choice rather than your language preference.

I think it’s actually far more important to think about all the things that apply regardless of implementation language - things like design, use of patterns & frameworks, use of techniques to improve software quality & maintainability like aspect-oriented programming, dependency injection, test driven development, contract-based programming, iterative agile development, all that good stuff. In the end, all of those considerations will impact the quality and maintainability of your final deliverable far more than what language you used.

In short, I think we should stop loving our languages and see them for what they are - simple tools which should demand no more allegiance than spanners, screwdrivers and hammers. Making software is about so much more than the individual characters we type into an editor, and I think we risk losing sight of what’s really important when we’re geeking out over the language minutae - just making good software. I for one don’t consider myself a C++ coder, or a Java coder, or whatever - I make software, and to do that I use a bunch of different tools depending on the circumstances. I actually think the more flexible you can be about those tools, the better.