In this article, you'll follow twelve steps that are designed to help you understand and gain some basic skills in the Scala programming language.

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

What do you think of Scala?

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.

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

Morel Xavier wrote
> Only one lazy functional language is even remotely
> widespread (Haskell, Miranda is also lazy but one can't
> say it's "widespread") ...

Clean also.

http://clean.cs.ru.nl/About_Clean/Clean_Language_Features/clean_language_features.html

Nice article guys! It's really nice to see Scala being introduced in this extent here at artima! Keep up with the good work.

This is really a great intro. I wish I had this when I was first trying to figure things out (not that I've figured it all out.)

Keep up the good work and thanks.

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

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

Good, lucid introduction overall. I still don't understand the order in which Scala calls the various overridden methods it inherits from its traits and superclass. I can't extrapolate from the exclamatorygreeter mixin example to understand how the chain would be resolved in general. Care to elucidate?

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 find I need to say Console.println("Hello") vs println("hello") as described in the article.

scala> println("j")
<console>:4: error: not found: value println
val line3 = println("j")



What am I doing wrong?

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

All the Scala tools accept -version. Since you usually should not care about the version so much, I am going to leave out the Pythonic display of the version at every invocation.

$scala -version
Scala code runner version 2.5.0 -- (c) 2002-2007 LAMP/EPFL

Anyway, doesn't the -> version look nicer? Identifiers are not in short supply, so I don't see why there should be any effort to conserve them, unless....

Ahh, maybe it appears to Artima readers to be a special case in the syntax. It is not. -> is just an operator, which in Scala can be used as a method name.

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.