Smalltalk Tidbits, Industry Rants

I caught this picture while I was driving back home from the mall - there's some blur, due to the fact that I was doing 60 at the time. It's a fairly nice sunset pic, I thought, taken with my picture phone. Seems to capture "end of the day" quite nicely.

I've got stable builds of BottomFeeder now, but there's one small problem - image display. At the moment, there's some kind of interfacing problem between NetResources (the code that handles http access) and WithStyle (the XML/HTML display component). It looks like a protocol issue - inspecting the results of a query gives me images - they just aren't being properly displayed. This should be fixed soon - I have email out to Michael already. Stay tuned...

Update: The download is available - check my suggestions here

I had high hopes for the new show Medical Investigations on NBC - but then I sat down and watched a pair of episodes with my wife. She was ranting at the TV the way I normally do when we are watching political pundits. Here's the problem - we've watched Discovery Health's Diagnosis: Unknown series.

What's the problem? Well, take the episode we just watched. The setup is a that a bunch of soldiers are sick - first theory, some kind of chemical/bio agent. Then they reveal that a bunch of nursing home patients are also sick, so scratch theory one. Then, it turns out that all of the victims are Catholic, and attend the same church. This is where things got silly. The lead investigator goes to the church, looking for connections between the victims. At this point, he suspects something in or around the church - so of course, he dips his hands in the holy water on his way in. It only got dumber from there

They track things down to a lay person, and go to his house. He's dead, in the basement. Is anyone wearing gloves or masks? No, it's only after they start poking around, finding rodent feces that they decide to do that (this generated a pause on the ReplayTV and a fair bit of ranting - not to mention the removal of the show from guaranteed status to optional status).

Did the producers even consider getting an expert adviser? There's also the fact that they just had to have that most annoying of devices, the irritating and irrelevant secondary plot line. Here's a tip for the writers - if the primary plot line is so bad that we need a secondary one to keep us watching - you have a problem. Sheesh.

I'm in the process of uploading a dev build of BottomFeeder with With Style as the browser component. It's ready to use, so long as you accept a few caveats - this is an early build. It works, but likely needs more testing. The first start will be slower, as all the cached http information needs to be converted (part of this changeover involved moving to a newer HTTP layer). After that, startup will be normal, and the cache will be more browser like (images, etc are saved there). Also - Asian character sets are displaying properly now. I'll update this post when the build is up.

Have a look at this post on debugging in Mono. I like this part:

What was missing was an easy way to get data out of a debugging session. By easy I mean right here, right now, that @$#^ ASN.1 blob looks wrong. It's too late to modify the code, it's too big to be decoded by hand (or it's also to late to do so ;-).

So something easy would be writing an assembly consisting of a single class with a single method to interpret the data, compiling it and, without even restarting the IDE, using the new code as an help to debug the current problem.

We're not there yet but we're getting close!

Actually with Visual Studio .NET 2005 the step are:

1. Create a new assembly, referencing the debugging assembly;
2. Implement this single method, Show, in a class implementing IDebugVisualizer;
3. Add an assembly-level attribute, DebuggerVisualizer, to map the debugging extension with a type;
4. Compile the assembly *;
5. Copy the assembly to a pre-determined location (which can be automated with the compile step);
6. and use it without restarting Visual Studio!

And in Smalltalk, the one step is:

Create a #printOn: method in the class(es) in question - including the ability to override system classes if they aren't descriptive enough. And obtw - you can do that while the debugger is looking at the code, and have it change right then. I love the way MS and Java folks keep finding incredibly complex ways to not quite match the power of Smalltalk.

The developer in question said he hoped he'd see this in other IDE's soon - here's where to look.

Via Scoble comes this link to what 1950's era CS folks thought a home PC would look like in 2004. Heh

As noted in the comments, that picture is a hoax. It's still funny :)

The dev build of BottomFeeder has been uploaded - you can grab it from the download page by following the development links. A few warnings:

• This is early code - there are some UI layout issues, and quite possibly other more serious issues. This is definitely a use at your own risk build
• Backup your existing files:
• bottomFeeder/btfSave/*
• bottomFeeder/app/*
• bottomFeeder/BottomFeeder.exe (on Windows; .im elsewhere)
• After backing up those files, delete everything in 'app', and replace the current image (or exe) with the one you downloaded

The first startup will be slow - There's some data conversion that has to happen. Another useful tip - if your fonts end up too big (or too small), try opening an inspector and executing this code: NamedFontSelector open. Change the font definitions and then reset the text settings in the Bf settings pane. This is early access code - notify me of bugs/issues/concerns. Thanks, and a tip of the hat to Michael Lucas-Smith for all his help on WithStyle integration!

If you have installed the new development build of BottomFeeder, then grab the update and restart. There are a few enhancements and fixes. As I said earlier, this is very early access code here - be prepared for a bunpy ride...

You can set your clock by it:

1. The Red Sox get tantalizingly close to the Yankees (coming from 10 1/2 games back to 2 1/2 earlier this month)
2. The Red Sox win a game against the Yankees, giving their fans hope
3. The Yankees slam the Sox down

On to the World Series for the Yankees, and back to the showers for the Sox...

In the comments to this post, a discussion about extending the syntax of Smalltalk came up. In particular, Rich liked the F-Script array extensions. Peter William Lount has a nice write up on that here.

Here's the thing - in this case (and in most of the things that come up), we don't actually need to change the syntax of Smalltalk. You want to be able to replace:

someCollection collect: [:each | each name]

with this:

someCollection name

Well, all you need to do is add this method to class Collection:

doesNotUnderstand: aMessage
	| selector |
	selector := aMessage selector.
	^[self collect: [:each | each perform: selector]]
		on: MessageNotUnderstood
		do: [:ex | self]

Now, if I do this simple test:

people := OrderedCollection new.
people add: (Person new
	firstname: 'fred';
	lastname: 'flintstone').
people add: (Person new
	firstname: 'barney';
	lastname: 'rubble').
people add: (Person new
	firstname: 'wilma';
	lastname: 'flintstone').
people add: (Person new
	firstname: 'betty';
	lastname: 'rubble').
people firstname.

Then you end up with a collection of the firstnames. Now, there are some obvious issues with this new approach:

• I can't send messages through if the collection itself understands them (say Person understood #first instead of #firstname, for instance)
• What if I would rather have the protocol use #select: instead of #collect:

Either way, if this sort of thing is something you want, you can do it yourself without having to modify the syntax of the language. Which is good - because you can also change it easily if you don't like it. Syntax changes are just there, and you have to deal with them whether you like them or not. Which is why the approach taken by Java and C# sucks so much...

Ted Neward identifies the vendor adoption problem with WS protocols:

Here's the deal: Amazon, Yahoo, eBay and others are all finding that trying to implement production-quality Web services right now is Hard Thing To Do. The tool stacks are still half-baked, the standards aren't really ubiquitous nor widely-supported yet (c'mon, folks, we're still seeing vendor implementations that are choosing the WS-I-obsoleted SOAP 1.1 Spec over the WS-I-approved SOAP 1.2 version, we're clearly not keeping up with the spec movement), and the specs just keep coming, and coming and coming. If these companies, whose very business depends on both the traditional consumer chain transforming into a more lucrative business-to-business chain, are finding that the WS-* stack is failing them, what chance do the rest of us have of making all this stuff work?

The problem is in the the specs keep coming and coming part. Look, here's a tip - keeping up with the WS standards isn't the only thing on a vendor's queue. I've said before that Web Services is the new CORBA - and this is more proof. Back in the 90's, the OMG churned rapidly with specs no one cared about. The web services folks seem to think that's a model worth striving for. Slow down, and actually think about what you're doing, instead of just adding specs "because you can".

In the meantime, many of the vendors will be solving actual problems they have with actual customers and prospects...

I ran across Gary Short's points on Smalltalk usage yesterday - he makes some valid observations:

As I've said before, I learned to program in Smalltalk and it remains my favourite programming environment. So, having said that, why do I earn my living programming in a Microsoft environment?

Well the answer's in the question really - it's because I want to be able to earn a living. Here in the UK there's a well known website called Jobserve that has job postings for different IT jobs, (among other things). A simple search for Smalltalk this morning yielded just 13 hits, UK wide, for the last 7 days. A similar search for .Net yielded over 1500 hits.

Yes, that's a problem - and one the vendors - like Cincom - need to help address. At the same time, some of the effort has to drop back to developers who say that Smalltalk is their favorite language. I don't expect developers to "go to the mat" to bring Smalltalk into a shop - far from it. On the other hand, I would expect them to at least bring it up, and ask that Smalltalk be evaluated when new projects come up. Not all the heavy lifting can be done from this end...

I've posted another dev build of BottomFeeder - this looks a lot better than the build I posted last week. It's still a dev build - this is not yet a full new release. So if you grab this one, be aware that there are still some rough edges. As I mentioned in my last post on this, back up the old executable (or image), and the contents of the 'app' and 'btfSave' directories before you try this build

We get asked about the performance of VW on the OS X platform a lot. Yes, we recognize that what we have out there now really isn't acceptable. In 7.3 (out late November this year), we are addressing this.

At the moment, the OS X version of VW uses the native Window system (as it does on all platforms) to open Windows and to make low level graphics calls (for the emulated GUI). On OS X, we the native interface has not been stable enough. In 7.3, we are instead going to rely on X11 on the OS X platform. The good news is that this results in a far more stable product - the bad news is, you have to have X11 installed for this to work.

X11 ships with OS X, so if you don't have it installed, it should be easily accessible. Yes, we realize that this is not an ideal solution - and we intend to revisit this choice when we do native widget support (post Pollock, in the future). In the meantime, it's the fastest route to a far more stable OS X platform.

Based on the comments to this post, it's obvious that I was not clear. It's not that the mac UI is unstable; far from it. Our current VM for the OS X platform is unstable. We are going to stopgap that problem by using our X11 based engine for the time being

Good gosh, someone call Buffy - Ivan just won't die. After swinging into the Atlantic last week, it went south again, into the gulf of Mexico, and is gathering strength.

I've got With Style into BottomFeeder now - and things are looking better. I've got all the obvious (well, at least to me :) ) bugs ironed out - there's a problem with the new http layer prompting for username/password on auth pages when it shouldn't, but we'll track that down. What's new?

• Support for user defined style sheets. Users can define their own style sheets and save them to a specific directory - and switch them at runtime. I'll be providing a few simple ones
• Better html display. This is the primary benefit of using WithStyle - better display.

I've just posted an update that fixes a few issues with newspaper view. Bear in mind that this new build is still a development build - backup your data before you try it out.

All of us have been in this conversation before. Heh.

Here's a great quote from a .NET vs. J2EE debate:

Visual Studio, like Visual Basic and other Microsoft development tools and languages, provide ease of use and a low learning curve at a price: They don't impose any kind of discipline or framework, making it too easy to crank out poorly designed apps and horrid code. This is not helped by all the amateur Visual Basic/Studio "developers" out there who have no understanding of basic comp sci concepts. (Luckily, we don't hire those kind of developers, but I'm sure we've all worked with many of them in the past.)

On the other hand, J2EE by its nature imposes some rigid rules and forces one to use some kind of a framework to deliver an enterprise level app. This takes more time, planning, and skill. As a result, though, J2EE apps, by comparison, tend to be more robust, maintainable, and scalable. This is not to say that .NET apps cannot have those qualities as well -- it just takes a lot more discipline and some self-imposed rules to achieve this -- Visual Studio doesn't give you that out of the box.

That's the mindset in too many parts of this industry - if it's simple, it can't be good. Or it won't scale. Or something. Of course, while the two pirates of complexity duke it out, people who want real productivity and simplicity can look over here. I'll be doing live updates and debugging live code in the meantime...

We've got a Wiki Page that I keep updated on what's coming. This release should be out in late November (possibly early December) of this year:

Cincom Smalltalk November 2004 is a major release for both VisualWorks and ObjectStudio. The main features we intend to add:

VisualWorks 7.3

• VM
• Preview Support for 64 bit platforms - we intend to have preview (beta) support for the AMD Opteron, the 64 bit Xeon, and the Sparc 64 bit platform. Other platforms (such as the G5 and the HP PA) will follow. This will be a full 64 bit implementation, not simply 32 bit on the 64 bit platforms. Some of what should be there:
• The 64-bit implementation uses full 64-bit adresses for objects, providing the ability to fill the entire available address space with objects
• The immediate floating-point format should provide a very usable range which, although it will be able to overflow to full 64-bit boxed Doubles, should overflow rarely in practice, providing much faster and much more space-affordable floating-point
• Shared Perm space on all 64 bit platforms - which means a much lighter weight server deployment
• The C connect in the 64-bit implementation is a full 64-bit ABI and consequently removes the annoying limitations people have encountered when trying to run the 32-bit system on 64-bit Solaris linking (or rather not being able to link) against 64-bit libraries.
• The two systems are code compatible in that the bytecode is exactly the same between the two systems, so parcels load unchanged and can be freely exchanged between 32-bit and 64-bit systems.
• We will support the ability to develop either in 64-bit or in 32-bit and deploy in the other width
• More details to follow as they become available
• Store
• Store Packages/Bundles into the base. This will mean eliminating categories and parcels as a separate view, and showing a unified package view of the product - whether you use a store repository or not
• Store will support atomic loading of packages/bundles when loading via source. At present, atomic loading only happens with packages store binary - this will change in 7.3
• Store will support file attachments - so you'll be able to include image files, ssp files (etc) when versioning. This will allow you to manage all project artifacts in Store.
• Better version support for packages. At present, one can make a package depend on another package, but not properly dependent on a specific version of another package. This support will enable us to introduce an important change in VisualWorks deployments - post 7.3, we will support (some) new packages on older versions of the base product. As an example, you'll be able to load a newer revision of a major component (Opentalk, Web Toolkit, etc.) on older versions of the product without upgrading the entire product suite.
• Base System
• Full Unicode (font) Support for Windows and Mac OS9 (These will probably remain in preview, but will be improved from the 7.2 release) - Mac OS X is planned, but will not make the current release cycle. This is currently Windows only
• An initial definition of a Smalltalk Runtime Environment. One of the most common issues people have with Smalltalk is the difficulty in packaging - with this release, we will start supporting build up rather than strip down, with a standard deployment system
• .NET Connect
• This component is currently in preview (beta). For the 7.3 release, it will be fully supported. It is possible that .NET Events and WinForms will be supported within this component
• Distribution
• VisualWorks will have a 2 way wizard for dealing with web services - you'll be able to point and click your way to a server and/or client interface very easily, with all the heavy lifting done by the tools.
• SNMP support should stabilize with better ASN.1 parsing
• We will support an Opentalk IIOP at Preview (beta) level. There may well not be a complete implementation (value types in particular). This work will lead to (not in this release) suppport for RMI over IIOP. More details will follow as they become available
• We will have a connection to MQS (IBM Messaging) in preview. This is stable, and in use by customers - but we do not have time for a full review before it is integrated into a supported state. That should happen in 7.3.1 or 7.4
• Internationalization
• We will have better support in the base system for Asian locales. A few Locales will ship with the commercial product, and will be available for NC on request.
• Documentation
• SmalltalkDoc - A new initiative to provide reference documentation for VisualWorks. This may only make it to preview status, depending on how much work gets done on this as opposed to the existing documentation

ObjectStudio 7.0

• Full Unicode support
• Full support for the XML package that was originally developed for VisualWorks
• Full support for Opentalk, which enables object level communication between VisualWorks and ObjectStudio
• We are investigating some exciting possibilities for ObjectStudio which I am not (yet) prepared to reveal publically. Stay tuned!

Further details to come

I'm in the process of uploading another development version of BottomFeeder for download. This is under the dev download links, and is still considered to be beta code. I've extended the application level support for style sheets - users can now switch amongst available ones (and new ones can be added to the 'stylesheets' directory). I'll post an update when the files are live on the server.

Update: Grab the dev downloads now

This is subject to evolutionary changes, but here's a product roadmap for Cincom Smalltalk. As always, contact me with any questions

JP Morgan has been a long time user of our product (and of Gemstone Smalltalk as well). They've agreed to talk about their applications - here's what they do (1.1MB, PDF). Enjoy!

In the news:

• PC Magazine UK
• Infomatics

Stephanne Ducasse has gotten permission to post the "Green Book" - Bits of History, Words of Advice by Glenn Krasner. Kudos to Stef for making this happen!

As you know, we offer a free download of our Cincom Smalltalk product (both VisualWorks and ObjectStudio). There's also an ESUG CD out there with just VW NC on it - it's come to my attention that there's an installer problem with that CD. You can grab a known good installation from our site.

You can stick a fork in it - the itanium is dead. HP just bailed, leaving intel holding the bag on a chip no one wants. Apparently, InfoWorld's Tom Yager hasn't gotten the memo yet

Sometimes, I really wonder how a columnist manages to get paid for their writing. Take this eWeek column by Jim Rapoza, for instance. It's supposedly about RSS, but it could be about anything - it's filled with platitudes, very light on real information. After reading it, I'm not convinced that Rapoza has the slightest idea what RSS is:

One of the main benefits of RSS is its simplicity. In minutes, I can write an RSS file to syndicate a column or blog, and there are tools that make this process even easier. But the simplicity of RSS also means that it doesn't have a whole lot of intelligence over its delivery.

Many large sites that deliver RSS feeds recently started complaining that they are being hit every hour with a flood of reader requests that is, for all intents and purposes, the same thing as a denial-of-service attack. This happens because most RSS readers are pretty dumb about when they check for updates, and there's little the server can do to control this.

The dreaded "RSS is DDOS" rears it's head. Odd - Slashdot somehow manages to deal with badly behaved clients - there are, in fact, solutions to this problem (if there weren't, massively popular sites like Yahoo and Slashdot would have folded up eons ago). But hey, those paragraphs show some passing familiarity with a recent wave of blather. What about this?

But this is also that time when many of the problems and deficiencies in RSS will be discovered, and enterprise users of RSS will expect these problems to be fixed as soon as possible. If the developers and caretakers of RSS are unable or unwilling to do this, many companies may decide to take a pass on the technology.

So, to those developing products that use RSS: Find ways now to address some of RSS' shortcomings and dig for problems heretofore unknown so the technology doesn't become a burden on those who decide to use it. To the RSS community: Find a way to work together to create one standard, which will be much more robust and responsive than multiple competing standards.

Insert almost any topic from the last 30 years in the IT sector, and you could write those two paragraphs. It was a stock column, with the acronym RSS copy/pasted in. What a waste of pixels...

Larry McCay of SDTimes has an interesting comparison of XP (Extreme Programming) to the Scientific Method:

XP builds on best practices such as unit testing, pair programming and refactoring. The basic principles of XP are communication, simplicity, feedback and courage; applying the methodology goes through the following five steps:

1. Choose story.
2. Write tests.
3. Run tests.
4. Refine, program and refactor 14repeat as needed.
5. Go to step 1, repeat until all stories are complete.

Let's compare against the Scientific Method, which was first introduced by Francis Bacon. It was not used as a strict discipline until Isaac Newton later in the 17th century.

The goal of the Scientific Method is to provide a set of steps to ensure the development of provable theories that may lead to new and greater understandings of the workings of nature and its systems. These theories are gradually stepped up in generality until the highest level, at which point there may be opportunity for unification of theories.

The Scientific Method consists of six steps, and you can see the similarity with XP:

1. Make observations.
2. Create hypotheses.
3. Make predictions.
4. Conduct experiments.
5. Modify hypotheses if predictions are not met and go to step 3.
6. Declare hypothesis as theory.

Go read the whole thing - it's an interesting article.

That thud you heard earlier this evening was the Red Sox losing to the Yankees. You can feel the pain in the Boston papers already. On to the playoffs - it's about time for another Yankees Series victory. But wait! It wouldn't be an end of year Yankees/Red Sox series without some classic Sox screw ups:

With an eerie similarity to last year's postseason debacle, Pedro Martinez took a lead into the eighth inning before tiring and the New York Yankees rallied past Boston 6-4 Friday night to open a 5.5-game advantage in the AL East.

Grady Little was the Red Sox manager last fall when he left Martinez in during the eighth inning of Game 7 in the AL championship series; the Yankees overcame a 5-2 deficit to tie it and earned a World Series berth when Aaron Boone homered in the 11th.

Little was let go after the season and replaced by Terry Francona. But Francona, much as his predecessor did, sent Martinez (16-8) back out for the eighth despite needing 101 pitches to get through the first seven innings; the Boston fans let Francona hear about it, much as they did for his predecessor.

Heh

This post is an example of how a good RSS tool can help you find problems quickly. I have to give credit to feedster for this one - I use a feedster RSS search in BottomFeeder, and that's how I ran across Gary's problem. I have a search set up for the word "Smalltalk", and that's how I find things like Gary's post. If you're in a position like mine and you aren't using an aggregator and Feedster to track your product - you must be nuts.

I think I underestimated the level of pain in New England after last night's game. Go over here to the Globe's coverage and see just how far into the Sox' heads the Yankees have gotten. Interestingly enough, last night's game was the 1918th game between the two team.... spooky :)

Another day, another hurricane strike for Florida. From the reporting, it looks like a lot of the residents are starting to get evacuation fatigue; i.e., they are planning to ride this one out. That's probably a mistake - it's a Category 3 now, and could get stronger yet. There's also the fact that the Dunes got lowered on a lot of the barrier islands by Frances.... this could be very dangerous. My folks are heading out again; everyone else should as well.

Jonathan Schwartz has an interesting article up on grid computing - Sun sells a service based solution here, and it might fit some people's needs. It's not as simple as he makes out though:

So when we announced our $1/cpu/hour pricing for our N1 Grid (as opposed to the ever so slightly different ones everyone seems to be building), we knew we'd strike a chord. Why build and operate what Sun could deliver as a web service? Priced by the drink, no less.

So we're now engaged with a growing population of companies to talk about leveraging an "on demand grid" for their workloads. We're also engaged with a number of CIO's who've asked their teams to benchmark their internal compute grids against $1/cpu/hr. All in, all up, at least there's now a benchmark. If they buy from us, they can simply turn the bill over to their internal clients.

And if nothing else, we've now put a stake in the ground. If you're paying more than $1/cpu/hour, odds are you're overpaying (and possibly overbuilding - another customer told me utilization in their xSeries blade farm was below 10%!).

That's hardly the only issue. If I have a complex set of calculations to offload, then I rather suspect that performance issues are one of the things I need to worry about (on Wall Street, I happen to know that this is the case). In that event, a web services accessible grid may not cut it - the network is still a whole lot slower than the local cpu. It all depends on the job and bandwidth of course - the faster the network connection gets, the more easily possible this may be - it may turn out that Sun and Schwartz are actually on to something with this idea. We'll see how it turns out.

I expect everyone in Florida is suffering from Hurricane fatigue - certainly my parents (currently holed up in an Orlando hotel) are - Frances and Jeanne both came very close to Melbourne Beach, where they live. I've been watching coverage of the storm on the various cable channels - a few minutes ago, MSNBC was showing video of damages to the Eae Gallie causeway. I've driven down that road many times; now there's a boat smashing up against the side of it and debris all over it - not to mention the flooding of the approaches. It's a little odd looking at damage to areas you know well. Here's hoping that Florida doesn't have any more of these to deal with this year.

Dare Obasanjo points out how some feeds follow the RSS specs (in so far as you can call them specs, but never mind) exactly - but end up creating a nightmare for aggregators and the users who use them. He points to a specific feed, and tells us exactly what's wrong with it - specifically, the issue of using the same link for multiple items (without a GUID being present):

Now how does the RSS aggregator tell whether the item with the title "I am item 1" is the same as the one named "I am item one" with a typo in the title fixed or a different one?  The simple answer is that it can't. A naive hack is to look at the content of the element to see if it is the same but what happens when a typo was fixed or some update to the content of the ?

Every RSS aggregator has some sort of hack to deal with this problem. I describe them as hacks because there is no way that an aggregator can 100% accurately determine when items with the same link and no guid are the same item with content changed or different items. This means the behavior of different aggregators with feeds such as the Cafe con Leche RSS feed is extremely inconsistent.

This is the sort of thing that drives us aggregator authors nuts. Presumably, authors want their content to be read. Is there a reason that some of them have to make it so blasted hard?