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

Better than simian-check

Simian is great for helping to maintain code quality and enforcing the DRY principle, especially in a green field project. And while not as helpful, it can help to implement the idea of "making things no worse" in a brown field project. However, its goodness only extends in one dimension for a two dimensional problem.

A team can mandate that the number of duplications within the codebase shall be no more than some threshold. That's one dimension. But what about duplications that already occur below the threshold? simian-check does nothing to ensure that the level of duplication below the threshold doesn't entropy. Simian is good for legacy codebases, but there is plenty of room for improvement.

This is something I've been mildly aware of for several years now, but I haven't been actively trying to find a way to solve it until recently. I had some slack time and was feverishly working at refactoring our legacy codebase to reduce our simian-check threshold another notch. Having reduced the count by one, I took a quick survey of what would be required to reduce it by yet another notch. At that moment I half panicked half had a flash of insight (most like I had the insight quickly followed by a brief moment of terror).

If you've never had to play in a large legacy codebase, you may not have ever run into the situation I just found myself. Since simian had not been running on this system, there was a lot of duplication. The more the threshold was lowered for the simian-check, the more work (i.e. more duplications to be removed) was required to lower the threshold one more notch. And the increase in work is more than linear.

My insight was this; I had a finite amount of time in which to lower the duplication count. If I couldn't do all off the work within that time, the threshold would remain the same. It was quite possible that I could remove half the duplications and then return sometime later and find that I had double the work to do. While that's possible, it's not very probably. I had seen the second dimension to the simian-check. My fear from that initial thought got the wheels in my head in motion.

The solution is very simple. The simian-report is a an xml file, so I wrote a SAX2 DefaultHandler that was able to parse the number of duplications at the different threshold levels. Putting this into a trivial ant task then gave us a task to help make things no worse even at levels below what the simian-check was doing! Within the first week, the new legacy-check was breaking the build (where the simian-check would never have) and focusing the teams attention on how to make things better.

Scala

I've been spending a bit of my spare time learning Scala. I like it because:

1. It compiles to Java bytecode
2. It can use any of the Java API's - the years of investment I have in them translates seamlessly to Scala development and I'm productive almost immediately
3. Functions are first class citizens of the language allowing for higher order functions leading to a more expressive language

It has a some other benefits, but I haven't fully learned the language just yet, so it's hard to say I like it because of things I haven't experienced.

The main drawback at the moment is lack of IDE support. I'm using the scala eclipse plugin, but it is primitive compared to the Java support I'm used to in eclipse.

The quality of the code you write today...

... will affect your ability to write quality code for the new features you need tomorrow.

If you haven't been writing quality code, how can you expect to write new code with any degree of quality? I hypothesize that the affect of this isn't linear, but exponential.