Older blog entries for apenwarr (starting at number 95)

Observations from my Trip to London

1. You can't say "Trip to London" without people assuming you mean London, England, even though I actually mean London, Ontario. For some reason this doesn't happen with Waterloo or even, irony of ironies, New England.

2. The Pontiac Pursuit is the first car I've driven in a long time that continually makes me think "awesome." Apparently due to my complete lack of media input lately, I'd never even heard of it before yesterday. Their web site even talks about its pulsating performance - as if it were a chicken, of all things! I wish I needed a car.

3. After two days spent essentially in tech support for someone else's product, I now hate programmers even more than ever.

3b. Also, Windows sucks much more than I usually give it credit for.

3c. So does everything else, particularly commercial database servers and anyone who has ever written "sleep(10)" for a "wait for operation to complete" function. I suspect those people are often one and the same.

Java constness and GC

pcolijn wrote about some things he likes/doesn't like in Java. I'm going to disagree with one from each category:

constness: I think you have your inheritence backwards. An immutable instance isn't a subclass of a mutable instance where some operations (gag) throw exceptions by surprise. No, in fact, a mutable instance extends an immutable one. In other words, start with the immutable interface, which only has getThis(), getThat(), etc. From that, derive an interface that adds setThis(), setThat(), etc. People require one of the two interfaces on their objects, and all is well, and you didn't really need const after all. The method you suggested - pretending to implement the mutable interface and then throwing exceptions - is like doing exactly the same thing in C++, and just as evil. On the other hand, in C++, a parent class can talk about a function with "const" whatever, while a child can implement the "non-const" whatever, and things will work sensibly. But if you think about it, that's just the same as what you can do in Java.

Now for the part about Java you do like: garbage collection. I'm actually a big fan of GC as a concept, because the idea of not crashing all the time because of randomly overwriting memory kind of appeals to me. However, I've learned two important things about GC:

1) Not having to explicitly delete things doesn't actually mean you don't have to explicitly think about object deletion; it just makes you think you don't have to think about it, which is much worse. Hence, where C++ programs tend to have explosions, Java programs (seemingly universally) have nasty memory leaks and no good way to find them (because they're not "leaks" in the usual sense; if nobody had a pointer to them anymore, they would be auto-deleted). They also have non-deterministic destructor behaviour, which is very restrictive. A GC language is good as long as people actually think about object lifecycles, but my experience is they don't, and so GC's don't solve anything. (If you think about object lifecycles to the extent that you have to, then you turn out not to need GC because your smart pointers will all do the right thing.)

2) I heard that Java object creation/deletion is so slow that people tend to use "pools" of object types that are created/deleted a lot, and explicitly place those objects into and out of the pools. You know what that is? It's bypassing the GC so you can get explicit memory allocation/deallocation. Snicker. Again, this is nothing against GC specifically (which can be quite fast), but it's definitely a sign that all is not right with the world.

31 Dec 2005 (updated 31 Dec 2005 at 20:28 UTC) »
UI Design and iPod Movie Conversion

guspaz is working on a Windows program called iPodDrop. I don't run Windows and don't need any such thing, but he was looking for suggestions on how to get more people to use it, since the alternatives apparently suck (which is not really very surprising).

Some suggestions:

First, drag and drop has largely been a UI failure. Dragging a document from one open folder to another folder - okay, makes sense. Dragging it from an open folder to a folder *icon*: suspicious, but okay. Dragging it from an open folder to a *program*: forget it, you've just blown your metaphor and lost 99% of your audience. The problem is that people don't take real-life documents and, say, smack them against a toaster to make them do things. When you have a toaster, you operate the toaster, not the toast.

Try adding an option to the Explorer right-click menu instead. (It's easier than you think.) The nice thing about right-click menus is that there's no real-life metaphor for them at all, which seems to upset Steve Jobs but means that people have an open slot in their minds to absorb the concept (eventually). Now that they've absorbed the idea that "right click = give me a list of actions to do on this object," adding new right-click menu items is the way to go. (Supporting drag-and-drop in *addition* to that is perfectly okay.) Right-click is a metaphor I'd actually love to extend to real life. Imagine right-clicking your bread and telling it to "toast." Saves me running around looking for my toaster.

Second, Windows users *hate* programs that have no GUI. Haven't you noticed? Millions of people will need to recode videos for their iPod, but maybe 0.1% of them want to use a command line program to do it. This goes beyond the badness of drag-and-drop; if you want users to be happy, you'll need to pop up a window with a few toggles, go and cancel buttons, and most importantly, a completion bar.

Third, as for getting more users for your software, you should see about getting it bundled with some spyware. Spyware is the new DirectX. People download and install spyware on their systems like crazy for some reason, and all you need to do is tag along by being included in the same installer package. Lots of other popular programs, especially ones dealing with "media sharing," are being distributed the same way.

Irony

What Unix does well isn't what people want.

-- Rob Pike

Trancendental Philosophical Musing

wlach: I see the difference between the two views of "idealism" you posted, but they don't seem incompatible, only different. That is, a particular ideal is an idea that (as a philosopher might say) can exist separate from reality; in fact, if ideals are "how things ought to be", reality often doesn't really enter the picture. But there's nothing stopping us from having an idea that is also real, or from having an ideal that can be achieved. The two things aren't identical (not all ideas are ideal), but perhaps one is a subset of the other (are all ideals ideas?).

Anyway, I would argue that the article I linked to earlier is at least relevant to the particular metaphysical goop I was spouting at the time. :)

Quality Assurance

We were terrible, but we thought we were great. It doesn't matter how terrible you are if you think you're great.

-- Yanni

I actually quietly attended the Desktop Architects conference in Portland, but avoided catching up on the mailing list about it until now. Thanks to Burgundavia for linking to the Linus thing. Here are some of my favourite quotes from the discussion.

Non-compromise

The majority of end-users want a simple printer dialog. In fact most people will just hit the Print button without changing any settings. These users are not 'idiots' they just have better things to do then futz around with printer settings. On the flip side I'm sure there are many pre-press publishers who want to tweak and change every setting. The two design goals do not have to be at odds with one another. A good design will satisfy both.

-- Gregory Raiz, Windows developer

Focus/Multifocus

To put it in mathematical terms: "The Intersection of all Majorities is the empty set", or its corollary: "The Union of even the smallest minorities is the universal set".

It's a total logical fallacy to think that the intersection of two majorities would still be a majority. It is pretty damn rare, in fact, because these things are absolutely not correlated.

-- Linus Torvalds, kernel developer

Amplify

When user interfaces means that something CANNOT BE DONE, it's not about "usable design" any more. At that point, it's about UNusable design.

Any Gnome people who argue that it's about "usability" have their heads up their asses so far that it's not funny. I've argued with them about this before, and I know others have too, and mostly given up.

"Usability" is an issue only if you can do something at all. But if you can't do the thing at all, it's pointless to talk about usability: the thing is BY DEFINITION not usable if it cannot be used for a specific task.

-- Linus Torvalds, again

Non-Simplify

If I have an overall point here, it's that all of us who are maintainers should be willing to make choices and take the heat, and that it breaks our ability to make good software if we start thinking "all things to all people," or "I can't do anything, so I'll just punt or bow to the flames." Either we have something to contribute due to our professional skills, or we don't. Users (like Linus) vote with their feet on whether we contributed the right things for them personally, or focused on someone else instead, or just failed to do anything useful for anyone at all.

If nobody uses my software, I want it to be my fault. And the same if they do use it. Why else would I bother trying to be better or worse at my profession?

-- Havoc Pennington, designer

Not Taking Things Too Seriously

Seriously, this has been entertaining. And I think Linus has made a lot of good points that certain people in the GNOME world should make an effort to take to heart. I found myself nodding rhythmically as I read most of his mails, even if he was being a big jerk half the time.

-- Nat Friedman, person who doesn't take things too seriously

Arcnet never really dies, it just gets weirder

Avery,

It is by fear that I email you in hopes that if your voice is as bad as mine. You won't sing! Actually I am going to be trying out your drivers on some fairly new cards using the SMC COM90C65 or 66 chips. Once I get the network working on twisted pair (Point to Point) I will be making some modifications to make the network Wireless. I may need help to gain control of the TX indicator output on the chip. I am hoping I can use it as a PTT for the transmitter.

Best regards.

If he pulls this off, he will be my personal hero.

Pragmatic Idealism

Yesterday one person accused me of being an idealist, and someone else overheard that and commented, "Someone says Avery's an idealist? I've got to hear this!"

I've spent a lot of time not being an idealist, because idealism, almost by definition, requires rejecting reality. I've done my best to be a good realist.

But I've really always wanted to be an idealist. It's just that if you understand realism, you can't just leave it out of your idealised world view; that wouldn't be very ideal at all. Most idealists are lucky, because they can't see the contradictions in their ideal world view. Since they can't, they can be successful idealists, although it won't do them all that much good in getting people to believe them. If you understand reality, it seems that accepting idealism is a compromise.

But what if you could come up with a system that was ideal (ie. solves its problem space without making compromises outside its problem space), but also implementable? I guess you might call that pragmatic idealism.

One good indicator that you finally understand something is that your invented name for it agrees with other people. For example, various modern philosophers discuss pragmatic idealism.

Obligatory Link to Open Source

Also, a google search for the term led me to Richard Stallman's Pragmatic Idealism essay, which I suppose takes us full circle. (rms's idealism is not really the same as mine. My idealism is based fundamentally on people being in agreement - since disagreement is a compromise - while his just politely excludes such people. But a situation that excludes such people is compatible with a system where such people don't need to exist.)

16 Dec 2005 (updated 16 Dec 2005 at 15:59 UTC) »
Snowtime in the Hinterlands

I live at the top of a hill on a busy street. In the summer, this can get loud. But in a snowstorm it can get ridiculous.

people helping people (and thus making me feel slightly guilty for just laughing at them)

people helping people until they stop at a stoplight (urban planning at its finest)

public transit triumphing until it stops at a stoplight

Who's happier here?

Very rarely, but sometimes, I'm just happy to have a digital camera.

Moral of the Story

There are several morals to this story. First, don't live on a busy street unless you own earplugs.

Second, when stuck in the snow, don't spin your tires!! As soon as your tires start spinning, you have only dynamic friction, not static friction, which means you have much less chance of succeeding. Plus, if the occasional loud crashing noise is any indication, when you do eventually find some traction, you take off rather quickly by surprise.

Third, it's December. Seriously, stop using your summer tires.

Fourth, SUVs actually do accomplish something. Minivans do not. I'm sad not to have a video of the ambulance I saw pushing a minivan up the hill just so they could get through.

Fifth, nobody except me ever learns these lessons, because everyone down there thinks they're somehow unique and will somehow get out of it just by spinning their tires. But two hours later, I can, with great confidence, say that it's a losing strategy.

Special Thanks

As always, special thanks to NITI for having their bandwidth sucked by these videos. But I may have to pull them soon in the name of, you know, not wasting money.

Stability

Tonight someone read me a story about resistance to change. Just sitting in on a story reading was kind of strange by itself, but that's not the point.

What struck me is that I totally understand the point of view of the people in the story - their fear of things changing out from underneath them. But I'm exactly the opposite. I have a fear of stability. If it's too safe and predictable, I quickly start to feel trapped. At the same time, I don't think I'd be terribly freaked out if I lost my job tomorrow and had to move to Mexico doing a job I've never done before. As long as there was something I could do about it, it would be okay.

I've heard people tend to grow out of that eventually. What a depressing thought.

Motivation, Part 2

I don't remember who, but a few people have told me in the past that salary is not a motivator - but at worst, it can be a demotivator. I don't know if this is true for everyone, but I think it's very true for certain kinds of people, particularly software developers. If they're getting paid enough that they're satisfied with it, paying them more won't make them work any harder.

I think there are basically three states of motivation:

- demotivated (negative)

- motivated (neutral)

- hypermotivated (positive)

I like to believe that, by default, most people are in the "motivated" state. That is, by default, most people want to do useful stuff rather than sit and not do useful stuff. Maybe I'm wrong, but in any case, I like to at least think that we don't hire people who are unmotivated by default, so it doesn't really matter if literally everybody is the way I think they are.

From this neutral state, you can go in two directions. The things that take you in one direction versus the other are actually unrelated to each other. More of thing A might demotivate you; less of thing A might demotivate you less. But no amount of it, or a lack of it, will ever hypermotivate you.

For example, you will never achieve hypermotivation because we pay you more, or give you clear (instead of unclear) specifications, or don't chain you to your desk and whip you, or don't make you play kindergarten-style HR role playing games.

It's unlikely that you'll become actively demotivated because we don't have a foosball table, or because we don't have an inspirational leader, or because you don't believe the work you're doing can really change the world.

The fact is that merely motivated people can do really good work. Some companies do just fine running entirely on merely motivated people. It's just that hypermotivated people can do even more... lots more.

I've written a lot lately about the two sides of various issues, and the fact that not compromising, but instead maximizing both constraints, is the only way to really succeed. For example, you research, write, and comply with excellent functional specifications in order to make people not hate your product; you do excellent design in order to make them love your product.

Companies and motivation work the same way. Carefully following some boring, well known HR guidelines to avoid the common demotivators can make people not hate working at your company. (Avoid the stupid parts of the well known HR guidelines, though, because some of them are demotivators themselves.) But hypermotivation isn't just about removing demotivators; you have to also have the right hypermotivators in the right places. For every person, those hypermotivators are different.

Not many people are hypermotivated; of the people that are, I'm not sure they could honestly all tell you exactly why that is. I think I'm in that category. But not knowing those things gets in the way of sharing those things with others.

86 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!