Older blog entries for apenwarr (starting at number 37)

Since I've said this to several people at work in the last few days and nobody has had the heart to disagree with me, I will now open myself up to public flaming and see if that helps.

My assertion: it is totally impossible make really reliable, high-performance programs (like oh, say, idb backup) in a language other than C/C++ (and maybe ADA and C#, but I'll reserve judgement for now). This includes, but is certainly not limited to: python, perl, shell, java, tcl, and php. Especially python. And *really* especially PHP.

My evidence: nobody has ever written a reliable, high-performance program in *any* of those languages.

Thank you. Have a nice day.

To avoid the worried feeling I get about a recent directive from top management to effect of "Do everything possible to trick Avery out of writing actual code, because he's most useful doing other things," I've been trying to make my own job seem more attractive. (That's the actual quote, by the way. There is no directive to me, only to other people. I love this company :))

So here's my latest attempt: in a parallel with the similarities I noticed between programming and People Hacking, I've noticed a similarity between code architecture and company management structure. My latest theory - and the coders at NITI will be familiar with the results of this by now - is that a manager, like an object, should do just one thing, and do it well. If it takes you more than a sentence to clearly explain what your manager does, then his job is not clearly defined, and sure enough: he'll do it badly.

So, after the OO fashion of the moment, we've been trying to rearrange our management structure on a functional-block basis instead of using a pure inheritence hierarchy. For example, the new Pusher job (no link yet, sorry) is "responsible for when a release comes out." The now-simplified Visionary job (well, that link is for EvilVisionary, but you get the idea) is "responsible for what goes into a release." Best of all, you instantiate a new Pusher for each release, but they all communicate with the singleton Visionary object, er, person, who can move features around between releases.

Consider what the pusher does when your release is late:

  bool ok = visionary.drop_features(release, 5 /* days */);
  if (ok)
     return true; // on time again!
  else
     release.duedate += 5; /* days slipped */

I think pphaneuf will agree with me when I say that there needs to be one object at the top that ties it all together by setting up the initial objects, but it should probably be about ten lines long and do almost nothing.

Okay, I'll stop now.

Perhaps foolishly, I told pphaneuf that I might help him with his XPLC IDL compiler if he would send me some "before and after" examples of what he wanted it to look like. He sent me some pretty crappy examples written by the XPCOM people (WOW! Bad documentation!), but I got motivated anyway, probably due to my still-sucky-but-upcoming manifesto, and like magic... we now have an IDL compiler.

Before, I thought that IDL ("Interface Definition Language") was a general term for languages that define interfaces, and an IDL compiler was a general term for something that turns your general language into a real language (like C++, perl, etc). But it turns out, for those who didn't know, that IDL is itself a well-defined language (by the CORBA people), and it's actually both straightforward and well done. The rest of CORBA turned into a mess, but IDL is a nice little gem hidden inside. Plus, there's a libIDL that even turns it into a parse tree for me.

Anyway, once I got the parser working (using the crazy magic of WvCont to convert the ugly state machine into a simple procedural program, heh heh), producing C++ output was pretty easy - IDL is based on C++ anyway, it seems. Then it wasn't too hard to write C bindings by making very, very dangerous evil assumptions about the format of the C++ vtable (so shoot me). Result: now, like magic, I can access my C++ classes transparently from C with zero overhead compared to C++. It's neat. (The overhead in C++ is also minimal; just the cost of a virtual function call. XPLC doesn't get in the way of plain C++ programming here.)

But that's all normal stuff that people have been doing (badly) for years. I could write a whole rant about how ridiculously bad COM and XPCOM are for no apparent reason, but I won't.

Instead, I will reveal to you the amazing secret I discovered about IDL: it thinks like I do. That's right, while in UniConf I made the simplifying assumption that "everything is a string" and it made everything easy, IDL allows us to make almost the same assumption. Everything is a string or an object. And, as we know, monikers are strings that map into objects.

So I added a feature to my IDL compiler to write wrapper functions for your interfaces. The wrappers *only* pass around "strings" and "objects" (actually, they pass around union objects that are both). You can look up a function by name, then match against its signature to see if the objects you have are the ones it wants, just in case there's more than one function with that name (ie. in different types of interface).

The magic: objects have interfaces, and functions take a "this" pointer that's always an object; but when it comes down to it, that's all objects do. You don't poke around inside them. You don't "serialize" them. They're opaque. You simply try to run functions on them and check the return values to see if they work.

CORBA (and others) screwed up by assuming I wanted to "do stuff" with objects, like ship them around transparently from computer to computer. Big mistake: real life says that I ship strings around from computer to computer, not objects, and I have nothing against making that transparent. And hey, if my objects *want* to have functions to convert themselves to strings and back, that's fine with me - but it's not transparent. It's for them to worry about.

Anyway, it turns out that this model is pretty trivial to get working, and functions that take and return strings and/or pointers to objects happen to be really well supported by SWIG, so I can now access my C++ objects from tcl and (probably) perl and a bunch of other languages, essentially for free. (I only need one plugin per language, not one per language+interface, and SWIG will write most of the plugins for me!)

What amazes me is that it's always been done so badly before. XPCOM claims to do this, but after all this time, I have no idea how to load XPCOM components into tcl or run a command-line javascript interpreter. Why? It should be easy. In XPLC, it'll be easy. (By the way, the XPLC runtime is still only about 26k. Now that we have scripting, there will be an extra cost of a few kbytes for each language binding we want. For reference, the tcl bindings are about 10k.)

I really want to write a "sh" binding to demonstrate how powerful this model is. After all, the shell is great at dealing with strings, and since I don't ship my objects back and forth, I can just have them all live in another process that my shell can talk to. Nobody else's component model has *shell* plugins.

Anybody who wants to follow along can grab my very-alpha-quality code from open.nit.ca's anonymous CVS (project 'xplcidl').

At Ozzy's suggestion, watched Pirates of Silicon Valley tonight for inspiration. Slightly depressed that I am neither a slimy poker-faced business supergeek negotiator (Gates) nor a crazy slave-driving hippie artist (Jobs), and will therefore probably never amount to much. On the up side, probably nobody will make a movie featuring my pathetic roller-skating antics or illegitimate children. It could be worse.

I was sitting today, thinking how unfortunate it is that C/C++ don't have any string quoting operators other than double-quote. I mean, designers of all sorts of languages since then (perl, in the especially extreme case) have figured out that if you want to print double quotes, that's just no fun at all.

Then I realized I was wrong.

#define qq(s) #s

 int main()
{
    printf(qq(blah blah\n "quoted" stuff (and some parens)
        with newlines));
    return 0;
}

Try it. It works.

...but the world is a better place thanks to ipsec_tunnel and patch that makes isakmpd work with it.

IPsec is a grotesque horror story which barely works and is too complicated to be provably secure. That's bad enough, but when crazy bad-quality programmers get into the picture, you get total nastiness - that is, Freeswan.

On the other hand, ipsec_tunnel is downright straightforward, but only because it skips the key negotiation stuff, expecting you to do it yourself. And isakmpd is actually pretty wonky, but only because it has to do a truly startlingly huge amount of complicated negotiation just to make things work out. I'm pretty sure they made it as configurable as they did just so you have to suffer a little bit, just like they did. But other than the big long boilerplate config file (containing words like "QM-ESP-3DES-SHA-PFS-SUITE"), the programmers are pretty certifiably Not Insane.

And after spending more hours today fighting with bugs in freeswan's pluto daemon, I could definitely use some of that.

Meanwhile, we're thinking of taking my age-old Tunnel Vision and making it use IPsec (ie. ipsec_tunnel, in this case) as the packet-transfer layer. That could have the major advantages of throwing out stupid horrible IKE, plus it would let you auto-negotiate routes like Tunnel Vision always does and IPsec never did. The ESP (tunnel) part of the IPsec standard isn't so bad; it's the key negotiation that sucks, so why not let SSL do it for me? Of course, it wouldn't really be IPsec-compatible then.

The other choice is to keep IKE and add a layer on top of that. The advantage there is that you can gracefully fall back to plain IPsec if the other guy doesn't have Tunnel Vision. But that solution makes me feel guilty, because then I'm just making a bad thing even worse. Oh well...

Blech. Capitalism is just a fancy meritocracy, and look what you get. When the judges of merit aren't worthy of merit themselves, weird things happen.

And speaking of capitalism...

I've confirmed it. Spending money doesn't cause happiness, only earning it does. So if earning your money doesn't make you happy, then do something, quick: it's not getting any better from there.

If only you had had System ER. :)

But it's good to have it back. Otherwise I would have had to go through the probably trivial effort of installing NITLog, followed by the non-trivial effort of collecting and converting my previous diary entries, and the depressingly large effort of coming up with my own CSS stylesheet.

Okay, so everyone at work is talking about The Corporation lately, so, as the local representative of the local corporation, I might as well throw in my two cents.

There are two important things to understand about this documentary. First, it offers no evidence for any of its claims; its examples are standalone examples, easily countered by hundreds of examples of non-evil corporations that didn't do any of those things. Of course, the movie doesn't claim to be making claims; it's offering facts. It's just that they expect you to make certain conclusions from their set of facts, and you shouldn't, because there is no logical way to get from those facts to those conclusions. A implies B, but that doesn't mean that whenever B is true, A is true. Don't be confused! So my first point is that this movie is deliberately controversial in order to encourage conversation. You can't learn anything useful from the documentary itself, only from the conversations it causes.

Secondly, they horribly confuse morality and legality. The two are related, but not the same. Corporations are "people" from the point of view of the law; the "owners" of corporations are legally protected (for certain purposes), because the corporation takes the legal blame. Okay, yes, and there are lots of good reasons for this. But people take this one step further, and say that corporations are immoral or amoral because they (and their owners) don't have to take responsibility for their actions.

Wow! Stop! If I'm running a company, and my company does something against my moral standards, then I take moral responsibility. Morality isn't about punishment; it's about my conscience. I will (or should) feel just as bad whether I do something evil or whether I paid someone to do something evil at my request. If people running companies are immoral, don't blame the companies; blame the people.

As a person, I can do lots of immoral things that aren't legally punishable. These are the exact same things that corporations can do without being punished. On the other hand, if a corporation does illegal things, it can be sued, fined, imprisoned (legal sanctions), or put to death (shut down) - just like me.

Lots of corporations do lots of evil things, but don't be blinded into thinking this happens because of some unrelated laws that treat corporations like people. Corporations do evil things for exactly one reason - they're run by evil people. Fix the people, and you'll fix the corporations. Or make enforceable laws about specific evil things, and the corporations, like people, will have to comply.

This weekend I was going somewhere Southwest of my apartment, so when I left my apartment, I started by going East.

Well, I wasn't in that big of a hurry.

I only went one block East, then I turned South, walked down that way, and went West to get to my destination.

The thing that interested me about this was when I realized I had never travelled that route before - the street one block East of my apartment is pretty nice, but I never use it. Everywhere I want to go is always to the West. I've tried pretty much all the routes that involve travelling "strictly non-East", but this time I got to see a lot of different, interesting things, just by allowing my path to stray a little bit.

I do have the tendency to overoptimize my travelling. I suppose most people do. This is why we need NonDirectionalFridays at work - although we often neglect them. That's dangerous, because it limits our perspective.