Digital Digressions by Stuart Sierra

From programming to everything else

Blog

Property of Properties

Posted on by Stuart

I was looking at a problem in the early chapters of Artificial Intelligence: A Modern Approach. It’s called Vacuum World. This is a very simple agent problem consisting of a vacuum placed on a grid. The grid has only two squares, each of which is either dirty or clean. The vacuum has three actions: move left, move right, and suck.

I wrote a simple implementation of this in Java (because the course I’m taking uses Java), starting out something like this:

public class Vacuum {
    private GridSquare location;
    public void moveLeft() { ... };
    public void moveRight() { ... };
    public void suck() { ... };
}

Obvious, beginner’s OOP, right? But then I start to second-guess myself. Is location really a property of the vacuum? Or is it a property of the vacuum in its environment? That is, does the location variable belong in the Vacuum class, in the Grid class (the environment), or in some “world” object that encompasses both the vacuum and the grid? Should Vacuum even be allowed to have a reference directly to its location, or should it query the environment indirectly, as in “Is the square I am currently occupying (wherever it may be) dirty?”

The example code on the A.I.M.A. web site seems to go out of its way to be inscrutably OO, with the behavior of the vacuum divided among half a dozen abstract “agent” classes. I think the vacuum there stores its location as an integer, but I couldn’t swear it to you.

Loggerheadache

Posted on by Stuart

I decide to play around with the Java logging facility. I write a simple test program:

import java.util.logging.*;

public class LoggingTest {
    public static void main(String[] args) {
	Logger log = Logger.getLogger("com.stuartsierra");
	log.entering("LoggingTest", "main");
	log.info("Info Message");
	log.warning("Warning Message");
	log.exiting("LoggingTest", "main");
    }
}

Compile, run, and I get this:

Aug 30, 2006 10:48:45 AM LoggingTest main
INFO: Info Message
Aug 30, 2006 10:48:45 AM LoggingTest main
WARNING: Warning Message

Hmm. Not quite what I expected. Two out of my four log messages don’t appear. Back to the API docs. Ah, yes, I need to set the logging level if I want to get finer-grained messages like “entering” and “exiting.” So I add the line,

log.setLevel(Level.FINEST);

just after getLogger(), compile, and run again. Same exact result — the “entering” and “exiting” messages don’t appear. I look at the API docs again. Nothing strikes me. The Java (TM) Logging Overview doesn’t enlighten me either. I try Level.ALL, just to make sure. Nope, Java doesn’t want to print those messages.

Now if I were on a deadline, I would say screw it and go do some real work. But I want to understand why this doesn’t work. After three or four web searches I find An Introduction to the Java Logging API. As it turns out, I need to set the level not just of my Logger, but also of each of the Handlers receiving messages from it. The article suggests this code:

Handler[] handlers =
   Logger.getLogger( "" ).getHandlers();
for ( int index = 0; index < handlers.length; index++ ) {
   handlers[index].setLevel( Level.FINE );
}

I insert that into my test code, and lo and behold, it works:

Aug 31, 2006 11:05:53 AM LoggingTest main
FINER: ENTRY
Aug 31, 2006 11:05:53 AM LoggingTest main
INFO: Info Message
Aug 31, 2006 11:05:53 AM LoggingTest main
WARNING: Warning Message
Aug 31, 2006 11:05:53 AM LoggingTest main
FINER: RETURN

So what's the lesson of all this? It's easy just to say "Java's logging API is weird." But I'm sure those Handlers are in there for a reason. I can imagine wanting to send the same stream of log messages to a file and a window at the same time. I can even imagine wanting to send different levels of log detail to different outputs. I do think it is a mistake to have the level-setting code duplicated in both Logger and Handler, as it means more work for me, the client programmer who gets frustrated when his code doesn't do what he expects it to. At the least, the API documentation for Logger.setLevel() should mention that you need to set the level on all the Handlers too.

More generally, I think this is an example of how a library can be too customizable. Picture the feature list: "Custom logging levels per-logger and per-output." Sounds great, until you have to remember to set them both to the same value to get what you want.

Lodged Net

Posted on by Stuart

I just returned from a short vacation with a little business mixed in. On the third day of my trip, I realized I needed to check my email. My hotel had free in-room Ethernet connections, but I hadn’t thought to bring my laptop with me. No problem, I thought, since the hotel also had one of those TVs with a wireless keyboard for web browsing. So I turned on the television, punched buttons for Internet access, and accepted the $9.95 charge for 24 hours’ use — a little steep, I thought, but I was only going to use it once.

To my dismay, the service was barely usable. The Web browser in the television seemed to be about Netscape 3.0 level, unable to render new-fangled sites like my ISP’s web mail. Half the text was hidden off the left side of the screen, and there was no horizontal scroll bar. To make matters worse, it operated at dial-up speeds. As I watched the “progress” bar creep along the bottom of the screen, I reflected on why WebTV never caught on. I think it’s because no one ever bothered to get it right before other technologies — small, cheap laptops with WiFi — took over.

Down With Upper Case

Posted on by Stuart

Slashdot: War Declared on Caps Lock Key

A good idea. And while we’re at it, let’s dump those silly Ctrl and Alt keys. Who uses them? F1 – F12 can certainly be abandoned, as well as that triumvirate of uselessness, Print Screen / Scroll Lock / Pause. Don’t get me started on Microsoft’s “Windows” and “Menu” keys (or Apple’s “Apple” key). “Insert” has outlived its usefulness, and Page Up/Down were obsoleted by scroll-wheels. That leaves “Home” and “End,” which I could live without. “Delete” is kind of redundant if you have “Backspace.” “Tab” never works the way you want it to. “Escape” is a false hope. And number keypads are an obvious waste of space. What does that leave us with? This:

Bare-bones keyboard

I’m not being entirely facetious here. Most of the keys on a modern computer keyboard are relics of some older technology, be it a typewriter (tab, caps lock) or a text terminal (scroll lock). They increase the likelihood of typing mistakes and make computers look more intimidating than they need to.

Of course, there will always be some user screaming if you remove his favorite key, so it’s easier to keep the legacy keys than remove them. And for power users, mouse-driven interfaces still can’t match the speed of Escape Meta Alt Control Shift. This will have to change, and I think it will with large, multiple-contact, flexible touch screens. Keyboards will stick around for a long time, because there’s nothing better for getting a lot of text down fast, and the tactile response is important. But they will be more “peripheral,” stripped down to their essential function and used only occasionally.

Abstract Interfaces

Posted on by Stuart

Office 2003 uses a table of 1500 colors to render the user interface. That’s 1500 different colors designers have to choose for each color scheme. Overkill? Probably. But it says something about commercial software that sets it apart from most open-source software. Despite the greater theme/skin-ability of KDE, Gnome, and friends, open-source GUIs tend to look less “polished” than big commercial ones. To be fair, the same could be said of an awful lot of shareware and commercial software from smaller companies. The fact is, only a huge company like Microsoft has the resources to pay professional designers just to pick colors all day.

Can independent developers compete? I think they can, with a different approach. By adopting a standard API for interfaces that goes beyond the usual widget set to encompass entire interaction paradigms, developers of many different applications can all take advantage of a consistent interface. Then that interface can be beautified by a relatively small number of designers.

I’m not talking about user-interface guidelines like the Gnome and KDE projects have, I’m talking about abstracting the entire interface away from application programming.

Emacs provides a simple example that goes in the same vein: If you are writing an Elisp application to run inside Emacs, you do not need to provide an interface to set user preferences for that application. You only need to describe the user-customizable variables and their possible values, then Emacs itself renders those options in a customize buffer, which will look and act consistent with every other Emacs customize buffer.

Now, Emacs is text-based and programmer-oriented, and the customize interface reflects that. But there’s no reason why the same concept cannot be applied to graphical interfaces. Suppose, instead of writing classes for MyAppMainWindow, MyAppMenuBar, and MyAppToolBar, you just specify “My App manipulates Foo objects. It provides the following functions: Qux Bar Baz. It can read and write Foo objects as plain text or XML. It has these user preferences: 1 2 3.” In other words, specify the hooks into the application’s functionality and let the GUI framework worry about things like where to position controls in a dialog box.

Creating such a sophisticated framework would not be easy, but I believe it could be done, and would open up possibilities for faster application development with more sophisticated interfaces.

Indecent Indirection

Posted on by Stuart

“Any problem in computer science can be solved with another layer of indirection. But that usually will create another problem.” —David Wheeler or Butler Lampson, depending on whom you ask

I’ve seen a fair amount of press about Virtualization over the past year or so. For servers, I think it makes some sense: it would certainly be convenient to have root access to a virtual server on my shared web host instead of a limited user account. But when people talk about virtualization on the desktop, I wonder: is this going to far? I already believe that most of the exponential increases in hardware capacity have been eaten up by abstractions created for the benefit of programmers. This is not necessarily a bad thing, as it gives us more sophisticated software. But it also means that each new computer I buy feels slower than the last one.

How many levels of abstraction are too many? When you have an interpreted programming language built with dynamic libraries running on a virtual machine on a virtual server, a simple “+” instruction might go through six different transformations before it hits the processor. Is this a good thing?

Beset By Red Squiggles

Posted on by Stuart

When I was a kid, I took piano lessons. Every day, after I couldn’t put it off any longer, I would sit down and practice a piece of music. Whenever I made a mistake, I would stop, go back to a point just before the mistake, and start again. The problem with this technique was that I never learned to play anything all the way through without stopping. Even if I didn’t make a mistake, I would automatically stop and repeat the difficult parts several times before continuing. This became an ingrained habit that took ages to break.

A few years later, my family bought a PC, which I used to type my school assignments. Like everyone else in the world, I quickly discovered how easy it was to edit on the screen. No messing about with white-out or correction tape, just “backspace” and start again. I learned to type on a computer, so I never learned to type without the crutch of a backspace key. For a long time after that, I automatically hit the backspace key after certain words I typically mistyped, even if I had typed them correctly.

Now I have a modern word processing application which will check my spelling, grammar, capitalization, and even my formatting while I type. One would think this would leave me free to concentrate better on the writing itself, but I find the reverse is true. All those little red squiggles distract me from the words I’ve written. I don’t care if my words are misspelled until I’m finished writing and into the editing phase.

I think today’s word processors are too focused on the editing phase, and their “helpful” distractions make it more difficult to write coherent prose that flows logically from one sentence to the next. I find myself falling into a stacatto, disjointed pattern of short sentences and disconnected paragraphs, more like an outline than prose.

Gary King wrote recently, “It’s up to us to ensure that the tools we use are optimizing the important tasks, not the trivial ones.” That’s why when I want to get any serious writing done, I launch Emacs full-screen.

My Life As a Robot

Posted on by Stuart

Despair.com - Motivation
This poster hangs in my cubicle. The caption reads, “If a pretty poster and a cute saying are all it takes to motivate you, you probably have a very easy job, the kind robots will be doing soon.”

Besides saying “nyah nyah” to the superiors who never stay in my cubicle long enough to read the caption, I more or less believe what the poster says. My job is very easy. In a few years, a robot will be able to do it.

One of my primary job functions is to be a human interface to technology, so that the important people don’t have to be bothered to learn how to use their computers. With better A.I. — not even strong A.I., just better language handling and learning algorithms — a computer could learn to interpret vague requests and do the right thing. The important people wouldn’t even lose the ability to blame their mistakes on their underlings — they could just blame their computers, and people nowadays are more understanding of computer errors than human error. And with handwriting and voice recognition, no one would ever need a human typist.

The second function of my job is searching for, sorting, and organizing information. Computers are great at that already, and soon software will bridge the gap from today’s web search, e.g. “Seth Greenberg San Francisco lawyer,” to “Find the phone number of the lawyer I talked to at the conference in San Francisco last month.” Pattern recognition systems are already widely used in areas such as finance and medicine. A.I. — again, not strong A.I., just better — will give us general-purpose pattern recognition systems that can be applied to any type of data. Internet research is already very useful, and “search agent” software that can learn to recognize items of interest will be eventually be more thorough than a human researcher. Currently, the public web lacks sufficient accurate information for serious research. The really good sources are locked up in proprietary databases with their own restricted search interfaces. Those interfaces will need to be opened up to third-party search systems — which does not preclude charging for the content in the database itself — to remain competitive in a software agent-driven research market.

The third major function of my job is basically minor physical labor: printing, photocopying, stuffing envelopes, mailing, and generally trasporting physical documents from one location to another. Once we more fully embrace digital communications, this task will dwindle down to nothing. This embrace will depend on a few things: 1) computer displays that are equal or superior to printed text for reading long documents, 2) a legal framework that accepts electronic “signatures” as valid, and 3) a generational change of attitude.

So I will, within a couple of decades, be replaced by a robot. There will not be an android sitting in my cubicle, but a combination of better hardware, smarter software, and cultural changes will leave me with nothing to do. Hopefully by then I’ll be doing something more interesting.

Functional Programming a Foregone Conclusion

Posted on by Stuart

Steve Yegge, who spent 7 years working on distributed computing at Amazon, writes about a book called Purely Functional Data Structures. Yegge: “it’s abundantly clear that it’s time for us to move up to a higher level of abstraction. … Object-Oriented interfaces are failing us, and we need to turn today’s network into a computer that we can start programming directly, as if it’s a single machine. … Functional Programming is going to be a necessity in this new world. It’s a foregone conclusion.”

Finger-Painting on a Computer Screen

Posted on by Stuart

Another blog named Digital Digressions (nuts, and it looks like she used it first, too) points to a video demo of a touch screen with multiple contact points. This is the interface I want! Everything on the screen responds to touch. You can move things around, zoom or resize, stretch, pull, and “play” with objects on the screen using both hands. I think something like this will be a big part of future computer interfaces, perhaps combined with thin, flexible displays. I can’t wait.

Now I just need a more original name for my own site.