Questions about Scala from a Rubyist

Question

I have recently been looking around to learn a new language during my spare time and Scala seems to be very attractive.

I have a few questions regarding it:

1. Will not knowing Java impose a challange in learning it? Will it be a big disadvantage later on? ( i.e How often do people rely on Java-specific libraries? )

2. How big of a difference it is compared to Ruby? (Apart from being statically typed) Does it introduce a lot of new terms, or will I be familiar with most of the language's mechanisms?

3. What resources would you recommend? I have my eye on Programming Scala and Beginning Scala books

4. Although subjective, is Scala fun to programme in? : P

Thanks

Content

Answer 1

There are many concepts that are shared between Ruby and Scala. It's been a while since I've coded Ruby, so this isn't exhaustive.

Ruby <==> Scala (Approximately!)

• Mixins <==> Traits
• Monkey Patching <==> Pimp My Library (Implicit Conversions to a wrapper with extra methods)
• Proc/Closure <==> Function/Function Literal
• Duck Typing <==> Structural Types
• Last Argument as a Proc <==> Curried Parameter List (see Traversable#flatMap)
• Enumerable <==> Traversable
• collect <==> map
• inject <==> foldLeft/foldRight
• Symbol.toProc <==> Placeholder syntactic sugar: people.map(_.name)
• Dynamic Typing conciseness <==> Type Inference
• Nil <==> null, although Option is preferable. (Not Nil, which is an empty list!)
• Everything is an expression <==> ditto
• symbols/hashes as arguments <==> Named and Default Parameters
• Singleton <==> object Foo {}
• Everthing is an object <==> Everthing is a type or an object (including functions)
• No Primitives <==> Unified type system, Any is supertype for primitives and objects.
• Everything is a message <==> Operators are just method calls

Ruby's Features you might miss

• method_missing
• define_method etc

Scala Features you should learn

• Pattern Matching
• Immutable Classes, in particular Case Classes
• Implicit Views and Implicit Parameters
• Types, Types, and more Types: Generics, Variance, Abstract Type Members
• Unification of Objects and Functions, special meaning of apply and update methods.

Embank

Regular expression: /Cats(.*)/ <==> "Cats(.*)".r – Earache

Scala 2.9 will introduce scala.Dynamic, akin to method_missing. – Embank

Damn you Scala, you have won this Rubyist's heart! :) The deeper I look, the more magnificent it appears. – Dynah

and extractors... You don't want to forget about extractors! – Katherine

Answer 2

Here is my take on it:

• Never mind not knowing Java.

• Scala relies a lot on Java libraries. That doesn't matter at all. You might have trouble reading some examples, sure, but not enough to be a hindrance. With little time, you won't even notice the difference between reading a Java API doc and a Scala API doc (well, except for the completely different style of the newest scaladoc).

  Familiarity with the JVM environment, however, is often assumed. If I can make one advise here, it is to avoid Maven at first, and use SBT as a build tool. It will be unnecessary for small programs, but it will make much of the kinks in the Java-lang world easier to deal with. As soon as you want an external library, get to know SBT. With it, you won't have to deal with any XML: you write your build rules in Scala itself.

• You may find it hard to get the type concepts and terms. Scala not only is statically typed, but it has one of the most powerful type systems on non-academic languages out there. I'm betting this will be the source of most difficulty for you. Other concepts have different terminology, but you'll quickly draw parallels with Ruby.

  This is not that big of a hurdle, though -- you can overcome it if you want to. The major downside is that you'll probably feel any other statically typed language you learn afterwards to be clumsy and limited.

• You didn't mention which Programming Scala you had your eyes on. There are two, plus one Programming in Scala. That latter one was written, among others, by the language creator, and is widely considered to be an excellent book, though, perhaps, a bit slow. One of the Programming Scala was written by a Twitter guy -- Alex Payne -- and by ex-Object Mentor's Dean Wampler. It's a very good book too. Beginning Scala was written by Lift's creator, David Pollack, and people have said good things about it to. I haven't heard anyone complain about any of the Scala books, in fact.

  One of these books would certainly be helpful. Also, support on Stack Overflow for Scala questions is pretty good -- I do my best to ensure so! :-) There's the scala-users mailing list, where one can get answers too (as long as people aren't very busy), and there's the #scala IRC channel on Freenode, where you'll get good support as well. Sometimes people are just not around, but, if they are, they'll help you.

  Finally, there are blogs. The best one for beginners is probably Daily Scala. You can find many, many others are Planet Scala. Among them, my own Algorithmically Challenged, which isn't getting much love of late, but I'll get back to it. :-)

• Scala has restored fun in programming for me. Of course, I was doing Java, which is booooring, imho. One reason I spend so much time answering Stack Overflow questions, is that I enjoy working out solutions for the questions asked.

Exonerate

Answer 3

I'm going to introduce a note of caution about how much Java knowledge is required because I disagree that it isn't an issue at all. There are things about Java that are directly relevant to scala and which you should understand.

1. The Java Memory Model and what mechanisms the platform provides for concurrency. I'm talking about synchronization, threads etc

2. The difference between primitive types (double, float etc) and reference types (i.e. subclasses of Object). Scala provides some nice mechanisms to hide this from the developer but it is very important, if writing code which must be performant, to know how these work

This goes both ways: the Java runtime provides features that (I suspect, although I may be wrong) are not available in Ruby and will be of enormous benefit to you:

• Management Extensions (MBeans)
• JConsole (for runtime monitoring of memory, CPU, debugging concurrency problems)
• JVisualVM (for runtime instrumentation of code to debug memory and performance problems)

These points #1 and #2 are not insurmountable obstacles and I think that the other similarities mentioned here will work strongly in your favour. Oh, and Scala is most certainly a lot of fun!

Coinage

Answer 4

I do not have a Ruby background but nevertheless, I might be able to help you out.

1. I don't thing not knowing Java is a disadvantage, but it might help. In my opinion, Java libraries are used relatively often, but even a trained Java coder don't know them all, so no disadvantage here. You will learn some parts of the Java library by learning Scala because even the Scala libraries use them.

2. --

3. I started out by reading Programming Scala and turned over to read the source of the Scala library. The latter helped a lot to understand the language. And as always: Code, Code, Code. Reading without coding wont get you anywhere, but I'm sure you know that already. :-) Another helpful resources are blogs, see https://stackoverflow.com/questions/1445003/what-scala-blogs-do-you-regularly-follow for a compilation of good Scala blogs.

4. It is! As you stated, this is very subjective. But for me, coming from a Java background, It is a lot of fun.

Menado

Answer 5

This is very late, but I agree to some extent with what oxbow_lakes said. I have recently transitioned from Python to Scala, and knowing how Java works -- especially Java limitations regarding generic types -- has helped me understand certain aspects of Scala.

Most noticeably:

1. Java has a horribly broken misfeature known as "type erasure". This brokenness is unfortunately present in the JVM as well. This particularly affects programming with generic types -- an issue that simply doesn't come up at all in dynamically-typed languages like Ruby and Python but is very big in statically typed languages. Scala does about as good a job as it can working around this, but the magnitude of the breakage means that some of it inevitably bleeds through into Scala. In addition, some of the fixes in Scala for this issue (e.g. manifests) are recent and hackish, and really require an understanding of what's going in underneath. Note that this problem will probably not affect your understanding of Scala at first, but you'll run up against it when you start writing real programs that use generic types, as there are things you'll try to do that just won't work, and you won't know why unless/until you understand the limitations forced by type erasure.

2. Sooner or later you'll also run up against issues related to another Java misfeature, which is the division of types into objects (classes) vs. primitive types (ints, floats, booleans) -- and in particular, the fact that primitive types aren't part of the object system. Scala actually does an awesome job hiding this from you, but it can be helpful to know about what Java is doing in certain corner cases that otherwise may be tricky -- particularly involving generic types, largely because of the type-erasure brokenness described in #1. (Type erasure also results in a major performance hit when using arrays, hash tables, and similar generic types over primitives; this is one area where knowing Java will help a lot.)

3. Misfeature #3 -- arrays are also handled specially and non-orthogonally in Java. Scala's hiding of this is not quite as seamless as for primitives, but much better than for type erasure. The hiding mechanism sometimes gets exposed (e.g. the ArrayWrapper type), which may occasionally lead to issues -- but the biggest problem in practice, not surprisingly, is again with generic types.

4. Scala class parameters and the way that Scala handles class constructors. In this case, Java isn't broken. Arguably, Scala isn't either, but the way it handles class constructors is rather unusual, and in practice I've had a hard time understanding it. I've only really been able to make sense of Scala's behavior by figuring out how the relevant Scala code gets translated into Java (or more correctly, into compiled Java), and then reasoning over what Java would do. Since I assume that Ruby works much like Java in this respect, I don't think you'll run into too many problems, although you might have to do the same mental conversion.

5. I/O. This is actually a library issue rather than a language issue. In most cases, Scala provides its own libraries, but Scala doesn't really have an I/O library, so you pretty much have no choice but to use Java's I/O library directly. For a Python or Ruby programmer, this transition is a bit painful, since Java's I/O library is big and bulky, and not terribly easy to use for doing simple tasks, e.g. iterating over all the lines in a file.

Note that besides I/O, you also need to use Java libraries directly for other cases where you interact with the OS or related tasks, e.g. working with times and dates or getting environment variables, but usually this isn't too hard to figure out. The other main Java libraries you might need to use are

1. Subprocess invocation, also somewhat big and bulky
2. Networking -- but this is always somewhat painful
3. Reflection, i.e. dynamically examining the methods and/or fields on a class, or dynamically invoking a method by name when the name isn't known at compile time. This is somewhat esoteric stuff that most people don't need to deal with. Apparently Scala 2.10 will have its own reflection library, but currently you have to use the Java reflection API's, which means you need to know a fair amount about how Scala gets converted to Java. (Thankfully, there's a -print option to the Scala compiler to show exactly how this conversion happens.)

Monique

Answer 6

Re. point 1. Not being familiar with Java the language is not necessarily a problem. 3rd party libraries integrate largely seamlessly into Scala. However some awareness of the differences in collections may be good (e.g. a Scala list is not a traditional Java list, and APIs may expect the latter).

The Java-related skills that carry over are related to Java the platform. i.e. you're still working with a JVM that performs class-loading, garbage collection, JIT compilation etc. So experience in this is useful. But not at all necessary.

Note that Scala 2.8 is imminent, and there are some incompatible changes wrt. 2.7. So any book etc. you buy should be aware of such differences.

Colloquy

Answer 7

This is another late answer, having recently come to Scala myself, but I can answer 1, 3, and 4:

1) I ported a large, multifaceted F# project to Scala without any use of either Java or .NET libraries. So for many projects, one can stick totally to native Scala. Java ecosystem knowledge would be a plus, but it can be acquired gradually during and after learning Scala.

3) Programming in Scala is not only great for learning Scala, it's one of the few truly readable computer books on any language. And it's handy for later reference.

4) I've used close to a dozen different programming languages, from assembly languages to Prolog, but Scala and F# are the two most fun programming languages I've ever used -- by a wide margin. (Scala and F# are very similar, an example of "convergent evolution" in two different ecosystems -- JVM and .NET.)

-Neil

Unpen