October 29th, 2005

  • evan

namespacing

One thing that OO languages do nicely is implicit namespacing of functions. That is, when I write button.setText() it's specified/implied which of many possible setText()s I'm referring to. In a lot of O'Caml/Haskell/C code there's a pattern where, for example, a function with a name like setText is too general, so instead of colliding with other potential setTexts they get names like buttonSetText.

In non-OO C++ you can do this this with overloaded functions: you can't confuse setText(Button*) with a setText that works with some other thing. But this only works because you have explicit types: at any call of setText the compiler knows the type of the argument and so can resolve which function to call. In a type-inferenced world, code like setText myobj is used by the compiler to figure out what type myobj has.

The irony of this is that Haskell does allow overloaded functions based on return types, which is one of many crazy aspects of the language but consistent with the way they think, which is this: overloading gives a single name for the same operation on multiple types, and is provided analogously to OO interfaces: your types all have to implement the same interface. And you could imagine the utility of a single ParseFromString which takes a string and returns one of many different types, calling different code underneath -- something impossible in C++ but used in Haskell.

But multiple unrelated setTexts can't share a name in Haskell -- they call it "ad hoc overloading" to distinguish from the more "principled" overloading described in the previous paragraph. And that's all well and good for principle but in practice it means that every time I look at Gtk2HS, the GTK bindings for Haskell, I get turned away by these long function names.

Now that I've typed this all out, though, I discover that the Haskell developers are aware of it and they have a paper describing the problem space much better than I could.
  • evan

python desktop

There's an interesting thread on Gnome's desktop-devel-list regarding the inclusion of a Python app into the stock install. On one side, it's great that they're branching out into different languages -- anything but C! -- and the app is supposed be cool, but on the other side it's one of those little panel applets and (for whatever reason) it takes 22 megabytes of memory while running, 10 of which are writable/unshared.

Some people say: "Who cares? That's not that much memory." But consider I'm currently running 40 user-space processes, which would be nearly half a gig of RAM at 10mb each. And many of them are much larger than a panel applet and many others aren't Python, meaning that they don't share the interpreter libraries overhead...

The arguing starts here and goes on for a while.