Smalltalk Tidbits, Industry Rants

Derek found out that when it comes to college grades, you actually do have a "Permanent Record". As much as we laughed, it sounds like Mrs. Grundy wasn't kidding....

shaykatc - and I'm sure other .NET developers - are drooling over this:

Ok - so what scenario would I use it in? Lets say you're writing some managed code. You're debugging your merry way through the code when voil, it crashes. Sigh. You see the little error dialog with additional information but to explore your code you have to dismiss it. As you go through your code, you wonder what that message said again? So you write a try catch and repeat the process.

Well, in Everett the debugger team put in a little feature called $exception. The next time you crash in C# or J# go ahead and dismiss the dialog. Open the locals window and take a peek at $exception there (chills are setting in right now). Expand it and you can see all the delightful things inside the Exception object - Messages, Stacktrace, Inner Exception etc - everything you would have gotten had you put a try catch around the code and caught the exception object. Is that cool or what?

Oh boy. You can see all that information? You mean, the sort of stuff that Smalltalkers have had for years and years? Here's the real question for shaykatc - can you go back through the stack in the debugger, change code and restart? It's always amazing when developers get excited about stuff that has been around in mature, productive tools for decades....

I saw this comment on Planet Lisp:

I certainly agree that the mismatch between memory and CPU performance supports the conclusion of the paper -- tagged memory and micro-programming would probably be beneficial in a big way. (Of course, given how manystupid buffer overrun viruses there are these days, it's hard to believe that anybody can still think that not having manifestly-typed data is defensible.)

The term manifest typing must mean something different in the Lisp world than what it means to me....

I'll remind Joel - and MS - that it doesn't have to be tradeoff between a linker and a runtime system. BottomFeeder is built in VisualWorks Smalltalk, which is a VM/Image based runtime system. And yet, I ship a 7 MB single executable for Windows - which is field upgradeable. It not only can be done, it has been done. Perhaps the MS engineers need to look up at the rest of the industry every so often...

Jon Udell points to Dare's post on not being able to read Atom feeds in RSS Bandit - by saying "sure you can", and pointing to Atom2RSS:

How? Just search Google for atom2rss. There are a bunch of translators floating around. The one I picked comes from the folks at 2rss.com. Here is their translator: http://www.2rss.com/software.php?page=atom2rss. And they are kindly making this service available for free. You can go to the site, plug in an Atom URL, generate the corresponding RSS URL, and subscribe to that.

That glib "just follow these simple steps..." misses quite a bit. First off, here's what most people are going to do (assuming they understand aggregators, which is assuming a lot already):

• Try to add the feed from the page in question to their aggregator
• Watch it fail
• Move along, figuring that either
• The feed is broken
• Their aggregator is broken

The liklihood of your average aggregator user deciding to do a search in Google for format translators is too amusing for words. Heck, I announced this PR Feed internally, and got 2 emails from people in my group asking what they were supposed to do with an XML file that showed up in their browser as a DOM tree. I've been working on BottomFeeder for a long while now, and - even so - plenty of people in my own work group have no idea what a feed is. Expecting an end user to go find a conversion tool is a fantasy - other than a handful of highly motivated geeks, it's simply not going to happen.

The simple truth is, aggregator authors have to just buck up and support this new format. I've written more than once on what a colossal waste of time and effort I think the Atom syndication format is, but it doesn't matter what I think - my users don't care about the "inside baseball" aspect of all this. They want to read content when they find it, and would prefer not to have to care about any of the technical details. Expecting them to wander off in search of a conversion site is expecting them to know about details they shouldn't have to care about - and more importantly, about details that they just won't care about....

I've posted a new set of change information on our Wiki - details the changes that have been made between VW 7 and VW 7.2. It's not complete; I did this only with a base image. However, the scripts I used are available for download - so if you want to look at the changes specific to a component (like, say, the Web Toolkit) - just grab the scripts and follow the instructions.

Dare points to the rising number of Atom feeds coming out of Blogger (the default choice over there now) - and laments that he can't read such feeds with RSS Bandit. I'm kind of surprised that he hasn't added suport; it was pretty simple to support Atom 0.2 (I added that months ago, because one of the users of BottomFeeder actually asked for it). I ignored Atom 0.3 for awhile, but then I got an email from someone telling me that Bf was handling 0.3 feeds oddly. I added a new handler for 0.3, and all was well again.

Here's why it's not that hard for me to add new formats, so long as they are relatively close in spirit to RSS - I don't keep the XML documents around. Bf parses the XML document, and then a framework originally designed and built by Dave Murphy maps all the relevant information to an object model. It turns out that the object model we built for RSS applies to Atom easily, so it was just a matter of mucking with the object mappings in a new handler class. When I finally added Atom 0.3 support, it took me about 20 minutes.

Back to the original topic. While Dave Winer assumes malice, Dare assumes the much older rationale - stupidity:

1. Always and inevitably everyone underestimates the number of stupid individuals in circulation.
2. The probability that a certain person be stupid is independent of any other characteristic of that person.
3. A stupid person is a person who causes losses to another person or to a group of persons while himself deriving no gain and even possibly incurring losses.
4. Non-stupid people always underestimate the damaging power of stupid individuals. In particular non-stupid people constantly forget that at all times and places and under any circumstances to deal and/or associate with stupid people always turns out to be a costly mistake.
5. A stupid person is the most dangerous type of person

Unless Google does have something up their sleeve?. Who knows? In the meantime, I support the Atom format, regardless of how many bricks I throw at it....

Via Scoble I found this article on the PR biz, and how blogging impacts it. Interesting read:

Public Relations is about communicating with audiences. Your job is to understand how to reach those audiences, how to deliver information to those audiences in a format that they find acceptable. We're not just talking about the media here. PR is about good communication to every audience, that includes customers, partners, staff, suppliers etc.

If you are not trying to reach and communicate with the relevant audiences for your organization or client, then in my humble opinion you're not doing you job.

This puts blogging in the proper light - it's not the solution for corporate communications, it's a solution. It doesn't replace anything completely, but it does add to the list of communication forms.

Looks like there are uses of atom as a module inside RSS 2.0 feeds - have a look here. I'll be taking a look at adding a module for that...

I've got some travel coming up in the next few weeks and months. Next week, I'll be in Houston, TX on Monday and Tuesday, and then Dallas, TX on Wednesday and Thursday. I'll be visiting a bunch of customers - listening tho their concerns, and letting them know what's coming for CST.

Then in March I'm off to Europe from the 20th of March until April first. Two days at CEbit, visits to a bunch of German customers, and a meeting with the Frankfurt STUG. Then I head to the UK to attend and speak at ot2004.

May brings Smalltalk Solutions, May 3-5 in Seattle WA. That should be a lot of fun, and I'll be speaking about BottomFeeder.

Then in the fall, I'm hoping to speak at ESUG - haven't gotten a definitive answer yet though. Looks like my passport will get a lot of stamps :)

The Medicine.Net feed has the following message for every item this morning:

"The log file for database 'MNI' is full. Back up the transaction log for the database to free up some log space. "

Looks like someone has a mess...

I gave the BottomFeeder presentation at the NY STUG this evening. We had a small crowd, but they were interested in both the application and in the process I've gone through in building it. This was kind of my first take on the presentation I plan to give at StS 2004 this year; I'll be working more on the slides and presentation based on how it went. It's always good to catch back up with the NY crowd.

I'm on my way to NYC to speak at the NYC STUG about BottomFeeder. Like any speaker, I'm doing my slides at the last second (on the train!). I actually had various parts of the presentation "lying around", but they weren't really in a coherent whole for a technical presentation yet - so I spent mch of the ride doing that. That's one of the things I really like about taking Amtrak to the city; I have time to get work done - and I still get to Manhattan faster than I would by flying. I was kind of hoping to find some WiFi on the trip, but I expect that I'm moving too quickly, and too far away from residential areas to boot...

Via Scoble comes news that intel has cried uncle in the 64 bit market - they are unveiling a 64 bit x86 chip:

Intel Chief Executive Craig Barrett said today the chip maker will offer a new version of its Xeon chips for the low-end computer server market that will mimic the capability of chips from rival Advanced Micro Devices.

The company said the new chip currently code-named Nocona, offers the 64-bit capability found in AMD's Opteron family of chips for servers. This spring Intel will offer both a Xeon for low-end servers and a 64-bit version of its Prescott Pentium 4 chip for workstations with single processors.

I like the attempt to salvage their pride over the itanium by claiming that this is only for the "low end" server market...

India's Linux for You magazine spotlighted Smalltalk in the January edition. I can't get a link to that month; their archives seem to be confused. Here's a quote from the article:

If one peers around the Smalltalk classes written entirely in Smalltalk, you would notice the strong Unix base that carries through. For instance, in the sockets code you have a complete re-implementation of the BSD sockets, and process creation is the very familiar fork calls with the simplest threaded call implementation. This makes the language a lot more familiar for the Linux user.

Being platform independent, nearly all dialects of Smalltalk support Linux. The major ones include:

• VisualWorks: Currently the most aggressive Smalltalk platform. It is supported widely by both enthusiasts and corporate development and is now positioned as a 4th generation application development platform
• VisualAge: The IBM version that has been the industry favourite for over a decade but is now taking a back seat to IBM 19s Websphere.
• Squeak: For open source enthusiasts, academics, and especially school kids, this is the best. It lacks features for corporate level multi-user, scalable solutions but touts the new Morphic UI architecture.
• GNU Smalltalk: An efficient, mature and contemporary implementation.

Smalltalk X: A commercial version having an efficient compilation system that can compile to a C level binary code once the development is done.

Very cool to see more trade press notice!

Blaine Buxton has a few words to say about the all too common perception that developers are interchangeable:

I've always been bothered with the notion that programmers are interchangeable parts. Technical managers that I have had seem to think we are all the same. Cut from the same tree if you will. Am I the only one that thinks this is hog wash? Like anything in life, there will be people that rise to the top of their field and be the best there is. But, it seems people think that programmers are all the same. I find this bothersome. I've known managers that thought they could pull anyone off the street and in 6 weeks have a good programmer. Would we expect to do the same with musicians? Just pick anyone off the street that knows nothing about music and expect them to play a mozart concerto flawlessly after the same period of time? I think the answer would be no! Would we expect to take even a first year english student and expect them to write poems the caliber of William Shakespeare? HELL NO WE WOULDN'T! So, why do we expect the same from programmers?

Blunt, but very much on point. Maybe we should start assuming that senior managers are interchangeable. When that gets the obvious objection, let the other shoe drop...

I saw this in cls and the Camp Smalltalk mailing list - Camp Smalltalk near Portland, OR:

I'm pleased to announce that we will be holding a Camp Smalltalk from July 18-23 2004 in the vicinity of Portland, Oregon, USA.

To finalize our space reservation, we need to place a deposit on a minimum of ten sleeping room reservations. We expect more than that to attend, but we need at least ten definite attendees to step forward and send in a deposit now. We must receive the minimum number of deposits BY MARCH 5. If you want to make a reservation, see below for details.

The basics:

What:
Camp Smalltalk. Smalltalk enthusiasts spending several days in small groups collaborating on a number of open-source projects to benefit the Smalltalk community. All Smalltalk dialects welcome. For more details, see http://campsmalltalk.com

Who:
Smalltalk enthusiasts. All experience levels are welcome, from "Using Smalltalk for more than 20 years" to "Fascinated by Smalltalk, but never really used it."

When:
Afternoon of Sunday, July 18, through midday Friday, July 23

Where:
McMenamins Edgefield
Troutdale, OR, USA
http://mcmenamins.com/Edge/index.html

How Much:
The main cost is the lodging and meals package at Edgefield. You're responsible for getting yourself there. All prices given include room, meals, gratuities, and tax for all five nights, and are in $US.

Single-occupancy King or Queen or Double Queen room: $600
Single-occupancy King or Queen or Double Queen Suite with bath: $952.50
Double-occupancy King or Queen or Double Queen room: $530 per person
Double-occupancy King or Queen or Double Queen Suite with bath: $787.50
per person

There are very few rooms with two beds -- if you want one of these rooms register soon.

We're looking into high-speed internet access, which would have some additional cost. We will not commit to additional cost without the approval of those who have registered.

Facility Details:

Location
McMenamins Edgefield, Troutdale, OR, USA
http://mcmenamins.com/Edge/map.html
A 15 minute drive east of PDX, the Portland Airport
It's right on the edge of the Portland Metro area, five minutes from the hiking and waterfalls of the Columbia River Gorge. It's easy to reach by public transit from either PDX or downtown.

General Feel
A private brewpub-based resort at a lovingly and quirkily restored historic campus of buildings -- lodgings, restaurants, brewpubs, winery, gardens, movie theatre, and more. Even a little golf course. Filled inside and out with interesting artwork http://mcmenamins.com/Edge/art.html). Even a working hot glass studio on the grounds. Hillside location with views across the Columbia River.

Work Room
We'll be in the main ballroom, which is generously sized (36x68 feet, 11x20m), on the second floor of the main lodge, with many windows on three sides and a huge mural on the walls. The view is away from the river.

Sleeping Rooms
Mostly European-style rooms, with private baths down the hall. Some suites with bath are available at a higher rate (see above). Most rooms have one bed. A few two-bed rooms are available -- send in a deposit soon if you want one of these.

Meals
Meals are included with room. If we eat in fairly small groups in their restaurants, they'll give us vouchers good for up to a specified amount for each meal. The Black Rabbit Restaurant (http://mcmenamins.com/Edge/brabbit.html) is very good, and the Power Station Pub (http://mcmenamins.com/Edge/pub.html) also has good stuff. Voucher amounts will be $10.50 for breakfast, $16.95 for lunch, $26.25 for supper.

Activities
On-site: Golf, evening movies, wandering around looking at interesting stuff (brewery, winery, distillery, artwork).
Fairly short drive: The Columbia River Gorge
(http://www.fs.fed.us/r6/columbia/forest), with hikes and viewpoints for amazing waterfalls and volcanic cores, Bonneville Dam, mountain viewpoints and more hikes. About the same distance to downtown Portland.

Longer drive: Mount St. Helens, Mount Hood, boardsailing or kitesailing on the Columbia, etc., etc.

Registration
To register, print out the registration form available at http://wiki.cs.uiuc.edu/CampSmalltalk/Camp Smalltalk Oregon 2004 and send it with your deposit to:

Martin McClure
GemStone Systems
1260 NW Waterhouse Ave, Suite 200
Beaverton, OR 97006 USA

To help us reach our minimum, and to guarantee you a room, we must RECEIVE your deposit by MARCH 5.

For details, check the FAQ below, or the latest info at http://campsmalltalk.com

FREQUENTLY ANTICIPATED QUESTIONS ABOUT REGISTRATION

Can I pay by credit card or purchase order?
Unfortunately, no.
We are using Edgefield's special "midweek retreat" package, so they cannot accept payment directly from individual participants. We must make lump payments, so an individual is coordinating the payments.

When will the remainder of the payment be due?
Final payment must be received by July 12. Again, check or money order in US$.

What if I can't make a commitment now, but I decide later that I can attend?

We will have a reserved block of sleeping rooms for only the deposits received by of March 5. Some rooms will probably be available until sometime in May or June. After March 5, check http://campsmalltalk.com about room availability and how to send a deposit.

Is my deposit refundable?
If we cancel the planned event on March 5 due to lack of deposits, all deposits will be refunded. If you have to cancel after March 5, we will try to transfer your registration to someone who registers later. If that is possible, you'll get your deposit back. If not, you will not get your money back.

Can I participate in the Camp Smalltalk sessions without staying at Edgefield?
Yes, provided we have enough people in paid sleeping rooms. If you are not staying at Edgefield, you can still buy meals at the Edgefield restaurant or pub. If you plan to attend but not stay at Edgefield, please send email to Martin.

What if I have more questions?
Get the latest info at http://campsmalltalk.com

You can access the Cincom Press Releases via RSS now - here's the feed. This is the little project I mentioned the other day

Troy Brumley has joined the Cincom Smalltalk blogging community. Subscribe to his feed here.

Apple has made rss feeds available for iTunes.

John Porcaro notes that someone is blogging for the Mars Rover. And there's a feed!

ISerializable is writing a series on adding scripting to an application. The reasons he gives for it are good ones:

Adding scripting support to your application is one of the most valuable things you can do for your client, letting them add value to your software, and keep it current over time with little or no overhead from the developers. Your users will be able to modify behavior at runtime, change business rules as the market changes and fix subtle bugs as they appear until better fixes come along in the form of compiled code. It is one of the most powerful techniques today employed my many varied business applications. But guess what? Its not very easy to do in .Net.

Now for the punchline - BottomFeeder has scripting support - on all supported platforms - in the same language the application was built in. And I didn't need to do anything to add it. All I had to do was deploy the application without removing the compiler. Here's how you can use it at startup - create a Smalltalk script, and save it in a file called ".btfrc" - put that in the same directory with the application. At startup, that script will be loaded.

I don't have a nice way to pop up a runtime workspace, but it can be done - Vassili explained how. So yeah, adding scripting support is a very nice thing - take a look at what Bob W does with it, for instance. I'll be interested in seeing how one does that in .NET

This article goes a long ways towards explaining what's so cool about Smalltalk, without ever even mentioning it. After talking about the Dorado and the Star (and what differentiated them), this example explains it:

At best I think most people ask "What could people do with this computer". That's a very different question from "What people will people do with this computer"... there are so many nifty features that if people pushed themselves they could use, but have a high enough barrier to entry that people don't bother.

Example: I have a nice thermostat in my apartment. Its fairly well designed and has quick push buttons for "Daytime", "Night" and "Vacation". It was even straightforward to set these to my preferred temperatures for "In the apartment, awake", "Out of the apartment or asleep", and I haven't bothered with the vacation button. Now I have noticed that I don't like to get out of bed in the morning because it is sort of cold. In fact, sometimes I'll lie in bed for 30 minutes because its cold, which is a big waste of time (I'm not very rational when I'm waking up). I have noticed that my thermostat supports scheduling changes between day and night temperature. I even looked at the instructions beneath the faceplate, and it looks like it'd be fairly easy to program. But I haven't done it. The device is usable in the sense that if I wanted to, I could program it, and probably get it right on the first or second try. Its not hard to use. But its a little too inconvenient, because I'd have to special case my weekend schedule, I'd have to set several different times using the fairly slow "up", "down", "next item" interface for setting time (on most alarm clocks etc). The point is, its not hard to figure out, but its stills too much hassle. So while I could program the thermostat, I won't. There's always something that seems better to do with my time, and I can't be bothered (even though rationally I know it'd be better overall if I just program the silly thing).

In a nutshell, that explains the difference between the way Smalltalk or Lisp developers work, and the way C, C++, or Java developers work. It's hard to create tools for the environments that curly bracers work in (excepting Emacs - many people working there write elisp macros to help themselves). Sure, you can create Eclipse plugins - but how many developers actually do it? It's a fair bit of work, and takes effort that most people won't expend (like the thermostat). It's not a matter of can't; it's a matter of won't. Smalltalkers are always making little tweaks and additions to the environment - because the barriers are low. This is one of the reasons I favor image based development - it lowers the barriers for productive twiddling.

There's a 3.3 stream and a dev stream update available for BottomFeeder. I ran across a bug report from Peter, and found an issue in the display logic for feed items that came from Atom with only the summary object filled in. I issued a bug fix, and now his feed can be viewed just fine. Thanks for reporting the bug!

Patrick Logan makes some excellent observations about security, closed source, and open source, ending with this:

Open source that is poorly designed is not safe. Closed source that is poorly designed and then released in the open is even less safe.

That's an excellent point, and - in a nutshell - the problem that MS faces with Windows

Here's a nifty Smalltalk article in JOOP - covering concurrency and how to build new control structures using the BlockClosure class. This is all in the context of the ControlWorks framework, a real-time process control development toolset sold by Adventa. Smalltalk is used in the most amazing places :)

It's too bad I'm not in the Triangle Research Park area - I'd love to attend this talk on the Roller architecture - especially the "lessons learned" part. I'm going to be giving a similar talk at Smalltalk Solutions and at the upcoming NYC STUG meeting. I'll be talking about BottomFeeder, but will likely have notes on my blog server as well. I'd be very interested in hearing another blog server author talk about the issues involved in building and deploying a server. Sounds interesting!

Scoble worries about outsourcing:

Anyway, Rajesh Jain's weblog points to the New York Times analysis. Do we really need to analyze this? Let's see. Average Chinese worker gets paid about $1000 a year. Yes, that's right. In Bejing the number goes up to $2500 per year. How much are you paid? I am paid a lot more than that. Is there pressure to send my job over to China? You betcha there is.

There's an interesting counterpoint to some of this in the latest ComputerWorld. To answer Scoble's assertion that there's pressure to move a job like his overseas - all I can do is chuckle. He's in a communications heavy job - he's meeting with customers, reporters, and fellow MS staff on a day to day basis as part of his (as I read it) evangelical job. It's far more likely - if MS is successful in India and China - that they'll nee local equivalents of him someday. I rather doubt that a guy in China, many, many timezones away, is hoing to be able to keep up the same communications schedule that Scoble does. Even in the universe of "grunt development" there are issues many people forget:

• Transitory cost increases - from severance costs, declining morale, people jumping ship, travel costs.
• Long term costs - travel to the outsourcers location. If that's China or India, it's not the same thing as a "quick" cross country trip. There's also a soft costs here - what are the spouses of your staff going to think about 2 and 3 week jaunts to the far side of the planet?
• Contract management - if getting agreement on requirements was hard with people a building over, how hard will it be to manage with people 12 time zones and a culture away? Language will not be the only issue here - just the most obvious.

This is not to say that savings don't exist; they do. They aren't going to be as much as most people think though, and there will be communications issues that crop up. Like other trends in the industry this one is no silver bullet - not to mention the fact that we've seen this all before - textile jobs, for instance, went from New England to the south and then overseas. The main difference today is the speed of the transition - software matured and started moving faster than things like textiles did.

Larkware News has the following rant:

Unification Policy - Alan Shi explains one of the fine points of the CLR's binding policy. I fear I've reached the same point with this stuff that I did with Godel, Escher, Bach: I understand it right after I read it, but my brain can no longer hold on to it. I think .NET has replaced DLL Hell with a binding policy so complex that it might as well be a purely random selection of which DLL to load, for all that an average developer understands what's going on. It is not at all clear to me that this is an improvement so much as just a different set of problems. Or perhaps my brain is just too puny to work at Microsoft.

First, let me state up front that I've not looked at the binding policy in .NET - I will say that the referenced explanatory page is hard to digest. This is not a problem limited to the CLR though - we are in the process of trying to address these issues in Cincom Smalltalk, and it's not a simple set of problems. We are hoping to have the beginnings of an answer out with VW 7.3 (fall 2004)

We have an update on the keynote speakers for StS 2004 - George Bosworth, one of the architects of the CLR at Microsoft. I'm sure that lots of people in the Smalltalk community would like to hear about the design decisions that have been (and are being) made in the development of the .NET CLR - come on out to Seattle to hear all about it. This year's conference is May 3 - 5 in Seattle, at the Crowne Plaza. Register today - the early registration discount will be expiring soon.

The Red Sox can't close the deal - the Yankees grabbed A-Rod. I love this commentary in the Times sports section:

But what chance do the Red Sox really have of winning on the field? Sure, the teams have to play 162 games, but the Red Sox could lead the Yankees for 161 games and still lose to them. They could have a three-run lead and be five outs from going to the World Series and - oh, right, that happened last October.

Heh. Pack it in, Sox fans :)

One of the Planet Lisp guys reacts to the Livschitz article:

I feel like jumping up and down and shout: "Lisp, just use Lisp!". Of course she would't know better. She probably never saw a Lisp Machine, let alone experienced one. It makes me sad/mad just reading it. It's almost as bad as this terrible book by Marilyn vos Savant (the woman with the worlds highest MENSA certified IQ) about Andrew Wile's proof of Fermat's Last Theorem.

Yep. Just like I wanted to hop up and down and yell Smalltalk!

Our marketing folks wanted to put together an RSS feed for Cincom's press releases, but weren't sure how to proceed. All the releases live in a database (SQL Server) with all the info necessary to create a feed - it just had to be put together. This is one of the places that most people would reach for a scripting language like Perl, or something like PHP. I reached for Smalltalk, of course, and it turns out to be pretty simple to support a small job like this in VisualWorks. Here's what I set up

• I created a small, loadable package that reads the data from the DB and dumps it to an RSS file
• The package depends on a small settings file to figure out what to read and where to write
• I created a small (4 MB) Windows executable with the package pre-loaded, and ready to run at startup

On the server in Cincinnati, this thing starts, reads from the db, writes the RSS file, and quits in less than 3 seconds. I was amazed, to be honest. Better yet, it's easily updated from my office in Maryland. If I need to change the code, it can reload the package at startup from an application directory, and then run with the new changes - so if anything big needs to be done (for instance, someone decides we need an Atom feed as well) - it can be updated without my having to make any changes to the executable itself, and it'll "just work" on the next run cycle. It's going to be set up as the Windows equivalent of a CRON job - run every N hours (days, whatever). So brush aside your preconceptions - Smalltalk is easily used for this kind of "small" job!

There's been a fair bit of commentary on the Livschitz article that I commented on yesterday:

• Sean McGrath commented three times: here, here, and here
• Danny Ayers weighed in here
• Patrick Logan had some more favorable thoughts here

Danny's comments are pretty close to where I came in on the article. I still say that much of what she's talking about exists in Sun's R&D labs, if only she'd go take a look :)

Like a lot of people, Sun's Victoria Livschitz confuses strong typing and manifest typing. Here's a quote:

The preventive measures attempt to ensure that bugs are not possible in the first place. A lot of progress has been made in the last twenty years along these lines. Such programming practices as strong typing that allows compile-time assignment safety checking, garbage collectors that automatically manage memory, and exception mechanisms that trap and propagate errors in traceable and recoverable matter do make programming safer. The Java language, of course, personifies the modern general-purpose programming language with first-class systemic safety qualities. It's a huge improvement over its predecessor, C . Much can also be said about the visual development tools that simplify and automate more mundane and error-prone aspects of programming

Strong typing isn't the same thing as manifest typing. Smalltalk, for instance, has strong, dynamic typing - an object simply will respond to an inappropriate message in a completely predictable way. Take Java though - you can make the compiler completely happy with a cast, and then end up with a system that falls down at runtime. Languages like Java and C encourage casting - the rigidity of their libraries, the "final" declarations, the way the collection libraries work - you can walk yourself into trouble with MNU handlers in Smalltalk, but you are picked up and driven there by many existing libraries in Java. Maybe Ms. Livschitz should look at what Sun produces before she makes assertions like the above. Strong typing is a good thing - it's really too bad that Sun doesn't encourage it. What she needs to do is go pick up one of the many fine books on TDD - I'd recommend Beck.

There's more:

Q: How well do you think modern programming languages, particularly the Java language, have been able to help developers hide complexity?

A: Unfortunately, I believe modern computer science and software engineering have failed to make significant advances there. The syntax of all mainstream programming languages is rather esoteric. Mathematicians, who feel comfortable with purely abstract syntax, spend years of intense study mastering certain skills. But unlike mathematicians, programmers are taught to think not in terms of absolute proof, but in terms of working metaphors. To understand how a system works, a programmer doesn't build a system of mathematical equations, but comes up with real-life metaphor correctness which she or he can "feel" as a human being. Programmers are "average" folks; they have to be, since programming is a profession of millions of people, many without college degrees. Esoteric software doesn't scale to millions, not in people, and not in lines of code.

Fascinating. The current mainstream languages are Java and MS' "Son of Java", C#. Physician, heal thyself. Go download a Smalltalk, Ruby, or Python system. Heck, go back to your very own research labs and look at Self and Strongtalk - see what your company could have been encouraging instead of what it is encouraging. She says she wants to improve things; a trip to Sun's R&D labs, along with some internal evangelism would help a lot.... But wait!

I envision a programming language that is a notch richer then OO. It would be based on a small number of primitive concepts, intuitively obvious to any mature human being, and tied to well-understood metaphors, such as objects, conditions, and processes. I hope to preserve many features of the object-oriented systems that made them so safe and convenient, such as abstract typing, polymorphism, encapsulation and so on. The work so far has been promising.

She really, really needs to visit the Sun research labs. They already have something a lot like that, called Self. It's been around for years, too. Unintentionally amusing, this article... Further down, the "holy grail" of component based development is raised again. I'm not even going to bother quiting that; more tears and virtual ink have been spilled on that subject than anyone can count. I have little faith in positive progress in that direction; reuse is non-trivial, and I just don't see it getting a lot better anytime soon. Take a trip to the Sun R&D labs, and take a look at what Sun has left withering on the vine.

I was going to give a talk on Bf in NYC last month, but snow intervened. That talk has been rescheduled to february 18th - this coming Wednesday. I'll be talking about BottomFeeder development - sort of a mini-case study of doing application development and delivery in VisualWorks.

Ruby Developers now have traits support - something Squeak has had for awhile. Traits are described here. There's an interesting comment on ease of development with traits in the article:

Despite that, I'm still not sold on the Traits concept. I'm not sure that sprinkling methods over a distributed set of Mixins would be fun to maintain, on a large scale. The Squeak implementation took advantage of the browser: you only ever see one method at a time in Squeak (smalltalk) code, anyway, and if the browser integrates with Traits, you could view and edit the methods as "part" of the class anyway. With Ruby, without a great IDE, you'd need to flick across files and use a bit of imagination to get a good "view" of your composed class - to even see what methods it's composed of. I believe that traits lose a good deal of their appeal without the Smalltalk browser, or a great Trait-aware IDE.

Interesting that he likes traits in Squeak better, due to the IDE support - one of my issues with traits - or method level namespaces - has been the whole dveloper presentation/understandability issue. It looks like I should grab Squeak and take a look, so that my preconceptions can be addressed with some actual data points :)

The Buffyverse is closing out - this is the last season of Angel. I've been pretty happy with the way the series has been progressing this year too. This may not be entirely bad news; Buffy lingered at least one season too long, and Boreanaz can't look young forever. Better to go out while it's still going well, but still - one more good show off the air. Can we please have Firefly back now?

I noticed earlier this evening that my blog page - not any of the other CST blogs - was messed up - the link bar, post footers, and title were all pushed to the right. This was only on IE; I checked with Mozilla, and it looked fine. I was sure that I had dropped a closing tag (or something) in a recent post, so I started looking through the recent ones... and they all looked ok. Finally, I scrolled all the way down the page - and lo and behold, one of the referral links was long - off the right side of IE. I fixed that by having long URLS shortend, and now it's back to looking good again. Yep, HTML and CSS - the replacement for complex client interfaces....

Scoble references someone worried about scaling syndication requests:

RSS and Atom feeds are pulled down by news aggregators like the NewsGator I use every hour. Multiply that by 20 million people and that's a bandwidth bill that's many times higher than it is via a web browser (because browsers only visit occassionally, and not every day).

RSS and Atom feeds pull down all the content every time, even content that hasn't changed since last time. Is there a way for him to only send down a feed that's changed, or even better, a partial feed with only new items? (My feed sends down 75 items each time whether new or not).

This is one of the things that already has a stock set of answers:

• Have your server handle conditional-get
• Have your server use mod-gzip

That's pretty much it - it has worked for years to scale the web, and I expect it will work for years to scale syndication as well...

Martin Fowler discusses the idea of domain specific languages, and relates it to code generation:

I've always used the analogy of creating a DSL to help think about building up a design - developing classes and methods with an eye to making them be a DSL. As much as possible I do this within the language I'm using, but if I can't I'm very ready to switch to code generation. At ThoughtWorks we've used code generation and similar techniques widely on our larger systems. The point at which I pull the separate language DSL lever is clearly different between languages. I never really felt the need in Smalltalk to use a separate language, while it's quite common in C /Java/C#.

I think this is another one of those places were C (etc) developers and Smalltalk (or Lisp, or Ruby) developers talk right past each other. Interesting article; go read the whole thing

This is from one of our internal bug reports:

If you lose your connection (which happens to me a lot), Store will offer to reconnect. In many circumstances this is useful, but if you're in the middle of publishing, it's a very bad idea. In the best case, the publish won't succeed, as you'll almost certainly encounter errors due to data Store thinks it wrote, but which was in a different transaction. Even worse, it might succeed, leaving partial data in the database.

The bottom line is this - if you are publishing to Store and the db connection drops, do not accept the offer the reconnect. Yes, this is an ugly, ugly bug - and it will get addressed. In the meantime, be aware that it's a nasty one...

Patrick Logan points to an interesting usage of Squeak by Mitsubishi

Dare Obasanjo talks about the specs and reality, and the variances thereof, in the encoding of xml docs on the web:

All files are sent with a content type of text/xml and no encoding specified in the charset parameter of the Content-Type HTTP header. According to RFC 3023 which Mark Pilgrim quoted in his article that clients should treat them as us-ascii. With the above examples this behavior would be wrong in all four cases.

He then goes on the list the way a client application actually needs to deal with this conundrum - check for:

1. the encoding given in the charset parameter of the Content-Type HTTP header, or
2. the encoding given in the encoding attribute of the XML declaration within the document, or
3. utf-8.

Which is what I stumbled on for BottomFeeder awhile back. I wish Dare had posted this back when I was stumbling in the dark :)

BC4J comments on the efficacy of visual cues - pointing out that the 3.5" disk icon is meaningless to his child :) Perhaps it is time to update some of the older icon standards :)