I Aten’t Dead

Surgeon General’s Warning: This post contains an excess of hyperlinks. There is anecdotal evidence that excessive linking may be hazardous to your health.

I’m still here. :-) I’ve just been busy with my new job at Trampoline Systems and non-code things.

On the computer front, I’ve been learning (a bit) about spatial data structures and graph algorithms, mostly for work related reasons although also for personal interest. Tinkering with Haskell continues apace – I’ve been finding that it’s a very good language for thinking in, even if I don’t write anything big in it.

The Lazy Strings project may look like it died, but fear not! It continues. Ok, you probably didn’t care either way, but still it continues.

I’ve decided that a) Life is too short to write it in Java and that b) I should just pick an implementation and stick to it. Consequently I’ve moved to Scala, and have the basics of an implementation based on a finger tree, rather than the traditional balanced binary tree used in a rope.

Why a finger tree? Well, umm. Because. :-) Finger trees have nice performance characteristics, are easy to implement, and seem well suited to the task. The version I’m using is very heavily specialised to the task at hand, and measures a number of things up front (currently just length and hash code) to improve performance and allow for various nice optimisations.

The main thing to note is that I’ve been using scalacheck to test properties of the string. It’s been a great help. I’ve not found it that useful for actually tracking down the specifics of the bugs – its error reporting isn’t that great – but it’s been very useful for showing that they exist and providing enough of a general area that I can track them down myself. The fact that Scala has a REPL has been very useful in doing enough experimentation to pin it down.

The utility of these will come to no surprise to those functional programmers reading my blog. :-) Scalacheck isn’t quite as nice as Quickcheck and the Scala REPL isn’t as nice as most of the ML ones (it’s better than ghci though), but they’re both good enough, and it’s nice having these in Scala.

Scala itself I continue to have mixed feelings about. It’s a little too Java like. I very much like what it’s done with the object system (first class modules. Yay!), and about half of what it’s done with the type system, but the whole effect still feels kludgy to me. It’s definitely infinitely better than Java though, and doesn’t fall much short of being as pleasant as an ML (it’s better in some ways, worse in others).

4 thoughts on “I Aten’t Dead

  1. rickynils

    Nice to see you find ScalaCheck useful! If you have any concrete examples of how you think it compares to QuickCheck, then I would be glad to hear it. I’m always interested in improving usability so comments and suggestions are very welcome.

  2. David R. MacIver

    I’ve definitely not found any serious usability problems in using Scalacheck – it’s very nice. I think the niceness of quickcheck in comparison to it is more to do with the how good the two languages are at expressing this sort of thing. I’ve not used either extensively, so I’m a little short on proper comparisons at the minute. :-)

    I do find the reporting in the case of failed checks to currently be a little unhelpful. I’m not sure how I’d want to improve it though.

  3. rickynils

    I see what you mean. For one thing, Haskell’s superior type inferencing is a great benefit for QuickCheck of course. For instance, in ScalaCheck you almost always have to annotate the arbitrary method with a concrete type to please Scala.

    The Show class in Haskell is very helpful in QuickCheck’s error reporting. In Scala, you often get just a memory address printed, no automatically derived pretty printing for ADTs, records etc. Maybe there are ways to improve error reporting in ScalaCheck though.

  4. David R. MacIver

    Actually, part of the problem with mine was that I do have a useful toString method, but it doesn’t reveal a lot of the internal structure of the data.

    Now that you mention it, it occurs to me that ‘toString’ and ‘show’ are really two different things, and that ‘show’ would be much more useful here.

    How about using reflection or similar to generate some sort of JSONesque representation of the object and display that instead? You could additionally define a ‘Show’ trait which allows customisable showing.

Comments are closed.