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...

Brisbane JAOO - Conference Day 3

Day three, pretty much the same as day 2, which is a good thing. I'll follow up later, but two snipets of the day.

Bob Martin talking about Clean Code: "Code in a try block is living in a fantasy world where nothing goes wrong."

End of the day chatting with Erik, Gregor, Patrick and Joe and then being invited out for dinner! (Sadly I was too tired to take up the offer :( ).

Brisbane JAOO - Conference Day 2

Wow, what a wonderful blur of a day it's been. Reflecting back on the day feels like looking over a few days in time so much has happened. Two interesting and informative keynotes and six sessions all with good knowledge to take away.

If I had to pick one session as a favorite, it would have to be Erik Dörnenburg's and Gregor Hohpe's Software Visualization and Model Generation. Simple ideas that can have a big impact on helping to manage large amounts of data. Basically they presented a simple pattern for using different tools to help visualize data. I'll post more details on this and other presentation over the next week or so.

Brisbane JAOO - Tutorials Day 1

So today was my first day at JAOO. And I loved it. I attended two vey good tutorials: Rebbeca Wirfs-Brock's The Art of Telling Your Design Story and "Uncle" Bob's "Advanced Principles of Agile Object Oriented Class and Component Design. Both presenters were engaging and definitely knew their subjects.

From the first tutorial, the key point was figuring out what to remove from a story to help more effectively get your point across to your audience. There were a lot of good points across the tutorial and good information that can be used beyond just telling a design story.

I really did enjoy the second tutorial. Bob is animated, full of energy and happy to digress slightly into entertaining and informative rants. He's completely shattered (in a good way) my view on OO modeling and the "is-a" and "has-a" relationships with excellent concrete examples. He gave us solid categorizations for defining problems with software designs. He made us reconsider what OO really means and I now have some interesting metrics to take back to our team to analyze the state of our codebase. Not to mention the design patterns he has for encouraging good design and fending off software rot. If I have some time and motivation in the future, I'll go into a lot more detail of what I learned from this tutorial.

Oh, and being in the same room with the likes of "Uncle" Bob, Micheal Feathers and Martin Fowler, I'm really enjoying it...