Chip Overclock

Generic Embedded Programming Using the C Preprocessor

2008-05-03T14:18:00.023-06:00

In the article Generic Embedded Programming Using Templates, I described how C++ templates could be used for generic programming in embedded applications. Generic programming represents a higher level of abstraction in which you express an algorithm without regard to the data types on which it operates. Experienced C developers may find that templates remind them of the C preprocessor. This is apropos, because in this article I will describe one way to use the C preprocessor to do a simple but useful form of generic programming in C.

Like C++ templates, the C preprocessor provides a powerful form of software reuse known as code generation. The symbolic substitution and macro capability provided by the C preprocessor, along with the native capabilities of the C compiler itself, lend themselves to a simple form of generic programming that can ease the burden of software maintenance. One of headaches of using the standard header files available in C and POSIX is the wealth of integer type definitions that hide what the actual data type is. For example size_t is returned by the standard I/O functions fread and fwrite. What is the range of size_t? Is is signed or unsigned? What about ssize_t which is returned by the recv socket system call? How about pid_t that is returned by the getpid system call?

Obviously, a few minutes perusing the hundreds of files under /usr/include (made simpler using a tool like cscope) will eventually lead you to discover that size_t is unsigned, and its counterpart ssize_t is signed. But on some systems size_t is thirty-two bits wide, others sixty-four bits. And on one system to which I've ported C code, it was a sixty-bit wide floating point data type, because that was the only data type that architecture had.

So what happens if you want to write portable code that assigns the minimum or maximum possible values to a variable declared as either of these two data types? You may be tempted to use the symbols MININT and MAXINT that are defined in /usr/include/values.h for the ssize_t variable, but is this safe? What if the code is moved to another machines where ssize_t isn't the same width as an int? What about all those integer data types defined in the third-party library you are porting? What if the next upgrade changes one of those type definitions you are using in your application? It's enough to make you want to turn to Java, which has a fixed set of integer data types which are the same on all platforms

But there's a simple way to write type-independent code where you generate the correct values for the integer data type automatically, providing the architecture implements true two's complement binary integers.

For size_t, or any other unsigned type, the minimum possible value is, of course, 0. So the minimum of an unsigned integer is easily defined. Let's suppose we define a simple macro to generate that value.

#define minuint(TYPE) ((TYPE)0)

This macro just casts the value zero to the appropriate type. It can be used just like this.

size_t min_size_t = minuint(size_t);

The maximum possible value of any unsigned type has all of its bit set. This is just the value ~0. So this is our next macro, and an example of its use.

#define maxuint(TYPE) (~minuint(TYPE))

size_t max_size_t = maxuint(size_t);

By now you may suspect that we can do the same for signed types. And so we shall. The minimum value of any signed number is the largest (numerically smallest) negative number. In two-complement arithmetic, this number has its most significant bit set and all of its other bits are zero. Using the C compile-time operator sizeof which returns the number of bytes in a variable or a type, this is easily computed.

#define minsint(TYPE) (((TYPE)1)<<((sizeof(TYPE)*8)-1))

ssize_t min_size_t = minsint(ssize_t);

Get it? The sizeof gives us the size of the argument TYPE. Multiplying that value by eight gives us the number of bits. Subtracting one gives us the bit position (relative to zero) of the top bit, and shifting the 1 (cast to the correct type) gives us the largest (numerically smallest) negative number.

It may come as no surprise by now that the largest signed number is again the bit-wise inversion of the smallest signed number, just as it was for unsigned numbers.

#define maxsint(TYPE) (~minsint(TYPE))

ssize_t max_size_t = maxsint(ssize_t);

So there you have it.

What's that? Yes, that's right, with these macros you have to know whether the data type is signed or unsigned. What? Really, must I do everything myself? Oh, very well; how about these macros, which will work with either signed or unsigned integer types?

#define minint(TYPE) ((maxuint(TYPE)>0)?minuint(type):minsint(type))

#define maxint(TYPE) ((maxuint(TYPE)>0)?maxuint(type):maxsint(type))

See the trick? If the integer type is signed, the value generated by the maxuint macro is interpreted as a -1. It the integer type is unsigned, the value is interpreted as the largest possible number for that data type which is always positive. The conditional expression automatically chooses the appropriate form of the minimum or maximum macros.

And here's an even better trick. All of this is done at compile time. The preprocessor expands the macros to their equivalent C expressions and submits the generated code to the C compiler. Since none of the values in the resulting expressions are run-time variables, the C compiler reduces the initializers to their equivalent integer numbers. If someone changes the underlying integer type of some type definition, the C compiler will automatically generate the correct minimum and maximum values the next time your code is built. Expanding on the trick above, you can even check to make sure that the data type is signed or unsigned.

Here's a working program that demonstrates the macros using a variety of integer data types.

#include <stdio.h>
#include <stdint.h>
#include <sys/types.h>

#define minuint(TYPE) ((TYPE)0)
#define maxuint(TYPE) (~minuint(TYPE))
#define minsint(TYPE) (((TYPE)1)<<((sizeof(TYPE)*8)-1))
#define maxsint(TYPE) (~minsint(TYPE))

#define minint(TYPE) ((maxuint(TYPE)>0)?minuint(TYPE):minsint(TYPE))
#define maxint(TYPE) ((maxuint(TYPE)>0)?maxuint(TYPE):maxsint(TYPE))

int main(int argc, char ** argv, char ** envp)
{
size_t minsize = minint(size_t);
size_t maxsize = maxint(size_t);
ssize_t minssize = minint(ssize_t);
ssize_t maxssize = maxint(ssize_t);
pid_t minpid = minint(pid_t);
pid_t maxpid = maxint(pid_t);
uint64_t minuint64 = minint(uint64_t);
uint64_t maxuint64 = maxint(uint64_t);
int64_t minint64 = minint(int64_t);
int64_t maxint64 = maxint(int64_t);

printf("minsize 0x%08x %u\n", minsize, minsize);
printf("maxsize 0x%08x %u\n", maxsize, maxsize);
printf("minssize 0x%08x %d\n", minssize, minssize);
printf("maxssize 0x%08x %d\n", maxssize, maxssize);
printf("minpid 0x%08x %d\n", minpid, minpid);
printf("maxpid 0x%08x %d\n", maxpid, maxpid);
printf("minuint64 0x%016llx %llu\n", minuint64, minuint64);
printf("maxuint64 0x%016llx %llu\n", maxuint64, maxuint64);
printf("minint64 0x%016llx %lld\n", minint64, minint64);
printf("maxint64 0x%016llx %lld\n", maxint64, maxint64);
}

Here are the results when you run it. (This version was tested on a P4 Linux system and a P4 Cygwin system.)

minsize 0x00000000 0
maxsize 0xffffffff 4294967295
minssize 0x80000000 -2147483648
maxssize 0x7fffffff 2147483647
minpid 0x80000000 -2147483648
maxpid 0x7fffffff 2147483647
minuint64 0x0000000000000000 0
maxuint64 0xffffffffffffffff 18446744073709551615
minint64 0x8000000000000000 -9223372036854775808
maxint64 0x7fffffffffffffff 9223372036854775807

This technique, as simple as it is, can make your C code more portable, more readable by eliminating some magic numbers, and more easily maintainable.

Update (2008-05-04)

When I write production code I have a habit of cranking the warning level of the GNU C compiler up to the max. This causes the compiler to object to checking for unsigned values being negative. To circumvent this in the versions of these macros I wrote for the Desperado C++ library, I reversed the check in the equivalent of the maxint and minint macros. I made this change in the macros above from their form in my original article.

Globalization and Amazon.com

2008-04-27T06:53:00.007-06:00

I had a The World Is Flat moment the other day. Some random synapse in my brain decided that I should read the old Alistair MacLean cold-war thriller Ice Station Zebra. I've always been a fan of the movie (me and Howard Hughes) and the soundtrack by Michel Legrand, but had never read anything by MacLean. So I hied me over to Amazon.com to order the book.

I was a little surprised to find it was out of print. But thanks to Amazon's Marketplace service, several used and even new copies were available from any number of sources. I'm no stranger to this service, in which independent booksellers use Amazon as a storefront. In Outsourcing Technical Services for Small Businesses, I wrote about how this service was a great way to get barely used copies of expensive or out of print technical books (the only thing that depreciates as quickly as high tech is fresh fruit). Nearly instant gratification was only a few clicks away.

It was only after I got the verification e-mail that I realized I had ordered the book from a bookstore in the U.K. Well, okay, I'm no stranger to that either. It seems that many of my favorite authors these days are Scottish: Iain Banks, Ian McDonald, Ken MacLeod, Charles Stross. I discovered that I can order one of their books a year in advance of it appearing in the U.S. by getting it through Amazon.co.uk, which is no more click-distant for me than its U.S. counterpart. (Note to U.S. publishers: the cover art on the U.K. editions is far superior too.)

It wasn't until the MacLean book arrived at the Palatial Overclock Estate (a.k.a. the Heavily Armed Overclock Compound) in an envelope covered in Deutsche Post stickers that I discovered that it came from a warehouse in Germany.

Man, you just gotta love the web. It isn't just that these things are possible. It's that they're so easy that you don't even realize that they're happening.

But it isn't just the web. It's the huge number of independent vendors who use the infrastructures provided by Amazon and eBay to reach out and e-touch someone. It's the amazing international shipping services that somehow transport tangible goods almost as fast as the Internet transports intangible bits. And, in the case of my book, they can do it all for under ten bucks.

I'm amazed. But apparently, some bean counters are disturbed.

The April 28th issue of BusinessWeek had an article on "The World's 50 Most Innovative Companies". Jeff Bezos was on the cover, Amazon being #11. Web services developers are already quite aware of the infrastructure Amazon can provide, quite cost effectively, to e-commerce web sites.

A week later, in the feedback section of the May 5th issue, a reader identified by the screen name "Beejat" writes:

If e-retailers like Amazon are offering computing on tap, doesn't it indicate that they have overinvested in technology? ... I am convinced Amazon has too much firepower - more than it needs to run its business. Its emphasis on its corporate computing market looks like a positive spin on a rather poor capital investment strategy.

Beejat, I know where you're coming from. You're coming from a bottom line, quarterly results, improving shareholder value, reducing costs point of view. The point of view that makes investors money in the short term, while eliminating any vision of the long term.

But Beejat, here's where you're confused. Selling books isn't Amazon's business. Creating the future of e-commerce is their business. Selling me stuff is just the way they unit test it.

The Future Has a Way of Happening

2008-04-20T17:29:00.013-06:00

In his blog Coding Horror, Jeff Atwood answers the question: Should All Developers Have Manycore CPUs? Probably to no one's surprise, the answer is "yeah, duh". Jeff concentrates mostly on the performance and productivity issues. For me, it's all about economics too, but not necessarily the economics Jeff is talking about.

Let's suppose a company has a product that generates, directly or indirectly (as, through service contracts) the bulk of its revenue. I'm talking hundreds of millions of dollars a year. It's the kind of revenue stream most of us poor sods working for tiny start-ups just dream about. This single product is without question the crown jewel of their product line. The installed user base is huge, global, and growing. It is considered by its customers to be a critical and strategic piece of their enterprise infrastructure, and has been for decades.

But, see, here's the thing: this product evolved from code written as far back as the late 1970s. By some estimates, the code base is eight million lines of code, mostly C. Much of it was designed and implemented long before multi-processor servers were cost effective, existing only here or there in various corporate and government labs. Although the application is multi-threaded, most of it was written before there was any way to run it on a platform where the race conditions that might occur in a truly concurrent environment could be exercised.

It wasn't (necessarily) that the developers -- and there would be hundreds of them over the years -- knowingly wrote code that wouldn't work on a multi-core platform. It's just that, well, it wasn't an issue. These developers were more worried about being attacked by a saber-toothed tiger or trampled by a herd of mastadon on the long commute home across the ice pack, then some hypothetical science-fictional multi-core future.

And, of course, even if the occasional forward thinking developer was worried, there was no way to test it.

Fast forward thirty years later. Multi-core servers are now cheap. So cheap, server manufacturers will soon see no point in making a server that isn't multi-core. Even if they wanted to, the day is coming when the microprocessor chip manufacturers will no longer make single-core microprocessors except perhaps for specialized, embedded applications. Chip manufacturers have been pushed into the multi-core future by having hit the wall for CPU clock rates, due mainly to issues in power dissipation. And they're dragging the rest of us in to the multi-core future, some of us kicking and screaming.

This hypothetical company's product, the thing that pays all the bills, won't run reliably on the current generation of servers. And they can't make it work. Finding all the race conditions that show up in a thousand lines of code is a challenge. Doing so in an eight million line code base is for all practical purposes impossible. They've also hit the CPU clock speed wall, and are reduced to limiting their application to run on a single core, while the other cores run (occasionally) an Apache web server for the system administration interface, or maybe blinks some LEDs.

In other words, they are screwed.

I don't want to make it sound like anyone is at fault here. For sure, my crystal ball hasn't been any better than theirs was over the past thirty years. At one time, I actually worked at a national lab which had bunch of those multi-processor, shared-memory systems. We called them supercomputers. But it never occurred to me that I'd have one of those systems in my home. In my basement. Under a table. And that it would have cost only about a grand, U.S. That's just crazy talk.

But for this company, the future caught up with them. When it came to designing for future multi-processor architectures, they effectively, and correctly, practiced an agile development methodology. Unfortunately, the future has a way of happening, and the agile principle of "you ain't gonna need it" eventually turned into "you need it right now, and there ain't no way to get it".

(There is some irony here. This same hypothetical company let go -- or otherwise drove away or simply ignored -- nearly all of their firmware developers. These were developers who were quite experienced in designing code for multi-processor shared-memory architectures, albeit for embedded applications. These guys and gals dreamed concurrently in their sleep, and could have been a valuable development resource for the server-side application architecture. But that amazing short-sightedness is a topic for another article.)

So with all due respect to Jeff Atwood, here's why I think all of your developers and testers should have a multi-core platform on which to write and test their applications: if they don't, and if your product has any success at all in the marketplace, sooner or later you will be screwed too. It's simply a matter of developing and testing on the platform you expect to deploy to the field. Or, as the rocket scientists say, "test what you ship, ship what you test".

I've written about some of the issues in the multi-core future in Small Is Beautiful, But Many Is Scary and its follow-up, and my alter-ego has given a talk on problems software developers are running into in writing multi-threaded code for multi-core (and, in the case of hyper-threading, sometimes even single-core) platforms. The company that issues me my paycheck, Digital Aggregates, put its money where my mouth is: we just added a Dell 530 with an Intel 6600 2.4 GHz quad-core processor to the server farm.

Engineer is the New Black

2008-04-08T11:48:00.000-06:00

Discuss.

Running a Dell Inspiron 530 Headless

2008-03-15T18:00:00.018-06:00

I finally finish configuring Ubuntu Linux on Digital Aggregates' new Dell Inspiron 530 PC with an Intel 2.4GHz Q6600 quad-core processor. I disconnect the USB keyboard and mouse and the flat-panel display I had borrowed from another system in my office, bundle up the power cord and Ethernet cable, pick up the 530, and trundle down several flights of stairs in the Palatial Overclock Estate (what the media still insists on calling the Heavily-Armed Overclock Compound) to the vast corporate computer center in the basement.

I plug the PC into the UPS, plug the Ethernet cable into the HomePlug hub, hit the power button on the 530, and wait a few minutes. Then I try telnetting into the 530 from an old Compaq laptop (running Fedore Core 5 Linux) that I use for stuff like this.

Nothing.

Well, crap, it worked five minutes ago up in my office. I try pinging. Still nothing. I check the Ethernet cable: the LEDs on both the HomePlug hub and the PC look good. I ping the other Dell PC on the same hub, the one that runs Fedore Core 1 Linux, Asterisk, Apache, and Subversion, and it promptly answers. I swap the 530's Ethernet cable to another port on the hub. Still nothing. I remember that these hubs are learning bridges, so I reboot the hub that the 530 is on. Nothing. I trundle upstairs and reboot the hub up in my office and then go back to the basement. Nothing. I go back up one flight of stairs (things are a little spread out in the Estate/Compound), I reboot the hub that the router is on, and then go back downstairs. Nothing. I ping everything that is on the wireless network and that has a static IP address. It's all good.

So I turn the 530 off, disconnect everything, cart the whole shooting match up several flights of stairs, and reconnect everything, including moving the display back over from where I had reconnected it to the other system in my office, an old ThinkPad T30 now more or less in permanent retirement in its docking station and used mostly as an X window server. Turn the 530 on, everything comes up fine.

For some reason I initially focus on not having a display. I google around for "Dell 530 without a display", I check the Support database on the Dell website, of course I find nothing.

Okay, now I remember vaguely having encountered this problem before on another system. I shut the 530 down, disconnect the mouse and the keyboard but leave the display connected, and hit the power button again. The BIOS helpfully announces

Keyboard error - hit F1 to continue or F2 for Setup

Okay, smart-ass, exactly how am I supposed to hit either F1 or F2 when you have a keyboard error? What brilliantly twisted mind thought of that as an error recovery strategy? I suppose you email your ISP when your internet connection isn't working, or dial the phone company on your landline when you can't get dial tone?

So by default you can't boot a Dell Inspiron 530 without a keyboard.

I reconnect the USB keyboard, hit F2 to drop into the BIOS Setup, and poke around until I find under Standard CMOS Features the option of Halt on All Errors, but Keyboard. Yeah, give me some of that! I do a Save and Exit, turn the PC off, disconnect the display, keyboard and mouse, and hit the power button again. After a few minutes I try pinging from my ThinkPad X61 over on my desk.

Golden.

Update (2008-04-05)

If you want to use your Ubuntu system as if it weren't headless, install the VNC server package on your system, and a VNC client on your desktop. I use the RealVNC client on my Windows XP and Windows Vista ThinkPads.

If you haven't already done so, you'll also need to install an X server package on your desktop system. I use Xming on Vista after a lot of pain trying to keep the Cygwin X server working under Vista. I set up my Windows systems so that the X server is started everytime I log into my desktop by placing a shortcut to the program in the appropriate Startup folder.

Login into your Ubuntu system using your favorite TELNET or SSH client. I use PuTTY on my ThinkPads.

Start the VNC server by using the vncserver (or the newer vnc4server) command. You do not need to be root to do this. The VNC server will need to be running on your Ubuntu system anytime you want to use your VNC client from your desktop. I haven't bothered yet to have it started automatically when Ubuntu boots up, since I only use it occasionally.

The first time you run VNC server, it will create in your home directory a subdirectory called .vnc which it will populate it with some files. Edit the file xstartup in that directory so that it looks something like this. All I did to mine was add the last two lines to startup the Gnome Window Manager and the Gnome desktop Session. Your mileage of course may vary.

#!/bin/sh
[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
vncconfig -iconic &
xterm -geometry 80x24+10+10 -ls -title "Desktop" &
gnome-wm &
gnome-session &

Now you can log out from your TELNET or SSH session. Fire up your VNC client on your desktop and log into your server. A complete Gnome desktop will come up in an X window on your desktop system. It's not the fastest thing in the world, but it's great for those occasional system administration chores.

Chip Overclock in the Popular Media

2008-03-02T15:34:00.006-07:00

Mrs. Overclock (a.k.a. Dr. Overclock, Medicine Woman) brought this Dilbert comic strip to my attention today, convinced that I was somehow making an appearance. I assured her that this could not possibly be the case: I have no intention of leaving my current employer, Digital Aggregates.

However, it was in fact your humble servant who was mentioned on the Weekend Edition Saturday Letters segment of National Public Radio a few weeks ago. Several readers sent me email when they heard my name, one of them commenting on the somewhat self-referential irony of the topic.

I apologize for the lack of material lately. I've been gainfully employed for some months now on an interesting project with bleeding-edge technology and smart engineers. (Really, does life get any better?) Unfortunately, that's about all I can say about it; these things happen.

However, thanks to the generous financial sponsorship of Digital Aggregates (who, perhaps foolishly, gave me a budget and a company Visa card), I'll be spinning up an internal project in a few months that I can write about - boy, will I - involving both an embedded system and a multi-core server. More to come as plans develop and details emerge.

One Small Step for a Man, One Giant Leap for Couch Potatoes

2008-01-27T16:46:00.000-07:00

You may recall that the Palatial Overclock Estate (what the media still insists on calling the Heavily-Armed Overclock Compound) has a TiVo digital video recorder. This Christmas, Techno-Santa brought us a Slingbox. Techno-Santa frequently brings us complex electronic devices that lead Mrs. Overclock (a.k.a. Dr. Overclock, Medicine Woman) to gaze lovingly into my eyes and say "This had better come with technical support."

The Slingbox extends your DVR, and hence your cable television feed, to the internet. I'm sitting here watching streaming video of some movie on the SciFi Channel on my ThinkPad X61 laptop over our WiFi network. I have an avatar for the TiVo remote over in the corner of the screen. I can watch television in real-time, watch a DVD, or control the DVR, all from my ThinkPad. (Or, I suppose, from Mrs. Overclock's PowerBook, too.)

Works remotely across the Internet as well. Although the thought of sitting at the local coffee shop and watching something I recorded at home the night before is going to take some getting used to.

It was ridiculously simple to install. The hardest part was dealing with all the dust bunnies behind the three cabinets containing all the A/V gear and our network equipment stack. This promises to being a whole new level of time wasting to my daily laptop usage.

One suggestion for the technorati at large: we need a standard for the secure internet control of A/V devices. This deal with everything controlling everything else via an IR port is silly, when all the devices have a CAT5 cable to the same router just two feet away.

Update (2008-02-06)

The bad news: thanks to the winter storm over the Midwest last week, Mrs. Overclock (a.k.a. Dr. Overclock, Medicine Woman) and I found ourselves stuck in an airport for eleven hours. The good news: it was a frackin' huge airport, and it had free WiFi. When we got tired of riding the trains around the concourses, we settled down with our laptops. Before we left home, I had put a DVD of a television series we had been watching intermittently (six episodes of the 1954 Rocky Jones, Space Ranger) in our TiVo. Sure enough, I was able to watch the DVD, playing in the TiVo in the family room at home, on my ThinkPad while sitting at the airport.

Totally surreal.

Can't win. Can't break even. Can't quit the game.

2007-12-08T16:57:00.000-07:00

From BusinessWeek, December 17, 2007, p. 68, "A Battery That Can Power A Whole Town":

"Hyperion Power Generation (HPG) is developing a nuclear battery capable of powering a town. The size of a hot tub, it can put out more than 25 megawatts for five years, enough to run 25,000 homes."

Here's that non-free lunch you ordered.

The End of Civilization as You Know It

2007-11-25T15:53:00.001-07:00

It has come to my attention that there are those of you out there that do not believe that Western Civilization will eventually collapse. How you justify this hubris is a mystery to me.

Henry Kissinger once said "Every civilization that has ever existed has ultimately collapsed." This seems so obvious that I'm always surprised that others found Dr. Kissinger's quote to be controversial. But for me, to assume otherwise would be to assume that anything wrought by man could be immortal. This is contrary to both physics and history. Thanks to the laws of thermodynamics, nothing is immortal.

Even corporations have a natural life span. Sure, General Electric has been around for as long as anyone can remember. But I bet at one time everyone thought the Dutch East India Company would be a permanent fixture, too (and would always pay an 18% dividend). To its credit, it lasted nearly two hundred years, before finally going bankrupt.

If nothing else, you know that in a few billion years or so our sun will run out of fuel. That's just part of the cosmological circle of life. Unless Western Civilization has escaped the grip of the Earth and our Solar System by then, it (and every other civilization on it at the time) is toast. It's not a matter of if, but when.

So it seems a safe bet that Western Civilization will eventually collapse, like every other civilization before it, permanently and irrevocably. It might collapse sooner than that, depending on various other catastrophic scenarios that are fun to ponder, like major asteroid or comet impacts, pandemics, or the super volcano under Yellowstone National Park erupting. On a purely statistical basis, it seems likely that one of those will happen (maybe more than once) long before our sun goes nova.

I think what people are actually saying, though, when they disagree with me, is that Western Civilization will not permanently collapse in their lifetime. This, I might agree with. But I would counter with that it seems almost a sure thing that your little corner of Western Civilization can collapse temporarily, given the right circumstances. This is the lesson of Hurricane Katrina. It was a hard lesson to all involved, but entropy means it is a lot easier to move from order to disorder (like, say, in Baghdad) than from disorder to order (as in New Orleans).

I used to spend my summers as a kid living in a farm house without running water, telephone, or the Internet, only a fireplace for heat, one iffy channel of broadcast television on a good day, and electricity most of the time. (I read a lot, drew water out of a well, and routinely walked around with a firearm.) As a professional, I've stayed in hotels many time zones away, where the tap water was not potable, and where I endured regularly scheduled rolling blackouts that put an end temporarily to elevators and air conditioning. (I also ate a lot of food which I had no idea what it really was, but I sort of liked that part.) These experiences really drove home the fact that the conveniences of modern day life are not evenly distributed, even in these United States.

I'm a fan of author Steven Pressfield. He's probably best known for his golf book The Legend of Bagger Vance because Robert Redford made it into a movie starring Will Smith, Matt Damon, and Charlize Theron. (Yes, I know it's not really about golf.) But if you've read more than one book by Pressfield, you probably already know that he is better known among his fans as an author of well researched historical fiction taking place in ancient Greece.

His book Last of the Amazons is about the siege of the city of Athens by the Amazons and their allies circa fifth century B.C. Greek scholars are still uncertain whether the Amazons, a tribe dominated by fierce woman warriors centered around what is now Eastern Europe, were real or myth. But if they were myth, the ancient Greeks devoted a great deal of time and effort to making bas-reliefs depicting the mythical war between them.

In Pressfield's book, we see Athens right at the early stages of its experimentation with democracy. The fictional Greeks in his book were aware of how fragile this beginning of Western Civilization was, and how easily it could all come tumbling down. Losing the war meant more than just death or enslavement. It meant an end to democracy, the end of the city state, and a return to being a nomadic tribe of hunter-gatherers living in animal skin huts.

I thought about this a lot while reading Pressfield's book.

When I say that Western Civilization is a house of cards, what I'm saying, in part, is that we shouldn't take civilization, Western or otherwise, for granted. It is fragile and all too easily lost. And once lost, difficult to regain.

Peak Oil and Finding Good Help

2007-11-18T08:33:00.000-07:00

I had lunch the other day with Ken, my local Ph.D. in theoretical physics who somehow ended up with a career in telecommunications. He remarked that ethanol fuel wasn't cost effective because without the government subsidies it cost more energy to make than it yielded. This reminded me of the fact that we don't have to actually run out of oil; we just have to run out of oil that takes less energy to extract than it yields. There may be lots of oil left in the ground, waiting for some more cost effective method of extraction.

I'm a fan of the blogs of several economists. One of them wrote the other day that the best way to break the ethanol myth was quit having early caucuses in Iowa. The candidates all go to Iowa and come away with the notion that corn is really important. If we had early caucuses in, I dunno, Colorado, maybe they'd think oil was important. Or toxic waste. Or snow.

Corn isn't even nutritionally that great. Mostly it's sugar and fiber. And we lack the crucial enzymes naturally to break down what amino acids it does have. Which is why you can starve to death eating corn unless it's treated with lye. I think a really interesting thriller would be to have the bulk of the U.S. population develop a food allergy to high fructose corn syrup, rendering all processed food inedible. Not as crazy as it sounds. Mrs. Overclock (a.k.a. Dr. Overclock, Medicine Woman) tells me that the development of food allergies is not well understood, happens suddenly, and is at least anecdotally linked with high exposure.

In some ways I find this thread connected with colleagues' complaints on their difficulty finding competent technical people. Welcome to our (near) future. I worked at a university for years, and we followed the "engineer production" curve closely. It's been cyclic for many many decades. A guy I used to work with when I was at a national lab always said that the big U.S. Department of Energy labs (with whom we worked closely) were a welfare program for physicists, because it was likely we'd need physicists for reasons of national security, and if we needed them, we couldn't wait a generation for the system to create them. I'm wondering if something similar is going to happen with the Information Economy. We're going to find out that we need to artificially stimulate the production of engineers because we can't tolerate the latency in the manufacturing process. This is a case where free markets don't really work. (Adam Smith didn't believe free markets totally worked either.)

Another friend of mine passed along an article in the WSJ Online where Dow Chemical got into trouble with its biggest customers by daring to suggest that maybe we should be saving oil to make important stuff like plastic, instead of burning it up. They had to backpedal when auto makers said "increase mileage -- are you crazy?!?"

To to link the threads even more, the friend who passed along that article was a technologist with multiple college degrees who left a high paying job with a large telecommunications equipment manufacturer to become a mail clerk in a civil service job for his city government. He was disgusted and just wanted to have an 8-5 job where he could turn his brain off. Another old friend of mine who is my age left the same company a few years ago to enter the police academy, a decision that while I have no desire to emulate, I never the less greatly admire. Now he's a sargeant in the police department, training other officers. These guys aren't reflected in the unemployment statistics, because they aren't unemployed; they just bailed out of the technology domain out of disgust.

I admit that seeing simularities between finding competant software engineers and peak oil may seem kind of twisted. But oil and software engineers both are resources that are not easily found or produced. In some dark part of my mind, I'm kind of looking forward to the collapse of Western Civilization. I'm pretty convinced it's all built on a house of cards, requiring cheap energy and lots of technologists to keep it running, both of which we're exhausting (in all senses). I am confident I won't survive the collapse, but what the hell, it'll at least be interesting.

One thing for sure -- upper management will find a way to blame the engineers for all of it.

Dickheads.

There Ain't No Such Thing As A Free Lunch

2007-11-18T08:27:00.000-07:00

Some friends and I have been talking about peak oil and the implications of actually finding a cheap, plentiful alternative energy source.

I'm not a global warming expert (although I have stayed at a Holiday Inn Express), but the role greenhouse gasses play is that they increase the retention of the ambient heat that we generate. Instead of letting it be emitted as infrared into space, they reflect it back or store it as heating and emit it back. The CO2 itself doesn't generate any heat itself, it just traps the heat we create (hence the name "greenhouse" gas). So global warming is an issue of ambient heat generation AND our inability to dissipate it because of greenhouse gasses.

The role that energy production and its use plays in heat generation is covered in the second law of thermodynamics which deals with entropy. All energy is, over time, broken down into unusable heat, because the entropy (disorder) of all physical systems increase over time. Meaning: every single bit of energy we generate and use eventually turns into heat. It may be a multi-step process, but as you drive your car down the road, your engine (electric or gasoline) generates heat; your tires generate heat from friction with the road; your car generates heat from friction with the air; the refinery that made the gasoline generated heat in its production. It all becomes heat. You can't get around this: it's the way the Flying Spaghetti Monster built the universe in his/her/its/their infinite wisdom. "Heat death" is pretty much the ultimate end of everything. When we're dead and buried, as we rot we generate heat, as our bodies release their stored chemical energy.

If we have some form of really cheap, really easily had energy, such that our energy production and use really increases, our heat generation rises by exactly that same amount. Greenhouse gasses in the atmosphere means that heat gets trapped instead of being radiated away as IR. But even if we didn't have any greenhouse gasses in the atmosphere, there is a physical limit to how much heat can be generated away per unit time. Basically, cheap available energy means we eventually cook ourselves to death. Literally.

Are there ways around this? It's been seriously suggested we build giant lasers that would somehow (this part is really unclear to me) radiate waste heat into space. I can imagine an SF story where we fry some passing alien craft and start an interplanetary war.

This has been proposed even for space craft with large power plants, since the only way to get rid of heat in space is by radiation; neither convection nor conduction works because there's no material to which to convect or conduct, like air or water. This is one of the reasons the Space Shuttle has big honking radiators built into the cargo bay doors and why they have to open them up when in orbit, even if they're not using the cargo bay. Their waste heat has no where else to go. This also places a physical limit to how much energy the Shuttle can expend, and how big a Shuttle we can build.

Quoting Robert Heinlein: TANSTAAFL. Cheap energy means increased heat production. In a way it just moves the problem somewhere else.

If you think about it, what is oil or coal? It's stored chemical energy. Where did the energy come from? From plants, and maybe some dinosaurs, that lived, ate, and grew millions of years ago. Because no system is 100% efficient, those plants (and dinosaurs) consumed a LOT more stored chemical energy, in the form of plants, dinosaurs, and soil and chemicals that once was plants and dinosaurs and rocks, than they created. Today we're taking advantage of a process that began millions of years ago, and that we cannot replicate. We can't make more oil because, besides the fact that we're impatient and can't wait millions of years (hence we invade small middle eastern dictatorships), the natural resources that went into making the oil, the incredibly rich biosphere, doesn't exist anymore. It went into making the oil that we DO have right now. Pretty much a one-way process.

Just like entropy and heat death.

LOLsupervillain

2007-11-10T08:37:00.000-07:00

We all have guilty pleasures. I CAN HAS CHEEZBURGER is one of mine. Now the LOLinator lets you can enjoy any web site through an LOLcats filter, including this one.

Do you know where your pension is?

2007-10-28T08:22:00.000-06:00

"Expecting a Lump-Sum Pension? Read This" in the November 5, 2007 issue of BusinessWeek contains this little bit of news:

Starting next year, companies won't be able to make lump-sum distributions if their pension plans are more than 40% underfunded.

Congress is understandably concerned that the growing wave of baby boomers nearing retirement coupled with underfunded pension plans will put the plans underwater if many retirees take a lump-sum distribution (as most do). It would be like a run on the bank. Prohibiting lump-sum distributions from underfunded plans gives the company time to fix the pension fund.

This is probably only of interest to folks young enough to still be working, but old enough to have a pension plan and thinking of taking the money and running. Many high-tech companies either never had a pension plan, or quietly froze their plan some years ago.

Still, when I cashed out of a company that I had been with for a decade, the lump-sum distribution I got from their frozen pension plan was nothing to sneeze at. It is now earning interest in an Individual Retirement Account that I control.

If you're thinking of retiring, or just thinking of leaving and cashing out like I did, the article suggests ways you might be able to determine the health of your company's pension fund.

The Return on Investment in People

2007-09-26T10:03:00.000-06:00

Starting in 1974, I spent about fifteen years at a university that was next to a major military base. To no one's surprise, many of my classmates, students, and co-workers were at that time currently or formerly in the military. While I was working at the campus computer center, I had three such co-workers who had two things in common: they were all former nuclear weapons technicians, and they were all going to college on the GI Bill.

This morning, National Public Radio's Morning Edition featured a story by John McChesney titled GI Bill's Impact Slipping in Recent Years. It's worth a listen. Some interesting facts from the story:

At the close of World War II, only 5% of Americans had college degrees.

Only 40% of the veterans of WW II had high school diplomas.

The GI Bill paid for full tuition and books and provided a modest living stipend.

Ten million WWII vets went to college on the GI Bill.

That number included fourteen who would go on to win the Nobel Prize.

Twenty-four who would go on to win the Pulitzer Prize.

The GI Bill would educate 91,000 scientists.

And 67,000 physicians.

As well as several presidents, senators, and Supreme Court justices.

How much did it cost? Educating the WWII veterans cost about $50 billion in 2007 adjusted dollars, and some estimates place the return to the U. S. economy at a equally adjusted $350 billion, a seven-fold ROI. The increase in tax dollars alone just from the boost in earning power for the newly minted college graduates more than paid for the GI Bill.

The story is part of a continuing series on the reduced effectiveness of the GI Bill. Given the statistics cited above, it would be hard not to be in favor cranking up the investment in education for current veterans.

But surely there's a more general lesson to be learned here regarding the ROI on investing in education for your employees. I've personally witnessed a large technology company reduce its educational subsidy from "your entire degree" to "just the classes we think are pertinent to your current project", and downsizing its employee training program from a rich set of intense forty-hour in-house classes to generic introductory web-based presentations. As both an employee, and as a former educator, it broke my heart to see how little interest the company had in investing in its people, beyond reminding them at every six-month review that "continuous learning" was critical to their continued employment. How they accomplished that continuous learning was left as an exercise for the employee.

Do we really think the ROI for those WW II vets is that substantially greater from the ROI we get from investing in the education of our employees? And as an employee, doesn't it suggest to you that education is virtually free, given the likely increase in your earning power?

Employees should aggressively seek training and education, whether that means choosing to work for companies that provide and subsidize it, or paying for it themselves.

I'd be interested in comments from any veterans on their experiences, good and bad, with the GI Bill, and its impact on their lives. And comments and suggestions from readers in general on their experience with training and education provided or subsidized by their employer.

Pocket Web Service

2007-09-20T16:43:00.000-06:00

In A Future Without Keyboards and Asterisk, WiFi, and a Nokia N800 Internet Tablet, I mentioned how I was playing with the Nokia N800 Internet Tablet, a pocket-sized, Linux-based, WiFi-capable, internet appliance. I also mentoned that I had installed a C Virtual Machine (CVM) on it, a version of the JVM configured for the Java Connected Device Configuration (CDC).

After just a few hours of futzing around, I can now serve the entire Digital Aggregates Corporation web site off the N800 using some Java code I slung together based on the prior work of Jon Berg of turtlemeat.com. Sure, it's not the fastest or even the smallest web server on the planet. I'm not about to expose it outside the company firewall. And of course I'm sure I'm not the first to do this. But I can sit at my laptop and browse pages on a web server that I'm carrying around in my shirt pocket.

Here is the source zip and the jar file (served off the production web server) if you want to have this kind of joy yourself. I dropped the jar file into the Foundation directory that comes with the CVM distribution, placed a copy of the entire web site in a www directory, then fired the server up with this shell script.

#!/bin/sh
cd Foundation*
./bin/cvm -cp chapparal-0.3.jar \
com.diag.chapparal.http.Server \
/home/user/www 300000 8080

I then pointed my laptop's web browser at http://192.168.1.106/index.html and watched wackiness ensue! (The IP address is DHCP served from behind my NAT firewall, so your mileage will vary.) The three arguments to the Server main are the root path prefixed to every file request, the number of milliseconds the server stays up, and the HTTP listen port to use.

I developed the whole thing on my laptop using Eclipse, tested it using junit, built it for the target with ant using the 1.6 compiler in 1.4 source and target mode, and then downloaded the jar to the N800 via its own web browser.

Wicked mad fun!

Update (2008-01-03)

Sun Microsystems offers a Java SE 5.0 implementation for Linux on an embedded PowerPC that you can use for a ninety-day free trial. (If you want to ship it as a product, you have to pay a royalty.) As an experiment I recently installed this JVM on such a system, and as a demo ran my Java-based pocket web server on it. Took almost no effort, worked like a charm. It makes a nice proof of concept.

The Sapir-Whorf Hypothesis

2007-09-19T09:48:00.000-06:00

"When all you have is a hammer, everything looks like a nail." -- Bernard Baruch

In Just In Time Learning, I argued that we should concentrate on learning the abstract rather than the concrete, for example new design patterns instead of new programming languages, because of their broader applicability. Now it may appear that I am going to argue for just the opposite.

One of the best ways I've found to learn new design patterns is to learn new programming languages that depend upon those patterns. One of the problems I have with using C++ to teach object oriented programming is that you don't have to use OOP to use C++. This was by design. It allows C++ to more easily and incrementally penetrate into legacy C code bases. You can use C++ as a "better" C, and ignore all the OO stuff. But this allows you to cheat if you are using C++ to learn OOP. Better to use a language like Java, which forces you to use OOP. Well, I suppose you can cheat in Java too, if you care to make everything static, but it's a heckuva lot more work than to just do it the right way straight off. Learning Java forces you into an OO way of thinking.

This is a variation of the Sapir-Whorf Hypothesis. No, Sapir-Whorf doesn't have anything to do with Klingons, although it may have something to do with the Klingon language. In the early to mid-twentieth century, linguist and anthropologist Edward Sapir and his student Benjamin Whorf formed a hypothesis that suggested that any natural language conditions the thoughts of the people that use it. In other words, not only does human culture influence the language used by that culture, but that the language in turn influences the thoughts of its speakers. If your natural language required that every sentence started with "Please", would children raised in such a society inevitably be more polite?

The hypothesis is essentially untestable, and has hence been controversial. Separating people from language for the purposes of a double blind study is impossible. But as a computer scientist and software developer, I find it hard not to be compelled by it. Because not only to do the design patterns you use influence what programming language you may choose to develop in, the programming language you develop in may influence what design patterns you choose.

In undergraduate and graduate school (this was back in the Dark Ages, you understand), I was lucky enough to have been exposed to a wide range of programming languages. C, much less Java, hadn't even been invented by the time I was an undergraduate. There was a rich culture of experimentation and innovation regarding programming languages, because no one language had really taken root as the "default" language to use for software development the way C and Java have today.

For sure, FORTRAN was was the language of choice (and still is) in scientific computing, and COBOL was the lingua franca for business applications. But every developer back then knew that neither FORTRAN nor COBOL was perfect for the burgeoning backlog of desired software applications, particularly for systems programming. That's why I ended up writing thousands of lines of assembler code (frequently using complex macro packages that made it look like a higher-level language) in the 1970s, and why C was invented at Bell Labs as a kind of structured assembler language. But it also lead to dozens, maybe hundreds, of other programming languages being tossed out into the software development community to see if any of them would stick. Let a thousand flowers bloom; let a thousand schools of thought contend. Except unlike Mao, the computer science community meant it.

Some of these languages were domain specific. Some were designed around novel hardware or operating system architectures. Some tossed the whole idea of procedural programming out the window, leading to whole new techniques for designing algorithms. Learning and programming in these languages lead to a many new paradigms and patterns being imprinted on your brain.

But see, here's the thing. Many of these new schools of thought can be adopted to languages like C, C++, and Java. They can lead to new and better ways to solve problems. Ways that were more efficient, more easily understood, and even more economically maintainable.

Some of the languages I learned in those Dark Ages persist today. Some do not. Some only existed for a short while in the feverish brains of my colleagues. But from each of them I learned something that I might not have learned had I just learned C or Java. Here are some examples.

Prolog. Prolog is a logic programming language. You do not write procedures or methods. You make logical statements that are themselves either true or false, or which can be evaluated as true or false with the insertion of boolean values into variables. A Prolog program might consist of hundreds or even thousands of logical statements, some standalone, some referring to one another. When you run the program, you set the initial conditions of any input variables, and the Prolog interpreter searches the entire solution space described by the Prolog program for a path through the search tree that could succeed. (There may be more than one.) If it exhaustively goes through all possible paths without finding a path that succeeds, the program fails. Of course, there might be a print statement or other side effect along the way.

Here is a Prolog program that was once part of my USENET posting signature. It's not too hard to guess what it means.

belong(opinions,me).
belong(opinions,_):-!,fail.

Yep, it's a disclaimer: these opinions belong to me; they do not belong to anyone else. Hacker humor. The bang prevents the interpreter from back tracking back through the solution tree to try another path, and the fail causes the program to fail.

Prolog blew my mind because it was such a different approach to writing algorithms. It's syntax was very grammar like (I was really into formal languages and parsing at the time), and I immediately set to work using it to implement a parser for another programming language. When I submitted a sample program in that language to my Prolog program, if the sample program was syntactically correct, the Prolog program succeeded, otherwise it failed. Side effects managed the symbol table and emitted pseudo-machine code.

Lisp. I was never a Lisp hacker, but the List Programming language was my introduction to functional programming style and the idea of representing complex structures as trees and performing transforms on them. Both of these ideas, functional programming style and structure representation and transformation, became part of my every day software design tool kit to show up again and again in the systems I develop. I think if I were to encounter Lisp now, I would appreciate it so much more than I did as an undergraduate, having spent the past thirty years applying its lessons in countless systems and applications.

SNOBOL. SNOBOL is a string processing language with regular expressions. Sure, that seems mundane now, but this predates UNIX and awk. Snobol taught me how to think of strings not as collections of bytes but as malleable forms that could be described and manipulated using complex regular expressions. Years later when I starting using UNIX, writing parsers and data tranformers using awk came naturally, partly because of my prior SNOBOL experience.

Back in the day it was a little game to see how many lines of code it took to write an 80-80 lister. An 80-80 lister was a program that read in punch cards and printed their content to the line printer. Not that you really needed to write an 80-80 lister, the IBM utility IEBGENER worked just fine. But it was just a quick way to evaluate the power of a programming language. An 80-80 lister in SNOBOL looked like this.

OUTPUT = INPUT

It was almost cheating, really.

Simscript. Simscript was an invention of the RAND Corporation, that wacky place that also brought us the Delphi technique of estimation and most of the ideas behind Dr. Strangelove. Simscript is a procedural programming language with support for simulation in the same way that Java supports multithreading: as part of the language itself. I only used Simscript as a student (it is a closed proprietary language, hence hard to get to), but all during my career I found myself wishing I had it around. For some reason I keep encountering the need to write simulations with event streams whose emission rates meet some statistical distribution. What is a few thousand lines of code in C become a few hundred lines of code in Simscript. I learned the basic design patterns of simulation in Simscript as an undergraduate, and I keep applying them in my professional career over and over in other languages.

Forth. Forth is a stack-oriented threaded interpreted language that is still in use today. Here, "threaded" has nothing to do with multithreading, but indicates how the interpretor stores the intermediate form of the program. A Forth program consists of a free form stream of words and numbers. New Forth words can be trivially defined. There is no compiler. Words are parsed and either executed directly or converted into some intermediate form (typically an address) into a dictionary as you type them in. Here is the definition of a simple Forth program that squares its input.

: SQUARE DUP * ;

This is a new word called SQUARE. It duplicates the value on the top of the stack so that there are two copies on the stack, then it multiplies those two values together while popping them off the stack, and pushes the result on the stack. The following Forth code squares the value of 12 and prints it out.

12 SQUARE ." SQUARE=" .

A useful Forth interpreter can be implemented in just a few kilobytes, and as such it remains popular in embedded circles. There is an IEEE standard for portable boot firmware that is Forth-based, and to this day you can walk up to many Solaris-based Sun workstations, hit a control sequence on the keyboard, and break into a Forth prompt from an interpreter in the boot ROM. I've embedded a Forth interpreter as a shell inside a C++ application, and have also used Forth's threaded interpretive approach in C and C++ code as a kind of self-modifying code model.

SAS. SAS is another closed, proprietary language that I've been fortunate enough to have access to several times in my career. It's a statistical analysis system, not a language really, but more like a large collection of feature-rich statistical programs with a consistent, high level interface.

I love SAS. Because simulation keeps rearing its ugly head in my work, I keep needing a way to crunch a lot of numbers and produce beautiful charts to summarize it. Spreadsheets don't cut it when you're dealing with gigabytes of data. For SAS, that's all in a days work.

SAS taught me the value of a consistent UI among a toolchain, and how that UI could look like a higher level language. It also taught me how to manage large datasets, something else it necessarily does well.

FP. FP is a pure functional programming language, pure in the sense that it has no concept of variables. It was first described by IBM fellow John Backus, the inventor of the FORTRAN programming language and Backus-Naur syntax, in his Turing Award lecture. It combines some of the ideas behind Kenneth Iverson's APL (another interesting language) with a functional programming style in an effort to liberate software design from the constraints of the traditional von Neumann computer architecture. I never actually used a working FP compiler, but the language turned out to be the partial inspiration of much research during my graduate student years.

Functional programming has informed my software design for the past thirty years, breaking me free early on from the traditional thinking of "compute a value, store the result" and the need to store partial results in variables. The functional programming paradigm maps to Java particularly well, since exceptions can be used to handle errors when using a functional design model.

BAFL. BAFL was another functional language based partly on FP. It existed only in the research group from which my thesis project emerged. What made BAFL really different from other languages, besides being functional instead of procedural, is that it had lazy evaluation. It never did a computation until it was convinced you were actually going to use the result. Lazy evaluation is the interpretive equivalent of the common compiler optimization of not generating code for parts of the program which have no effect.

I remember once we wrote this huge BAFL program to compute some mathematical function or other, turned it loose, and... nothing. We made a couple of corrections, tried it again, and... still nothing. We were looking for the bug when we realized we never told it to do anything with the result, so it never computed it. We added a print statement, and then the interpreter finally executed the huge evaluation tree that it had built.

BADJR. An implementation of BADJR, a language which only existed in the mind of my thesis advisor and mentor Bob Dixon, was my thesis project. In many ways it was the most bizarre programming language I have ever used. It had arbitrary precision fixed point arithmetic, implemented in two's complement base 100 binary coded decimal. It had no language constructs for iteration, instead opting to use efficient tail recursion in which the stack doesn't grow. And it had single-assignment variables: you could assign a variable a value once and only once, after which it was immutable.

When I describe this to people, particularly the single assignment part, a common initial reaction is "this can't work". The idea of single assignment seems more foreign than having no variables at all. But it is simply a very different programming style. The value of a particular variable in a particular stack frame can never be changed, but you can recurse and create a new copy of the same variable in a new stack frame and change that version.

BADJR was sufficiently powerful that another graduate student used it to implement a Prolog interpreter for his thesis project (and he went onto Bell Labs a decade ahead of me -- I always was the slow one). The entire research program from which my thesis emerged was inspired by Japan's Fifth Generation Computer Systems Project, which was to use AI (okay, so now you know it failed), massively parallel computers, and dataflow architectures, to take over the world. BADJR's single assignment architecture mapped well to massively parallel dataflow architectures, and the 5G project had already expressed an intent to leverage Prolog in its AI work. So we thought this was pretty cool stuff.

And it was, in its own way. BADJR pounded recursion as a school of thought into me like no other effort had. It's arbitrary precision arithmetic taught me how multiplication and division actually worked (and led to Mrs. Overclock giving me a copy of Knuth, including the ever-so-critical Seminumerical Algorithms, as a gift). And the two garbage collectors I had to implement for it (reference counting, and mark-and-sweep) helped me appreciate the issues underlying GC in the JVM decades later.

Assembler. Sure, laugh. I learned how and why programming languages work under the hood by writing tens of thousands of lines of IBM BAL and PDP-11 PAL assembler code (and made me a real C zealot as a result). That experience has served me well in my embedded work, when figuring out some of the more esoteric Linux kernel macros, and in fixing the occasional errant DSP application.

But more than that: my early assembler work circa 1976 was my introduction to object oriented design. No, really. The OS/360 I/O subsystem's assembler code introduced me to polymorphism, inheritance, modularity, and encapsulation, and to such OO mechanisms as dynamic binding and virtual tables. When C came along to be the portable assembler language I had always wanted, I used some of these same techniques, admittedly primitively implemented. When C++ finally came along, I breathed a sigh of relief: finally, a language that does all this for me.

Okay, maybe I really wasn't that smart. I'm not sure I really appreciated all those design patterns in the IOS. I just knew a good idea when I saw it, and the first rule of engineering is: steal all the good ideas.

Today I might recommend languages like Ruby and Haskell, although Prolog, Lisp, Simscript, Forth and SAS are still alive and kicking, and still very much worth learning just for the purposes of bending your head around their very different ideas of how to code. And assembler, maybe particularly Intel P4 assembler, still has its place too.

Learning new, and more importantly, radically different, programming languages will make you a better developer even if in your day job all you use is C or Java.

What new and different programming languages would you recommend?

Hail Ming!

2007-09-17T16:48:00.001-06:00

Domo Arigato, Mr. Roboto

2007-09-17T12:17:00.001-06:00

"Travel is fatal to prejudice, bigotry, and narrow-mindedness, and many of our people need it sorely on these accounts." -- Mark Twain

Mrs. Overclock (a.k.a. Dr. Overclock, Medicine Woman) and I just returned from nearly three weeks in Japan. Five days of it were spent attending Nippon 2007, the 65th World Science Fiction Convention, in Yokohama. Nine days were spent with a group of over two dozen fans from the convention, travelling around Japan seeing the sights, having a grand time, and just generally making a nuisance of ourselves being henna gaijin. The remaining time Mrs. Overclock and I spent making a careful survey of the extensive and wonderful Tokyo subway systems, gawking like the small town rubes we really are.

First, the convention. The location of the World Science Fiction Convention is chosen by voting members of the WorldCon two years in advance from among the bidding locations. The WorldCon is completely fan-run. The most senior committee members may receive some compensation since for them it is very much a full time job, but for every one else it is a labor of love. For a convention that pulls anywhere from 2000 to 8000 attendees, the fact that it is a volunteer effort alone makes it a remarkable undertaking.

Nippon 2007 had about 2200 attendees, of which about 800 were from outside of Japan. While many WorldCons are held outside of the U.S., this was the first to be held in Japan, and hence the first to be run by Japanese fans. If my own experience is any indication, it was a complete success. The Japanese fans deserve a big domo arigato goziamas from this henna gaijin. Well done.

For many of us from the west, being in Japan is the closest we are likely to come to making first contact on another planet. For science fiction fans, this is a very resonant thing indeed. There were times I felt like I was living in The Mote in God's Eye by Niven and Pournelle, along with all that implies. (I might add that Mote is the only novel of any kind that I reread every decade or so.)

It is as difficult to quantify or qualify science fiction fandom as it is to precisely define science fiction. One of our tour group remarked that it is less than a family, but more than an organization. Mrs. Overclock characterizes it as a tribe, as in "Nothing good can come from dating outside your tribe." I like this a lot. Merriam-Webster says a tribe is "a social group comprising numerous families, clans, or generations together with slaves, dependents, or adopted strangers" or "a group of persons having a common character, occupation, or interest". Either of these serves as a workable definition of science fiction fandom.

I always know that I'll share some common interest with any fan. Perhaps I'm not into filk, maybe you aren't into anime, but we can both agree the latest William Gibson novel is just frackin' great. That's why travelling with fen (the plural of fan) almost always works well: you know the dinner conversation is going to be interesting, and almost all fen have a nearly insatiable thirst for the new and different, usually for the downright weird. They also seem to almost all have a wicked good sense of humor.

On our way to distant WorldCons, Mrs. Overclock and I play spot-the-fan in airports. It is cheating if they pull out the latest Gregory Benford novel. It is interesting to note that Mrs. Overclock and I had no problems identifying Japanese members of our tribe, regardless of the fact that we shared no spoken or written language with them. Apparently the fan gene transcends ethnic boundaries. Truly, this warms even my neutronium heart.

If science fiction is the religion of fandom, then it is a religion which has a huge and varied pantheon of gods. This is not unlike Shintoism, or for that matter Greek and Hindu mythology. And like those other pantheons, our gods walk among us. I had casual conversations at this particular convention with Gregory Benford, Larry Niven, and Joe Haldeman, and once I observed Mrs. Overclock chatting with Charles Stross. (For that matter, at least two members of our tour group were published authors, and Mrs. Overclock herself appears in a DVD and on two music CDs of science fictional sensability that you can purchase on Amazon.com.)

Lest you think it's all about elves, Star Wars, and Spock ears, one of the panels I attended was a slide slow and Q&A session by a forensic anthropologist who worked on a U.N. war crimes investigation team in Kosovo, Serbia. Holy crap, that was an eye opener; how far the Austro-Hungarian empire has crumbled. Other panels I attended included topics like The Sapir-Whorf Hypothesis (with Geoffrey Landis) -- no, that has nothing to do with Klingons, it's from the field of linguistics, the growth in public surveillance (with David Brin), the current thinking in life extension (with Greg Benford and Joe Haldeman), the Singularity (with Benford and Charles Stross), and legal aspects of current directions in intellectual property law (with Cory Doctrow). Only at a science fiction convention, folks. Maybe they should call it an "awesome mind blowing stuff convention".

"The future is already here. It's just not evenly distributed." -- William Gibson

This quote came to me while I found myself travelling with a group of more than two dozen fen at nearly 200 miles an hour across Japan in a superexpress or "bullet" train. It may be that every age thinks of itself as an age of miracles, but this is the age of miracles in which I live: that I can be sitting in first class comfort reading a book while traveling at the speed of Formula 1 race car. I can do so in the company of a group from five different nations (U.S.A., Canada, Great Britain, Australia, and Sweden) yet all in the same tribe. And I can order an iced coffee from the lady with the food cart. Sometimes you just gotta step back and live in the moment.

Fandom is populated by an inordinate number of technologists, and perhaps rightly so, since it is they that must work in the future professionally. But our little group of tourists included two physicians, two lawyers, a nurse, a librarian, a retired school teacher, an airline pilot, someone running for public office, and a megalomaniacal supervillain. It was about evenly distributed in gender (provided we agree that there are two genders), and probably statistically typical for sexual orientation and physical abilities. We were probably not typical for number of college degrees per capita.

What the demographics won't tell you is that it was a damned interesting group of people with which to travel. It was with this group that we made our whirlwind tour of Tokyo, Mount Fuji, Hakone, Hiroshima, Miyajima, Kyoto, and Osaka, all the while dealing with the effects of Typhoon #9, a.ka. "Fitow", as it hit the coast of Japan. It was sobering to stand near ground zero in Hiroshima and realize that with the exception of a single structure preserved for posterity, everything around us dated from one fateful millisecond in 1945. While we did not see every single Shinto shrine and Buddhist temple in Japan (seems like there is one just around every corner), I'd like to think we hit all the big names. Despite the fact that I purified myself at every one, I still managed to uphold my tradition when travelling abroad and bring home a new strain of viral crud. When the epidemic hits North America, you can blame me.

Our tour would not have been nearly so successful (in fact, it could have been total disaster -- getting fen to break their target lock with shiny pretty things is like herding cats) without the hard work of a lot of folks, and they also deserve a big domo: fearless leader and fan wrangler Ken Smookler, North American travel agent Alice Colody, our extraordinarily patient Japanese guides Kaori-san, Nobuyo-san, Yasuko-san, Yuki-san, and the many other expediters and drivers whose names I didn't catch. You brought 'em back alive!

"I don't think we're in Kansas anymore, Toto." -- Dorothy in The Wizard of Oz

Mrs. Overclock and I completed our trip with a few days spent exploring Tokyo. We stayed at The B Akasaka, a small boutique hotel that I would recommend. It is five minutes walk from the Akasaka subway station on the Chiyoda line that is right next to (there is a God) a Starbucks. Every morning we could be found there with our lattes and curry pies, pouring over maps planning that day's campaign, while avoiding the commuter rush hour.

Tokyo is unbelievably huge, to us anyway (maybe less so if you live in New York City or London). It is divided up into twenty-three wards, any one of which is the size of downtown Denver Colorado. Tokyo and Yokohama are the first and second largest cities in Japan, and the Tokyo-Yokohama corridor is the most densely populated region on the planet. We took an hour-long bus ride from Yokohama to Tokyo and never once left the urban cityscape. I've read that it was this corridor that was the inspiration for William Gibson's U.S. eastern seaboard "Sprawl" in his novel Neuromancer.

But we mastered the London tube, so we were equally determined to tackle the Tokyo subway system. We managed to navigate our way not only across different subway lines, but even across different competing subway systems, the Tokyo Metro and the Toei. We found our objectives in Akihabara ("Electric City"), Asakusa, Shibuya, and Shinjuku. We had a good time. We drank a lot of beer, hydration under such circumstances being crucial to clear thinking. That, and we never had to drive.

Several times while in Japan, and never more so than while using the subway, it occurred to us that there are just so many successful design patterns for doing anything. And so it turns out that the Tokyo subway works much like the London, Chicago, and Washington D.C. subways. This also applies to getting a cab, ordering a meal, and paying for a scale model Tachikoma in a Akahabara robot store.

We did encounter some new patterns.

The shinkansen or "superexpress" trains (only called "bullet trains" in the West) have almost no luggage space. It's a good thing too, since a superexpress stops for only about one minute at each station (this is not an exaggeration). You have to be at the door with your luggage in hand ready to get off or on. The Japanese solve this problem by shipping luggage seperately via motor freight. We used this successfully twice during our trip, packing for a few days in backbacks until we could rendezvous with our luggage. We also did laundry twice during the trip, having taken only a week's worth of clothes. Partly this was due to the desire to travel light, but also due to weight restrictions on domestic flights.

We successfully deciphered the bizarre Japanese system of street addresses that confounds even its cab drivers to find Mrs. Overclock's Japanese bead factory outlet. We are both pretty amazed that this worked. The Japanese system does not make use of street names. In fact, with the exception of very major thoroughfares, streets are not named. Although some Japanese cities are based on grid system adopted from the Chinese, Tokyo, especially the older parts, is a maze of twisty passages which all look alike. Apparently this was a deliberate attempt by paranoid shogun to make invasion difficult.

We ate at a typical Japanese lunch counter, where you begin by inserting coins into a vending machine. As you insert coins, possible meal selections are illuminated on the menu on the front. When you finally make a selection, you get a ticket. You give the ticket to the person behind the counter, and after a few minutes of hash slinging your meal appears. The staff never handles money. Mrs. Overclock and I discovered that the chicken katsu don was just like what we eat at our favorite Japanese restaurant near our home.

The Japanese have a very civilized approach to religion: you can have none, or you can have several simultaneously, and only practice when it suits you. I found this practical approach so compelling that I found myself praying at every Shinto shrine and Buddhist temple we visited, when I haven't been to a Western church in years except for weddings or funerals.

My month spent in the People's Republic of China in 1995 was a life changing experience for me, and it prepared me for three weeks spent being deaf, dumb, and illiterate in Japan. It is humbling to not be able to read signs or even ask simple questions. But I never really felt handicapped. Japan can be easily navigated, enjoyed, and savoured, without speaking Japanese.

And it should be. While the U.S. has a culture of individualism that (I would like to think) promotes innovation, Japan has a culture of group harmony that promotes efficient production. As peoples we are stronger together than we are separately, because our strengths are complementary. Both cultures have much to learn from one another.

Plus, they have lots of really cool stuff.

Yokohama

2007-08-22T16:09:00.000-06:00

A note from Housekeeping: Mrs. Overclock (a.k.a. Dr. Overclock, Medicine Woman) and I will be leaving shortly for a three week trip to Japan, where internet access (for us, anyway) will be limited. The fannish among you will correctly guess that we will be attending Nippon 2007, the 65th World Science Fiction Convention, held this year in Yokohama. We will also be spending time in Tokyo, Hiroshima, Kyoto and Osaka. Perhaps we will see you there!

Just In Time Learning

2007-08-22T14:35:00.000-06:00

It has been said that there are only seven basic plots from which all stories derive. Textbooks define seven simple machines on which all mechanical devices depend. These numbers are in dispute, of course, just as the number of fundamental particles has grown from the neutron, electron, and proton that you may have been taught in grade school. When I sat around the campfire with the tribe as a child, it was pretty much just Earth, Air, Fire and Water.

You may be surprised to find that in 1936 mathematician Alan Turing proved that all computing devices can be defined in terms of a few simple operations which he defined to be a Universal Turing Machine. For sure, the UTM is an abstract concept; programming in assembler (any assembler) would be a tremendous step up. But the basic idea is that all computing is at its heart built on a foundation of just a few very simple operations, which are combined macro-like to define more complex operations, which are in turn combined to define yet more complex operations, pretty much ad infinitum. It's macros all the way up until you finally arrive at languages like Ruby, Prolog, and Haskell.

Barry Karafin, computer scientist, professor, one-time CEO, and former head of Bell Laboratories, once said: "The half-life of any high technology is around five years". That's not true for all technologies, of course. As much as we hate to admit it, FORTRAN and COBOL have actually done pretty well for themselves and are still in use today. C has done remarkably better, serving as a portable assembler language in most of its applications. The jury is still out on C++ and Java, although I have more faith in the latter than in the former. It's not clear when or even if the Internet Protocol will be ever be replaced, but probably not in my lifetime.

While it may be fun to learn the latest hot new language (or framework, or any other technology), and hence feel hip for at least a brief while, to me that hot new language just doesn't really feel all that new. It seems more like one of those movies that try to recapture the feeling of a television show from thirty or so years ago, and frequently doing a terrible job of it. Even if a new technology is successful, you usually get the feeling that it won't be successful for all that long before it's replaced by the next big thing. The success of C, Java, and TCP/IP is that they've stuck around long enough to make becoming an expert in them worth your time.

I don't know how many basic algorithms or design patterns there are, but it's a lot more than seven. But I'm pretty sure it's not infinite either. And I know that those algorithms and patterns aren't language-specific. Sure, a pattern might be easier to implement in one language than in another, speaking as someone that has done object-oriented design by implementing the C++ virtual table in assembler. But as long as your language is Turing-equivalent, I'm positive you can implement any algorithm or design pattern in it.

That's why I find it a lot more satisfying to learn algorithms, design patterns, and basic techniques, than I do to learn a new programming language. And that's why for many high technologies, I practice Just In Time Learning. I deliberately delay in learning most new technologies until it becomes apparent that I'm actually going to need to know it. Then I ramp up quickly.

For sure, there are lots of things I've learn just for the sheer joy of it. Digital Aggregates has an Asterisk server because I got interested in the idea of an open source PBX. I have a Nokia N800 on my desk because I'm intrigued with the idea of an wireless internet appliance. I installed the CVM on it because I'm interested in using embedded Java in such devices. But I'm very careful where I spend my time in learning new things. This is partly because I am old and don't have much time left (see One Hundred Books), and partly because the value equation inside my head tells me it's just not worth the time I do have when compared to other things I could be spending my time learning. I prefer to learn high-leverage stuff.

Does this mean that I am arguing against the life-long learning that most career advisers say is absolutely necessary? Just the opposite. To practice JITL, you have to be really good at coming up to speed quickly. To do that, you must learn how to learn. And the only way to do that is by practicing learning new things. But you have to be picky about where you spend your time, because even though you are probably a lot younger than me, it is likely that your time is limited as well. (Whether the time of your children is similarly limited is a discussion we'll leave to the Singularity folks.)

Does it mean that I refuse to learn niche technologies that I need to do my current project? No, indeed. But it does mean that learning those niche technologies is made easier by that fact that I can see in them patterns and techniques in common with stuff I already know.

Fortunately, my career has been one big rummage sale of projects whose learning requirements were all over the map, ranging from writing cryptic assembler code for resource constrained digital signal processing chips to writing Java code for business process automation. Yet the same design patterns keep showing up, time and time again, regardless of the project or the language in which we implemented it. And in those rare moments in which I thought to myself "Hey... I've never see this technique before!", I had the wonderful feeling that I was adding yet another useful tool to my toolbox.

The older I get, the more interested I become in some of the really hard problems, like process issues (people are always more challenging to deal with than technology), or in the big picture areas like finance and economics. Some of the perhaps more esoteric stuff on my list to learn include rate monotonic analysis, game theory, and queueing theory. These aren't technologies, but techniques that can be applied to many areas, and for the distant foreseeable future. Many companies require their employees to take so many days of training per year, then offer the most introductory of classes in technologies that are likely to have disappeared in just a couple of years. Unless they are teaching a technology that is going to be imminently used by the employee, their training dollars would be better spent in teaching more fundamental skills and more broadly applicable tools.

I'd better get a move on. Time is short.