Smalltalk Tidbits, Industry Rants

The submission deadline for Smalltalk Solutions is in less than two weeks! All submissions should be received by January 15, 2005.

Smalltalk Solutions is a premiere venue for Smalltalk enthusiasts, researchers, and professionals to meet and exchange ideas. We are currently accepting proposals for all varieties of talks involving Smalltalk technology and other areas of interest to Smalltalkers. We're looking forward to an excellent conference, and need your participation to maintain the high technical level of the conference!

This year's conference will take place in Orlando, Florida, June 27-29 2005. Presentations may be in the form of:

• Technical Presentations
• Experience Reports
• Technology Demonstrations
• Half-day Tutorials

In addition to the normal tracks, this years conference will feature a business track-including presentations with a greater emphasis on business than on pure technology.

Proposals should be submitted by email to Alan Knight at knight@acm.org and should include the following information:

• Name
• Contact Information
• Type of Presentation
• Title of Presentation
• Brief Abstract
• Short Biography of the Presenter(s)
• Desired Length
• Any constraints on date/time
• Any other information of importance in evaluating the proposal

Submissions should be received by January 15, 2005. Note that submissions with incomplete information may be rejected - particularly if bio or abstract information is missing.

See you there!

Bill Gates managed to ruffle a lot of feathers with his comments likening Open Source to communism:

Q: "In recent years, there's been a lot of people clamoring to reform and restrict intellectual-property rights. It started out with just a few people, but now there are a bunch of advocates saying, 'We've got to look at patents, we've got to look at copyrights.' What's driving this, and do you think intellectual-property laws need to be reformed?

A: "No, I'd say that of the world's economies, there's more that believe in intellectual property today than ever. There are fewer communists in the world today than there were. There are some new modern-day sort of communists who want to get rid of the incentive for musicians and moviemakers and software makers under various guises. They don't think that those incentives should exist.

That's throwing a bone over to the RIAA and MPAA folks who want to make the very notion of P2P illegal. Microsoft has an entirely different problem with Open Source, and I think I outlined the shape of that problem here. I guess Gates wants big allies for this fight, and the music/movie industry has lots of dollars to throw around.

There's a scary connect the dots thing here:

"Intel has a new line of chips with DRM built in. This appears to be the very first DRM-enabled chip to hit the streets. This microprocessor is unlike others available, because the user doesn't have complete control over the thing, and your computer can (theoretically) betray you. For a while now, there have been computers (IBM ThinkPad) that won't boot unless you give the password, but you could always rip out the hard drive and read it, right? With this chip, the keys and RAM are on the chip, and the flash is encrypted, so this really looks locked up tight.

That's Hollywood's wet dream right there, and it sounds like Gates is willing to sign on - in order to get allies in his fight against Open Source.

One of the improvements I made in BottomFeeder in the last release was in memory consumption - it's lower now. Why is that? The answer gets into the configuration of ObjectMemory. One of the best things you can do is to read the class side comments in class ObjectMemory. In general, VisualWorks divides memory into 7 "zones" that are managed by the VM. The key for this problem lies in the following definition:

NewSpace
NewSpace is used to house newly created objects. It is composed of three sub-spaces: an object-creation space (Eden) and two SurvivorSpaces. When an object is first created, it is placed in Eden. When Eden starts to fill up (i.e., when the number of used bytes in Eden exceeds the scavenge threshold), the scavenger is invoked and those objects housed in Eden and the occupied SurvivorSpace that are still reachable from the system roots are copied to the unoccupied Survivor Space. Thereafter, those objects that survive each scavenge will be shuffled by the scavenger from the occupied SurvivorSpace to the unoccupied one, until such time that the aggregate size of these survivors threatens to make the scavenge pause excessively long (i.e., when the number of used bytes in SurvivorSpace exceeds the tenure threshold), whereupon the scavenger will attempt to speed up subsequent scavenges by moving some of the older surviving objects from NewSpace to OldSpace. We say that such objects are being 'tenured' to OldSpace.

New objects get created in eden, and then bounced to a survivor space. If the survivor spaces get filled too quickly, then objects get tenured into Old Space. Now, Old Space is the only part of Smalltalk memory that grows at runtime - and in garbage collection terms, the scavenger doesn't look to clean it up unless it's in extremis. So... if you create a lot of objects quickly - and don't have enough new space for them - they get tenured. This tends to grow memory that you really don't need. That's exactly what BottomFeeder was doing.

During the update cycle, here's what happens if a site gets queried:

1. Fetch the XML source for the page
2. Parse the XML Source into an XML document
3. Convert the XML document into a feed object with items
4. Process the items against what we already have for that feed, adding any new ones to it

That's repeated for each feed that gets updated. That's a lot of new objects, particularly if you have threaded updates on. In 3.7 and prior releases, New Space was too small - so lots of the transient objects (the XML document, the raw page source, etc) were being tenured as new space filled. With 3.8, I made sure that New Space is bigger. This had a big impact - I subscribe to 295 feeds, and it means that Bf now consumes 25MB less than it used to - and all just by looking at how my application used memory.

There can be big wins here for any application - both in footprint and performance. Have a look at the documentation for class ObjectMemory, and do some experimenting with the method #sizesAtStartup:

It turns out that there was a problem with the 3.8 builds if they were being installed for the first time. I've fixed that bug - so if you downloaded BottomFeeder and couldn't get it working, try grabbing the stuff I just uploaded. My apologies for this error

With the 3.8 release out (and it's a big improvement over 3.7), my attention is turning to futures. The first step is already started; I'm moving development to VisualWorks 7.3. There are few things that will need changing, due to underlying framework changes in VW (the Http libraries and the subscription listener). I've got a development image built, and everything seems to work fine though - I expect to have early development builds out fairly soon. So what's coming?

• On Windows, support for the Tray. Instead of "slim mode" on Windows, you'll see a tray icon. That's more in line with what Windows users expect.
• Unicode support on Mac OS 9, and possibly on OS X.
• Better image support on Linux, if we can get a working rev of gdiPlus integrated

That's the short list; I'll be taking a look at the Wish list for ideas and plans as well.

I posted awhile back on our dishwasher woes; the parts that the tech needed finally arrived today. So it was back to the phone, to see if there would be any way to get a tech in before next Friday. After navigating their truly annoying voice response system yet again, I finally got a real person. Not that it helped a lot; the best I could get was a promise to put me into a "if anyone cancels we'll call you" queue.

Now, I understand that they have other people waiting. On the other hand, the original trouble call was on December 27th, and I told them the next day which parts the tech should have with him. The whole thing is just irksome, and doesn't fill me with warm fuzzies about future Sears purchases. Heck, A goodly part of the reason I bought a GameCube rather than a PlayStation2 was this mess I commented on last month.

Via InstaPundit come links to two views of where syndicated content is leading - The RSS is killing our ad stream view, and the everyone is going that way view.

This is a lot like what PVRs (TiVo, Replay, etc) are doing to TV. It used to be that you could time-shift (and even skip ads) with the VCR. It took planning - you had to manually program the VCR regularly and swap tapes. After an initial fuss (the Sony case of the early 80s), the media industry decided that this wasn't that big a deal - they could sell/rent videos, and not that many people went through the hassle of setting up a taping schedule. You still got plenty of eyeballs in front of the ads (or at least, you could convince the people buying the ads of that).

The dawn of the PVR changed that. It's trivial to have a PVR pick up your favorite shows for you. I suspect that a lot of people, like my wife and I, watch their favorite shows later the same day simply to enhance the viewing experience. Why watch "Lost" over an hour with 15 minutes of ads when you can start the show 15 minutes in and just blip over all the ads? This is what terrifies the media industry, because it's a threat to the basic economic model of TV. There are things they can do (banner ads during shows, product placement, etc) - but it's a wrenching change they'd rather not make - and you see that in the fight to get ReplayTV to drop the commercial skip feature.

That's what RSS is doing to the web. If you follow bookmarks in a browser, you see all the ads splattered on a site (and possibly all the annoying popups). If you subscribe to their feed, you skip all that and see just the content. Sure, ads can be slipped into a feed - but they are pretty easily ignored there. As well, most aggregators strip out lots of the tags and scripting that advertisers use. That leads to this kind of response, from the first view above:

Sorry for the inconvenience...

..but we have had to change our XML/RSS pages back to excerpts instead of whole entries. Too many of you didn't come to the site at all and it has killed our blogad revenue, despite continued high bandwidth usage. This is a very expensive site to maintain, unfortunately.

I know, I know, I like to read the whole post in bloglines myself. We are truly sorry.

The trouble is, this runs smack into the leading edge usage of RSS that you see posited in the second view:

If you're like me, virtually all of your time is now spent between two inboxes: your email and your RSS feed (which I read with the excellent web-based Bloglines). Indeed, I've pretty much stopped using bookmarks altogether. If I do visit a site, it's usually via a link in my feed and only then if I feel pretty sure the full text there will be worth the trip.

That describes my usage of the web as well. There are very few sites that I like well enough to put up with partial content - I've simply stopped reading a bunch of them. I've also done something else - I've written scripts to scrape the content into a full content feed on my local hard drive for a number of sites that offer only partial content. Now, that's beyond the capabilities of most aggregator users, sure. But the "it's not worth bothering" behavior certainly isn't. Thus the problem for a lot of sites - they need to drive people to their sites to view ads, but their audience would much rather see just the content - just like what PVRs are doing to TV.

Where is this going to go? One thing is for sure - like the betamax case I referred to above, it's a safe bet to assume that we'll see more lawsuits. Based on the behavior I've seen so far, it wouldn't surprise me a bit to see some kind of legal attempt to prevent site scraping...

Here's one of the reasons I find the various attempts to make languages like Java more dynamic amusing - look at the headache David Walend gets trying to do the Java equivalent of this:

someArray := Array with: elementKind1 with: elementKind2 with: elementKind3.

In Smalltalk, we can place any objects we want into a collection - and write tests to ensure that they all support the appropriate protocol. As it happens, I use such collections extensively in BottomFeeder to hold various feed or item like things. In Java, you also have to satisfy the compiler...

The Software With Style guys have added an RSS Feed for their releases. From Michael:

This is a rough start, but it's working. There is a link in each item to go to the download of the release. I'll also include a summary of how many passes/failures and errors there are for the release. The body of each release will include the change comments.

The URL for this is http://www.softwarewithstyle.com/developers/developers.rss

You'll be prompted for a username/password when you subscribe, so go ahead and register with them first.

Since just before the New year, the nightly spasm of wiki spam on the UIUC Wiki and on the Cincom Smalltalk Wiki has stopped. I don't know what it means; maybe we outlasted the spammer, maybe my complaints to the abuse address helped, who knows. In the meantime, the spam attempts on the blogs have continued unabated. It's being blocked due to a few measures I've put in - disallowing comments on old posts has prevented a bunch of stuff I might not have noticed.

Blaine Buxton discusses whether or not to use getters/setters (as opposed to direct variable access). His post is based off this article, which opposes using them.

Blaine comes down as a pragmatist, stating that the most important thing is consistency - either use them or don't, but don't mix and match styles. I have a slightly different perspective, but it's colored by my experience developing BottomFeeder. One of the things I added early was the ability to have the app update itself on the fly. Smalltalk has always been capable of this, so I thought it would be a nice way of tooting that horn. Using direct variable access is problematic if you are going to update an app on the fly. Why?

Well, posit a method foo that directly accesses a variable bar - the older version (i.e, the one being replaced) was written before that variable had been added to the class in question. So I access the variable... and as soon as I try to send a message to it I'm likely to get an exception. When I add a new variable to a class, it gets initialized to nil, so I have one of two choices:

• I can wrap all direct accesses with a nil check
• I can simply add a getter method that does lazy initialization

The former is a more annoying version of the latter, and scatters the same initialization logic all over the class - which violates the once and only once principle. Now, this kind of thing never comes up in Java, because you can't add attributes to a class at runtime there - you would need to restart. For that reason, Java developers simply aren't going to come across this messy little use case for getters. That's why I tend to use getter methods - it makes runtime updating of code far, far simpler.

I've just released version 3.8 of BottomFeeder. There have been a lot of enhancements, updates, and fixes in this release; here's a short list:

Changes from version 3.7

• A much faster and more robust HTML display component. Software With Style has upgraded their tool, which enables much better BottomFeeder performance
• Bug fixes in th euse of libtidy and the spell checker. The intermittant stability problems that cropped up are gone
• Bug fixes and enhancements for the saving of your content. Backup/restore has been greatly improved.
• Better offline browsing capability - with the local cache created by the underlying network libraries, you should see images with your feeds while offline (assuming that they have been cached)
• Lower memory consumption - the memory system has been tuned to be less aggressive about grabbing memory from the OS.
• Two new keyboard shortcuts:
• ctrl-g: Fully expand the tree
• ctrl-h: Fully contract the tree
• A new font definition tool - if you don't like the fonts that are offered for display, you can now change them, and have them loaded at startup. See the System>>Define Fonts menu item
• Added a toolbar button for "Add Feed" - new users had complained that the context menu was not obvious
• More events reported from BottomFeeder:
• #bottomFeederStarting: sent with the feed viewer as an argument. Allows plugins to take advantage of startup
• #bottomFeederQuitting allows plugins to be notified of application quit (as opposed to image quit, which is also reported)
• Regular expressions now supported for internal searching
• Internal searches now support a "search for feed title" option
• On Unix/Linux, browser spawning can be customized to use a specific shell, instead of defaulting to a (possibly not installed) csh. As well, users may use arbitrary script names - the launching expression is not checked as a valid path
• Amazon search capability is fixed - there was a bug that prevented new searches from being defined
• Shutdown will be faster - the save files are only saved if there have been user changes since the last save
• Lots of bug fixes, including one that could cause problems in Newspaper view
• A raft of new plugins - Asteroids, Xonix, and GoldenMonkey. Now you can waste time while your feeds update!

I'd like to thank Michael Lucas-Smith for all of his help with this release. The libtidy and spellchecker fixes are his, and all of the improvements to the WithStyle browser component come from him and his colleages at Software With Style. I'd also like to thank Rich Demers for the documentation - I sure couldn't have produced that myself - and his tireless work documenting BottomFeeder brought numerous bugs to my attention. I'd also like to thank all of the great users I have - their usage and bug reporting helps make the tool better every day! Enjoy the new release

The open source conversation on Google that Dare linked to has been included in a Wall Street Journal story. Dare has the excerpts on his blog, as the WSJ is a pay only service. The take away from this? Any conversation you have on a blog counts as a pseudo-interview...

Charles Miller has a very prescient thought about the Six Apart purchase of LiveJournal:

On the other hand, Danga was a casually-run company that existed to keep Livejournal running, and its founders cupboards full. SixApart is a venture-capital backed organisation that has a much more concrete appreciation of the concept of return on investment. It's inevitable that at some point, someone will look at the statistics and realise that fewer than one in fifty Livejournal users are actually contributing to its upkeep.

Any business ultimately needs to have some level of ROI - the difference with VC backed ventures is that the money guys are looking for a large ROI - and ultimately, for the day when they can go public and get paid off. That drives a set of behaviors, and those behaviors are not necessarily the same as those of a privately held concern. The private owner may be ok with a level of "charity", so long as the bills are being paid; VC's simply won't stand for that. This is not to say that VC's are bad - far from it. On the other hand, I would be surprised if LiveJournal didn't see some wrenching changes down the line.

The dev links on the BottomFeeder download page are a new build - and possibly the 3.8 build. If there are no major issues, this will be the release. We'll see what happens.

Dave Johnson corrects some of those "expert analysts" that the C level IT folks pay oh so much attention to:

Sun Readies Open Code, Michael Singer: "Other analysts say Sun could also open source its enterprise blogging application, named Roller. While the platform began its life as an open source project, before Sun hired its founder David Johnson, the company has not given the software the full on corporate treatment since he joined."

I don't believe those "other analysts" actually exist, this guy is just talking out of his, uh, never mind. I guess I need to set the record straight. First, Roller is and has always been open source. The version of Roller we use at Sun is the same one that you can download from the Roller project site at Java.Net in either source code or binary form. Second, I'm not interested in the "full on corporate treatment" -- I'm a married man.

This guy Singer is ready for the big leagues in analysis - next, he'll be making 20 year projections...

Update: The other analyst revealed

Dave Roberts has some excellent observations on open source issues up today. Here are a few I particularly like:

So the question here is how people working to reduce great ideas to practice are going to eat in the mean time. Every economic theory has to answer this question. All philosophy about the exchange of knowledge and ideas will lead absolutely nowhere if you can't answer the question of how people eat.

This is a point I end up making about Cincom Smalltalk all the time. People will ask me why we don't just open source our product. Well, the bottom line is simple - if you want to see future versions of the products, then there has to be a model whereby we can pay the people who develop the products. Right now, we are profitable, and growing. I have yet to see an open source model that wouldn't result in a drastic cutting of staff in the short term. Now, the common answer to this is "charge for service and support" - well, Dave has thought of that one as well:

• Development is difficult and support is a necessary evil. As a business, I'd rather spend all my time developing my product and as little time supporting it as possible. If I do the reverse, it means I have lots of customers with issues and my product is stagnating in the market. If I'm deriving my revenue from support, I'm actually incetivized to spend as much time on support as possible and as little on development as possible, leading to exactly the reverse of what we'd like as consumers.
• It is difficult to differentiate on support. There are many organizations that can support all sorts of different products. This is particularly the case with open source where the source code is available. As the developer of that product my revenue stream is being undercut by competitors that are not burdened with my development costs. Put another way, in this model, another business is actually incentivized to let everybody else do the development and then come in and skim off the support revenue (say business C comes in and supports the system created by A and B and doesn't give anything back to either one).
• At this point, people often speak up about "community" and giving something back. Business C is bad, they would content, if it simply reaps the rewards without doing some innovation itself. While I'm all for developing a good community and fostering community spirit, let's de-cloak that word and call it what it really means in this context: charity. While business C might have some sort of tacit moral obligation to not simply ride somebody else's coat tails, it is under no legal obligation to do so. In practice, there will always be at least one business like C, which will then gain competitive advantage by not shouldering the development costs. Whether C is ultimately successful depends on how much the "community" values "community spirit" (do they buy from C or avoid C because it is riding coat tails and therefore C is populated by bad people).
• In summary, if you're going to create a sustainable system, you need to find a way to tie revenue to effort as directly as possible. Any model which says "give this away and make it up over here" is going to create stresses on the system which can eventually cause it to fail. Can sustainable "loss leader" systems be produced? Yes, they can and there are many examples, but they need to be very carefully thought out and I don't think most FSF advocates have done much more than a hand wave here. In other words, certain product categories will do better here than others. Examples for include complex systems like JBoss where people inherently need training, etc. Examples against include anything that will be used by consumers who don't have time for training and don't want to be calling a 1-900 number for support.

There's a perfect example of Business C in the open source world - Red Hat. There's also a good example in the proprietary world - IBM, with respect to Java. Think about it - Sun does all the work, and made sure that Java would be popular by letting people use it for free. Before that ocurred, IBM had a whole stable of tools that were much like Eclipse - the VisualAge line. VA Smalltalk is the only one left - the C++, Cobol, and Java variants all got deep sixed. Why? Partly because it was far cheaper to be a free rider on Sun's charity.

Say we followed the advice of RMS, and put Cincom Smalltalk out under the GPL. Right now, Cincom supports the product with a small number of support engineers (and a larger number of development engineers). What would stop a company from offering support contracts for CST separately from Cincom in this scenario? Nothing. Could they do it cheaper than Cincom? Certainly - we would have to factor in the cost of the developers, while this competitor would only have to charge based on the much smaller number of support engineers they hired. What's the end result of that? It's a near certainty that Cincom would have to cut most of the development staff. Now, go look over here - just how much of that roadmap would be executed on after that? Not a lot.

There's an old Heinlein phrase that comes to mind here - TANSTAAFL (There Ain't No Such Thing as a Free Lunch). You say that Java is doing just fine, so that disproves my assertion? I beg to differ. Sun's revenue numbers have been in free fall for a long time now, and the only thing propping them up is the large pile of cash they acquired during the good times. Eventually, that pile is going to run out and Sun's financial folks will have to explain the nature of reality to Schwartz and McNealy. In the meantime, I can assure you that Cincom has nothing like the cash hoard that Sun built up - we would have to Pay the Piper" a lot sooner.

I love this quote that Bill Clementson repeated on his blog:

Another good summary of some of the considerations that a language designer needs to take into account when designing a DSL is spelled out in a post that Scott McKay (one of the authors of "The Symbolics Virtual Lisp Machine" and the person who said "C++ is history repeated as tragedy. Java is history repeated as farce.") made on the Lightweight Languages (LL1) mailing list over a year ago.

Heh

I've updated the Why Upgrade VW page on the CST Wiki

Chris Petrilli is completely unimpressed with the notion of adding type declarations to Python. I particularly like this comment:

So what do I do if I want to say that I just want a number. Any number will do. Or maybe I only want rational numbers? What if my int is actually a Decimal type? Is that ok?

def foo(a: T1, b: T2) -> T2 where T2 <= T1:

Holy crap. That's all I'm saying. Larry Wall, your ship has arrived. Perhaps I missed something, but this is starting to look like Dylan, which is cool, but I don't see any mention of generic functions, which means it basically comes loaded with baggage - that's empty.

Update: Peter William Lount adds his thoughts

We had a number of open meetings with customers at the User's Conference last month. I've just posted the feedback notes from those meetings.

If you follow that first link, you'll find a number of links to conference notes.

My colleague Sudhakar has been working on a series of articles for the Indian technical press; here's the first one:

The article itself isn't online, or I'd point to it. The referenced sample files are here

What's Coming in 3.8

• Lower memory consumption - the memory system has been tuned to be less aggressive about grabbing memory from the OS.
• A new font definition tool - if you don't like the fonts that are offered for display, you can now change them, and have them loaded at startup. See the System>>Define Fonts menu item
• Scripting support - Bob Westergaard created a script running tool a few months ago, and I've enhanced it by making SAX drivers available for easier script creation. See the "sample scripts" directory for a few examples - you'll need to install the plugin, and then place any scripts you create in the "scripts" directory (create if it does not exist). All scripting is in Smalltalk. Scripts support one pseudo-variable called 'runInterval'. If you wish to define it, do it like this:

runInterval := 24.

Make sure to include the period. This sets the update frequency for your script to once every 24 hours. The value will be taken as a number of hours. This plugin qualifies as "advanced" at this point - so I'm not including it with the distro. You'll have to choose to download it.

• Added a toolbar button for "Add Feed" - new users had complained that the context menu was not obvious
• More events reported from BottomFeeder:
• #bottomFeederStarting: sent with the feed viewer as an argument. Allows plugins to take advantage of startup
• #bottomFeederQuitting - allows plugins to be notified of application quit (as opposed to image quit, which is also reported)
• Regular expressions now supported for internal searching.
• Internal searches now support a "search for feed title" option
• Amazon search capability is fixed - there was a bug that prevented new searches from being defined
• On Unix/Linux, browser spawning can be customized to use a specific shell, instead of defaulting to a (possibly not installed) csh. As well, users may use arbitrary script names - the launching expression is not checked as a valid path
• Shutdown will be faster - the save files are only saved if there have been user changes since the last save
• A raft of new plugins - Asteroids, Xonix, and GoldenMonkey. Now you can waste time while your feeds update!
• A much faster and more robust HTML display component. Software With Style has upgraded their tool, which enables much better BottomFeeder performance
• Better offline browsing capability - with the local cache created by the underlying network libraries, you should see images with your feeds while offline (assuming that they have been cached)
• Two new keyboard shortcuts:
• ctrl-g: Fully expand the tree
• ctrl-h: Fully contract the tree

Lots of bug fixes, including one that could cause problems in Newspaper view

VisualWorks now supports Windows CE devices - but I recently ran across something that I had not been aware of - THUMB libraries. These are apparently 16 bit libraries for the ARM and XScale processors. We don't work with those - the question is, should we? I need some feedback from the community.

Arghhh! I simply hate the Comcast ads that claim that Comcast is better because "we're in the neighborhood". That's swell - it's really too bad that your support people are on another planet behind a no help at all desk.

The glitch that was preventing a number of us from getting our email has been fixed - all the stacked email is on it's way down to me. If I haven't gotten back to you lately, you now know why :) However, there's a small caveat - the download server still can't send mail, due to some kind of relay issue. We are working on that, but it's past 5 PM here on the east coast as I write this.

Oliver Steele thinks that Patrick Logan is mis-interpreting his points about static typing. Based on his latest post, I'm underwhelmed and unconvinced. Here's the first point he tries to make about types adding meta information:

// a and b are non-negative integers
function gcd(a, b) {...}

Structured comment:

// @param a : Integer
// @param b : Integer
function gcd(a, b) {...}

Variable name encodings:

// Smalltalk style (loses information):
function gcd(anInteger, anotherInteger) {...}
// Extended Smalltalk:
function gcd(aNonNegativeInteger, anotherNonNegativeInteger) {...}
// Hungarian notation:
function gcd(nA, nB) {...}

Umm, no. Let's try actual Smalltalk style, shall we:

greatestCommonDenominatorFor: firstNumber and: secondNumber

First off, we tend to give things meaningful names. Second, keyword style messages mean that we can encode the name and purpose of the arguments easily. The above example isn't that good, either for the point Oliver wanted to make or for the point I want to make. Here's a better one - posit some server that we want to start:

" Smalltalk style "
startServerOnHost: hostname port: portNumber queueSize: 5

// C style 

startServer (String hostname, Integer portNum, Integer qSize);

Now, without the documentation handy, it's easy to reverse the final two arguments - the fact that they are integers tells me nothing of value. In Smalltalk, that's not going to happen - the name of the method tells me what to use and where.

Here's a tip - to make a point with Smalltalk as an example, you should actually know something about Smalltalk first.

It looks like Python is about to take a bunch of back steps and gain nothing of value in the process - Guido Rossum is adding type declarations. Patrick Logan is not impressed with the proposal. While I don't know Python, I seriously doubt that complexity and rigidity are what it needs...

I'm in the process of putting up a dev build of BottomFeeder that should consume a lot less memory. The basic change is a tuning of memory layout. If you subscribe to a large number of feeds (I subscribe to 293), then the update loop can create a lot of objects that should never "tenure"- i.e., they should be scavenged out of new space immediately. What I had noticed was that Bf was growing by about 20-25 MB of memory on the first update, and then staying stable. What that meant was that objects that should have gone away were being moved to old space. Working in the runtime with a workspace illustrated this to me - yet another reason that it's very nice to have access to development tools in an honest to goodness runtime. In any event, this change helps a lot. My running application was typically consuming 105 MB - now it's taking 74.

Update: The dev build is up

So our dishwasher broke on December 26th - that's a lot of fun when you are planning on a party for 24 (we had that on January 1st). The thing should still be under warranty for the busted part - we had a local guy come out and diagnose it the next day, but parts would run $200 + if he did the work. So, we called Sears. They arranged a wonderfully convenient arrival date of today (January 3rd).

They called this morning to say "Sorry, we can't come today, our tech is backed up. How's next Monday?

After bouncing through 5 different people at Sears who desperately wanted to avoid doing anything for me, I got a woman named Angela Martinez who actually called someone with authority to do something - and we had a tech here by 1:30. Thank you, Angela. This victory was short-lived though, due to the second problem:

The tech didn't have the parts

Never mind that I had told them which parts were blown a week ago.... So he orders them. They'll arrive in 7-10 days, and he'll be back to install them on the 14th. Marvelous! Another 11 days of glorious hand washing to look forward to. So my question is, how flipping hard would it have been to bring the blasted parts I asked for? How hard would it have been for the first support person I spoke to to not try and blow me off? Do they want to drive my business elsewhere? It sure seems like it...

Slava Pestov has an early review of the JVM sources (which are now available under Sun's community license). He's not impressed; the JVM is over 3M lines of source code, and there's apparently a lot of duplication in there:

• Code duplication and copy and paste coding is routine. The HotSpot compiler includes an XML output class, written in C++. There is a regexp implementation in sun.misc, different from java.util.regexp. There's at least a half dozen implementations of UTF8 encoding/decoding in the various C++ and Java layers. There is a huge amount of code, obviously copy/pasted then search and replaced, to handle different primitive types in different situations.
• The reflection implementation is the lamest one imaginable. When you reflectively access a method or a field, it generates a class on the fly, which calls JVM bytecodes to (non-reflectively) invoke the method. Ever wondered why reflection is 100x slower than direct method calls in Java? This is why.

That last one gave me a chuckle. I think I know what happened here. Cast your mind back to when Sun acquired the HotSpot code (from Animorphic - it was originally created as a fast Smalltalk technology). Now, the things you need to do in Smalltalk to speed things up don't necessarily map that well to Java - the kinds of techniques you use to figure out dynamically typed code are not the same ones you'll use with statically typed code. What do I think happened? Well, Sun didn't put the Self team on the problem, that much is clear. They likely pulled a bunch of C programmers out and told them to "have at it". It was nearly 3 years before the HotSpot technology debuted for Java - I bet that management there followed the time honored "throw more developers at the problem" technique of problem resolution. The kinds of things above are a result of that - I'd guess that a lot of those developers never got anywhere near the HotSpot stuff - they were likely farmed out to areas where "they couldn't do much harm".

I think we see the results 3M LOC later. In contrast, the VisualWorks VM has always had a fairly small, focused team working on it - the makeup of the team has changed over time, but it's always been pretty well focused. The result? A VM that is in the neighborhood of 300K LOC (235K of C code, the rest being C header files). Now, the JVM really isn't solving a fundamentally different problem than the VW VM, so there's no good reason to make it bigger (heck, there are lots of things we plan to remove from our VM and move up to Smalltalk over time). The difference? Sounds like Sun fell victim to the age old Too many Cooks Spoil the Broth problem.

Hat tip to Patrick Logan and Chris Double for the link to this.

Patrick Logan takes on Oliver Steele's typing argument in detail:

Since Oliver already points out weaknesses in any one of the scenarios, there is no point attacking them individually. I cannot argue against the whole because I don't see a complete equation that can be analyzed. But I will point out some glaring problems he's passed over.

• Documentation Providing f(a: String, b: Integer): Boolean rather than just f(a, b) is a weak argument. What are f, a, and b? Those names, well chosen, will tell me more than String, Integer, or Boolean. Moreover using Smalltalk's keyword syntax you have even more expressiveness than this Pascal style.
• Early error detection Test-driven development eliminates the gap between coding and testing. There is no "earlier" time for detecting type errors.
• Discouraged from writing tests If your language is so bad that programmers are discouraged from writing tests, my friend, well, type declarations are not going to make up the difference.

I don't really buy Oliver's arguments either. As Patrick says, he lists a bunch of drawbacks of static typing, and then somehow claims that all those negatives add up to a positive. He better have an even number of negatives, and be using multiplication...

It's been a busy holiday season here - we had dinner for 8 at Thanksgiving, followed by dinner for 12 at Christmas, followed by dinner for 24 on New Year's day. We also had the holiday shopping, relatives, and house guests - and the dishwasher breakdown to put a cap on everything. It was a good time though, and the recent disaster in southeast asia reminded me of how much I have to be thankful for - a busted dishwasher may be a pain in the neck, but it completely pales into insignificance when compared to all that. Here's hoping that the new year is happy and healthy for all of us.

When you compare this to just adding a method where you want it, .NET generics still looks like an overly complex set of rules for "do what I want, darn it!"

Update: The .NET guy comments

I ran across Joel on Software's latest post this evening. Mostly, it's full of good advice for college students considering a career in software development - learn to write well, for instance. I'll heartily second and third that one. I can barely believe how much barely literate email I get on a daily basis. Spelling mistakes, poor grammar - it doesn't matter how good your arguments are, if you can't express yourself clearly, no one will ever hear them.

The only thing I questioned was his advice on learning C. Now, I don't dispute the value of knowing C - the simple fact is, the low level API's of Windows, Unix, and Linux are all in C. if you ever intend to drop down from a high level language (Smalltalk, Java, what have you) - it's going to be to C. Having said that, here's what Joel says:

Part two: C. Notice I didn't say C++. Although C is becoming increasingly rare, it is still the lingua franca of working programmers. It is the language they use to communicate with one another, and, more importantly, it is much closer to the machine than "modern" languages that you'll be taught in college like ML, Java, Python, whatever trendy junk they teach these days. You need to spend at least a semester getting close to the machine or you'll never be able to create efficient code in higher level languages. You'll never be able to work on compilers and operating systems, which are some of the best programming jobs around. You'll never be trusted to create architectures for large scale projects. I don't care how much you know about continuations and closures and exception handling: if you can't explain why while (*s++ = *t++); copies a string, or if that isn't the most natural thing in the world to you, well, you're programming based on superstition, as far as I'm concerned: a medical doctor that doesn't know basic anatomy, passing out prescriptions based on what the pharma sales babe said would work.

Here's the first thing - most developers simply aren't going to be writing compilers or JITS - they are going to be writing stock business applications. As such, I'd argue that knowing about exceptions is going to be a lot more relevant than being intimate with low level C details. Still, this isn't the reason I linked to this - it's the linked article that concerned me:

That opens another whole can of worms: memory allocators. Do you know how malloc works? The nature of malloc is that it has a long linked list of available blocks of memory called the free chain. When you call malloc, it walks the linked list looking for a block of memory that is big enough for your request. Then it cuts that block into two blocks -- one the size you asked for, the other with the extra bytes, and gives you the block you asked for, and puts the leftover block (if any) back into the linked list. When you call free, it adds the block you freed onto the free chain. Eventually, the free chain gets chopped up into little pieces and you ask for a big piece and there are no big pieces available the size you want. So malloc calls a timeout and starts rummaging around the free chain, sorting things out, and merging adjacent small free blocks into larger blocks. This takes 3 1/2 days. The end result of all this mess is that the performance characteristic of malloc is that it's never very fast (it always walks the free chain), and sometimes, unpredictably, it's shockingly slow while it cleans up. (This is, incidentally, the same performance characteristic of garbage collected systems, surprise surprise, so all the claims people make about how garbage collection imposes a performance penalty are not entirely true, since typical malloc implementations had the same kind of performance penalty, albeit milder.)

Hmm - now I'm no expert on garbage collection, but I spent plenty of time working in C a decade or so ago, and I've spent all the time since in Smalltalk. Modern gc systems do not have the problems that malloc has - and moreover, they remove memory management from the error ridden hands of the application developer, and put it instead in the hands of a framework with global knowledge of the application. It's a huge win for all concerned - better performance for all but the smallest proportion of applications (such as those living in embedded systems with constrained resources). Joel is spreading bad knowledge here - not unlike his complete lack of cluefulness on exception handling.

I think Joel is getting to the point where he just doesn't know what he doesn't know...

Patrick Logan continues the conversation on typing by linking to Oliver Steele, who's in favor of optional typing. I don't really buy Steele's arguments either, but it's a good exposition of that point of view.

I made a small change in the BottomFeeder development stream last night that eases the memory consumption of the application. The HTTP client library we use, Net Resources, has two levels of cache - disk and in-memory. Up until now, the application has been keeping that cache in memory as it ran. What I've done is added a setting - if it's false (the default), then the cache is not held in memory (except during the update loop) - it's only on disk. For my running copy, that dropped the appetite of the app by nearly 20 MB.

Michael has started looking at making the content for cached items demand loaded (instead of the current all in memory model). I doubt I'll get that into the soon to be released 3.8 - it's too radical a change. Once we get that in, it should lower the runtime footprint of Bf dramatically.

Another comment I've gotten has been on the cpu load during the update loop - grabbing the RSS feeds and processing them in a threaded update loop is fast, but it can be expensive in memory and cpu terms. I added an option awhile back that lets you slow that down - if you look under Settings>>Network, check the Slower Update Cycle option and turn threaded updates off. What that will do is sequence the updates across the update interval you've chosen. So, say you subscribe to 60 feeds, and you have set the cycle to 60 minutes. If you toggle the settings as listed above, each http query will be separated by a minute - and when they are all done, there will be an hour's delay before the next update. This was in response to numerous requests, and setting it up that way should make the application less resource intensive as well.

This is interesting news. Sounds like Delta is going to break ranks and stop punishing business travelers who don't want to sacrifice their weekends:

The biggest present for airline passengers, though, may be from Delta. Next week the nation's second largest carrier is expected to become the first of the so-called Big Six (American, Continental, Delta, Northwest, United and US Airways) to radically change its pricing policy nationwide, removing irritating ticketing rules like required Saturday-night stays, halving ticket-change fees to $50 from $100 and slashing fares on everything from first class to last-minute tickets.

If that is the case, then the other major airlines will have no choice but to respond - and that response will trickle through the entire travel industry. Hotel and rental car pricing is built around the saturday stay assumption - look at all the "weekend get away" marketing you see from hotels. It's not that the concept of a quick holiday will be destroyed - but a lot of the underlying price support for it will dry up. You know what the slowest thing to change in light of this will end up being? Corporate travel policies....

It's not always easy for a software company to deal with open source issues. Cincom, for instance, makes the vast majority of its money via software licensing and sales, so it's a very controversial issue internally - which explains why you don't hear us talking about it much. If you haven't figured out a story line yet, it's probably best not to have the inconsistencies dissected in public - witness Cafe au Lait Java taking Sun to task, for instance.

Chaos is a party where 10 kids (all 11 or younger) arrive, and there are only 4 positions available in the GameCube. Add chocolate and soda for fuel, stir until the headache arrives :)

Information Week has an interesting little roundup of underrated and overrated stories for the year. Here's a snippet of one you've seen me comment on before:

But the smoke generated by the offshoring debate obscured the big picture, which has to do with an increasingly global economy and the changing nature of technology work. And short-sighted executives, bent on offshore outsourcing for bottom-line reasons only, may risk trading innovation and competitive advantage for short-term gains. Wal-Mart Stores Inc., the world's biggest retailer--and arguably the most tech-savvy company in any industry--does all software development in-house. "We'd be nuts to outsource," says CIO Linda Dillman (see "Wal-Mart's Way," Sept. 27, 2004). Outsourcing in general, including offshoring, is a valuable business-technology strategy. But it needs to be employed for the right reasons.

Another interesting one on Open Source, another topic I've commented on from time to time:

Compare Red Hat Inc.'s midtier standard price for Linux with tech support ($799) to a roughly comparable Windows Server 2003 license from Microsoft ($999), and you begin to see how the numbers really crunch. And those are just list prices. Among the revelations to surface in the Justice Department's failed attempt to block Oracle's proposed takeover of PeopleSoft Inc. was eye-opening evidence of deep discounting. Penny-pinching CIOs can play Red Hat against Microsoft, Microsoft against Oracle, and Oracle against SAP.

In addition, there are costs associated with open-source software that aren't always obvious. Yankee Group analyst Laura DiDio reports that in-demand Linux system admins can command salaries 20% to 30% higher than Windows staffers. In addition, third-party tools and intellectual-property insurance can jack up the overall cost of open-source environments even more. So, here's how to do the math. Add up all the costs to run an open-source stack. Subtract thousands of dollars in concessions from proprietary-software vendors anxious to negotiate. The difference might be less than you think.

There's also a slap at bloggers in there, and a few other things of interest. Have a look.

Here's an interesting thing - JetBlue pulled out of Sabre last month:

JetBlue Airways Corp. said this week it plans to drop out of the Sabre electronic ticketing system by Jan. 1, a move that could cause other airlines to follow suit.

Bookings on Sabre, the software system operated by Sabre Holdings Corp., account for just 2% of JetBlue's sales, says sales and distribution director Noreen Courtney-Wilds. But sales through Sabre have been the airline's most expensive, while it's keeping costs down by funneling business and leisure travelers through its Web sites, she says. Revenue from ticket sales through Jetblue.com and a corporate travel Web site launched in June accounted for 75% of JetBlue's third-quarter sales.

Hmm. Later in the same article I found out that Southwest was part of Sabre - I had thought they weren't. Apparently, Sabre (and the competing Galileo) charge something like $5 per segment booked - so a round trip to Europe from where I live might end up throwing $20 at Sabre when the Cincom travel agency books it. That's a significant cost. The article notes that Sabre and Galileo intend to go ahead with their annual price hikes.

I guess the question is, is JetBlue a harbinger of things to come, or a one-off? On the one hand, pulling out of a system like Sabre early means that corporate travel services are less likely to find your flights; it's unlikely that an agent is going to bother juggling 3 or 4 (or more) different travel systems. on the other hand, being able to drop your prices by doing so could give you an edge. It'll be interesting to see how this goes - will more airlines jump, and will Sabre realize that they might be facing immediate disintermediation?

Comcast decided that there wouldn't be internet service today. Which is mostly not a problem, because we are having a party this afternoon. In the meantime, my wife wanted to print out a grocery list. But nooo - just in case I thought Word was extra stupid, WordPerfect is here to show me a deeper level of insanity - the printserver that is part of WP fails if there's no network connection - even though all I want to do is print to the local printer. Gah!

Ok, so we save the file in RTF to a shared drive - the idea being that I'll pick it up and print from my notebook using Word. Sounds simple, right? All I want to do is grab a file from the local LAN - I have no need to see the internet. Windows networking seems to think differently. Even though I'm only browsing a shared drive on a local PC, each directory navigation is taking something like 60 seconds to navigate - apparently, some deeply stupid part of Windows networking is trying to do a WAN lookup as a navigate the local LAN. It's not just a simple socket timeout thing either - it's taking way too long for that.

I think the problem is that Windows thinks there's a WAN connection, because it was there when Windows booted. I see this in BottomFeeder on Windows - if I bring it up without there having been a network connection, any socket connections time out instantly - whereas they take 20 seconds each if the connection was there and dropped. This is far, far worse though - Windows networking is taking minutes to navigate from directory to directory on the local LAN, when it shouldn't even care about a WAN connection.

The befuddling part is that LAN access from my wife's machine was normal speed - so I was finally able to grab the document by pushing it from her end. Utterly baffling - I have no idea why that should be....

Ok, get ready for two bad jokes I ran across:

"A dyslexic man walks into a bra..."

"Did you hear about the dyslexic, agnostic insomniac? He stayed awake all night, wondering if there really is a dog. "

You can groan now :)

Podcasting - it's all about Dave, apparently.