Nokia’s VP answers some questions

Suggested reading at Engadget. It took them long enough, but Nokia just might be able to pull off a turn-around. The hardware of the N8 looks nice and the MeeGo OS is built on the solid foundation of Linux and Qt. The Nokia Vice President also seems aware of the challenges they are facing and gives refreshingly non-marketing answers (such as Symbian’s menu-based navigation not being a good match for touch interfaces).

Coolest photo bomb ever

A couple wanted to take a self-time picture at Banff and a ground squirrel got in the way. [details, original source]

Clark on cluelessness, Clarke on what is possible

I think this law has psychological applications, too:

Sufficiently advanced cluelessness is indistinguishable from malice. [J. Porter Clark]

Also fun—Clarke’s three laws:

1. When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is probably wrong.


2. The only way of discovering the limits of the possible is to venture a little way past them into the impossible.


3. Any sufficiently advanced technology is indistinguishable from magic.

How to board a train that never stops?

Answer: You enter a capsule that is dropped on top of the train as it enters the station, while another capsule that was previously on top of it stops at the station. Check a YouTube video for details. Presumably, such a train would be more energy efficient than one that has to stop at every station. It reminds me of Arthur C. Clarke’s idea (in “Profiles of the future”) of having running strips as public transportation. One enters an outermost strip which runs at a low speed and proceeds to inner strips that become increasingly faster. [Source: Der Spiegel]

A light rail train that drives around cars

Source: ChinaHush

Cool idea: China is working on a light rail train that has a hole inside so that cars can drive through it. That means that it can use the same roads as cars, without occupying additional space. And even while it stops, cars can continue to drive. Compared to a subway system, routes are much cheaper (10%) and quicker (1 year versus 3 years or more for 40km) to build. But how is this better than a single-lane light rail train (in Munich, some of them share a road with cars)? No tracks in the road? I’m sure that could be fixed by using non-track wheels and some sort of automatic guidance.

[Source: Huffington Post]

Google Wave is dead

It was bound to happen: Google Wave is dead. Google Wave has always been a problematic product: What does it really do?

(*) What is wrong with email, instant messaging, forums, and collaborative editors? Why do they need to be merged into a single product? It was a typical Google product: Technologically very impressive, only for technical people (I have yet to meet a non-technical person that has used it), abandoned after a short while.

By the way: If anyone has an answer to (*), I would love to hear about it.



Update 2010-12-25: Google Wave has now become an Apache project.

I’ve thought about it some more and there is something intriguing about continually updating information and tracking the changes that are made. But a wiki that allows one to follow changes should be enough for that. Instead, Wave conflated this kind of documentation with instant-messaging-style brainstorming. I suspect that keeping brainstorming fully documented does not make sense and goes against the human tendency to maintain order by throwing stuff away and/or transforming it into something new.

Why we are actually writing getters and setters in Java

I now often hear the opinion that writing getters and setters has something to do with better encapsulation, that using “naked” fields is bad practice. To find out if this is true, we have to look at Java history. In the mid-nineties, Sun developed the Java Bean Specification as a component model for Java. This model was supposed to help with tool support for Java, e.g. when connecting a graphical user interface with domain objects. In this case, it is useful if one can observe changes made to fields and react to them (e.g. by updating the text displayed in a window). Alas, while there are some languages that allow this kind of meta-control (Python and Common Lisp come to mind), Java does not. Thus, Java Beans introduced standardized naming that allowed one to implement a field as a pair of methods which then would manually implement the observation.



I usually code as follows: If I need just a field, I use a public field (no getters and setters), because it helps me to get started quickly and introduces less clutter. If I later change my mind, I let Eclipse introduce the indirection of the getter and setter. That means that there is no penalty for such a change and no need to think ahead! Granted, having both public fields and getters/setters affects uniformity, but the added agility is worth it for me.



Obviously, it would be nice if Java had true observable (and optionally computable) fields. This feature was initially on the table for Java 7, but did not make the cut. Maybe IDEs could help by displaying getters and setters as if they were fields. Their source code would be hidden, with visual clues indicating if such a pseudo-field is read-only etc. Additionally, auto-expansion would be improved, because pseudo-getters (such as Collection.size()), getters/setters, and fields would all be part of the same category. No more typing “.get” and hoping that the information that you are looking for is available as a properly named getter. The same kind of grouping should also be made in JavaDoc. Lastly, one could display foo.setValue("abc") as foo.value = "abc". But I’m not sure if that makes sense.



Addendum (2010-08-07): I think I did not make my point clear. It was not “use public fields”, it was “don’t use getters and setters blindly”. I’m applying the coding style mentioned above during an exploratory phase of coding. IDEs such as Eclipse allow you to do this kind of quick and dirty exploration because real getters and setters are always just a refactoring away. I do agree that, as soon as the API and its client code are not in the same code base, you cannot do these refactorings, any more. Thus, you have to think ahead and freeze some things.



As for generating getters and setters: Yes, Eclipse does that for you. It even expands getFoo into foo getter source code and setFoo into foo setter source code. And it can also rename the setters and getters for you while renaming a field. Even then, getters and setters still add clutter.