Functional Programming
When I were a lad, and was being taught to program, I read a bunch of Basic code and wrote great long lists of instructions; that's pretty much how many people in the 90's described programmers, coders or hackers "someone who spends lots of times typing great long lists of instructions into their computer" - Robert X Cringley.
However, long lists only get you so far, so my next step into the world of programming was to learn Pascal, and I first read a simple book as part of my A-Level, by P. M. Heathcote, which introduced very basic programs in Pascal, something like...
program HelloWorld (input, output)
begin
println ('hello world');
end;
So, I suddenly had this idea of putting the long lists of instructions into sort of functions:
program HelloWorld2 (input, output)
procedure foo()
begin
println ('foo');
end;
procedure bar()
begin
println ('bar');
end;
begin
print ('hello ');
foo();
print (' and hello ');
bar();
end;
(Note: before you call me out and say you can "GOSUB" or "CALL" other functions in BASIC, not in the dialect I first learned, all you could do was SUB to a line number, following the instructions until you used RET to go back to where you were... So they were technical functions, or procedures, but they were really just more lines of code within the huge list of lines of code, no indentified in anyway, except by comments, as being functions).
Interestingly at this time, I was taught there were two kinds of functions you could call, ones which returned a value, known as "functions" in Pascal, and ones which didn't return anything known as "Procedures". These latter you'll be very aware of from other langugages like C, where the return type is part of the function declaration, so "void foo();" obviously doesn't return anthing, whilst "int bar();" returns an integer.
That "Procedure/Function" definition stuck with me a long while, I was a kid, I was taught something and got a certificate to say to the world "He knows what he's talking about", so it was with some trepidation, years later, that I had to admit it was rubbish and everything was a function.
And this revelation came with my being taught about "Functional Programming", this was important for large projects written in languages like C, because you really wanted to start to learn how to keep functions doing one task. So when you designed, named, write and test a piece of code, you can break it down, and know each piece, or each function, is doing just one job.
"void Max(const int& p_Left, const int& p_Right, int& p_Result)"
Here I've just defined a function prototype, even without my explaining, I'm pretty sure you could guess what it does... Yes, it takes the left and right integers given and decides which is the bigger, placing that value in the result.
We can design code, define the prototype, and hand the nitty gritty of the actual code body of to someone else, to write the body of it, or just to test our implementation works. And though this is a trivial example, think about a single function to say format a disk, it might contain calls to dozens, or hundreds, of other functions, but it itself does one task, and each sub task is itself kept in a single function so you break the whole job down. Within your large projects therefore you maintain a level of ease in how to debug, maintain and update the code, if your "foo" function doesn't work, just fix that one function and re-test, there shouldn't be multiple-foo's and there shouldn't be more than one task performed within the code inside "foo".
This was the first major meeting, and teaching, I had on "Functional Programming", and it was something I took to heart. My code took on very much a "one function" style, where each function had a single purpose.
Twenty years on, and even in an Object Orientated world (of C++, C# and Java) I utilise the functional idea.
The main thing applying the single function ideal to my code has lead to is a vast improvement in maintainability, this has been important for my job and on going sanity with large projects.
However, there are other caviates, for there are other parts to functional thinking which have to be taken into account. For example, are you going to allow functions in your code to have just one, or multiple exit points from a function? For example:
const int bar (const int& p_i)
{
return p_i * 2;
}
const int foo ()
{
if ( x > 0)
{
return bar(x);
}
else
{
return bar(-x);
}
}
This is perfectly reasonable code, foo does one job, deciding upon the value of x which value to pass, however, this is a trivial example, what if there are tens, hundreds or even thousands of different paths you could take as the result of foo?... A case statement with every character possible already throws hundreds of options our way, so it's not out of the ordinary.
You could be tracing through this code and ANY of those many exit points could fail, causing a crash, which you then have to dig through after the stack has all unwound.
Using many exit points is fine, if you can justify it, please don't get the impression I'm hating on the concept, if you have a low memory situation for example, I can see you won't have space spare for my suggested solution; and this is part of the many trade-offs you will learn about in a career of programming, when to, and when not to employ a technique.
But in the above example, I would change foo as follows:
const int foo ()
{
int l_result = 0;
if ( x > 0)
{
l_result = bar(x);
}
else
{
l_result = bar(-x);
}
return l_result;
}
So, you see I have a local value copy, this is using more memory, and wants to allocate that memory... and there are other options than allocating that as a local variable, but for maximum maintainability keeping that value within the actual function is a key feature of this example.
And so how does this assist in maintainability? Well, we can now debug the function a lot more easily, we can see the value of "l_result" at any moment in a watch within the debugger, we can wrap individual - failing - calls to "bar" into try-catch statements and debug the returned value for the whole function at the return at the bottom.
I've seen some horrors in the poor use of both returning from within a function, where return points are hidden three, four or more nestings deep, and it's made for nothing but frustration, try to avoid multiple function exit points.
What else does functional programming offer us?... Well, it also offers us an easy way to make code self-documenting, if we have a function like the "max" function earlier, it explained itself in just it's definition, take advantage of that fact.
But what about functions inside objects? I hear you cry, well lets take a pure C++ example, in C++ (or at least most C++ compilers) we're allowed to just define a function prototype and go to town, but that's really; technically; C not C++. To make things C++ we really should have the functions all inside a class definition... I stick to this idea, even if we just need a pseudo class of static functions:
class Helpers
{
public:
static void Max(const int& p_Left, const int& p_Right, int& p_Result);
static const int Sum(const int& p_Left, const int& p_Right);
};
One can see what the functions mean, and the function have meaningful names, the class itself can have, a useful name, and indeed the class can then be in a namespace which itself has an even more useful name. So we build up not complexity, as some assume, but ease of division of functionality, breaking numbers from user interfaces from strings from file management, break it down, divide and conquer, that was the original purpose of functions in computing, and so that original function is now emphasised in the languages and methods we employ today.
C++, C#, java, Python, all can benefit from using the function idiom... Your projects certainly can.
