Smalltalk Tidbits, Industry Rants

Have a look at Span - it's Smalltalk with curly brace syntax.

The Press Release is here.

Everyone and his brother has commented on this essay by Paul Graham. Most of the commentary has been positive; Eric Sink is one of the few who's had a contrary opinion. I've been looking at the essay, and I have to say that I've got a few problems with his essay myself. Let's have a look at his notion of why you want hackers (as he descibes them, top notch developers):

It's pretty easy to say what kinds of problems are not interesting: those where instead of solving a few big, clear, problems, you have to solve a lot of nasty little ones. One of the worst kinds of projects is writing an interface to a piece of software that's full of bugs. Another is when you have to customize something for an individual client's complex and ill-defined needs. To hackers these kinds of projects are the death of a thousand cuts.

Ok, let me be extremely clear here - he's full of crap on this. What he's saying is that problems that actual users care about are uninteresting. This doesn't really jive with his assertions that startups are a great place for hackers. Why not? The best startups (you know, the ones that succeed) - pay attention to their early clientele. In fact, they often build stuff more or less exactly to the specifications of their early clientele. The minute you stop fulfilling end user needs is the minute you stop making money.

Now, Graham's assertion is that you can "protect" your great hackers by having them build "tools". That sounds nice - until you ask: "Who are these tools for"? Well, they are going to be for some set of users (Internal or external). If your hackers aren't paying attention to the users, then they are going to end up building a bunch of over-architected crap that no one wants or needs. Trust me on that last point - I was at ParcPlace, and got exposed to plenty of "hackers". We had some really brilliant people back when I joined ParcPlace in 1993 - and the ones who Graham would call "hackers" were typically the least useful developers. They would wander off and build things they thought were highly interesting - and that no one else wanted.

I recall one of our hackers touting some great browser extensions he had in 1994. I publically ripped him a new backside - because he had done all the work on the legacy browser, not the new one that was coming out for VW 2.5 (in the then new GUI toolkit). This would be the equivalent of one of our (Cincom's) engineers proudly touting some additions to the GUI builder (current) after Pollock had shipped. Cool? Maybe. Also completely useless.

That's the trouble with Graham's idea of a hacker. He elevates the sort of developer that lives off in the clouds, building their own idea of perfection without regard to what anyone else might need. You know what? I don't need that kind of guy on my team - Graham can keep him. I want the kind of people we have on the Cincom Smalltalk team now - extremely bright, highly motivated developers - who listen and respond to customers. Are they perfect? Heck no, no more than I'm a perfect Product Manager. We know who pays the bills though. I'm not sure Graham gets that part.

Here's exactly where he gets it wrong:

The distinguishing feature of nasty little problems is that you don't learn anything from them. Writing a compiler is interesting because it teaches you what a compiler is. But writing an interface to a buggy piece of software doesn't teach you anything, because the bugs are random. So it's not just fastidiousness that makes good hackers avoid nasty little problems. It's more a question of self-preservation. Working on nasty little problems makes you stupid. Good hackers avoid it for the same reason models avoid cheeseburgers.

Bull. I'd actually say it's almost completely the other way - if you go in and fix the nasty, stupid UI bugs you learn something about what your users (you know, the people who pay your salary) want. You learn the difference between adequate work that people accept and great work that makes people happy. Look at the difference between the VW tools in VW 5i.2 and every release since then, for instance - the "polish" that's been added (mostly by Vassili) has been more important in many respects than the added functionality. Appearance matters - a nice UI differs from a bad one in the same way that a person with a shower differs from the one without - while a shower doesn't make you any smarter, it certainly makes you easier to be around. Save me from developers who don't want anything to do with the user community. I'll happily load down any of my competitors with them.

Infoworld points out the obvious - handhelds are a niche market. The problem is simple - these devices are neither fish nor fowl, and people can already use their cell phones for all the things a handheld promises. Once you've covered address book and email, you've covered most of what people want to do with these devices. There's a similar issue with tablets, IMHO. Now, if the hardware cost of tablets equalizes down to the level of a standard notebook, tablets may become ubiquitous... but it won't be because people are actually looking for a Tablet. It'll be more along the lines of "oh, it does that too? Cool".

Loudthinking points out a possible problem for MS - Longhorn is looking like more of a problem than a solution to some people. The early adopters are already moving - for all the noise about tablets, take a look around at the next trade show you attend - it's likely that you'll see more mac notebooks than you might expect. I've said before that the issue Longhorn will face is not the actual cost of migration - it's the perceived cost of migration. if the meme gets around that "it's not worth the trouble", then MS is going to have a problem on its hands.

Travis notes that VisualWorks on OS X has some problems. We recognize this, and are working on addressing the problems. The stability issues should be fixed in 7.3 - we have a solution in mind, and the VM team is working to implement it. We understand that this has been a great source of frustration for Mac users, and we apologize for the difficulties.

I understand what the feds are trying to do by insisting that net based phone calls be traceable - they are trying to keep up with shifting technology. The fact of the matter is that they are grasping at dust. It's not as if VOIP is my only option for net communication. I can use various IM systems, I can use IRC. I can create my own chat system easily enough as well; there was an Opentalk demo of a peer to peer chat system 4 years ago, slapped together in a few hours by one of our tech sales people. It's simply too easy to establish a communications channel on the net. The feds are going to have to accept reality, and realize this....

Apparently, it's not just Linux and software that have problems with patent law. medical research is hitting patent walls as well:

More and more diseases are being linked to genes, but making tests for the afflictions runs the risk of violating a gene patent. Researchers currently count on good will, but new laws may be needed.

Interesting

Some of the people commenting on this post (in email as well as actual comments) were skeptical - "who are they going to sue", was the common refrain. What they forget is that perception is reality in these cases. Witness Munich's backing off of linux, for instance. Now, for all I know they've run into user pushback and are using this as an excuse. This is what they are saying though:

As previously mentioned, there is a rising concern that software patents could stifle development of open source worldwide. FFII has complete coverage of what is going on in Europe." (FFII stands for Foundation for a Free Information Infrastructure.) Reader jmt(tm) writes "The call for bids was supposed to be published in late July, but the Munich Green Party had pointed out about 50 possible patent conflicts which the city wants to evaluate before moving on."

The actual threat is far less relevant than the perceived threat in cases like this...

Apparently, Schwartz's last missive fueled a bunch of speculation that Sun might acquire Novell (talk about the walking dead buying the shambling dead is always interesting, I guess). In any event, it managed to move Novell's share price - see the Business Week article. Dare Obsanjo also noticed the post, and had this to say about Sun (amongst other things - read his whole post):

It is definitely amusing to see Sun scramble to stay relevant as they realize that their hard ware is overpriced and they can't figure out how to make money from Java's popularity. If not for the billions they have stashed this would definitely be a company in its death throes.

I have another thought - Schwartz wasn't that widely criticized for this post (which some might interpret as a passably successful attempt at stock manipulation). What would the press and blogosphere reaction be if Ballmer or Gates made similar comments, I wonder?

Not only is MS entering the blog server space, they are starting in Japan - I guess that means that they'll get the i18n stuff down early. Spotted in Phil Ringnalda's blog

Over the last few releases, we have shipped a separate, localized to Japan version of VW - no extra charge to customers, but fully localized. The 7.2.1 version will be ready in about 2 weeks or so. Things will change with 7.3 - we will have all the message catalogs for the product shipping - and we spent the 7.1 and 7.2 releases ensuring that strings were replaces with UserMessages. So starting with 7.3 (in the fall), there will be no separate version for Japan. Instead, it will be part of the core product.

The other day, Ralph asked me about the upgrade tool in BottomFeeder. Well, until this evening it had mostly been a component piece of Bf, not easily reusable elsewhere. I think I've fixed that. I just spent some time refactoring the tool and splitting it out of the bf bundle (which makes it entirely possible that the upgrade tool will be used to upgrade itself sometime. Such is Smalltalk :) ). The code is in the public store as PatchFileDelivery.

One thing you'll notice is the existence of PatchManager and PatchManagerUI, which I don't really use. That's an artifact of the way I used to deliver bf updates. The more current classes of interest are UpgradeManager and UpgradeManagerUI. Here's how I use them:

First, I set up an XML Manifest file on the server. I use the XML Configuration Files package in the public store for that:

defs := OrderedCollection new.
list := #('dev\Emote-Support.pcl' 'dev\ExtraEmphases.pcl' 'dev\VRCommonDialogs.pcl' 'dev\Http-Access.pcl' 'dev\PatchFileDelivery.pcl' 'dev\Browsing-Assist.pcl' 'dev\OSTimeZone.pcl' 'dev\XmlRpcClient.pcl' 'dev\XML-Configuration-Files.pcl' 'dev\BottomFeeder.pcl' 'dev\TwoflowerBundle.pcl' 'IRC-BottomFeeder-Plugin.pcl' 'Pongo.pcl' 'Blog-Tools.pcl'  'WinMineGame.pcl').
names := #('Base Component, Icon Support' 'Base Component, Font Support' 'Base Component, Dialog Support' 'Base Component, Http Support' 'Upgrade Tools Support'  'Base Component, Browser Support' 'Base Component, Local Time Support' 'Base Component, XML-RPC Support' 'Base Component, Upgrade System Support' 'Base Component, Main Application' 'Base Component, HTML Browsing Support' 'Plugin, IRC Client' 'Plugin, MSN IM Client' 'Plugin, Blog Posting Tool' 'Plugin, Minesweeper Game' ).
descripts := #('' '' '' 'encoding priority fix' 'Refactored Patch File Code' '' '' '' '' 'remote browsing includes top 5 items' 'encoding changes' 'Fix for settings reading problem' '' 'preview load could fail, fixed' '').
sizes := list collect: [:each | each asFilename fileSize]. 
allows := #(true true true true true true true true true true true true true true true ).
list do: [:each | | version nm timestamp properties index |
	properties := [CodeReader new readInfoFromFileNamed: each] 
				on: OsError, CodeReader fileFormatSignal
				do: [:ex | ex return: Dictionary new].
	version := properties at: #version.
	nm := properties at: #parcel.
	timestamp := properties at: #timestamp.
	index := list indexOf: each.
	comp := ComponentDefinition
		parcelName: nm
		parcelFilename: (each asFilename tail asString)
		version: version
		releaseDate: timestamp
		descriptiveName: (names at: index).
	comp description: (descripts at: index).
	comp fileSize: (sizes at: index).
	comp allowDynamicLoad: (allows at: index).
	defs add: comp].
(defs at: 12) isPlugin: true.
(defs at: 13) isPlugin: true.
(defs at: 14) isPlugin: true.
defs last isPlugin: true.

"now save it"
file := Tools.XMLConfigFileSupport.XMLConfigFile filename: 'upgradeBtf.xml'.
file saveObject: defs.
file saveConfiguration.

That saves a configuratioin file to disk - the plugins/main components thing is Bf specific, but it's not really essential to the package. To open the UI and check for upgrades, this is all you need to do:

	loader := Patch.UpgradeManagerUI new.
	loader viewer: self.
	Cursor wait showWhile: [loader doUpgradeCheck].
	loader open

Of course, to specify where the upgrade information lives, you need a settings file that looks like this:

[Settings]
patchSiteUrl='http://localhost/patches/'
patchSiteFilename='patches.xml'
patchDir='patches'
saveDir='app'
upgradeURL='http://localhost/upgrades/'
upgradeFilename='upgrades.xml'
version='1.0'
isOnline=true

By default, the code will look for a file called 'patches.ini'. You can also hand the manager object (the domain underneath the UI) settings in code; there's an API for that. That's pretty much it; Assuming that you have Http access to the remote server, you now have patch file delivery.

Sam Gentile points out one of the issues when dealing with Windows CE and the .NET compact framework:

There are a whole lot of things different about programming for mobile devices with the CF versus the desktop framework.

Of course, if you use Cincom Smalltalk for Windows CE, you merely need to worry about the form factor (i.e., the screen layout) and the transient nature of connectivity - There are no differences between Smalltalk for any other platform and Smalltalk for CE. Binary portability means binary portability....

In support situations, one thing that tech support likes to get is a reproducible error - it's hard to diagnose a problem that can only be vaguely defined. It can get even harder if the problem only crops up under a set of circumstances that are fairly unique to a specific installation. Enter the Smaltalk image - here's a message I got from a customer:

Yesterday, we were having a subtle CORBA issue.

The problem occurred when processing CORBA events from a device in our lab ( an Alcatel 5620 Network Management device in case you are interested).

The developers were able to step through the code in our lab environment with all the devices we typically connect to in play, and at the point of failure, save the image.

They then sent the image to CINCOM for further analysis.

At CINCOM, they brought up the image, and continued the investigation (from precisely the point of failure), identified the problem, and between the two of us, a fix was determined.

The fix was then applied to our dev environment, and we were back in business.

Less than 24 hours start-to-finish.

I contrast this with Java, where we have previously spent many weeks trying to come up with a 'reproduction scenario' that the Java vendor could then use to debug the problem outside our labs!

When in doubt, send the image - that way, the support guys can see the actual problem in the actual running environment. That's one of the values of having an image.

For the last few years, we've spent a few weeks each summer paving something - a patio, walkways, or - last year - digging up the patio to lay pipe. We bought more brick this summer, in order to lay down even more walkways (soon I won't have any grass to cut - just weeds to burn between bricks). However, the bricking project was placed on hold the wife decided that we needed to paint the kitchen. Billions of little paint chips later, we had two colors picked out. No simple monochrome job for my wife - two tone with a wallpaper border.

The taping alone took a day (have you ever looked at your kitchen and considered the pre-paint taping job? Makes me wish I had forked over the money for a paint job by the builder). Now it's mostly done - the border still has to go up, but the painting itself is all done. Then there's the cleanup, and bringing back in all the stuff we moved out. Paving stones might actually be less work...

Ryan Lowe played a round of Extreme Golf last weekend. Can't say that I've had to look in a tree for a club before :)

Here's the real risk that Linux faces - patent law. Companies like IBM, Sun, and Microsoft have been filing software patents pretty aggressively for years - it's not inconceivable to consider the possibility of MS deciding to make a patent claim (of course, who they would make such a claim against is an interesting problem all by itself). Take a look at this:

'Linux potentially infringes 283 patents, including 27 held by Microsoft but none that have been validated by court judgments, according to a group that sells insurance to protect those using or selling Linux against intellectual-property litigation.' Dan Ravicher, founder and executive director of the Public Patent Foundation, conducted the analysis for Open Source Risk Management. OSRM is like an insurance company, selling legal protection against Linux copyright-infringement claims. It plans to expand the program to patent protections."

Patent use as a business weapon is nothing new - I wouldn't be surprised to see this sort of thing at all.

Aaron Brady is impressed by Squeak Smalltalk, but asks: "Apart from legacy, why do people still use Smalltalk"? Well, that clearly gets into advocacy - have a look at dynamic updating updating in BottomFeeder - end users can load updates without having to restart. I do the same thing for this blog server. Dynamic typing makes the language much easier to develop in (similar to Python in this regard). The Smalltalk image is implemented in itself, which makes it much, much easier to develop tools in Smalltalk - developers commonly extend their own environments. Why use Smalltalk? Probably the best answers can be gleaned by reading the blogs here and see what the community itself has to say.

Jonathan Schwartz is a wonder. Here he is, one of the head honchos at "Red Ink 'r Us", and he's telling us that IBM is in trouble. Hmm. From IBM's latest earnings report:

ARMONK, N.Y., July 15, 2004 . . . IBM today announced second-quarter 2004 diluted earnings per common share of $1.16 from continuing operations compared with diluted earnings of $.98 per share in the same period of 2003, an increase of 18 percent. Second-quarter income from continuing operations was $2.0 billion compared with $1.7 billion a year ago, an increase of 15 percent. Revenues from continuing operations for the second quarter were $23.2 billion, up 7 percent compared with the second quarter of 2003 revenues of $21.6 billion.

And Sun's latest report?

Sun Microsystems this week reported a profit of $US795 million or $US0.24 per share in the fourth quarter, compared with a loss of $US1.039 billion or $US0.32 per share in the same quarter of last year. Total revenue for the quarter, which ended June 30, was $US3.11 billion, up 4.3 percent from the year-earlier quarter, Sun said in a statement. Sun's profits were buoyed by the nearly $US2 billion it received as part of its legal settlement with Microsoft earlier in the quarter. Discounting the Microsoft money, Sun reported a net loss of $169 million or $0.05 per share.

That's right - had MS decided not to create another charity case, Sun would have had yet another consecutive red quarter. With that as a premise, let's see what brilliance Schwartz is brimming with today:

A few years back, IBM and HP both hopped onto the social movement called linux. It's a wonderful movement. But the bad news for IBM is that the vast majority of enterprise datacenter deployments are now occurring on Red Hat's linux. 100 to 1, depending up on where you look. And with Red Hat increasing price, while adding in an application server that competes with WebSphere, IBM's finding itself in the uncomfortable position of having lost control of the social movement they were hoping to monetize. They're beginning to look like the IBM of Mr. Akers's era - having missed the forest for a tree, and finding themselves without an operating system.

IBM has been among the most aggressive (and ironic) in positioning itself against the world of "proprietary" technology - in stark contrast to its history as the world's most pernicious patent litigator. It's against that backdrop that IBM brags about its "thousands of programmers working on linux." But ISV's can't build their business on a social movement - they have to pick a base software distribution and web service stack. And with most enterprises having picked Red Hat on IBM's recommendation, IBM now clumsily realizes it's invited the fox into the hen house. With Red Hat running on the majority of IBM's proprietary hardware, Red Hat can now direct those customers to HP and Dell. Even Sun.

It's amazing to me that he gets paid for this level of obtuseness. Sun pretty much created the shovel operation that plows money to IBM - Java. IBM has nearly half the application server market (to Sun's just about nil) - and Schwartz wants us to believe that IBM is in deep trouble, while Sun is all set to cruise forward on the commodity rails they've set up. Dream on. Here's the gist of the delusion that Schwartz has set himself:

IBM is in a real pickle. Red Hat's dominance leaves IBM almost entirely dependent upon SuSe/Novell. Whoever owns Novell controls the OS on which IBM's future depends. Now that's an interesting thought, isn't it?

Yeah, right. Last time I looked, IBM was happy to sell you Websphere (for huge gobs of cash) on just about any platform you wanted it on. Sun is the company that desperately needs you to have a Sparc box running Solaris; IBM just doesn't care. We (the Cincom Smalltalk team) are in the same position (so far as concern, that is) - VisualWorks runs everywhere, we don't care what hardware you buy. Ditto IBM (on a much larger scale, obviously). Ironically, what's the main reason that IBM can not care about the hardware - Java. Who created the commodity space that shovels money at IBM and away from Sun? Oh, that would be... Sun.

Keep whistling past that graveyad Jonathan. At least you're entertaining the rest of us while you do it.

LtU links to a PDF of Alan Kay from the History of programming Languages. Good stuff.

I've talked quite a bit about Dynamic Updating (one of the niftier features of BottomFeeder). Bf implements updates on a package (parcel) basis - you can download updates I make available on the server, and they ca be loaded on the fly (or at startup). I've been asked a few times about making the package that does this available; it's always been available - the package PatchFileDelivery is in the public store. However, it's been fairly tightly tied to BottomFeeder. I've refactored the package this morning - it should be possible to make use of it outside Bf now - you'll need the latest version, which should have its pre-reqs properly set.

I went to see The Village last night with the wife. It was an entertaining couple of hours in a popcorn movie sort of way. I can't really talk too much about it without revealing the gist of the movie. I will say that I thought that "The Sixth Sense" was done a lot better though. Not a bad film - just don't try to over-think the implications at the end. Have popcorn and enjoy the escapism :)

You may have some periodic issues getting to the blogs (and other Cincom sites as well) today - we are having another round of ISP trouble. They tell me that it will be an on again, off again problem until they get it resolved.

ESPN reports on the ongoing steroids/doping scandals in baseball:

SAN FRANCISCO -- A former San Francisco Giants outfielder and three others told a federal investigator they obtained performance-enhancing drugs from two men charged in a doping scandal involving a San Francisco Bay area laboratory, a newspaper reported Saturday.

Armando Rios, now in the minor leagues, told the agent he purchased a human growth hormone and testosterone from Greg Anderson, trainer for Giants slugger Barry Bonds

It's well past time for the players and owners to stop treating this problem as a negotiating issue and start treating it as the scandal it is. How many of the records (especially in the home run area) broken in the last decade are going to end up with large asterisks next to them? How many people have to wonder about the odd improvement of Bonds' homerun output as he approaches 40? It's time for Selig and Fehr to get serious about this.

Scoble talks about LongHorn - this part made me sit up and take notice:

For another, it's the largest software project I've ever heard of. Thousands of people working on it. Tens of millions of lines of code. Heck, it takes a bank of computers several hours to compile it (and the code size will probably grow quite a bit between now and release).

Any project of that scale is problematic to my mind. For one thing, if it takes that long to compile agility is right out the window. For another, anything that big has too many people involved in it - realistic collaboration is simply impossible. Makes me wonder just how much completely unknown duplication is taking place, for instance. I'm sure LongHorn will ship (in one form or another). I'm also sure that the end results won't be entirely predictable.

ComputerWorld has an interesting piece on one of the aspects of outsourcing that doesn't get talked up enough - communication:

"Business owners still aren't happy with the fact that application design meetings need to be held at 7 a.m," he said, jabbing his chopsticks into the pickled ginger. "Projects are taking three and four times longer because overseas workers don't understand our business the same way my old employees did. It's not that one group of developers is smarter than the other; it's that my old group had more experience on the existing applications than the new one does. In a couple more years, it will probably be OK, but for now, it's a disaster."

Forget the cultural issues (which themselves are non-trivial) - just look at the communications issues in the simplest way - there's a 12 hour timezone problem. You can't have business calls during normal business hours for everyone. That's going to have a productivity impact. Heck, I see this even in a non-outsourced relationship. We have staff and partners in Australia, which is 14 hours off-cut from the east coast of the US. That makes real time communication difficult, unless someone is willing to work during non-business hours. It often means that any communications are going to be delayed by a full day - which makes misunderstandings difficult to fix.

In most of the talk about offshoring, I only see cost as a factor in the decision. Communication ought to be front and center.

It's nice to be placed in the same category with Paul Graham, but I think I'm being a little misunderstood. Here's what I mean:

There are some software development pundits from the world of obscure languages who have lots of really smart stuff to say, like Paul Graham and James Robertson, whose hatred of popular languages just has to be glossed over if you expect to be able to read them. I think that they're so offended that their language of choice (Lisp, Smalltalk, or whatever) never hit the big time that they just can't see other, more popular languages all that rationally. I know they'd tell me that they hate Java or C# or whatever because they handcuff your productivity when compared to the obscure language that they favor, and they may even be right.

It's not a matter of hating C# or Java - I recognize them as rather large scale improvements over C++, the programming language from hell. What I'd like to see is less auto-decision making going on. Instead of "well of course we'll use Java", I'd like to see people actually think. I've seen people using EJB and three tier set ups for problems that could best be solved by Access, for instance. What I mostly object to the sheer volume of hammer/nail thinking in the IT industry.

Longhorn is going to be later - I guess that gives developers more time to be confused between WinForms and Avalon :)

Jonathan Schwartz likes commoditization, so this report must be music to his ears:

Aeronautics giant Lockheed Martin plans a 10,000 seat migration away from Solaris over to Linux and Intel, a confidential source told us yesterday. There's no word yet on how much the new Linux deal could be worth or who the lucky vendor might be, although our source did throw out the name Dell once.

Maybe he's got some great railroad track line to cover this situation :)

In a post about databases, Roy Osherove slips in this funny bit:

"Question:  If the DBMS knew you were approaching the end of your rope, why didn't it say something?  My working hypothesis is that it's kind of like when your wife wants you to take out the trash, but all she says is, "The trash can is almost full."  Not, "Honey, will you please take out the trash?"  Her objective is not to get you to take out the trash; rather, it is to improve you, the husband, morally and spiritually -- while at the same time getting you to take out the trash.  You're supposed to infer, based on the facts she's provided, that you need to do it.  I say, this is more like training than housekeeping.  My wife insists that she must therefore be a very poor trainer.  But trust me, she's keeping score."

Heh. Very true, that...

This looks like good news:

Jim Hugunin, the creator of Jython, starts work with Microsoft Monday chartered to work towards a production-ready IronPython, and more broadly to improve the state-of-the-art of dynamic languages on the CLR.

That means that Microsoft is genuinely interested in making things better for dynamic languages. Meanwhile, Sun continues to let the JVM stagnate - because gosh, they did everything that ever needed doing back in the mid 90's. Tip of the hat to Microsoft here

This post got a lot of attention from the curly brace crowd. When I asked "So how do you run a 24x7x365 Java/C# application server?", I got a bunch of responses. They all involved having multiple application servers (load balanced), and updating each in sequence while doing server configuration tricks to ensure that the app server being updated didn't get accessed. So I have a simpler question. Say - like this server - you have one app server you want to update without downtime. Let's say that said update involves shape changes to various objects that may or may not be in memory. So how do you keep that up while updating it? Sure, I get the notion of sequential updates.... but say the server (like most of them out there, to be honest) isn't a suite of load balanced systems. What then?

Sean McGrath makes a comment on the wisdom of using static languages in middleware:

My position on this is simple. Anyone coding middleware in a statically compiled language, working in a commercial environment where time is money, has rocks in their head.

Clearly, I agree with that. How do Java folks update their servers without taking them down and up? How do C# developers? In Smalltalk, I do this all the time, and as a result, my servers tend to run 24x7x365. Yes, I test things out locally before I upload them :)