Tuesday, 27 May 2014

Is it Imperative that you learn Functional Programming with Java 8?


I've recently been taking look at Java 8 and have got hold of "Java 8 In Action" published by Manning. The first thing that struck me is how one of Java 8's unique sales propositions is functional programming; functions are now first class variables, you can pass them around your code as you would an int or a String. This is a big change.

It seems that functional languages have become more popular in recent years and there are no end of them to choose from. Modern function programming language examples include Clojure, JavaScript, Scala, and even Erlang, invented in the late 1980s, has made a come back.

So, why is there this change in direction? You could probably come up with several reasons, but we’ll begin with the premise that industry best practise changes over time and even the most popular languages will one day fall out of favour. I imagine that if you're young enough there will be a day when you'll look back and say "remember when we used to use Java”? Before looking at why there is this change, let’s reflect on how we got here by stepping back to the 1980s...

According to Wikipedia the IBM PC was released on 12th August 1981. The first PCs shipped with BASIC1 although the cool guys soon got fed up with this and moved on to Borland’s Turbo Pascal. Turbo Pascal’s coolness didn’t last that long because Microsoft bought out Microsoft C (or MSC), which soon became the defacto standard. It was cool because if you were clever you could access the hardware directly using int 21H, int 10H and int 14h and others, and if can remember which interrupt did what, then you’re old like me2...

There were other computers before the IBM PC including the Apple II, Commodore Pet etc, but the IBM PC was a 'grown-up' PC for business applications. I remember trying to buy one for a project I did in 1985, they cost thousands of pounds and you couldn’t get one for love nor money, everyone wanted one; however, I digress.

In the late 1980s came the Microsoft Windows SDK, a C based SDK that's bean around since tiled Windows 1 (apparently Microsoft didn't used overlapping windows in Windows 1 because it copied Apple's Macintosh and probably infringed their patents - even though Apple allegedly stole the idea for the Mac from Xerox Parc, though how true this is I can't confirm). The SDK really took off in Windows 2 introducing the world to callback, message based programming; an idea they allegedly stole from X-Windows and Motif on Unix.

Around the mid 1990s languages became Object Oriented; classes were invented to tie together methods and data, introducing the concepts of data hiding and encapsulation. ‘C’ became ‘C++’ and if you were using the Windows SDK around this time then you switched to Microsoft Foundation Classes; an OO wrapper around the SDK. This change was seen as a good thing. A major problem with the old function based languages was that you could allocate global variables anywhere in your code base and change them using any function at any time. This obviously caused major screw-ups in a lot systems as you couldn't be sure that changing the state of a global variable wouldn’t introduce a bug in some far flung corner of your application. The other major problem with defacto language C was that YOU were responsible for allocating and deallocating memory and if memory pointers were global then, when you accessed them, you couldn’t be 100% certain that the pointer was still valid and if it wasn’t… you crashed.

Along with object oriented languages came object oriented methodologies, culminating in the late 1990s with UML. This was a fusion of the Booch Method, James Rumbaugh's OMT and Ivor Jacobsen's OOSE and it was de rigueur when it came to designing software. All kinds of tools were available for the job of documenting and communicating your designs and, from experience, some of these were of very questionable quality, which in begs the question: were the developers actually using UML to write their UML programs? If so, then those products weren't really a good advert for UML.

You don't see as many organisations using UML these days, though I still do when I need to get a design straight in my head. My first choice of UML tool is, and always will be, pencil and paper. It's simple and it works.

Finally in my brief history of programming is Java. Initially released in 1995 and becoming popular a few years later, Java was based upon the idea of improved C++. This mainly because it runs on its own virtual machine, which takes care of memory allocation and deallocation for you. It has become a defacto standard of object orientated languages.

The thing about this broadly made up timeline is the under pinning concept of imperative programming. In summary, assembly language gave rise to C, C to C++ and OO, and C++ and OO lead to Java - all imperative. Wikipedia gives a good overview of imperative programming, so I’m not going into it in detail, but I’ll summarise imperative programming as programming with functions AND mutable state, meaning you can have instance and global variables.

How does functional programming differ to imperative programming? The main idea is that functions are data, just like integers and Strings; algorithms are implemented in terms of function calls (while and for loops do not exist, you use recursion) and variables are always local.

You could be fooled in to thinking that, because they contain the concept of a function and no classes, languages such as C and Turbo Pascal are functional programming languages. They’re not, they’re imperative programming languages, because they have state data

So, what’s changed? The common answer to this, one that put about by Erlang developers and one you’ll find in Manning’s Java 8 book, is that hardware has changed. ‘Computers’, at least the one’s you’ll find in a server room, are now a sophisticated multi-processor, multi-core affairs with terabytes of memory. Take, for example, the HP Proliant DL580 G8 server; it has up to four processors and each processor can have up to 15 64bit cores. That’s huge, especially when compared with the original, revolutionary 16bit Intel 8086 on the original IBM PC. Assuming you’re running Unix and you ran the top command, then maximum processor usage would be given as 6000%. Given this dramatic rise in machine power we software developers need languages that can support them allowing us to easily use all this concurrent processing power and that’s were functional programming comes in.

In imperative programming you can have instance variables, global variables and mutable state. These can be shared between threads although sharing these resources is costly and inefficient in terms of synchronisation and locking. It’s also fairly slow and difficult to do as you have to avoid deadlocks and other similar problems. Functional programming does away with all these problems because it does away with all the tedious mucking about with instance variables and state. That means you don’t have to bother with locking and synchronisation and thread or processes (call them what you will) can be independent of each other.

That’s the theory, but does it hold up to scrutinisation? Let’s not forget that it’s possible to write good multi-threaded programs that effectively use the many cores of a large multi-core and multi-processor machine with imperative Java 6 or 7. Just like functional programming languages you have to think about what you’re doing, plan out a suitable design and execute it using business ‘best practice’. Just because Java 6 or 7 is an imperative language, you don’t have to share data between threads/processes and use synchronisation and locking, it’s just a matter of design. The logical conclusion of this is that you can do without functional programming, which leads to possibly the real reason behind the popularity of functional programming languages: people enjoy using them.

You could therefore say that functional languages are the “latest thing”; a craze, they’re trendy, a fashion. I have to emphasise that 'fashion' in software development is not necessarily a bad thing and is nothing new. If you go back to my potted history above you’ll see that the time-line is full of trends and crazes: the adoption of ‘C’ over Turbo Pascal and BASIC, the paradigm shift to Object Orientation and even the move to Java with it’s compile once and run anywhere promise.

Is it Imperative that you learn Functional Programming with Java 8? Ask me in a few years time...


1All historical facts in this blog are guaranteed inaccurate by my failing memory.
2Correct me if I'm wrong, but int 21H = MSDOS Functions, int 10H = direct screen access and int 14H = serial I/O

3 comments:

sidgate said...

Do you really think it is a craze? wouldn't it help developers to write minimal code without worrying about parallelism?

Roger Hughes said...

sidgate
Thanks for the comment. By saying 'craze' I want to highlight that in this business science sometimes take a back seat to hype and fashion. There's often more psychology behind the adoption of a language or paradigm change than logic. Writing more minimal, clearer, more maintainable code is a really good reason to use Java 8. The 'parallelism' thing seems more like marketing hype as you can do 'parallelism' without functional programming and Java 8; hence, the supposition that developers use functional programming because it's cool... This s not necessarily a bad thing as reinvention and change is nothing new drives the computing industry.

Anonymous said...

Functional programming makes it much easier for the JVM to run your code on multiple cores. However, for 99.99% of all problems, aren't things quick enough already, and is it worth the additional 'think' time to implement your solution in a functional way?