Mike Schaeffer's Blog

For some reason, I've been thinking a lot lately about Seymour Cray. When I was growing up, I remember asking my dad about who made the fastest computers in the world, and the answer at the time was Cray. I don't know if he meant the man or the company, but for a while both were true. I suppose it made an impression.

I've found a bunch of good things online about the man and his work:

• http://research.microsoft.com/users/gbell/craytalk/
• http://en.wikipedia.org/wiki/Seymour_Cray
• http://www.cwheroes.org/oralhistoryarchive/seymour_cray/index.asp
• http://www.spikynorman.dsl.pipex.com/CrayWWWStuff/

Reading through them, a couple of things made impressions on me:

• He didn't mind throwing bad ideas away (or saving them for later). The Cray 1 took a very different approach from the CDC 8600.
• Cray failed a lot. He was always pushing the limits and taking risks, and paid the price of those risks. The CDC 8600 failed, as did several designs for the Cray 2. The Cray 3 failed to sell, and the 4 doesn't seem to have hit the prototype stage at all. Even the Cray 2 doesn't seem to have been an unqualified success, thanks to issues with memory bandwidth.
• He had a very 'startup mentality'. His career seems to be a repeating story of initial success, spin off lab, and spin off company.
• A lot of his design problems weren't electronic at all. He seems to have struggled as much (if not more) with packaging and cooling as with anything else.
• He had a keen sense of style. With the possible exception of the Connection Machine CM-1/2, his machines were the most visually striking of the major supercomputers. Maybe it's superficial, but it can't have hurt the sales or publicity.
• He knew what he had accomplished. There's a story about his suprise when Steve Chen developed the X-MP from the Cray 1 and doubled (?) the performance. Of course, the story goes on to describe how Cray ended up appreciating the new design.

Anyway, I have nothing but the utmost respect for the man and his accomplishments. R.I.P, Mr. Cray.

There's been some 'controversy' in the blog world about a petition that's circulating to ask Microsoft to continue supporting "Classic" Visual BASIC in addition to the replacement VB.Net. A month ago, I had a pretty long post dedicated to the topic, but due to technical problems I wasn't able to get it online. Therefore, I'll keep this sweet and to the point.

The core problem VB6 developers are facing is that they sank lots of development money into a closed, one-vendor language. Choosing VB6 basically amounted to a gamble that Microsoft would continue to support and develop the language for the duration of a project's active life. That gamble hasn't paid off for some developers, and companies with sizable investments in VB6 code now need to figure out how to make the most of that investment while still evolving their software.

With standardized languages like C, languages with multiple tool vendors, the risk is significantly lower. If one vendor drops their version of a language, switching to another implementation is going to be a lot easier than porting to an entirely different platform (particularly if you've avoiced or isolated vendor-specific features).

So... what's the moral of this story? Before you base your business on a particular language or tool, make sure you know what happens if that platform ever loses support. Pick something standardized, with multiple viable vendors. Or alternatively pick something open source, where you can take over platform development yourself (if you absolutely need to). Whatever you do, don't pick a one vendor tool and complain when the vendor decides to drop it. Commercial vendors, particularly, have no legal obligation to their customers.

Global variables tend get a bad rap, kind of like goto and pointers. Personally, I think they can be pretty useful if you are careful. Here are the guidelines I use to determine if a global variable is an appropriate solution:

• Will there ever be a need for more than one instance of the variable?
• How much complexity does passing the variable to all its accessors entail?
• Does the variable represent global state? (A heap free list, configuration information, a pool of threads, a global mutex, etc.)
• Can the data be more effectively modeled as a static variable in a function or private member variable in a singleton object? (Both of these are other forms of global storage, but they wrap the variable accesses in accessor functions.)
• Can you support the lifecycle you need for the variable any other way? Global variables exist for the duration of your program's run-time. Local variables exist for the duration of a function. If you don't have heap allocated variables, or if your heap allocator sucks, then a global variable might be the best way to get to storage that lasts longer than any one function invocation.
• Do you need to use environment features that are specific to globals? In MSVC++, this can mean things like specifying the segment in which a global is stored or declaring a variable as thread-local.

If all that leads you to the decision that a global variable is the best choice, you can then take steps to mitigate some of the risks involved. The first thing i'd do is prefix global variable names with a unique qualifier, maybe something like g_. This lowers the risk of namespace collisions as well as clearely denotes what variables are global, when you have to read or alter your code. If you have multiple global variables, I'd also be tempted to wrap them all up in a structure, for some of the same reasons.

The last line of my VB6 post post was this: "Commercial vendors, particularly, have no legal obligation to their customers." To clarify this, companies are legally obligated to their owners, not their customers. Since the owners own the company and have their investment at risk, the company has to act in their interest... even if it's in opposition to their customer's interest.

Since a company has to have customers to survive, most of the time the interests of the owners are in line with the interests of the customers. However, this isn't always the case: Microsoft's VB6/VB.Net decision might be an example. If you believe that the lower costs and better prospects of VB.Net outweigh the lost goodwill of all those VB6 developers, then you can also argue that dumping VB6 was a net profitable thing to do. This is despite the fact that so many customers are paying a price for the decision.

So... if you're a VB6 developer and you're upset about the way you were treated, the best protest you can make is to make Microsoft's decision a bad one. Make it unprofitable. When it comes time to pick a replacement platform, vote with your wallets and send your dollars somewhere else (and hopefully to a platform served by more than one vendor).