Smalltalk Tidbits, Industry Rants

People are starting to grope towards the idea that static typing is the problem. Take a look here - Ajeru is moving toward a Smalltalk point of view, whether he realizes it or not. For instance:

In mainstream OO languages, objects are associated with classes (types, interfaces, etc) at the time they are created. In the real world, this is not how it works. For example in a customer relationship management application, there will be different types of customers depending on the probability that they spend lots of money. To simplify things, say we have A, B and C customers. Business people talk about A, B and C customers and they specify different rules that apply to A, B and C customers respectively. But we cannot easily have classes for these types of customers because the type of a customer is a dynamic property that changes at runtime. The result is, we cannot capture these business rules in the same way that domain experts do. What we do in our designs is to introduce methods like isAdult() or getCustomerType(). But neither can we use this kind of "typing" to specify constraints, nor can we organise method dispatching based on such types. No polymorphism, just switch statements.

public class A extends Customer {
   definedby {
      getRecentPurchases() > CUSTOMER_A_THRESHOLD;
   }
}

public class B extends Customer {
   definedby {
      getRecentPurchases() > CUSTOMER_B_THRESHOLD;
   }
}

public class C extends Customer {
   definedby {
      getRecentPurchases() > CUSTOMER_C_THRESHOLD;
   }
}

No, it would not be easy, because among other things it contradicts static typing. A pity we must accept the fact that we have been betrayed.

Ok, that's interesting. I think he wants the decorator pattern, not the state pattern anyway - it seems that static typing has already clouded his mind. I found this reference on the fishbowl, where Charles attempts to deal with this. His explanation comes from the Java is all I, or anyone would ever have school of thought:

In Java at least, an object's type represents three different things:

1. The messages that the object will respond to. This defines the object's interface.
2. The code that the object will use to respond to these messages. This defines the object's implementation.
3. An attribute of the object, of type Class.

Sometimes, people get stuck on the third one, and give it far more importance than is really necessary. There is nothing magical about the identity of an object's class. It's just another attribute of the object. Its primary value is as a way of determining which messages we can send to an object, something that is done often enough that Java gives us the short-hand operator instanceof instead of making us call Class.isAssignableFrom(). However, the existance of this operator shouldn't make us feel that the class attribute as an attribute is any more or less important than any other.

Yes, Java is the end all.... All this verbiage spilled because the crowd can't see that static typing is the problem - let go of it, and these artificial constraints disappear. As David Buck said brilliantly:

Dynamic typing allows the programmer to do the right thing without trying to convince the compiler that it's the right thing.

The 2.9 release is getting closer. There are a few UI issues to resolve, but I think those will be easy. I re-did the downloads again - if you look at the dev builds page, you'll see that I've gone back to zip files. The entire directory structure is still being saved, so this change should be minor, and my hope is that it will make it easier to deal with the downloads.

I have so been in this meeting

One more problem to overcome. Say I have a subcanvas, and widgetA is invisible in it. Now say I make the subcanvas invisible, then make it visible again. Is widgetA visible or invisible? The sad answer is that it is visible - the state is not maintained. I'm not sure whether this qualifies as a bug in VW, but it sure is irksome...

I've linked to these notes from Cory Docterow before - Alan's Kay's talk at ETCon is getting a lot of notice. This morning, Lambda linked to it. Something (good) is in the air :)

Ted Leung points out that the Unix Hater's Handbook is now available online. I especially liked this bit of cynicism:

"In my more cynical/despairing moments, I like to tell people that computer scientists regularly reinvent the wheel, doing it a little bit worse each time around."

Heh. Some of us suspect the same thing happens with programming languages in our more cynical moments....

I swear this is my ISP

I notice that Elizabeth Lane Lawley (posting on Evan William's blog doesn't think much of Wikis. Her basic complaints are in the presentation area:

You can spot a wiki page a mile a way. They all look exactly like the pages that my students used to turn out in basic HTML classes back in 1995. All they're missing are the rainbow-colored bars to replace the ubiquitous horizontal rules.

She doesn't get it. There is a problem with wikis, but this most assuredly isn't it. The problem with wikis is the lack of actual collaboration. In my experience, not that many people are willing to add content to a WIki. This is curious in a way, given that the markup is generally simple (regardless of implemementation)- but that's how it turns out. If you set up a Wiki for developers, a small percentage will go out and edit pages. A smaller percentage will create pages. You'll generally find 1 or 2 people willing to devote any time at all to maintenance of the Wiki page space. Now add non-technical people. Those numbers get even smaller. On a regular basis, I'll get email telling me that there's a problem on a Wiki page, along with the fix (for instance, a bad link). This is interesting. Someone went out of their way to send me an email about a problem page. It would have taken less time to fix the page.

Why is this? It's hard to say. It might be an ownership thing - people generally consider web pages to be content for consumption, not documents for editing - i.e., it's not their content, so they don't feel comfortable editing it. That's part of it, I think. There's also the scared by confusing markup crowd - what we (developers) think of as simple markup, non-developers see as confusing notation. Thus email reports - email clients are tools that people feel far more confortable with.

Which takes me back to Elizabeth's post. She seems to think that presentation is the problem, and I'm here to tell her that it's not. I think the population of willing posters to a hypothetical gorgeous Wiki would still be small. It's not the presentation that's the issue here. There's something simpler afoot here, and it's something that plagues web software in general. People like rich client software. People tend to not like basic editing tools - which is what Wikis use. Combine a Wiki with decent posting tools, and I bet you would see more collaboration. Combine it with more pleasant layouts, and I bet nothing much would change

I've decided to support the Comment API that Joe Gregario proposed, and that a lot of the blogging community has picked up. So this blog is now accessible via any tool that supports the API from the client end - which will include BottomFeeder once 2.9 is released.

I'm not sure I agree with his modelers/developers divide. He asserts that MS is a company of "techies" while Sun is a company of "modelers" (let's pause while this Smalltalker picks himself up off the floor. Sun and elegant design.... ROFL). However, in making his point he dissects Sun and Microsoft in interesting ways, and makes this point:

When you reflect on this for a bit, it starts to explain a lot about the differences in philosophy between the two platforms. Microsoft will never, ever produce an implementation of the CLI on a platform other than Windows, because they want to make sure that any implementation they produce is the fastest possible. Let's be blunt: anybody who's looked at the Rotor code and thought about the low-level hackery that would need to go on in order to make it a "real" implementation, and then thought about what it would take to port that to another platform has probably gone insane, raving incessantly and wildly to the cat. Microsoft wants to take full advantage of every last little nook and cranny of the underlying CPU where possible, and that's just not inherently portable. Sun, meanwhile, looks for ways to remove the underlying platform almost completely off your personal developer radar, stressing "platform portability" and "WORA", in order to push a "best-of-breed" solution that allows us as developers to choose, from a flat field of competitors, the best price-to-performance vendor solution we can find. Like good modelers, Sun's vision is to let the vendors play techie, you just focus on building good models that conform to the spec.

I think he's right about the feasibility of the MS .NET stuff on non-Windows platforms. Until or unless MS releases the Office suite on non-Windows platforms, they won't be gung ho about cross platform development.

Ted Leung has another thoughtful post on dynamic and static languages. Ted found Bob Martin's post here on the subject - from Bob:

I've been a statically typed bigot for quite a few years. I learned my lesson the hard way while using C. Too many systems crashed in the field due to silly typing errors. When C++ came out, I was an avid adopter, and rabid enforcer of strong typing. I scoffed at the smalltalkers who whined about the loss of flexibility. Safety, after all, was far more important than flexibility -- and besides, we can keep our software flexible AND statically typed, if we just follow good dependency management principles.

Four years ago I got involved with Extreme Programming. I liked the pragmatic emphasis it placed upon developing software. I also liked the emphasis it put on testing. Since then I have become test infected. I can no longer concieve of writing software without using test driven development. I can't imagine not having a comprehensive suite of unit tests to back up my development.

About two years ago I noticed something. I was depending less and less on the type system for safety. My unit tests were preventing me from making type errors. The more I depended upon the unit tests, the less I depended upon the type safety of Java or C++ (my languages of choice).

I thought an experiment was in order. So I tried writing some applications in Python, and then Ruby (well known dynamically typed languages). I was not entirely surprised when I found that type issues simply never arose. My unit tests kept my code on the straight and narrow. I simply didn't need the static type checking that I had depended upon for so many years.

I also realized that the flexibility of dynamically typed langauges makes writing code significantly easier. Modules are easier to write, and easier to change. There are no build time issues at all. Life in a dynamically typed world is fundamentally simpler.

Now I am back programming in Java because the projects I'm working on call for it. But I can't deny that I feel the tug of the dynamically typed languages. I wish I was programming in Ruby or Python, or even Smalltalk

Very cool - and this is a big change from "back in the day" when Uncle Bob was editing the C++ Report. I'm very pleased with the way that TDD and agile methods have been turning people's heads. Ted added some thoughts as well:

Very interesting... more and more smart, respected people are coming to the conclusion that we can do better than Java/C#, etc. The only thing I can fault in the article is the omission of Lisp in his list of dynamic languages.

I guess life for the Lisp advocates is even tougher than it has been for us Smalltalk guys - we tend to at least be remembered when this topic comes up :) Either way, the Smalltalk community needs to get its act together. If we want to play more fully in the coming rise of dynamic languages, we need to get straight with Open Source - because that's where all the grass roots stuff is going to happen. We can either be on the bus, or watching the bus....

It seems that David Buck's Domino Effects article (which I commented on here) has generated some interest. I saw this post from ceperez this morning:

(citing David's article)

Interestingly, the two examples he sites "const declarations" and "checked exception handling" are vivid examples of the problems of static checking. Both constucts seem to work well for small programs, however they don't seem to scale. Could it be that static typing works well for small programs and more of a nuisance with larger ones? I tend then to agree with the observations, static types tends to propagate throughout a system, and will have a domino change effect. That is, for "Programming in the Large", static type checking is problematic.

However, does that mean that we should get rid of static type checking altogether? I think that's too radical, any kind of static checking is extremely useful. However, we should always make an effort examine the extent of the static dependencies inside our system. Large systems tend to use a combination of both static and dynamic checking. For example, Eclipse is a large scale progam however its able to overcome the problems of static type checking. I don't believe that there's a Smalltalk program of comparable size to the Eclipse project. The evidence therefore exists that you can build large programs with static typing, however its interesting to know how to do this.

Large programs developed in a statically typed language is successfully acheived by exploiting a Component Model. That is, you structure the composability of your application in terms of a component model that uses dynamic typing. The advantage of using a statically typed language like Java over a dynamic typed one like Smalltalk is that with Java you can develop in both modes instead of exclusively in one. I think this alone statement sinks David Buck's arguments for Smalltalk

Using dynamic typing in a language like Java? First off, that mostly concedes the point to the Smalltalk POV - Using dynamic typing this way in Java (or C++, etc.) merely points up the inherent limitations in the static model. If you have to escape the model in order to achieve good results, what does that tell you about the model?

I also find this kind of thing interesting in another way - this post freely admits to a lack of experience with Smalltalk - but is more than willing to assert that Java better supports his "mixed mode" development than Smalltalk. It's clear that David Buck has a good level of expertise in both the static world and the dynamic world - and based on this post, I'm unclear as to how any of David's points have been sunken. Heck, most of the post accepts his points, and then veers off into what looks like rationalization at the very end. I suggest a reading of Uncle Bob's post on static typing and dynamic typing. Combine the points made there with David's article, and I think things will become much clearer.

Bottom line, I don't think the post sinks anything David had to say.

There were some issues with the Comment API code on the server until now. I had developed the code in VW 7.1, but this server is still running 7.1. The Web Toolkit was still evolving between 7 and 7.1, so the protocol that worked to grab the XML fragment for the CommentAPI worked in a 7.1 image, but not in 7. I set up the testbed 7 server locally, and sure enough, the protocol was slightly different. I adapted the code, and now all is well - I got a test comment up a few minutes ago.

Awhile back, I was interviewed with some other folks by the Lehrer report for a story they are doing on blogs and blogging. Here's the email I just got:

After several months of work (and waiting!), the NewsHour story on blogs is airing tonight (4/28/03). Check your local listings for the time your PBS station airs the NewsHour. It should air at approximately 29 minutes past the hour. Whether you were interviewed for this story or provided some background information or assistance, thank you again for your participation. If you have any questions, please let me know! The transcript for this story should appear on the following page in the next couple of days:

http://www.pbs.org/newshour/media/index.html

Cool! My 2 seconds of fame has arrived :)

Brian Livingston of Infoworld has noticed RSS:

I believe this is just the beginning of a tectonic shift that your organization must plan for. Soon after Microsoft made its move, other corporations such as Cisco Systems and Fawcett Publishing started their own RSS-compatible streams.

Dave Winer, the coinventor of RSS, says he was happy to find out that Microsoft's new feeds don't use proprietary tricks. As a result, the Microsoft feeds are compatible with any RSS aggregator.

When aggregators become widespread, many b-to-c newsletters will switch to RSS and drop now highly unreliable e-mail. I wrote three months ago that ISPs such as Hotmail and Yahoo, trying to stop spam, shunt to a junk folder or simply delete 25 percent of newsletters requested by subscribers (see More e-mail scandal, Jan. 6, page 22.)

I guess RSS and aggregation are about to hit the bigtime :)

The NC Download site had a problem this morning, due to a protocol change I made to an underlying piece of code. Unfortunately, the server was still running with the old version of said code, so it never initialized when I restarted the server this morning as part of a test. In any case, the NC is available again - Sorry for the inconvenience

Looks like that blog bit on the Lehrer report will have a bigger audience - Instapundit has blogged it

Cringely has an interesting take on Open Source. Keep reading - he gets to open source in the second half of the article. Here's the gist of his point:

Here is the core argument: There are a thousand Open Source projects that get started out of need or fun, are maintained for awhile for fame, then get abandoned because there is no reason to go on. Eventually, the programmers come to understand that "users" are people who yell at you to fix stuff. So Open Source is inherently flawed. It only works because otherwise unknown programmers can get 15 minutes of fame using the Internet as low-barrier entry into introducing their skill to the world. Since they are introverted nobodies, getting a few emails from unknown users that say "good job!" feels great. But in time, most Open Source projects grind to a halt. The ones that survive are projects like Linux and Apache that have substantial involvement by PAID engineers. One could argue, in fact, that the idea of Open Source software being created by volunteers is a misnomer. Even Linus Torvalds is paid by Transmeta to be the God of Linux

This is an argument I've made more than once - that all the work done to make Linux usable was done once companies like RedHat started paying people to do it. One interesting aspect about an awful lot of open source is usability - it's the kind of drudge work that few people want to do (organizing menus, cleaning up the UI, etc) - but it's also the kind of work that is crucial for widespread acceptance of a product. Love them or hate them, this is something Microsoft has always understood.

Then Cringely goes on with some theories on how MS could crush open source efforts. I'm thinking this wanders a bit into tinfoil hat territory, but here it is:

It is possible to hijack an Open Source project since any Open Source team will automatically bend itself around the party doing the most work. What I find most interesting, however, is applying varying motives to the hijacking. What if Microsoft, for example, suddenly started devoting a lot of resources to Open Source development? They could throw a team at all the key projects. But why would they do that? Well, IBM is already doing it. IBM has hired most of the Apache team. IBM has some major pull on what work gets done and does not get done. In some cases, it is frustrating, and other cases not. However, everybody just accepts it because IBM is paying the bills and people can do what they love. Is there an official IBM party line at Apache? Absolutely not! It is just that none of the Apache developers will talk negatively about IBM, even those that do not work at IBM. So in this sense, it already appears that Apache has been hijacked.

Now consider an evil alternative. Say Microsoft assigns a team of programmers to help some Open Source project. Maybe this time that team isn't specifically identified as being from Microsoft, perhaps it is a Microsoft-funded startup. This team, because of its vitality and funding, quickly takes control of the project and goes running off in some particular technical direction, taking with it the rest of the suddenly re-energized team. But what if this new direction is not a good one? Even worse, what if the team gets far down that lonely road only to have Microsoft suddenly pull the plug, removing its team from the game? Would the project survive? It is hard to say, but if I was Microsoft that's how I would compete with Open Source, by subverting it. Microsoft can't compete on quality or price. And subversion -- since it is subverting a not-for-profit venture -- breaks no laws, nasty as it is.

I think he's wandered off the reservation with this stuff. The usability and paid work - I agree with that. The latter stuff? Tinfoil hat :)

My 15 seconds of fame came and went on the Lehrer Report tonight. Right there at the end of the segment they almost showed a shot of BottomFeeder :)

If you are going to be in NYC tomorrow, check out the NYC Smalltalk Users Group meeting:

The next meeting NYC Smalltalk meeting will be Wednesday, April 30th.

We will preview a live demonstration of a new sports-related web site, written entirely in VisualWorks Smalltalk with Javascript integration.

Our meetings are open to the general public. Anybody is welcomed to stop by and contribute to the discussion.

Date	April 30th, 2003
Location	Suite LLC offices
Address	440 9th Avenue, 8th Floor
Time	6:30pm to 7:00pm -- Open house
Time	7:00to 8:30 pm -- Main Event

Directions:

Take E or C train to 34th (Penn Station) walk to corner of 34th and 8th. Walk up one block to 9th.

Sounds like a meeting I wish I could attend.

I have just posted a new Survey on the site. The topic this time: The VisualWorks GUI, native widgets, and GUI embedding. As always, your feedback is greatly appreciated!

The Frost code was open sourced by Cincom a couple of years ago - it was an ObjectShare project to build a Java runtime into the Smalltalk system. It's languished for awhile, but someone is actively publishing it in the Public Store now. Have a look at the Frost package.

VisualWorks has supported SOAP for a couple of releases now, and the tool support for it has been improving. There's a simpler protocol that hasn't really been noticed by most Smalltalkers - XML-RPC. It's a very simple RPC scheme, using XML for the formatting of messages and responses, and HTTP for the transport. It hasn't hit the radar of most development shops, but it is in fairly widespread use in the blogosphere.

Blogs are very popular right now - according to last night's Lehrer story said that there are around 500,000 blogs in the US alone. It turns out that XML-RPC is an important mechanism in this world. How so? Well, the most widely used posting API is the Blogger API. It's a pretty simple (and not terribly sophisticated) api for dealing with and managing blogs. It uses XML-RPC as the messaging scheme. This is hardly the only usage - there are a variety of other uses as well:

• Pingback, a specification for notifying other blogs that you have linked to them.
• Trackback is another, older specification for link notification. It is similar to Pingback, but not typically automated
• Blog Pings are a way of updating various blog aggregation sites that your blog has been updated.

The common theme here is that all of these mechanisms use XML-RPC. So how do you do that in VisualWorks? Fortunately, Roger Whitney, a professor at SDSU, implemented XML-RPC for VisualWorks. He did this in VW 3 using VisualWave. I've since added basic support for the Web Toolkit (servlet based) and posted my version in the public store - look for Bundle XML-RPC. It contains a client side implementation (for sending messages) and a server side (for receiving them). Let's have a quick look at them.

XML-RPC Client Code

The example I'm using comes from the code used to implement this blog. Whenever I make a new post, or whenever someone adds a comment, an update is sent to blo.gs, an aggregator that tracks blog changes. Here's how it looks:

sendBlogUpdatePingTo: server

	|  url name args response xmlRPC |
	url := self mainLink.
	name := self blogName.
	args := Array with: name with: url.
	xmlRPC := XmlRpcClient url: server.
	response := [xmlRPC 
		perform: self  blogPingMethod
		withArguments: args]
	on: self httpExceptions
	do: [:ex | Transcript show: 'Ping failed: <<', ex error String, '>>'; cr.
			nil].
	response isNil
		ifTrue: [^self].
	response isXmlRpcFault
		ifTrue: [Transcript show: 'XML RPC weblog.ping failed: <<', response description, '>>'; cr].

That's it - The XML-RPC client framework handles all the complexity of actually creating the XML document that is transmitted and sending it. All you really need to do is find out what the services are, and then create simple code like this. Now let's have a look at a server, as implemented in a Smalltalk Servlet.

executeMethod
	"entry point"

	| methodRequest xmlResult |
	methodRequest := self request webRequest httpRequest xmlRpcRequest.
	xmlResult := self performRequest: methodRequest.
	self fillResponseWith: xmlResult asRpcXml asString.


fillResponseWith: xmlResult
	response contentType: 'text/xml'.
	response status: 200.
	response contentLength: xmlResult size.
	response write: xmlResult.

That's pretty much it. You register the messages you can receive, and then simply have the server perform them. The framework handles creatinga valid response in an XML document from your objects. It's all pretty simple, as Roger took care of all the hard stuff. I've been using this on my blog for awhile now. You can take a look at my full implementation usage by loading the CST-Blog bundle from the public store. If you have any questions, feel free to email me.

Update It seems that this is not the expected behavior, but some kind of problem related to a server outage they had over the weekend. I've coded around it in the meantime - but hopefully it will be fixed soon.

There's been some talk about bad RSS readers - now I have a beef about bad feeds. Today I was reading Sam Ruby's comment feed and stumbled across something odd - the feed <link> element was set relative - to /blog. Well that's special. Relative to what? The guess BottomFeeder now makes is based on the feed URL - I strip off the elements after the domain, assume that's the base, and slap the relative URL onto that. It works in this case - but it's a hack, since there is no information in the feed which actually specifies the base URL. I can understand items having relative URLS - in that case, it's fair to assume that they are relative to the link element. However, if both are relative, you have to guess. Guessing is not robust.

Scott Johnson discusses subtle bugs on his blog - and I identified with this piece:

Now I do ok intellectually but I honestly don't think I'm all that smart as a general rule of thumb. I've hired smart people before and they make me feel like a drooling idiot. Still I'm definitely both skilled and experienced and I read a lot which people sometimes attribute to smartness. And today those things reared up and smacked me in the head and then dribbled said head down the virtual basketball court and scored an extra point.

I don't actually do hiring, but as Product Manager I interact with a lot of very smart engineers in the Cincom Smalltalk development group, and I've helped interview people who have been hired. So I know exactly where Scott is coming from - I have experience, and I have a good grasp of the VW libraries - but I hardly count myself in the same league with a lot of the developers I interact with.

Buffy and 24 tonight - off to the big screen TV!

That was a pretty cool Buffy. Not whatI expected, and the show looks to be winding down in top form - which is a good thing, after last season. Now on to 24, where we see if the plot line continues to go beyond my ability to suspend disbelief....

Here I am with a notebook and a house LAN (wired and wireless) - and my battery is torched. It burned out this evening - I now have to shutdown the machine anytime I want to move it. Sigh.

Over on Sam Ruby's blog I stumbled across an amusing alternate title for Alan Kay's "Daddy are we there yet" talk at ETCon:

Now that my weblog is back on it's feet, it's time to capture a few thoughts on the last week's excellent ETCON Best of show clearly goes to Alan Kay's "Daddy are we there yet" presentation, though it equally well could have been titled "it must suck to be forty years ahead of your time".

Yeah, that about captures the way Smalltalkers feel when we survey the field of mainstream development....

I've been scanning my logs again, and the results are always interesting. Over the last few days, IE and Netcape/Mozilla hits were nearly equal. I've also found that a full third of my traffic comes from bots - things like the Google Bot, Syndic8, etc. I suspect that I have a higher volume of Linux/Mac users hitting this site than many others - what I'd be truly curious about are stats from a more mainstream, non-technical site.

Scott Knowles has a very detailed take on the Lehrer blog story. Here's an interesting point - one which I agree with:

Is weblogging journalism?

Joan (MSNBC Editor): "One of the values we place on our own weblogs is that we edit our webloggers. Out their in the blogosphere often it goes from the mind of the blogger to the mind of the reader. And there's no back up. And I would submit that that editing factor really is the factor that makes it journalism. Are you making a mistake here? Do you really want to say that? Do you really want to use that word? Is that libelous? All those basic journalism questions that we always ask."

This is interesting to me because it's almost exactly what Henry Copeland and I briefly discussed after DC DOT COMM in January - He said much of the same.

However, this is where I disagree with Joan. Those are the "basic journalism questions that news media always ask?" (paraphrased). I think instead of saying the editor/writer structure makes MSNBC's blogs real journalism and others not is somewhat of a biased statement to the existing (or shall I say old) hierarchy in the news media.

There are different types of journalism. The journalism that blogging brings to the table is a singular person, gonzo style. In the flesh, without hierarchical control. And to the point of several in the story, blogging is participatory journalism. I would even call it conversational journalism. Conversations do not hold the same characteristics as broadcast communication. I would argue that there is a mutual understanding between reader and writer in much the same way that our real world debates and converses.

One of the things I like about blogs is that they more informal that news - conversational, as Scott put it. It's a good post, well worth reading

Ted Leung points out some reflection in Python. Seems to me that there is increased interest - especially in the TDD/Agile community - in dynamic languages. This is a very good opportunity for Smalltalk - if there's an XP users group in your area, you should start showing up at meetings and offer to demonstrate TDD in Smalltalk. No one's going to find out unless we tell them....

ComputerWorld has noticed blogging:

Early weblogger and developer Dave Winer (www.scripting.com) says weblogs have the following characteristics, which he sums up in the phrase "personal Web-based publishing communities":

• Personal. Blogs are created by a single person, expressing a distinct personality.
• Web-based. They're frequently updated, inexpensive to maintain and accessible via a Web browser.
• Published. Automated publishing tools help the author present his words in an attractive format, and maybe even syndicate them.
• Communities. Blogs link to other blogs and sites, acknowledging that they're part of a larger world.

Blogs have gotten a lot of notice recently - TV (Lehrer), trade rags - the works.

I noticed yesterday that my RSS feed wasn't validating. Running off with some assumptions, I tried all sorts of things that didn't work. So I asked a question in a conversation with one of our engineers, and he immediately noticed that there was a bad character in the feed.

Insert head pounding here

The Irony? It was in this post about subtle bugs....

I stumbled across an anti-XP paper on the ObjectView site. I decided to take a look, and see what the author's beef was. I'm a little surprised at the sheer intellectual dishonesty involved here. For instance, the authors state at the beginning:

To start with, the complete title (which is "XP Refactored - The Case Against Extreme Programming") will give you an idea of what Matt and I are doing. By way of background, I got engaged in the XP debate originally on OTUG (the Object Technology User Group), mostly with Bob Martin and Ron Jeffries a few years ago (this culminated in quite an intense discussion about the Chrysler C3 project, and whether its cancellation meant success (as they claimed) or failure (as it seemed to many of us). Subsequently I've made a few attempts at satirical humor that have been pretty well received, notably "Alice in Use Case Land", which was a keynote speech I gave at UML World and recently repeated at the Rational User Conference, "Fragile Methods" which was a talk I gave at SD West, "Emperor's New Code", and then my son Rob and I have a lot of fun rewriting old Beatles songs, which we've compiled into "Songs of the Extremos."

Well let's just start with that, shall we? Based on what I've read on the c2 Wiki, the project died for the same reason that many projects die - politics. In particular:

Near as I can tell the fundamental problem was that the GoldOwner and GoalDonor weren't the same. The customer feeding stories to the team didn't care about the same things as the managers evaluating the team's performance. This is bad, and we know it's bad, but it was masked early because we happened to have a customer who was precisely aligned with the IT managers. The new customers who came on wanted tweaks to the existing system more than they wanted to turn off the next mainframe payroll system. IT management wanted to turn off the next mainframe payroll system. Game over.

That's a clear political problem. And yet the leading premise of the authors of this paper is that - since C3 failed, XP failed - these guys are big fans of some Iconix modifications to the RUP process. So by their leading argument, if any RUP project has ever died due to politics, RUP is a failure? Is this the kind of argument they want to make?

Let's move on. Their next strategic argument is the setting up of a strawman. In reference to "The simplest thing that could possibly work":

Well, there are many variations on this theme. KISS (Keep It Simple, Stupid) is one of them. And keeping it simple is, of course, a good idea in most cases. But let's examine the phrase "the simplest thing that could possibly work". Think carefully about what this means. This phrase goes beyond normal "keep it simple" advice. We do not build generality into the system in expectation of future requirements. We build the simplest objects that can support the feature we're working on right now. This is a very very different idea from just "keeping it simple". This says "don't think ahead about other requirements, just slap some code together for what you're building RIGHT NOW". This advice, in the hands of most programmers that I've ever met (and I earned my living writing code for about 15 years), can prove to be incredibly dangerous. What the Extemos ask you to believe is that "constant refactoring after programming" (do your own acronym) makes that all OK. It's OK to hack stuff together with rubber bands, bubblegum, and scotch tape today because you're going to refactor it tomorrow anyway. Uh-uh. Not for me.

You see that? YAGNI means, don't build more than you need to, since your guesses are unlikely to match future needs. They morph this into "hack it any old way and refactor later". It doesn't mean that. In fact, they know it doesn't mean that - either that, or they simply made wild assumptions a long time ago, and have stuck to them in order to justify their arguments. XP isn't about hacking - in a true Test Driven Development set up, hacking is the last thing that will occur. So again, these guys have translated a part of XP into something it isn't, and argued against that fake problem. The interviewer should not have let them get away with that.

Later, they complain that early deliverables results in the project going into maintenance at a very early stage. so what? BottomFeeder was delivered in its 1.0 incarnation at a point where these folks would have said it was not ready. The advantage of that was early feedback from real users who could raise real issues with what we thought were good ideas. We learned a lot that way, and have iterated to a much better product over time. It hasn't stopped us from big changes either - which is one of the "problems" they say will occur - entire subsystems - including the feed persistence mechanism - have been changed over completely more than once. It sounds to me like these guys have had the luxury of working on projects that are very stable, and where requirements change slowly - if at all. That's not the world most of us developers live in.

But wait, here's another whopper:

"My big issue with XP's approach is that pair programming is used as an excuse for not doing upfront design. That's completely bogus, in my opinion"

What's completely bogus is this assertion. Pair programming works from the "two heads are better than one" mindset, not at all from this silly statement. He goes on to make a whole lot of claims about how pair programming wouldn't work, based on two examples. Argument by anecdote, always a great way to build a strawman. But wait, there's more!

Actually, a nice aspect of XP is that the individuals get to sign up for the tasks that interest them the most in each increment, so their natural role in the team really does emerge. I would recommend doing that in any project, XP or otherwise - letting people identify the things that interest them the most. People are much more highly motivated when they are good at what they are doing, hence more productive. Of course you have to draw the line somewhere though: there are always "chores" that somebody just needs to knuckle down with and get done. And an added danger is that in a roomful of programmers, no one ants to do design, or test what they've written, or write things down. They just want to get coding: everything's a prototype, nothing is customer-facing, unless they are told otherwise. Sometimes you need someone in a position of higher authority (a team leader, say) to make sure the not-so-fun stuff gets done too. Otherwise, it's like having a house full of kids who are allowed to watch TV and eat ice-cream all day, but the washing-up never gets done.

I love his casual assertion that in XP, "chores" like testing won't get done. He's either never read anything about XP, or he's back to making wild strawmen up to combat. Either way, it's laughable. Test First is perhaps the most important tenet of XP. But it's so much easier to invent strawmen than to actually have a cohesive argument...

Bah

I stumbled across an anti-XP paper on the ObjectView site. I decided to take a look, and see what the author's beef was. I'm a little surprised at the sheer intellectual dishonesty involved here. For instance, the authors state at the beginning:

To start with, the complete title (which is "XP Refactored - The Case Against Extreme Programming") will give you an idea of what Matt and I are doing. By way of background, I got engaged in the XP debate originally on OTUG (the Object Technology User Group), mostly with Bob Martin and Ron Jeffries a few years ago (this culminated in quite an intense discussion about the Chrysler C3 project, and whether its cancellation meant success (as they claimed) or failure (as it seemed to many of us). Subsequently I've made a few attempts at satirical humor that have been pretty well received, notably "Alice in Use Case Land", which was a keynote speech I gave at UML World and recently repeated at the Rational User Conference, "Fragile Methods" which was a talk I gave at SD West, "Emperor's New Code", and then my son Rob and I have a lot of fun rewriting old Beatles songs, which we've compiled into "Songs of the Extremos."

Well let's just start with that, shall we? Based on what I've read on the c2 Wiki, the project died for the same reason that many projects die - politics. In particular:

Near as I can tell the fundamental problem was that the GoldOwner and GoalDonor weren't the same. The customer feeding stories to the team didn't care about the same things as the managers evaluating the team's performance. This is bad, and we know it's bad, but it was masked early because we happened to have a customer who was precisely aligned with the IT managers. The new customers who came on wanted tweaks to the existing system more than they wanted to turn off the next mainframe payroll system. IT management wanted to turn off the next mainframe payroll system. Game over.

That's a clear political problem. And yet the leading premise of the authors of this paper is that - since C3 failed, XP failed - these guys are big fans of some Iconix modifications to the RUP process. So by their leading argument, if any RUP project has ever died due to politics, RUP is a failure? Is this the kind of argument they want to make?

Let's move on. Their next strategic argument is the setting up of a strawman. In reference to "The simplest thing that could possibly work":

Well, there are many variations on this theme. KISS (Keep It Simple, Stupid) is one of them. And keeping it simple is, of course, a good idea in most cases. But let's examine the phrase "the simplest thing that could possibly work". Think carefully about what this means. This phrase goes beyond normal "keep it simple" advice. We do not build generality into the system in expectation of future requirements. We build the simplest objects that can support the feature we're working on right now. This is a very very different idea from just "keeping it simple". This says "don't think ahead about other requirements, just slap some code together for what you're building RIGHT NOW". This advice, in the hands of most programmers that I've ever met (and I earned my living writing code for about 15 years), can prove to be incredibly dangerous. What the Extemos ask you to believe is that "constant refactoring after programming" (do your own acronym) makes that all OK. It's OK to hack stuff together with rubber bands, bubblegum, and scotch tape today because you're going to refactor it tomorrow anyway. Uh-uh. Not for me.

You see that? YAGNI means, don't build more than you need to, since your guesses are unlikely to match future needs. They morph this into "hack it any old way and refactor later". It doesn't mean that. In fact, they know it doesn't mean that - either that, or they simply made wild assumptions a long time ago, and have stuck to them in order to justify their arguments. XP isn't about hacking - in a true Test Driven Development set up, hacking is the last thing that will occur. So again, these guys have translated a part of XP into something it isn't, and argued against that fake problem. The interviewer should not have let them get away with that.

Later, they complain that early deliverables results in the project going into maintenance at a very early stage. so what? BottomFeeder was delivered in its 1.0 incarnation at a point where these folks would have said it was not ready. The advantage of that was early feedback from real users who could raise real issues with what we thought were good ideas. We learned a lot that way, and have iterated to a much better product over time. It hasn't stopped us from big changes either - which is one of the "problems" they say will occur - entire subsystems - including the feed persistence mechanism - have been changed over completely more than once. It sounds to me like these guys have had the luxury of working on projects that are very stable, and where requirements change slowly - if at all. That's not the world most of us developers live in.

But wait, here's another whopper:

"My big issue with XP's approach is that pair programming is used as an excuse for not doing upfront design. That's completely bogus, in my opinion"

What's completely bogus is this assertion. Pair programming works from the "two heads are better than one" mindset, not at all from this silly statement. He goes on to make a whole lot of claims about how pair programming wouldn't work, based on two examples. Argument by anecdote, always a great way to build a strawman. But wait, there's more!

Actually, a nice aspect of XP is that the individuals get to sign up for the tasks that interest them the most in each increment, so their natural role in the team really does emerge. I would recommend doing that in any project, XP or otherwise - letting people identify the things that interest them the most. People are much more highly motivated when they are good at what they are doing, hence more productive. Of course you have to draw the line somewhere though: there are always "chores" that somebody just needs to knuckle down with and get done. And an added danger is that in a roomful of programmers, no one ants to do design, or test what they've written, or write things down. They just want to get coding: everything's a prototype, nothing is customer-facing, unless they are told otherwise. Sometimes you need someone in a position of higher authority (a team leader, say) to make sure the not-so-fun stuff gets done too. Otherwise, it's like having a house full of kids who are allowed to watch TV and eat ice-cream all day, but the washing-up never gets done.

I love his casual assertion that in XP, "chores" like testing won't get done. He's either never read anything about XP, or he's back to making wild strawmen up to combat. Either way, it's laughable. Test First is perhaps the most important tenet of XP. But it's so much easier to invent strawmen than to actually have a cohesive argument...

Bah

File under "pay no attention to what's happening in the market" department, as a Sun spokesman says the following:

Linux is a good thing, but it isn't all things to all people. And companies that are making more than a tactical investment should be very careful to invest with their eyes wide open. I'll start with five major points:

The Linux story is mostly a brat pack remake of the Unix story It is going to take years for this story to play out as Linux matures Most of today's Linux buyers are merely taking advantage of commodity hardware and what I perceive to be a commodity operating system The future of enterprise computing isn't about the OS, anyway At the end of the day, many Linux customers will end up back where they started

Yeah, back where they started, on a Unix variant. Unfortunately for Sun, that Unix variant won't be Solaris. Linux is way cheaper, performant enough, and stable enough.

Today was my day to volunteer at my daughter's school - cut and paste day, usually :) Today was a little different - there's a bigevent coming up for the kids, and they needed signs printed. I figured how hard could mail merge be?.

Sigh. My printers absolutely refuse to print in landscape mode while doing mail merge. The print preview lies. Bordering a page with an outline, forget it. Word hit the peak of productivity at Word 2.0 - and has been downhill ever since....

I got a copy of some of the logs from the main Cincom site and got some interesting information. As I expected, IE hits on the main site are much more predominant than on this site. Here, Mozilla/Netscape makes up 40% or so of the browser traffic - on the main site, 81% is IE, 13% is Mozilla/Netscape. Interestingly, far fewer bots hit the main site as well. The other cool part - almost 24% of the traffic on the main site goes to the Smalltalk side of it. All very interesting, when combined with my previous looks at the logs...

I've thought that Angel was better than Buffy all season long - but I also knew that, based on the way both storlines were progressing, there was going to have to be a link between them eventually. That's whatwe got last night - the link between the 2 story arcs. The last 2 episodes of Buffy should be very interesting, with Angel in Sunnydale...

I have created a BottomFeeder bookmarklet. What's that? Well, you can drag the bookmarklet (see below) to the links area of your browser, and it will add an RSS auto-discovery tool to your browser. As you browse websites, you'll be able to select the bookmarklet - and it will scan the page you are browsing for RSS links, and subscribe youto them in a running copy of BottomFeeder. The bookmarklet can be found on the BottomFeeder home page

Here's a coll use of RSS:

There is an RSS feed of the calendar for the programming language course I'm teaching. You can subscribe to it in your news aggregator and get a daily reminder of that day's lecture and what homework is due.

RSS is out in the wild - no telling what people will do with it :)

I came across this post about the ongoing arguments over RSS between Bill Kearney and Dave Winer. I watch this sort ofthing with an amused air of detachment; I just work on an aggregator - I don't feel all religious about tag intricacies. Anyway, this is just precious:

Just a little preview of today's episode on the syndication list

Dave: Now I'm filtering his (ed: Bill) email in such a way that it's deleted on the server, I'll never see another message from him, so I won't be able to rebut it. Please assume that I would if I had read it.

Bill: Oh bull****, you've threatened that nonsense before. You're too addicted to all the attention to ever possibly ignore it.

And as with real day time television, you are almost too embarrassed to watch (and you certainly won't admit it), but you cannot get your eyes of it once it is on, just like that car wreck you passed on the highway

The funniest part is the comment thatcame in there:

The first car wreck you pass in a day, sure. The third, maybe. By the twentieth, you just wish the b******* would learn how to drive, so they could stay out of your way and let you get to work.

lol

ESUG looks good again this year - the list of keynote speakers is out:

• Lars Bak
• John Brant
• Vassili Bykov
• Dan Ingalls
• Joseph Pelrine

That's a powerful lineup. This year's event is being held in Bled, Slovenia, August 23 - August 29. The blurb on this year's meeting:

The entire ESUG Smalltalk Conference Committee is pleased to invite you to contribute to and actively participate in this 11th edition of the main European conference on Smalltalk. Continuing a strong tradition, the attendants will enjoy tutorials, workshops and demonstrations on various Smalltalk related subjects.

Since last years attendees enjoyed having a Camp Smalltalk during the conference, another Camp is planned for this conference edition too. New this year is that the talks are scheduled primarily in the morning and that the afternoon focuses on concrete collaborations between participants and workshops.

This year the conference will be held in Bled - Slovenia from Saturday, August 23 to Friday, August 29, 2003. This is the first time that the conference takes place in a country of Eastern Europe. We're very excited by meeting Smalltalkers in a very beautifull place in mountains.

Looks good, wish I could be there. That's still the week my daughter starts school....

Ted Neward wonders when Object-Hierarchical Impedance Mismatch will start getting talked about:

But what happens when objects don't form nice, natural trees?

Hierarchical data models are not new; in fact, the relational data model was an attempt to find something easier to work with than the database systems of the day, which were similar in concept to the hierarchical model we see in XML today. The problem with the hierarchical model at the time was that attempting to find data within it was difficult, since users had to navigate the elements of the tree manually, leaving users to figure out "how", instead of focusing on "what"--that is, how to get to the data, rather than what data they were interested in.

With the emergence of XML (and the growing interest in "XML databases", despite the inherent ambiguity in that term), it would seem that hierarchical data models are becoming popular once again. While a full discussion of the implications of a hierarchical data model are beyond the scope of this book, its important to discuss two important things: when we're likely to use a hierarchical data model in J2EE, and what implications that's going to have for us a Java programmers.

While the industry currently doesn't recognize it, the mapping of objects to XML (the most common hierarchical storage model today) is not a simple thing, leading one to wonder if an object-hierarchical impedance mismatch is just around the corner.

Now there's an interesting question. We spent the 90's focused on the object-relational mismatch - looks like it's back to the future! Thinking about it,. XML storage isn't a lot different than the old hierarchical datamodels that prevailed before the RDBMS revolution. Somewhere, an old Cobol hacker at IBM is laughing his socks off....

Ted Neward has a post on O/R up. I raised this post on the Smalltalk IRC channel to general snickers - I'll probably have a more detailed critique from an O/R expert later. In any case, I'm reading along and come across this:

If none of these approaches seems particularly what you're looking for, particularly because they still seem like too much work and too awkward to work with from within Java, another approach is to make use of the recently-standardized SQLJ, or "embedded SQL for Java", specification recently approved as part of the SQL-99 specification. As with other embedded SQL technologies, SQLJ allows a programmer to write SQL statements directly within the Java code, which is then preprocessed by a SQLJ preprocessor, turned into regular Java code and fed to javac as a normal compilation step. The SQLJ preprocessor takes care of any of the call-level interface logic in your Java code--you just focus on writing the SQL when you want to talk to the database, and on Java when you want to do anything else.

The easiest way to use SQLJ is to use static SQL statements embedded in the code directly, what's known as SQLJ clauses:

Ummm.... you build a data access layer with embedded SQL all through it? One of the first Smalltalk applications I built (way back in the early 90's) did that, because at the time "it seemed simple". Then the schema changed, because the dba's decided it needed changing. Boom crash, broken app, with changes required all over the place. IMHO, embedding the SQL this way is as silly as scattering hardcoded constants all over the place - it doesn't scale.

Then there's this:

One major drawback to SQLJ, however, is its relative lack of support within the J2EE community. Although the J2EE and EJB specifications do mention it by name as a possible data-access technology layer, it receives almost no attention beyond that. Oracle is the only major database vendor to have a SQLJ implementation available as of this writing, and there seems to be little support from the community as a whole, which is a shame, because in many respects this is the epitome of a relational-first persistence approach.

So not only is it a terribly bad idea, it's unsupported for the most part. "Here use this approach that cripples your application maintenance, and obtw, better stick to one DB". Bah. It looks more and more to me like Gemstone is like Da Vinci - brilliantly ahead of it's time, simply outside the grasp of the current crop of developers....

Now here's something cool. very nice article on Smalltalk, web services, and ease of development:

There's more talk about Smalltalk these days, as the object-oriented programming language gains something of a developer following for Web applications. The notion of Web services, where one discrete piece of software talks to another without knowing very much about the other system, was a concept that originated in Smalltalk, say implementers of these new apps.

Now there's a nice piece of news - something that will hopefully catch some eyes. There's more:

Some experts point out that Java, C++, and Microsoft's C# are evolving in a direction set over 30 years ago by Smalltalk, yet rarely do proponents of these languages acknowledge their debt. Such oversight only reinforces the undying loyalty that some developers feel toward the language. "I will quit coding in Smalltalk when they pry the keyboard from my cold, dead fingers," says Karen Hope, chief architect of an online Smalltalk insurance-quote application at the St. Paul Companies Inc.

And then this, from Allen Davis:

Smalltalk is "by far the best programming language available for Web and enterprise development," says Allen Davis, the new executive director of the Smalltalk Industry Council and CEO of Smalltalk vendor Knowledge Systems Corp. When it was first conceived by Alan Kay and his team at Xerox Palo Alto Research Center, Smalltalk was regarded as a resource hog. But as systems grew in processing power, Smalltalk began to come into its own. As part of its effort to revitalize the language, the council is organizing its first Smalltalk Solutions Conference, July 14 to 16, in Toronto.

Some other developments are in Smalltalk's favor. IBM includes Smalltalk in its VisualAge integrated development environment. And Cincom Systems Inc., which acquired a Smalltalk toolset from ParcPlace, has lowered prices for getting started from $3,500 to a free download for developer try-out and $500 a year for one developer's deployment of Smalltalk applications to one or two users.

So get the to the download site and have a look!

Yes, it was well worth going. I went in with low expectations after the firstmovie - but it was worth it. Recommended!

Now this story is amazing:

MOAB, Utah (AP) -- A Colorado climber amputated his own arm Thursday, five days after becoming pinned by a boulder, and he was hiking to safety when he was spotted by searchers, authorities said.

Now that took some intestinal fortitude. Wow

Last week I commented on a Cringely piece where I thought he wandered off into tinfoil hat territory. Well, this week he's back, making the other side of his argument about Open Source. This week he takes the tack that Open Source is here to stay. At first, he's making some relatively reasonable points about the sorts of extant OS projects:

But it could be so much better. At the risk of annoying my two remaining technical readers, I believe Open Source suffers from a kind of unspoken caste system, with a few projects getting lots of resources and most other projects getting very little. The result is what I think of as three classes of Open Source software -- professional, semi-pro, and amateur. I'm not saying this is bad, just that it is the case.

Truly professional software development really needs technical writers, user interface designers, and QA people, but most Open Source projects lack those types of helpers, and therefore, often fall short in the long run. Those projects that DO succeed (Apache, the Linux kernel, et cetera) are those that only need that type of diversity to a very small extent because they generally live on the command line. These applications generally target people who can get by without the product having the best documentation or interface -- namely, other developers. I think of these as semi-pro products in that they are robust, but tend to lack external trappings of commercial software

Ok, that's mostly reasonable. I feel very fortunate to have Rich Demers documenting BottomFeeder - he's uncovered numerous problems and inconsistencies in addition to creatinga great set of doc - so I can see Cringely's point about projects that lack that being less useful outside a small circle. However, we soon return to tinfoil hat territory:

Look how many Open Source projects have updated versions and the changes read "cleaned up some code." What that really means is the programmer loves his little project, and a few fans have made him love it more, and he just NEEDS to touch it. He can't keep his hands off the code even when he isn't adding new features.

"Cleaning up code" is a terrible thing. Redesigning WORKING code into different WORKING code (also known as refactoring) is terrible. The reason is that once you touch WORKING code, it becomes NON-WORKING code, and the changes you make (once you get it working again) will never be known. It is basically a programmer's ego trip and nothing else. Cleaning up code, which generally does not occur in nature, is a prime example of amateur Open Source software.

Hmmm. Refactoring is useless? I guess he has this notion that programmers always produce the best possible code the first time out, and that new features never require changes to previously working code? And his statement that this breaks things - here's a phrase he can add to his vocabulary:

Unit Testing

Bah

Infoworld now has a bunch of RSS feeds - the links are right on the front page. Over time, most one-way communications that are now email-lists will likely be replaced with RSS. No possibility of spam, or of the clientaccidentally classifying it as spam...

Or is that Objects vs. the Web? Alan Knight of Cincom and Naci Dai of Eteration have a paper out on OO and web development. The paper discusses how to use the MVC paradigm with web development. This is the same material which has been used for a presentation they have given at various trade shows. Go have a look; it's well worth your time.

Update - thanks to Alan Knight, for pointing out my mistake on Naci's name, and providing an updated link to his website