Blub at large

There are actually blub programmers who are not too shy to boast their status. Not only that, they point to the very people explaining their misconception and don't get it. They also manage to create a website that tells you that you need to login only after you click the comment link, and provide no visible of means to create a login in the first place, which is the reason for me posting this here.

(Seems the site has been dead for a while.)

Trust and Guarantees

Bertrand Meyer had me laughing for a change. Obviously trust doesn't mean the same in computer science as it does in normal life; he wants to build 'trusted components -- reusable software elements whose quality can be guaranteed'.

The department of defense actually uses the same misconception: They are initiating a program for verifying the functions of chips manufactured abroad, and call this program TRUST.

Now trust implies that we don't know that a system has a specific property; we assume it has, on more or less sound reasons. Guarantees come via control, at a price. It's the same as in project management; either you have people you can trust to deliver results, or you need processes to control the output (and hopefully only of those you can't trust).

Blogger oops

Blogger does not give me the delete button, and it should also not have posted this twice.

Learning at the barber's

I accompagnied my wife to the barber's recently. The cutting looks so easy, everybody should be able to that! (Just like software.) I kept looking and learned. Even though it looks like he is just cutting away, he doesn't. There are different movements for the different stages, and there are tricks to check if the (long) hair has the same length on both sides.

Learned: To make it look easy you need to know what you are doing and what you can do. The last part, your options, are the hard part. You can't just bash away (at the scissors or at the keyboard), you need the confidence that you can handle upcoming difficulties.

Shackles of Compatibility

The Shackle of Compatibility means you can never recover from mistakes in language design.

Well, I don't think so. If you do an incompatible feature you could just make it possible to enable and disable it. For example the newest rage amongst Java programmers is to declare every variable and parameter final. This is intended to catch accidental (as opposed to purposeful) variable reuse, which is a good idea.

But it is questionable whether sprinkling the source with final isn't too high a price. Ok, you can't just change the language semantics to have final be the default. But, why not make it switchable? Add something like pragma "default_final_vars";, and enjoy the best of two worlds. Old code stays as it is, new code can be not cluttered.

Similarly, any language could make the subversion or misfeatures selectable.

Of course there is a drawback as you must be aware which dialect is in use. But you need to do that anyway since many of the mainstream languages look pretty similar to each other.

Speech recognition

Giles Bowkett argues that every programmer should develop a personal style,
and Andrew Norris responds that this is not a good goal. He seems to think that this is akin to writing Fortran in any language.

I don't quite agree. Personal style should be orthogonal to the style imposed by the idioms of a language. It reminds me of speech recognition, which can have several outputs: First, the words spoken. Second, who's talking. Third, the mood of the speaker. I don't have experienced 'speaker recognition' (that isn't tied to idiom usage) in source code yet, however, and can't quite think how that would look like.

I do remember, however, reading a german book about electronics, whose tone was just slightly unusual. It turned out to be a translation from finnish.

Desperate...sort of

I'm back from holidays, and I just scan the blogs and don't get started with work. A year or so ago I stopped reading usenet, and now it's blogs... Anyway, finally I did start work, and then almost got desperate over my brain not immediately wrapping itself around every line of code of that smallish programm I'm supposed to extend (in a way rather cross to its design).

At the same time I wonder why I read so much about Haskell et al where I should be wanting to do some work with it. I got it into my head to attend the haskell workshop end of september which is conveniently located quite close this year.

I even got the strange idea of giving a talk there, about solving a relatively specific communication problem in haskell. Problem: I haven't used haskell for more than ten minutes yet and thus doesn't have hardly any idea how to implement it at any level, the submission deadline is in mid of june, and I have sufficient urgent real work on my desk to fill most of may.

So if I'd be any serious about that I should be prototyping haskell like crazy instead of continuing to read blogs, shouldn't I? Seems not... At least I'm not alone with programmers block.

And they I am not sure about the motivation for the workshop. See exciting things, maybe get a gig, or both? I suspect mostly academia there, so not much of a commercial opportunity.

So many ideas, so little time, and drive.