Smalltalk Tidbits, Industry Rants

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....

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.

Do you believe in magic?

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?

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

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.

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.

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'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!

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

Joel Spolsky and many people on his forums are clearly confused about Closures and web apps. Looks like they need to visit Avi's blog....

Ryan Lowe comments on Smalltalk for Eclipse (he attended the Ottawa demo last night). I'm always interested in seeing how ST demos come across to people who don't know Smalltalk - for instance this:

Part of the talk included a very interesting tangent on a concept called "doits" (pronounced "do its", not "doyts"). I'm not sure if it only applied to the Smalltalk Eclipse IDE or Eclipse in general though. The idea is to put a simple scripting language in Eclipse that you can use to perform quick tasks in the IDE. The example doit he gave was if someone else found a bug they could attach a doit to the bug report download the project from CVS, compile it and then highlight the line that refers to the bug. A scriptable IDE sounds really cool indeed. I don't think he mentioned a possible language it would use if they made it though. Maybe python?

This points to one of the classic failings of Smalltalk marketing - we don't explain our advantages at all well. The fact that Smalltalk is scriptable (even an end user app - see this post, for instance). It always has been - you can modify the way the environment works in ways that go well beyond the plugin capabilities of Eclipse, but we have not made that clear.

I think my attitude towards Eclipse for Smalltalk has changed though. I was somewhat leery, but I've changed my mind. We need to have things that operate as outreach to the file based, CVS style developers (they are the majority!). If we can't bring Mohammed to the mountain....

Via Syndic8 - if you get asked what RSS is, this is a pretty good explanation. It keeps it all at a high level, for the non-geek crowd.

After I made this post yesterday, Douglas pointed to this MSDN article on something MS is calling "ClickOnce" - a framework for a unified install/update cycle. The article describes a more complete version of what I do now for BottomFeeder; it's also very similar to the ideas being worked on by our engineering group for this problem. It's good to see MS tackling the issue - I hope that Symantec adopts their scheme so that I don't have to reboot so often after their updates. That last thing is the main problem I have with most application updates out there now - I can do updating for Bf that takes place immediately - why do so many applications force an OS level reboot? Hopefully, this MS work will get rid of a lot of that...

Patrick Logan explains some of the issues that would crop up in a hypothetical .NET that supported dynamic updating (as speculated by Gordon:

One issue that comes to mind is stack-allocated objects...

Imagine module A defines a stack-allocated and some system should load a newer version of A. Now imagine the newer version of A redefines the stack allocated object, e.g. gives it a new "shape". What does this do to the objects allocated on the stack and the code in other modules that manipulates them?

This is one of the key differences between the "everything is an object" as defined by dotnet, and the "everything is an object" as defined by Smalltalk.

Dynamic updating isn't just for servers either; BottomFeeder can have new versions of code downloaded and loaded without a restart. This is one of those power things where Smalltalk is just better

I'll be speaking at the Frankfurt STUG in a few weeks:

Cincom Smalltalk Product Manager talks on "Blogs and RSS" at Smalltalk Meeting in Frankfurt, Germany

Jim Robertson, Cincom Smalltalk's Product Manager, will take the opportunity of his CeBIT visit in Germany to give a speech at the monthly meeting of the Frankfurt circle of the German Smalltalk Users Group.

Subject	Blogs and RSS - worth your time?
Date and time	Thursday, 25 March 2004, at 19:00 h (7 pm)
Location	Restaurant Au Mandarin, Chinarestaurant
	DG-Bank-Tower
	Westendstr. 1
	DE-60325 Frankfurt

Afterwards discussion and Q & A

All Cincom Smalltalk customers are welcome to attend this presentation. Please let us know when you will attend; please mailto infode@cincom.com.

Kind regards.
Dr. Monika Laurent
Marketing EMEA
Cincom Systems GmbH & Co. oHG
mlaurent@cincom.com

Cincom will be at CeBit in germany this year - Helge Nowak, technical sales in Germany, and Claude Poole - our engineering manager - will be in the Cincom booth for all or part of the show:

Cincom Systems at CeBIT 2004

Interested in getting the latest news about Cincom solutions and services? Come and visit us at CeBIT 2004 in Hanover, Germany, from March 18 - 24.

At CeBIT 2004 Cincom will be hosting two booths:

In Hall 3 Booth # B19 our main themes will be Cincom Smalltalk and Cincom Manufacturing Business Solutions.
With the latest Cincom Smalltalk Fall 2003 release including .NET connectivity, Cincom Smalltalk now stands as a bridge between the two "separate worlds" J2EE and Microsoft's .NET. Being multi-platform compatibel has been enlarged to the mobile world: Cincom Smalltalk now also supports mobile platforms like Windows CE. The Cincom Smalltalk experts from Cincom and from our partner Georg Heeg are looking forward to meet you at the Cincom booth in Hall 3.

Find out as well what Cincom can offer you as added value for your complex manufacturing environment, such as

• Interactive Selling Solutions,
• Enterprise Management,
• Quality Management.

In Hall 18 Ground Floor, within BANK-FINANZ-SYSTEME, at Booth # A24 - 2.6, Cincom presents Cincom Financial Services Solutions which help you identify and solve your issues in the following fields:

• Data Access and Integration for Sales and Marketing
• Improved Data Analytics
• Increased Customer Profitability
• Identification of Sales Opportunities
• Multi-Channel-Communications and Business Workflow

We will be happy to welcome you at Cincom on CeBIT. If you are interested to visit us please send an email to infode@cincom.com and ask for your complimentary guest ticket.

Kind regards.
Dr. Monika Laurent
Marketing EMEA
Cincom Systems GmbH & Co.
mlaurent@cincom.com

Come see what's new!

Good news for HP customers - HP is throwing in the towel on itanium and moving towards the AMD Opteron. The good news for Cincom Smalltalk customers using HP? You'll get 64 bit support within the year!

Well, I'm off to more customer visits this afternoon in Dallas. Yesterday's visit to Tradewell was fascinating - as I said yesterday, they have an amazing system for dealing with energy trading. They demonstrated the system to us, and the visual display of deals made it very, very easy to understand and follow. This should be a killer app in that field. I'll be visiting Vialink and Adventa over the next two days - I'm already familiar with both of their systems, but it should be interesting to see what they are up to. As well, this gives them a chance to tell me what we are doing right, and what we are doing wrong.

Forbes has noticed syndication

Bill Clementson outlines a plan for making money on Lisp; the same ideas are applicable to Smalltalk (or any development niche, for that matter). The ideas are spun off of this thought:

You sometimes hear people on c.l.l. complain that they can't find ads for Lisp programming jobs. Rather than bemoan the lack of Lisp jobs on the Monster job web site, it might be more useful to focus on what Lisp is good for and work out how those Lisp-specific qualities might help you make money. Fast Company recently pointed to a weblog posting by Dave Pollard about the 10 most important business ideas of 2003. Reading through this list, I was struck by how well-positioned Lisp is in some of the areas highlighted by Dave...

Smalltalk excels in the same areas.

PR Opinions has a story on RSS and tracking. I can understand why people want to know who is and isn't subscribed; subscribed readers are more committed, adn - in a sales/marketing context - may be more open to learning about the products and services you provide. It's interesting that outfits are starting to look at that, but the 'solutions' are amusing:

So when I read that IMN Inc (formerly iMakeNews) have announced (PDF only) a trackable RSS feed service I was intrigued. A way of tracking RSS success.  Fantastic.

However, when I went to their site, and from the story in ClickZ it seems that all they do is publish your content to an RSS feed and count the hits.

"We've encoded all the links -- usually with an RSS feed you get a subject of an article and a link. Every link provided is a unique trackable link. When you open up the feed we know it. Every time you refresh the feed we count it. And when you click to read a particular article we register that," Goodwin said

Heh - that's just scanning logs and counting, something I do in my free time for entertainment value.

CSS is being filtered by Symantec's content filter - probably because IE allows Javascript in CSS. Great, another useful tool ruined by the feature gnomes at MS....

I saw a couple of very cool customer applications today - a POS system used at restaurants, and a trading system for buying/selling natural gas. These are both very, very cool systems - and with the latter, our partner tells me that most of his competition is spreadsheets and PowerBuilder! It looks great, and I was very impressed with the work they've done - it's a great example of a VisualWorks application. I'll have more later, but I'm about to jump on a plane to Dallas - more customers to visit over the next two days.

Steve Gillmor has an RSS problem. I can mark items persistent, so even if they are read, they hang around. I can also bump the cache for a given feed up to absurd levels to ensure that items don't go away. Hmmm. Maybe he has a tool problem...

Bill Clementson talks about dynamically changing a Lisp Server - this is something Smalltalk does very, very well also. I do something similar with the blog server - but I don't (typically) have GUI access to it - it runs as a headless server, many miles from where I live. So how do I dynamically update it?

• Test a patch on a local version of the server so I can verify that it works
• File the code out (i.e., push it to a file that can be loaded and compiled into the server
• Version the new code off into the source code control system, and drop a new version of the loadable component that the patch belongs to. This is so that I can get the server going with the correct code the next time it gets restarted
• FTP the code up to the server, and into the appropriate directories
• Using a defined remote API, kick the server so that it will load the patch

No fuss, no muss, no restart - and problem solved.

Brad Abrams quotes Chris Brumme on why you don't get a lot of info from a NullReferenceException (sounds like trying to send a message to nil in Smalltalk):

The NullReferenceException occurs because an instruction like call [eax 44] or mov edx, [esi 24] has resulted in an access violation.  We don't retain nearly enough information to form a correspondence between a particular register being NULL at a particular EIP and the fact that a particular reference in the application was null.  Especially since the EIP might be in a shared helper like a write barrier routine or an array helper.  In those cases, we would have to perform a limited stack walk to get the effective EIP.

The machinery that would be required to improve this error message is huge.  For the foreseeable future, you will have to rely on debuggers, or on FX code explicitly checking and throwing an appropriate NullArgumentException.

Fascinating. Contrast that with what I get when someone reports a BottomFeeder bug to me - I get a complete stack trace - with information on every object involved (arguments, senders, receivers - the works). All available in the runtime, dropped to a log file that can be sent to me. And that doesn't begin to explain how much better the information is in the development environment. This is one of those supposedly nebulous things about Smalltalk productivity - just about everything is simpler and easier to get to

Typing terminology is one of the areas where developers end up talking right past each other - because we use the same terms to mean different things. Take the following descriptions of typing:

• Static
• Dynamic
• Manifest
• Weak
• Strong

Now, go look in the archives of cls, or comp.object - likely other groups as well, but I'm less familiar with them. Try to get common usage for any of those terms. Take one that is bandied about between Java and Smalltalk advocates, for instance - "static". We typically use it to discuss whether variable types are declared manually by the developer in the source code. That seems simple enough... until you get a functional language developer in the mix. They'll talk about their language(s) as being statically typed - even though there are no manual declarations (or at least, no requirement for them). What they mean is that the types are not declared by the developer, but the compiler infers them and enforces them at compile time

This led me to start using the term "manifest typing" to mean manual declarations. That was fine, until I ran across this on Planet Lisp. Patrick Logan pointed out to me that Lispers mean this:

What this means is the object is inseparable from the type at runtime. The object always comes with a "manifest" that describes the type of object.

Whether that manifest is manually defined or dynamically inferred is apparently a separate issue. And heck, that doesn't even get into the more common confusions over Strong/Weak - many people equate manually declared type declarations with Strong typing (forgetting the way you can cast yourself into oblivion in C) - and also equate a lack of manual declarations with weak (forgetting that Smalltalk, for instance, gives you well defined behavior for a message that is not unnderstood).

The bottom line? You have to be extremely careful when you discuss this topic and start tossing jargon around - otherwise, you could end up making as much sense as a guy from Germany discussing Football with an American, each completely sure that they know full well what football means!

For those of us who take the blogosphere way, way too seriously Sriram Krishnan has a few words of advice....

The first leg of my trip to Texas is coming up - I'll be leaving for Houston, TX as soon as the cab arrives. I'll probably have some posts queued up when I arrive.

Alan Knight explains it all.

Bill Burnham worries too much:

The irony of RSS's success though is that this same success may ultimately contribute to its failure. To understand why this might be the case, it helps to imagine the RSS community as a giant Cable TV operator. From this perspective, RSS has now has tens of thousands of channels and will probably hundreds of thousands of channels by the end of the year. While some of the channels are branded, most are little known blogs and websites. Now imagine that you want to tune into channels about, let's say, Cricket. Sure there will probably be a few channels with 100% of their content dedicated to Cricket, but most of the Cricket information will inevitably be spread out in bits and pieces across the 100,000's of channels. Thus, in order to get all of the Cricket information you will have to tune into hundreds, if not thousands, of channels and then try to filter out all the "noise" or irrelevant programs that have nothing to do with Cricket. That's a lot of channel surfing!

There are a number of things wrong with this theory - first and foremost, it forgets the critical role of the end user. I subscribe to new feeds all the time. If the author of that feed keeps pushing out stuff I don't care about, I can do one of two things:

• Apply filters at the client (aggregator) side to eliminate the things I don't like
• Just unscubscribe from the feed in question

It may be difficult to find new feeds of interest - but the same problem exists in lots of other places as well:

• Books. There are loads of books published every year. How do I know which ones to look at? To a large extent, experience (looking for new works by authors I already like) and word of mouth. The same thing happens in feed-space - BlogRolls and links do the job.
• TV shows. Not as many new ones as books, but lots every day over digital cable. We have the Replay doing what amounts to keyword search, and we talk to friends.

The same sorts of things are happening in RSS. Why is this hard to figure out? There are already millions of feeds out there; I'm hardly paralyzed by that fact. This is much ado over nothing at all....

I was wondering how much space some of the caching I use in BottomFeeder uses. Now, I could have copied my feed data over to my dev directory, started Bf up in the dev system, and taken a look. However, that wouldn't have given me an accurate picture of cache usage in the real system - the usage of caching happens as a side effect of real usage. What to do? Well, this is Smalltalk, not some godforsaken curly brace language - so I went right to the application. It turns out that you can pop up inspectors in Bf if you know how. So up came the inspector, and I opened the workspace pane. This is one of the truly cool things about Smalltalk - the system is truly putty in your hands. Since the whole system is there (I don't strip out the compiler; it would not be possible to do the kind of runtime updates Bf does if I did), I wrote up a quick script:

| all feeds |
all := OrderedCollection new: 1000.
feeds := RSS.RSSFeedManager default getAllMyFeeds.
feeds do: [:each | all addAll: each items].
all collect: [:each | each cachedHTML].

I inspected the results of that, and got a collection of all the cached HTML the application is hauling around. I had 8206 instances of them, and the aggregate total of characters was 300k - i.e., not worth worrying about. The nifty thing is, I was able to get a real runtime result, not an assumed result based on semi-real usage in test.

This isn't the limit of what you can do, either. Awhile back, I introduced a bug in the dev stream that resulted in the item cache sizes being set to absurdly small sizes for most feeds. That would have been painful to fix manually, so did this

RSS.RSSFeedManager getAllMyFeeds do: [:each | each feedLevelCache: 120]

Which reset all my feeds to a more reasonable level. Do I expect average Bf users to do this sort of thing? Heck no. On the other hand, it's certainly handy for me as a developer - I can get real world usage answers from the system instead of test answers that may not match up. Try that in .NET or Java :)

Matt Croydon is more organized than I am - he's at least got a daytimer. me, it's all I can do to keep the whiteboard calendar up to date...

Don't think that blogs are a way to route a message around other media? The White House apparently believes it is. This led me to marketing - what if you are having difficulty getting your message out in the trade press? Blogging is a possible answer - and will has the ability to wind back around - as the above story did - into the major media. In the political world, this meant something like the WaPo. Here in the techie universe, it might be less trouble, since folks like Jon Udell and Dan Gillmor are already blog savvy....