Hybrid User Interface

I really like my new Escape Hybrid, but I've started to notice some interesting UI issues:

I was stopping at a traffic light yesterday. I'd been driving a while so everything was warmed up. The gas engine turned off as I dropped below 20MPH -- as expected.

If the radio's not on it gets eerily quiet when you stop. Cool.

Then I took my foot off the brake. I noticed something unexpected. The car started to creep forward, just like "normal."

Hmmm...

In a normal car, the creep happens because the gasoline engine has to keep running. The torque "leaks" through the automatic transmission's torque converter. But for a hybrid the gas engine is off, and an electrical engine doesn't really need to keep spinning. In fact I'll bet the electrical engine was at a dead stop, too, when my foot was on the brake. Where is the creep coming from?

I'm betting that it's designed into the system to comfort those of us used to an automatic transmission. It reinforces the concept that a hybrid is "just like a normal car, only more efficient."

I wonder how much time Ford wasted getting this behavior to feel right. Personally I'd just as soon my car stayed where I put it unless I explicitly tell it otherwise.

Cross-Programmer Code

A lot of my programming work is intended to be portable across platforms where a platform is defined as a combination of operating system, computer architecture, and development tool set (compiler, etc.). ACE is a prime example of what it takes to achieve this goal.

However,

Even more important that platform portability is programmer portability. It is highly unlikely that any significant programming project will be developed and maintained by a single programmer for the life of the project. Every time a new programmer gets involved in a project the source code has to be "ported" into that programmer's model of the language.

Every programmer carries around a lot of mental baggage. Some of us are fresh-out-of-school apprentices -- lacking the pragmatic experience of a seasoned pro. Some of us are old fogies with fond memories of FORTRAN COMMON (who strive to recapture the glory using the Singleton pattern (chuckle.)) Some of us have been programming in C++ so long that we forget how arcane some of the "obvious" idioms are.

Fortunately, unlike computer architectures, compilers, etc. the port can work both ways. The code can be adapted to the understanding of the new programmer, or the new programmer's understanding can be adapted to the code. In fact there is usually much more of the latter adaptation than the former, although I have certainly been involved in situations in which it was easier to rewrite the code than to attempt understand it.

Recognizing how often programmers must adapt to unfamiliar code, and vice versa, we should make an effort to write programmer-portable code. With that in mind, I propose the "five programmer test."

Given a language feature or coding idiom, create a sample of code using that technique.

Select five programmers with skills ranging from average to superstar (below average programmers should be dumped on someone else's project.) Ask each of them to explain in English what the code does and to describe any limitations, consequences, etc. that need to be considered when using the technique.

If all five of them agree, then it's ok to use the technique.

If at least three of the five agree (and one of them is the superstar) then it's ok to use the technique, but it requires a comment to clarify the usage.

If fewer than three programmers understand the technique, or if any programmer "understands" the technique, but her explanation of what it does is way off base -- find another way to achieve the same goal that does pass the five-programmer test.

Another Interview Question

Another good interview question is, "Once you fix all the syntax errors and get a clean compile, what type of errors are most likely to still be in your code?"

Wrong answer: "None." End of interview. Have a nice life.

Most common answer: "I don't know."

Followup question: "So how could you find out?"

When I first asked myself this question (shortly after reading Writing Solid Code) my solution was to create a "programmer's diary." This was a background program that I could pop up with a hot key. It opened up an edit window into which I could paste or type information. It date/time stamped the entry then appended it to a sequential file and disappeared.

To use it, I'd select/copy code containing an error, pop open the edit box and paste it, then annotate it to explain the error. I did not do any further analysis in-line. Instead I went back to whatever I was doing -- fixing the problem or running more tests or whatever...

After capturing data for about a month, I analyzed the file. I categorized the types of errors into classes like:

• uninitialized or improperly initialized variable;
  
• sense of a condition is backwards;
  
• failure to release resource when returning from a function;
  
• difficult to use, difficult to understand, or easy to break feature of the language (think "goto" although I'd already stopped using those.)
  

Then for each class of mistakes I asked myself:

• What can I change can I make to my coding style or work habits to prevent this type of error?
  
• What can I change can I make to detect this type of error sooner?
  
• What type of test would detect this type of error?
  

In some cases this resulted in changes in my coding style. For some cases I added new types of tests to my set of tools. In others, just the increased awareness of my error-of-choice was enough to help me avoid the error.

I continued to use the diary for a couple of months afterwards, and yes, there was a noticable reduction in the types of errors I had specifically targeted. Without benefit of statistical analysis, I also think there was a significant overall reduction in uncaught-by-the-compiler errors.

The downside of all of this is when I get into an argument (oops, I mean a reasoned discussion) about programming style issues I tend to be dogmatic about my style. That's because I think it's based on emperical evidence rather than aesthetics or arbitrary preferences. This would be a lot more valid if I had used the diary recently. My emperical evidence is from sometime before 1995 -- and of course it is specific to one programmer. Programming has advanced considerably since then -- in particular exceptions and patterns like RAII have changed the way I program. I wonder if it's time to fire up the old diary program.

This one's for Jonathan

In the lobby where visitors sign in at Google, there's a Naked Juice vending machine.

The Computer History Museum

We visited the Computer History Museum yesterday. Lots of interesting artifacts including an Enigma machine, a Cray 1, etc. The item that captured my attention, though, was a white teapot. In fact, THE white teapot. If you've seen the test images from any 3D graphics program, you already know what the teapot looks like. And it does.

Do you know the way to San Jose?

Do airplane trips ever just work? I mean have you ever gotten to the airport on time, sailed through security, found a comfortable seat next to a pleasant companion, arrived at your destination feeling refreshed and rested, and had your luggage make it, too?

Well...

Tina and I just flew to San Jose to visit Peter, and the perfect plane trip didn't happen (one more time.)

Let’s see,

• My computer fell out of the back of Dave's van as he dropped us off at the airport (nothing damaged, apparently.)
  
• When we checked our bags, they took my picture ID and wandered off with it. When I asked what was going on, they told me my name was on a "watch list." This must be the same evil Dale Wilson who is behind on his alimony payments and stiffed an eye-care place somewhere in Illinois. Kind of spooky knowing I have an evil twin.
  
• Next was Tina's turn with security. "Is this your bag, ma'am?" said the TSA guy. "Yes," replied Tina. "I'm going to have to ask you to open it up." By then I was through security myself, so I didn't hear the details, but after I stood around for quite a while, Tina finally made it through. Apparently they confiscated a vicious looking nail file and were deeply suspicious about the dangerous drugs that were Not In Their Original Ibuprofen Bottles!
  
• So the plane was a little bit late taking off.
  
• And we landed in Tulsa. Most of the passengers go off, but those of us who were heading on to Phoenix on the same flight rearranged ourselves and got comfortable for the next leg. One of the stewardesses stopped by to admire my beard. She said her husband also had a long beard, and was giving Tina some really unfortunate suggestions involving braids and tiny lights, when the PA system announced we all had to get off the plane and go to another gate. There was vague mention of a "maintenance issue."
  
  When we got to the new gate, there was an enormous crowd. Much more than a planeful. It seems that they were putting us on a plane that was supposed to go to Dallas. Since the plane was going to Phoenix instead, now, the Dallas people were being sent to yet-another-gate where presumably they would eventually be put on their own replacement plane to replace the one we had just borrowed from them.
  
  This being Southwest, we were given new boarding passes that let us board first -- even before "families traveling with small children." If you want to get on a Southwest airplane first, get yourself a mauve boarding pass (honest they called it mauve!)
  
• So that got us on the plane in Tulsa. We were 45 minutes late, but we were on our way. Nothing much went wrong during the flight to Phoenix (unless you count peanuts, but they're normal for a Southwest flight.) As we made our final approach into Phoenix they announced that Southwest was holding all connecting flights, and would anyone going to San Jose go directly to gate C2. Of course, our plane docked at the far end of the D concourse, but it coulda been worse. We hiked on over to C2 in time to walk right onto the plane shortly before they closed the doors. Things were looking up -- this plane was half empty so we had no problems finding seats.
  
• Oops. Spoke too soon. As we arranged ourselves I realized that I had left the book I was reading on the other plane. "Do you think they'll let me go back and get it?" I asked Tina. Right.
  
• So on to San Jose. We made up the time somehow and actually got to San Jose on time! The only unfortunate part of this leg was when the stewardess decided to sing as we taxied in to the airport. I guess it was endearing. A personal touch sort of like the early episodes of American Idol. "A bit pitchy," said Randy, "but not too bad." "I don't think this was a good song selection for you," said Paula, "but you've got a, um, loud voice." "I've heard better performances from the taxi driver that brought us to the hotel." said Simon.
  
• Home free, eh? Our baggage made it! Calloo, Callay!
  
• Then we got to Peter's car, and I said -- where's my computer? The brief case containing my computer--which I had carried on, so I couldn't blame the airline--wasn't there! In near panic I headed back to the baggage claim area. Fortunately it was sitting on a chair waiting for me. Airport security hadn't confiscated it as an unaccompanied bag -- probably because there was a woman there watching it. She said she saw us leave it and couldn't figure out what to do, so
  she was waiting a bit to see if we came back before calling security. Thank you, thank you, thank you.
  
  
  And so we're in San Jose. I do so love traveling.

Guidance toward the-one-true-path.

Paul Colton wrote an interesting article for Byte about XAML. Once sentence in the article was a real attention grabber:

XAML has many strengths, and Microsoft's ability to educate the marketplace and guide the .NET developer community may ultimately tip the balance to XAML.

Wow. I'm *SO* glad Microsoft is willing and able to educate and guide me. ;->

Thoughts Meandering From Interview Questions to Semantic Compilers.

I used to do a lot of interviews for programming positions. One of my favorite interview questions is:

What's the best book about programming you've ever read? What book should every programmer read?

(I know, that's two questions --- but hey, it's my interview (and my blog) so I make up the rules.)

There is no "right" aswer to this question, but there are a couple of wrong ones.

The worst answer is "I haven't read any programming books recently." The applicant can recover from this if she goes on to explain that she reads programming blogs, and magazines instead because the informaion is more current, but barring such a last-minute save, a negative answer is an interview stopper.

The next worst answer is a textbook required by a college course. If the interviewee is more than a couple of months out of college and hasn't learned anything since, well....

Responding with something like "How to write [fill-in-the specific-application] programs in [fill in the language] on [fill in the platform]" earns a barely passing grade. The interviewee is on the bubble and better come up with a reason why I should keep talking to them really quickly!

Oh yeah, and any book containing "for dummies" in the title is instant death <chuckle/>.

So, how would I respond to the question?

I might mention some recent read (ala "The Pragmatic Programmer.") or I might fall back on one of the very few books that have a profound impact on the way I program.

Looking back, there have been a lot of programming books, but very few that were life-changing. "Elements of Programming Style" counts (yes, that was a long time ago, but it's still worth reading.) Most programmers know about "Elements.." and it is actually used as a textbook in some college courses (which contradicts the "second-worst" judging criterion above. hmmm.)

Another book that had a major impact was "Writing Solid Code" by Steve Maguire. I'm not sure whether this was that good a book, or whether it just happened to be the right book at the right time for me. I should probably re-read it if I could find my copy.

One concept I acquired from "Writing Solid Code" is the idea of a compiler that checks semantics rather than (or in addition to) syntax. Wouldn't it be great if the compiler would tell you: "Yes, that's legal C++, but it's really not what you should have written." Actually, over time, compilers have gotten better at producing this type of warning messages. By flaging unused variables, statements with no effect, and such atrocities as:

if (a = b)

modern compilers bring your attention to possible semantic problems. This is a good thing.

But wouldn't it be nice if compilers could go further? If they could warn not only about obvious nonsense, but also questionable practices, bad algorithms, etc. we could write better programs faster.

One problem of course, is my "really cool technique" is your semantic abomination, and vice versa. In recent discussions here at work we haven't been able to agree on where the & should go in:

int & a;

Some say goes with a because you can say "int &a, b, *c;" to which I say -- not in MY semantic compiler you can't! Some say it goes with the int because it's "part of the type" to which I say, but how about const and static. Aren't they part of the type.

In case you haven't noticed, I think that & and * are first-class citizens and deserve to stand on their own rather than being piggybacked on another token -- but that's just my opinion and it is certainly subject to debate. It's also completely beside the point of this discussion.

Lack of agreement about what constitutes a good program makes it very difficult -- nay impossible -- to come up with a one-size-fits-all semantic compiler. So how about a compiler that "learns" your programming style, and flags departures? If you always indent by two, but happen to indent by four in one place -- well maybe that indicates the code is wrong. Better yet, if you always use braces (as you should (chuckle)) then an if statement with no braces should be flagged as an "error."

Hmmm. How well does this play on a team programming project?

Of course these are all "small scale" issues. The real benefit comes when the compiler can detect, for example, that you're doing a linear search of a (large enough) sorted list and suggest that a binary search would be a good idea here, or can look at an object full of get and set methods and advise you that you've really blown the encapsulization and should be writing domain-meaningful methods instead.

STL does makes some interesting strides in that area by declining to implement "unwise" methods on some containers. Java was also a step in this direction -- unfortunately a lot of the decisions that went into Java were one man's opinion so some valuable techinques were "tossed out with the bathwater." and some warts like uninitialized references made it into the language.

There's much more to be said on this topic, but this entry is getting too long. To be revisited...

The kind of person that keeps a parrot.

Tina was looking at my blog and pointed out that not everyone was familar with the Mark Twain quote. Although anyone who reads parrot mailing lists surely knows it, for the rest of you, click here.

Pet Peeve n+1: Thinking outside the box

The phrase "Think outside the box" ranks right up there with "Have a nice day :-)." and just barely below fingernails scraping on blackboard.

Most people use the phrase to mean "ignore the rules."

Trucker #1: Why are you stopping?
Trucker #2: Look at the sign on that overpass.
Trucker #1: Yeah, it says "Clearance 11 ft. 6 in." So what?
Trucker #2: The trailer we're pulling is 12 feet tall.
Trucker#1: (looks around) I don't see any cops. Let's go for it.

See. Trucker#1 is thinking outside the box the way most people use the phrase.

The origin of the phrase is a classic logic puzzle. Given nine points arranged in a 3x3 grid:

  X  X  X
  X  X  X
  X  X  X

Draw a continuous series of four line segments that passes through each point exactly once.

The solution (which you know, right? (if not, there's a hint below)) involves extending the lines beyond the "borders" of the array. Hence, "Thinking outside the box."

You don't solve this puzzle by thinking "outside" the box. You solve it by realizing that there is no box outside of which to think! [Look again, do you see any box?]

Understanding the true constraints on a problem and finding creative solutions within those constraints -- good. Ignoring the constraints that happen to be inconvenient -- bad.


All of which applies to programming, too!

Hint:

  X  X  X  x
  X  X  X
  X  X  X
  x

The Sins of Intel

Another entry in my Hack series. This one's a threefer:

A lot of people complain about the Intel architecture. It must have been really easy for hardware designers to build systems around the early Intel chips, 'cause you'd never find a software developer praising their design. Early Intel chips (and some not-so-early chips) were much harder to program than they needed to be.

Sin #1: A + (-B) != A - B
One of my favorite Intel sins, is that the engineer(s) who designed the early chips did not understand binary arithmetic! The way the chip was designed 5 + (-1) [that's five plus negative 1] did not produce the same answer as 5 - 1 [five minus one]! That one deserves an extra exclamation mark!

To explain:
On a four bit machine 5 + (-1) looks like:

  0101
  1111
1 0100

That 1 hanging out there is a carry bit. It is normal for a subtraction to generate a carry (it means you did NOT have to borrow!)

Unfortunately on Intel the flag that ends up holding that 1 is called the carry/borrow flag. If you add, it holds the carry. If you subtract it holds the borrow.

That means 5 + (-1) is four with a carry, whereas 5 - 1 is four without a borrow, but borrow and carry are stored in the same flag, so to do-the-right-thing with the carry bit you have to know how you got here.

The result is a lot of really sweet binary arithmetic techniques were just a little bit harder and messier (and hence a little bit less sweet) on the Intel machines.

Sin #2: Segment granularity

When Intel discovered they needed to go beyond the 16 bit address space of their early processors they added segment registers. This was a good move because it preserved compatibility with older software -- or at least made it relatively easy to migrate to the new processors.

The sin comes when you considered how the segment registers were factored into the address calculations. The segment registers have 16 bits -- making them easy to manipulate on a machine that's built around a 16 bit architecture, but in order to achieve the goal of extending the address space, the segment registers have to address units of memory larger than a single byte. Intel choose a 16 byte addressable chunk for the segment registers. That means the segment register is shifted four bits to the left when it takes part in the addressing calculations. The result is the 20 bit (one megabyte) address space that hampered the Intel processors for years! (Of course IBM and Microsoft managed to hack that into the 640K limit, but that's a different transgression.)

Suppose Intel had shifted the segment register by 8 bits rather than 4 bits. Downside is a granularity of 256 bytes rather than 16 bytes (big deal--not)

Upsides:

First of all, calculating the values to go into segment registers would have been much easier because it's a lot easier to move things by 8 bits than by four bits on an Intel chip, but thats only a minor advantage compared to the real plus which is that the address space just became 24 bits (16 megabytes rather than 1 megabyte) Admittedly 16 megabytes seems small today, but it took almost 10 years before we achieved that state. Countless man-centuries (yes and woman-centuries) were poured down the bottomless pit of extended memory and expanded memory hacks trying to compensate for Intel's short sightness.

Sin #3: The 80286
Ok so they forgot to figure out how to get from user mode back to kernel mode (D'oh) This inspired the truly byzantine technique of booting the whole damn machine to do a context switch back to the OS. Kool, eh!