Smalltalk Tidbits, Industry Rants

The 3.4 release of BottomFeeder is fast approaching. There have been a lot of nice improvements and bug fixes; the UI is much cleaner now. The documentation for 3.4is almostready (Thanks Rich!). Expect a push around the end of the month or the beginning of March. Here's what's changed:

• Simplified the user interface - all the view modes are available via toolbar buttons or the menu. Feed icons are moved to properties, and the wasted space at the top of the UI is gone
• Downloading upgrades has been made safer via a validity check
• Added support for some Atom components in RSS 2.0 feeds as modules
• Added Search feeds - synthetic feeds made up of items searched from what has been downloaded into BottomFeeder
• Added a Google Feed builder, akin to the Feedster feed builder
• Feeds which are parsed with errors will be flagged as such so that end users who wish to notify the producer can do so. For the same purpose, there is an interface to the feed validator at http://www.feedvalidator.org
• Added a News Ticker that can be used instead of the 'slim mode' interface.
• Modified the application so that all user interface elements respect the text settings of the user.
• There's a menu option that can stop an in-process update cycle without taking BottomFeeder offline. Previously, you would have to take the application offline
• There is now a Mac OSX installation that installs properly
• Fixed a bug that prevented proper startup after an abnormal quit
• Added more information to the upgrade screen for the user (sizes and descriptions of the change). Also modified the properties to disallow save on a bad download, and to disallow loading without a restart if that would be inadvisable (in the case of UI changes, for instance).
• Browsing options could have different behavor depending on how the option was selected; this has been cleaned up and unified

I'm on my way back home from dallas as I write this. I've just spent 4 days visiting cuctomers - seeing the great apps they've built with our products, shwoing them what's coming down the pike, and listening to their questions and concerns about the products. There's really no substitute for getting out and hearing the customers speak. In that vein, I'd like to pose a question to our users - what are we doing right? More importantly, what are we doing wrong, or not doing well enough? What issues do you have with VisualWorks or ObjectStudio that - to your way of thinking - should be addresses asap?

Either post answers here via comments, or send me an email. Thanks!

Joel Spolsky let slip something that I'm pretty sure he hasn't thought through:

On Lisp: And I have the ultimate respect for Paul Graham -- I think there's a good probability that in a year or two we will credit him with being the man who solved spam. But I think that if you try to ignore the fact that millions of programmers around the world have learned lisp and don't prefer to use it, you're in the land of morbid cognitive dissonance.

That sounds reasonable... but I don't think he (or many other people in the tech world) like that line of reasoning at all when it extends to the political. Think about it - Joel's argument is "The majority is always right". Well. If that's the case, abolish the courts now, and let's just do referendums for everything. What's that? You don't think that the majority is always right?

If not, then why is a majority of developers always right? Do they have some "special knowledge" that the general public lacks? Somehow, I don't think so...

And obtw - I'm not sure that you could make the claim that "millions" of developers have tried out Lisp, or Smalltalk (insert niche language here). More likely it's in the tens or hundreds of thousands - at best

I've been thinking about this post by Joel Spolsky again - I posted on it last night before I went to bed, but I didn't really go into the topic that deeply. Joel asserted that developers have tried Lisp (the same argument extends to Smalltalk) and rejected it in favor of things like VB, C++, C#, and Java. This is an argument I've heard many, many times. The problem is, it's completely bogus. First off, most developers haven't actually tried (insert niche system here). One of a small number objections come up, either from developers or from management:

• We won't be able to find any (blah) programmers!
• That technology is very old (never mind that the libraries are up to date)
• I would rather work in (insert mainstream language here), so that I can stay marketable

Notice how none of these are actual technical arguments. The first two would be reasonable management issues if they had validity, but they don't. First off, go find a developer. Ask them how many software development languages they know, and then ask how hard they find learning a new one. Heck, if newness alone was a barrier, then neither Java or C# ever would have taken off.

The objection is often this: "If we build a Smalltalk application, and our developers leave, what then?" Well heck, what if you build a Java application, and your developers leave? Sure, there are more people who know Java - but that's not the hard part. How many developers are you going to find who know and understand your business domain? If you had a choice between hiring:

• Someone who knows your problem domain, but doesn't know the implementation language
• Someone who knows the implementation language, but doesn't know the problem domain

Which one would you hire? The better answer would be the first person - learning the new language will take a lot less effort than learning the problem domain. Many IT managers don't actually believe that, even if they say it - that's clear from the way they hire and the way they decide on implementations and rewrites. It's equally clear that business staff (implicitly) think differently - the knowledge staff that handles business issues is typically not full of candidates for outsourcing.

Let's go back to the other part of Joel's assertion - that "millions" of developers have tried (Lisp, Smalltalk) and rejected them. That's just silly. Sun claims that there are 3 million Java developers. Most people think that VB has wider penetration, and I'd guess that C is on the order of Java. Then there are niche languages like Smalltalk and Lisp - millions of developers have tried them and rejected them? I don't know about IBM's VAST numbers, but I know that we get an average of 1000 or so people downloading VW and OST Non-Commercial per month. Even if every one of those people actually took a serious look at the products, that's in the low tens of thousands per year (and some of these are repeats - people picking up newer revs). Back in its heyday (pre-Digitalk merger), ParcPlace was a $40 million dollar firm, and I recall that we had estimates of actual end developers in the low tens of thousands. Digitalk was something like a $10 million dollar outfit, but likely had at least as many (possibly more) actual users. VAST was bigger, but not significantly so. Those numbers went down in the late nineties, and have now started to go back up again. Does that qualify as "millions" of people having tried Smalltalk and rejected it?

Like many other things, software development is a popularity contest. There is perceived safety in numbers, and the C language family has become that "safe" haven. This has nothing to do with quality or productivity - it has to do with the fact that C was a good choice for development early on (given the state of the art in processors, disk and memory) - and that advantage built up higher through inertia and the creation of a large "installed base" of people who knew the language. C , Java, and C# benefit from this familiarity, and VB benefits from the widespread early deployment of Basic on PCs and University systems.

That's not a rejection of Smalltalk or Lisp, at least not in the way Joel implied. It shows that the early "winners" in the language derby gained a large advantage in terms of mainstream adoption. It says nothing about how hard it would be to use a niche language, even though many people (especially IT project managers) read it that way. As I said above, training a new developer in Smalltalk is a whole lot easier than training them in your problem domain. Having developers learn Smalltalk is not a hard thing - just ask them. Bottom line - if you make the statement "Yes, Smalltalk is more productive, but..." - just eliminate the latter half of the statement.

In the comments to this post, Gregg said:

You're confusing action in private markets with public coercion. In a private market individuals are choosing to allocate their scarce time and resources to one programming language or another. They find using one programming language allows them to achieve their ends easier than another. Their corporate action leads people to say, "the market is always right." The reason you do not extend this to the political realm is because the state can act with force. "You use programming language X or you will be jailed." When private markets act coercively, it's a criminal offense

I added a comment of my own, but I'm pulling my response up here. I don't think I'm confusing anything here. If you don't think IT shops have been (and still are) being run top down (and sometimes bottom up) towards specific technologies, then you missed the entire PowerBuilder drive of the early 90's, and the all of the Java madness of the late 90's. In both cases, existing applications - written in a wide variety of other systems - were re-written in PB or Java for no good technical reason. There's as much politics in the IT sector as there is anywhere else.

Bob Congdon points to a very funny story about measurement :)

Linux Today links to this story on the city of Munich's difficulties in moving from Windows to Linux. Apparently, they are finding the transition to be more difficult than they thought it would be.

This is no big surprise - based on all the reporting I saw on this, the decision to move was a political decision rather than a technical decision with political support. In other words, the city decided to migrate, and only then did they find out what it entailed. This is similar to many of the rewrite efforts you saw in the late 80's, moving from (insert tool here) to Java. A decision was made for political reasons, and only later were technical issues discovered.

Contrast Munich's head first decision with what the city of Paris is doing:

This hasn't stopped other cities, states and countries from giving open-source software a try 14 or at least a second look. Paris recently revealed it was studying ways of moving its 17,000 government PCs from Windows to open-source

Instead of just making a gung ho "let's go" call, they seem to be studying the issue so that they can see what pitfalls and issues there might be first. Now, let me relate all of this back to a series of posts I've made (here, here, and here) over the past few days. Shops that just decide up front to use the currently fashionable language and/or tools - without even looking at other possibilities - do themselves no favor. Heck, they may end up going with Java or .NET after looking around - all I've been trying to point out is that too many IT shops don't even look. With the perceived cost advantages of outsourcing, how bright is it to close off possibilities like that?

Do you believe in magic?

Clemens Vasters has a few words about open source dreams. In an open letter to a 21 year old open source developer, he writes:

However, I start to wonder where your benefit is. You are - out of principle - not making any money out of this, because it is open-source and you and your buddies insist that it must be absolutely free. So you are putting all of that time and energy into this project for what? Fame? To found a career? Come on.

If someone installs your work from disc 3 of some Linux distro, they couldn't care less who you are. The whole fame thing you are telling me only works amongst geeks. The good looking, intelligent girl over there at the bar that you'd really like to talk to doesn't care much whether you are famous amongst a group of geeks and neither does she even remotely fathom why you'd be famous for that stuff in the first place. I mean - get real here.

Read the whole thing - and ask yourself whether or not there's a clear benefit to you in open source. I'm not as down on it as Clemens is - heck, BottomFeeder is open source. Then again, I'm not directly trying to make money from Bf either - it's a public demonstration for Smalltalk - i.e., marketing. Anyway, it's an interesting read.

Clemens Vasters questions the efficacy of open sourcing Java:

If Sun were actually to open-source (that's a verb now, is it?) Java as IBM demands, IBM would finally own it. They've got more resources and they'd throw them at the problem, easily taking away the leadership in the Java space. Sun would just be sitting there, watching in disbelief what happens to what used to be their stuff. That's really what IBM wants and I am amazed how clever they are about it.

This begs another question though: what tangible benefits does Sun get from Java now? Seriously - they have this huge staff on the JavaSoft team, lots of guys working on NetBeans - and they are nowhere in the competition for

• Application servers (IBM, BEA, Oracle - and, to a lesser extent, MS - own this space
• Tools - they give NetBeans away, and Eclipse gets all the press anyway
• Consulting Services - IBM and the big consulting outfits get most of the revenue

It looks to me like they have invested a lot of money in other people's business plans. Open Sourcing Java might actually be a face saving way of admitting defeat and cutting their costs....

One of the Lisp guys on CLiki pointed me to this article on type systems terminology. This is looking more and more to me like a pov thing - the terms mean different things to different developers...

There's a new search engine for feeds - and they offer both RSS and Atom flavored results. I've added support for it to the dev stream of BottomFeeder

In a comment to this post on OSS, Ryan Lowe said:

Hey, I'm not saying we can't all make a buck. But there's no reason for Clemens to piss all over someone else's views of open source software. Call it socialist or communist if you want (maybe bad blood coming from a German?) ... it doesn't matter. It's free, it's shared, it's open. Sounds like he's just afraid of being marginalized. Free software is going to commoditize the software market one segment at a time, he's just going to have to get used to that. More programmers will make money in services -- customizing software for specific tasks.

That was in response to Clemen's screed on giving software away. Clemens has a follow up where he clarifies the "free vs. free" thing. Here's my 2 cents - stating that everyone should "get over it" and realize that the money will shift to services is incredibly naive. As Clemens says, that theory will lead to huge profits for entities like IBM's Global Services (et. al.), and small amounts of dough for the rest of us. Ryan's theory works out fine for the guy who's in his early 20's, has no wife, no kids, and doesn't mind hopping on an airplane frequently to do services work. It works a lot less well for people who are a bit older, have families (including small children) who kind of want to see Mom and/or Dad on a regular basis. I've done the heavy travel gig - and believe me, it takes a toll on your family life. It can also easily become a "broadening" (in the waistline sense) experience.

Many areas of software are becoming commoditized, and that will continue as the industry matures. However, that doesn't mean that the people working on commodity software don't have bills to pay. The desire to stay home more often and pay your bills ontime is not selfish, and those who seem to think it is just haven't thought it through completely.

Sometime this evening I'm going to push out what I hope will be the 3.4 release to the dev download page for BottomFeeder. If there are no issues over the next few days, I'll be releasing it.

The Academy got over itself for an evening, and gave Lord of the Rings Best Picture - plus 10 other awards. Now if the same rationality could sweep over the MPAA and the RIAA....

Ok, I like this one too much: Larkware News proposes this new term:

I would like to introduce a new word to the language: spamvalanche. This is what happens every Monday morning, when the dumb people go back to work and double-click on the viral attachments in their e-mail..

Heh

The (hopefully final) 3.4 build of BottomFeeder is now up on the download pages - development links only. If you are a current Bf user, you should be able to just grab the appropriate baseApp zip file, and drop the new image or exe into your directory (replacing the old one). For Mac OS X users, that means replacing Contents/Resource/resource.im with the new bottomFeeder.im (but rename it resource.im first). You can blow away all of the files in your 'app' directory, and all of the files in the 'plugins' directory (excepting any homebrew plugins, of course). I haven't updated the doc pages yet - I'll do that when I go to full release. That should be in a day or two, so long as nothing major crops up.

Windley points to an interesting use of RSS - a feed run by the Utalh State dept of purchasing, advertising the current bids page. That's a great way to get information out - consulting companies should pay attention to this.

Maybe this is the right response to the RIAA:

"A British-based company is selling MP3 players which can be attached to an assault rifle...."

Kidding!

Pat Logan points to Jon Udell's article on the lack of dynamic languages - or even support for such - on dotNet. Seems to me MS is following the Sun path on this. Early talk about great things in the future, followed by complete inaction. That's too bad, because there are a whole lot of languages that are being pre-emptively "voted off the island" as a result. Patrick speculates:

MSFT deliberately de-emphasized dynamic languages approaching the first release of dotnet. But did they go so far as to paint themselves into some kind of a corner, maybe with an over-restrictive programming model?

Maybe there is no consensus, but *something* is wrong.

If I had to guess, I'd guess that it's just completely fallen off their radar....

If you use Borland Tools, check out their feeds. LOts of good content for that developer community....

Now I can get updates on the Red Sox' agonies directly from the Globe - they are offering a wide spread of RSS feeds. Here's the sports link - should be filled with Sox agony right around mid September :)

I've posted a new survey on our site. I'm asking some questions about the non-commercial product - please give us all the feedback you have!

I'm looking for a simple service for online selling of products - we have an interest in selling Cincom Smalltalk (possibly other Cincom products as well) online. The problem with building the service ourselves is the complexity of tax and shipping issues around the world. When we sell direct, we have local offices that deal with that. For online sales, it's a whole different ball of wax. Does anyone have any advice on this subject? Send email to me. Thanks!

Interested in what Nasa's up to? Then subscribe to their RSS feed.

We have a new blogger on the site - Sudhakar Krishnamachari. His feed is here. Welcome! Sudhakar is a very vocal Smalltalk advocate in India; it's great to have him on the site!

Avi has posted some comments to the squeak-dev mailing list about SmallBlog. One of the issues with the current version (you can see the problem on the learning Seaside Blog) is the lack of permalinks for existing posts; that makes it next to impossible to get back to old content once it's scrolled off the main page. Apparently, that's been addressed:

One of the major advantages of this version is that if you configure it with your hostname, the links generated in the RSS feed will be absolute, and so will actually work. Also, accessing the front page and the RSS feed no longer involves HTTP redirects, which confused some aggregators

BottomFeeder was ok with the redirects - it handles temp redirects accurately. It's good to see the link issue addressed though. I'm looking forward to Avi's keynote at Smalltalk Solutions - I'd like to hear more about Seaside.

Don Park comments on why Open Source projects typically have low quality UI's:

• open source developers have little interest nor incentive to do it right.
• most software developers lack the knowledge and experience to design good UIs.
• UI design is hard and insanely tedious, even for the professionals.

This was in response to Eric Raymond's post lamenting this. I'd add a simple observation - open source developers tend to build exactly what they need - and nothing else. Why? Well, this hearkens somewhat back to this topic. Most open source projects are small efforts (there are exceptions, like Eclipse and Apache). Most of these efforts are also not really about making money. As Don mentions, building a decent UI takes time and effort. If you aren't being paid, there's very, very little incentive to put in the kind of effort MS and Apple clearly do. Instead, you'll build something that's clear to you (the developer) and move on to more "interesting" (read - technically challenging) problems.

Heck, you see this in commercial projects as well. For years, VisualWorks had a second rate user presentation, because the tools were being built by engineers as an afterthought. We have people who are interested in and care about presentation on staff now, and it shows (compare the UI from 5i.3 forward to the UI for 5i.2 and previous to see what I mean). Small open source efforts are going to fall into this as well, unless they are fortunate enough to have a developer who actually cares about these issues. The larger ones - Eclipse, Apache, et. al. - are effectively commercial (i.e., funded) efforts and can afford to pay someone to care.

A lot of things fall into the "UI bucket" that aren't strictly speaking UI - anything that qualifies as a "finishing touches" issue will tend to fall by the wayside in open source projects. This isn't a flaw in open source development; it's simply human nature at work - and I expect that it's one of the reasons that political decisions to move to Linux (like this one) are going to run into rough patches. There are rough edges in Linux that many end users are going to be very frustrated with.

In an attempt to see if anything will stick, SCO has sued AutoZone. Meanwhile, ComputerWorld points to an interesting flaw in their theory:

AT&T said it wanted "to assure licensees that AT&T will claim no ownership in the software that they developed -- only the portion of the software developed by AT&T."

In other words, AT&T never intended for Unix licensees to give up ownership of code they added to their versions of Unix. That was never part of the deal. And the deal AT&T cut is the one SCO has to live with -- even 19 years later. That's how contracts work.

Of the million lines of Linux code that SCO claims IBM hijacked from Unix, SCO hasn't identified a single line that came from the original Unix source code. It was all created by IBM. According to AT&T in 1985, that means it's IBM's to keep -- or give away. And SCO's theory that it owns Linux code appears to be kaput

Goodnight Irene....

Cafe au Lait points to this question - "Think about it: have you ever had to reboot your microwave?" . Well, just like the Cafe Au Lait guy, I've noticed an increasing number of common appliances that need to be rebooted. My microwave, no. However:

• My minivan sometimes has spurious sensor malfunctions that light up the "check engine" light. A trip to the mechanic results in a hardware reset for the sensor in question, with no repair needed. I've had this more than once; the last one ended up pushing my annual pollution check on the car back
• My stereo receiver - a very nice Sony unit - sometimes refuses to play audio for any devices. It's clearly receiving signal from radio, or the CD or the DVD - it just won't play audio. Powering on/off doesn't work; I have to unplug and count to about 20, then plug it back in.
• We have two Replay TV's in the house, and they are supposed to be aware of each other - allowing streaming A/V between them. Periodically, they "forget" that there's another machine on the network, and have to be rebooted.

This is all due to the spreading of embedded systems to appliances and other devices. One of the things it's pointing out to me is that the people who write embedded software don't seem to be significantly better at catching boundary issues than the rest of the developer community is. Kind of makes me wonder about some of the truly mission critical systems out there....

Blaine Buxton announces the first meeting of the Omaha STUG:

If you're in the Omaha, NE area, please feel free to stop by Abraham's public library (around 90th and Fort) at 7:00pm for the first Smalltalk user's group! We will have an exciting demo fo Squeak by Mr. Steve Wessels. I would like to have lots of discussions and maybe we'll go for coffee later. I want the user's group to be a lot of fun and very interactive.

I remember Steve Wessels. Tell him I said hi!

ComputerWorld reports that IT hiring is increasing this year. Interestingly enough, they are also reporting that R&D is being offshored. That likely means that the overall market for IT services and products is starting to rebound, and that overall demand is starting to come back. Either way, an interesting pair of stories

The demand for Smalltalk books in Germany seems to be strong. I posted on this new book last year, and now I've learned that the book has gone into a second printing - only a 6 months after it became generally available! The book is in German, and includes a Cincom Smalltalk (VW 7.1 and OST 6.8) CD. If you've been looking for a good intro to Smalltalk, and you speak German, this is the book you want.

If you use VW 7.2, our engineering group has an important patch you need to get:

We have a patch for a fairly serious MD5/SHA regression in 7.2 (AR 47235: Hashes hashes intermittently generate wrong digests).

Have a look at the patch page - grab 47235 and install it now

If you are developing with VW and Store, I strongly suggest that you take a look at the package Store-Speed Patches in the public store. Loading packages goes a whole lot faster after loading it - kudos to Cham Puschel!

Amazon now has a ton of predefined search feeds. Wow.

Here's some more details on the schedule for Smalltalk Solutions 2004 - go and register today!:

An exciting set of keynotes feature Microsoft CLR Architect George Bosworth on the Smalltalk and CLR virtual machines, former Hotspot architect Lars Bak on Smalltalk for very small embedded devices, and Seaside inventor Avi Bryant on using Smalltalk to redefine web development.

Learn about technologies in-depth with tutorials covering the Seaside continuation-based web framework, Ward Cunningham's "FIT" acceptance-testing framework, Gemstone, garbage collection, web technologies from a Smalltalk point of view, and the GLORP object-relational mapping library.

Expand your knowledge with a wide-ranging technical program. Stay current with talks about Smalltalk and current "hot" technologies, including web services, .NET, XML, web interfaces with CSS, and Smalltalk on small devices. Hear the experiences of developers using Smalltalk in domains from pension plan management to emergency services dispatch to internet syndication to 3-D CAD and on topics from document management and reporting to the issues of migrating an application from Oracle to Gemstone. Last, but not least, learn about new enhancements and future plans, the impact they may have on your development, and about directions for the long-term evolution of Smalltalk.

Make sure to join us in Seattle!

Life after Angel - Firefly is going to hit the screen in 2005. That's really cool news.

The Schedule for StS 2004 is here. Now's a great time to register and get ready to come see the show. I'll be talking about BottomFeeder - Come see that if you want to learn more about the entire process of deploying a Smalltalk application in the wild.

The Register has found out what the PR masterminds at SCO have to say about themselves:

The SCO Group's masterful public relations tacticians have demanded that the company be compared to fellow IP (intellectual property) crusaders at the RIAA.

"We believe that there are important similarities between our recent legal activities against end users and those actions that have taken place in the recording industry," said SCO CEO Darl McBride, during a conference call today.

"It wasn't until the RIAA (Recording Industry Association of America) ultimately launched a series of lawsuits against end user copyright violators that the community at large became fully educated regarding the liabilities associated with using copyrighted materials without providing remuneration to the copyright owner. We believe that the legal actions that we have taken and will continue to take will have a similar impact on end users of Unix and Linux."

Yeah, there's a plan - identify yourself with the group that's suing 12 year olds. I had this vague notion that PR was supposed to be positive...

This year's Smalltalk Solutions promises to be a great show with some great presentations - like Avi's keynote on Seaside:

Winning the Application Server Arms Race: Using Smalltalk to Redefine Web Development keynote
Avi Bryant: http://www.beta4.com
Monday 10:30:00 am to 12:00:00 pm

Abstract: It would be hard to imagine a worse model for user interface development than HTTP. Would you use a GUI framework where every event from every widget in your application was handed to you at once, periodically, as a large hashtable full of strings? Where every time a single piece of data changed you had to regenerate a textual description of the entire interface? Where the event-based architecture was so strict that you couldn't ever, under any circumstances, open a modal dialog box and wait for it to return an answer?

Those are the costs of using the web browser as a client platform, and, by and large, we accept them. The dominant paradigms of web development -- CGI, Servlets, Server Pages -- do very little to hide or circumvent the low level realities of HTTP, and as a result, web applications are fragile, verbose, and ill-suited to reuse.

Smalltalk can do better. More than that -- Smalltalk is uniquely suited to do better. To date, we've followed conventional wisdom and built Smalltalk implementations of the same old paradigms, providing familiarity and compatibility. But by throwing these away, Smalltalk can instead provide an overwhelming competitive advantage. By leveraging Smalltalk's particular strengths, we can abstract away the ugliness of browser/server interaction in ways that simply aren't possible in other environments, and profit greatly by it.

For all its limitations, the web is fast becoming the most important deployment platform for many classes of application. The Java, Perl, PHP, and .NET worlds, to name a few, are pursuing it agressively. Many of us are going to have to play their game -- but we don't have to play by their rules.

Bio: Avi Bryant is an independent consultant based in Vancouver, Canada. Much of his work centers around the use of Squeak Smalltalk as a platform for commercial software development. As an actively contributing member of the Squeak community, he maintains its standard version control system, as well as packages for web development and relational and object database access. As a consultant, he has helped companies develop Squeak-based products for the travel and theatre industries, higher education, and mobile devices. Avi previously worked as a developer and research assistant for the University of British Columbia.

I've updated the details page on the upcoming (Fall 2004) release of Cincom Smalltalk. Have a look at what's coming your way

I've had a few reports over the last month or two of BottomFeeder's update loop inexplicably stopping, requiring the user to toggle the application through online/offline to restart it. I was baffled for awhile, but got some help this morning from one of our engineers who runs the application in his VW development environment (as opposed to the packaged application). It turns out there there were some poor assumptions in the code that checked for "too many" timeouts during the update loop.

There's a setting that allows you to ignore timeouts during the update loop. I always have that set, so I wasn't even seeing the problem. Now, say you have that unset (the default). The update loop keeps track of how many timeouts have occured during the current cycle, and takes notice when "too many" have occurred. How many is "too many"? Well, the code was set for 10%. This works fine for me and my 244 subscribed feeds. It works less well for someone subscribed to, say, 20-30 feeds - 2 or 3 timeouts can trigger the event. Now, the trigger was supposed to launch a dialog notifying you of the problem. This is where the second part of my error came into play

The action on too many timeouts is to suspend the update loop and then pop a dialog. The problem was, the dialog firing code was after the code that terminated the loop - and thus, never ran. Dohh! That's now addressed, and I've also put a lower bound on "too many" timeouts - it's now 10% of total or 10, whichever is larger. That should fix that problem. Now I'm off to create a new potential 3.4 build...

Michael Lucas-Smith points out one of the key differentiators of Smalltalk - extensibility. Every set of libraries - the STL (for C++), the base Java and .NET libs, the Smalltalk libraries as shipped by a vendor - all have limitations. These may be things the vendor didn't foresee, or things that the vendor's engineers have not gotten to. Either way, they represent an issue for any team that runs across them. The nice thing about Smalltalk is that you can deal with them directly. How? By adding to or modifying the base libraries themselves. String is missing a few methods in your opinion? Add them. The XML framework has insufficient reflection? Push it in. The code you add can be versioned off in easily separable ways from the vendor code as well - making it a simple matter to check for issues when the next major release from the vendor comes out. You just can't do this in those other languages - and I don't think it's a "feature", no matter how many ways it gets spun as one :)

Mark's experience with spurious information shows why you should always look at the media with a very jaundiced eye....

The second keynote at Smalltalk Solutions 2004 will be George Bosworth's talk about the CLR:

Smalltalk and .NET: A Comparison of Virtual Machines
keynote
George Bosworth: Microsoft
Tuesday 10:30:00 am to 12:00:00 pm

Abstract: TBD

Bio: George Bosworth is a CLR Architect with Microsoft and formerly architect of the Digitalk Smalltalk virtual machines.

We don't have an abstract yet, but George will be discussing VM architectures, dynamic language support, and the CLR. I'll post the abstract as soon as it becomes available.

Sci Fi Wire reports that there's going to be a remake of Logan's Run. All I can think is "Why?"

Sébastien Paquet has an interesting graph of subscription numbers from Dave Winer's share your OPML pages. At 246 subscriptions, I'm starting to push towards the right end of that chart - still nowhere near the 1300 or so that Scoble subscribes to though. I have no idea how he keeps up with that...

I started this as a comment to this post, but I decided to just post it once it started getting long.

The point we are trying to make is simple - all libraries, from all vendors, have issues and limitations. Pick a Java library or a .NET library, and you are pretty much stuck with the limitations. In many cases, some bozo library designer has declared it perfect for all time and made it final, so you can't even subclass it. Other times, usage of specific classes is hardcoded so that it's not practical to subclass even if you can

When confronted with this, you end up having to re-invent a lot of the supposedly reusable vendor code. Every Java application I've ever heard of has their own private String libraries to deal with this. The beauty of Smalltalk, in this case, is that we can overcome the limitations of the library without heroic efforts. I've made a number of such changes in BottomFeeder - in many cases, new releases have obviated my changes and I've removed them. But I didn't have to either:

• Live with the limitations until the next release
• Create my own parallel set of code that solves the issue

Instead, I've had to make small tweaks here and there - easily monitored, versioned off, and eliminated when necessary. That's one of the things VisualWorks would lose if we integrated into .NET (or Java) the way some people suggest. If we used "off the shelf" platform libraries, then the ability to modify them when we needed to would disappear. Here, go read this post for an example of what I'm talking about - Troy "enjoys" those .NET facilities every day :)

I indented that to make it clear that I was responding to the referenced comment. It's not that reusing existing facilities has no value - clearly, it empowers developers to "stand on the shoulders" of others. However, VisualWorks (the Smalltalk implementation being discussed here) is cross platform (which obviates total integration with .NET), and is dynamic (which obviates the JVM as a platform choice, since its support for dynamic languages is very sub-par. Yes, Jython esists. It's also much slower than it should be).

Looks like XP Service Pack 2 could break a lot of products - like all JITTed systems (most Smalltalks, and most extant JVM's). Here's the relevant quote:

"Applications which perform dynamic code generation (such as Just-In-Time code generation) that do not explicitly mark generated code with Execute permission might have compatibility issues with execution protection." The company is supplying specific instructions and code samples to explain the implications of the changes for application developers.

It's actually quite brilliant. I's a great way to take a shot at Java while standing innocently and saying "who, me?" You have to give points for the audacity alone. Here's the best part, from the MS page referenced above:

Some application behaviors are expected to be incompatible with execution protection. Applications which perform dynamic code generation (such as Just-In-Time code generation) that do not explicitly mark generated code with Execute permission might have compatibility issues with execution protection. Windows .NET Framework applications do not currently mark generated code with Execute permissions. XPSP2 recognizes the current, shipped versions of .NET Framework and runs them with NX off. Therefore existing .NET applications will continue to run. Microsoft is enhancing the .NET Framework to take advantage of NX and will ship service packs for each of the shipped versions in the XP SP2 RTM timeframe. The .NET Framework "Whidbey" will innately support NX.

Wow. So .NET gets a pass, and the rest of us get to suck eggs. This will be fun...