Crazy Coding Conundrums

As part of the discussion on refactoring and the more general notion of how important ‘smart tools’ in general are for programming (see “Is your IDE tilting at the Dynamic Language Windmill”, a interesting post on Reg Braithwaithe’s excellent programming blog), I submit the following musing:

I like how subtext (especially the demo movie) drops a ten-tonne bomb with ‘functional programming!’ written all over it on anyone who isn’t familiar with that totally different way of operating a computer (Watch the demo if you never really grokked what functional programming is about, it’ll blow you away). I like languages like Haskell and subtext as a sort of ‘king of functional’ – it’s the epitome of functional. Of course, there be monsters in these seas; haskell has to wring itself in all sorts of nasty bends in order to support such mundane things as I/O. It looks like subtext is heading to similar waters.

One thing that struck me in general about Subtext (and also about Haskell) is the inherent limitation to such a concept for large, ‘real world’ projects. Put differently, the world as we know it is imperative and not functional, and you start to feel the pain in Haskell (and, I think, subtext, though I haven’t actually used it, just marveled at the movie) when expanding from toying around in it and using it for a full app. See Axel’s attempt at introducing refactoring scripts to subtext for how such dedication to the functional paradigm causes problems.

However, I see a nice ‘solution’ out of this dilemma: Where you can separate out a part of the functionality you need into an entirely separate module (self-contained, does not refer to anything outside its own namespace) there really isn’t much stopping you from taking this abstraction all the way including using a different language. And, provided this module is small enough, you can safely forego such niceties as refactoring tools. It’s annoying not to have them, but not bordering on panic which is what would be the case if the project is so large that a ‘hand-built’ refactor is just infeasible.

Turns out a lot of problems that are well suited to the domain of functional programming are usually very ‘module-able’ – they are very easy to separate out into something entirely standing on itself. From outside the ‘black box’ of the abstraction, it’s usually a function call, nothing more. Give it some parameters and out comes the result. It’s very unfortunate that neither Haskell nor (AFAICT) subtext have the ability to compile to a common runtime platform (be it the JVM or Microsoft’s CLI) which means for now you have to muck with non-portable C-compiled code and ‘native’ bridges if one wants to mix up java and haskell (or subtext).

If a language is used primarily as an offshoot add-on maker for a very specific and limited domain, none of that refactoring stuff is important, and you can safely chase brevity and ‘neatness’ with no regard for tooling at all.