Asus Eee PC: First Impressions

Good heavens, it's small, and I got the one with the whiny fan.

The screen, while low on density, is easily readable indoors, and adequate for my needs. The LED backlight is adjustable via Fn-F3/Fn-F4. It goes to sleep via Fn-F1 in about 3 seconds and comes back with the power switch in about 5 seconds.

Typing is... challenging, although I suspect I'll adapt with a few days use... So far the only stumpers have been the right-hand shift key (it's small, and I often hit the up-arrow by mistake), the number keys, which are shifted a half-key or so to the left, and re-training the fingers to not track as far--the keys are quite close together.

Ctrl-Alt-T brings up xterm; I replaced that by editing my ~/.icewm/keys file to use konsole:

key "Ctrl-Alt-t" konsole

Setting up virtual desktops was also straight-forward; I edited ~/.icewm/preferences to include them, and a start menu:

TaskBarShowStartMenu=1
ShowProgramsMenu=1
TaskBarShowWorkspaces=1
WorkspaceNames="1", "2"

Putting the unit to sleep seems to mess up wireless connections; it's irritating--hopefully I'll figure out why that's happening so I don't have to keep typing in my ridiculous wireless password (it supports WPA, which is handy).

A real desktop can be had by installing kicker:

apt-get install kicker
apt-get install ksmserver

I had some issues with the task bar in full desktop mode that haven't been resolved yet; it redraws incorrectly when there's more tasks than taskbar. I may actually stick to "simple" mode for the time being.

While some have panned OpenOffice.org's performance, it's not that bad. I probably won't use it very often, but it's nice to know it's there. AbiWord is another option. VIM comes pre-installed... while I'm an Emacs person, I'm a little scared to even try it (I dread an even more-cramped Emacs claw), so I'll probably stick with something else on the little guy.

When my OLPC arrives I'll be comparing the two to see which will be my "drag it around" machine--the Asus is light but I suspect not as robust as the OLPC, and I really like the OLPC's screen.

For now the Asus will serve as a note-taking little-bits-of-work machine used during commutes. Battery life will be an issue; my MacBook Pro 17" Hi-Res will go round-trip w/o recharging, about 2.5-3 hrs, doing word processing and Java web development. The Asus is claimed to last 3.5 hrs and I doubt I'll be doing any Java development on it, but I may be able to continue using OOo for some books-in-progress.

It will also make an interesting hackery platform.

Today's Java Irritant: Java's Impoverished Mixology

Today's Java Irritant is the lack of mixins or similar functionality, although Warth et al.: Expanders have an implementation.

A current project has an interface consisting of about two dozen getters (and setters). This interface is implemented by a minimum of two classes due to design and lack of multiple inheritance.

Being forced to implement this functionality in even one place, not tucked away in some base class, module, mixin, etc. is irritating enough: having it in two places is more than twice as bad. Keeping the implementations in sync is irritating. Looking at the code so I know I can ignore it is irritating. Maintaining three sets of code (the interface and two classes) is irritating.

This functionality is available for Java--sort of. Warth et al. created Expanders via the Polyglot compiler front end. It allows classes to be non-invasively updated with new methods, fields, and superinterfaces.

Expanders look like what we want, and like the rest of Java, are statically-typed, preventing at least some types of errors.

package some.pkg;

public class SomeJavaClass {
// Normal class definition.
}

...

package interfaces;

public expander Foo of SomeJavaClass {

private String _someProp;

public void setSomeProp(final String someProp_) {
_someProp = someProp_;
}

public String getSomeProp() {
return _someProp;
}
}

...

import some.pkg;
use interfaces.Foo;

public class UseThatShiznit {

public static void main(final String[] args) {
SomeJavaClass anInstance = new SomeJavaClass();
anInstance.setSomeProperty("No brainer.");
}

}

This is a crude use of Expanders. Consider the creation of a Swing JTree-aware class via Expanders: rather than include Swing-specific information in the class itself we can create an Expander that implements TreeNode and ILabelProvider and since Expanders are typed, we can create different expanders for different classes. If there is shared behaviors, no worries; Expander behavior can be overridden just like class behavior.

use StringIconExp;
public expander PublicationExp of Publication implements TreeNode, ILabelProvider {
// Enumeration children()...
// String getText()...
public Icon getIcon() {
return "/icons/publication.gif".getIcon();
}
}

What's that getIcon() code doing?! Strings don't have a getIcon() method... but strings with an expander do.

public expander StringIconExp of String {
private Icon icon = null;
public Icon getIcon() {
if (icon == null)
icon = new ImageIcon(Object.class.getResource(this));
return icon;
}
}

Yes, this could be implemented with source generation tools, but that's a poor substitute for type-safe, naturally-composable functionality in the language itself, and it adds a layer of build-time complexity that must be documented and maintained.

If you think Groovy, Scala, and so on are tough sells, try selling Expanders. It's tantalizing, but experimental, and with the current crop of JVM languages, I doubt we'll be seeing it in mainline Java.