Tag Archives: java

No, seriously, why Scala?

Recently an article called Why Scala? was posted on reddit. It’s an ok introduction to the language, but the very fair observation was made that it’s much more of a “What is Scala?” than a “Why Scala?”. I thought I’d share my thoughts on the subject. Mainly because I like hearing (reading) myself talk (write). :-)

Quick background: I initially learned to program in standard ML while at university (self taught, mostly, with the help of some friends doing computer science. I was doing maths). On graduating I then switched tracks entirely and started doing Java web development in a small software firm in London (I’ve since switched again, but I’m still doing Java professionally). I’ve also dabbled and read a lot with computer science and programming languages in my spare time since then, filling in the gaps that not having done any real computer science at university left me.

My train of thought on the language switch from ML to Java was basically:

a) Wow, this is different.
b) Ugh. Where are my higher order functions?
c) Where are all these random exceptions coming from?? I’ve compiled the code successfully, isn’t it supposed to work now?
d) Hmm. But there’s some useful stuff here too.

Scala’s a nice way to scratch both itches, and adds some very interesting features and functionality of its own. It’s not my favourite language (I don’t really have one. All languages suck. It’s just that some of them suck less in interesting ways), but it has a lot I like. Here’s a brain dump of some of it.

Things I like:

Object oriented programming

I know, it’s so entrenched it’s past even bothering with its buzzword status. But object oriented programming has a lot of advantages for medium to large scale composition. It has some disadvantages, and frankly sucks at small scale composition of functionality (which is where functional programming shines), but it allows for some very nice pluggability.

Module oriented programming

ML has higher order modules. I never really used them much when I was programming it more often (mostly because I was only writing enough code to do some simple maths projects. I never wrote anything large scale), but having looked into them in more details since they’re really powerful. They’re essentially a different take on the composition that object orientation provides. Where object orientation resolves everything dynamically, ML’s higher order modules resolve everything statically. This introduces some limitations in flexibility but makes up for them in power and type safety – they provide a much more flexible and interesting abstraction over a type than mere subclassing and interfaces can.

Scala has both. Further, it has both and lo and behold they are the same thing. Objects are modules, and can declare their own types (note: This is much more than just declaring an inner class in Java is), imported, etc. Modules are objects and can be instantiated at runtime, extended, etc. You lose a bit of the static guarantees that ML modules but you gain a lot of flexibility from both sides.

Static Typing

I’ve written too much Java to not like static typing.

Wait, I know that sounds like a non sequitur, but read on.

I’ve written too much Java and seen flagrantly stupid and really subtle runtime errors that should never have made it past the compiler coming out of it to not like static typing. NullPointerException, ClassCastException, argh.

If you’ve written enough code in a language like ML, OCaml or Haskell you will know that the compiler is your friend. And, like all good friends, it will yell at you if you do something stupid and then help you pick up the pieces.

Scala doesn’t quite manage that. If you write code in just the right way you can achieve that level of guarantee (and in some cases, more. But that tends to be the result of abuse of the type system by deranged maniacs), but the combination of subtyping and some Java interoperability decisions mean that it’s not quite as good. It’s not bad though.

So: I like object oriented programming, I like static typing. It logically follows that I must like statically typed object oriented languages, right? Well, in principle, yes. But Scala is the first one I’ve met with a type system that didn’t suck. Scala’s traits (a sort of mixin) are so much better to work with than interfaces, the generics work properly, provide variance annotations, etc. A reasonable subset of the types are inferred. Compared to the type systems of Java, C# and C++ it’s a dream (it’s not as nice as the type systems of the statically typed functional languages I know of. Subtyping seems to cause issues, with a lot of research still needed to make it work well, and Scala seems to have largely ignored what prior work there was Hindley-Milner style type systems with subtyping)

Functional programming

You’ve all been dreading this section. “Oh no. Now he’s going to enthuse about how marvelous functional programming is and how it’s going to cure cancer”. Nope. Can’t be bothered. Functional programming is nice. If you don’t believe that, I’m not going to try to convince you of it. Scala’s support for functional programming is ok. It has some warts, but it also has some nice points, and it generally works well and isn’t too verbose. I’m not going to get any more excited about its presence than I am about the fact that my bike has wheels (but I’d be pretty pissed off if my bike didn’t have wheels). Higher order functions, pattern matching, etc. It’s all there. It works. Moving on swiftly…

Implicits

Scala offers a bag of features under the keyword ‘implicit’. This is one of those things that makes you go “Oh, that’s cute” when you first see it and then go “Wow, that’s powerful” six months later.

Essentially implicits give you statically guaranteed and provided dynamic scoping. You say “I need a Foo. I don’t care where it comes from”, the compiler says “Here you go” or “Sorry, no Foos today”. These can be objects, implicit conversions between types (You know the way Ints get implicitly converted to longs, double, etc in Java? Scala does that too, but it’s all programmer definable. They’re just library functions in scala.Predefined). If you remember what I said about Scala objects being modules and you’ve read this paper a little light might just have gone on in your brain. If you haven’t read it and don’t want to, here’s the summary version: Implicit function arguments + first class modules gives you something that looks and quacks very much like Haskell type classes (yes, I know this isn’t actually what the paper says, but it follows from it). Mmm.

These are the big things to like about Scala. Here are a few little things:

Sane constructor/class semantics. If you’ve written a lot of Java there’s a good chance you hate its constructor system. Scala’s is much nicer.
Expression oriented code. Everything is an expression. You can form compound expressions trivially – { val foo = bar(); baz(foo, foo); } is an expression which evaluates to baz(foo, foo).
Sanely uniform scope. Pretty much anything you can do inside a method you can do inside an object and vice versa. Things are for the most part lexically scoped in the right way.
The primitive/object divide is much less irritating. Primitives get a few special treatments at the language level, but mostly they’re just objects. When things should compile to use primitives, they do. When the primitives need to be boxed, they will be. It’s almost entirely transparent.
Performance. Scala generates very good (well. ‘good’. Java-like) bytecode, which means it gets to take advantage of most of the optimizations the JVM is willing to throw its way. Further it puts a reasonable amount of its own work into performing optimisations on the bytecode, etc so you get those nice juicy abstractions without much overhead. There’s essentiall y no performance penalty for choosing Scala over Java

etc.

Scala’s far from perfect. It has some syntactic weirdnesses, a few issues carried over from Java, a moderately buggy compiler and a host of little features and edge cases that are really hard to keep in your head. However, I find that these issues don’t actually do more than annoy you from time to time. The core language is powerful and very useful for just sitting down and writing good code in.

Statically checked range types in Scala

I was showing off some Scala features earlier (specifically “Oh, hey, look. With proper singleton support + implicit arguments you can completely remove the need for a dependency injection container while losing none of the advantages”. More on that later…) and got to discussing the language with Craig, a coworker of mine (well, specifically our CTO. I work at a cool company. :-) ).

He asked me if Scala supported range types, to which my answer was something along the lines of “Well, no. But it should be possible to add as a library. Hmm. Might be hard to get it statically enforced though”.

Turns out it’s not. Here’s some code: http://snippets.dzone.com/posts/show/4876

How do we use this?

scala> import ranges.Range;
import ranges.Range

scala> val myRange = new Range(0, 10);
myRange: ranges.Range = [email protected]

scala> val myRange2 = new Range(0, 20);
myRange2: ranges.Range = [email protected]

scala> val array = new myRange.CheckedArray[String]
array: myRange.CheckedArray[String] = [email protected]

scala> myRange.indices.foreach(x => array(x) = x.toString)

scala> array.mkString
res6: String = Index(0)Index(1)Index(2)Index(3)Index(4)Index(5)Index(6)Index(7)Index(8)Index(9)

scala> array(myRange.minIndex);
res8: String = Index(0)

scala> array(myRange.maxIndex);
res9: String = Index(9)

scala> array(myRange2.minIndex);
:8: error: type mismatch;
 found   : myRange2.Index
 required: myRange.Index
  val res10 = array(myRange2.minIndex);
                            ^

scala> array(myRange.minIndex.mid(myRange.maxIndex));
res11: String = Index(4)

scala> array(myRange.minIndex + myRange.maxIndex);
:8: error: type mismatch;
 found   : myRange.Index
 required: String
  val res13 = array(myRange.minIndex + myRange.maxIndex);
                                              ^

scala> import myRange._;
import myRange._

scala> array(myRange.minIndex + myRange.maxIndex);
:11: error: type mismatch;
 found   : Int
 required: myRange.Index
  val res14 = array(myRange.minIndex + myRange.maxIndex);
                                     ^

scala> array(minIndex + maxIndex);
:11: error: type mismatch;
 found   : Int
 required: myRange.Index
  val res15 = array(minIndex + maxIndex);
                             ^

CheckedArrays (and similarly ArraySlices) are scoped to a particular range object. You can only access them with indices from that same object. You can get Index objects by getting the minimum, the maximum, combining them with various operators, iterating over them or converting from an Integer (at which point it will either min/max it into bounds or throw an IndexOutOfBoundsException if the integer is out of bounds, depending on which method you call).

If you import the range (I’m thinking of separating that out into a separate object for convenience with working with multiple ranges) you’ll get an implicit convertion from indices to integers (*not* the other way around).

Currently nonexistent: Support for subranges, or working with multiple ranges (Update: See below). I think I know how to fix these in a niceish way.

Always going to be nonexistent: Can’t statically verify that two ranges are equal. This isn’t possible in principle, but even simple cases like knowing that new Range(0, 10) and new Range(0, 10) are equal types isn’t doable. I don’t think this is avoidable without special logic in the compiler or significantly more static resolution of objects than Scala is ever likely to have (e.g. I think we could do this using ML functors and sharing constraints, but it’s been so long since I’ve looked at those that I’m not really sure).

Update: Working with multiple ranges is always going to suck without language changes. There’s not enough sharing of values at compile time to express what it needs to. Subranges will probably still work though.

Update 2: It’s been observed that if you don’t know Scala then it’s non-obvious how this code works. Unlike Java, inner classes of different instances in Scala are actually different types. So given

val range1 = new Range(0, 10);
val range2 = new Range(0, 10);

range1.Index and range2.Index are different types, and may not be freely converted between. So this code works by having Range enforce that its Index elements are in bounds, and the compiler enforces that you can’t mix Index elements from different ranges.

Minor irritations

I just noticed the following issue in Java. It’s never bothered me before, so it’s clearly not that big a deal, but I find it vaguely annoying.

The following code is not legal:

final Foo foo;
try{
  foo = stuff();
} catch (Exception e){
  foo = otherStuff(); 
}

The compiler thinks that foo might already have been assigned in the catch block, even though it clearly can’t have been.

The reason is presumably that it doesn’t distinguish it from the following code:

final Foo foo;
try{
  foo = stuff();
  bar();
} catch (Exception e){  // Might have been thrown from bar.
  foo = otherStuff(); 
}

Which is reasonable. I’m not sure if I’d really want this edge case to be handled specially.

As Ricky Clarkson pointed out in ##java, what would really be much nicer is:

final Foo foo = try { stuff(); } catch(Exception e) { otherStuff(); }

i.e. Compound expressions ala Scala (or GCC extensions, or any number of other languages). It would avoid a lot of annoying edge cases with assigning to final variables.

This isn’t really a “Please add this to Java 7” request. I don’t care enough and the list of desired features is getting annoying. It’s just a minor irritation with the language.

Don’t forget to fly

I saw this comic a while ago and it occurred to me during today’s HUG.

I think the analogy is obvious, but I’m going to spell it out anyway because I feel the need to rant about it. (As a side note, I know I’ve occasionally been guilty of what I’m ranting about. Hopefully I’ve stopped…)

You like functional programming. That’s great. You write C#/Java/C++/Brainfuck/PL-SQL/Malbolge during your day job. That’s a shame, but oh well. You and everyone else. I bet you really wish you could use folds/lazy evaluation/lightweight threading/COMEFROM statements in your work code. Great. Me too.

There’s a lot of neat stuff in functional programming (and in the better OO languages. And in logic programming. And in a wide variety of other things). So, use it. Go wild. Write code.

DON’T waste time posting endless blog posts about how closures are awesome and wonderful and here’s an example of how they might work in Java. “Here’s a nice bit of code I wrote” is one thing. “Here’s how to implement a for loop. Isn’t it awesome!!!”? Not so much. If you’re interested in something, use it. Don’t waste time thinking about how to shoehorn its features into a language you know far too well.

You can fly. Stop thinking about how great it would be to do so and go out and do it.

Dependency injection in Scala

I (and some others in #scala) have been wondering recently about the state of play for dependency injection in Scala. This is mostly just a brain dump of a few thoughts and a request for feedback. If anyone has any good ideas, please share!

As I see it, most of the Java dependency injection frameworks should work fine for Scala. Guice won’t because of generics issues, and similarly the generics support from other frameworks (e.g. Spring’s type collections) won’t though, so you lose a great deal of type safety. You’re back to an almost Java-like level of type safety in fact. :) Also these don’t take advantage of many of Scala’s great features (higher order functions and a more advanced object system in particular), so the whole thing seems rather unsatisfactory.

I wondered briefly about a system based on abstract method injection using traits, but I couldn’t make it work in a satisfactory manner. The fact that you’d expose dependencies as defs was also unsatisfactory because it means that the compiler doesn’t know that they’re stable so you can’t e.g. import them.

There was some discussion in #scala last night about how “dependency injection is useless if you have higher order functions”. This seems like nonsense to me. A well designed scala program may have less need for DI because of the presence of higher order functions but the basic need for composing of modules (that’s what dependency injection frameworks really are after all – a module composition DSL) is still there, for more or less the same reason why Scala has objects as well as functions.

It’s not entirely clear to me how DI should work in Scala, both from an API and an implementation point of view. Something Guice-like might be a good starting point (but only a starting point! Porting Guice verbatim to Scala would almost certainly be a bad idea), but it’s not clear to me how one would even implement it in Scala. Part of the problem is that Scala lacks a satisfactory metaprogramming facility. It can use Java’s reflection, but the scala.reflect packages seem sadly meager. (There do seem to be a bunch of interesting sounding classes in there, but there appears to be no documentation or evidence of prior usage, so I can’t figure out what on earth they’re for).