Log in

No account? Create an account
Previous Entry Share Next Entry
Programming as art: Scala's new Collections API
Okay, this one's for the hardcore code geeks in the audience; anybody else will find it eye-glazing. But if you really love code, check out the Scala 2.8 Collections API. It's a thing of beauty, and a really good illustration of why I so love Scala -- they systematically deconstructed every major collection type, figured out exactly what they have in common and what makes each one different, and rebuilt the libraries to be about as consistent and sensible as is humanly possible. (They were already way better than average in 2.7, but they nonetheless rewrote it under the hood to make it all *right*.)

The result looks about as close to perfect as you can get: as many common base traits as possible (making everything more learnable and robust); focused on immutable collections (for safety and scalability) while allowing you to work with mutable ones whenever you feel the need; lots of consistent operations, so very-high-level functional programming Just Works; abstractions that let you seamlessly work with infinite collections exactly the same way you do finite ones; thoroughly type-safe from top to bottom, using Scala's type inference to catch programming errors without you needing to state types explicitly. I could go on, but you get the idea.

I sometimes talk about programming as my artform, and I mean that quite seriously: I perceive the aesthetics of code just as clearly as I do for painting or music. The Scala project has won me as an adherent on that basis, perhaps more than any other -- there is a common devotion to crystalline elegance in both the language and its tools. That lets me program *better* on a practical level, but beyond that, it's just plain more *satisfying* a language to work in...

  • 1
Somewhat, yes, and it's interesting to note that my own tastes are changing.

But the Actor thing really is a good example, because you can't think of pass-by-value as being just about how you communicate the data structure -- it's really about how you are *sharing* the data structure. That is, you're passing an immutable pointer, but the important part is that both of the Actors working on that structure should be able to operate on it without worrying about each other. That's difficult to do with mutable structures unless you get into the usual mess of complex locking schemes, or copying the object entire, and making an immutable copy of a mutable structure *is* expensive. But if you think of it as immutable from top to bottom, each Actor can reason about and operate on the structure completely independently, without worrying about what the other guy is doing.

My gradual shift in taste is being driven by these sorts of considerations. Almost every serious project I do is heavily multi-threaded, and I usually spend a ton of time worrying about synchronization issues. (And cleaning up after other programmers who don't quite know what they're doing.)

So I'm increasingly serious about finding architectures that are inherently robust in the face of parallelism, requiring simpler rules to not screw up, since I think that's the way things have to go. Actors seem to be one of the two really good answers I've seen to that. (MapReduce is the other; they seem to be good for different sorts of problems.) And if you follow a discipline of using immutable collections, Actors become significantly safer, since there is less danger of accidentally exposing mutable objects...

  • 1