Wednesday, October 4, 2006
The cool track today was “Back To the Future” hosted by Dave Thomas and Ole Lehrmann Madsen. The idea of the track was to broaden our perspectives by presenting ideas about some older and little-used programming languages. I liked this track because I’ve become so used to equating programming with Java and that feels perhaps a little too comfortable for my own good. (In fact, it struck me that the subject of diversity of languages is a big theme this year.)
The first presentation was on “The History of Scheme” by Guy Steele Jr. (http://tinyurl.com/jdr9r ), who wrote Scheme in the 70’s with Gerald Sussman (they wrote about it in the so-called Lambda papers: http://library.readscheme.org/page1.html ). The interesting thing about this talk was that it showed how elegantly some ideas could be conveyed in a language that was all about lists, and that in working on the Scheme interpreter, Sussman and Steele discovered by accident that support for functional programming and for agent-based programming (some very early conception that led to OO programming) amounted to the same thingas far as the interpreter was concerned.
The next talk was by Erik Meijer, on “Functional Programming And Monads”. This talk was also very interesting. Basically, it was about how great, according to Meijer, the Haskell programming language is (http://www.haskell.org/haskellwiki/Why_Haskell_Matters). The speaker seemed to get a lot of stimulation out of boasting just how concise the language was and how natural it was for expressing stuff that you could write down in mathematical notation. That said, I found the idea of functionals (or higher-order functions) and the conciseness of the language to be quite elegant. I’m not sure how I would use such a language for solving general-purpose problems; I’d like to play around with it to see if I can bridge the gap between a language like Haskell and one like Java. How could I apply the way one thinks when programming in a functional language to coding in Java? If I did so, would that make my programs easier or harder to understand? By the way, Meijer claimed that you could also consider Haskell to be an OO language (if you wanted to).
A third talk in this track was “What mainstream OO can learn from SIMULA and BETA,” presented by Ole Lehrmann Madsen (http://tinyurl.com/jqjzd ). Madsen is a professor at the University of Aarhus, Denmark, and followed Nygaard’s work on Simula with a modern version called Beta. The thrust of this talk was basically that abstractions are important. Madsen stressed that point that it seems like we Java programmers are getting bogged down in very complex implementation and technical details. (How many common Java frameworks can you think of that actually simplify your work?) He explained that Nygaard didn’t come to write Simula from a computer science background, but rather, from the need for a general purpose modeling language (recall that Simula is basically the first OO language).
To quote Madsen, “Modeling was essential for SIMULA (originally designed to create simulation models). Programming was essential for executing the simulation models. Modeling and programming was in balance in SIMULA.” This message hit home with me because I feel that we’re suffering from a chronic lack of modeling — domain modeling — on our project. It’s as though we’ve unconsciously adopted the hacker’s credo: “The first duty of a programmer is to get away with it.” That said, Madsen isn’t saying that OO models reflect the real world exactly, but rather that an OO model can be a very good tool for conceptualizing a perspective on a real world domain.
I recommend reading over Madsen’s presentation slides. In reviewing them myself, it reminded me of another point he made in talk: it’s important to know the limits of the expressibility of the language you are using to model in. When you reach that limit, but don’t know it, you can get yourself swamped in complexity. On the other hand, if you know when you’re getting to the limits, you can adjust your approach and work around it. It’s difficult to truly express domain concepts in a programming language precisely and correctly enough for a computer to execute them.
When the language is going to fail to do so, trying to force one’s way through is like blathering jibberish. It’s preferable in such cases to reconceptualize the problem and express it in a way that works for the language, at the cost of using abstractions that aren’t as close to our real-world (and totally ambiguous) human language.