Martin Odersky talks with Bill Venners and Frank Sommers about the design motivations behind Scala's type system.

http://www.artima.com/scalazine/articles/scalas_type_system.html

What do you think of Odersky's comments on Scala's type system?

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 :-)

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.

> the languages we'd like to cover are Clojure, Fortess,
> NewSpeak, Fan, C# 3.0, Erlang.

I am looking forward to reading the interviews. A small suggestion - would you try covering F# which is roughly speaking Scala equivalent for the .NET platform.

> > the languages we'd like to cover are Clojure, Fortess,
> > NewSpeak, Fan, C# 3.0, Erlang.
>
> I am looking forward to reading the interviews. A small
> suggestion - would you try covering F# which is roughly
> speaking Scala equivalent for the .NET platform.
>
Yes, F# is on our list too. Sorry, the list I gave was off the top of my head and I had a nagging feeling I was forgetting one or two.

Mr. Odersky does a great job of explaining things on my level. Excellent interview!

When I started reading it I was kind of following him but when it got to the covariance and stuff discussion I started skipping it.

I am fairly addicted to dynamically typed languages in their Ruby and JavaScript forms and I am probably out of it when it comes to statically typed languages even when they try their hardest to work for more people as in Scala.

These interviews make for curious reading and after the editing work and whatnot they read quite fluidly. Thanks.

Having solved the type problem, it remains to be seen how Scala will solve the libraries and applications problems because I am fairly skeptical about how much easier it can make developing tons of applications and libraries that each can depend on each other but that also install and are used separately.

Say for example what RubyGems represents in Ruby-land or what JavaScript randomly loaded files represent in the JavaScript-land as in jQuery powered pages.

The answer to sharing code in Ruby has been made quite obvious since RubyGems came to be. The way for decoupling and sharing a module is "ship it in a gem!"

JavaScript has a little problem with scaling to larger applications but with the developments of libraries that help with OO inheritance, modules developments, and managing the dependence graph between files/modules be it a task that is run on the server-side from PHP/Ruby or on the client-side with YUI 3's on-demand module loading, that seems to be at least under development. Although folks also like using just a tad of JavaScript on a page by making use of jQuery for instance. So, on a site powered by jQuery, one can find lots of single pages that each make a little use of jQuery, and on the backend one can find PHP or some other technology also doing its piecemeal work.

When it comes to Scala entering said markets, just like on the question of Scala working for small (script) tasks just as for the big ones, I rather think that Scala is more principally targeted at the big ones which also means fewer applications and libraries in exchange for a solid experience.

If Scala had solved the issues of making "safe programming" a solved matter for every day developers, I am sure Microsoft would be all over trying to copy it. ;-)

So, in theory Scala could be used more generally, but in practice we will be talking about making Scala more popular for the foreseeable future, I fear.

And yeah, so much for the proud of making use of a solid base when your front-end is ActionScript, JavaScript, IronPython, IronRuby, JavaFX and C#. ;-)

> Martin Odersky talks with Bill Venners and Frank Sommers
> about the design motivations behind Scala's type system.
>
> http://www.artima.com/scalazine/articles/scalas_type_system
> .html
>
> What do you think of Odersky's comments on Scala's type
> system?

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

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

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 :-(


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.

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

This is a red herring, but I must ask Frank Sommers _please_ not to bring back those stupid expressions "programming in the small" and "programming in the large." It is perfectly adequate to say "Scala lends itself equally well to programs both big and small."

"Small" and "large" are adjectives, not nouns, and therefore are inappropriate to serve as objects of prepositions. I think the coiner of those phrases twenty-five or thirty years ago was obnoxiously arrogant to promote such an idiosyncratic grammatical form.

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

Too late! Too late! I just know someone is going to point out that the word "please" doesn't have underscores in. After that, it's only a matter of time before there'll be an pointless reference to some usage and history of the phrases, showing that they do not refer to "big" and "little" programs but have actual meaning in their own right.

Open University (http://www.open.ac.uk): Course M257 - Putting Java to work

Unit 2 - Java in the small

Introduction
"We have called this unit 'Java in the small' after a term coined by DeRemer and Kron in a 1976 paper. This refers to the programming of the internal parts of programs, in particular the contents of methods."

Unit 3 - Java in the large

Introduction
"Programming in the large is about specifying how the parts of our programs should work with one another, and object-oriented languages provide us with keywords that allow us to reason about how methods may be used, how data may be manipulated and how objects may 'communicate' with one another."

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