IT-Analysis.com
IT-Analysis.com Logo
Business Issues Channels Enterprise Services SME Technology
Module Header
Craig WentworthMWD Advisors
Craig Wentworth
16th April - Egnyte the blue touchpaper...
Louella FernandesLouella Fernandes
Louella Fernandes
11th April - Managed Print Services: Are SMBs Ready?
Louella FernandesLouella Fernandes
Louella Fernandes
11th April - The Managed Print Services (MPS) Opportunity for SMBs
Simon HollowayThe Holloway Angle
Simon Holloway
11th April - Intellinote - capture anything!
David NorfolkThe Norfolk Punt
David Norfolk
11th April - On the road to Morocco

Analysis

Will functional programming have a Renaissance?
Russel Winder By: Dr Russel Winder, Partner, Concertant
Published: 26th February 2008
Copyright Concertant © 2008
Logo for Bloor ResearchLogo for Concertant

In the 1980s and 1990s the war between declarative programming and imperative programming was eventually won by object-oriented programming. Declarative programming was represented by logic programming with Prolog, and by functional programming with languages like Scheme, Erlang and Haskell. Imperative programming was represented by the heirs of structured programming, all based on abstract data types, of which the object oriented languages such as C++ and Smalltalk were the favoured languages of the time. And then came Java and that was it—imperative, and object-oriented in particular, won. Or did it?

Ever since the hegemony of imperative programming was established, the mainstream programming languages have been moving more and more towards declarative expression. A trivial, but very indicative Java example, looping through the elements of a list is traditionally written in a way directly inherited from C and C++:

for ( int i = 0 ; i < list.size ( ) ; ++i ) { doSomethingWith ( list.get ( i ) ) ; }

iterates over each element of the list, represented as an array, calling a function. However, most people are now of the opinion that this is a very low-level form of expression that is useful in very few situations. Instead, the modern way of expressing iteration is exemplified by the Java statement:

for ( SomeType s : list ) { doSomethingWith ( s ) ; }

Other imperative languages are going down this road. For example in Python:

for item in list : doSomethingWith ( item )

and in C++:

std::for_each ( list.begin ( ) , list.end ( ) , doSomethingWith ) ;

The programmer no longer has to worry about how to access the elements of the data structure, nor how to keep proper control of the iteration variable: the details of how to do iteration are hidden away in a declarative expression. This more declarative mode of expression allows the programmer to assume that between them the compiler and runtime system will get it right. So the evolution of abstraction in programming appears to show that declarative rather than imperative expression is the higher level abstraction.

So, did functional programming have it right in the first place? Are the imperative languages slowly transforming into functional languages? Well, yes—and no! The evolution of C++, Java and Python shows that declarative expression is to be preferred over imperative expression in many situations. So why did the declarative languages fail to win the hearts and minds of programmers and their managers in the 1980s and 1990s?

Part of the reason is that functional languages were seen as academic and imperative languages were for real programmers. There was also a very large amount of imperative code and expertise around and nowhere near the same amount of functional programming expertise. Having said that, Erlang grabbed a central place in the development of telephony switchgear, and Java seized a central place in the world of Web services. So it is possible for new programming languages to burst onto the scene. Usually, though, it comes when there is a new class of application to be constructed, or a radical new requirement that existing languages cannot satisfy—for example trading room systems, where statically compiled and linked systems were not suitable, so Smalltalk and then Java filled the gap.

Is there a way functional programming can move centre stage? Will Haskell become a dominant language? I suggest not. Two main reasons: a) recursion is a fine way of expressing recursive functions and recurrence relations, but it is a very poor way of expressing iteration; and b) the currently dominant languages are evolving to incorporate all the most expressive aspects of functional languages. Declarative modes of expression may be good when appropriate, but being able to write an explicitly imperative statement when needed is the flexibility that functional languages do not have.

So is the door open to languages such as Scala and OCaml which combine declarative and imperative? Possibly. What is more likely is that Java will evolve to encompass the features that Scala and OCaml have that are useful, which it does not already contain.

Can functional languages have a renaissance? Yes. Learning about functional programming is a very good way of improving your programming in imperative languages. The consequence is that every C, C++, Java, Groovy, Python, Fortran, etc. programmer should be studying languages such as Haskell, OCaml, Scala and Erlang. Not because those languages will be used directly in development, but because the way of expressing things in functional languages leads to excellent idioms in imperative languages. As the Psychology of Programming community has known for many years, an important measure of programming expertise is the number of different programming paradigms a developer is competent with. The most important paradigms are procedural (exemplified by C), object-oriented (exemplified by C++ and Java), and functional (exemplified by Haskell and Erlang).

For Java programmers, Scala is interesting exactly because it merges functional and imperative programming in an integrated way. It will probably not take over from Java, but it has an important place nonetheless, if only as a useful training vehicle.

Advertisement



Published by: IT Analysis Communications Ltd.
T: +44 (0)190 888 0760 | F: +44 (0)190 888 0761
Email: