Smalltalk Tidbits, Industry Rants

Charles Miller has an amusing idea about credit for bad code - adopt the Alan Smithee crediting system

This story has an interesting case study of the development of a web app. The developers ended up going with Lisp rather than Java for productivity reasons - based on their evaluation, they would have done as well with Smalltalk. Take a look - here's an interesting snippet:

As software developers we had the most experience building web applications using Java technology. In the Java world you find all the necessary tools, frameworks, libraries and servers to build almost anything. Java is very good at absorbing all the great abstractions like object technology, garbage collection, model-view-controller, layered systems. However, the Java world is becoming very large and complex. And all things touched by Java (especially the J2EE part) have a tendancy to become overly verbose and cumbersome. This is partly because of limitations in the Java language itself (full static typing, no interactive or dynamic modifications at runtime, little room for data driven programming) and partly it is a community thing (standards reached by consensus and political motivations).

Because we had a past exposure to both Lisp and Smalltalk, we knew that there were very good alternatives to Java. Thanks to Java, a type-safe runtime with automatic memory management and garbage collection became accepted both on the client and server side. People now know that the small price in performance is dwarfed by the advantages in productivity. Lisp and Smalltalk easily match Java feature-wise, but add full dynamic typing, allow interactive and dynamic modifications at runtime and allow for much easier data driven programming. The best part is that current Lisp and Smalltalk implementations often consume less memory and run faster than Java.

The bottom line - if you build the same way as everyone else, the liklihood of your gaining an advantage over the competition is very slim. If, on the other hand, you are willing to look at alternatives - and gain productivity in the process - you have a decent shot at getting a leg up.

Spotted in The Doc Searls Weblog:

Novell Buying SuSe. Interesting...

Paul Graham shares some words of wisdom about software development:

For example, I was taught in college that one ought to figure out a program completely on paper before even going near a computer. I found that I did not program this way. I found that I liked to program sitting in front of a computer, not a piece of paper. Worse still, instead of patiently writing out a complete program and assuring myself it was correct, I tended to just spew out code that was hopelessly broken, and gradually beat it into shape. Debugging, I was taught, was a kind of final pass where you caught typos and oversights. The way I worked, it seemed like programming consisted of debugging.

For a long time I felt bad about this, just as I once felt bad that I didn't hold my pencil the way they taught me to in elementary school. If I had only looked over at the other makers, the painters or the architects, I would have realized that there was a name for what I was doing: sketching. As far as I can tell, the way they taught me to program in college was all wrong. You should figure out programs as you're writing them, just as writers and painters and architects do.

Realizing this has real implications for software design. It means that a programming language should, above all, be malleable. A programming language is for thinking of programs, not for expressing programs you've already thought of. It should be a pencil, not a pen. Static typing would be a fine idea if people actually did write programs the way they taught me to in college. But that's not how any of the hackers I know write programs. We need a language that lets us scribble and smudge and smear, not a language where you have to sit with a teacup of types balanced on your knee and make polite conversation with a strict old aunt of a compiler.

If someone asks you "what's RSS, anyway?" - then point them to this handy summary

Sean McGrath has some interesting observations on the issue:

Non-IT people looking at this smorgasbord of syntax quite understandably develop retinal glaze syndrome. They hope against hope that the whole thing will just goes away some day. The questions ripple out from the water cooler. 'Why do you guys in development want dozens of types of hammers when all you have are nails?'. 'Why doesn't everyone just use Java?'. 'Why doesn't everyone just use C#?'. And so on.

IT people are also inclined to see the diversity as bad or at least conclude that the benefits of a multilingual approach are outweighed by the costs. A consequence of this is that mono-lingualism is rife in commercial IT. Some of the uses I see Visual Basic being put to, or Java being put to - all because of a corporate edict of mono-lingualism - are downright sad. Sad because of lost opportunities - not only to deliver better product quicker, but also to deepen the knowledge of design and implementation techniques in the development team.

There is no single "silver bullet" - picking a hammer will make everything look like a nail, and not in a good way. What IT people ought to do is look at carpenters - or mechanics - and ponder what their way of thinking would translate to in those realms. Would you trust a mechanic who only used a screwdriver with your car?

Sean McGrath - and a lot of other people - have been piling on about how voting machines just have to be open source in order to be safe. I don't really care about the politics of this - let's look at the claim though. If no closed source system is safe for voting, then how safe is closed source for anything? i.e., if you advocate this position, then you should not be using WIndows, or Oracle, or SQL Server, or Solaris, or Java, or Smalltalk (outside of Squeak or Gnu ST) - etc. Somehow I doubt that all these advocates are quite that consistent....

Chris Admanson wonders if the problem with Java GUIs is that - since they are so easy to create - too many people who should not create GUIs are doing so. He writes:

A couple of people made the point that new and better GUI tools won't necessarily result in better applications. jeremyzacker writes:

The problem with Java GUIs isn't the language, its the notion that any Java developer can write a GUI. Java makes it so darn easy to write GUI code that people who would normally have nothing to do with a GUIs think that they can write one.

He goes on to note that the real problem is with developers who don't understand threading and the Java AWT event-dispatch/repainting scheme, who block the GUI and create apps that appear slow or prone to freezes. Good point, and one that was directly addressed in a recent java.net article by Jonathan Simon. I ran in to similar problems a while back and blogged on ONJava about it.

First off, if you don't have a GUI builder, GUIs aren't "easy to write". In fact, a lot of the issues with event hookups likely derive from people not following the intended practice with the frameworks they get - something a decent GUI Builder does by wiring that stuiff for you (which, incidentally, is one of the bigger complaints about the VW GUI builder - the fact that it leaves an inordinate amount of that work to the developer). If a system where it is "too easy" to build GUI's leads to constant performance problems, which in turn yields few mainstream GUI apps - then I really, really want someone to explain the prevalence of C, C++, and VB based GUI apps on Windows. Visual Studio (and Borland's tools, et. al.) make it very easy to slap together a GUI - much easier than it is in Java. So if the "too easy" premise held water, there would be a dearth of Windows GUI apps. Hmmm

The referers list on the blog has been broken for awhile, I think - I only just noticed. I took a look, and the break was because of an unintended side effect to a change I had made in the server a few weeks back. It's all fixed now, so the referer list is back.

Here's yet another example of a politically driven rewrite - one that is not taking account of user requirements - and why they are a bad idea:

Earlier this year, I put into production a new part of the UI system, using HotDraw. It allows the users to link two accounts by putting them into a "map" and drawing a line from one to the other. This causes a database update, cache refresh, yada yada yada. Users love it.

We have another project going on, our UI rewrite. This is being redone in Java, with a Web front end. It has to be done using the "anointed toolset", nothing else. I've known this was coming, which was the main reason I did the HotDraw thing. This is driving the Java guys nuts, because they don't have a similar tool with whatever cheezy toolset they're using. My users look at what they have, and say "But how come I can't just draw a line from one to the other like in the old system?"

My favorite complaint is "But you promised us we'd have everything we have now." They say "I meant you'd have everything you had at the time I promised it, not everything that'll ever exist."

And IT people wonder why there's so little sympathy for their jobs getting outsourced. When you utterly ignore users for years at a time, what do you expect?

Want to reach a more targeted audience for your PR pitches? Then use RSS

I'm not going to post spoilers or anything - just a sense of disappointment. They could have wrapped the series up by tacking 3-45 minutes onto the second movie; the balance of this was fluff. Cool special effects fluff, but fluff nevertheless.

NewsFacror asks "Is Java Dead?". Wow - not a question I expected to see in the IT press :)

Then ponder this data from Giga:

Outsourcing Deals Fail Half the Time because most companies lack data on how well internal operations stack up against so-called cheap, external competitors. Pointing to market research by Giga Information Group Inc. and others, Jason Schroedl, director of corporate marketing at newScale Inc., claims that more than 50% of IT outsourcing agreements fail for lack of comparative information. "You need to know how well your outsourcer stacks up against your internal offerings," he says, or you increase the risk of having an outsourcing deal collapse. For example, companies often discover that much of the money saved by sending work outside is eaten up by the costs of managing the outsourcer relationship. Also common is for the outsider to bungle the service quality.

So outsourcing to save money - without a really solid plan - is like flipping a coin to save money.

I've started adding application events to BottomFeeder - something which will allow plugins to take note of events that are happeneing in the main application. Here's what I've got in the dev stream right now:

This message is sent to the plugin class (the one registered with Bf) when the feedlist menu changes due to a feed selection

plugin 
	customizeMenu: menu
	forItem: anItem
	andFeed: aFeed

that's sent to the class, not to the instance

To get these events, interested objects should register as a dependent of class RSSFeedViewer

• #addedFeedList: feedUrl -- This is sent when a feedlist is successfully added, with the url as an argument
• #addedFeed: -- This is sent when a feed is successfully added, with the url as an argument
• #newItemsFor: -- This is sent when there are new items for a feed (after an update, manual or via the update loop). The argument is the feed object
• #newItemsForAlert: -- This is sent when there are new items for a feed (after an update, manual or via the update loop) which is set for alerts. The argument is the feed object
• #removedFeed: -- This is sent when a feed is removed. The argument is the feed url
• #removedFeedList: -- This is sent when a feedlist is removed. The argument is the feedlist url
• #quitting -- This is sent when the BottomFeeder image is going to quit. The image will not quit before your method returns.

That's what I've got for now; I'm open to input on this!

Then you need to read this article (via Scoble). Yet another buffer overflow problem. This comes from the continued usage of C and C++. Yes, there are ways of finding those problems. And no, most people won't use those ways most of the time. The answer? Use a managed language - Smalltalk, Lisp, heck, even Java or one of the .NET languages. Or, keep producing security flaws....

Cringely takes on MS plans and Ted Leung is thinking about the whole issue. Here's Cringely:

This (having paid developers who's jobs are theoretically on the line) is nonsense. It is nonsense because Steve Ballmer, like Bill Gates before him, confuses market success with technical merit. Microsoft's product roadmap is a manifestation of a business plan, and what matters in Redmond is the plan, not the map, which is in constant flux. How many technical initiatives has Microsoft announced with fanfare and industry partners, yet never delivered? Dozens. That is no roadmap.

I'm not sure this is the right place to attack, because - in this area - I see little difference between open source initiatives and closed source ones. Here's the deal - Product Management comes up with a technical roadmap, based on how they see the industry with respect to their product(s). Let's say you take that roadmap out 3 years. What's the liklihood that, 18 months in, you'll see the industry the same way? Pretty slim - you'll have course corrections - sometimes big ones. There will be things you intended to do that now make no sense - think MS' big turn in 1993-1995 with respect to the internet, for instance. You think their 3 year plan for Windows circa 1992 really had the internet that much in mind? Things change, all the time

I see this every day in my job. We have planning meetings for the Cincom Smalltalk line after each release - and each release comes 6-10 months after the previous one. We look at what we've done, ongoing initiatives, product needs (based on customer and market inputs), and available resources for implementation. We then make plans for what we are going to do in the immediate future, with goals laid out beyond that. A record of those plans since 2000 would show quite a few changed/dropped plans Why? Because conditions - internally, externally, or both - changed. You simple have to react to those changes.

How is this going to differ for open source and closed source projects? Not a lot, I think. Sure, some of the answers are arrived at differently (particularly resources) - but the questions are the same. Cringely picked the wrong hobby horse here - As with war plans, business plans simply don't survive contact with the market - you have to adjust them

Ted Leung responds to my response on the topic. I see what Ted is driving at as far as a "crutch" for the curly brace crowed - he may well be right. I do think type annotations as an option are important for inter-language interop (SOAP, CORBA, etc). The other side of those conversations is going to want type information; the less painful we can make it to provide that information, the better.

Misbehaving points to Build a Bear as an example of savvy marketing. They don't know the half of it - my daughter and pretty much all of her friends love the place. The website is well targeted too - all the invitations for my daughter's birthday party were printed straight off the site. The people running that company figured out their target market really, really well.

Via Scoble comes word that Google is sending bots to IRC channels. Fascinating. I can't imagine what good that's doing them in search; I'd love to know the rationale.

Sjoerd Visscher talks about RSS Enclosures:

Christopher Lydon Interviews Adam Curry. I had not yet listened to any of these interviews, and as Adam Curry always as something interesting to say, I thought I'd listen to this one.

So I clicked on the link to the mp3 of the interview, expecting a Save to disk dialog. To my surprise a Quicktime bar appeared in page, and immediately started playing the interview. The download progress bar vastly outpaced the current playing position slider, and the interview played to the end without interruption.

In the interview Adam talks about RSS enclosures. I've never really liked enclosures because you can only listen to them the day after you've read the item it belongs to. So I always forget to listen to them because they are by then right at the bottom of the aggregator page, and it fills the harddisks with things you only want listen to once.

Adam specifically mentions the interview as a good example of an enclosure. So now I wonder if Adam actually knows about streaming mp3.

There's really nothing specifically in enclosures that specifies the "download later" action; that's a Radio specific feature. I recently added support for Enclosures to BottomFeeder, and I thought the whole "download to a folder later" thing sounded complicated and silly - especially in a broadband world. So here's what bf does - if there's an enclosure, you get a link to it right in the item pane. Clicking said link will spawn a browser. I leave it up to the OS/browser combo to figure out what to do with the data that comes from the link - that seems like the right thing to do.

Hey, look at that. Those are BottomFeeder screen shots Wow.

Periodically, I've had people tell me that they get server errors when posting comments here. I figured out what causes that - the comment entry form had a dependency on cookies, and many people have cookies disabled. So, I've gone ahead and removed that dependency - commenting via the web form ought to work now whether you have cookies enabled or not

Think again. Here's a post that sums up how many average net readers view RSS:

I am not a technically proficient user. I don't know what XML, RSS, or even HTML stand for. I think the internet is the web, and the web is the internet. I still haven't figured out that I can dial up without having to click on the blue 'E' first.

When I see an orange button, I wonder what it does. I push it. A bunch of garbage text fills my screen, so I assume the button is broken. I don't push the useless button again, and resent it being there.

There are more people in this camp than you would like to imagine. As I said here, for most people a computer is an appliance - they use it to do some task. They don't want to know about protocols, file formats, or network issues any more than they want to worry about the technical differences between the AM band and the FM band. We (technologists) forget this, a lot. For the opposing bozo view on this, read this Guardian article

Spotted an old article on dynamic vs static at ongoing this morning. There's a section at the end on exception handling, which provides more proof for an old theory - over time, everything grows to resemble Smalltalk or Lisp. Or both

Charles Miller says that there's no silver bullet for security issues. And he's right. On the other hand, we can choose to limit the potential classes of problems - as this Register article advocates. To my mind, there's simply no good reason to be doing application level development in C or C++ any longer - the risks are too high. That article advocates Java as the answer - obviously, my answer is different. But you knew that :)

I was trawling around the Lord of the Rings site this morning, and stumbled across an interesting bit of video they did on sound effects. In Two Towers, there are a few scenes of the Nazgul riding flying beasts. They have the beasts roaring a few times - and I just found out where that sound originated: from a donkey bellowing.

Now, of course, I'll have the image of a donkey in my head whenever I see it :)

eWeek says it's coming down the pike. I've been at this for a little over a year now, and I think it's helped the Smalltalk group here at Cincom gain visibility. Marketing departments are going to have to get used to this sort of thing being one more outlet.

The most recent version of GF/ST is now in the public store

Curtis Cooley writes down some pragmatic thoughts on XP and success. Well worth reading

Curtis Cooley writes down some pragmatic thoughts on XP and success. Well worth reading

We are in the home stretch for the next release of Cincom Smalltalk. Look to the home page for announcements and updates

If you are using the dev stream of BottomFeeder, and you just grabbed the latest - you likely saw a whole bunch of 'new' items that you had already seen. Addressing an issue with the code that merges new items in after each fetch is the culprit - the large number of bogus new items is a one time event.

I went to a small game convention last night and this morning - there was a Puerto Rico tournament. I did very well in the first three games - won them all. Then in the 4th round I got completely out-manuevered, and came in 3rd. I still made the final; my three wins saw to that. I got knocked off my early strategy of getting a Factory - they went when I was short a few doubloons. I think my mistake was buying the Office; should have gone for the Large Market. I came in 3rd in a very close game - the 4 of us separated by 5 points. All in all, a pleasant diversion - I'll have to do this again!

Keith Ray has some advice for a guy using C++ for a new project - just say no

So I was looking at all the RSS feeds Microsoft has for their in house bloggers - an impressive list, and a lesson to the rest of the tech community. Say what you will, but most other orgs - closed and open source - are well behind the curve on this kind of subversive marketiing. That's not the reason for this post though.

In the process of examining these feeds, I stumbled on this blog and the associated RSS feed. Well - the items seemingly had no content. So I take a look at them in the dev environment, and here's what one of the items looks like:

<body xmlns="http://www.w3.org/1999/xhtml"> <p> Get it now, for free!  Some guy is hosting Moveable Type based blogs for free at 
<a href="http://weblogs.us/">weblogs.us</a> </p> <p> You get a blog, 100mb of hosting (for photoblog or whatever), and 1gb of traffic 
FOR FREE..  what a deal -- if you wanted to start blogging but weren't sure how to get started, now you can! 
</p> <p> Good luck </p> <p>   </p> </body>

So what the heck is up with a leading body tag? I had to add more clean up stupid crap in the text code to BottomFeeder for that. Entropy continues to increase....

Charles Miller has started on a book covering application level security issues with software. As he says in the article, other than rejoinders to avoid buffer overflows, not a lot is being written on this topic. Hat tip to Charles for bringing up this important topic.

Check it out - this is on my list of projects I should look at as well...

Check it out - this is on my list of projects I should look at as well...

We tried out a new game last night - New England. It's a four player, territory/resource management game. The idea is that you are one of the settling families at Plymouth, and you have to set up the most productive land holdings. You do that by playing land tiles, and you play the land tiles according to a system determined by cards you buy. The game is ery easy to learn, and once you get it down, you never really have to check the rules - it's much cleaner that way than a lot of board games I've played. I don't have a complete feel for the game yet - we played about half a game, but all of us were too tired to continue - the game convention took it out of 2 of us, and we had to just stop when we were too bleary eyed to see the board anymore :)

Even so, I'd have to recommend this game. It played well, was easy to learn, and took no time at all to setup. We'll give it another go next weekend, I'm sure - and I'll let you know what I think of it after a full play

I got to thinking about this when I took a look at all the MS dotNet blogs - all of them with RSS feeds. MSDN now has RSS feeds as well - think about that for a minute. The dotNet blogs all allow comments, and it looks like the authors read (and more importantly, respond to) the comments. What does that mean? Well, a bunch of those bloggers are product managers or project leads. How hard was it in the past to get ahold of the product manager for something at an outfit as big as MS? Now look at it - straightforward access, including contact information. That's huge. It used to be that you had to go to a trade show (and swim through huge crowds) or be an important customer and get ad hoc access. Now anyone with a browser or news aggregator can get far more details.

There's another fallout of this as well. MS is a big company, and - to put it delicately - has something of a controversial public image. These blogs help soften that image by putting real - and unedited - human voices on the firm. Instead of a carefully crafted press release from Redmond, you can read the actual thinking of employees at MS - including those of blogger in chief Scoble - who's posting MS marketing stuff to a non-MS server. For all the crap I give Scoble about the rah rah postings, it's real - and it seems that MS hired him, in part, to do exactly what he's doing.

Over time, this is going to result in a more positive view of MS through the tech community - because they'll be exposed to real people who work for MS instead of just the reporting of the trade press. This is happening somewhat in the political realm as well (see the Dean campaign for an example). I think it's a little less real there - the various campaign blogs are all marketing efforts, not real stuff like the MS blogs, or this blog. Still, they are opening a window into those campaigns that is valuable - the campaigns aren't relying only on major media to get their message and tone out - which is relevant to the point I'm trying to make here

Now contrast this with bigger companies that don't have anyone blogging for them. The only image you get is the marketing department's image. Maybe that's ok - but I think most people take that image with a decent amount of cynicism. This isn't to say that there aren't dangers here - marketing departments exist to create and massage the image of a company, and letting just anyone create an unfiltered view could go badly. It's early days on this stuff, and I'm sure we'll see some major mistakes made as time goes by. In the meantime, I think it's a bandwagon that most firms in the tech world are going to have to get on

Sam Shuster has started writing a series of articles on Drag/Drop, specifically in a VW context. Start here for part one, and then read part two. Sames promises more on the topic - stay tuned.

IBM seems to be trying the format out with this Lotus Notes blog and this accessibility issues blog. Searching for 'blog' on their site turns up a few others as well - anyone know if they have a page where these things are all linked?

Joe Gregario has a nice set of points on the MS push. In particular, this:

Let's look at this diagram of Longhorn. Focus on the lower third of the diagram, the part in white labelled "Base Operating System Services", but excluding the part in "CLR". That part, which represents about 1/3 of the whole diagram, is what Windows NT is today. That means in the next three years the size of Windows is going to triple. This does not sound like a good idea. It's taken MS years just to beat the lower third into shape, and it's still less stable and more bug ridden than linux. Now they're going to triple it in size?

and then this on the WinFS file system:

Now assume (incorrectly) that you were real careful and went back and entered meta-data for the 20GB of your special files. You know the ones, the same files that you have not been annotating with meta-data over the past 5 years. What are you going to use WinFS for? Why to search for pictures of granny or for old documents. That's it. Just search. Why all the fuss over meta-data? What you really want is Google for the desktop. All the meta-data in the world isn't going to find the mis-filed final revision of your marriage proposal titled "Untitled7.doc" sitting in "c:\Documents and Settings\Owner\Application Data\Microsoft\Office", yet a simple text search for "poem love marriage" will likely turn up all 7 revisions.

While I hadn't put my finger on it, that's pretty much what I had rumbling around my head on WinFS...

Let's Welcome Bob Westergaard to the Smalltalk community blog. Bob is the guy who does all the behind the scenes work that make builds and VW in general happen. It's great to have him blogging!

I was on my way to dinner this evening when bam, I hit a deer. Stupid animal sailed across the front of my car, crushed the hood on the passenger side, and left part of an antler in the broken front window. I had my daughter in the car, and fortunately not in the front seat. Broken glass everywhere, but no injuries. Now I have to go calm down...

I'm not the only one who thinks that the various XML messaging services are reinventions of the wheel - Ted Neward has seen it all before as well. IMHO, this is one of those times in the software industry where everyone jumps on a new messaging bandwagon for no apparent reason. COM/DCOM - sure, that was MS specific. RMI? Sure, that's Java specific. CORBA, on the other hand, wasn't specific to anyone. To those who say that CORBA was/is too complicated - I say that you clearly haven't been working in XML long enough. Having done both now, I fail to see much difference....

Clay Shirkey wrote an article recently that everyone else has commented on - so I suppose I ought to drop my 2 cents. It's a good read, and makes some interesting points:

Despite their appealing simplicity, syllogisms don't work well in the real world, because most of the data we use is not amenable to such effortless recombination. As a result, the Semantic Web will not be very useful either.

The people working on the Semantic Web greatly overestimate the value of deductive reasoning (a persistent theme in Artificial Intelligence projects generally.) The great popularizer of this error was Arthur Conan Doyle, whose Sherlock Holmes stories have done more damage to people's understanding of human intelligence than anyone other than Rene Descartes. Doyle has convinced generations of readers that what seriously smart people do when they think is to arrive at inevitable conclusions by linking antecedent facts. As Holmes famously put it "when you have eliminated the impossible, whatever remains, however improbable, must be the truth."

This sentiment is attractive precisely because it describes a world simpler than our own. In the real world, we are usually operating with partial, inconclusive or context-sensitive information. When we have to make a decision based on this information, we guess, extrapolate, intuit, we do what we did last time, we do what we think our friends would do or what Jesus or Joan Jett would have done, we do all of those things and more, but we almost never use actual deductive logic.

Consider that for a minute - just how often are you confronted with a set of simple truths, from which you can derive useful results? In my experience, not that often. What we get instead are a set of partial facts, many of which are actually (or seemingly) contradictory. You aren't left with a set of statements from which an obvious truth drops out; rather, you are left with a mass of data that you have to make sense out of - and deductive reasoning isn't going to help you that much. Heck, marketing and sales departments would have much higher hit rates if it was as easy as the semantic web folks make it out to be. Here's a useful example he gives:

Consider the following statements:

• The creator of shirky.com lives in Brooklyn
• People who live in Brooklyn speak with a Brooklyn accent

You could conclude from this pair of assertions that the creator of shirky.com pronounces it "shoiky.com." This, unlike assertions about my physical location, is false. It would be easy to shrug this error off as Garbage In, Garbage Out, but it isn't so simple. The creator of shirky.com does live in Brooklyn, and some people who live in Brooklyn do speak with a Brooklyn accent, just not all of them (us).

Each of those statements is true, in other words, but each is true in a different way. It is tempting to note that the second statement is a generalization that can only be understood in context, but that way madness lies. Any requirement that a given statement be cross-checked against a library of context-giving statements, which would have still further context, would doom the system to death by scale.

Context is what kills this. Statements nearly always have a context - we simply don't live in a context free world. Thus, any statement requires knowledge of context before it can really be evaluated. Without that context, what you get is GIGO. The most entertaining part of the article is Clay's devastating takedown on proposed uses of the Sematic web - taken directly from the W3C site:

Consider the following, from the W3C's own site:

Q: How do you buy a book over the Semantic Web?

A: You browse/query until you find a suitable offer to sell the book you want. You add information to the Semantic Web saying that you accept the offer and giving details (your name, shipping address, credit card information, etc). Of course you add it (1) with access control so only you and seller can see it, and (2) you store it in a place where the seller can easily get it, perhaps the seller's own server, (3) you notify the seller about it. You wait or query for confirmation that the seller has received your acceptance, and perhaps (later) for shipping information, etc.

One doubts Jeff Bezos is losing sleep.

This example sets the pattern for descriptions of the Semantic Web. First, take some well-known problem. Next, misconstrue it so that the hard part is made to seem trivial and the trivial part hard. Finally, congratulate yourself for solving the trivial part.

All the actual complexities of matching readers with books are waved away in the first sentence: "You browse/query until you find a suitable offer to sell the book you want." Who knew it was so simple? Meanwhile, the trivial operation of paying for it gets a lavish description designed to obscure the fact that once you've found a book for sale, using a credit card is a pretty obvious next move.

This describes the free floating "huh" I've had whenever RDF gets discussed. The advocates throw it around as if it were a magic wand, ready to deliver perfect meaning to all of us - without ever stopping to consider the issue of context. Field names mean nothing without context, and throwing them around as if they had freestanding meaning simply confuses the issue. Just because I have a tuple with names attached doesn't mean a lot - if it did, there wouldn't be so much data migration work in the real world. Clay goes into this problem as well, and it's worth reading in full

You can look at RSS, and the various attempts to create meaning from it as an example. RSS works because all the tags have an agreed upon meaning. If I stumble across <title> as a part of the <item>, I know what it means. Why? Because enough people started using it that way. Does that mean that I know what <title> means in some other XML document of a different format? Nope. I don't care if the RDF folks shout all day long about how the tuples describe it; unless there's been an explicit or implicit agreement, the tag could mean anything. If I try to make assumptions, I'll likely present utter nonsense to people. This is why standards exist; you have to have agreement on terms before you can get anywhere. Loose rules based on supposed semantic equivalency simply aren't going to be trusted.

This summary puts it all very well:

After 50 years of work, the performance of machines designed to think about the world the way humans do has remained, to put it politely, sub-optimal. The Semantic Web sets out to address this by reversing the problem. Since it's hard to make machines think about the world, the new goal is to describe the world in ways that are easy for machines to think about.

Descriptions of the Semantic Web exhibit an inversion of trivial and hard issues because the core goal does as well. The Semantic Web takes for granted that many important aspects of the world can be specified in an unambiguous and universally agreed-on fashion, then spends a great deal of time talking about the ideal XML formats for those descriptions. This puts the stress on the wrong part of the problem -- if the world were easy to describe, you could do it in Sanskrit.

Context, or as Clay puts it, world view, are critical. His examples make this clear:

Many networked projects, including things like business-to-business markets and Web Services, have started with the unobjectionable hypothesis that communication would be easier if everyone described things the same way. From there, it is a short but fatal leap to conclude that a particular brand of unifying description will therefore be broadly and swiftly adopted (the "this will work because it would be good if it did" fallacy.)

Any attempt at a global ontology is doomed to fail, because meta-data describes a worldview. The designers of the Soviet library's cataloging system were making an assertion about the world when they made the first category of books "Works of the classical authors of Marxism-Leninism." Charles Dewey was making an assertion about the world when he lumped all books about non-Christian religions into a single category, listed last among books about religion. It is not possible to neatly map these two systems onto one another, or onto other classification schemes -- they describe different kinds of worlds.

This is exactly why you can come up with industry area standards on formats using meta-data to describe things - the context, or world view, is similar enough that you can get agreement on terms. Now try to come up with a cross industry, universal context - and you'll start to understand why so many large ERP projects run aground. The ERP vendor put together workflow (etc) within a given context - and that context works less well the further away from it you get. The same thing happens with attempts to come up with a universal descriptive language for the semantic web - there are too many competing contexts.

I'd suggest you go and read his entire piece - it's a truly devastating takedown of much of what the semantic web folks think they are trying to accomplish. By shining the bright light of reason on it, Clay has given all of us a lot to talk about

If you are Smalltalking in Italy, then here's the mailing list for you

The Fall 2003 release of Cincom Smalltalk is done - CD's are being printed, the new NC should be ready soon. It's a great release, and I want to congratulate all of our engineers for the great work they've done. The release contains:

• VisualWorks 7.2
• ObjectStudio 6.9

There's an interoperability bridge between the two products now - check out the Opentalk port to ObjectStudio!

Now here's Ed Foster of INfoWorld reporting it - you can buy a new printer for the cost of the replacement cartridges. Ed quotes a reader letter:

About a year ago, I purchased an HP Photosmart 7350 inkjet printer and a black cartridge (since it only came with the color & "photo" cartridges) for $260--an excellent price at the time. A buddy of mine found that same printer, with all 3 cartridges, on clearance at Costco today for $99. The price drop doesn't bother me (well, not overly). It's the fact that he's buying the printer BECAUSE HE'S OUT OF INK ON HIS OLDER, PERFECTLY WORKING PRINTER!

I said that MS would keep at the SmartPhone thing

Catch up with the whole continuation based web development thread on Ian Prince's blog. It's implemented in SBlog (on top of Seaside), so it's a dogfood example. The RSS feed is here

Catch up with the whole continuation based web development thread on Ian Prince's blog. It's implemented in SBlog (on top of Seaside), so it's a dogfood example. The RSS feed is here

WOAD (Washington Object Architecture and Design) has a TDD presentation coming up on November 18th, from Dave Astels. Here are the details:

Washington Object-Oriented Architecture and Design

WHEN:	Tuesday, November 18st, 2003 at 7:00 PM
WHERE:	Best Western of Rockville (in the Restaurant)
DINNER:	Buffet $12.50 (includes tax $ tip - to get the space, we have to eat)
TOPIC:	Test-Driven Development
SPEAKER:	Dave Astels (author of Test-Driven Development: A Practical Guide)

Test-Driven Development (TDD) is a corner stone of XP. Without TDD in place, most of the other practices are difficult or impossible (e.g. refactoring, continuous integration, ...). While writing a complete suite of programmer tests for your software is good, writing them first is better.

However, the benefits of practicing TDD are not limited to XP, and can be realized in any Agile (and even some non-Agile) contexts. TDD helps make our code better, regardless what amount of design or modeling has been done before programming begins. It's a generally useful technique to have in our bag of tricks.

About Our Speaker:

Dave Astels practices, teaches, evangelizes, and coaches XP and Agile Processes. Dave co-authored "A Practical Guide to eXtreme Programming" and "A Practical Guide to Test-driven Development", both with Prentice Hall. An active member of the DC area eXtreme Programming User Group, Dave also contributes to many OO and XP conferences including the XP conference in Europe, JAOO, SD West, SD Best Practices, XPAU, Smalltalk Solutions, and OOPSLA.

Dave Astels is also a founding partner at Adaption Software,Inc.. Adaption's offers a variety of OOAD, eXtreme Programming, and Test-driven Development related services, including training, mentoring, and outsourcing.

RSVP:

Put WOAD-RSVP in the subject line. RSVP by email to cpbell@sysnet.net Space WILL be limited to those who RSVP.

I love the taglines in Doc's post:

There will be no joy in Fudville. Mighty Darl will strike out.

This NY Times article (free registration required) likely explains what happened.

This post gets today's over-simplification award:

First of all, one of the things that we need to do is to make applications that encourage the capture of this data and that make it simple to add and difficult to forget. For years, Office apps have had the facility to prompt for summary information when you save if you so choose. In addition, some data can be automatically derived from your documents - smart tags show one particular way that this can happen.

Make it easy to enter? How would that work? I enter a document. I want to save it. Unless you are planning to automatically grab information from the text, anything you prompt me with is going to irritate me. The liklihood of

• Me going out of my way to enter meta information
• The system capturing anything useful on an automated basis

is low - very, very low. The reality, getting meta information on data takes work - data entry work. No one likes data entry work, plain and simple.

If you want to subscribe to a master feed instead of each blog on this site, then add this xml feed to your BottomFeeder subscriptions.