I'll try to comment more once I collect myself, if I ever do.
Scala blends functional and object-oriented programming into one language, which runs on a JVM, interoperably with Java. Why functional programming (FP)? What's functional programming? Here's an interesting summary - Functional Programming for the Rest of Us.
Update (Apr 9, 2008, 10:40 am Central): Here's an excellent audio overview by one of the authors of the book Programming in Scala (whom I had the privilege of mountain biking with in August 2001 at Crested Butte, Colorado, while attending a week-long seminar on Design Patterns he and Bruce Eckel taught) This introduction, which I just listened to, includes most all the key points I mentioned to a friend of mine in an enthusiastic conversation yesterday evening. Venners captures much of the unrest in the Java community that I have sensed over the past several years. He captures well my own hesitation to jump into Ruby, Python, and Groovy as solutions to this angst and my immediate determination that Scala is it, the language we've been waiting for - Bill Venners on the rise of Scala
Update (Apr 28, 2008, 2:10 pm Central): I've read Programming in Scala cover-to-cover, and I'm still gaga.
My guess is that Scala is "it", the language that will supercede Java, more speedily if it markets itself like Spring, by putting forward the Actor library as the entry point and not forcing people to adopt everything all at once, given its interoperability with Java.
X10 is also interesting. Might Scala adopt x10's notion of a clock? Perhaps there'll be some sort of interoperability between X10 and Scala, or even a hybrid. I imagine Lex Spoon has some things to say on this matter, having been involved with both projects. Indeed, I see from Spoon's CV that he "assisted with the ongoing design of X10, a language for high-performance computing, both in its pure form and with a Scala-like front-end."
I have questions about Scala's classloading and security. Do they differ from Java's?
Update (May 9, 2008, 1:50 pm Central): Odersky, Spoon, and Venners published a new version of their Pre-Print edition this last Sunday, May 4. And what do you know? They added a new section on clocks in chapter 30 "Actors and Concurrency". I'd like to think one of the comments I had submitted to them online sparked this addition, but I don't know. I read it yesterday. It's great.
Update (May 9, 2008, 5:52 pm Central): Here's one small example of some code in Scala that speaks to its power. It's based on an example from the book.
val name = "Agent 99"
val nameHasDigit = name.exists(_.isDigit)Here the
String type is implicit in the first line, but it could be spelled out explicitly, along with a semi-colon at the end of the lineval name: String = "Agent 99";In the second line, the method
exists applies a boolean function to a sequence of objects, returning true if at least one of the results is true. Since name is a string not a sequence, it's implicitly converted to a sequence of characters. The function is described by a function literal, but it could have been defined using the symbol f with some code like thisdef f(ch: Char): Boolean = ch.isDigit();
val nameHasDigit: Boolean = name.exists(f);def f(ch: Char) = ch.isDigit
val nameHasDigit = name.exists(f)Details, details, details...
A function literal, by the way, is also known as a predicate when it returns a Boolean, as
_.isDigit does above.One detail. If you already know Scala, can you find the error in my expanded pedagogic code for defining the function
f?In Scala, there is a coding convention for differentiating between commands and queries (see Bertrand Meyer's writing on the Command-Query Separation principle). Queries return information without causing "side-effects". Commands change objects. The convention in Scala is to only include empty parentheses when the method has side-effects. When it returns information without changing things, returning say a conceptual property of an object, then it's a query, and, again in the spirit of Bertrand Meyer's writing, in this case on the Uniform Access principle, the parentheses are removed. That's the Scala convention.
If the code defining the method specifically omits parentheses however, then this isn't optional. It's enforced, as in the case of
isDigit. You'll see a compile-time error if you try to call the method with empty parentheses. I also didn't mention that
scala.Char is implicitly converted to scala.runtime.RichChar, behind the scenes. Implicit conversion makes for more intuitive, succinct code. It also allows you to wrap code from pre-existing libraries using traits. Traits are akin to Java interfaces, however they can include concrete implementations, and so they're mixins.Another detail - the implicit conversion for
exists actually requires an Iterable. A sequence is, more precisely, a Seq, a subtrait of Iterable. The conversion is made from String to a RandomAccessSeq, a subtrait of Seq, by one of the implicit conversion functions in a singleton object called Predef, where many such common conversions are defined. In Scala, by the way, in addition to defining a
class, you can define an object, which is just a singleton. You can define a class and an object using the same name, in which case the object is the companion object to the class. So every Scala class can have an associated singleton object.Update (May 13, 2008, 8:15 pm Central): I noticed an announcement for the first meeting of a new Scala User Group for the San Francisco Bay Area. It's scheduled to meet at this very moment. Wish I were there. Maybe their next meeting, or the meeting after that....
Here in Minneapolis, I hope to meet other Scala users at the OTUG meeting next week, where Ted Neward is making a presentation - The Busy Developer's Guide to Scala
The Java platform has historically been the province of object-oriented programming, but even Java language stalwarts are starting to pay attention to the latest old-is-new trend in application development: functional programming. In this lecture, Ted Neward introduces Scala, a programming language that combines functional and object-oriented techniques for the JVM. Along the way, Ted makes the case for why you should take the time to learn Scala — concurrency, for one — and shows you how quickly it will pay off.So far I only know one other programmer in the Twin Cities who's interested in Scala, and I had a coffee klutch with him yesterday evening on the subject. It'd be great to get a Scala User Group going here, starting with some of the attendees of Neward's talk.
