Scripting along…

This post is inspired by a discussion with a development lead of a company nearby and by the blog post “What about complexity in software“.

The specific discussion was about the idea of using a scripting language (think PHP, Python, Ruby, Groovy et al) for developing business applications and integration features.

A perfectly reasonable approach. Everything inside me rejected it.


There is more context to the discussion of course – which is why the formulation above is slightly unfair to the reader. But before going into any detail, let’s disect the situation a little bit.

For simplicity let’s assume you already have some software asset that you need to develop further in some specified but rather broad direction (i.e. expectations unclear as so often – but there is a distinct feeling of necessity).

Now, every time you make a decision about adding some tool (or technology, or team split, or…) into the big picture  you do not only make a step in some direction but you do also add complexity and limit further possibilities. While you can achieve more short term, it will typically be hard to revert that other decision or to make a competing, challenging, similar decision later on.

How hard changing a decision is, depends on how easily the change can be implemented. When changes can be implemented more or less atomically and others involved are not confronted with the unexpected, we tend to call that a refactoring**. All other cases are revolutions, causing significant pain before showing tangible improvements. If the pain and risk factor is large and your organization is sufficiently political, decisions will probably not be taken at all (or late, or for political reasons) and you should generally consider yourself screwed (bye bye progress!).

That said you should naturally strive to delay the unavoidable and:

  1. Make sure you really need to pick a tool at all.
  2. Make sure to pick a tool that carries as far as possible – albeit possibly not the most sexy one short term (so that you can live with it longer – even if you do not love it).
  3. Make sure to pick a tool that can scale with your problem space.

Back to the Point

Enough of that and back to the beginning of the post and the specific question of whether to use a scripting language for application development is a smart thing to do.

Scripting languages (at least the ones named above) are tuned for productivity. The general idea is provide for productivity by requiring little declarative “overhead”, provide simple and versatile data structures, high-level rich operations, and be relaxed about type safety and sometimes syntax.

Scripting languages are great for “wide but thin”: Shallow layering of code, mostly local data structure, many variations of the same pattern. Heavy re-use of non-trivial data structures and interfaces, deeply designed call hierarchies, performance-critical code are not what you should bring to the party.

Considering bullet point two above, if you know you are in for “wide but thin” and you can handle other known implications (e.g. deployment and distribution), go for the lightness and productivity of your favorite scripting tool. If you don’t know what you are in for, pick a tool that carries further – i.e. Java (it was about time I’d say that!), or C#, or C/C++ even (depending on your problem domain again – of course) – although that may be perceived as harder.

**) The ability to refactor instead of “throw away and redo” or “live with the pain eternally” cannot be praised enough.