Choosing a Programming Language

What programming language to use is probably the single biggest technical decision facing a project. That one decision, affects every one that follows – from the frameworks and libraries you can use, to the people you hire. So how do you go about choosing what programming language to use?

The truth is, you probably do what most people do and use the same language you used on your last project. Or, if you’re a hipster, you use the latest super cool language. A couple of years ago all the cool kids were on rails. Now the hipsters are trying to tell me how awesome their nodes are. Or that clojures are where its at. Last time I checked, their turing complete language had the same problem solving capacity as my turing complete language. Really what they’re arguing is their language gives them better expressive power: it’s faster to write and/or cheaper to maintain.

Right tool, right job

As the old adage goes: always use the right tool for the job. If you need to automate some command line maintenance task – use a language that’s good at shell scripting: bash, perl, hell even ruby; don’t use Java. If the problem you’re solving needs a desktop client that integrates seamlessly in a Windows environment: use C#, don’t use Java (be quiet Java on the desktop fanboys, just be quiet). If the problem you’re solving involves handling lots of XML and you like stack traces: sure, use Java.

The biggest distinction normally comes down to algorithmic complexity. If what you’re working on has a lot of algorithmic complexity, use something that’s good at expressing it: a functional language, like haskell or F#. Or if, like 90% of webapps, what you’re doing is data in, data out you need a language with good OO power to try and model your domain: Java and C# are both good choices here, along with almost every other modern language out there.

Scala

Or maybe you really hate yourself and you want a compromise: why choose functional or procedural when you can have both? Why miss out on every language feature thought of over the last 50 years when you can have them all, baked into one mess of a language? Yes, if that sounds like you, you probably think you’re a hipster but you actually missed the boat by several years: its time to learn you some scalas.

I suspect part of the reason Scala is gaining so much popularity is that it finally gives all the frustrated Java devs the language toys they’ve always wanted. Java really is an unbelievably retarded language now, it’s incredibly frustrating to work in. As someone that’s just switched to C#, I’ve relished all the new language gadgets and geegaws I’ve got to play with. Have they made the code any better? With lots of toys comes lots of complexity and variety, making code hard to understand and hard to maintain.

The thing is, Java is a toy language: any idiot can write decent idiomatic Java. The trouble is, Java is a toy language: everyone is forced to write screeds of noddy idiomatic, idiotic Java, no matter how much of a ninja rockstar they are. The best thing with Java, is it stops all the ninja rockstars from showing how ninja they are by writing undecipherable crap. I fear the impact lambdas will have on the maintainability of the average Java codebase as everyone starts finding new and confusing ways to express everything.

Hiring

Another reason to choose the right programming language, is it affects the developers you can hire. But does it really? I work in a C# shop now, do I turn down Java developers? Hell no. A good developer is a good developer, regardless of the language. To dismiss potential recruits because of the language they know is retarded.

And the trouble is, if you think that hiring only python or node developers will get you a better standard of developer: you’re wrong. The pool will simply be much smaller. Maybe the average quality of that pool will be higher, who knows, who cares? I only need one developer, I want her to be the best I can hire – it makes no difference where the average is.

Language has no correlation with ability: I’ve met some very smart Java developers, and some truly terrible hipster developers. I’d rather cast the widest possible net and hire good developers who are happy to use the technologies we use. To do anything else is to limit the pool of talent I can draw from; which, lets be honest, is pretty limited already.

Another argument I’ve heard is that the technologies you use will limit candidates willing to work for you – some developers only want to work in, say, clojure. Well, they’re retarded then. I’d rather have people who want to work on interesting problems, regardless of the language, than people who would rather solve shit problems in the latest hipster language. Now if you work for a bank, and all you have are shit problems? Sure, go ahead and use a hipster language if it helps you hire your quota of morons. If nothing else it keeps them away from me.

Lingua Franca

Take a room full of hipster language programmers and ask them to form teams. What happens? Magically, you’ve now got a room full of C# and Java developers. Almost every developer will know at least one of these two languages – they are the lingua franca. Everything else is frankly varying degrees of hipster.

The truth is the most important thing when choosing a language is how many developers on your team, and those you plan on hiring, already know the language. If everyone on the team has to retrain into say, smalltalk; and everyone you hire needs hand holding while they learn the new language – that’s a cost you have to factor in. What’s the benefit you’re getting from it?

Secondly, how easy is it to get support when you hit problems? The open source community around Java is awesome – if you’ve got a problem, there will already be 15 different solutions, some of which even work. If you work in C#, your choices are more limited – but there will be choices, some of which aren’t even from Microsoft. If you’re working in the latest hipster language, guess what? You’re on your own. For some people that’s the draw of hipster languages. For those of us wanting to get work done, it’s just a pain.

In the end, the best advice is probably to use the same language you used on your last project: everybody already knows it and your tooling is already setup around it. This is why Java has quickly become the new cobol.

Advertisements

First company coding dojo

Last month we ran our first company coding dojo – this was only open to company staff, but attendance was good (around a dozen people).

For those that have never heard of it, a coding dojo – based on the idea of a martial arts dojo – is an opportunity for programmers to improve their skills. This means getting a group of developers together, round a big screen, to work through a problem. Everything is pair programmed, with one “driver” and one “co-pilot”. Every so often the pair is changed: the driver returns to the audience, the co-pilot becomes the driver and a new co-pilot steps up. That way everyone gets a turn writing code, while the rest of the group provide advice (no matter how unwelcome).

For the first dojo we tackled a problem in Scala – this was the first time using Scala for most people, so a lot of time was spent learning the language. But thanks to Daniel Korzekwa, Kingsley Davies & DJ everyone got to grips with the language and we eventually got a solution! The session was a lot of fun, with a lot of heated discussion – but everyone felt they learned something.


Afterwards, in true agile style, we ran a quick retrospective. The lessons learned showed the dojo had been an interesting microcosm of development – with us making the same mistakes we so often see in the day job! For example, we knew we should start with a design and went as far as getting a whiteboard; but failed to actually do any design. This led to repeated rework as the final design emerged, slowly, from numerous rewrites. One improvement for next time was to do just in time design – in true agile style.

We also set out to do proper test-first TDD. However, as so often happens, this degenerated into code-first development with tests occasionally run and passing rarely. It was interesting to see how quickly a group of experienced developers fall out of doing TDD. Our retrospective highlighted that next time we should always write tests first, and take “baby steps” – by doing the simplest thing that could possibly make the test pass.

Overall it was a great session and very enjoyable – it was fascinating to see the impact of ignoring “best practices” on something small where the results are so much more immediate.