> Personnaly, I like Scala, it looks like a very cute
> development effort. But I have to admit that hybrid
> languages aren't likely to have any future — they lack
> lazyness that is vital to the success of functional
> language.

I fail to see how lazyness (as a core semantic of the language) is "vital" to functional language. Only one lazy functional language is even remotely widespread (Haskell, Miranda is also lazy but one can't say it's "widespread"), the vast majority of functional languages follow a strict evaluation model (pretty much every Lisp dialects, pretty much every ML dialects and derivatives including SML and OCaml, Erlang, ...) with the potential ability to include local lazyness (Scheme, D, Nemerle).

Not to mention that lazy evaluation still has huge execution-time and memory behaviour issues (which lead to the introduction of strict-evaluation operators and variants in Haskell for optimization purposes...)

Urgh it seems I had the wrong version. Scala 2.5RC doe sindeed have the "println" construct.

It would be nice if the scala interpreter could output the version number.

something like ...

$python
Python 2.5.1c1 (release25-maint, Apr 12 2007, 21:00:25)
[GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>

The details are in the spec.

http://www.scala-lang.org/docu/files/ScalaReference.pdf

By the way, this spec is readable as specs go. There is a ton of detail, but it is meant to be readable, not to be leverage for lawyers.

Anyway, the rule is that inherited classes and mixed in traits get linearized. Message sends invoke the first class/trait in the linearization that has a matching method, and super calls work their way up through the linearization. The precise linearization algorithm is in the spec, but it is an intuitive one IMHO.

Note that with this rule, you can evaluate all of the methods by simply chaining "super" calls. If the first method invokes "super", and so do all the others except for the last, then you will end up invoking each method one time. This pattern is practically impossible with multiple inheritance, and is awkward with the original traits from U. Berne.

> Great introductory article.
>
> A question about the map examples. What is it about method
> -> that is better than just defining the
> tuple? I mean, why is (1 -> "value") better
> than (1, "value")?

Good question. The only thing I can think of is that you could perhaps override the -> method, if that's allowed. Not sure that would be a good thing, though.

One advantage of the -> method is that brackets are not required (unlike the example in the article). This makes the syntax a lot more readable: e.g.

val romanNumeral = Map(1 -> "I", 2 -> "II", 3 -> "III", 4 -> "IV", 5 -> "V")

versus

val romanNumeral = Map((1, "I"), (2, "II"), (3, "III"), (4, "IV"), (5, "V"))


I am a long time C / Java programmer. Never used any functional languages, (well, I did use LISP very briefly many many years ago) most of this is new to me. Perhaps this ignorance shows in my (admittedly somewhat cynical) comments below.

Overall, I love the fact that Scala runs in the JVM and I can import familiar Java classes. (And, I assume, 3rd party jars such as Apache) The parts work, I can use Eclipse, I'll almost certainly give Scala a try. But I have a lot of quibbles with the syntax. IMO, they got too creative / cutesie.

You define an object as Singleton by calling it, DOH, object. Why not use the term "singleton"!

If :: is pronounced "cons", why not type it as cons? Geez, its all of 2 extra characters. And it's clearer - I see "cons", I wikipedia LISP, and I get a lot of info on what it means, plus links to cdr, etc... And it's less likely to get confused with :::. A common programming bug in confusing = and ==, why design in :: and ::: which are visually even closer?

treasureMap += 1 -> "Go to island.";

for adding to a map is truly the most disgusting syntax ever. This is almost enough to make me writeoff the language. BTW, this syntax is longer than Java's

treasureMap.put(1,"Go to island.");

I'm extremely leery of syntactically important white space which seems common in Scala (if I'm understanding some of these alternative syntaxes right).

"Sometimes the Scala compiler will require you to specify the result type of a method"

I saw something like this in another article about variables. leave off declarations till it complains and you learn better. So you "save" typing and are ultra efficient by leaving off "int" or "void", but then you waste time when the compiler complains. Call me a sceptic.

BTW, they should use void for void, not "unit". What the heck is unit?


Finally, about all the functional parts. Will somebody please please post a useful example other than printing an array of strings? When the key benefit of FP that 1000s of posts of Artima are demanding be added to Java is the ability to go


args.foreach((arg: String) => println(arg))


instead of


for (String arg : args)
System.out.println(arg);


I am, well, completely underwhelmed.