Haskell’s effect on my C++: exploit the type system

Like most programmers, I was attracted to Scheme by the promise that it would make me a better programmer. I came to appreciate the functional style, but swapped to Haskell, a more developed language with a rapidly developing standard library. Unfortunately, for me, Haskell can’t yet replace C++ on a day to day basis, so I reluctantly spend my days tapping away at C++. So, were the promises true? has functional programming made me a better programmer?

Better is a tough question, I have no benchmarks for the quality of my code before and after Haskell, but it has certainly changed my coding style. An example is an increased use of constants in my C++. The immutability of variables in Haskell means that every variable is essentially a constant. The result on my C++ is that a phrase such as

int a = f();
if (a < 0) a = 0;

has been replaced with

const int a = MAX(0,f());

Brevity and clarity are not the only advantages of the second style. In the first case it is very easy to write if (a = 12) instead of if(a == 12) and accidentally modify rather than test a; we’ve all done it, and it is a nightmare to track down. If you get into the habit of declaring all variables that need no later modification as constant you transfer responsibility for eliminating this class of bug to the compiler.

This is a simple example of how Haskell teaches you to exploit the type system to turn potential runtime bugs into compiler errors and warnings. Another example would be an image editing package that uses one coordinate system for the original image, and another when displaying to the screen. With a single Point class for both coordinate systems you will introduce bugs by confusing the coordinate system of a variable, however careful you are with your naming convention. Consider instead defining a ScreenPoint and an ImagePoint class. Coordinate system confusion becomes a compiler error you have eliminated that entire class of bugs.

The absence of mutable data requires a rethink when you write loops. Without the ability to write i++ you are forced towards either tail recursion or the map and fold functions. As with my first example, the resulting code is more descriptive, and again the absence of mutable data will cut down on time you spend with a debugger. Unfortunately this recursive style cannot transfer to C++. Datatypes are not recursive by nature, and if they were compilers are not optimised for it so your software will crash when it exhausts the call stack.

Algebraic data types feel like a lost limb when returning from Haskell-land. Instead of writing

class Rect {
  public:
    double x,y,width,height;
    Rect (double _x, double _y, double _width, double _height) : x(_x), y(_y), width(_width), height(_height) {}
}

In Haskell you need only write

data Rect = Rect { x,y,width,height :: Double}

The comparative verbosity of C++ feels criminal. Although the ease of defining convenient data types in Haskell let me see the positive effects of doing so on the readability of my code, without Haskell’s lightweight syntax I have lapsed back to functions with large and confusing argument lists.

Finally, Haskell will give you a peek into the future. The top 7 languages in Tiobe’s index(C,C++,C#,ObjC,Java,PHP) are ancient in design. Although the newcomer C# was only introduced ten years ago, there is little in the language to reflect the thirty years of research into programming languages since C++ was introduced. Most of that research has been directed towards functional languages, and recently Haskell seems to have been getting all the attention. For example the rapidly increasing core count of a modern processor has made mainstream the problem of how to multithread your code, and strategies such as Parallel Futures and Software Transactional Memory made it into Haskell very early in their development cycle, if not first.

There is no doubt that time spent playing with Haskell has taught me to exploit the type system when coding in C++, but the most lasting effect may be when I abandon C++ altogether. As discussed here the belief that real work can only be done in C or its derivatives is false, and with the growth of Haskell’s standard library, and the appearance of functional languages such as Scala and F#, which are capable of plugging into the two largest standard libraries on earth, it won’t be long until functional programming ceases to be an avenue for academia and self improvement, and integrates itself into industry.

Source:http://vallettaventures.com/post/17090296373/haskells-effect-on-my-c-exploit-the-type-system