Author Archives: david

Wait, you believed them when they said "Write once, run anywhere"? That’s so cute.

So, I’m writing a tiny little application that sits in your status bar and pops up occasional reminder messages in the corner of your desktop. It uses the Java 6 desktop integration stuff. It’s not very exciting – just fun and moderately useful.

I originally wrote this for Victoria with a set of hardcoded messages, so it only needed to run on windows. It worked really well, so I thought I’d turn it into a proper application – it should only be a few hours of coding to do so.

Especially, I thought, as it should run nicely cross platform.

Ha ha. Ha.

First off, Macs are ruled out – no functioning Java 6 yet. I took a brief look at using jdic instead, but it turns out that doesn’t support macs either. Argh. So, we’re stuck with windows and linux. Ho hum.

Yeah, linux? Not so much.

First off, Swing *never* works properly under linux. As far as writing cross platform GUIs, “Write once, run anywhere” is a blatant and utter lie. If you’re using Gnome or KDE with their standard window managers, it will just about limp by. If you’re using anything else, good luck.

Anyway, I use xmonad. However I use xmonad with gnome (at least on my laptop), and this is just a status bar feature, so given that I still have the gnome status bar I was optimistic.

Nope. Looks like Swing checks the window manager name, not the availability of the status bar. It’s really great the way the Swing/AWT developers actually understand the environment they’re developing for, isn’t it? On a related note, the resulting toolbar icon looks *really bad* even when I run it under normal gnome. That’s probably just a scaling and transparency issue though. I imagine I can sort it out if I try hard enough.

I have to say, despite this the desktop integration stuff is moderately nice. It’s a great way of writing once and running anywhere that has windows and the latest version of Java installed.

Sigh.

Anyone willing to put a word in for Groovy?

Groovy seems to come up in conversation a reasonable amount. People appear to be doing some interesting things with it. But every time someone tries to advocate the language it leaves me completely cold. Basically all the advocacy seems to come down to:

It has “closures”
It looks like Java…
…but it’s dynamically typed.

Yay?

It has a few features that seem a bit more interesting. It has named (and default?) parameters, which is nice (not exciting, just nice). What little I’ve seen of its metaclass stuff gives me a simultaneous “yikes” and “ooh, that’s kinda neat” reaction.

This isn’t really intended to be a bash at the language. I just don’t know much about it, and none of the information I’ve seen seems terribly compelling. I’d like to hear some stuff about why it’s actually a nice language to use. I probably still won’t use it – I have enough languages on my plate as it is – but I’d like to be a little less ignorant about it.

Tell us why your language sucks

Let’s play a game. Take your favourite languages and tell us what you hate about them. Like I’ve said before – all languages suck. Don’t pretend yours is perfect. If there aren’t things about it which annoy you you’re not trying hard enough.

Note: This should not be about bashing languages you don’t use or like, or even languages which you use and don’t like. Everyone does that already. I don’t want to hear yet another rant about why Ruby sucks from a Java programmer, why Java sucks from a Factor programmer, why Lisp sucks from a Javascript programmer, etc. I’m not even interested in hearing about people who are forced to use Java|C|C++|Javascript|Whatever and hate it. Tired, been done to death. It specifically has to be a language you use at least semi-regularly and like. Feel free to post here, to your own blogs, to the inevitable reddit thread, etc. But wherever you post it, have fun. Go on, rant. Get it off your chest. You’ll feel better for it. :-)

I’ve already started with Scala. Now I’ll do Haskell. Hopefully someone more experienced with the language will follow up, as I’ll freely admit it’s not my best language.

So, things I hate about Haskell:

Let’s start with the obvious. Monad tutorials. No, not monads. Specifically the tutorials. They’re endless, overblown and dear god are they tedious. Further, I’ve never seen any convincing evidence that they actually help. Read the class definition, write some code, get over the scary name.

Now we’ve over the one sociological issue, let’s get to some actual language ones.

Modularity. Haskell’s module system is about the minimum possible you can get away with and still claim to have a module system. Anything less and you basically have C style header files. Now, this isn’t a huge problem. To a certain degree type classes mitigate the need for anything functorial. But there are examples where it’s an issue. Take ByteStrings for example. Lazy and strict ByteStrings have essentially the same module signatures, but there’s no way to write code which is agnostic as to the type of ByteString it uses. They don’t live in a type class because it was considered that the type class signature would be too long. This is probably fair, but life would be a lot nicer if you could write functors over the ByteString modules.

In general, Haskell has very poor namespacing. If two modules define something of the same name you have to redefine one of them or refer to one of them qualified. It’s not a huge issue, especially as you *can* rename and Haskell modules are anyway not as long as Java packages. It’s not like you have to refer to org.haskell.data.collections.map.mypetcat.lookup. M.lookup isn’t too onerous. This mainly causes problems with symbolic operators, because things like Foo.++ look a lot worse as infix operators than Foo.bar does. I don’t know of a good solution to this problem. Object oriented languages provide a solution to it by basically making the type of the first argument responsible for namespacing. I don’t find this especially satisfactory, but it does work.

On a similar note, Haskell type classes basically live in global scope. There are good reasons for this, and it avoids you having to write a whole lot of painful sharing constraints (The example that is thrown at me every time I complain about this is what do you do if you want to unify two Data.Sets, each of which uses a different instance of the Ord type class)? It can be a real pain though.

There’s another issue related to type classes. Let’s pick an example. Data.List defines both sortBy and sort. The difference is purely that sort uses the standard ordering on the Ord type class while sortBy uses a provided ordering. And you need to define different functions every time you want to be able to use either a type class or something user configurable. Because you can’t redefine type classes locally or pass them as first class instances there’s basically no way around this. You can normally avoid the issue with selective use of newtype and careful choice of your types, but it’s definitely there.

Which brings me to another point – type classes are not first class. The Scala encoding of type classes is clunky in many ways, but a very nice feature is that the things you’re using as type classes are real first class members of the language, and you can bring to bear all the usual tools you have for manipulating stuff.

10,000 compiler extensions. GHC introduces so many compiler extensions, and everyone goes wild about them. This is understandable. Some of them are really useful. Some of them it’s amazing to manage living without (No multiparameter type classes in H98? Yeargh. Getitaway!!). I really like most of these I’ve used, but it sometimes make it feel like you need to employ deep and profound type system voodoo to get anything done. It would be very nice to get these unified into something sane and consistent, but Haskell’ seems to have stalled.

Tuples and records. There’s basically no good generic handling for either of these. Each of the different sizes of tuples is a totally different type (with no common type classes for abstracting over them), records are just a thin wrapper over normal datatypes with no extensibility or namespacing. Your record accessors will clash just as much as any other function name.

Something which has bitten me in the past is sharing code between monadic and non-monadic contexts. You essentially need to write pure and monadic versions of a number of functions. It would be nice if generic monadic code could automagically be specialised to the identity monad in a way that didn’t uglify pure code using it, or pure code lifted to monadic versions (this is harder I think). This doesn’t come up too much, but it means that there’s often functions like foo and fooM for pure and monadic versions.

The prelude and standard type classes are a bit painful sometimes. Things which you’d expect to be overloaded into type classes aren’t (Data.Monoid defines a function mappend for example, which in the List instance is ++. Why isn’t ++ on Data.Monoid?) and sometimes the type classes which are there are poorly thought out (Num shouldn’t extend Eq, and it would be nice if + was factored out in order to provide better support for things like vector spaces). I believe there is some work on alternate numeric preludes.

Plus lots of other little things which don’t spring to mind at the moment.

Also, one final disclaimer. Please please please don’t take this as a “Haskell sucks, don’t use it!!!” post. If you do I’ll… I don’t know, give you a really devastating hurt puppy look or something.

I’d also appreciate it if you don’t use this post to start a language war. Remember – you’re only allowed to say bad things about languages you actually like. Otherwise you’re cheating. :-)

Easy binary serialization of Scala types

I’m going to be prototyping some stuff in Scala at work in the coming week, and wanted a nice way of marshalling things to/from files and across the network. The BytePickle stuff in scala.io does nothing for me, and Java serialization gives me the screaming heebie jeebies, so this prompted me to get off my ass and do something I’ve been meaning to do for a while – port something akin to Haskell’s Data.Binary to Scala using the encoding of type classes I’ve previously discussed. Well, it’s done – it didn’t take very long at all. The port is *extremely* loose – in particular I’ve just written it for imperative use rather than define custom monads for reading and writing in a pure manner (sorry). The project is hosted on google code at http://code.google.com/p/sbinary/

At its heart it’s extremely simple:


trait Binary[T]{
  /**
   * Read a T from the DataInputStream, reading no more data than is neccessary.
   */
  def reads(stream : DataInputStream) :T;

  /**
   * Write a T to the DataOutputStream.
   */
  def writes(t : T)(stream : DataOutputStream) : Unit; 
}

object Operations{
  /**
   * Use an implicit Binary[T] to read type T from the DataInputStream.
   */ 
  def read[T](stream : DataInputStream)(implicit bin : Binary[T]) : T = bin.reads(stream);

  /**
   * Use an implicit Binary[T] to write type T to the DataOutputStream.
   */
  def write[T](t : T)(stream : DataOutputStream)(implicit bin : Binary[T]) : Unit =  
    bin.writes(t)(stream);
}

Err. That’s it. Did you want more? :-)

There’s more to it than that of course, but most of the rest of the code I’ve written for this is just helper methods, instances and scalacheck tests.

Out of the box this will serialise tuples of any size (that Scala supports. i.e. of 22 elements or fewer), lists, arrays, immutable maps, options, Strings, all the AnyVal types and any combination thereof. Looking at the code should give you an idea of how to define your own Binary instances.

Using it is very simple. It works by knowing the type of thing you want to read or write from the stream and selecting the appropriate logic based on that type (but, unlike Java serialization, if you give it the wrong type it will attempt to read it as that type anyway and probably do crazy things – this is very explicitly using the type to define a compact encoding and doesn’t select it based on dynamic information from the stream). e.g.


  import binary.Operations._;
  import binary.Instances._;
  val foo = read[(Int, Option[String], List[Int])](inStream);
  write(foo._2)(outStream);

The read and write methods on Operations take care of selecting an appropriate implicit instance of Binary and combining them to do the right thing.

Note that binary serialization logic is kept entirely external to the class, so it’s almost as easy to define for classes from external libraries as it is for your own.

I’m not doing an official release yet – I want to have a play around with this and see how usable it is. Once I have, I might change the API around to improve it. On the other hand, the code works now and does enough (within its very simple objectives) that it’s probably useful. I’ve written a bunch of scalacheck tests for it and am reasonably confident it gets all the current binary instances right. If you want to use it for something, go right ahead! Report back to me and let me know how it goes.

Edit: By the way, this only works properly on 2.6.1 or higher. There were some problems with the implicit arguments implementation prior to then that prevent the instances from working correctly.

More penne and cheese

My penne and cheese experimentation the other day inspired me to try more on the baked pasta theme. It’s quite different, and significantly more elaborate and… well, in fact bears no resemblance to the other recipe except that it contains penne and cheese (though a different type) and is baked in a glass dish.

What I used

About 300g of dried penne
One medium-large onion
One small aubergine
One yellow bell pepper
One red bell pepper
Three large (somewhat underripe) tomatoes
Ludicrous quantities of grated cheese (enough to cover the roasting dish)
One dried chilli pepper
About 1/2 tbsp coarse salt
Olive oil

The cheeses I used were turkish cheeses which the packages respectively claim them to be Eski Kasar and Kasar Peyniri. Kasar is apparently a kind of sheep milk cheese. They’re both semi-hard cheeses, with Eski Kasar tasting approximately like a milder parmesan and Kasar Peyniri approximating mozzarella. You could probably use those as substitutions.

What I did

There are quite a few steps in this, and it ended up taking a long time – about an hour and a half (though not requiring continuous attention).

I finely chopped the onion and peppers and cubed the aubergine. I roast this with olive oil, salt and the chilli pepper (which I flaked) at about 250C until it was fairly cooked.

Meanwhile I cooked the penne (deliberately undercooking it a fair bit). I coarsely chopped the tomatoes, and once the roast vegetables were cooked I added the pasta and tomatoes, mixed it up thoroughly and put it back in the oven at 200C.

After about 10 minutes I realised that the pasta wasn’t really cooking well enough, so I covered it in foil to keep the moisture in (you’d be surprised at how hard this is to do to a ridiculously hot glass baking tray…) and put it back in for another 15-20 minutes.

Once the tomatoes were looking suitably roast and the pasta was cooked I covered the top in grated cheese and put it back in to the oven until it was cooked (the desired end result was the top looking like a nicely cooked pizza topping). At that point, it was ready to serve.

Result

This made a huge amount of food, and it’s really filling. I think I’m going to get at least another 3 meals out of this, quite possibly 4. Fortunately, it’s very nice. Mmm…

I’d do a few things differently – I’d use a little more chilli. The vegetables were only very mildly spicy (I think my dried chilli peppers are getting old and losing flavour). I’d like to use a bit less olive oil, but my experience is that those vegetables don’t roast as nicely without. I’d probably use a bit less cheese.

In terms of timing, I think I should have put the tomatoes in before the pasta (but after the other vegetables) and let them roast a little bit, and similarly let the pasta cook a little more so that it was slightly hard but edible at the point it went in.

Still, definitely something to make again.