May 28, 2009
May 27, 2009
Multimethod in Clojure: Should I call it first class Pattern Matching? or Pattern Matching in disguise?
from Rich Hickey on Clojure’s Features and Implementation
Clojure multimethods are just another level of that same logic, in fact they are a realization of the last sentence I just said. They are dispatch based upon an arbitrary function of the arguments. You define a multimethod and you say “Here is a function of the arguments I’d like you to use” You could look at the first argument, you could look at the 5th, you could look at all of them, you could look inside them, some member of an argument, it could look at the types or not or the values. Now, you could look at relationships between arguments, you have dispatch based upon an arbitrary function of the arguments and you have a vastly wider set of polymorphic possibilities than you had before and it’s quite powerful. In particular, it allows you to do Runtime dispatch on Runtime attributes. You don’t usually represent something like being hungry as part of something’s type, it’s some attribute that it acquires while the program is running or being outdated or things like that. Now you can access those things and you can do things polymorphically based upon that and take a lot of switch statements out of your code.
Should I call it first class Pattern Matching? or Pattern Matching in disguise?
May 8, 2009
Paul Hudak on Haskell
An interview I did with Paul Hudak that begins with a discussion of when to introduce difficult Haskell concepts like monads, moves to a discussion of the philosophy of higher order programming, the success and influence of Haskell, its use in the mainstream, and concludes with the idea of teaching computer music and Haskell simultaneously.
http://www.infoq.com/interviews/paul-hudak-haskell-Qcon-SF-08&language=en
Data, Context and Interaction : a new architectural approach by James O. Coplien and Trygve Reenskaug
James O. Coplien and Trygve Reenskaug have recently introduced a new architectural approach to OOP based on Data, Context and Interaction pattern. It should allow capturing user mental model in terms of behavioral requirements, something that classic OOP fails to do. The article, that triggered many reactions and critics, provides insights into DCI using concrete examples to show its advantages.
May 4, 2009
Yet another million dollar mistake?
Martin Odersky:
In the generics design, there were a lot of very, very hard constraints. The strongest constraint, the most difficult to cope with, was that it had to be fully backwards compatible with ungenerified Java. The story was the collections library had just shipped with 1.2, and Sun was not prepared to ship a completely new collections library just because generics came about. So instead it had to just work completely transparently.
That’s why there were a number of fairly ugly things. You always had to have ungenerified types with generified types, the so called raw types. Also you couldn’t change what arrays were doing so you had unchecked warnings. Most importantly you couldn’t do a lot of the things you wanted to do with arrays, like generate an array with a type parameter T, an array of something where you didn’t know the type. [..]
When Java first shipped, Bill Joy and James Gosling and the other members of the Java team thought that Java should have generics, only they didn’t have the time to do a good job designing it in. So because there would be no generics in Java, at least initially, they felt that arrays had to be covariant. That means an array of String is a subtype of array of Object, for example. The reason for that was they wanted to be able to write, say, a “generic” sort method that took an array of Object and a comparator and that would sort this array of Object. And then let you pass an array of String to it. It turns out that this thing is type unsound in general. That’s why you can get an array store exception in Java. And it actually also turns out that this very same thing blocks a decent implementation of generics for arrays. That’s why arrays in Java generics don’t work at all. You can’t have an array of list of string, it’s impossible. You’re forced to do the ugly raw type, just an array of list, forever. So it was sort of like an original sin. They did something very quickly and thought it was a quick hack. But it actually ruined every design decision later on.
