Java bytecode lets you overload method names based on the return type as well as the argument types, even if the language doesn’t.
Category Archives: programming
Hardware vendor shit list
In keeping with my recent stance on blog content, this has nothing whatsoever to do with programming. It won’t educate you about esoteric languages, you won’t learn good development practices from it, and frankly you probably won’t care about it.
This is a post about hardware companies who suck. This post has two purposes:
a) In the hopes that it will prevent someone else from having to deal with these issues.
b) A small measure of petty revenge against those who have SERIOUSLY PISSED ME OFF. It’s not like they’ll notice the loss of a few sales, but if this persuades even one person not to give them money for their crap it will make me feel better.
There’s a tentative c) that if anyone could give me a suggestion for fixing my laptop I’d be eternally grateful. :-) But I don’t really expect that.
The past six months have not been happy ones for hardware. My work machine has never worked right, and my personal laptop has mysteriously died. Twice. The incompetence of Mesh in dealing with the desktop’s problems has been rivaled only by the astoundingly poor communication skills and unreliable hardware of Asus.
First, Mesh.
The problem with the desktop is a very annoying one: The screen would intermittently go black for a second or two. At first it did this once every few hours and I wasn’t sure if it wasn’t just power saving mode or something. Eventually I verified that no, it really was happening, and it was happening in both vista and ubuntu, so it most likely wasn’t a software problem. As time went on the problem got progressively worse – these days the rate is several times per minute.
I eventually narrowed it down. The problem would only manifest in the exact following circumstances:
a) This exact PC. Any other one worked fine.
b) The exact brand and make of monitor. Brand and make you say? Want to know how I know this? It’s because they sent us three. Sending us the second one was quite reasonable – it looked like a monitor problem. After the second we pointed out that maybe this wasn’t such a productive use (however we didn’t complain too hard, as the monitor had developed several dead pixels. But they wouldn’t replace it for the dead pixels sitting smack in the middle of the screen. You need at least 5 before it’s a replaceable condition. More on this later.).
c) Only on DVI input.
c) was the fortunate point which meant that I’ve actually been able to get work done in the last six months. I dislike VGA, but it’s at least usable.
Speaking of the brand of monitors, here’s another shit list entry: Mirai, the brand of this monitor. Quite possibly the worst monitor I’ve ever used. Despite my best efforts and tinkering the colour has never been anything less than washed out. They’ve developed dead pixels, random image problems (my favourite was the “yellow line down the middle of the screen”. That was a fun one. The flickering effect was another nice touch).
Anyway, back to mesh and this peculiarly specific hardware problem. Very random, isn’t it? What’s the chance that two pieces of hardware picked out of the blue would demonstrate such a specific incompatibility?
Wait, picked out of the blue? That doesn’t sound right. Let’s try again.
What’s the chance that two pieces of hardware picked and provided specifically to work together would show such a specific incompatibility?
Having exhausted monitor options they concluded that maybe we should replace the motherboard (it had onboard video). And so they did.
Eventually.
It took more than a little trying and them sending no less than four people out (it might even have been five. I forget if we had one or two no shows). Between these four, they managed the following problems:
a) A no show
b) someone who came out with a very handy motherboard box. No motherboard mind you, but one out of two isn’t bad, right?
c) Someone who in his truly inspiring competence managed to bring not only a motherboard box but an actual motherboard contained within. Rapture! What service! Oops. Wrong motherboard. What service?
d) Finally someone who managed the simultaneous combination of box, motherboard and correct brand of motherboard. He didn’t arrive until 7:00 in the evening and seemed to think he was going to be visiting a home address, but oh well. Why be picky? He managed to replace the motherboard successfully and everything, we booted up the machine and the display appeared stable. Could it be that after all this time the problem was finally resolved??
For context, I should clarify that I was now working on a different machine. We’d cut our losses and moved me to another desktop (a Dell. I’m not a big fan of Dell, but I have to admit their customer service is great). This meant that I wasn’t directly observing the other machine, but we booted it up with the intent of testing it and once we were sure the problem was resolved putting it to another use.
At some point during the following day I got a question from someone who sits next to where I had the computer set up.
“David, did Mesh come to fix this last night?”
I moved around to talk to them. As I did I said something along the lines of “Yeah, they replaced the motherboard and it seems to have solved the… oh shit”
Flicker. Flicker flicker. Blink.
Which is about where we stand currently. I don’t know what we’re going to do now.
Now, Asus.
I went with Asus because I’d been told their laptops were very reliable. Yeah… not so much. Also their website is awful, their customer support is awful, and their communication skills lie somewhere between “awful” and “nonexistent”.
I placed the order on a weekend. I got a generic “thank you for placing an order” with a note about sending confirmation when they were ready to deliver. On tuesday I still hadn’t heard from them so I made a mental note to call them in the morning to ask when they were likely to deliver.
And arrived to find my laptop sitting on my doorstep. On the one hand, yay laptop. On the other hand, RANDOMLY LEAVING EXPENSIVE HARDWARE ON ONE’S DOORSTEP IS NOT COOL. Granted it was internal to my building, not on the street, so clearly someone had to have let them in and signed for it, but this is still not acceptable behaviour. But even setting that aside, the key point here is that there was no communication, no advance warning, nothing. If they’d just done exactly what they should have done and said they were going to and let me know that they were planning to deliver that day I would have planned accordingly.
Anyway, rather than tear them a new one, I decided to let it pass. After all, I had a laptop (and a reasonably nice one). No harm done.
A week and a half later the laptop turned into a brick. The power light came on when you pressed the power button, and some vague whirring noises, but nothing more than that. I called up asus technical support, reading their support procedures on the card with growing dread (it involved sending you a snail mail form to fill out if they decided that yes really you needed replacement hardware). Fortunately their procedures were 71% less insane than claimed, and the dreaded form was in fact an excel spreadsheet. Hurray.
Upon filling this out and getting confirmation I had to call an entirely different branch in order to arrange a pickup. When I did they asked me to call back later as the details had yet to come through. Apparently their inability to communicate extends to eachother as well as their customers. It’s good to know I’m not being singled out.
Eventually I persuaded them to pick up the laptop. In fairness it didn’t require *that* much persuading. They picked it up promptly once arranged.
And then silence.
Two and a half weeks later I finally found time to call them up and say “Soo… laptop. What’s going on with that?”. “Oh, yeah, we sent it out this morning. You should be getting it today”. Fine, great, I’m glad they sent it back. But again with the total non-communication. And slowness. Two and a half weeks is not a nice length of time to be laptopless. For additional failure to communicate, they gave no indication whatsoever of what the fault was. I should have enquired, but I couldn’t be bothered at the time. This was a mistake.
That was a couple of weeks ago – I forget how many, but definitely not longer than a month – and the absence of this knowledge is now highly relevant, because the laptop has just done it again. This time it appears to have been the result of leaving it on until it went into power saving mode – I fell asleep with it on, woke up four hours later to discover that I no longer possessed a functioning laptop. If anything it’s brickier than last time – I’m not even getting a power light when pressing the switch.
This is especially upsetting as it means I will have no laptop over the christmas period. This means no working on personal projects I’ve been putting off due to work and, more importantly, a very limited amount of communication – in particular I’ll have to borrow my parents’ computer if I want to use Skype or IM (and no video at all. Sigh). It also probably means that you get a respite from my blogging. :-)
For added irritation (and admittedly I can’t blame this on hardware vendors, although if I could I’d try at this point), I seem to be running a moderately high fever. All in all this does not result in a happy David.
Type classes in Scala
Some backstory on this post: I got about halfway through writing it before realising that in fact it didn’t work because of a missing feature. I sent an email to the mailing list about this feature and after some discussion it was concluded that in fact this missing feature was a failure to meet the specification and that it had been fixed in 2.6.1. There’s still one thing lacking, but more on that later. The post now resumes.
I mentioned in a recent post that Scala could emulate Haskell type classes with its implicit defs and first class modules.
In actual fact, the situation is much happier than that. Implicit defs + first class modules give you significantly more than Haskell type classes (although with a tiny loss of type safety). At least, much more than Haskell 98. In particular, multiparameter type classes and associated types come for free. You also gain a number of other advantages, such as type class instantiation scopes lexically, so you can redefine type classes locally.
So, how does all this work? I’ll begin with a general introduction to this style of programming with no real reference to Haskell, and then I’ll tie this back in to encoding Haskell type classes at the end of it.
Here’s a class that’s familiar to anyone who has written non-trivial Java:
trait Comparator[T]{
def compare(x : T, y : T) : Int;
}
trait Comparable[T]{
def compareTo(t : T);
}
Now, let’s define the following method:
def sort[T](array : Array[T])(implicit cmp : Comparator[T]) = stuff
So our sort method can either have a comparator passed to it explicitly or it will pull one from the surrounding environment. For example we could do:
object SortArgs{
implicit val alphabetical = new Comparator[String]{
def compare(x : String, y : String) = x.compareTo(y);
}
def main(args : Array[String]){
println(sort(args));
}
}
Will pick up the alphabetical instance.
It would be nice if we could also have defined the more general version:
object SortArgs{
implicit def naturalOrder[T <: Comparable] = new Comparator[T]{
def compare(x : T, y : T) = x.compareTo(y);
}
def main(args : Array[String]){
println(sort(args));
}
}
But this doesn't seem to work. :-/ Hopefully this will be fixed - it seems like wrong behaviour. Matt Hellige came up with the following workaround, but it's not very nice:
object Sorting{
trait Comparator[T]{
def compare(x : T, y : T) : Int;
}
def sort[T](arr : Array[T])()(implicit cmp : () => Comparator[T]) = null;
implicit def naturalOrder[T <: Comparable]() : Comparator[T] = null;
implicit def lexicographical[T]() (implicit cmp : () => Comparator[T]) :
Comparator[List[T]] = null;
def main(args : Array[String]){
sort(args);
sort(args.map(List(_)))
sort(args.map(List(_)).map(List(_)))
}
}
Moreover I haven't the faintest notion of why it works. :-)
However we can also chain implicit defs:
implicit def lexicographicalOrder[T] (implicit cmp : Comparator[T]) : Comparator[List[T]] = stuff;
So now the following code *does* work:
def main(args : Array[String]){
sort(args);
sort(args.map(List(_)))
sort(args.map(List(_)).map(List(_)))
}
}
An amazingly nice feature of this which some encodings of type classes miss is that you don't need an instance of a type to select on that type. Take for example the following:
object BinaryDemo{
import java.io._;
trait Binary[T]{
def put(t : T, stream : OutputStream);
def get(stream : InputStream) : T;
}
implicit val utf8 : Binary[String] = null;
implicit def binaryOption[T] (implicit bin : Binary[T]) : Binary[Option[T]] = null;
val myStream : InputStream = null;
def readText(implicit bin : Binary[Option[String]]) : Option[String] = bin.get(myStream);
readText match{
case None => println("I found nothing. :(");
case Some(x) => println("I found" + x);
}
}
Unfortunately this example betrays a weakness in our encoding. I can't just randomly call "get" like in Haskell's Data.Binary - because I need to invoke it on an instance of Binary[T] I need to ensure at the method level that one is available. There doesn't appear to be a good way of getting access to implicits from the enclosing scope directly.
However, here's a silly hack:
def fromScope[T] (implicit t : T) = t;
And we get:
fromScope[Binary[Option[String]].get(myStream) match{
case None => println("I found nothing. :(");
case Some(x) => println("I found" + x);
}
}
This works just as well with multiple type parameters. For example, if we wanted to port Java's AtomicArray classes without wrapping everything (although admittedly wrapping everything would be more idiomatic Scala) we could do the following:
object ArrayDemo{
import java.util.concurrent.atomic._;
trait AtomicArray[S, T]{
def get(s : S, i : Int) : T;
def set(s : S, i : Int, t : T);
def compareAndSet(s : S, i : Int, expected : T, update : T);
}
implicit val long = new AtomicArray[AtomicLongArray, Long]{
def get(s : AtomicLongArray, i : Int) = s.get(i);
def set(s : AtomicLongArray, i : Int, t : Long) = s.set(i, t);
def compareAndSet(s : AtomicLongArray, i : Int, expected : Long, update : Long) = s.compareAndSet(i, expected, update);
}
}
So, that's multi-parameter type classes. But one thing you'll notice about the above encoding is that it's a bloody nuisance to invoke - you need to know the type of the array class you're using, which is annoying. Far better would be if the trait took care of that. In Haskell terms this would be an associated type.
No problem.
object ArrayDemo{
import java.util.concurrent.atomic._;
trait AtomicArray[T]{
type S;
def get(s : S, i : Int) : T;
def set(s : S, i : Int, t : T);
def compareAndSet(s : S, i : Int, expected : T, update : T);
}
implicit val long = new AtomicArray[Long]{
type S = AtomicLongArray;
def get(s : AtomicLongArray, i : Int) = s.get(i);
def set(s : AtomicLongArray, i : Int, t : Long) = s.set(i, t);
def compareAndSet(s : AtomicLongArray, i : Int, expected : Long, update : Long) = s.compareAndSet(i, expected, update);
}
}
Scala's classes can have abstract types. So we just encode associated types as those.
So, to recap on our encoding:
class Foo a where
bar :: a
baz :: a -> a
becomes
trait Foo[A]{
def bar : A;
def baz(a : A) : A;
}
instance Foo Bar where
stuff
becomes
implicit Foo[Bar] bar = new Foo[A]{
stuff
}
instance (Foo a) => Foo [a]
becomes
implicit def[T] (implicit foo : Foo[A]) : Foo[List[A]]; And for invoking: foo = bar
becomes
val yuck = fromScope[Foo[A]].bar
So it's a more verbose encoding, but not a terrible one. And it has some abstraction advantages too. For example:
sortBy :: (a -> a -> Ord) -> [a] -> [a] sortBy = stuff; sort :: (Ord a) => [a] -> [a] becomes def sort[A](xs : List[A])(implicit cmp : Comparator[A]);
Because our type classes are a form of implicit object passing, we can also use them with *explicit* object passing. Thus we can redefine behaviour much more nicely to behave equally well with an ordered type and explicitly provided comparison functions.
This has disadvantages too - you need to be more careful to ensure that you can't accidentally use two instances of the type class. This isn't a major burden though. The general solution is that when you have something which needs to maintain type class consistency between invocations you pass it an instance at construction type. Take for example Haskell's Data.Set. In Haskell getting a new Set (Set.empty) works for any type but almost all the functions for building sets have a constraint that the type belongs to Ord. In Scala you would require an Ord instance to be passed for Set construction but after that would not need one (analagous to Java's TreeSet providing a constructor that takes a Comparator).
One thing I haven't covered is type classes which abstract over type constructors rather than types. The reason I haven't covered them is that I've yet to peek into that corner of Scala's type system. However, I assume they work as Tony Morris has done some stuff with monads in Scala. Also, see this paper (which I've not read yet)
Random thoughts on OO
OO is supposed to be about modularisation right? Separating your concerns and all.
Suppose I told you there were two major areas of your code that were deeply intertwined. Each is intimately connected to the other and it was almost impossible to tell where one started and the other began, yet the two were really very different.
Doesn’t sound very modular, does it? Practically the antithesis of good OO practice.
Suppose I now told you those two areas were “behaviour” and “data”.
Don’t mind me. Just thinking out loud…
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.