Smalltalk Tidbits, Industry Rants

The Fishbowl has some interesting thoughts on where software revolutions come from:

Look at Java, recently described on Bruce Eckel's weblog thusly, citing Paul Prescod: "He called COBOL and Java neanderthal languages that have no descendents on the evolutionary tree.". Java has great libraries and right now, great momentum, but it's a dead-end. It has no future. It has nothing to evolve into. Its only likely long-lived descendant is C#, a language that, if it survives, will do so for the same reasons that Visual Basic survived so far beyond BASIC's use-by date. This is the source of my disquiet about Web Services. Microsoft are telling me they'll be big. IBM are telling me they'll be big. Some very respected developers are enthusiastic, but most are sitting back wondering what the fuss is, and have been for three or four years now. The momentum just hasn't gathered. SOAP and XML-RPC are both great solutions to a particular range of problems, but we're just going to have to face the fact that the chance of them becoming a revolution, as promised, are slim. Shortly, some technology is going to appear and blow my socks off. But it's more likely to appear in some experimental corner of JBoss 4.0 than it is in J2EE 1.4 or in .NET. And it's quite likely going to appear in Python or Ruby, or even coded in C by some college student or lab assistant who has thought of a really neat way to solve a real problemin the real world, and wants to share that solution with the rest of us. And we'll take it, and use it in ways the inventor never dreamed of. That's where revolutions come from.

My posting tools are apparently posting through the proxy server (I'm on dialup at the hotel) - but telling me that they aren't. Then there was IE's complete refusal to browse with the proxy server, while Netscape seems happy. Sigh....

Spotted on Loosely Coupled:

The bad news for the IT industry is that CIOs have realized they can spend less and achieve more, using web services. Instead of investing in new systems, they want to get more out of the systems they've already got. Here's what they've been saying at InfoWorld's CTO Forum this week:

• "We've got to rationalize our investments. We've been spending $4 billion a year for years. We need to get more out of it," says Merrill Lynch's chief technology architect, Rick Carey.
• "When we looked at our core assets, we had lots of services our customers were not using. The problem was [the services] were not flexible and convenient enough," says senior Verizon IT executive Luis Lando.

The really bad news is that they can expose and link those web services without having to invest in expensive new integration systems. They don't even have to buy application servers, according to Cape Clear founder Annrai O'Toole

Hah! Anyone who thinks that exposing via web services will be easier than - say CORBA - hasn't tried it both ways.....

I'm copying this from the vwnc mailing list - there's now Store and EXDI support for SqlLite. go here for details.

I've written an EXDI and Store interface for Sqlite (http://www.sqlite.org/) databases. It works on my machine under linux and windows (wine, really). And I think Sqlite is quite neat for local repositories, because the setup is so easy - you just need one dll/shared library where VW can find it. No server process, no configuration files.

The bad news is it's new and untested. While the feature set I use seems to work, that's about all I can claim. There were also some problems with Sqlite's view implementation; a large part of the code is workarounds. So I don't want to put it in the open repository until a few more people have used it.

I did put it on a web page: install instructions and downloadable links are at http://www.gjdv.at/cgi-bin/pyson.cgi/en/vwsqlite.pyson

If you do give it a try, I would suggest to also use a "real" repository, or "Publish as Parcel" on a regular basis ;-)

Enjoy, Juergen

I got this in email as a response to this post:

Last night I read a piece by Dr. Alan Kay. Within the article is a section "Most of current practice today was invented in the 60s". It goes on:

"It is worth noting the slow pace of assimilation and acceptance in the larger world. C++ was made by doing to C roughly what was done to Algol in 1965 to make Simula. Java is very similar. The mouse and hyper-linking were invented in the early sixties. HTML is a markup language like SCRIBE of the late 60s. XML is a more generalized notation, but just does notationally what LISP did in the 60s. Linux is basically Unix, which dates from 1970, yet is now the "hottest thing" for many programmers. Overlapping window UIs are one of the few ideas from the seventies that has been adopted today. But most of the systems ideas that programmers use today are from the data- and server-centric world of the 60s.

The lag of adoption seems to be about 30 years for the larger world of programming, especially in business."

This, as you might expect, leads us to believe that the time for Smalltalk (and Lisp?) is about to come?

I added OPML support to BottomFeeder today. What can the system do with this?

• BottomFeeder now supports OPML (as done by syndic8) in addition to OCS for feed lists
• BottomFeeder can export the subscribed feeds as an OPML file. This flattens all feeds into a single folder, but does allow export
• BottomFeeder can import OPML based (as done by syndic8) feedlists from a local file, and convert that into a set of subscribed feeds

Numerous people have requested this feature.

Via Matt Croyden

Follow the link for all the feeds - 12 from Cisco alone!

I've managed to get a few interesting new BottomFeeder features done in the last two days:

• Import from OPML File - You can now import an OPML file (in the format used by syndic8 into BottomFeeder. The imported feeds will be added to a new folder under the subscribed list
• Import from OCS File - You can now import an OCS file into BottomFeeder. The imported feeds will be added to a new folder under the subscribed list
• Add Feedlists from an OPML source (such as syndic8).

One of the complaints I've received in the past is that BottomFeeder cannot have feeds added from local export files (say, from other RSS aggregators). If you can get your feeds into OPML or OCS format, that's no longer the case.

Cincom Smalltalk spring 2003 will be released on April 7th. Engineering formally released the product last week, and the only thing left now is CD production and product shipments to our subscribed customers. It's a great release - check this page for details.

I've just added an RSS Import to BottomFeeder. Numerous tools export feeds as either RSS, OPML, or OCS. BottomFeeder can now handle all three. In the case of RSS, the feeds get listed as items. In any case, BottomFeeder can now import all three formats, and export as OPML. This should make it easier to test the tool out.

Now Microsoft is using it for MSDN updates - see Rob Fahrni's blog for details. Specific RSS Links via Tim Ewald

Sam Gentile has a new post about S#:

Very cool... simplegeek

Yes it is and something I will be looking into and writing about. "S# is not a scripting language in the sense that it's any less powerful than other .NET languages; instead, it's a scripting language in the sense that it doesn't require strong variable typing in other words, it's a dynamically typed language. . . Beyond that, you can perform operations impossible in VB.NET or C#. " - Like Jason and his upcoming Win-Dev session, I am always interested in moreof the CLR from the internalperspective or "alternative Langauges" aspect of .NET to keep things interesting.

More news from the REST vs. SOAP front, via Slashdot:

tadghin writes "I was recently talking with Jeff Barr, creator of syndic8 and now Amazon's chief web services evangelist. He let drop an interesting tidbit. Amazon has both SOAP and REST interfaces to their web services, and 85% of their usage is of the REST interface." Read on for some more thoughts and information on REST and Web services, including information about a free Web services seminar on April 22nd.

" Despite all of the corporate hype over the SOAP stack, this is pretty compelling evidence that developers like the simpler REST approach. (I'm sure there are applications where SOAP is better, but I've always liked technologies that have low barriers to entry and grassroots adoption, and simple XML over HTTP approach seems to have that winning combination.)

This is pretty much how it's going in the blog world as well - when developers choose, they choose simple....

The planning meetings this week were too short, but also exhausting - start at 9, go until 7. Then hop back on a plan to get back home. At least I wasn't insane enough to take a red eye this time around. On the other hand, I got stuck - again - on the old TWA equipment American Airlines runs - no power at the seats! Since my notebook spends most of its time plugged in, the battery life is awful.

There was a plus side to that, of course - I read a couple of not terribly memorable, but interesting enough yarns. I'll spend the next few days sorting out how the meetings went, and then I'll have to go and edit our internal wikis to reflect the results of my cogitation. I'll also have to update the public wiki - with VW 7.1 and OS 6.8 out, it's time to start posting a coming attractions page for the next release.

Our current plan calls for the next release in the fall, likely November. That will keep us in the regular schedule we have been trying to hit - and also set up the follow on release to synch up with Smalltalk Solutions 2004.

So in Meerkat's Open Source Column, I see this:

Of course Sean is dead wrong as to the salient matter, but he's always a good read. RDF is for people who understand directed graphs. If you take any random audience, this is, of course, a small proportion. Same story for forensic histology, but I doubt Sean would moot for closing down all the crime labs. The argument that "not everyone can get RDF " is not worth any number of words. The more interesting point is that anyone who can't get RDF can't get relational databases or any other sort of formal information modeling, and they can't get code (both flow of control and declarative algeras are graphs more complex than RDF). For those outside this set, as Sean points out too obliquely, there are plenty of tools and they needn't deal with RDF directly

Yeah, right. Here's two words on RDF:

Needless Complexity

One thing I'm hoping will happen with the new import/export tools for BottomFeeder is a greater ability on the part of potential users to try the tool out. Bf now imports OPML, OCS, and RSS exports, converting them to a set of subscribed feeds. It likewise can export subscribed feeds as OPML, allowing easier interchange in that direction as well.

Missing Angel and 24! Thank goodness for the Replay....

David Buck pointed me to this Slashdot piece this morning. Alan Kay is still doing his The Computer Revolution Hasn't Happened Yet talk. Here's some excerpts:

While at Xerox PARC, Kay invented Smalltalk. Although the present day hot OO languages, Java and C#, make a lot of their C-like syntax, much of their real roots can be found in Smalltalk. In addition to an OO language, Smalltalk was also a development system and an operating system for Smalltalk programs. The five person Smalltalk team at PARC created both the software and the hardware to run it on. As a result, Smalltalk applications performed quite well on these systems.

In the 1980s, Kay explains, Intel and Motorola were not producing processors that could run these higher level languages. As a result, programmers interested in performance were programming in C and early bound languages. When Stroustrop developed C++ he wasn't trying to emulate the work done at PARC, he was creating support for objects using a preprocessor for C. The relationship between C++ and C was much like the relationship between SIMULA and Algol. Kay sees Java as falling between Smalltalk and C++. In some ways it is an improvement, in other ways it is mainly C++ with garbage collection. One of the most obvious deficiencies of Java, says Kay, is that "Java has a difficult time of adding to itself."

Go have a look at the whole article - it's well worth reading

I stumbled across this cartoon recently - very amusing. Something I can definitely identify with...

Writing on Eclipse, Ted Leung writes

Carlos responded to my response (Carlos, I was at the IBM Center for Java Technology in Silicon Valley -- I was part of the team that brought you XML4J, now known as Xerces-J.): The Eclipse environment in the programming language arms race is equivalent to those JDAM GPS guided bombs. These weapons are cheap, it changes the battlefield in a revolutionary way. So the next time someone argues to you that C# has a nice syntactic feature, show him how Eclipse makes that irrelevant.

Yes, for the uninformed masses who haven't seen Smalltalk or Lisp. For those of us who have, it's yet more reason to ponder the snails pace of progress in the "mainstream" of development...

I saw this in the XP mailing list on Yahoo. egb refers to Grady Booch, for context purposes.

There aren't 10-12; there's only one:

- minimize the time between specifying a feature and letting end-users benefit from it

egb: It finally strikes me in reading your message why we sometimes see angst from management as to the business value of agile stuff: the characteristic you suggest is orthogonal to return on investment (this is not to say that they are unrelated, but rather that they are very different measures of success and value). Reducing the time-to-availability is certainly a good value to pursue, but it is not the only one that organizations must embrace - as organizations grow larger and the cost of developing software becomes a relatively large capital expense for the business as a whole, achieving a return on investment becomes a greater driving factor.

Orthogonal to ROI? This is exactly what is wrong with BUFD - you spend so much time determining whether a thing is valuable, that by the time it gets delivered, the ROI has approached zero. Time to availability is perhaps the most important value. Why? Because you can then tell whether a development project is on track or off track. Being on or ahead of time has a value of its own, and tends to build ROI (or prove quickly that there will be no ROI). I don't think it would be possible for me to disagree more with the above sentiment.

And - not to put too fine a point on it - if the cost of developing software gets to be that much of a problem as the business grows, then there is a severe business problem that needs to be fixed. The cost is a symptom of a much bigger problem in that case.

I posted earlier on an XP mailing list thread - here's more:

Orthogonal to ROI?

egb:Yes, these really are different values - but I am not claiming that they are completely independent values. There is certainly a time value to money, meaning that if you can reduce the time-to-availability, there is indeed an economic value. However, I would argue that minimizing time-to-availability is not necessarily equivalent to maximizing return on investment.

Time to availability is perhaps the most important value.

Egb: In some domains, yes, but it is not fair to generalize this to be the primary value in all domains. If I'm writing embedded software for a toy, accelerated time-to-market has value but there is likely greater value attached to reducing per-unit cost...shaving off cents will make a difference in a mass market item (i.e. spending time to squeeze code into a smaller ROM footprint). If I'm writing an avionics control system, I probably have some hard final code complete date and accelerating availability will likely contribute to risk reduction (and thereby will have some economic value) but my return on investment will likely be more impacted by architectural initiatives that drive to economics of scale.

ok - first off, you picked two rather extreme examples. I'd warrant that most people reading this group are building more prosaic business systems - and in that case, your examples don't mean a lot. But even within those systems:

• embedded software in toys or games - if you don't get something in front of the customer fast, you have no market. The toy and game markets are perhaps the prime example of time to market being king; spending a lot of time on design in that space will ensure that you never get a product sold, plain and simple.
• Avionics - economics of scale in the manufacturing sense don't apply the same way to software. we can assemble large factories with machine tools and robots to spew out parts; we can't do anything even vaguely like that in software. I'm not at all sure that I get your point here at all, honestly

...

Why? Because you can then tell whether a development project is on track or off track. Being on or ahead of time has a value of its own, and tends to build ROI (or prove quickly that there will be no ROI).

Egb: yes, but my point is that this does not necessarily optimize ROI....reducing time-to-availability does force early risk identification, which is certainly an element of ROI, but it is not the only element of ROI: what is outsourced? How small do I squeeze down my development staff? Can I achieve some economics of scale by earlier architectural investigation?

IMNSHO, if you are considering outsourcing of development, you better outsource the whole thing. Trying to run product management and design here, and development there (where there is 12 hours in tz distant and the culture is different as well) is a just silly. Those who think otherwise will answer differently when asked "Why not outsource marketing?", or "why not outsource all C level staff?" Economies of scale? In software? I truly have no idea what you mean by that. Large teams of developers are a mistake.

...

and - not to put too fine a point on it - if the cost of developing software gets to be that much of a problem as the business grows, then there is a severe business problem that needs to be fixed.

The cost is a symptom of a much bigger problem in that case.

Egb: if you take the automotive industry as an example, reality is that cost is increasing - and not just the total dollars spent, but the relative dollars spent as a percentage of the cost of a car.

Egb: Does this constitute a

If their costs are rising in a well understood business, they have a problem. It's truly that simple. I don't know what they are doing wrong, but I'm sure that they are, in fact, doing something wrong.

Second, getting features in front of end users quickly is optimizing. Getting them there slowly after some sort of complex ROI process is a fools errand. Why? Because in general, without feedback from actual users, it's unlikely that software that solves real problems will be produced

Egb: so, I think we have the two basic issues at hand: first, you would seem observe that time to availability is the most important value - I would agree with you for certain domains, but I would not agree to the generalized statement of applying this to all domains; second, you would seem to suggest that minimizing time-to-availability is tantamount to maximum ROI - I would agree that there is an influence, but I would again argue that there are many other elements that make up an ROI.

IMHO, it's true for any domain I can think of. In domains where something seems to prevent it, I suggest that the entire development model is screwed up, and needs fixing.

I posted here and here on a discussion that cropped up on the XP mailing list yesterday. This C2 page summarizes the whole point I was trying to get at nicely.

I've just read Ted Neward's tips for HTML based apps. They are good ideas, and, if used, will result in a more pleasant end user experience. For instance:

What is it, exactly, that takes an otherwise well-built, well-behaved application and turns it into a snail? A large part of it is the HTML being returned. When an HTML page contains dozens of references to images, large and small, scattered all over the page, the page as a whole seems to drag to a crawl as the browser is forced to go back to the server over and over again to download those images. Yes, the images make the page look pretty, but does the website really need mouse-flyover image-switching graphics buttons for a main menu? Or a footer of ivy leaves twined around the copyright statement? Or the company logo in the upper-left corner of every page? I'll be the first to admit that these things make the page look pretty, but after they've been seen once, they just fade into the background in the user's mind. Worse, though, they still need to be displayed, which means that they still need to be downloaded each and every time. (A good browser will sometimes cache some of the images, but there are limits to what can be cached.) Even beyond that, consider the size of the images themselves--if they're any decent size and color depth at all, they can measure well into the hundreds of kilobytes in size, all of which has to move across the network from server to client.

He goes on with some recommendations, all of which are good - but they raise a simple question in my mind. 20 years ago, we started the migration from server (mainframe) based applications to client (PC) based applications due to - well, pretty much exactly these problems. In fact, a web application is a green screen terminal application with (slowly loading) graphics. So why exactly do we want to deliver applications that way?

In some contexts, it makes a lot of sense. Outside the walls of the business, web apps provide a way of getting feedback from, and getting information to, customers and prospects. We have no control over the platforms those people have, so we have to settle for an LCD solution - a web app. Let's look within the business though - once you get beyond the simple applications, what value is being provided by web apps to your corporate users? Sure, IS can update them easily. On the other hand, delivering patches and/or new versions over the intranet for a client application isn't hard either. You have all that desktop power in front of the users - why throw it away? What many IS groups seem to forget is that the time of their users is important. I've seen web "solutions" to reporting from sales staff that force field sales people to spend 3 and 4 times more time on reporting than they did prior to the roll out of the "productive" web application. There was a reason we abandoned terminal screens; IS organizations would do well to recall those lessons.

Go read Ted Neward's travel thoughts.

Boy, did I ever identify with that.

I've been leaving the dev builds directories alone, just updating the upgrade directories. Well, I am now updating those as well. That way new downloads should get the latest stuff right off....

If you want to call it that. It's a geek's Easter breakfast ;)

Gordon Mohr's Easter breakfast

It's a good thing that the kill rate of SARS is so low (something like 3.5% IIRC). There's something resembling a minor panic starting over it now; can you imagine what the major media would do with a virus that had numbers like Smallpox?

Lots of good historical pointers at Bitworking this morning - including this statistic:

The influenza virus had a profound virulence, with a mortality rate at 2.5% compared to the previous influenza epidemics, which were less than 0.1%

Earlier today, I pointed out that SARS had a death toll (thus far) of 3.5%. Hmm. My own grandmother's twin sister died in the flue pandemic in 1918 - this thing will bear watching....

I just finished implementing RSS Auto-Discovery to BottomFeeder. It's only in the dev builds at this point, but it seems to be working well. It was easy enough to implement as well; the hardest part was filtering all the duplicates from syndic8 XML-RPC queries.

What can you do with this now? Well, when adding a feed, if you type something like CNN, BottomFeeder will search the syndic8 site for matches, and then offer to subscribe you to any/all of them. It's pretty cool.

The new NC downloads are ready! If you have not registered before, register here. If you have downloaded, either login here, or follow the link we sent you in email. Kudos to the Cincom Smalltalk engineering team for a great release!

Tomorrow will be a phone day. I have a call at noon, another at 1, and a third at 2. That will keep me busy for awhile....

That's what SETI@Home is learning with this report from PC World:

The earlier version of the screen-saver software contains a buffer overrun vulnerability in code that processes responses from the SETI@home server, according to Berend-Jan Wever, the 26-year-old Dutch student who wrote the advisory.

After tricking the client into connecting to a server the attacker controls, an attacker could cause the buffer overrun by sending a long string of data followed by a "newline" character, Wever wrote.

The vulnerability affects all versions of the SETI@home client software, including those for the Microsoft Windows operating system, Apple Computer's Macintosh operating system, and versions of the Unix operating system.

The software running on the main SETI@home server at UC Berkeley contains a similar vulnerability, according to the advisory.

And kind of an "oops" here as well:

A separate problem concerns the SETI@home client's transmission of information back to the SETI@home server. Wever discovered that all information from the SETI@home client is sent out in plain text form. That information includes data on the operating system and processor type used by the machine running the SETI@home client.

Malicious hackers could collect the SETI@home data using any one of a number of common packet-sniffing programs, providing useful information for planning a larger network attack, according to the advisory.

The vulnerability would require attackers to "spoof" a fake SETI@home server and trick the software clients into connecting to it before they could be compromised. The SETI@home team knew of no previous attack on a client that used such a method, the Web site said.

However, clients could easily be tricked using spoofing tools or attacked from HTTP proxy servers or routers used by the SETI@home host machine, according to the advisory.

More than 4 million Internet users have registered with SETI@home. Of those registered users, more than 500,000 are considered "active," having returned data to the main server within the last four weeks, according to the project's Web page.

Buffer overflows. So when are people going to learn that C and C++ are simply unsuitable for most tasks?

By now some of you have noticed that the web services file is missing from the download area for NC. This is an oversight, not us holding anything back. We should have this addressed sometime this morning - I just have to wait for the guy who has sufficient permissions on that box to wake up...

if you tried to register for a public store account over the last few days, you got roadblocked by a small bug. Somehow, I managed to ftp up to the server the wrong version of the app, and responses from the db were not being properly read. That's been addressed - tip of the hat to Eric Engstrom for pointing the problem out to me.

Gordon Weakliem pointed me to this post from Patrick Logan. There's a lot of nice words about Smalltalk there. I've copied the whole thing from Patrick's post below:

Whither Smalltalk?

Instead I think the question should be, "Whether Smalltalk?" And the answer could very well be yes.

VisualWorks 7 is loaded with Internet capabilities: servlets, server pages, SOAP (Open talk). The VM is so much more mature than the CLR and JVM implementations.

The company appears to be solid, and has backed VisualWorks longer than anyone gave them credit for. Cincom rescued Smalltalk from history, after ParcPlace nearly bungled one of the truly great software systems of all time.

S# appears to be close to release for dotNET. Not only could this put some spark back into Smalltalk, but it could pave the way for widespread success of dynamic languages in general on the CLR, through the collaborration with Microsoft and the specific implementation techniques.

Not to mention that Dolphin and MT are still solid Smalltalk implementations for Win32 and on multiple platforms Squeak and GNU Smalltalk are too. The combination of VisualWorks and S# and these others make a cross-platform opportunity for Smalltalk. Systems built for S# or VW to a large degree should run on the other.

VW 7.1 is supposed to provide a more solid (non-beta) native Mac OS X implementation and VW is already solid on Linux and other Unix systems.

Smalltalk is a simple, classic notation for expressing computation. Code written 20 years ago still runs on modern implementations.

Why build important computational assets in notations that are overly complex (i.e. they make you say more than necessary) and are tied to implementation decisions that will soon be outdated (i.e. the "standard" notations are regularly updated with new features that compell adoption by marketing lust and lead to a chronological stratification similar to carbon dating)?

Java and C# books become outdated in a year. They no longer teach the notations the way developers want to use them. On the other hand, a developer can learn 90 percent of Smalltalk by picking up 1983's Smalltalk-80: The Language and Its Implementation!

Far better to build your important computational assets in a notation that is already long-lived, simple, flexible, and efficient, not to mention mostly unchanged for 20-30 years or more. There are a two of these notations that make sense to me: Lisp and Smalltalk.

I could go with either. Smalltalk is easier to explain to developers using other object-oriented languages.

Add Patrick's Weblog to your reading list - there's always stuff worth reading and thinking about there.

For those of you who missed the WebServices package, it's now been placed on the download site. We apologize for the confusion.

It turns out that the Mac VM, when installed under Windows or Linux, loses the resource fork information. So I've grabbed the VM files that we ship with vw-dev in a compressed form (.bin), and have them packaged up that way. This means that BottomFeeder Mac users will have to do a little work on their end - decode the .bin files, and also set the type and creator codes for the image to HPS7. If I had a Mac, this would be easier. Alas, not in the budget...

If you have been using the Aragon goodies, you may well see a few problems in 7.1 - I was trying to fix the installer, and I think I broke some - possibly all - of the Aragon parcels. Since none of have been changed by the author since the 7 release, just grab the old 7 versions. I apologize for any difficulties....

For those interested in looking at the feature set of BottomFeeder before downloading it, have a look at the Users Guide. The 2.9 dev builds have some significant changes:

• Keyboard shortcuts - see here for details
• Ability to import OCS, OPML, and RSS feeds from local files (based on the formats used by syndic8.com
• Ability to export the subscribed feeds to an OPML file. This will be extended to RSS and OCS before the release of 2.9
• A new, cleaner settings tool

BottomFeeder has supported marking feeds, folders of feeds, or all feeds read/unread for a long time now. The downloads are packaged as ready to run applications; the goal of this project is to make the application accessible to smalltalkers and non-smalltalkers alike. If you want to get into the code, the project has a SourceForge page - but the most recent codebase is in the Public Smalltalk Repository. Volunteers are welcome!

Thanks to one of our doc guys (Mark Roberts), the download page is cleaner and has a better set of explanations as to what you need to download. I also cleaned up the Web Services download link, which still had an invalid file name. It should all be ok now (fingers crossed)

This is priceless - Don Roberts at the C2 wiki:

He is a RedneckSmalltalker. He used to be "The Simplest Consultant That Could Possibly Work", but now he's at the University of Evansville as "The Simplest Professor That Could Possibly Teach." Where he's learned that teaching OOP using C++ is like teaching General Anatomy using only cancer patients.

ROFL

I am visiting a prospect this morning - I'm just printing out the handouts now. It's a lunch meeting in Herndon, VA (which is heck and away from here), so it will take a long time to get there and back. Hoepfully, I'll have interesting news to report when I get back late in the afternoon.

I got invited to speak at a local company today by a developer (Dave Astels) I ran across at the local XP group. I was there for about 90 minutes, talking about Smalltalk and what's new in Cincom Smalltalk. A lot of the folks there had used Objective-C, so they were more open to the concept than a lot of people might have been. I got a lot of questions, and a good level of back and forth. I expect a few more downloads of the non-commercial product at least, maybe even some skunkworks usage of the product. We'll see; it was fun to just do an evangelical call for a change.

We had some kind of server problem over the last hour or so, but it's been dealt with. Seems that the postgres db we use had a brain cramp, and had to be restarted. All is well now - the web apps are responsive again, the public store is responding normally - we apologize for the problem, and now return you to your regularly scheduled Smalltalking...

I found this post on Patrick Logan's blog interesting. Patrick quotes Paul Graham asserting that Java, like Cobol - is an evolutionary dead end in terms of language development:

I think that, like species, languages will form evolutionary trees, with dead-ends branching off all over. We can see this happening already. Cobol, for all its sometime popularity, does not seem to have any intellectual descendants. It is an evolutionary dead-end-- a Neanderthal language.

I predict a similar fate for Java. People sometimes send me mail saying, "How can you say that Java won't turn out to be a successful language? It's already a successful language." And I admit that it is, if you measure success by shelf space taken up by books on it (particularly individual books on it), or by the number of undergrads who believe they have to learn it to get a job. When I say Java won't turn out to be a successful language, I mean something more specific: that Java will turn out to be an evolutionary dead-end, like Cobol.

This is just a guess. I may be wrong. My point here is not to diss Java, but to raise the issue of evolutionary trees and get people asking, where on the tree is language X? The reason to ask this question isn't just so that our ghosts can say, in a hundred years, I told you so. It's because staying close to the main branches is a useful heuristic for finding languages that will be good to program in now.

At any given time, you're probably happiest on the main branches of an evolutionary tree. Even when there were still plenty of Neanderthals, it must have sucked to be one. The Cro-Magnons would have been constantly coming over and beating you up and stealing your food.

The reason I want to know what languages will be like in a hundred years is so that I know what branch of the tree to bet on now.

I think he's right about Java - it's the butt end of the C language family, and - IMHO - goes about as far as you can go in that direction. To me, the emergence of new dynamic languages like Python and Ruby - which owe more to Smalltalk than to Java - shows you where things are going at a grass roots level. Java may be where a lot of the work is, but it does not seem to be where the interesting action is.