I don’t want to start an ecumenical conflict, but…

30 Aug

by edwardjstone 30.08.12

Developers and hackers are prone to holy wars, and choice of language and framework is no exception. A blog post in the last few months sparked up an age-old debate about the merits (or lack thereof) of PHP, leading to the creation of a real world PHP hammer to illustrate one of the key metaphors.

There are definitely some very persuasive arguments for why one shouldn’t develop in PHP, but the reality is that if you look hard enough you can find a blog post about why almost anything isn’t the right language, framework or tool, regardless of how popular or trendy it is. As enjoyable as it is to author polemics itemising the flaws of a particular technology choice, and then dogmatically insist on The One True Way™, it’s much more useful and pragmatic to focus on what you’re trying to achieve and why, and let that guide your choices of language, framework and tools.

In some ways this is analogous to one of the tenets of the agile manifesto - valuing “Individuals and interactions over processes and tools” - which is not to say that there isn’t value in processes and tools (or indeed in language and framework choices), but that there is more value in the individuals and interactions facilitated by those choices. In the Tobias & Tobias development team, we try to keep the what and the why foremost as we decide what works best for us:

  • We want a language that strikes the right balance between being easy for the programmer and doing things the right way - so we use Python.
  • We want a light-weight framework that will get out of our way when necessary - so we often prefer Flask to Django (although we do use and love Django for some projects).
  • We don’t want to repeat ourselves when writing CSS - so we use LESS (but we’re not averse to SASS, either).
  • We want to use open-source projects, and see them get better - so we try to contribute.

There are a multitude of incremental best practice decisions that have led us to the technology choices we’ve made, but we’re always looking to improve them. Part of that improvement process is not to spend hours complaining about the shortcomings of the language/framework/tool that you’re not using, but to keep sight of the what and the why.

Which isn’t to say that we don’t like to have the odd ecumenical conflict down at the pub.

blog comments powered by Disqus