Smalltalk Tidbits, Industry Rants

The Eolas web patent has been nullified. Is this progress at the PTO, or an "even a stopped clock is right twice a day" event?

Doc Searls takes the typical intelligentsia swing at TV - "it's all crap" while explaining why TiVo hasn't caught on:

Part of the problem is this right here: the Net. It's much more interesting and informative, and even entertaining. TV can't compete. So I think the problem is with television itself. It's still mostly a drug, and getting a better way to administrate it doesn't change the nature of the substance. It just facilitates better abuse.

I have gotten very tired of this brand of slam - whether it comes at TV, at the net, at politics (etc). It's all the same thing - Sophisticated people love to tell you how crappy something is, and why they don't pay attention to it. It's a tiresome argument, and reveals far more about the person making it than about anything else.

To be sure, there have been changes in TV over the last few decades. It's simply no longer the case that one of the major networks can get the attention of a large plurality (or even a majority) of the viewing audience with a few shows. There's simply too much competition. Say you like science fiction - it used to be that you had to just sit back and take Star Trek, or whatever else the networks offered (or didn't). Now you have the SciFi channel. Is there always something on that's worth watching? No, but there's a decent number of interesting things for that fan base within a given week. It's the same thing for history and science - it used to be that all you had was Sunday morning fare and public TV. Now there's the History Channel, the various Discovery Channels, and the Weather Channel (which airs weather related infotainment when it's not covering the weather). Which explains why you don't have to wait up for the 11:00 news anymore - the Weather Channel is always there, as are the 24 hour news networks.

And that doesn't even get into the vast sea of movies and series that are available on cable. Or into classic movies on things like TCM (Turner Classic Movies). The point is, TV isn't "crap" - it's filled with a huge variety of things, some good, some bad, some excellent, some awful. That's where a PVR - TiVo, ReplayTV, etc - helps out a lot. You set up the things you are interested in (either specifically or by category), and then it does the heavy lifting of separating the wheat from the chaff for you. So why haven't these things taken off yet? Well, I'd guess that we are still in "early adopter" mode on these. It took VCR's awhile to really take (I can remember many people questioning their worth in the late 70's), and - until recently - they were only being offered by two very small companies (one of which, ReplayTV, has had numerous issues). That's about to change though. My local cable company is offering PVR's as part of its service now, as are other cable (and satellite) vendors. This is going to help mainstream the technology.

It's not just the smallness of the vendors that has prevented takeoff though. Setting up a PVR is no walk in the park for most people. Getting all of these pieces properly set up:

• The TV
• The Stereo equipment
• The VCR

And adding the PVR into the mix such that you can watch one thing while recording another is asking a lot. I suspect that having the cable company offer to come out and hook it up will help with penetration - lots and lots of people's eyes glaze over when they are confronted with the sea of cables that have to be connected - mine included. I've set up two ReplayTV's, to two different tv/stereo/vcr setups now - and adding the Replays also meant adding a network connection into the A/V mix. I think the biggest issue with PVR penetration is the same issue we face with PC's - people mostly want to buy it, plug it in, and have it just work. Outside the hobbyist community, twiddling with cables and connections is work, not entertainment, and getting things subtlely wrong is just too easy. The cable and satellite vendors are adding a service offering into this mix, which will help a lot.

Enough with the "it's all crap" thing already though - get over yourself....

BottomFeeder 3.4 has been released. I'd like to thank Rich Demers for his help on this release - he spotted numerous bugs before they had a chance to embarrass me, and he did his usual great job on the Bf users guide. Michael Lucas-Smith prodded me to clean up the UI, and that's been done - we have a cleaner, sparser main UI now. As always, report any bugs to me.

If you are already using BottomFeeder 3.3, then you don't need to do a re-install - simply get the appropriate base application from the downloads page, and replace the image or executable. If you have 3.2 or prior, then you'll need the full install, as 3.3 started using VW 7.2 as the base deployment environment. Back up the contents of the btfSave directory before you do anything! If you do a full re-install, you can just restore the files in btfSave, and the btfSettings.ini file after you do so. Enjoy!

Variety has a slew of RSS Feeds - I just subscribed to the TV and movie related ones. Nifty.

This is interesting: VisualStudio effectively creates a runtime image while it operates, in order to facilitate all the features of the IDE:

The reason, though, why you can't turn of background compilation is that the IDE completely depends on it. The information provided by background compilation drives Intellisense, it enables the WinForms designer (as well as all other designers), it fills the dropdowns at the top of the window, it drives the object browser, it enables go to definition, etc, etc, etc. Essentially, without background compilation, the IDE becomes Notepad.exe with syntax coloring. (Coloring, interestingly enough, does not require background compilation because it's entirely based off the lexical grammar of the language and requires no further knowledge of the code.) So that's why we don't let you turn it off.

I'm always intrigued by the fact that large projects effectively re-implement Smalltalk and/or Lisp in order to accomplish the things they need to do. There's a simple way they could take a shortcut, of course... :)

Register for StS 2004 here and hear Paul Baumann talk about SRP:

Introduction to State Replication Protocol (SRP)
presentation
Paul Baumann:
Monday 8:30:00 am to 9:15:00 am

Abstract: SRP is a multi-dialect framework for binary serialization of objects. SRP currently exchanges objects between seven Smalltalk dialects: Dolphin, GemStone/S, Smalltalk/X, Squeak, VisualAge, VisualSmalltalk, and VisualWorks. SRP excels at portability and space efficiency.

An overview and demonstration of the SRP is presented. Participants will understand how to use the framework, how data is encoded for portability, how to customize replication, how to exchange objects, and how to apply various encoding options. Other topics likely to be discussed are portable mapping rules, metastates, remote references, and proxies. Version 3.0 of SRP will be available at the presentation.

Bio: Paul Baumann has developed Smalltalk applications since 1992. He is proficient in code management and in the development of portable frameworks.

See you in Seattle!

Scoble links to a demo of the Kinzan demo. I've had a look, and yes - it's a clone of PARTS. These sorts of things don't scale worth a darn. Not to mention that - even in the simple demo Kinzan has constructed - making the same alterations in a text pane would likely have taken far less time and effort. These things are eye candy, and project managers tend to be awed by them. Until, that is, they have a moderately complex application built with the connection tool that simply cannot be understood any longer. I've got customers who went down that road years ago, and wish they hadn't....

Ryan Lowe comments on my post and on the Visual Studio link that I originally commented on. He's not happy with the way background compilation works in VS:

As for C#'s less than perfect background compiling: I can't stand it. There's nothing worse than editing a file in a *modern* IDE, seeing no errors, then compiling/running it and finding compile errors. It's a complete waste of my time and it only gets worse as the project gets larger and more complex. I know we've come a long way from the dark ages of the command line interface but I'm a new school hacker -- I'm more demanding, I'm writing agile code and I'd rather not wait for: code, complete re-compile, run test suite, code, complete re-compile, run test suite, etc...

That's an interesting problem, and one that "new school hackers" would simply not have were they using Smalltalk. In a Smalltalk system, the code you are creating doesn't need a complex background compilation process - each method is compiled into byte code at the point where you accept (compile) it. That means that you can actually create a test - before the code is written (with said test referring to non-existant code). The system will complain about references to objects that don't exist, but you can let that go. Your test will fail of course - but that's the point (then, at least). You can then start creating the classes and code you need, testing incrementally the whole time

XP came up out of Smalltalk because Smalltalk supports that way of working. While you can use agile techniques in any language, they offer the most productivity in a truly agile language (like Smalltalk). Look at what VS and Eclipse are trying to do - build a Smalltalk-like system. You could actually be working with one, instead of with some second hand, not fully baked copy :)

Variety reports something that makes me cheer - The theatrical release of RoTK on DVD is set for May 25. No word yet on the extended DVD, but that should tide me over....

Register for StS 2004 so you can hear Dan Antion talk about Smalltalk in the nuclear industry:

ANI's Digital Archive
experience report
Dan Antion: American Nuclear Insurers
Monday 8:30:00 am to 9:15:00 am

Abstract: American Nuclear Insurers has been developing a document management system using VisualAge Smalltalk. ANI's digital archive is designed to support both availability of business critical documents in the event of lost or damaged paper documents and broader access to all documents by off site staff. ANI reviewed commercially available document management systems, but they were prohibitively expensive and required a significant amount of effort to prepare and index documents upon submission.

The system can handle any digital document or digital files, such as images, related to documents. In addition, enhanced support was included for business documents based on existing business objects. Once known business documents are scanned, they are pulled into the archive, and the management system creates most all of the index keys necessary. The system also contains a comprehensive search and archive navigation program. A server component handles moving documents in and out of the archive, to prevent people from moving or deleting files outside the control of the system.

Bio: Daniel Antion is Director, Information Services for American Nuclear Insurers. He is responsible for all systems development activities in addition to managing general information technology efforts. Prior to joining ANI, he worked in systems development for several companies. He also worked as a consultant for Coopers & Lybrand and KPMG Peat Marwick, specializing in information systems and consulting services to financial institutions. An enthusiastic fan of Smalltalk, Dan has made presentations at Smalltalk Solutions and OOPSLA

See you in Seattle!

I posted on the MS changes in XP SP2 a few days ago. As it turns out, VisualWorks already does the right thing here. An internal AR (Action Request) was raised, and our VM guys responded:

Turns out we already apply execute permission to the code cache so on the face of it we have nothing to do. However, we in fact apply execute permission to the entire initial allocation the engine makes to load the object memory, which includes not only the code cache but also all of permSpace and oldSpace.

It wouldn't surprise me to learn that most JVM's do the same thing as well.

I've come across an interesting call for papers from a post Java set of workshops. The very name of this event is interesting: 2nd Workshop on Object-Oriented Language Engineering for the Post-Java Era: Back to Dynamicity. It seems that the R&D community in software is starting to realize that Java - and C# - are the last signposts in a dead end area of software, not the heralds of a new way of doing things:

The advent of Java has always been perceived as a major breakthrough in the realm of object-oriented languages. And to some extent it was: it turned academic features like interfaces, garbage-collection and meta-programming into technologies generally accepted by industry. Nevertheless Java also acted as a brake especially to academic language design research. Whereas pre-Java Ecoop's and Oopsla's traditionally featured several tracks with a plethora of research results in language design, more recent versions of these conferences show far less of these. And those results that do make it to the proceedings very often are formulated as extensions of Java. Therefore they necessarily follow the Java-doctrine: statically typed single-inheritance class-based languages with interfaces and exception handling.

That's certainly been the case at OOPSLA the last few years - all Java, all the time - and pretty much none of it new. Instead, it's been a progression of things that had already been learned, but redone in Java. In that respect, the academic world has been echoing the goings on in IT shops during the late '90s bubble - things were redone in Java, and not for any really good reasons. The herd jumped that way, and everyone got behind the herd. Now, it would seem that two things have started to occur:

• IT shops have reconsidered large rewrites as a strategy (the budgets for such things have become very hard to justify)
• The academic world is waking up and realizing that there might be some value in looking elsewhere.

This is all very good news for those of us who have thought that Java represented a sideways step. Yes, the mainstreaming of VM technology and of garbage collection have been altogether good things - I no longer have people questioning their value. However, it's also meant the continuation of a very static approach to systems development. Look at web applications - nothing really new has been invented in that space except in the dynamic arena - Seaside and other continuation based web frameworks have come out of the dynamic language camp (Smalltalk, Scheme, Lisp) - not out of the Java or C# side of the house. All we get from there is masses of XML based "advances" (Struts) that represent a status quo solution to an existing problem. All the new thought is coming from the dynamic niche - which is exactly the sort of problem that people behind this workshop see:

Recent academic developments seem to indicate that a new generation of application domains is emerging for whose development the languages adhering to this doctrine will probably no longer be sufficient. These application domains have recently been grouped together under the name Ambient Intelligence (AmI). The visionary idea of AmI is that in the future, everybody will be surrounded by a dynamically defined processor cloud of which the applications are expected to cooperate smoothly. AmI was put forward as a major strategic research theme by the EU's IST Advisory Group for the 6th Framework of the EU. Meanwhile, the first european symposium on AmI has recently been organised and institutions like the MIT and Phillips have published their visions on the matter. Currently, AmI seems to group previously "unrelated" fields such as context dependency, domotics, ubiqutous computing, mobility, intelligent buildings and wearable hardware. Early experiments in these fields already seem to indicate that their full development will need a new generation of programming languages that have dedicated provisions to deal with highly dynamic hardware and software constellations. As such, AmI will open up a new "market" for a new generation of programming languages which are designed to write software that is expected to operate in extremely dynamic hardware and software configurations. In the past, lots of languages answering this profile have been investigated. Examples are Lisp, CLOS, Scheme, Self, Smalltalk and loads of less well-known academic languages. Give the new constellation outlined above, we believe there is a new future for languages like this. The goal of this workshop is to bring together researchers in object-oriented language design who adhere language features and languages that do not follow the current Java doctrine but adhere more "dynamic features".

Take a look at what's being said there - these folks believe that we need progress, and it's not going to come from the static side of the house. There's progress to be made, but doing so requires a more dynamic style of development than is possible in languages like Java. I have to say, it's nice to hear some validation of the sorts of things that we dynamic language advocates have been saying for years now. With any luck, OOPSLA will start being an interesting show again, instead of "Things we already knew how to do, but have applied to Java".

If you are interested in this from a research standpoint, then follow this link and get involved with the workshops.

Tim Bray noticed something I blipped over the other day. There's been a set of stories claiming that MS is funding SCO's lawsuits. Now, I have no idea whether there's anything to that story or not, although I have my doubts - it's the sort of thing that would look very, very bad to a lot of people - judges especially. The interesting thing is how MS responded:

They went to Scoble to get the message out. I guess that they realized something simple - a net rumor could only be fought properly in the same medium.

Martin Fowler has some interesting observations relating to software developement and how it's impacted by "world view":

• A debate a while ago triggered by Joel's post on exceptions. He didn't like exceptions because they could be misused badly, leading to confusing code (directing). Bill Caputo pointed out that exceptions, when used well, make life much easier (enabling).
• Some of the static/dynamic typing debate brings up these points. Some arguments in favor of static typing talk about how they prevent people from making certain kinds of mistake (directing) while dynamic typers point out how static typing restricts some useful idioms (enabling).
• Agile processes are PeopleOriented (enabling), while plan-driven methods seek to ensure that even a poor team can do an acceptable job (directing).

Martin ties a lot of threads together on a bunch of topics that many people - myself included - have commented on. It's well worth reading the whole thing

In an otherwise interesting article about Sun's plans for RSS use, Jonathan Schwartz apparently felt compelled - as usual - to take a swipe at Microsoft

Gillmor: You mentioned earlier that Microsoft is holding RSS back for some reason. What is that reason?

Schwartz: It's a couple of things. One, the RSS market is relatively nascent. And there are some technology leaders who are going to go deliver their RSS feeds more proactively than others. Is Microsoft missing a huge market right now? Probably not. But it just goes to the prior point that he who controls distribution controls the definition of the standard.

On one hand, I think they're uncomfortable with how much of the RSS standards have been done in the open source community that they can't therefore lock away. And if they take a path, they have to take one that breaks that alliance, and in breaking that alliance - as they've tried to do with HTTP, Java, and every technology they couldn't control - lies some risk for Microsoft. I'm not sure right now they're all that interested or focused on it. I think Steve Ballmer is probably more focused on his pricing in Malaysia than he is on the infrastructure for RSS

I guess Schwartz is unaware of MSDN RSS access. I guess he's also unaware of evangelists like Scoble. But wait, it gets even stupider, with the silliness spreading over to eWeek's Gillmor:

Gillmor: Given that, when will we see some code coming from you that essentially makes it more difficult for Microsoft to ignore RSS?

Schwartz: We have to have that strategy ironed out by the time we announce the developer desktop, which I'm hoping will be within the next few months, certainly not the next few years; this is a this-year activity. And there is already so much innovation occurring in the RSS community 14the number of articles written on RSS today is staggering. Everybody's talking about it. There's Java readers, Mozilla add-ons, Ampheta 26 The issue of when we will make a decision about what we will include in the desktop will be in the same time frame as when we announce our developer desktop.

Somehow, I rather doubt that MS is ignoring RSS and Atom. It wouldn't surprise me a bit to wake up one day and find out that one of the readers that integrates with Outlook (like, say, Newsgator) has been purchased by Microsoft. On the other hand, it wouldn't surprise me if they just let the field develop the way it's been developing. MS is doing the right thing as a content producer with RSS; heck, for that matter, Sun seems to be as well. All I know is, when I hunt around the blogosphere I hear a lot more out of bloggers on the MS side of the aisle than I do from Sun/Java guys. Maybe Schwartz should spend more time trying to get his people blogging, and less time tilting at windmills.

Update: Scoble makes the same points, but with a little more edge.

Sam Ruby's feed validates, but it looks odd to me. What's up with content being in a separate <body> tag instead of in a <description> tag? I can't find any listing of that anywhere as standard. In fact, I went and checked here. Nowhere is a <body> tag referenced as an alternate possibility for <description>. Heck, it's not defined in a namespace, it's just sitting there as something that an aggregator is supposed to magically figure out. This explains why Sam's items are mostly showing up as empty in BottomFeeder right now - valid or no, it's a bad feed

I pushed an update to BottomFeeder last night that deals with the XHTML <body> tag in Sam Ruby's RSS 2 feed. Here's my problem with what Sam's done (apparently quite awhile back; it's discussed here) - it's not sitting in a defined module, and it's not part of the RSS spec. Yes, it's sitting in a namespace. However, it's a "private" module for all intents and purposes, put forth - from what I can glean from Sam's site - because there's some thought that it's "bandwidth friendly", and easier to parse. The former, maybe. The latter? Here's a cluestick - if you have a halfway decent XML parser library, neither the XHTML nor the encoded html is any harder or easier to parse - as an application developer, you never see either one. This is a silly concern over utterly irrelevant technical points. There's also the fact that - as a non-standard extension - aggregator developers are only going to notice this IF they happen to subscribe to a feed doing this, and IF they notice that the content disappeared (which is what I noticed yesterday).

I did a seach on Blogdigger for "xhtml body" - and one on Feedster. Blogdigger brought back 3 results, none of them relevant. Feedster answered zero results. Google actually got me to the relevant blog posts (no pages describing this as a proper RSS Module though). This is a private extension dreamed up by a few people not actually creating aggregators themselves under some delusion that it makes life "easier". Not to mention that all of them are doing it slightly differently - some of them just slapped a <body> tag around the text in <description> - some are throwing out a separate tag, like a module (but again, not documented as such). I dealt with the body tag inside descriptions months ago when I stumbled on it.

Contrast this with something like the Comment API - there's an actual page describing the module - what it is, what it's for, how to implement it. As opposed to this atrocity - described in a few blog postings and foisted on aggregator developers for absolutely absurd reasons. This makes me oh so confident in the eventual outcome for Atom - how many "because we can!" things will end up being tossed into that spec? Or worse, how many won't be, but will start getting used anyway?

Joe Gregorio sounds a little cynical about XML:

Listen closely, in 5 years we'll replace XML with some new whizbang format, and make all the old mistakes in totally new ways.

Sort of like the way XML is a whiz bang format, with a set of interop standards (Web Services) that replaced the former whiz bang format (IIOP) and set of interop standards (CORBA)? Heck, there's even talk of binary XML now. The more things change, the more they stay the same....

Martin Kobetic will be talking about encryption technology in Smalltalk at this years's Smalltalk Solutions. Register today so you can hear all about it!

Cryptography & Smalltalk
presentation
Martin Kobetic: Cincom
Monday 9:15:00 am to 10:00:00 am

Abstract: Recent eruption of security consciousness in the IT industry promoted cryptography from a geeky toy of particularly paranoid computer junkies to an everyday reality for the majority of computer users. Cryptography is just a small part of the arsenal of security professionals today, nevertheless a fundamental one. Thorough understanding and proper use is absolutely critical for any cryptographic solution. Seemingly minor issues can utterly destroy any security properties of an application.

Complexity and misunderstanding is often the culprit behind of all too frequent failures to deliver secure software solutions. Superior expressivity of Smalltalk along with its inherent suitability for agile development methods like TDD provides us with unique opportunity to address many of those issues in an efficient and reliable way.

This presentation is meant to spark the interest of smalltalkers and to motivate them to add cryptography to their arsenal and hopefully profit from this opportunity. It is primarily a practical introduction to cryptography using the Visual Works Security library, but the concepts that will be covered apply to any cryptographic library regardless of the environment or even programming language.
Small "cryptlets" will demonstrate critical properties of various algorithms and techniques. Discussion of practical aspects of a "100% Smalltalk" solution in contrast with alternatives will complement the instruction.

Bio: Martin Kobetic is a member of Cincom Smalltalk development team working primarily on various networking frameworks (Opentalk, DST, Web Services) and the security library. Prior to that he worked on TOPLink for Smalltalk at The Object People, Canada and on various internal frameworks at ArtInAppleS, Slovakia. He presented at Smalltalk Solutions several times on various topics, notably TOPLink, Opentalk and CVST.

See you in Seattle!

Mark Bernstein points to a post by Dave Winer, asking for a merge of Atom and RSS (2.0). It would be a nice thing, and would certainly make things easier on us aggregator developers :) I wonder if the interpersonal politics will prove to be too much though...

I was amazed to read this about Movable Type:

The first problem I ran into was that the process of exporting my existing database and importing it into the new Movable Type installation did not preserve the IDs of entries. Unfortunately, entry IDs are used to construct the URLs of individual posts, which means that all URLs anywhere on the web pointing at specific entries would point to the wrong entry. For about 5 minutes I waffled on whether or not this was acceptable, but then I found these instructions on how to work around the problem.

Modifying the Movable Type source, exporting, putting out-of-order entries back into order, and inserting dummy entries to preserve IDs took about 45 minutes of tedious emacs work. Export/import that preserves IDs/URLs seems like a pretty basic capability.

I'm feeling a lot better about my object serialization scheme for saving entries now :)

Great post on Smalltalk and why developers tend to not "get" it:

That environment-the image-is very different conceptually from how most people program. Most people see programs as a series of files that are compiled and run. There is, underneath even the most extreme of the XP ideas as implemented in Java, etc., the write-compile-run-debug loop that has been inescapably etched onto people's minds.

Smalltalk isn't like that. Code is effectively always compiled, always ready to run, and the debug/run/edit cycles are all blurred together. You can make changes in the editor and continue on from where you are, without having to restart and get back to your original location. It's totally foreign to how people are taught to think about software development. Smalltalk doesn't have phases, and when I write code, I incrementally write/test/explore everything, using a combination of the Browser, the Debugger and the Transcript to do everything.

It's a fascinating thing - more so as tools are now groping more and more towards an image-like state - VisualStudio and Eclipse, for instance, more or less build an image each time you fire them up....

Ian Bicking is somewhat confused about Smalltalk. Yes, Smalltalk looks different than C - but then again, so does Basic (and oddly enough, people seem to be able to use it). Here's the part that caught my eye:

Well, starting from causes, I think Smalltalk's insularity is its greatest flaw. This is in part because Everything Is An Object, and objects have fairly specific conventions. There's a considerable barrier between The Rest Of The World and Smalltalk. It's not just that the syntax looks weird to people -- though that doesn't help -- but it also looks weird to other programming languages. You can't easily map C or other libraries into Smalltalk. You can't make analogous interfaces to the interfaces found in other languages -- you can't even make a freakin' function! Sure you can do everything you need to without functions, but you can't directly map other system's APIs onto Smalltalk syntax, which means you can't map people's past programming experience, or their past programs. (It doesn't help either that Smalltalk's OO nature encourages everything to be a framework, instead of building mere libraries, but that's a topic for a different day)

Gosh, there's so much misinformed confusion there that it's hard to figure out where to start. Too many frameworks and not enough libraries? I suppose this guy has never heard of Taligent or the STL. Everything being an object is a problem? Other than making an assertion, I don't see a real argument in his post. Ahh - here it is "you can't make a function". Translation: "All this object stuff confuses me. Give me a few globals so I can feel safe again!". He then rants about not being able to script Smalltalk or use it to create CGI scripts - first off, I've created Smalltalk images that support scripting on Linux - it's not a huge challenge. The issue here isn't capability so much as culture - Smalltalkers haven't put any effort into supporting scripting, because - for the most part - they haven't been interested. CGI Scripts? I could create one in VW, although having a persistent application server that gets invoked via web server services is simpler and more efficient. I can't run Smalltalk from the command line? Apparently, he hasn't seen any of my Linux server images.

I just love it when people without any recent Smalltalk knowledge make wild assertions like this. I don't spout off about Python or Ruby - due to the simple fact that I don't know a lot about them. I think Ian needs to download a Smalltalk system and ponder it awhile before the next time he lets loose with uninformed silliness....

Update:Patrick Logan comments

Sjoerd Visscher says that liberal parsing is wrong:

RSS and Atom are both XML file formats, they do not accidentally look like XML. Thus according to the XML specification, aggregators are not allowed to try to show broken feeds. If you are doing liberal XML parsing, you are not playing by the rules.

A lot of people are parsing feeds, or are planning to do so. Most of them do so because they want to do something interesting with the data, it might be an aggregator, but it could also be some cool new application. What they certainly are not interested in is the technology of parsing itself. They simply want to use one of the abundantly available XML parsers. Now there are two ways to do feed parsing. One is to only allow proper XML and patiently educate feed producers who do not use the proper XML tools how to improve. (And almost all feed producers are willing to produce valid XML, but they are not helped enough to actually do that.) The other way is to liberally parse anything that vaguely resembles XML and spoil the fun of using feeds for everybody else. If you are doing liberal XML parsing, you are being inconsiderate.

Heh. He's even gone so far as to say he's stopped reading my blog over this. Here's the problem with his theory - it's wrong. And no, I don't really care what the XML spec says. The spec was written before XML went out into the wild. It's out there now, being used by actual people. You know what happens under those circumstances? Errors happen. You know what happens when an end user can't read a feed with an aggregator? Here's a hint - they don't contact the author of the feed, they contact the author of the aggregator. Why is that? Because - from their perspective - it's a bug. You can point to the spec all you want, and it just doesn't matter. Don't believe me? Go write an aggregator, get yourself some users, and then see what happens.

The issue is even simpler - XML is a textual spec. What that means is - in most circumstances - recovery from an error condition is easy, and getting the rest of the document trivial. That's not the case with binary specs - if the people who fuss about XML being a pure spec are really serious, let them go create a binary spec that doesn't allow for simple error recovery. They can also tell me all about the zero end use they'll get

The funny thing is, I actually use a parser that blows chunks on bad XML. I use Smalltalk though, so I've subclassed the system parser, and overridden the error handling as necessary. I have it flag an error and move along. In BottomFeeder, you'll see that as a black bar on the feed icon. In that manner, if the end user is so motivated, he or she can look at the collection of errors, find the contact info (assuming the feed had it) for the author and report it. Contrast that with Sjoerd's preferred world - the application would report an error and stop processing the feed. No more information, no contact info for the feed author, nada. So here's the punchline - he thinks liberal parsing is inconsiderate. Of course, in his world, we simply get inscrutable errors that can't be reported to anyone - but that's somehow considerate. And he says I rant too much :)

Nu Cardboard has a far more pragmatic explanation of why developers stay with their familiar text file based approach to development:

The problem with text files, as with petrol engines, is that they are good enough. We are used to text files. We are trained to work with text files. All our IDEs, OSes and version control systems are geared to text files. Any other system for storing and manipulating source is competing with computing's technological and cultural heritage.

The funny thing is, Smalltalk sources are in files - they just aren't in a bunch of little files stored in a directory hierarchy (typically, although VW's parcel files are a lot like that). On the other hand, it seems to me that tools like VisualStudio and Eclipse are groping in the direction of image based development more and more - it will be interesting to see where they end up as they go that way.

May is just around the corner and Smalltalk Solutions will soon be here. Remember to sign up before April 3rd to receive the early registration discounts. Current STIC members receive a $75 USD discount for the conference. You can easily join STIC or renew your membership while signing up. To register visit:

http://www.smalltalksolutions.com/registration/register.htm

When you register for the conference don't forget to book your hotel. Smalltalk Solutions will take place entirely within the Crowne Plaza Seattle hotel. Make sure to mention you are attending SS 2004 in order to receive the hotel discount. More information can be found at:

http://www.smalltalksolutions.com/hotel/hotel.htm

Keep your Tuesday night open while in Seattle because STIC has planned a fun-filled night at the world famous Seattle Space Needle for conference attendees. We have reserved a banquet room high above the Seattle skyline for you to enjoy. Hors d'oeuvres and drinks will be served starting at 6:30 followed by a delicious dinner and entertainment later in the evening.

This year's Smalltalk Solutions looks like it will be a blast and I look forward to seeing you all.

Thanks, from the STIC team

Register for StS 2004 and hear Bob nemec talk about custom reporting solutions:

Visibility based Report Framework
presentation
Bob Nemec: Northwater Objects
Monday 9:15:00 am to 10:00:00 am

Abstract: Northwater Objects has implemented a custom report writing framework based on Totally Object's "Visibility" product. The framework is built with logical, data, output and print layers. "Logical" is the report specification; 'data" is the specification combined with the domain data; "output" is the data combined with the layout and "physical" is the collection of visibility print command objects. We have also written a user interface for report configuration and diagnostics.

Having the entire report writing mechanism in Smalltalk has proven to be a huge benefit. Our previous experiences with Access and Crystal Reports, while functional, were much more labour intensive and error prone.

The application is written in VisualAge Smalltalk with WindowBuilder and GemStone/S.

Bio: Bob Nemec, Vice-president of Northwater Objects, is responsible for the framework development of an in-house financial application, written in VisualAge Smalltalk and GemStone/S

See you in Seattle!

I've posted quite a bit on why I think Smalltalk is more powerful than many of the competing solutions - now I'm going to toss a few numbers around. One of the fascinating things about the software field is the relative dearth of hard data. Even when there is data, however, many people are more than happy to rationalize that data away. Take this post from 2002, for instance - I can paraphrase the analyst viewpoint this way:

Never mind the fact that our research says that following the mainstream of development will yield dramatically higher failure rates. Being mainstream is all that matters!

The amazing thing is that companies pay huge sums of cash to have unqualified people advise them that way. It's hardly limited to analysts though. Ask a developer how hard it is to learn a new language (software language, that is). I've yet to find one that will say it's a significant hurdle. Now, go recommend to a development manager that project X should use Smalltalk (or some other niche language, for that matter). Suddenly the eyes glaze over - "but where will I find staff?" Never mind that his entire existing staff will tell him that learning a new development language is not a real problem.

But wait - it all extends down to developers as well. I've been pointing to this post (which has been updated here in the past couple of days). "Source code not in a directory tree? Syntax that doesn't look just like C? Heresy!". There are plenty of developers that are stopped cold if the syntax isn't sufficiently C-like, or if they have to do anything differently than the way things have "always been done" (I seem to recall the old auto industry being run clean over by overseas competition - partly as a result of hidebound practices. But nah, that would never happen in software - offshoring's a myth, right?). Well, even actual data doesn't get through the wall of rationalization.

SPR still has the data compiled by Capers Jones on language levels, error rates, and lines of code per function point. The data is instructive, if a little dated (1999). C# wasn't out then, but - I would have to place C# within the same basket as Java. Here's the relevant snippets from their data:

Language	Language Level	Lines of code per Function Point
C	2.5	128
C++	6.0	53
Java (C#)	6.0	53
Smalltalk	15.0	21

Ponder that for a moment (Function Points are defined here). With a little arithmetic, you find that Smalltalk is nearly 2.5 times as productive as Java. You'll immediately run across two objections to this (try making these points in comp.object to see what I mean):

• Function Points are meaningless
• You'll get more errors in Smalltalk due to the lack of manifest (declared) typing

Well, the first point is nothing but a rejection of the data by assertion. This is research that was done over the course of many years; if people want to object to it, they can point to conflicting research. I've yet to see any such argument being made. The second point is commonly made against Smalltalk (and other dynamic languages). However, there are some other bits of research from the SPR documents in this area - it turns out that they measured error rates per function point:

Language	Error rates per FP
Java (C#)	0.5
Smalltalk	0.13

So much for that. The arguments you'll hear at this point hold as much weight as those against Function Point measurement - the assertion will be made that it's all irrelevant, without any attempt to point to research that shows otherwise.

The bottom line is, this is the data we have, and it points in a particular direction. Do analysts pay it any heed? No, the best they can do is count the number of developers and declare winners (they seem to think that this is all Nielson ratings). Project Managers? No, they quiver in fear of finding developers (regardless of what real developers would tell them about ease of learning). Developers? No, they have a magic faith in C style syntax and declared types (It's what we've always done, don't bother us, we refuse to look at contradictory data). This is a large part of the reason that I run this block - it's an uphill battle, but I have to keep pushing the rock up the blasted hill :)

We are releasing a new set of VM's for VW 5i.4, with a number of fixes. Here are the details:

VW 5i.4x Engine Updates

As of March 2004, these 5i.4c engines are the most up-to-date engines for VisualWorks® 5i.x images. See http://www.cincomsmalltalk.com/CincomSmalltalkWiki/VisualWorks 5i.4c engines.

Bugs Fixed over 5i.4b:

• On all platforms, several primitives that had incorrect argument counts have been fixed. These incorrect argument counts could have caused crashes when primitives failed (but only when they failed).
• On all platforms, the oldSpace allocator now uses a sane approach to calculating the free-list probe count. This should improve image-level MemoryPolicy behavior.
• On all platforms, a bug was fixed that caused a crash when using the TimeProfiler due to incorrect stack management in primitive Context>>#terminateTo:.
• On all platforms, a bug was fixed that caused a crash in the debug and assert engines when using the check-mark mechanism to verify the incremental collector when running with -o11s (aggressive assert checking).
• On IA-32 platforms (Windows® and Linux86), these engines fix a performance problem with floating-point primitives on dual Xeon processors. Floating-point performance is about 4.8x faster.
• On UNIX® platforms, signal handlers now use significantly less stack space.
• On the SGI® platform, "dirty sends" have been enabled, improving Smalltalk execution performance by about 5%.
• On the Windows platform, a bug was fixed that caused attempts to open files larger than 4 Gigabytes in read-append mode to not seek to the end.
• On the AIX® platform, the translated floating-point primitives have been implemented providing almost a factor of two improvements in floating-point performance.

Bugs Fixed in 5i.4b and 5i.4c Over 5i.4:

• On all platforms, a bug was fixed in the \\ primitive.
• On all platforms, a bug was fixed in context management during non-local returns that would occasionally cause crashes.
• On all platforms, a bug was fixed in the code generator that caused | i | i := 2. ^3 between: i and: (i := 4) to return false.
• On all platforms, a bug was fixed whereby doesNotUnderstand: method lookups were not being flushed when requested.
• On all platforms, a bug was fixed in the translated floating-point primitives whereby aFloat op anInteger would return different results to aFloat op (anInteger asFloat).
• On all platforms, a bug was fixed that accused the snapshot primitive to incorrectly save the free list, causing a crash on image load.
• On all platforms, a bug was fixed that would cause a remembered-table overflow on loading a perm-saved image, causing the image load to abort.
• On all platforms, a bug was fixed whereby code referencing new literals might not be correctly scavenged, causing a crash.

On all platforms, a bug was fixed whereby shrinking oldSpace could corrupt the list of oldSpace segments, causing a crash. On all platforms, long-long access primitives were added, improving the performance of [unsigned]LongLongAt:[put:].

• On UNIX platforms, a bug was fixed whereby attempts to list the contents of directories mounted over nfs would return an invalid list of files.
• On X11 platforms, a bug with fetching and storing the text selection was fixed.
• On Windows platforms, the priority of the IO poll thread was corrected.
• On Windows platforms, bugs with zlib decompression of images were fixed.
• On Windows platforms, bugs with 64-bit file access were fixed.

Customers with support should already have received an email to this effect, but I know how many spam filters kill automated emails (even those that are actively being subscribed to).

In my last post on this topic, I alluded to the rise of offshoring, and how it sounds an awful lot like an echo of what happened to manufacturing years ago. Now I see that Dan Gillmor of ComputerWorld is writing about that topic:

I never entirely bought their faith, though the Valley has repeatedly shown an ability to rebound to new heights after deep economic downturns. The recent evidence, notably the surge of offshoring, makes me ask again -- about the Valley and the entire nation.

And I wonder if something is genuinely different now.

Intel CEO Craig Barrett put his finger on it a few weeks ago when he stopped by my newspaper for a long chat with some reporters and editors. What's new this time, he told us in a persuasive way, is the nature of the global workforce.

For the first time in human history, Barrett said, a truly gigantic pool of well-educated, technically adept and eager-to-please labor is being created. This pool of talent, which will include hundreds of millions of people in China and India (many of whom speak English fluently), has another characteristic: a willingness to work for a fraction of what Americans expect.

This is not because they like living poorly. It's because local conditions and currency exchange rates make what would seem like a pauper's salary here a highly attractive one there.

Well, this can go one a few different ways. American development shops can keep doing what lots of developers think is "good enough" - unproductive languages that hinder more than they help (Java, C#, etc). Code in files, and the old "edit-compile-link" cycle. If that's the way people go, then they will be screwed - overseas competitors can use unproductive tools and heavyweight processes (CMM-5, anyone?) at a fraction of the cost. The results won't actually be any better, but boy, will they be cheaper. And since the level of competence in IT is so low now (just go look for IT project failure rates; the numbers are not improving), getting the same crappy results for a lesser dollar amount will be seen as huge progress

Now, what have people done in the past to overcome this kind of thing? They've gotten more agile (like some of the newer steel companies in the US). Now look at software shops - asleep at the switch, using unproductive tools and languages - and they act utterly astonished when jobs get moved overseas. Is there any awareness of the higher levels of productivity available from agile processes (see the Agile Alliance site) and dynamic languages (see the numbers I posted here? Heck no, there's a dogged insistence that all is well, and that doing the same old things in the same old ways will be just fine. Never mind that offshore developers can do those same old things at a fraction of the cost - apparently, Alfred E Newman is alive and well, and living in most US development shops

If you want to keep working in this field, you're going to have to take a hard look at what happened to auto (and other manufacturing) jobs in the last 30 years, and at what kinds of changes had to be made to keep US shops competitive. Here's a hint - it didn't involve doing the same old things in the same old ways. It's well past time for developers to look for more productive ways to work - both in the process area (agile) and in the language/tools area (dynamic vs. static). I think Gillmor is more pessimistic than he needs to be - but there will be a large jolt in this sector, and everyone who is cheerfully wedded to the mainstream is in for the biggest set of shocks....

For those of you with rather large hard drives, this is a use for XML I bet you hadn't considered:

I saw an article on TSS labeled "Thread dumps as XML," and thought to myself, why couldn't byte code be done as XML? So I built a custom JVM and converted rt.jar to my new XML byte code format. Now, this might seem an impossible undertaking, but fortunately I had some extra hard drive space. My new rt.jar is 620GB, but the class files are all human-readable now, and it's really nice to be able to edit them in Notepad

I don't know whether to be impressed or scared :)

Register for StS 2004 so that you don't miss Michael Lucas-Smith present withStyle:

Smalltalk WithStyle
presentation
Michael Lucas-Smith: Wizard Information Services
Monday 2:00:00 pm to 2:45:00 pm

Abstract: Recent years have seen many software development projects moving away from desktop clients to Web Applications. Unfortunately, whilst today's Web Applications offer some benefits (particularly for implementors), they constitute a significant step backward for users. Usability and productivity suffer as user interfaces are 'dumbed-down' to fit a request-response model reminiscent of green-screen terminals. The IT industry has again manufactured new limitations that need not exist.

With:Style WebUI is a 100% Smalltalk user interface technology that frees user interfaces from the limitation of Web Browsers that were not designed to meet the UI requirements of business applications. The quality rendering capabilities of the With:Style technology prove the strength of Smalltalk as a first-class user interface platform that need not be fragmented and tied to Java or Windows-specific front-end technologies.

As a customisable XML presentation technology, With:Style offers many deployment models and even more possibilities for rich, 'hybrid' user interfaces through integration with Pollock. It fits in naturally with server-side Web applications and emerging Service Oriented Architectures. Demonstrations will include XML Editing and Scripting client-side behaviour with Smalltalk.

Bio: Michael Lucas-Smith currently works at Wizard Information Services as the head of Research and Development. While at Wizard he has worked on Smalltalk business applications ranging from an Audio/Visual Archiving system to web content management software.

He has been involved with computers since age 4 and first came in contact with the concept of "Online" when he ran a BBS from his bedroom in high school. His software interests range from Commodore64 assembler through to modern business applications.

He has spent the last four years using VisualAge and the last two using VisualWorks. Michael is a co-author (with David Murphy) of the TypeLess irc client written in VisualWorks, has helped with James Robertson's Bottom Feeder and has contributed goodies such as StackOverflow and ThreePaneSelectorsBrowser.

Michael has recently started Software WithStyle with three other partners to pursue the WithStyle WebUI technology, a Web-based User Interface thin-client using XML.

See you in Seattle!

Many C level managers have an almost magical faith in the ability to take projects offshore. The amusing thing is how many of the same managers distrust telecommuting. The issues for the two are very similar, although offshoring typically adds greater distance and cultural issues into the mix. I ran across an interesting case study in the Wall Street Journal on this - the summary is copied below:

ValiCert expected to save millions annually while cranking out new software for banks, insurers and government agencies. Senior Vice President David Jevans recalls optimistic predictions that the company would "cut the budget by half here and hire twice as many people there." Colleagues would swap work across the globe every 12 hours, helping ValiCert "put more people on it and get it done sooner," he says.

The reality was different. The Indian engineers, who knew little about ValiCert's software or how it was used, omitted features Americans considered intuitive. U.S. programmers, accustomed to quick chats over cubicle walls, spent months writing detailed instructions for overseas assignments, delaying new products. Fear and distrust thrived as ValiCert's finances deteriorated, and co-workers, 14 times zones apart, traded curt e-mails. In the fall of 2002, executives brought back to the U.S. a key project that had been assigned to India, irritating some Indian employees.

"At times, we were thinking, 'What have we done here?' " recalls John Vigouroux, who joined ValiCert in July 2002 and became chief executive three months later.

Shifting work to India eventually did help cut ValiCert's engineering costs by two-thirds, keeping the company and its major products alive -- and saving 65 positions which remained in the U.S. But not before ValiCert experienced a harrowing period of instability and doubt, and only after its executives significantly refined the company's global division of labor.

That last paragraph is the instructive part - eventually, they saved money. It required a lot of learning about what worked, what didn't, and a lot of uncertainty (and near disaster) in between. What does that mean? It means that offshoring work is not to be taken lightly - you have to look at as a project that is on a scale with installing a corporate wide ERP system. It's going to require changes in internal culture and processes. Consider how many ERP projects founder on those shoals, and you'll start to see why so many offshoring projects run into problems - changing culture and processes immediately gets into internal politics. Many people will fight against the changes based solely on inertia. In fact, if you know that large scale change like this is unlikely to work at your firm, then offshoring is likely going to be a very, very dicey proposition. If you have trouble with internal communications, sending work 12 hours away is only going to make things worse.

Bottom line - it's not that offshoring can't work (clearly, there are firms that make it work, just as there are firms that make telecommuting work). It's a big change though, and something that should get looked at seriously, rather than the almost offhanded "lets save a bunch of money" kind of thinking that seems to be all too common

For the most part, I like Eudora - it has a decent interface for setting up filters and is generally a nice email client. Today I ran across a limitation that ticked me off though. I get cc'd on all the mails from the NC download application - it's a useful backup of the information entered, especially if people don't receive the emails (likely do to spam blocks). I've never deleted or archived mail from that folder, and that got me into trouble today. I clocked over 32K messages in that folder at some point today, and Eudora crashed. That's always an irritation, as I get everything back in my inbox since the last mailbox compaction. However, it was worse today - everytime a new mail for that folder came in, Eudora would get baffled, and eventually crash. This got tiresome in a hurry. Eventually, I ended up having to open the blasted folder file in an editor and trim off old messages by hand, and then let Eudora rebuild the table of contents on startup. Yeah, I know that 32K messages is a lot. On the other hand, I was keeping them easily accessible for a reason. Why should there be a limit like that? Here's another place that static typing is "helping" me. Someone at Qualcomm decided that a specific size integer was all "anyone would ever need". Sigh...

Tim Bray has more on the MS funding SCO thing:

Business Week says that Microsoft did lead the Venture Cap horse to the SCO trough. I tend to trust Business Week. Uh, would Martin Taylor like to clarify his statement that the allegations "are not accurate"?

Back to Scoble :)

Based on this post by Dare Obsanjo, it looks like 'Generics' means one thing in C++, and something else in C# and Java:

Although Bruce didn't confirm whether the above limitation exist in the C# implementation of generics he is right that they have the same limitations as Java generics. The article An Introduction to C# Generics on MSDN describes the same limitations Bruce encountered with Java generics and shows how to work around them using constraints as Bruce discovered. If you read the problem statement described in the article on MSDN it seems the main goal of C# generics is to solve the casting problem in containers

Yet another case of developers being separated by terms used in variant fashions. Dare has a lot more than that paragraph; go read the whole thing

I just noticed Glenn Vanderburg's blog via the referers list on my site. He's writing some good stuff; subscribe here. I particularly like this post :)

If the rants here aren't enough for you, then visit the BileBlog. I really like this post on how insignificant we (developers) really are :)

Neither Scoble nor MS get it

So, if you want us to ship more often, you are asking us to ship lower-quality stuff. It's just human. There's only so much testing one human can do in a day (and, keep in mind that even though we have tons of computers running tests 24-hours-a-day a human still needs to fix the problems found). There's only so much testing that can be done. Only so many bugs that can be fixed in a day.

Hmm. Maybe if your teams didn't come up with (insert grandiose plan here) tasks that will:

• Take years to implement
• Be outmoded by the time they ship

You wouldn't have this problem. Here's a tip - go tell your project teams to start shipping every 6-9 months. Have them lay out long range plans, sure - but the teams will have to come up with actual deliverables that can be shipped in a short time frame. It will likely take a couple of cycles for them to figure this out, but they'll get it. You know what will happen? You'll deliver incremental progress to customers on a regular basis - and you'll have a chance to do course correction every few months

What do you have now? You have (insert huge monolithic plan here) a large set of work that will take years to complete (witness Longhorn). How do you course correct a 5 year plan (hint - it didn't work so well for the Soviets). It's time for your teams to get more agile, and ship more frequently. Your customers will see progress, and your marketers will get actual feedback as to whether you are headed in the right direction.

As to quality? I rather suspect that delivering incrementally and more frequently will improve that far, far more than what you are doing now...

Brian Marick defends the use of text files (as opposed to what most Smalltalks do):

Very tangentially, I'm reminded of those who claim that the failure of Lisp and Smalltalk was partly due to their being hermetic - taking all data on their own terms, not the world's. They failed to embrace the string and the regular expression.

Failed to embrace the string? What the heck does that mean? The regular expression? What, you would rather grep for text than uses senders/implementors? This is what I love about the complacent curly brace crowd - the sharp sticks and pointy rocks make them so happy :) But wait - there are wild assertions ahead!

(Not just to pick on Lisp and Smalltalk, two fine languages: how long did it take for a regex class to make it into Java? And a regex class is one significant affordance notch below regexps built into the language.)

All I can say to that is huh? Please explain how having regexp built into the language - i.e., inextensible - is better than having a regexp library which I can extend and modify? This just makes no sense...

Markus Kohler points out that SOAP is still less functional than CORBA, and slower to boot. I'm wondering what nifty RPC interop mechanism will be all the rage in 3-5 years instead of SOAP - maybe Markus already has the answer to that

Register now for StS 2004 so that you can hear James Foster on making apps test friendly:

Building a 'Test-Friendly' Application
presentation
James Foster
Monday 2:00:00 pm to 2:45:00 pm

Abstract: Your manager has just seen a demo of a popular automated testing tool, and decided it will solve your quality problems. The tool records a user's interaction with your application and then plays back those interactions so that applications "work flawlessly the first time and remain reliable." Of course, the devil is in the details, and you've been assigned to deal with the details. What happens next? In this experience report you will see how a Smalltalk application was modified so that the automated tests worked when a window has hundreds of widgets, many with the same label. Find out why the flexibility of Smalltalk prompted a WinRunner consultant to say that this was what he wished all development environments could do.

Bio: James Foster learned FORTRAN in 1971, Smalltalk in 1993, and a few other languages in between. He has been developing healthcare systems since 1987 and is presently Software Architect with BulldogIT. He has presented at prior Smalltalk Solutions and at OOPSLA conferences.

See you in Seattle!

I wrote about release cycles yesterday, and I thought I'd expand on the thought a little. As I said yesterday, I value "release early, release often" quite highly. To my mind, having a short release cycle improves quality quite a bit - and I think the proof is in the pudding (VW 5i.3 through the present have been on short cycles). There's a constant tension in this between Product Management, Engineering, and some customers though:

• Some projects cannot be done in a short (6-9 month, in our case) cycle. Pollock, for instance
• Some engineers want to extend the release cycle in order to get a long project done within a cycle
• Some customers object to short cycles, as they cannot possibly update to new releases given technical and political constraints in their shops

To my mind, all of these are

• Outweighed by the benefits of a short cycle
• Fairly easy to address

Ok, so how do you address them? Let's take them one at a time:

Long term projects
There are projects that will span multiple release sycles. Some will span multiple cycles while they are under initial development, and some will have only a partial implementation when they first hit the street. Pollock is an example of the former; the Web Toolkit is an example of the latter. Pollock has been an ongoing project for us for a very long time now. The engingineering team working on it has pushed early releases of it out in a pre-beta form over the last few cycles, and has made ongoing versions accessible to the vw-dev team. I think this has worked out well for us.

How so? Well, even though it's taken a number of cycles to get to the point it's at, it's been available for comment for quite awhile. There have been some very lively design discussions on the Smalltalk IRC channel - and some very good ones on our developer mailing lists. Pollock has been developed "in the open", across multiple short cycles. I think it's an example of how long term development is not only possible, but works very well in this scenario. The multiple cycles over the life of the project have also afforded us a lot of opportunities for course correction and adjustment - something I simply have not seen happen over long cycles (The development of ObjectLens for VW 2.0 being perhaps the best example in my memory).

What about Web Toolkit? It came out for VW5i.4 - with some limitations and issues, but in a usable form. People - myself included - started using to build web applications, and the development team was able to see what kinds of things were actually important to end users - as opposed to what they might have thought would be important. Development has continued across VW 7, 7.1, and 7.2 - with quality improving at every step, and course corrections possible at every step.

I think these two projects illustrate how long term development is not only feasible within the context of short release cycles - properly planned, it can actually improve things. The issue with a long cycle is that developers tend to "hunker down" and build to their original design - without much feedback from the outside world. Shorter cycles force that feedback. Sure, one could posit a long cycle with feedback - but in my experience, it just doesn't work out that way. Long cycles encourage a "specs over the wall, product back from the wall much later" approach. That's an approach no one's happy with, except for the insular engineer who doesn't actually see that as a problem :)

Engineers who want a longer cycle to "just get it done"
I think this one is easy to push aside simply based on the entire history of softeware development projects. Extending the time doesn't help. Why? Software developers are notoriously bad at estimation. Give them 2 years, and they'll see an endless expanse of time, and shoot for the stars. Give them 6 months and they'll still aim too high - but it will be obvious a whole lot sooner. Engineers are also no better than anyone else at visualizing what the marketplace will look like in 2 year's time - and giving them a long cycle to develop "the next big thing" will likely result in "the last big thing". Everyone needs check points - if you don't have time for course correction, you'll wander down a lot of ratholes. With short cycles, you'll still wander down a few - but at least it'll be for less time, less money, and with more of an opportunity to see the mistake early. Go pick up any number of trade journals and you'll see stories on projects that were disasters simply due to delivery past the point of impact

Customers and their ability to keep up
This is the most serious one - because now we are talking about the people who pay our salaries :) Short cycles do make it harder to keep up, even if each incremental update is "painless" (and they won't be). In the end, it doesn't matter though. Why? Well, most customers will only be ready to update when they have a large milestone on their own projects. At that point, they can take what you have and migrate to it. That may be at 12 month, 18 month, or even longer intervals. But so what? If you had a longer cycle, there's no better chance that yours will align with theirs anyway - and that might mean 3, 4 (or even more) years between upgrades. That's going to be much harder for them to deal with (and believe me, I have experience with this). Counter-Intuitively, a short cycle actually makes it easier for customers to keep up.

As they hit a milestone, it's likely that you shipped some incremental release recently - so they can move up to that. Moving to something that's seen 18-24 months of churn is going to be easier than moving to something that's seen 24-48 months of churn. It turns out that short cycles do a better job of keeping customers on something current - long cycles make the eventual upgrade look very scary, and keeps a fair number of your customers on ancient back releases. An incremental cycle has a far better chance of minimizing that risk.

Ultimately, I believe that shorter cycles are better for engineering, better for your product's quality - and most importantly - better for your customers.

According to Sun, it's not good enough. Researchers are looking for more dynamism. The failure rate for Java projects is still atrocious. Sun's researchers don't believe in the language. C# is a sideways step to the same place.... heck, we even have hard data on some of this. And yet, many analysts will still tell you that you should stay in the "mainstream" - apparently, failure is better than unpopularity if you're an analyst (I guess it's still high school prom time for them).

And developers wonder why outsourcing and offshoring are popular....

Now this is an interesting thing - MS' HR department has a blog, complete with an RSS feed. Sort of makes the MS doesn't get RSS comments by Sun's Jonathan Schwartz look even stupider...

In response to this post, I got a question about release cycles and their relationship to product pricing. That's a great question, and it allows me to expand on something that confuses a lot of people - the pricing model we use for Cincom Smalltalk. Let me talk about our pricing model first, and - in the process of doing that - I think I'll be able to address the release cycle/pricing thing

First off, I'm going to say something that a lot of you are going to question at first:

We don't sell development tools

That's right campers, we don't sell development tools. We sell a platform on which you can develop and deploy applications. Think about it - you develop and deploy on the same system - it's a platform (like J2EE or .NET) as opposed to a development tool (like Eclipse or VisualStudio).

Now, with that small bit of explanation out of the way, let me switch gears to pricing. We have a small number of pricing plans:

• End user based (for internal, client/server applications)
• Server based
• VAR (for resellers)

We offer these on an annual subscription basis. In most cases, the number of developers are unlimited - which goes along with the idea that we aren't selling development tools - we don't price on the basis of developers, we price on the basis of platform usage. Now, how does any of that relate back to the release cycle? Well, if we are going to sell on an annual subscription basis, there had darn well better be some value. That's a large part of why we have short release cycles - it's a way of demonstrating value for the annual subscription. We not only give full support, but - during the span of a subscription, our customers get each and every release we put out. That's value back to them in a few ways:

• New features on a regular basis
• Incremental, hopefully easier to update to releases
• Concrete evidence of progress

That last one is perhaps the most important one for many people - they want (and need) assurance that their investment in our product is safe. With any commercial venture, the proof is in the pudding - all the words in the world from me (or anyone else) are just that - words. Steady, ongoing releases, on the other hand - that's everyday proof of stability and commitment.

Dan Fernandez writes about early access to the (due in 2005!) next release of VisualStudio. Simply having these thoughts at all should push you towards a shorter release cycle, IMHO:

Does Microsoft Give Access too Early?
After reading these posts on Whidbey and in thinking about the backlash on Longhorn (too much info too early), it occured to me that maybe its not such a good idea to give the broad developer community early access to code. I'm not saying this because we don't value everyone's opinion, but because it might be dangerous to set such high expectations.  What happens when you see a great feature and you see that it won't be available until the next release?  Some features you like may or may not make Whidbey, it's a technical preview, we really cannot give any guarantee as to what the final product will look like.  As Jay points out, we're even starting to give developers interim builds in a continuous effort to make Microsoft more open to developers.  I would assume this would be a good thing, but there is risk in this approach. The risk is that we over-promise and under-deliver which leads to developers being angry, which is the exact opposite of what we're trying to achieve.

Well, if you release every 6 to 9 months, that ceases to be a problem. We have given developers access to our ongoing builds for quite awhile now - and I'd have to say that it's been overwhelmingly positive - we get bug reports, bug fixes (admittedly, this is easier for us - a Smalltalk system ships with all sources), and we set expectations very concretely - over time, developers have gained a feel for what we can and can't do within one cycle, and they evaluate the builds based on that. It's interesting to see just how many negatives start to flow from having an extended release cycle...

Register now so you can hear Michael Lucas-Smith talk about using XML with Smalltalk. This is a not to be missed talk; Michael's been doing some very cool work with both VisualWorks and VisualAge.

Smalltalk, XML on the Web presentation
Michael Lucas-Smith: Wizard Information Services
Monday 2:45:00 pm to 3:30:00 pm

Abstract: Although much XML-related work is being pursued in the systems integration and Web Services arenas, the way in which Object Oriented software can benefit from an XML Architecture at a more fundamental level has been largely overlooked. Software Architectures can benefit greatly from the unity and flexibility of a loosely-coupled XML-on-HTTP model that talks to Web Applications and Web Services natively. This experience report discusses how Wizard Information Services is adapting it's core applications architecture to be XML-based whilst taking full advantage of Smalltalk and its Object Oriented paradigm.

Wizard has taken business objects stored in a relational database and opened them up to the XML world by adding an XML server built on VisualAge's Server Smalltalk technology. Internal SOAP transactions are transparent to clients that may choose a simple HTTP access method. A powerful XML transaction infrastructure can then be built using the Apache Group's Cocoon XML publishing server on top of a Smalltalk server writing XSLT to process XML updates. This experience has provided some insight into the effectiveness of SOAP for running services in a Smalltalk image.

Bio: Michael Lucas-Smith currently works at Wizard Information Services as the head of Research and Development. While at Wizard he has worked on Smalltalk business applications ranging from an Audio/Visual Archiving system to web content management software.

He has been involved with computers since age 4 and first came in contact with the concept of "Online" when he ran a BBS from his bedroom in high school. His software interests range from Commodore64 assembler through to modern business applications.

He has spent the last four years using VisualAge and the last two using VisualWorks. Michael is a co-author (with David Murphy) of the TypeLess irc client written in VisualWorks, has helped with James Robertson's Bottom Feeder and has contributed goodies such as StackOverflow and ThreePaneSelectorsBrowser.

Michael has recently started Software WithStyle with three other partners to pursue the WithStyle WebUI technology, a Web-based User Interface thin-client using XML.

See you in Seattle!

The NYSTUG has a fascinating meeting coming up - a fifth grade teacher in New York is going to talk about how he uses Squeak (EToys) to teach programming at the elementary level:

Please join us for our next meeting to be held Wed March 31st

Presenter's Bio:
Seth Orbach is Director of Academic Technology at St. Bernard's School in New York City. He has a B.A. in Architecture from Yale College and a M.A. in Mathematics Education from Teachers College, Columbia University. He first began teaching Squeak to fifth graders at Trevor Day School several years ago after hearing Alan Kay speak at the NYSAIS Conference on Information Technology in November of 2001.

Presentation Abstract:
"E-Toys is a version of Squeak designed for use with school-aged children. I will present some of the introductory lessons that I use with students, some of the more advanced challenges, and examples of student work from my 3 years of teaching with this tool. I will also discuss and demonstrate the pedagogy used in my constructivist classrooms."

Details:

Date:	March 31st, 2004
Location:	Suite LLC offices
Address	440 9th Avenue, 8th Floor
Time:	6:30pm to 7:00pm -- Open house
Time:	7:00to 8:30 pm -- Squeak in NYC presentation.

Directions:
Take E or C train to 34th (Penn Station) walk to corner of 34th and 8th. Walk up one block to 9th.

RSVP is requested. Please send mail to: charles@ocit.com with subject line of: NYC Smalltalk March 31st 2004. Our meetings are opened to the general public. Invite a friend ! To join our mailing list simply send mail to nycsmalltalk-subscribe@yahoogroups.com

Joining our list will give members access to all of the presentations and articles maintained on our site.

Sounds interesting - check it out

Register now so that you can hear all about Cross Dialect Smalltalk Portability at this year's Smalltalk Solutions:

Dialect Portability
presentation
Giorgio Ferraris: Elevensoft
Monday 2:45:00 pm to 3:30:00 pm

Abstract: This talk describes work on creating a dialect portability layer. This more than just translating syntax between dialects, but also having a base of services in different areas such as GUI, Compiler, and file handling.

Bio: Giorgio Ferraris is a chemical engineer totally devoted to software. After years of work as a software free-lance consultant he co-founded, 15 years ago, Eleven srl, a small (20 people) Italian firm developing turn-key software solutions.

He started using Smalltalk more than 15 year ago (Smalltalk/V). He began following the international community first using Compuserve and the Digitalk forum, then participating in Smalltalk and OO related user conferences, starting from the Digitalk one, to SmalltalkSolution and OOPSLA.

He has been involved on OO analysis, design and architecture definition for 10's of customers (from small to medium to large). He follows his company's internal projects like lead technical mentor.

He has held several tutorials on OO, Smalltalk, OO analysis and design for 100's of Italian people and has worked as a mentor and supervisor on several OO projects. He is currently working as a mentor on several OO projects in Italy (Smalltalk, Java and C#), and helping a big italian customer on migrating to Smalltalk.

See you in Seattle!

I've been watching Stargate SG-1 for quite awhile now - I think it's the best Sci-Fi show on TV now. Sure, there are a few issues - the expeditionary teams are too small (4 people) and the wrong service (they play Air Force, they should be Marines). Those are nits though; the team size is a compromise to allow for character development. What's good about the show is the writing - contrasting it with Star Trek: Enterprise is particularly bad - for Star Trek

What do I mean by that? Well, there's always "and then a miracle occurs" moment on Star Trek - one where some seemingly unsolvable conflict is solved, typically without force. I fully expect last week's cliff hanger to end the same way, without any difficult choices having to be made. Stargate, on the other hand, does confront the characters with crappy choices and "least bad" alternatives (look at how they ended the replicator threat, for instance - no "everyone ends up happy" outcome there)

I'm wondering how things are going to progress this year - they have done a couple of things that offer some interesting possibilities, but also some areas that could be hard to deal with:

• The Stargate program has been revealed to other major nations (last year)
• There's just been a change in administrations in the series world, with their political opponent Kinsey becoming the new VP
• It looks like next week's episode will make the existence of the Goauld public (world-wide) knowledge

I'm very curious to see how well they deal with that - it's a big change in the dynamics of the series. For the most part, I'm happy with changes in that direction; I think X-Files washed all the interest (at least for me) out of the "evil government conspiracy" back story. I guess we'll have to see how it develops - but I'm interested in seeing how it does. With Enterprise, I tend to miss shows, and just not care a lot...

Artima has an interview with Bertrand Meyer where he goes into exception handling. Meyer, for all his erudition, seems to have no real familiarity with dynamic languages (Smalltalk, Lisp, Ruby, Python, etc):

The exception mechanism in Eiffel is quite different from those that exist in other languages, and it surprises many people. When you have an exception in Eiffel, you only have two ways of reacting to it. The reason that you only have two ways is that exceptions are something that you don't want to see happening. So it's quite different from the approach that says exceptions are special cases that we are going to expect and process in a special way. In Eiffel, exceptions are really a sign that something quite wrong has happened, so you have only these two ways of reacting. One is to accept that you can not do anything better, and to just pass on the problem up to the next routine up the call chain, which of course will be faced with the same dilemma. That is often, especially for operations deep down in the call chain, the only real world reaction, because the operation does not have enough context to do anything smarter. The other reaction is, if you actually do have some elements that enable you to think you're smarter, to attempt to fix the condition that led to the exception and try the same operation again after correcting the context. This is the kind of mechanism that provides direct support for what I was calling software fault tolerance, and I think it can be quite effective provided it's used with reason, that is to say, not as another algorithmic mechanism, but as a mechanism of last resort

Somehow, I doubt any Smalltalkers are surprised (we have a fairly rich exception framework, and one I take good advantage of in BottomFeeder). I guess Meyer's world view goes as far as the C language family and Eiffel - and no further....

There's a new language that's gotten some press - Scala. Sounds like an interesting merger of OO and functional languages...