Foo-Oriented Software

September 5, 2007

Erlang is oh-so-hot at the moment (which must be a novel experience for such an old, mature language), but Tim Bray isn’t convinced: –

… I think that the human mind naturally thinks of solving problems along the lines “First you do this, then you do that” and thinks that Variables are naturally, you know, variable, and has grown comfortable with living in a world of classes and objects and methods.

This got me thinking. My reaction to Erlang variables was the same: “they’re not variables, why don’t you call them something else?”. I think the answer is basically that it’s easier to understand the concept by remembering them as variables that aren’t, rather than having to build up a whole new concept. The other thing about variables is that they’re not all that instinctive when you’re learning to program – they don’t work like in maths, so an expression looks like an equation, but doesn’t (in imperative languages) work like one. In Erlang, it does (or it fails ;-)).

It is practically impossible to teach good programming style to students that have had prior exposure to Basic; as potential programmers they are mentally mutilated beyond hope of regeneration. — Edsger Dijkstra

Most people start OO code by writing huge long main methods and writing most other code in static methods with some objects only if they need data structures, i.e. the most natural way to solve a problem is to start somewhere and perform a sequence of actions. So why use OO at all? To abstract the solution to solve a whole a family of problems, to decompose the problem to make it easier to solve and to make the solution easier to understand etc. The thing I like best about in Java is that it’s fairly easy to create code that can be easily understood by others. I suspect that this quality is at the root of Java’s adoption, and that the tools are as important as the language features (or lack thereof…); Javadoc’s contribution shouldn’t be underestimated.

More investigation is required to see how well Erlang does in creating comprehensible, reusable code!

Advertisements

C#: Fat or Fit?

July 12, 2007

In C# 3.0 Considered Rubenesque?, David Ing considers (mainly) whether C# needs the functional extensions being proposed for v3.0 and by the by touches on a discussion I’ve been having internally about Java, Python and Erlang. The main points for me revolve around language complexity, the timing of the need for functional programming and when not to abstract.

Elliotte Harold has been vocal against adding complexity to the Java language. The complexity loving geek in my stamps his foot (“… but I want properties / closures / etc”) but Elliotte’s right – programming languages don’t have to accrete features, and in the real world most Java programmers get dazed and confused if you throw inner classes at them. On the other hand python has managed to support a functional style of programming (although I’m told that this isn’t totally pythonic) and is still considered easy to learn, so perhaps it can be done simply.

You don’t need to reach for Mother Shipton’s almanac to know that functional programming languages are going to be hugely important, with processors now not getting much faster, but gaining more cores. The languages that enable normal rank and file developers to take advantage of that are going to win in the way memory managed languages did, and in the way dynamic languages are doing. The question is not really “if” but “when”, and the answer probably depends who you are and what you need to do.

If I were writing an data analysis program to run a cluster (say 32 machines with dual-dual processors), then I’d be reaching for any language that let me use them as efficiently as possible – give the air con something to think about. Even if I had a dual-dual server dedicated to a single service I’d probably do so too, even though I’d be unlikely to get a 4x speed up due to I/O contention (example from Pragmatic Programmer). Most of our current web facing servers (where most of my code will end up running) are single or dual core, and aren’t due for an upgrade any time soon. So I’m better off sticking to what I know for now.

The final point is probably the most important, since it’s not future gazing: –

There is a school of thought that when you’re working with a relational database rather than a collection of in-memory objects, then you should not lose track of the various nuances and advantages of the stores – abstraction to save typing can come back to bite you?

Replace “working with a relational database” with “machine boundary” or “transactions” and it’s still true. Remember the first law of software complexity – you can’t get rid of complexity, just move it around. The more amazing an abstraction is at hiding complexity from you, the more likely it is to leak.