On a whim, I flew through Programming Scala this weekend. I’ve had the book for a while, and actively tried to read it before. But this time, it stuck.
All the ideas in Scala are fascinating for a language nerd. It’s the best instance I know of, so far, where ideas from object-oriented and functional programming are combined intentionally and at-scale to produce a language that developers are using on a day-to-day basis. For a language nerd like me, it’s fun to see how all those ideas play out together.
That said, there is a lot of language lawyering. Having to write a chapter on scoping and public/protected/private rules in OO seems like a demoralizing thing for the authors to tackle. And all those hybrid OO/FP ideas come at a conceptual cost; it seems like there’s a lot to know. I’ve noted before that I’m very interested to see how Scala does in the marketplace of minds. It’s a very large language, but I think it’s large in a way that is already familiar to developers. So it could end up that Scala isn’t a great beginner language, but is fine for someone who already knows one FP and one OO language.
I should note that this isn’t my first Scala rodeo. I’ve tried, at various times, to tinker and hack on little projects or simply to grok other people’s code. The blocker on these previous attempts is that I, personally, am sbt-challenged. Whenever I’ve tried to compile projects or add dependencies to my own, I end up in an sbt-shaped trough of disallusionment. Part of this is my ongoing war of attrition with Maven. Part of this is, well, I’m not sure yet. I should note that I can mostly make leiningen, also Maven-based, work. So it’s not entirely Maven’s fault.
Most interesting to me is that Scala could have the versatility of Ruby, wherein one can grow a program from a script, to a message-based program, to a hybrid OO/functional system, to a multi-machine distributed program. You can’t say this about other JVM languages like Java or Clojure. The JVM is a gift and a curse. It makes Scala and Java impractical for scripts, due to startup time. But once your program is somewhat grown-up, Hotspot and the JVM’s excellent concurrency features come in quite handy.
More specific to the book, it cleared up some ideas I’d previous found confusing:
- What’s a method call/operator overloading? It’s an object, a dot or space, and then a method/operator name.
- Implicit methods/views; if you declare methods with the
implicitkeyword and they have the right type signature, the compiler will use them to coerce objects to your own types, giving you many of the benefits of something like Ruby’s open classes - How functions, maps, and ad-hoc data structures that are typical in Ruby map to actual types in Scala; lots of things get converted to
FunctionandTupleobjects by the compiler, which makes sense when you think about it in an ML-ish everything-is-strongly-typed way. - Internal DSLs feel weird, but parser combinators for external DSLs seems like it would be great.
- for-comprehensions; I guess I’ve read enough about them in Clojure now that they make sense in Scala. It’s worth noting that Scala’s for-comprehensions feel simpler than Clojure’s.
- Self-type annotations; I’ve seen this all over in Scala code and didn’t quite understand what was going on. It sure does have an odd name.
And some things are still confusing to me:
- Type bounds, variance; when will I need these?
- Linearization of object hierarchies; rules, I don’t like learning them!
- Tail-calls/trampolines; the JVM makes this a headhurt.
- Path-dependent types; not sure when I’d really need this, but it’s good to know about.
- Anything that’s a band-aid over type-erasure; again, the JVM is sometimes a headhurt.
I don’t have any projects that imminently need the things that Scala provides. Further, I think imposing Scala on a team that’s already succeeding at Ruby or Python is a stretch. You have to be in a place where you really need low, predictable latencies to accept the tradeoff of working with a much larger language.
That said, it’s totally a reasonable choice as a way to get yourself onto the JVM; if Clojure isn’t your thing, Scala probably is. Even if neither are your thing, don’t be a wuss; read some code in either language and expand your mind to reduce your headhurt.
Adam Keys is typing 
What does sbt mean?
It’s scala-build-tool, a project automation gizmo for Scala.
sbt stands for simple-build-tool, not scala- ;)
Thanks, Piotr!
on JVM, besides Scala and Clojure, there’s also Groovy, also JRuby is very promising
`time scala -e ‘println(“Hello World”)’`
I get 0.5s of real time. Not disputing the statement about scripting. You wouldn’t want to write a loop over hundreds of files using a scala script with stdin piped to it.
Just compiling “script sized” programs and starting them is actually very reasonable though. At least compared to JRuby. You’d be pleasantly surprised at just how quick starting up the JVM can be if that’s your frame of reference (it was for me, I realize Adam has a lot more Java baggage. ;-) ).
Otherwise this seems pretty fair to me. One clarification though? If you’ve read “Scala for the Impatient” you’ll run across Odersky’s idea of Application Developers vs Library Developers. I think a lot of the more mind-bending stuff is actually on the library side. IOW, I can’t imagine a lot of cases where you’ll need to worry about writing your own generics and consider co/contra-variance if you’re currently a Rails developer and are considering Play. You’ll be writing mostly the same sort of code outside of a few neat additions.
Twitter’s Scala School actually explains that one very nicely IMO: http://twitter.github.com/scala_school/type-basics.html#variance
So as a beginner, one of the things I like most about Scala is it’s familiarity as a Rubyist. map, collect, case statements (on steroids: match), it’s all there. For the most part. In day to day Application developer mode anyway. But then there’s also lots of neat new toys to play with. I can treat match as a case-statement, but I can also learn how the magic works and write my own extractors: http://danielwestheide.com/blog/2012/11/21/the-neophytes-guide-to-scala-part-1-extractors.html
I can write in the synchronous style I’m used to, but I can also use Futures, and it doesn’t take a lot of mental gymnastics as a Rubyist to learn to map objects to values as well as collections.
Option is really cool. With a little practice, having 5 ways to say “nil” actually makes a ton of sense. An “EmptyList” constant (Nil) isn’t very hard to grasp, especially when you learn the rule about operators with a trailing colon, and, “oh hey, so that’s what `1 :: 2 :: 3 :: Nil` is doing!”. Nothing causes an `if()` to return a more specifically typed expression. Ok, a little deep, but practical, not difficult to grasp. null is null. Unit is void. We’ve all written Ruby methods returning nil when we really meant void, but we don’t have a way to say “you should never care about the return value here” in Ruby. Sure those methods are rare. I imagine about the same as Scala though when writing Application code.
If you’re interested, this slide-deck (http://blog.greweb.fr/2013/01/playcli-play-iteratees-unix-pipe/) covers a library using Iteratees, which is one of the more… ugly? concepts I’ve run across, and makes it make sense, and hey, it’s actually kind of elegant, maybe there’s something to this. ;-)
Anyways. Fun stuff.
Sam, thanks for details on the elements of Scala you find most helpful. I actually find it really useful to see how people are actually using Scala, not just how libraries are constructed.
The application/library divide seems good on paper, but as I understand it, it didn’t work out well for Yammer. It does seem like abstractions gonna leak and having a bifurcated is an odd choice.
I used to the the Yammer thing was pretty damnig, but after actually working with Scala and Play, and all the projects Coda has pumped out in Scala, I think the immature idioms that seemed to be the thrust of his complaints are probably mostly due to the nature of their development. IOW, the average Rails shop today wouldn’t run into those issues in Play for the most part.
Coda was doing things like implementing JSON wrapper libraries around existing vetted Java libraries. It was all about making it “feel more like idiomatic Scala”.
I don’t discount his perspective because, holy hell he produced a lot of code if you take a look at his contributions. I just mean to say that for the average Rubyist, it’s probably an Apples to Oranges comparison. From what I gather, Coda was working on projects in Scala of the sort of things that Tony Arcieri or Ola Bini do/did in Ruby.
Play on the other hand seems to have pretty solid conventions for the 99%.