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.