Functional Programming in Imperative Languages

This post is a bit techie here... bear with me! :)

I've been toying and experimenting with functional programming these few weeks. Ever since I got into a bit of trouble for not debugging my software properly, I've been thinking: "How come software engineering is SO difficult to debug? and integration is every software engineer's nightmare. We keep having to do regression testing again and again and again till the cows come home, and even then, we can't be reasonably sure that we haven't missed out some distant but destructive bug." Scary.

And part of the reason is due to the heavy use of stateful variables, which keep on getting changed as the program executes. Functional programming (FP), in its purest form, is super-easy to debug, as it is impossible for unforeseen side-effects to occur (due to its inherent property of referential transparency).

So I was thinking, "There must be a better way to write software than to have to do all this testing - it's simply... not effective enough. Unit testing is NOT the way to go - it's the entire foundation of writing software that's not good enough."

The main problem with using FP to write commercial-level software is that for the past 40+ years, the most widely used programming languages to write commercial languages are imperative languages. And I bet you that at least 90% of all software engineers have to write in imperative languages. And functional languages, to put it mildly, have very exotic syntaxes and grammars. Imagine the huge costs to organizations if they have to retrain an entire generation of software engineers. So the companies prefer to keep the status quo.

*******
So why don't we use a balanced approach? We can borrow the key principles of FP that make them so useful, and apply them to our favourite imperative languages (e.g. C++, C, Visual Basic, Delphi, etc. etc). That way, we gain the best of both worlds - and even better, we don't have to learn a totally new language (like switching from writing English to writing Chinese) just to benefit from FP.

So I've been trying to apply FP principles to Visual Basic 6. Yes, THAT toy language. And it's very interesting. Like making sure that I do NOT change the value of any variables within a function. And I'm thinking of how to implement higher-order functions (functions that accept other functions as parameters) in VB6.

And hee, thank God, the code is so much more readable, cleaner and more predictable! And... even more cool is the fact that the number of lines of code is cut by between 1/3 and 2/3!

Of course, there's a slight disadvantage - performance issues due to overhead of function calls (esp recursion). But that can be resolved by judicious usage of stateful variables to cache the output of any function.

Hence, using FP principles in imperative languages should help reduce the complexity in any given class that tends to balloon when you keep using member variables to cross-reference other member variables... anyone who's tried to do software maintenance on a class that's been inherited (pathetic pun intended) from the guy before him, who in turn inherited it from another guy... ad infinitum.

Cool. :D my first ever techie rant/proposal on this blog. if you're a fellow techie, what do you think of this idea?