Programming language designers: reclaim the bitwise operators!

Considering that:

• most programming work does not access the machine's hardware directly, and
• using bit fields for memory optimizations is not necessary anymore in most cases, and
• bitwise operators use several really enviable characters (~, &, ^, |, for example,) and
• bit manipulation can be handled with a simple library and does not need to be built into a language,

I say: stop copying these operators from new language to new language! They were an important part of the C programming language, which is to this day twiddling uncountable amounts of bits per second. For a new, non-system programming language, they are extremely out of place.

Finally we will be able use & and | for boolean operations instead of && and || !

Lost my religion

A few months ago, I was involved in a rather disastrous project. After consistently pointing out the problems we had, I was told by the person who should have been solving those problems to either quit complaining, or leave. Since I couldn't live with the constant frustration of clearly seeing issues but not being allowed to even talk about them, I left. It was a great relief, although I feel a little bad for that team, since it still has the same problems.

I've been claiming to be an Agile guerrillero for quite a few years now. If I enter your organisation, you will slowly see things change more and more into the Agile direction. A typical bottom-up person. Sadly, trying to get the disaster team on track with the guerrillero approach took so much of my energy that it dominated my life. That's not something I want to happen again. That made me rethink what I had been fighting for.

A way to get my actual programming work done with the least amount of overhead and frustration. That's what it was. I called it Agile.

The whole company has been transitioning to Agile for a while now. Well okay, everybody calls it Scrum here, because that's the only thing people hear all day, so much that most people can't tell Agile and Scrum apart. Remind me to complain loudly about Scrum someday. The company and I are not talking about the same Agile. I'm certain that I understand the spirit of Agile, and that major parts of the company do not (yet) understand. But who am I? I cannot convert the company on my own when so many people are either completely uninterested, misled, or actively frustrating an Agile revolution.

But that's fine, since fighting for Agile should never have been my goal. Getting rid of overhead and frustration; that's the goal, whether it's taking ideas from Agile, Lean, or even waterfall. I don't need a revolution, and most companies do not want or need one anyway.

I hereby cancel my membership of the Church of Agile.

Learning JavaScript

I'm currently learning JavaScript because, sadly, it's the language that runs the HTML5 canvas, the most accessible platform for games in the future.

Learning JavaScript is a disaster. Just like when I was trying to learn ActionScript, I keep finding articles all over the web written by badly informed people. People who are so happy that they got something to work by copy/pasting stuff together from other places that they will post it on their blogs, announcing it as the new state of the art. Some will write complete sites with misleading and/or incomplete tutorials.

Bah.

Addition: this is the kind of article I want to see. It's concise, it's clear, it's correct.

Eclipse Xtend

There seems to be very little hype around the Eclipse Xtend programming language. That could be because it doesn't really stand out, and has an air of hobbyism about it.

But Xtend is very different from every other new JVM language! Not because of the language it is, but because it offers a very good Eclipse plugin, and because it compiles to Java. Both of them make this language very easy to pick up. You can start using it at work right away. Or, maybe wait for the Maven plugin.

Do yourself a favor and install it.

Update: looks like they kept their promise for a much improved version - it looks complete now!

The state of Ogg on Java

Ogg Vorbis and Theora are great free audio and video formats. There are no great Java libraries for them, though.

Ogg is the format for streaming data. It does not say anything about the data it may contain. Inside Ogg, we can have Vorbis - audio data like mp3, and/or Theora - video data, and/or more.

Xiph, who made the specifications of all this stuff, started out with a few reference implementations of these in C.

• JOrbis is the most common implementation of Ogg and Vorbis. It's a very ugly port of the reference implementation, but is also quite complete.
• vorbis-java is comparable to JOrbis, but even though it's hosted on Xiph's site, it seems to have been a one-off hack project of some guy.
  
• J-Ogg is mostly a clean implementation of Ogg, Vorbis, FLAC and Theora. The code looks nice, but the implementation isn't finished. Vorbis and FLAC are good enough for most cases, but Theora support does nothing much yet.
• Cortado is a collection of libraries - JOrbis in combination with some Fluendo stuff, like a Theora decoder. The most important thing is that this library is under active development (probably motivated because it's being used by Wikipedia,) whereas the others haven't received any updates for years.

None of these options make me very happy. Still, Cortado should give the best overall options. And none of these libraries are available on Maven. Hurray for dependency hell!

Some thoughts on e-readers

After having an e-reader for a month and using it a lot, I have gathered my experience with it here.

Good points:
+ you can store an unimaginable amount of books on it. Within a few hours, I had half a bookcase of books on it. That was before I added an SD card. I'm not sure if I can still claim ownership of these books on librarything though, that would feel strange.
+ it's very easy to carry along - especially my 5" reader. The screen size is not a problem, because all the text should be resizable. In theory.
+ the screen is well readable thanks to the e-ink technology. There is no backlight that shines in your eyes, and there is not much glare.

Bad points:
- Flipping pages is slow. E-readers are best for reading a book from start to end, and are less suited for browsing around in a book. A search function helps.
- It's really obvious, but I never thought about this before I bought it: there is only one device. I read books in bed, in the living room, in public transportation, at work, on holiday, and I have to lug the one single e-reader everywhere. I think I'll buy a few more once they get cheaper.
- The major point: file format support is really shitty. There are some formats that support reflowing well, but formats like PDF and plain text don't. The device tries, but often makes an unreadable mess out of it. As a programmer, I would say that it's logical to parse all file formats into a single general format, then pass that to the module that renders pages to the screen. Not even that is true. All file formats render differently, and have different abilities. Some can be zoomed five times, some resist zooming. Some can be rotated, some can't. Some have a table of contents that can be navigated, some don't. None of them show page numbers and the total page count correctly.

Now, that last part may be partly the fault of my particular model, but I've seen more complaints about other devices.

(Mine's a bebook mini, by the way. It's a rebranded Jinke V5.)

Who needs exception handling anyway?

Ok, disregard all my previous posts about exception handling. I think I finally understand why Scala doesn't really do a lot about it: it has constructs that handle the checked exception cases very well.

Here's the discussion that made me realize this. The summary would be that with classes like Option and Either, it's possible to return the normal result of a method, and sometimes return something exceptional. Option lets you return the results or "none." Either lets you return one of two types of results, and the documentation already states how one of them is seen as the normal result, and the other the exceptional result.

Scala supports these kinds of classes very well, so it seems that there's not much of a reason to demand checked exceptions anymore. The only runtime exceptions would be the ones that are considered fatal (out of memory) or programming errors (division by zero.) They can still be caught, but not many people would want to.