The woman, who is also a programmer, criticized her husband for not coming home with THIRTEEN gallons of milk.

Thanks for the link.

Insightfully said, Anonymous Coward.

You are correct of course, Anonymous Coward. Thinking of Ruby as a Smalltalk dialect is obviously more metaphorical than literal. And actually, Matz himself has remarked that he accepts the comparison of Ruby to Smalltalk as a compliment.

Thanks for replying, phantomfive. Obviously I did not express my question clearly enough.

Lisp is not statically typed, and it's therefore a very different sort of language than Scala. There are interesting dialects like Racket, which allows you to "turn on" some type checking, and like Qi, which I didn't previously think of as an OO language. At least, you have given me something to think about.

ljw1004, Javascript is not statically typed. But, your suggestion of OCaml is a thoughtful one. I am not aware of how well a feature like Type Classes fits into the language. My suspicion is that they are more cumbersome than in Haskell or Scala, but it's an interesting thing to explore.

phantomfive, You have responded with a bit of vitriol that surprises me.

Can you please cite other examples of mainstream statically typed languages that are both OO and Functional? I ask this not to insist that no others exist, but rather to further engage you, and try to understand where you are coming from.

Actually, no. It's not about modifying the syntax. It's about bringing some very exciting ideas from research into Dependent Object Types into a mainstream language.

No, I am quite certain that language designers respect Scala. Consider Peter Van Roy, for example, who is a leading expert on programming languages, and the co-author of a very influential book on programming paradigms. He highly recommends Scala.

Yes, compiler performance is an honest complaint from in-the-trenches Scala programmers, but that's a far cry from the "Scala is a joke" headline you use. If it were really a joke, then how could it continue to be used in the large scale applications of which you speak?

It depends on what we mean by "popular". If popular means that more lines of Scala are being written than Java, then, no, Scala is not popular.

But if we mean that the Scala programmers are in demand, then yes, Scala is popular.

I am certainly an advocate of lifelong developer training and code reviews. But consider this. If a language permits these sorts of == vs equals errors, then perhaps that's a defect in the language design itself.

Groovy is not really very simple. But more importantly, it's not a simpler Java at all. Since Groovy is dynamic and Java is static, they are completely different languages that bear a superficial syntactic similarity.

You are correct. I believe that the Pizza language, which became Java generics in the Tiger release, was designed by Martin Odersky. Type erasure in Tiger was deemed necessary for backwards compatibility with Java 1.4 code.

And consequently, Scala has type erasure for interoperability with Java. IIRC, James Gosling wanted many features like generics in Java, but couldn't get them into the language without slipping Java's release date. It's sad that a modern language like Scala still suffers from this twenty year old decision.

However, Scala also has Manifests, which address some of the weaknesses imposed by type erasure. It's good to shake the dust from our sandals.

Well said. Of course, Professor Odersky *is* a language expert/theorist, and Scala already makes a real difference. Its successors may well continue to do so.

What's so fascinating about Scala is that the blending of OO and Functional ideas into a Modular language is (1) possible, and (2) innovative. There's an orthogonality of Scala language features (something Stroustrup strove for in C++) that allows for some real surprises. For example, Implicits make Type Classes possible very elegantly. Scoped type classes turn out to be an emergent language feature, which didn't have to be baked into the compiler.

Perhaps, but why should there even be an == operator for objects? This is not a flippant question, but a deep language design question. It may be the case that Java's decision to expose == introduced too much opportunity to get things wrong. It's possible to imagine a more robust language without such an operator. Just as it is possible to imagine one without null, which would surely be better.

Java has changed many times, with careful thoughts to backwards compatibility at the source level. But it's a verbose beast, living in the uncanny valley between dynamic languages and languages with type inference. So, Java essentially has many of the hassles of static typing with few of the benefits.

There hasn't been as much Scala written as Java, and it may never catch up. But I'm sure that the Scalaists care about backwards compatibility, too. There's already too much Scala written for there not to be a "flap." But somehow I think even breaking changes in Scala will be tolerated if they make the language more pleasant. The research being done right now on dependent types is just too exciting.