Brisbane JAOO - Conference Day 2 - Morning Keynote

The morning keynote was given by Erik Meijer,Why Functional Programming (Still) Matters.

Creating software is all about abstraction, which is reducing information and retaining only relevant information. Unfortunately the industry has been abstracting the wrong details for the last 50 years...

There are 5 Dilemmas:

1) Useful versus Useless

I'm not sure I really understood the point Erik was trying to make here, but it was along the lines of the things that makes programs useful are the things that make them vulnerable to misuse, such as data as code and component interaction leads to XSS, buffer overruns, virus and BSOD.

2) Rich versus Reach

Flash, Silverlight and Java are rich (proprietary) whereas HTTP, HTML and JavaScript have reach (open standards). Whatever :)

3) Local versus Remote

Local is easy and remote hard. Local is what is taught in school. Remote is interesting and more like real life development. Erik defined attributes of local as:

• compositional
• sequential deterministic
• implicit
• synchronous
• homogenous

and remote as :

• concurrent
• nondeterministic
• explicit
• asynchronous
• heterogenous
• noncompositional

4) Change versus Inertia

Geeks like to build cool things. People just want to get things done. Marketing tries to make people believe that the cool new things that the geeks built are the things they need to get stuff done.

Geeks p(success) = F(10 X improvement * Moore's Law)
People p(success) = F(perceived crisis / perceived pain of adoption)

see "The Change Function"

The fifth dilemma seems to be Erik's main point...

5) Pure versus Impure

Erik gives an example of some code (in C#?) that does a couple of queries including output that outputs in an order that is non-intuitive. The issue is that the code can be read as local yet the code is remote and the side effect of this is that things don't occur in the order that they have been coded.

Another couple of examples (C# again?) shows an unchecked exception happening beyond where it would appear it should occur and a file being disposed before it is used, again local versus remote.

The main point of all of these examples is that there are side effects occurring that are not obvious from the code, i.e. the relevant information has been abstracted away.

Erik continues highlighting side effects by stating that even object creation has side effects, i.e. two different heap spaces are set aside for two different objects of the same class.

Code has side effects which are not obvious from reading the code, that is the side effects of code are as important as the parameters and the return value. But you can't get rid of side effects.

Erik states that Fundamentalist Functional Programming is the answer (pure functions with explicit effects) where a functional language is defined as a language where functions are first-class citizens and given a function and a set of parameters, the function returns the same value ever time it is called with the set of parameters (equality-preserving, i.e no side effects). I believe it is here that he also makes the point that parameter evaluation should be lazy, but I have to admit that where this was mentioned or the importance of it was lost to me.

Monads allow the declaration of a functions side effects and he gives a few examples of what this means the mapping to and from functions with monads.

Then Erik considers whether or not normal programmers can understand what is required and can functional programs interact with legacy code. He gives some examples though all a little bit underwhelming in convince me that either is possible without much pain and gnashing of teeth.

He concludes by giving a litmus test for determining whether or not a language is a fundamental functional language and suggests buying a Haskel book and helping to persuade MS to produce a fundamental functional language.

While I found the talk interesting, it was rather unconvincing in its final conclusions for me. I'm in no rush to run out and buy yet another language book and I doubt I'll ever tell anyone what language they should implement. Erik's real crisis is just a perceived crisis and I doubt the industry would change to Haskel anytime soon based on the evidence from this talk. In the end, this talk just seems like an intellectual exercise to get people to think...