Summary:
In this article, which is based on Chapter 1 of the book,
Programming in Scala, you'll get an overview of the Scala language and insights into its design.
The ability to add new comments in this discussion is temporarily disabled.
Most recent reply: December 10, 2008 1:00 PM by
Jason
|
|
This article, based on Chapter 1 of the book <a href="http://www.artima.com/shop/forsale">Programming in Scala</a>, describes the scalable programming features of Scala: http://www.artima.com/scalazine/articles/scalable-language.htmlWhat do you think of the language features described in the article?
|
|
|
|
|
The language features sound great to me.
Can anyone comment on Rich Hickey's decision to make all values read-only in Clojure and how Scala compares in that regard? Does anyone believe that, paraphrased, "updatable values are the new spaghetti code", as Rich says? If no, why not? If yes, what does Scala do about it?
|
|
|
|
|
I can't say much about Clojure, but I do agree that state leads to spaghetti in most situations.
Scala allows you to have read-only, and writable fields called val, and var. I think it is normally suggested that you use val, (everything immutable) unless you have a really good reason for state.
My rather uneducated guess is that Scala allows for var because (hardcore functional programmers please don't kill me) it makes sense in some situations, and to ease Java programmers into functional programming.
|
|
|
|
|
scala sounds great.
the val (value) is like constant, var (variable) is nothing more than variable - it can change its value whenever.
|
|
|
|
|
> My rather uneducated guess is that Scala allows for var
> because (hardcore functional programmers please don't kill
> me) it makes sense in some situations, and to ease Java
> programmers into functional programming.
It definitely makes sense in certain situations to be able to use state, i.e. mutable objects. For example, if you have a queue that you need to modify it would be very inefficient to create a new queue every time you do an add or remove.
|
|
|
|
|
Looks like Scala borrowed a lot of concurrency constructs from Erlang rather than from Java. Now I am interested in Scala :)
|
|
|
|
|
Scala did borrow the actor model from Erlang, and built it on top of Doug Lea's fork-join.
|
|
|
|
|
actually scala borrowed a lot of things from many languages, it's a good blend :)
|
|
|
|
|
If I understand correctly:
1. The object composition pattern is a language feature in Scala. I imagine this would make a much bigger difference in scalability than combining object-oriented and functional paradigms.
2. Also exciting is the way Scala, like Smalltalk, is a small language with a big API, where operators have almost no special rules regarding lexical or syntactic analysis as they do in languages with far more complex grammars, such as Java or C#.
Hooray for Scala!
|
|