blarg?

Good, Bad, Music, Code.

If you’re a Bauhaus fan, and you’re at all concerned about the well-being of Abe Vigoda, then you should check out this page, which contains both up-to-the-minute news on Abe Vigoda as well as one of the best parody/tribute tunes I’ve heard recently. The other one is here: you’re hearing two different Nickelback songs coming out of the left and right speakers, the funniest thing I’ve heard recently. Act surprised.

Shaver is right, it is an interesting paper, though I don’t understand why you would argue that “programming languages should be more like the languages we speak” and then go on to advocate operator overloading. That’s crazy talk; the number verbs and adjectives available wildly outstrips the number of available operators, and contain a lot more descriptive information; overloading just means that when you see thingA+thingB, instead of having to know what things A and B are, you now also need to know what + does. And when that diverges wildly from the expected behaviour, or goes somewhere where no expectation could possibly be said to reasonably apply (like, say, when you start overloading bitshift operators into stream operators) the whole thing is just a blank cheque drawn on the Bank of Obscurantism.

Ask any ESL student how much they like homonyms. Ask anyone how much they like puns. That’s what comes from the same symbols meaning different things. There are some warts on Java, for sure, but the lack of overloading isn’t one of them.

7 Comments | Skip to comment form

  1. Lara

    That Nickleback link is doing my head in right now. It’s eerie.

  2. shaver

    Overloading is important for allowing user-defined types to behave like built-in types, which is an important goal for many type systems. Any language with a rich type system, such as one permitting virtual dispatch, requires more than textual understanding of expressions, for better or worse, and it doesn’t matter whether you spell your expression as:

    c = a + b

    or

    c.assign(a.addWith(b));

    I personally find that for many types, especially numerical ones — complex numbers, vectors (not that people can agree on how to spell the dot- and cross-product operations, generally), matrices, you know — it’s much easier to read expressions spelled with overloaded, mathematically-historical operators.

    Of course, it can be misused. But I don’t think it’s any worse than virtual method dispatch — same method name and base type can do wildly different things! And Java has operator overloading as well: integer and floating point addition, string concatenation, reference-vs-value semantics for assignment of primitive types and objects, “.” as member access or namespace traversal or introduction of magic for naming java.lang.Class values.

    (I think it is sucky that MT strips out <tt> tags here, by the by.)

  3. Mike Hoye

    Java’s tragic/magic overloading is, I understand, just so that it can make string and boxed builtins behave like they do in c++, which I’ve always thought was kind of silly.

    That ease-of-reading you mention makes perfect sense if you’re actually reading math-related stuff, but I don’t see it extending far beyond that; the only reason “String + String” makes any sense is that I’ve been reading it on my screen for years. I have no idea what “String – String” might mean, and “World += Dog” could mean anything.

    I’ll concede that it should either be all or none, though; the current state of half-assedness seems, well, half-assed. I’m filing that under the Things I Don’t Get About Java, alongside “why do you have two base- and three boxed-classes for both ints and floats” and “Arrays: What The Hell?”

    The other thing that I’m curious about is how well overloading and exception-throwing play together, which my simple cave-dwelling mind fears might be complicated and ugly.

  4. Mike Hoye

    Excuse me, I’m talking at cross-purposes from my original point: that being that the english language contains a lot more flexibility and semantic clarity than the very small number of available operators; basically, that a good choice of method name offers a lot more clarity than a mathematical symbol once you’ve strayed outside the realm of things mathish.

  5. Mike Kozlowski

    The argument for operator overloading is that programmers like terseness, and would often prefer to write a + b than a.Add(b).

    The argument against operator overloading is that programmers like terseness, and would often prefer to write a % b rather than a.CalculateTaxRateForState(b).

  6. Mike Kozlowski

    And more related to your main point, I find myself equally rhetorically convinced by Paul Graham saying that syntax gets in the way, and an ideal language should be as minimalist and pure as possible; and by Larry Wall saying that human languages are complex and messy, the problem domain is complex and messy, and it’s more natural to write in a computer language that’s complex and messy.

    Empirically, though, there’s no contest: Lisp is dead, and every other simple language gradually grows the encrustations needed to deal with complexity (whereupon the advocates of simplicity give it up for lost and move on to the next promising-but-impractial language).

  7. madhava

    I like puns.