Matt Hellige / blog

Been a long time... Anyway, I was reading this proposal for Java closures (well, more or less closures, you know what I mean).

Not much to say about the proposal as a whole. But this...

This is a funny and very insightful comment about programming practice from Kay Schluehr:

Three days of JavaOne was enough to completely sour me on the entire idea of programming. I'm not really sure what did it. But then I made the right decision and went to the BayFP meeting. I left feeling quite rejuvenated, my faith in humanity and love of programming fully restored.

The first two days of JavaOne have been precisely as expected. Big, silly, lots of hype. But there's been some good stuff as well. The big hype efforts this year seem to be around JavaFX and Glassfish. I don't care about JavaFX at all, and as far as I can tell, nobody really does. But my sample is surely biased. Glassfish looks like a good direction, but we've all seen Spring and OSGI, so I think it's a fairly obvious direction at this point. There's also lots of hype about the JVM running on all kinds of devices, but so what?

In my last post, I translated the first part of Data types a la carte into Scala. I decided to push ahead into the next section, just for fun. The summary is: Scala's implicits are a very poor man's type classes, at least using the obvious encoding, and I am as always humbled by the cleverness of GHC.

I apologize for what you're about to see...

As a little experiment, I decided to translate part of this pearl from Haskell to Scala. By this I mean literal translation, as opposed to an idiomatic implementation in Scala. Of course, this goes deeply against the grain of the Scala language. On the other hand, as I wrote here:

It certainly cuts across the grain of current practice, and the grain of the libraries. But I think it takes a long time to discern the grain of a language. And I think it takes a lot of pushing and prodding, which is why I think this kind of experimentation is so important.

For now, it's a reasonable default to stick to a style that reflects the origins of the language (mostly Java-style OO with some functional goodies and richer types). I definitely think we should be open to the possibility that Scala style will diverge more radically from this tradition.

At this point, I'd probably replace the word "important" with "fun and maybe sort of worthwhile." Anyway, let's get started...

(This is the last of these, I promise.)

In my last post, I described a direct translation of Parsec's permutation parser combinators into Scala. I described one major problem with that approach: the need to provide a fully curried handler function. I suggested that a fix might be possible, and indeed it is. I've produced a new version of these combinators that does not require such a function.

A recent thread on the Scala list raises the question of parsing permutations using parser combinators. This is a situation where parser combinators offer a substantial improvement over EBNF. David Pollak proposes a solution, but it suffers from two problems:

• we are only able to parse permutations where all elements have the same type.
• the results are returned in input order, rather than declaration order, leaving us to figure out how to distinguish them.

Neither of these is disaster, but I hope it's possible to do better.

I've gotten a couple of questions about Hibernate and Scala. My last posts weren't really intended as a "gentle introduction" or anything: my goal was to document a difficulty I had with a particular situation. So here's more of an overview.

Happy new year!

There's been several threads on the Scala list about syntax, and in particular a lot of hating on the /: and :\ methods as shorthands for foldLeft and foldRight. I understand the concerns about overuse of meaningless glyphs, but:

• I think this concern is mostly misplaced in Scala, since operators translate straightforwardly into methods, so it's always obvious where to look for the definition;
• and in any case I still like /: and :\ for folds.