Hi Mr. Brandybuck,

> I don't really have to say much about the past couple of
> scala interviews except that these kinds of talks are
> exactly the reason I started reading Artima a lot and
> recommending it to friends. I'm glad to have this sort of
> interview back. It's been a while.
>
> Thanks Bill. Good stuff as always :-)
>
Great to have you back. I also felt the interviews were the heart of Artima, but for a long time I just couldn't afford the time to do them. They are very time consuming to create, because they involve a lot of preparation, and a lot of post editing. But our plan is that this series with Odersky will be the first of a bunch of interviews with language designers. On the JVM and off, there is a sort of "renaissance" of language design going on. Some of the languages we'd like to cover are Clojure, Fortess, NewSpeak, Fan, C# 3.0, Erlang. I'd also like to do some non-language ones, such as on domain driven design, process patterns, "clean code," etc. There may be a break between each series, but we'll try to keep that small.

>
> I think he has a clearly biased point of view with regards
> to dynamic checking (AKA dynamic typing), and miss the
> point with "Typically the annoying parts are type
> definitions that are redundant, which require you to do a
> lot of (finger) typing."
>

I would say he is biased (sounds like you are, too), has his preference, use whatever words you want, but I thought he had a lot more to say about it than 'finger typing is annoying'. The article mentions many of the deficiencies with the sort of strong static typing people are used to that are overcome by the use of pattern matching and Scala being able to infer types without explicit declaration. I was pretty sure he got the point and did a decent job explaining his position. That his position doesn't jive with yours doesn't mean he missed the point. He just doesn't agree. Honestly I think it is nice to see an opinion that isn't so 'mainstream' for lack of a better word. So much has been written over the past few years about the benefits of dynamic typing. It's nice to see something different and has a bit more in depth explanation than 'my typing preference is good, all others are bad'.

> He's missing the strengths of dynamic typing
> (heterogeneous collections, the ability to write code that
> only fulfill the relevant parts of a contract, and the
> ability to synthesize reasonable behavior at run time,
> effectively fulfilling a contract without having a full
> set of methods at compile time).
>

I thought the whole section on 'quacking like a duck' covered this pretty well. The result doesn't appear to be as fluid as what you would get in a full blown dynamic language, but it gets you most of the way there and for most use cases it sounds better than good enough to me. And for people that prefer static typing, they get to have their cake and eat it too.

> He's also missing the primary problem with the redundant
> definitions: It is not the amount of finger movement
> necessary - it is that the type declarations interrupt the
> flow of both writing and reading code.
>
> I had examples for the benefits of most of this, but
> Firefox crashed and took my message with it :-(
>

Personally in a lot of cases I find that they help when reading and get in the way when writing. There are plenty of examples that you can use to go both ways. For favoring static typing imagine that you have a cowboy class and a shape class. Both have a method Draw, but obviously they would do different things. In many cases this would be important and if I see something called Boots.Draw() am i looking at a boot shaped thing that is going to get drawn on the screen or is Boots going to pull a gun and put a bullet in my belly?

>
> Apart from that, I found it an interesting article - the
> thought about orthogonality around types/methods/variables
> passed as parameters and inherited was new to me.

> He's missing the strengths of dynamic typing
> (heterogeneous collections, the ability to write code that
> only fulfill the relevant parts of a contract, and the
> ability to synthesize reasonable behavior at run time,
> effectively fulfilling a contract without having a full
> set of methods at compile time).
>
> ...
>
> I had examples for the benefits of most of this, but
> Firefox crashed and took my message with it :-(
>
I wish it hadn't. What's a legitimate use for heterogeneous collections? I can think of, say, http request arguments (though they're really all just strings at that level), or other properties/preferences containers.

I know I've had a need for it before, but I can't think of a compelling example off the top of my head. The favorites example used to show the technique in _Effective Java_ isn't compelling to me.

Must.. not.. let.. grammar police... hijack.. thread...... Must... resist... comment.... ugh....

> "Small" and "large" are adjectives, not nouns,

Yes, they are ...

> and therefore are inappropriate to serve as objects of
> prepositions.

Yes, they are ...

(hairsplit)
But they aren't nouns in this case. The nouns of this sentences are actually missing. Somehow cut off ... ay.

It should read: Programming in the small [problem space of tasks leading to use-once scripts] and programming in the large [problem space of architecture centric enterprise applications]
(/hairsplit)

BUT: What I really wanted to say is that I really appreciate this interview series, as they talk easily about problems of understanding I had when reading other texts.
Don't know, it seems that here somehow a necessary background is given. Not so much a "theoretical" background as more like links and connections that shine through, which I haven't grokked earlier.

Thank you