jducoeur | Scala By Example

For serious programmers: I've been gradually reading into the language Scala for the past few weeks. Having just finished the online book Scala by Example (PDF, about 150 pages), I commend it as a fine read, for language geeks or simply programmers who want to expand their repertoire in useful ways. It's one of the better languages books I've come across.

It's written by programmers for programmers -- anyone who doesn't have pretty good depth in the subject will just be left at sea. But if you're an experienced software engineer, it's a neat read. Rather than trying to be orderly and complete, it instead presents a series of chapters, each introducing a major concept in Scala with relatively rich examples. It doesn't waste time on the basics: most chapters are focused on things that are really different from conventional languages like Java or C#.

It's gone a long ways towards convincing me that I want to migrate much of my development over to Scala. My original motivation had simply been the desperate crying need for a functional language -- I use functional techniques a *lot*, and emulating functional programming in Java is an awkward and bulky pain in the ass. But in practice, I find myself very attracted to a lot of Scala's other capabilities. For example, it rather casually (in Chapter 3) describes Scala's capabilities for working with Actors and Messages -- essentially, by adding a single library, it gains the core functionality of Erlang, while not being as irritating and limited a language as Erlang. Given that I'm increasingly suspecting that the Erlang-oid message-passing approach is probably the way CommYou *should* work internally, this is very tempting, and I may start experimenting with it.

Better yet, the book drives home the language's meta-programming facilities. A lot of the examples are of the form, "Here's a useful language feature -- and here's the code that implements it". Indeed, the book ends by returning to its start, building up from a few synchronization primitives to demonstrate how to implement a simplified version of the Actor functionality.

I'm quite taken by the whole thing: Scala looks to be a very good language. It has Ruby's intense object-orientation, without Ruby's syntactic quirks and weak threading. It has Erlang's message-passing, without Erlang's lack of OO. It has more or less complete interoperability with Java (within reasonable limits: if you define classes that go beyond Java's semantics, you may not be able to access them), and access to Java's full libraries, but adds all the things that Java is lacking such as functional programming.

So I'm going to investigate it more seriously: I'll try installing it and migrating some CommYou systems over to it. More reports on that as it goes...

Flat | Top-Level Comments Only

Good stuff to know; I'm taking a look myself.

Any idea about the performance hit (if any)? Always my worry with 'fancier' languages.

Edit: Neat. They have an IDEA plug-in. I'll just do some testing, then...

Edited 2009-01-03 21:07 (UTC)

I know that the performance is considerably worse than pure Java; how much worse in practice remains to be seen. The Debian shootout seems to indicate a typical overhead of 2-5 times, with a few outliers -- that's sort of "eh" by my lights: slower than I'd like, but not horrifying. It appears (by the same benchmark) to beat most other alternatives (eg, Ruby, Python, Erlang, Perl) by wide margins.

I suspect it's worth it to me if it improves my productivity. Moreover, it's leading me down some interesting paths: I'm seriously considering a severe rearchitecting of CommYou in ways that would be considerably easier in Scala than in Java (based on the Actor model). So I'm taking it quite seriously. (Not to mention that this architecture would probably be *much* more effectively multi-threaded than I could easily manage in pure Java...)

If it is named after Flaminio Scala, then perhaps I should look at it too.

Sadly, doesn't appear so...

Hmm. Fairly conventional ideas, it looks like so far, but selected and composed in a more judicious way than in many extreme languages. I've gotten jaded about new languages, but I might play around with this one. I like that they ground the functional paradigm, which I quite like in the abstract, with a sense of the necessities of state persistence in real world applications.

(Of late, the more I delved into lambda structures, the more I realized that a truly functional language cannot produce functioning applications, because interaction is always a side-effect.)

The thing I like about it is that it clearly doesn't see itself as an extreme language. It doesn't really have a Theme Goddammit, as so many do. (Ruby is OO Goddammit; Erlang is Messages Goddammit; Groovy is Dynamic Goddammit; even Java is OO Goddammit to the point of deliberately refusing functional capabilities; etc.)

Scala, by constrast, seems to take a very pragmatic approach of picking and choosing the best aspects of all of these (as well as ML and a few other sources), while trying to keep clean abstractions for them under the hood. That appeals enormously: I've gradually lost all respect for the notion that any single paradigm covers all the bases, and this seems to be one of the better multi-paradigm languages. It's not trying to be novel, it's trying to be *useful*.

So for example, as you say, they support functional decently well, but don't force pure-functional on you. And while they do force OO on you, they provide the "object" alternative as a first-class concept of singletons for when that's what you really want. All terribly pragmatic, and I'd much rather have a pragmatic compromise rather than a religion...

Hmm, I like the handling of generics, too, but I just read the bit on parallel processing constructs. I hadn't realized how similar their approach was to Fortress's, though I guess that explains why the latter is currently built using the former...

Not another bloody language! ;)

I've toyed with Erlang; I'm still not convinced a pure functional language is the solution. At the same time, lambda methods are amusing me more and more when I have to deal with lists ( or Lisp? )

I found myself playing with Python again this weekend, only using more functional stuff because it's on my mind. Actually, more of the list comprehensions that seem lifted from Haskell.

I enjoy a lot of Python, except that "data type as you go" crap that so many newer languages seem to think is useful...

Wait! Scala looks like Python Java fusion. All those little defs in defs with typesafe declarations? I think I may have to play with this. Damn.

And thanks. :p

You're welcome.

You have to keep in mind, there aren't *that* many ideas out there -- all of these languages are picking and choosing from a fairly limited pool of core concepts. The differences come in which ones they pick up, and how cleanly they combine them.

Scala appears to do better than most. Erlang's pure-functional basis is cute, but IMO too annoying and limited. I like OO, and find it very useful in many circumstances. (And I find mutable state *very* useful, albeit dangerous.) Python's generally good, but it has all the strengths and weaknesses of a dynamic language. (And a fairly quirky syntax.)

So I wouldn't quite call Scala a Python/Java fusion. Rather, it's drawing on some of the same roots as Python (notably the functional work that's been done in the ML family of languages) and designed to run cleanly on the JVM. Also, it's a static and strongly-typed language where Python (IIRC) is a dynamic and loosely-typed one, which makes it faster and more type-safe. It doesn't *look* as strongly typed as Java, but that's only because it's using type inference to automatically suss most of the type declarations for you...

I think Python is dynamic and strongly typed.

>>> 5 == "5"
False
>>> a = 5 
>>> a = "5"

Agreed. The real issue is the dynamic part. I like my type mis steps to be caught at compile time, rather than run time. It's really one of my only gripes with the language.


>>> def test(foo): print foo, "\t", str(type(foo)).split("'")[1]
... 
>>> test(5.0)
5.0 	float
>>> test("5")
5 	str
>>> test(5)
5 	int
>>>

Understood. I am a fan of dynamic typing, but hell, I work in Javascript half the time, so... :)

Well, that doesn't describe strongly typed -- indeed, that's clearly *weakly* typed from your example. A strongly-typed language like Scala wouldn't allow a to be reassigned to a value of a different type. In general, "strongly typed" means that a given variable is necessarily assigned to exactly one type. I believe Scala would have thrown an error on the last line, as would any strongly-typed inferential language.

(At least, that's the definition of strongly typed I've always seen. I know only a few languages that are *so* loose that they would return true on your first line...)

Wikipedia says (http://en.wikipedia.org/wiki/Type_system#Strong_and_weak_typing):

"Weak typing means that a language implicitly converts (or casts) types when used.

>>> 5 + "37"
Traceback (most recent call last):
  File "", line 1, in 
TypeError: unsupported operand type(s) for +: 'int' and 'str'

is used an example of strong typing. However, it also says:

"these terms have been given such a wide variety of meanings over the short history of computing that it is often difficult to know, out of context, what an individual writer means when using them." -- Strongly Typed Programming Language (http://en.wikipedia.org/wiki/Strongly-typed_programming_language)

So... we're probably both right :) To me, the 'dynamic' means that the latter succeeds, and the 'strong' means that 5+'37' or 5 == '5' don't work.

Scala By Example

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject