The Cafes

A bogon is an element that appears in an HTML document, but has never been recognized by any browser. You’ll often find them by viewing source on pages written by XML geeks like me. I got the term from John Cowan’s TagSoup, which has, a --nobogons switch to suppress any elements it doesn’t recognize.

A semibogon (my own coinage) is an old element that used to be recognized by one or more browsers but is no longer. Examples include:

• marquee
• basefont
• bgsound
• keygen
• bgsound
• spacer
• wbr
• nobr

I’m trying to generate a reasonably complete list of these semibogons for Refactoring HTML. Can anyone add to this list?

There’s a large rebellion over XML config files from programmers who don’t like to type XML and don’t want to learn APIs for processing it. They’d rather limp along with the same scanf code they’ve been using for the last 20 years.

The problem is there really isn’t such a thing as a plain text config file. What there is are specially formatted text files that are easily as complex as the XML equivalent but inconsistent, poorly documented, and easily broken. For instance, consider this extract from LogValidator’s “plain text” config file:
Read the rest of this entry »

(Custom look and feel considered harmful)

Suppose you’re playing piccolo in a marching band. You want to play the Stars and Stripes Forever because it really shows off your skills as a piccolo player. However the rest of the band is playing the Star Spangled Banner. The talented piccolo player plays the Star Spangled Banner like everyone else. The pointless prima donna plays Stars and Stripes Forever. It sounds awful and everyone stops listening to the band.

User interfaces are no different. Some are advocating that we each choose our own tune, and indeed designing libraries to help us do that. However this serves only the egos of the players (or programmers). It does nothing for the audience (or end users) except make them walk away in disgust. I reiterate: it is the goal of a Java application (or any other application for that matter) to fit in with other applications, not to stand out.
Read the rest of this entry »

I’m slowly coming around to the idea that first class functions in Java are probably a good idea. I’m still not convinced we need full-blown closures though. Possibly we do. Doug Lea has some interesting use cases I need to explore further.

Several things concern me though. One is syntax. I really, really want the syntax to be simple and have no surprises or significant learning curve. I want existing Java programmers to be able to read Java code that uses closures (or first class functions) and immediately be able to see what the code is doing without any prior training in the new syntax. I want the syntax to be that clear. If we can’t have that, I don’t want to do it. I want Java to still be a lingua franca.

Secondly I want closures to be really, really easy to write. No gotchas. A little training may be allowed here, but there shouldn’t be any special cases or surprises. Programmers’ first instincts of how to write something should be correct. In particular, I do not want to see any issues like “the closure works if the external variables are declared final, but fails if they’re not.” Or, “the closure works if the external variables are not modified, but stops compiling if a line is added that modifies one.” That is, implicit final is not a workaround. The only things that break the closure should be:

1. Syntax error inside the closure itself
2. Breakage in the closure syntax (i.e. leaving off a trailing curly brace or some such in the closure definition)
3. Removing or renaming an external variable the closure depends on.

In other words, the only things that should cause a closure to fail to compile or run in the expected fashion should be exactly those things that cause today’s code to fail to compile or run. If you rename a local variable from x to y and forget to rewrite the statement foo(x);, then the compiler complains. This is a common bug we all know how to handle when it happens to us. I want to make sure that adding closures does not add any new failure types or patterns.

Those are my requirements for any proposal to introduce closures or first class functions into the Java language. I am prepared to reject any proposal that does not meet these two criteria. If no proposal can satisfy these two criteria, then we shouldn’t add closures or first class functions.

So what are the proposals on the table, and how well do they meet these criteria?
Read the rest of this entry »

When does a site start to stink? When do you know it’s time to refactor? These are questions I’m considering in Chapter 1 of my new book, Refactoring HTML. Here are some of the smells I’ve already written about:
Read the rest of this entry »