July 30, 2010


You know, I have a Master's degree in software engineering and a Ph.D. in Computer Science, but now that I'm a Sun Certified Java Programmer people can finally start taking me seriously.

July 24, 2010

Tron Legacy

To quote from the original: "Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes."

July 22, 2010


This is my 100th post (jay!). I was wondering what to use it for, but now I think it will just confirm me as a TED fanboy.

Is it just me or are we going through a wave of alternative input devices ? First we were waving a WiiMote, then we were going multitouch on everything, then we've got camera's following our every movement, and now we can think about something and it just happens... Things are going crazy.

This has some implications though. If you're a developer your apps are going to get more complicated, and so is your coding. I mean, how do you really program for these kinds of devices ? Simple frame-based interfaces are not going to cut it anymore. And simple onClick handlers will no longer be enough. I hope that the creators of these devices understand that. The device itself is just half the story. Making it usable by everyday programmers is another.

But even beyond the developer's troubles lies this: people are going to be much more sensitive to computer responsiveness, or really its lack thereof. I recently noticed that when I get into a state of flow the slightest interface hickup can throw me off. Simple example: typing and the computer not being able to keep up with your input because it's too busy doing something else. Or typing in an input box and then some other app takes focus and suddenly you have to start switching back and restart. (This is a major annoyance to me. Really, if a user is typing in something don't shift focus away from that !!!) Now think what will happen when our control becomes ever more complex, more finegrained and more subtle. Consider what happens when you have all these devices working hard to blur the line between you and your computer and your computer can't follow you fast enough... I think this is frustration waiting to happen.

And that's were I think this technology will stand or fall. If it can truly make itself invisible then it will score. But if it gets in your way for any noticeable amount of time you'll start hating your pc again.

Well, I guess my 100th post was not just another look-at-this-cool-ted-talk. :-)

July 13, 2010


Remember my rant on trying to find a better language for programming enterprise applications ? Well, Rust might be a valid candidate. Here are some of its features as found in the FAQ:

  • Memory safe. No null pointers, wild pointers, etc. Automatic storage management.
  • Mutability control. Immutable by default. No shared mutable state across tasks.
  • Typestate system: ability to define complex invariants that hold over data structures.
  • Very lightweight tasks (coroutines). Cheap to spawn thousands-to-millions.
  • Multi-paradigm. pure-functional, concurrent-actor, imperative-procedural, OO.
  • First class functions with bindings.
  • Structurally-typed objects (no nominal types or type hierarchy).
  • Multi-platform. Developed on Windows, Linux, OSX.
  • Practical rule-breaking: can break safety rules, if explicit about where and how.

Actors, first class functions, cheap coroutines: Rust definitely is a contender. I'll have to keep an eye on this one.

July 07, 2010

Koopa 1up

I just updated the Koopa Cobol Parser with a new version. It now supports parsing Cobol code in either fixed format or free format. Don't know what I'm talking about ? Here are the definitions as found on COBOLPortal:

Fixed Format Source - Each COBOL source line consists of 80 characters which are divided into various fixed areas. There are restrictions on the syntax that can appear in each area.
Free Format Source - Each COBOL source line can consist of up to 250 bytes of characters. There is no restriction on where syntax may appear on the line.

I don't restrict lines to either 80 characters or 250 bytes (note the difference in units btw.), but other than that it should be as described.

The GUIs and the command line application have been updated to give the user the choice of which Cobol format to use. Default is fixed. Just pick what you want in the "Parser settings" menu, or by passing "--free-format" as an option on the command line.

As usual there is an executable jar available on the sourceforge project page.

Message from my one year old daughter

^^plp^l ,k ,j v, ,j , ,, n,n,,, jm=àj yjv bjuèèvè ,y§ zwed b jv bhniii ijn hhhhh§èt n§§b§xr y®‹≈r rrcxyhhhhhhhhhhr rh f frfrèy

I'll leave figuring out what happened to you. :-)