Giles Bowkett: IRB: What Was That Method Again?

Giles Bowkett: IRB: What Was That Method Again?

Well, #methods is a good start. But it doesn't capture the method_missings. This shows just the power as well as the shortcoming of ruby and rails: You can't look everything up, you need to know some parts.

On another note, I'm just working on a small code generator that turns a protocol spec (of a proprietary thing) into java classes that offers the protocol commands as connection object methods. It's actually the same thing: We decided for the code generator, because that way, the IDE can show what is there; were we using annotations, this wouldn't be possible and things more dynamic. This isn't the whole cause; performance (as of exceptions, not primarily reflection) also played a role.

Still, I'd rather like to do the generation within the java compiler, which would save us some subclassing.

The generator itself is not in java, but in haskell, because of parsec, and generally to do some actual hacking in haskell. I like it; it is very nice when you change some definition and the compiler tells you the places you need to adapt.

Quoting haskell

Well, Haskell is getting really interesting. I always wanted a language that allows me to intersperse fragments of other syntaxes (especially for a message syntax; think s-expr), and on the haskell workshop was an interesting talk about how to introduce exactly that for expresssions and even for pattern matching.

Right now I struggling with the right way to approximate the same in java, and bump into acceptance problems from some sides, whether I go via annotations or some code generation.

It's not that haskell isn't still rather foreign on me. I think I have a hint of understanding monads, but this doesn't go anywhere near how to design them.

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.

Synchronizing

It is a longstanding problem of how to really synchronize mail folder, schedules etc. between home and mobile computers. Again, I can't remember who observed that originally. But the problem is about to dissolve instead of being solved, simply by being always online and no longer needing multiple replicas of one's data.

Now, a similar thing has happened before: There has been tremendous effort to make precise clocks as these were needed to get exact coordinates in ship navigation. You were on sea for months and did not want more than a minute of error. Then radio came and soon allowed worldwide transmission, and the need for mobile precision clocks disappeared.

Spell checking

A blog post completely irrelevant to this topic complained that some software's spell checker did not know firefox and some others. Reminds me primarily that I practically never used them. The wiggly red line just had too many false positives. I seem to have a rather good spell checker built in anyway, and I wondered what an external checker would do to the internal one.

I found a strange analogy. This year I had a hiking stick (of the old-fashioned kind), and in the mountains it still had snow. The stick proved very useful to keep the balance crossing small snow fields, or, more exactly: It made me feel saver, but it damaged my ability to cross them without its help.

Although this analogy is quite probably limping, I shall continue to stay away from spell checkers. And let haskell check my spells.

Drowning in the swamp of pixels

Yesterday it hit me hard. I 'just' had to fix up the logging of an application (which enables it to reconstruct its exact state after a crash). Unfortunately, it wasn't my application in the first place; I just had to 'fix' it. And all kinds of annoyances came together...

It was a shared office, meaning occasional meetings and all kinds of small discussions happening right behind my back. Pretty much impossible to build up any concentration in these phases, not even for reading blogs!

Then I had my laptop at 1024x768 and the local PC with 1600x1200 on its glass monitor. Problem: Apart from some silence I needed the big screen estate for actually getting all relevant code in eyesight. But unfortunately looking at that monitor only made me wonder what was wrong with my eyes; I couldn't actually focus on reading. In the old office it was just working for me, in this new one it didn't any more.

So I was getting desperate: To be able to actually getting anything done I needed to head back home to the fullsize LCD screen. The alternative would be to start massive notetaking, which is a form of thrashing and would just kill productivity as well.

I never experienced either workspace disturbances nor bad equipment that hard before, and now I am considering to buy another LCD for that workplace. Probably some silencer, too?

Flying

When aboard a plane, give me a seat and a window, and I'm happy. Give me a stewardess telling me to close the window so that the sun does not keep the guy on the other side watching the move, and I'm not happy.

Looking around in business class I notice that most people don't care at all that they're just experiencing mankind's dream come true. As Richard Bach said, this is aviation, not flying, and thus these people don't care just how they get to Cairo, only make it fast. And that happens to be by air. Since most of them aren't good at waiting for the arrival, there is also a lot of entertainment of diverse kind abord.

Who would book a flight just to be able to watch a movie? And yet that is exactly what happens: Sit down and turn on the flick, even one they wouldn't think of going to the movies for. Just because there isn't anything else to do. Remember: When you're bored, it's because you're boring.

The trick of flying isn't, by the way, to fling yourself on the ground and miss it, as Douglas Adams had it. Actually, that's orbiting. You need to stand high enough and throw yourself not directly to earth but a bit to the side, and voila, your in a rather elliptical orbit if you manage to actually miss the earth (and the atmospehere). Flying is simply to throw down enough air so that in exchange you can stay up.