Smalltalk Tidbits, Industry Rants

I got an interesting piece of news from a customer today - see this article on Bank of America and Image Cash Letters? The very first exchange of Image Cash Letters between that bank and a customer used a Cincom Smalltalk based system from DeepCove Labs. Here's what they say about Smalltalk:

DeepCoveLabs, is in the business of developing payment processing solutions. We currently offer products for cheque conversion, multi currency credit card processing, international electronic funds transfers into about 30 countries, cheque printing in many currencies and languages, a currency exchange module and a CRM system for managing a payment processing operation.... all written in Smalltalk by a couple of developers at a time. Why Smalltalk, this is not an item of debate for us, everyone involved feels they personally can more done faster using Smalltalk than with any other tool set.

Zefhemel has the right idea about language features and productivity. Noting how many extra (and complicated) language features C# had to add in order to do LINQ, he asks:

So, here’s my question. How far are we willing to drag on the huge beast that is a static language? If you look at a language like Ruby or Python, they already got most of the features that C# had to add to make this happen, but in Ruby and Python they’re not half as complicated. In Ruby you could already add methods to existing classes, anonymous methods (in Ruby known as blocks) are something a Ruby programmer breathes, anonymous types? var keyword? generics? Don’t need those.

If we want to carry on in the direction that LINQ is heading, and I think we should, shouldn’t we sacrifice this one thing: static languages? This makes things a lot simpler in many ways, and the sacrifice may just be worth it.

This was the point I was trying to make here. It's not that LINQ is a bad idea in and of itself; it's that all the cruft MS needed to add for it is. At some point, you would think that people like Hejlberg and Gosling would look at dynamic languages, ponder the complexity they've added to their own creations just to approach the same capabilities... and get a clue.

I'm going to put together a short screencast on using the Web Services wizards in VisualWorks - using the Google API as a way of demonstrating the operations. It's been awhile since I did one, so I'm going to have to remember how to use the tools - look for it later

I've done another screencast, after a long gap - this one goes over how to use the WSDL client wizard in VW 7.3.1. I've got two formats uploaded this time - if you want to see this in Flash, then go here. If you want the streaming wmv file, then go here. I didn't upload the original AVI file - that was 1/2 a gig :)

I've got all of the screencasts I've done aggregated here on del.icio.us

Time for a look at the weekly logs - the BottomFeeder downloads are up to nearly 500 a day - although a fair bit of that is likely upgrades to 4.0. Here's the details:

Platform	BottomFeeder Downloads
Windows	987
Mac 8/9	651
HPUX	495
Mac X	433
Sources	381
Linux x86	191
CE ARM	106
Windows98/ME	51
Update	50
Solaris	32
Linux Sparc	26
SGI	24
AIX	22
Linux PPC	6
ADUX	3
CE x86	3
Source Script	2

Now let's take a look at the html accesses to the blog pages:

Tool	Percentage of Accesses
Mozilla	43.9%
Internet Explorer	40.5%
Other	7.6%
MSN Bot	5.4%
Google Bot	2.6%

Well, IE usage is up - my traffic rose, so I guess that means that my readership is becoming broader. That's a good thing :) Now, the RSS accesses:

Tool	Percentage of Accesses
Mozilla	24.6%
BottomFeeder	16.5%
Other	11.6%
Net News Wire	10.3%
Planet Smalltalk	4.6%
Safari RSS	4.5%
Feed Demon	3.8%
Magpie	3%
NewsGator	3%
Internet Explorer	2.8%
SharpReader	2.7%
BlogLines	2.5%
Feed Reader	1.9%
BlogSearch	1.8%
RSS Bandit	1.4%
Liferea	1%
JetBrains	1%
Feed Tagger	1%
Google Bot	1%
Jakarta	1%

Looks like the RSS distribution isn't that different - although, the Windows specific readers seem to be a bit up. All in all, another interesting week.

Well, it seems that a persistent spammer has been trying to deface the Postgres pages on the UIUC Wiki all day. Sadly for that dork, I have a script - I just select the Smalltalk code in a workspace, and repair all of his damage. No fuss, no muss :)

The storm track for Rita is strange looking - there's a blocking high pressure system that's going to stop the storm in it's tracks in northern Louisiana or Mississippi. It's going to get very, very wet down there...

I should have known better. I spent many, many, many (did I say many?) hours playing the original "Civilization" PC game, and I just grabbed Civ 3. It's every bit as addictive as the original.

Update: I think today's all day session confirms my addiction :)

I see that the music industry moguls don't like what they see in the commoditization of their business - Bronfman of Warner Music is up in arms over Apple's 99c pricing on iTunes:

At an investors’ conference in New York, Warner Music Group CEO Edgar Bronfman Jr. said the price of downloaded songs should vary depending on the popularity of the songs and the artists. He called Apple’s across-the-board $0.99-per-song charge unfair.

“There’s no content that I know of that does not have variable pricing,” said Mr. Bronfman at the Goldman Sachs Communacopia investor conference. “Not all songs are created equal—not all time periods are created equal. We want, and will insist upon having, variable pricing.”

Sure there is - commodities. You just got disintermediated. It's time to realize that consumers like being able to pick and choose by song instead of by album.

Here's a post discussing scalability, threads, process models, etc. I was drawn to it by these two statements - I'm trying to figure out how the author manages to hold both of these thoughts in his head at the same time:

Performance gains are going to be extracted through threads, NOT processes.

Well. So much for that unscalable model used by Apache then. By assertion, it doesn't work :)

Tim says that "Debugging it is a complete mindf**k, and I’m spending too much time debugging it because I have no idea how to write the unit tests." I have done some debugging for MT applications, and believe me it is no fun. You get nightmares, insomnia, loss of weight, and ultimately loss of concentration.

Yeah, something that brings about that second thing most certainly will bring me to scalability nirvana.

Instapundit points to some models that show a nasty possibility - Rita returning to the gulf. Sounds insane, unless you remember Ivan's wild ride last year.

PVRBlog spotted a funny thing about DRM and the TiVO last week - an episode of "King of the Hill" got flagged as something protected, and the people at Tivo said that the flag was caused by line noise. The technical response to that?

When I asked them if they believed that noise could be "misinterpreted" as a DRM flag, they burst into positive howls of disbelief. One present talked about Macrovision's checksums and said that that must have been "incredible noise if it completed the checksum." A semiconductor expert laughed out loud. Charitably, an operating system vendor's rep suggested that TiVo might not be lying: rather, he said that perhaps they've just done an "incredibly bad" implementation of Macrovision.

Most likely, it was an error on the part of some tech setting broadcasts up. What it points out though is this - fair use rights to programming are being eroded as we sit here.

Looks like the Department of Homeland Security screwed up their site somehow. In case it's back to working by the time you see this, have a look at the saved screenshot here.

I don't feel nearly so bad about my occasional mistakes now :)

Blaine Buxton gives a great example of why "private" methods can be a problem:

I look through the class and find a methood called gatherFiles(File,String,result). It takes a file and determines if it is a test class. Well, a simple check to see if the file is a jar, add the class names of the entries which are tests to the result, and we were in business, right? Well, that's what I thought! So, I overrode gatherFiles, added super to let it do its job, and then, added my jar functionality. Simple right?! It didn't compile. It seems gatherFiles is a private method and I didn't have any visibility for the super. OK, I then just copied the original gatherFiles in place of the super and a little gentle refactoring. Everything compiled, but it worked like the old one. It then struck me. You can't override private methods. GRRRRRR! So, I wound up copying the remaining methods that I needed and removed ClassPathTestCollector as my superclass. It shocked me to know what should have been a simple refactoring, turned into a lot more, and it forced me to commit the worst of all sins: Duplicate code.

The problem with "features" like private and final are that they assume perfect knowledge of all possible future uses of code by the original author. That's simply impossible, and Blaine's found a great example of it.

Scoble is still looking at search, and asks us to try this search for the Toshiba Gigabeat. Yes, there are a lot of third party sites, but I did spot the Gigabeat site - 4th down on the list. The general issue of relevant search results varies a lot - and the subject matters too. For instance, have a look at the results for this one. See the first two results? That's "Google bombing" at work there.

In the blogosphere, we get a lot of inadvertent Google bombing, simply by the normal kind of meme spreading that takes place. That's a side effect of having more people discussing more subjects - it makes relevancy that much harder to rank (as in - who gets to decide what's relevant?).

This makes the job of web marketers harder, because the message you are trying to put our can easily get buried by the noise generated by a semi-smart mob interested in the same topic. This is why I keep saying that you have to pay attention to blogs and search results - if you don't, someone else certainly will.

For a company that prides itself on ease of use, there are a few cases where Apple really drops the ball. Witness "Finder", for instance. I just plopped a VW install CD in the cd drive on the Mini, opened Finder.... and couldn't spot the installation files. I opened a terminal window and found them (good luck running it from there though) - so what the heck was up?

Well, I had someone tell me to resize the Window. I hadn't even noticed that the horizontal scrollbar was active. Sheesh - there were all of 11 files in the folder - it couldn't arrange them all to fit?

Scoble points to some fascinating research results on web search - the bottomline is, if you don't show up on the first page of results for a search that should find you, you don't exist. If you aren't at the top of the list, it's nearly as bad:

Professor Thorsten Joachims and colleagues at Cornell University conducted a study of search engines. Among other things, their study examined the links users followed on the SERP (search engine results page). They found that 42% of users clicked the top search hit, and 8% of users clicked the second hit. So far, no news. Many previous studies, including my own, have shown that the top few entries in search listings get the preponderance of clicks and that the number one hit gets vastly more clicks than anything else.

There's more - they tried some hidden manipulation of results to see what happened:

What is interesting is the researchers’ second test, wherein they secretly fed the search results through a script before displaying them to users. This script swapped the order of the top two search hits. In other words, what was originally the number two entry in the search engine's prioritization ended up on top, and the top entry was relegated to second place.

In this swapped condition, users still clicked on the top entry 34% of the time and on the second hit 12% of the time.

Meaning, an awful lot of people (a solid plurality) hit the first link without really examining it. Think about what the means in the context of my earlier post on google bombing. Now, bear in mind what this means if people haven't heard of your company, but are interested in a product or service you provide: it means that you are completely invisible unless you get yourself to the top of the list (or at least the first page) for relevant search terms.

My daughter Victoria is a girl scout, and has been selling cookies for many years now - today she charged out as soon as school was over, in order to beat the rush from the elementray kids, who get out an hour later. When they did get home, it was kind of amusing watching the lot of them run from house to house, trying to score sales first.

We stayed at it for about 90 minutes, finally getting driven in by rain - the mild remnants of Rita mixed with a cold front. What that means is - I'll be back on the streets with her tomorrow :)

I swear, the networks seem to have the same batch of ideas all at once. Ponder these two series: "Invasion" and "Surface". While you're at it, make the mistake of watching "The Abyss" and "Close Encounters of the Third Kind" in the same week. Then try - just try - to keep any of the details straight.

So far, I've seen lights from the sky drop into the water, lights from the water fly up towards the sky, people get taken over like "Body Snatchers" (or Goa'uld from SG-1), and compulsion to travel to the "main site". Gah! It's too many plot derivatives!

Here's an interesting by-product of the last O'Reilly Foo Camp - a "meme map" for web 2.0. The interesting aspect to me is this - it's the product of lots of unplanned, organic growth - the end result of lots of people working independently. In some respects, the explosive growth of web personalization (blogs, Flickr, del.icio.us) is akin to the explosive growth of inventions in the late 19th and early 20th centuries - it's amazing how many people are converging toward the same set of loosely coupled ideas.

This is exactly the kind of growth that large firms aren't terribly good at. It's not that they don't have smart people, it's that the bureaucratic impulse tends to stifle independent thinking.

Blog Relations recently took a survey of 50 PR professionals on blogs - what do they know about blogs, are they a force for good/bad (or neither), etc. The results can be found here. Most of the respondents live and/or work in the US or UK, so keep that in mind - YMMV in other places (Asia comes to mind). The most interesting take away for me was the answer to this question:

Do Blogs pose a threat to corporate reputations? (May tick more than one answer)

44% affirmed that one. My guess is that the "" business was still fresh in the minds of this crowd when they took the survey. The other answer that popped from that area was this one:

It is much harder to spot a crisis coming from a blog than from the traditional media

42% responded yes to that one, and 64% agreed with this:

A disgruntled employee or a dissatisfied customer could use a blog to ignite a full-blown crisis

It's not all negative though - most of these folks agreed that businesses can benefit from setting up blogs - and thus becoming part of the conversation. That really goes back to something I say a lot: Define your message, or someone else will define it for you. That's what these PR folks said in these answers.

Go have a look at the whole thing - it's interesting reading.

Update: As per the comment below, I updated the post to reflect the correction.

Smart Office News has a WSJ report about the real reasons for Longhorn's delay - it was fundamentally broken. I think I said something along those lines - here, for instance. Here's the punchline:

Allchin is co-head of the Platform Products and Services Division. "It's not going to work," he told Gates in the chairman's office mid-2004, the paper reports. "[Longhorn] is so complex its writers will never be able to make it run properly. "The reason: Microsoft engineers were building it just as they had always built software. Thousands of programmers each produced their own piece of computer code, to be stitched together into one sprawling program.But Longhorn/Vista was too complex: Microsoft needed to begin again, Allchin told Gates.Allchin's warning recognised a growing threat from Google, Apple Computer, makers of Linux and corporate buyers - the latter horrified about security problems. Allchin and a small team demanded a revolution in how Microsoft works.

It was only a matter of time before the "tightly couple everything to everything else" theory collapsed, and it sounds like it collapsed ugly. The thing is, the management shakeup - the one that ousted Allchin and put Ballmer's cronies in charge - is probably the last thing they need. If I read this article right, it sounds like Allchin played Cassandra, and got the same kind of treatment she got. The sales guys are in charge now, and architecture is the last thing they care about.

I predict rough sailing ahead for MS.

James Governor points to Jaime Cardoso, who's taking Gartner to task for some, shall we say, questionable predictions. I especially like this prediction from them:

"Linux and Windows will be the only two operating systems left in five years."

The problem with that statement isn't just Unix - it's the current problems MS is having (see my last post), combined with Apple's move to intel. I don't foresee Apple becoming a huge player here, but they could easily pull a Firefox - i.e., start whittling their way up to a more significant percentage.

Not every OS vendor is as stupid as Sun - which is what I think the Gartner guys are assuming. Jobs may be a lot of things, but stupid isn't amongst them.

We have a new blogger on the site - Terry Raymond. Terry is the author of the Professional Debug Package, which we integrated into VisualWorks back in VW 7. Terry's been working with Smalltalk for years, and has a lot of expertise around debugging and memory management - BottomFeeder uses a memory policy he created, for instance. Subscribe here!

Update: Make sure to follow Terry's blog for tips on maximizing your use of the debugger.

Scoble sheds some light on the Longhorn restart:

Either way, I'm glad the story is getting out. The short view is that last year we threw out the code that had been written for Longhorn and started over with a fresh code base (they restarted with Windows Server 2003's codebase, by the way). Then they started checking in features one at a time, albeit with higher quality bars. It was a very painful time. I had been sold on how cool Longhorn was going to be too, and last year I couldn't really say much as they rebuilt the entire product.

Well, that's not far enough back, IMHO. Windows started being a mess with NT 4.0, when they decided to move the graphics drivers into the kernel (and ushering in an era of blue screens related to that decision). It went downhill with the full bore integration of everything with everything else. What this decision does, IMHO, is delay the day of reckoning for the "big ball of mud" a couple of years. They'll be right back to their 2004 state, because they haven't actually dealt with the real problem yet.

And believe me, I know a big ball of mud when I see one. One of the things that our team has been working on is untangling the core Smalltalk image for VW into components. It was built as one big ball of mud from the start, and it's not easy to untangle. We know that's a problem, and are addressing it. If untangling VW is more complex than I'd like, imagine what untangling the mass of dependencies in Windows is going to look like.

I would have loved to have attended this talk:

One of the unique features of BYU is that every week on Tuesday, there's a one-hour time slot where no classes are scheduled. Three weeks of the month, there's a devotional. The fourth week is called forum and it's usually some national figure who's been invited to address the BYU faculty and student body. You'd be surprised how well attended devotionals and forums are. We hold them in the Marriott Center and sometimes there's as many as 25,000 people there.

Today's forum address was by David McCullough, the author of 1776 and the biographies of John Adams and harry Truman (among others). The title of his address was "The Spirit of 1776." I estimate the attendance at today's forum to be about 10,000.

Via Phil Windley

Apple seems to have learned from the Dell Hell incident - they have a VP addressing the issue, trying to get out in front of the iPod Nano screen complaints. Looks like Apple's management isn't using the "Duck and Cover" technique that Dell used :)

Via Steve Rubel.

I thought it was September, but my local Giant supermarket seems to be convinced that it's Christmas time already - I snapped the photo below in the back of the store:

Kevin Burton has some thoughts on the ping servers out there - sites like blo.gs and weblogs.com, for instance. These sites take pings from blogs and other frequently updated sites, allowing various other services to notice new stuff as it gets posted. The trouble is simple - what's the viable business model for that? With Technorati, it's pretty clear - they use the ping server to feed their other search services, which they are trying to monetize. I'm not at all sure what the business model for some of these other services are. I rather suspect that they are selling information off the back end to interested parties, because there's no other model that makes sense to me.

Think about it - how many people actually go out of their way to visit these sites directly? Kevin tries to relate this to the IDE business, where he says that everyone wants the service, but no one wants to pay. There's some rough similarity there, but there's also a big difference. Unless I'm missing something, no one in the ping business is purposely offering their wares for free in order to drive the competition out of business (can you say Eclipse Foundation?).

The bottom line on ping sevices, IMHO, is that the only survivors will be those who are monetizing their service indirectly (like Technorati is trying to do). Come to think of it, that may not be that different from the IDE space...

MemoRanda compares block syntax between Smalltalk and Ruby. While I think Smalltalk's is simpler, they are very, very similar.

Rich discovered that I had included the 3.9 revisions of some of the documentation in the build, so I'm in the process of uploading a new build now. Sometime this afternoon, the new stuff will be online. There's no new code here, just an update to the shipped documentation.

Update: The updated builds are up

It's nice that BEA has caught up with something I've been doing to this server for years, and that Smalltalk has been capable of for decades. Note the breathless "first ever" tone:

BEA Systems plans to release a new version of its flagship application server that will allow upgrades on the fly to mission-critical applications, the company said Tuesday. "Upgrades are now on the fly," CEO Alfred Chuang told approximately 2,000 delegates at the company's users' conference in Santa Clara, Calif. "This is the world's first hot-swappable application server in production. Imagine changing the engine of a race car during the race...this is what we are doing.

Hey Alfred - I've been there and done that for years. Congratulations for making it all the way into the mid 80's, technology wise.

RSS and blogging have attracted their own special kind of spammers - Doc Searls was taken in by one yesterday. I'm seeing a lot of this show up in my BottomFeeder search feeds - IceRocket, Feedster, and PubSub in particular seem to be getting gamed quite a bit.

There was some initial hope that RSS would liberate us from email style spam - it looks like we'll be fighting that battle on new turf - with engines, at least. The good news, of course, is that unsubscribing from a feed - search feed or otherwise - that has turned into a spam bucket is far, far easier than dealing with email spam.

After last night's debacle, the Yankees turned it around and beat the Orioles, 2-1. The good news - the loss last night was a no-op, since Boston and Cleveland also lost. The even better news - as I post this, the Red Sox are down 7-2 to Toronto in the 8th, and the Indians lost 6-5 to Tampa Bay. If the Sox stay down, the Yanks go up a game in the East, and have already gained a game (in the wild card situation) on the Indians.

MemoRanda gives a nice example of why unit tests are worthwhile.

Blaine spots Vince Foley making an excellent analogy:

I compared dynamic languages and Java with riding a bike; in dynamic languages, you ride on two wheels and you get where you want pretty quickly. You can fall if the road is slippery, if you hit a rock or something, but with a little experience, these cases rarely occur. On the other hand, riding a Java bike is like having 8 wheels to make sure you don’t fall over, 10 people constantly around you, ready to catch you should you fall. You may be safer, but you’re not getting places faster than the dynamic biker.

This came in the context of the following:

A friend of mine told me tonight that his boss is putting the axe in Java at his workplace. This is explained by the very low productivity of Java. Demands made by users are never delivered on time, and apparently the programmers are not really to blame, they know their stuff pretty well. Java is simply too complex, puts too many sticks in their wheels for them to be really productive.

The mainstream languages are a safety net for most people - using them means that you probably won't fail any worse than anyone else. The flip side of that is that you won't succeed any better, either. If you want to go faster, you have to look beyond the mainstream.

I thought that - after last year - the red Sox wouldn't need extra help. Check this out:

So is Obi-Wan their only hope? Heh.

Periodically, a customer or interested party asks me about the future of Smalltalk - invariably, it's a question along the lines of:

Will I be safe selecting Smalltalk? Will it still be here in 20 years?

The thing that always strikes me is the periods people choose to ask about. 20 years is a long time in the software industry. Cast your mind back to 1985, for instance (listen to this song if you have trouble :) ) In 1985, Windows 1.0 was released (in November). It landed mostly with a thud. In the PC world, most people were using DOS, although a not insignificant amount of CP/M installations were still floating about. The Macintosh had been out for a year, but the Apple IIe was still a popular platform (it's what I was using back then).

The most common programming language in use was probably Cobol, although C (K&R C, ANSI C was a long ways off yet) was gaining ground. It would be years before C really broke through in the PC world though - people working on those systems were mostly writing in assembly language. In 1985, C was mostly used by Unix geeks (and I say geeks because Unix had not, at that point, broken out into widespread use in industry).

Smalltalk had been around for awhile, mostly as an academic R&D creature at Xerox PARC. Digitalk produced Methods (the precursor to ST/V) in 1985, and ParcPlace had not yet commercially released a product - that wouldn't come until 1987. Why am I going through this abbreviated view of 1985? Well, let's stand in 1985 for a minute, and - with what I just sketched - try to look at 2005. Do you have any sense that you would be able to foresee the dominance of Microsoft, the fall (and rise) of IBM - or Google and the internet? Would you have spotted OO as the future of software development, and seen that a pair of C hybrids (Java and C#) would be widely used?

I doubt it. Which takes us to the "what about 20 years from now?" question. The short answer is, no one knows. Java and C# look dominant now - but in 1985, what language/system would you have bet on? By the same token, I'd be very wary of making predictions about the year 2025.

A lot of people are going to ask for long term comfort words anyway. As it happens, I can give you some level of reassurance. I mentioned that Methods had just been released in 1985, and that ParcPlace was working toward a release (which ultimately came out in 1987). The current Cincom Smalltalk VisualWorks environment is a direct descendant of that work - in fact, it's a direct descendant of the Smalltalk work done at PARC in the mid to late 70s. So Smalltalk has been around for 30 years now, and in continuous use over that interval (continuous commercial use for 20 of those years). Does that guarantee anything 20 years hence? Like stock traders, I have to say that past performance is not necessarily indicative of future results - but look at these signposts:

• Cincom is now the corporate home of both VisualWorks and ObjectStudio.
• Cincom has been in business since 1968, with the same President now that we had in 1968.
• Cincom is supporting customers using products that were originally purchased in those first years of business
• Cincom is profitable, and privately held - which means that quarter to quarter issues which buffet public companies don't concern us
• The Smalltalk group within Cincom is profitable, and our revenues are growing
• We are currently selling 3 and 5 year contracts for Cincom Smalltalk - which means that we are constantly pushing the future of the product out (legally speaking) into the future

We have a product roadmap here, but you'll notice that it doesn't delve deeply into the future. There's a reason for that. Five years ago, how critical were web services? Given that, just how useful is it for me to talk about what we'll deliver in 5 years? Some vendors have elaborate 3, 5, and 10 year roadmaps. Those vendors are full of (insert your favorite substance here). They have no idea what their products will look like that far out. Demands shift, and plans have to be changed. The Smalltalk group at Cincom is extremely nimble, and has been excellent at tacking in new directions. Take Web Services, for instance - we have a fully standards compliant implementation, complete with code generating wizards to ease the problem of dealing with the mass of WSDL out there. Five years ago, we had no idea that any of that was going to be necessary - and yet there it is. We tacked - shifting the importance of things like CORBA down in favor of WS*.

Nothing speaks to longevity like success, and we have a lot of good stories to tell there. Take a look at our success story page, where users of our technology sing its praises. Many of these companies have been using the product for years - telling you everything you need to know about the value of the product as compared to newer fads that have been crossing the industry. There are a few stories I'd like to point to in particular, as they show long term interest in the product, and high levels of success and satisfaction:

• Adventa Control Technologies
• JP Morgan
• Key Technology
• MetaCase Consulting

All of those companies have been using Smalltalk for many years - they've stayed with it through various corporate upheavals, including the sale of VisualWorks to Cincom. My point? Smalltalk has been a safe choice over the last 20 years, and the odds are that it will be a safe choice for the next 20. Go ahead and give it a try - download it here.

An interesting question came up on comp.lang.smalltalk - the post I linked to provided the answer. The question?

now that you have mentioned it, is '' in VW imutable?

The answer can be found easily - do a "print-it" on this in a workspace:

'' isImmutable.

The cool thing is, I just brought up a BottomFeeder workspace to try it out.

James Governor has some good points about blogs and wikis vs. traditional content management - he's spotted a win for blogs as a back end vs. Lotus. Now, he's caveating this, and I agree with him:

I should stress again that this is an outlier rather than a full-blown trend. On the other hand, it should become increasingly clear to IBM, Microsoft and other content management, portal and collaboration players, that something is afoot. As RedMonk has argued before, blogs and wikis can in many cases functionally replace large scale content management and messaging platforms.

This is a trend that anyone looking into CMS should follow - look at your actual needs, and see whether a full blown CMS is actually what you want. It might be - or it might not

If this possible JSR gets implemented, it will be very, very good news for dynamic languages - it will make them possible to implement decently on the JVM. This comes via a post from Gilad Bracha:

Last winter we had a meeting with various people who work on such languages - things like Groovy, Perl, Python/Jython. Our conclusion was that the most practicable thing was to support dynamically typed method invocation at the byte code level.

The new byte code, invokedynamic , is coming to a JSR near you very soon. I’m forming an expert group which I will chair (because of my deep fondness for standards, committees, meetings and process). This group will get to argue over various fine details of how this instruction should work.

Basically, it will be a lot like invokevirtual (if you don’t know what that is, either open a JVM spec and find out, or stop reading). The big difference is that the verifier won’t insist that the type of the target of the method invocation (the receiver, in Smalltalk speak) be known to support the method being invoked, or that the types of the arguments be known to match the signature of that method. Instead, these checks will be done dynamically.

There will probably be a mechanism for trapping failures (a bit like messageNotUnderstood in Smalltalk).

Does this do everything everyone wants? No, but that is not the point. It isn’t really feasible to accommodate the exact needs of a wide variety of disparate languages. Instead, one should provide a good general purpose primitive, that all these languages can build on.

If this comes to pass, my longstanding disdain for the JVM as a platform will have to be re-evaluated.

Joi Ito has some useful globalization experiences to share, from the "sharp end of the stick" perspective - in this case, trying to get a unified credit card account:

I first had an American Express card in Hong Kong, then in the US and now in France. When I applied for the new Amex card in the US and in France, I was assured that my membership date would go back to when I first joined.

Each time I got the card, however, (my French card just arrived) they considered me a new member. A longer term of membership can confer benefits.

When I complained to the French Amex yesterday, the customer service person explained that American Express in Hong Kong is not the same as American Express in France. Funny, because that is not what their advertising seems to imply.

Sounds like some of the large companies out there are not integrated across borders yet. I'd warrant that many aren't integrated within borders yet :)

Esquire magazine tried a fascinating experiment - they had a writer post an article (with mistakes, typos, etc) to WikiPedia, and then solicited the audience to fix it. The results:

According to the Wikipedia page for Jacobs' story, the article was edited 224 times in the first 24 hours after Jacobs posted it, and another 149 times in the next 24 hours.

The final draft, which was locked on Sept. 23 to protect it from further edits, reflects the efforts of the many users who worked on it.

Here's the entire history of the effort - it really demonstrates the value of collaborative editing. The interesting thing about Wikipedia is how much it was pooh poohed by people in the beginning - the thinking was, if anyone can edit, everyone will edit - and trolls would end up owning the site. Something else entirely has happened, and it's now an extremely useful resource - I use it when I'm looking up historical references all the time. For instance - I had the History Channel on while I was cleaning my kitchen floor this morning, and heard the tail end of something about the Knights of Malta. Well - Wikipedia filled it in for me.

Scoble tries to explain it all, and misses:

Training companies, for instance, will do the hard work of helping Bryan move his apps to WinFX. It won't be easy. If you watch the Sparkle video you'll see that the entire architecture and development process for building these new apps has changed from the VB 6.0 world. That's why Microsoft hasn't built a porting application yet. Just like there weren't good porting apps from Apple II to Macintosh apps. Or why there weren't good porting apps from DOS to Windows. Or why there aren't good porting apps that'll take you from a Windows app to a Web Services app.

He's making the claim that an application's architecture has to change when moving from VB6 and (insert any version of Windows here) to WinFX? Say what? It's one thing if that "port" means moving from fat client to server based - in that case, yes - the architecture has to change. I had to explain that to people multiple times back in the late 90's, when they wanted to pick up VisualWave and do an insta-port to the web. The basic issue - single user vs. multi-user.

But there are plenty of apps that aren't going to go that way. Not every application needs to support the WS* stack, and plenty of apps are just fine (architecturally speaking) as they exist now.

When someone says "you'll have to buy training and use a new architecture" in order to run your application on a new OS, one of two things is happening: either a non-techie who barely understands "application architecture" is speaking, or you are being sold a pile of crap. Possibly both, I suppose. With Scoble, I suspect it's the former - he's not dishonest.

If you contribute code that lands in the "goodies" directory of our Cincom Smalltalk distribution, we have an announcement that might impact you. We are changing the name of the directory from "goodies" to "contributed". Our experience has been that too many people have been mistaking the name "goodies" for "toys", and never even looking into what's there - and there are plenty of good things in there.

In any case, this may impact the pre-requisite chain for some of the packages in there, so please be aware of the change.

Scoble wants OPML:

Here's the deal. I will switch to the blogging tool that outputs OPML automatically like what Michael Arrington did by hand.

Will it be a Microsoft service? I hope so. Hey, MSN Spaces, you gonna add OPML and categorization, er tagging, support so this will be possible, or will it be Google or Yahoo that does it first?

Michael, this is awesome. I want this for a whole lot of reasons. It looks a darn lot like tagging support, which we added to Channel 9 , but is a whole lot more powerful. Why? It lets me again escape the Web browser. See, to me, Web 2.0 is letting me do things in an edge way. I can't use Channel 9 while on an airplane very well. I could use OPML, though.

Ye gods, it's time someone came out and said something. OPML is a really, really crappy format. Really crappy. I had massive headaches implementing OPML support for import/export in BottomFeeder. Why? Because there's no real specification. Like everything Dave Winer has ever been involved with, the specs are all in his head, and it's up to the rest of us to figure out wtf he actually meant. Here's the "spec" - and look at all the meaningless crap in it (windowRight? Why is there something specifying the number of pixels for the margin?).

I had to add tons of hacks to the OPML support in order to support the export formats of various tools. The problem? Everyone implemented it a little differently, because the spec is incredibly unspecific - about just about everything.

Getting back to Scoble's excitement, I have no idea why he thinks OPML is some magic mojo that let's him escape a browser. It's a format, and a fairly bad one. It doesn't enable or disable anything by itself.

Scoble responds to last night's rant about OPML:

James, here's the deal. I really don't care about specs. I'm a user here. When users say they want something the correct answer isn't to call what they are asking for "crappy" but it is to either say "here's what you're asking for" or it's to say "here's what you're asking for and I made it even better." Or, I guess an OK response would be "I can't do that, sorry."

Well. You don't care about specs as a user. In the abstract, that's correct - you don't. However, you actually do care when it starts hitting you as a user. Consider the field of blog posting tools, all (or nearly all) of which have to deal with the utter atrocity known as MetaWebLog API. As with OPML, it's underspecified, and each implementor has to figure out what Winer thought he meant.

You know what I had to do to get my client and server implementations working? I had to download multiple posting tools, and start hitting my server with them. And working with other people using other tools. And debugging my test server live as requests came in, so that I could see what they actually did, as opposed to what I thought they did based on the sorry excuse for a spec. Based on other posts I've seen, I know that other authors have gone through the same exact problem.

OPML has the same problems associated with it. It's underspecified, and it has way, way too much extraneous crap floating around in it. Which means - as a user - you'll care when you notice that there are subtle interoperability bugs between tools. When those start to crop up, you'll blissfully blame the tool author, having long since forgotten that said tool author is likely pulling his hair out trying to read Winer's mind.

Do I have a better format? No, I don't really do formats, or specs. But I'll say one thing - for all the crap I've given the Atom movement, their spec is easy to implement. Reading their docs, I know what it is - as an implementor - I'm supposed to do. Which is something I've never been able to say about OPML, or MetaWebLog API. Or, to expand the field to other lame specs, Blogger API (where, to be fair, the authors recognized the problem).

You can have a look at the WikiPedia page for an idea of what the consensus view on OPML is.

Finally, there's this request from Scoble:

I am a user. I'll leave those discussions to the developers. But, as a user, I don't really give a flying leap. I see the feature I want. I see that someone has done it by hand to get what they want. I want even more. Are you gonna give it to me? Fine. If not, then can you stay out of the process please?

None of us implementors can give you anything worthwhile so long as we have to deal with utter crap. I'm writing code in this space - both on the server side, and on the client side. So no, I'll stay in the process, thank you very much.

Update: Comments from James Kew and Gary Short. I'll also add this, following on from Robert's "put up or shut up" dare - it reminds me of the oh so common political argument that devolves down to "I care more, so you're facts don't matter". Sigh.

Ted Leung spotted an interesting use of blogs - completely outside the tech or political realm:

Last week when I was walking through the kitchen, Julie stopped me so I could see the blog of Seattle-based classical singer Anne-Carolyn Bird (website). I popped the url into Firefox, but it has taken me a while to get to it. Anne-Carolyn's blog is a window into the life of an aspiring classical singer. It was pretty interesting to read her accounts of auditions, rehearsals, performances, and interactions with others in the music community. Via her blog I've found (but not yet gotten to) the blogs of a number of other classical musicians.

It's cool to see people in fields that I know nothing about posting about how things work for them. It gives me (and anyone else who cares) a window into a field that I otherwise wouldn't know anything about - and I'm sure that the other potential windows (random TV shows and movies) are distorted by the same lack of knowledge that I have.

Dave Buck explains that the problem with manifest typing is coupling and rigidity, and that refactoring and code completion tools don't help with those problems.

Well - I guess my post on OPML was received with interest by the blogosphere :) I've been thinking about adding a per post cache to Silt for awhile now, but it hadn't really been necessary - until about 30 minutes ago, that is. That's when not having one overwhelmed the server - which is why you might have seen an Apache level error a bit ago when trying to access any of the blogs here.

So... I added a cache to my test server, and tried it out. It worked great, and showed me something else I hadn't known - specific page requests were generating two lookups to the back end, which meant that each time a specific post was asked for, the server rummaged for the specific file twice! That's not good. So while I was in the code, I fixed that problem.

The good news is, the site's back in operation. The bad news is, I now need to upgrade the site. It's been running on VW 7.1 for awhile now (just like our customers - I only upgrade when I really need to :) ). So, I'll be building a 7.3.1 deployment server today and testing it out on my local server. We'll see how that goes, and upgrade the server itself when things quiet down a little.

Cringely has an amusing take on Microsoft's reorganization:

So now Microsoft has decided to become Cerberus, the three-headed dog guarding the gates of Hades. Ballmer and friends have done what the DoJ couldn't do, splitting the company into divisions for platforms and services, business apps, and entertainment. (It was very scientific: I understand they converted Microsoft's old org chart into MP3 files and put them inside an iPod Shuffle.) The Redmond Ramblers desperately need to bring more innovation and less imitation to the table. The question is, Will the reorg make them smaller and more nimble, or merely three times as inept?

Heh.

Brainwagon summarizes the issues with OPML (and with RSS, for that matter) better than I did - I wish I'd written this:

Scoble likes to champion first RSS and now OPML under the claim that they are good for users. What would be good for users is for the deficiencies of these formats to be absent, or at least invisible. They are not. They manifest themselves in all sorts of edge cases which prevent interoperability. I've spent a great deal of time reading RFCs for various networking protocols and formats, and by comparison the RSS and OPML "specifications" are scribbles on napkins.

Scoble's attitude reflects what I think of as the Microsoft way: it doesn't matter what's underneath as long as what's on top looks shiny. Sure, it will belch smoke, require servicing by a third party every three thousand miles and occasionally make strange sounds that will puzzle and worry the owner, but look how shiny it is.

Read that second paragraph again, and then go read this. The problem with OPML, and with RSS, and with MetaWebLog API is that the specifications are loose. Not just loose, heck, they are basically non-existant. I'm going to do something now that'll surprise a lot of people - I was wrong about a bunch of the crap I gave the Atom group. Ideally, Atom wouldn't have been necessary. But Winer is such an incredibly difficult person to work with that a bunch of people who would rather have tightened up the RSS spec (you know, into an actual spec) went out and created a new syndication format.

Sure, over the time they spent on that, they had a lot of "Angels on the heads of pins" conversations. It seems to me that such things are endemic to standards groups though, and they did produce a specification. And - unlike RSS - if you look at the Atom 1.0 spec as an implementor, you know exactly what it is you need to do. That's simply not the case for any of the formats Winer has created and championed over the years. Yes, RSS has been (and is) very useful. It will continue to be useful. It could have been a lot easier, if only Winer were willing to accept reality.

So let's get back to users. Scoble has a follow up post here - where he summarizes:

James Kew, for instance, asks "why can't a reviewer say something sucks?" OK, I buy that. But, usually Ebert and Roeper have something better for you to see. In this case, I have an app. I have a demonstration of what I want from TechCrunch. I want it too. Is there something better that meets my needs? Give it to me.

The crappy format is good enough until someone comes up with something better. And that's what you're all missing.

Remember the link I put way back at the top of this post to the "broken windows" post from Scoble? Longhorn is very, very late - and a lot of the reason is that MS let a bunch of developers run off with loose (or absent) specs and implement stuff as they saw fit. What a shocker - the pieces didn't all fit together. Well heck - what the do you think we have now with the "crappy format of the week" situation? We have a bunch of pieces from various developers that don't all fit together - and since we don't all work at the same place, we can't toss everything out and call a do-over, like MS did.

So yes Robert - as a user, you ought to give a damn. The reason people have trouble coming up with applications that interoperate well is because the baseline formats that are out there suck eggs. I'm done giving the Atom people crap - they were right, and I was wrong.

It comes down to the last three games of the season - there are two slots left - the AL East ring, and the wild card. There are three teams looking to get one of them. Here's how it looks right now:

Team	Wins	Losses
Yankees	94	65
Red Sox	93	66
Indians	93	66

That's a pretty tight race with 3 games to go. The Yankees and Red Sox play their last three games against each other - so each of those two teams holds their own destiny in their hands - the Indians have it a little tougher, since they can only get the wild card. I saw something on ESPN about the Indians having some kind of edge in a tie-breaker situation, but I can't find a reference for it. The Indians play their last three games against the White Sox, who have clinched the central division. Still - they don't want to go into the playoffs on a losing note.

It's going to be a tense weekend for baseball fans.

Poor math skills at ESPN:

Let me try to explain this with some brevity: The short answer is that the White Sox won via a tiebreaker. The White Sox have not clinched the division's best record, but they have clinched the division title. Still confused? If the Indians manage to sweep the White Sox this weekend, both teams will finish the season with 96-66 records, leaving them tied atop the standings. But with both teams guaranteed a postseason berth -- either the Yankees or the Red Sox will necessarily finish with fewer than 96 -- who wins the Central is relevant only when it comes to postseason seeding.

Let's see now - the standings have the Yankees at 94 wins, with three games to go. So - if they swept the Sox, they would end up with 97 wins. Which, last time I checked, was a bigger number than 96. And how are the Indians "guaranteed" a post season slot? If they end up tied with the East division second place team, then it comes down to tie-breakers (and if that's a wash, a one game playoff). They could end up being swept, and completely out of it. How he gets to the Indians being guaranteed a slot? I have no clue...

With the Yankees/Red Sox game on???

Ok, this tale of email that can only go so far is just too amusing :)

TalkLeft explains just how expensive not backing up can be. I've paid good money to recover files as well - $600 a few years ago, for a far, far smaller drive:

It cost $1,250.00 for the restore and another $100 for an 80 GB USB hard drive which I'm about to hook up and see how usable the files are. Bottom line: Back up your stuff. $1,350.00 could have bought me a new laptop or a vacation. Now I'll get neither. It sucks that I had to spend it for this. But, it's my own fault for not taking the time to back up onto a cd-rom or dvd.