Smalltalk Tidbits, Industry Rants

And with better information than I had! Over at Gordon Weakliem's log web log are some thoughts from another veteran of STIN. I hope he didn't have to pull the 12 hour days us Booz-Allen guys (my employer at the time) did. I was wrong about Hugh (famous for HuBol) as well - I guess we all just thought he was near retirement.

Oh, yeah, TravelBase! I used to work in the basement of the STIN building with Hugh Wilkie, the creator of "HUBOL". I've heard it described as a blend of FORTRAN and COBOL with bit shift and rotate operators thrown in. Never saw any actual HUBOL code, but it was still kicking around at the time.

TravelBase was really my first death march experience. Always nice to know someone else remembers it...

Only 6 1/2 hours to LoTR - The Two Towers

I have a conference call with Feiman and Driver (Gartner) on Thursday this week. If anyone has suggestions for me, I'd love to hear them

David Brin writes a very interesting critique of the entire Tolkien mythos. I was tempted to lift a quote from his third page, but no - read the whole thing yourself - it's well worth a few minutes reflection.

Web Services according to Jon Oltsik. And this time, Smalltalk is prepared - VW 7 shipped with full Web Services support. From the article:

This was a tough call for me. I truly believe Web services will improve application development and integration and has the potential to change the way companies use software. Even so, the technology still remains very immature. XML (Extensible Markup Language) is a good foundation for standards, but data definitions and business semantics remain a battleground. Web services also suffer from a lack of application-level security

Last July, I had kind of an epic brain cramp with one of the internal wikis - see the post I referenced for details. The cool thing is, the server has been running nicely since then - and I've had to add a new wiki to it - without any hiccups. That's 5+ months of uptime, a pretty good track record.

Why Smalltalk has the goods on the upcoming ESUG 2003 Conference. I would love to go this, but the last week of August is just a bad time for me - that's when my daughter starts school, and it's time to meet her new teacher. This looks to be packed with good stuff:

Continuing a strong tradition in organizing Smalltalk events for Smalltalk practitioners, this year promises to be very exiting. ESUG organizes a Smalltalk Joint Event comprised of Camp Smalltalk, Advanced Seminars and a Research track:

1. An official (and free) Camp Smalltalk, starting the week-end before and continuing the rest of the week.
2. The Advanced Seminars, where invited speakers and technical presenters show concrete applications and research using Smalltalk.
3. ESUG Research Track: an academic research track with top-of-the-line program committee. A separate call for paper was issued for this event, which is attached to this mail at the bottom.

The event will be in Bled, Slovenia between August 23-29. Follow the link to Why Smalltalk for details and contact information!

Application Analysts - How Reasonable? Update - Permanent Link here

In the IT industry, the various analysts have a large amount of influence. They have analysts who follow all aspects of the IT industry - server platforms, development tools, operating systems, the whole gamut. This raises a question though - with how influential they are, how accurate are they? It should be pointed out that I am hardly an unbiased observer - as the Product Manager for Cincom Smalltalk, I am obviously going to have a distinct point of view on what people should use for developing software. Still, over the last few years I've watched the analysts go negative on Smalltalk, and I decided to start looking at what they say and how they justify it.

The best place to start is with an analyst report put out at the end of September: Leading Languages for IT Portfolio Planning. This report looked at what development languages are in use, and what development languages are likely to be in use. Additionally, it makes recommendations on what languages should be used - and also on which should not be used. The report was written by the analysts at the analyst firm in question who follow development tools. Here's the table of language penetration they came up with in their survey:

Language	IT Shop Penetration
Java	70%
VB	70%
Cobol	45%
C++	45%
PowerBuilder	20%
Delphi	10%

These are the languages that they classify as mainstream. They consider Java, VB, and (to a lesser extent, C++) to be mainstream, with C# soon to enter that state. To quote them, they say the following about this table:

"Other languages and integrated development environments such as Pascal, Delphi, PowerBuilder, Smalltalk and Natural have already been pushed into a niche area, where we expect them to remain. We recommend that enterprises consider a migration to Microsoft or Java languages and technologies. Qualifying factor in their assessment would be the degree to which their vendors align their strategies with Microsoft or Java. Bottom Line: Enterprises must balance specific language requirements with the mainstream critical mass of skills. When possible, mainstream IT enterprises should first look to align application development initiatives with Microsoft.NET or Java-related technologies, tools and programming languages. They should consider niche tools only when the risk is far outweighed by the limited use of these specialized toolsets"

What they recommend here is that IT shops should strive to be in the mainstream, where it will be easier to find skilled developers and tools. That sounds reasonable, until you notice these comments made to the press by an analyst who follows aplication development tools: made in an interview:

"A September survey by the Gartner Group, a technology consulting company, revealed that approximately 40% of information technology (IT) projects do not produce their intended results, an indication of how badly some companies need the consulting services of a tech-savvy CPA. Gartner's prediction that global IT spending will reach $3.3 trillion by 2002 highlighted the broader implications of this finding"

This is in line with other reporting; the statistics on project failure tend to range between 30% and 40% depending on whom you ask. Where it gets interesting is when you see the same analyst quoted above saying this to the press:

To date, around 70 percent of initial Java implementations have been unsuccessful, according to new research from Gartner Group.

"An inordinately large number of large-scale Java projects have been failures," said Mark Driver, Gartner research director for Internet and ebusiness technologies.

However, Microsoft shouldn't draw any comfort from those figures as it seeks to promote its .NET technology strategy either. In all likelihood, the failure rate for early implementations of .NET systems will be similar, Driver said.

So let's recap here - analysts recommend that you use a mainstream language for your development - Java, VB, or a .NET language is what they mostly recommend. They particularly recommend that you migrate projects from Pascal, Delphi, Smalltalk (etc.) to Java or .NET post haste - and they do so even though their own research shows that the failure rates for that decision are inordinately high.

It's at this point that I have to question the value of their reporting. They have the failure rates in front of them - they are quoted reporting them. And yet, in an official publication, they recommend that any shop using a non-mainstream tool should migrate in order to mitigate risk. I have to ask, what risk? The statistics show a 40% failure rate overall for IT projects, but a 70% failure rate for Java (and likely .NET as well) projects. That means, logically, that starting a project in anything but Java or C# has a lower than 40% chance of failure, while starting in Java or C# yields a 70% failure rate. This isn't my Smalltalk advocacy speaking; this is their very own data speaking. In full view of all this data, these statements have been made to my customers:

"Smalltalk has become a niche technology that will be used by less than five percent of enterprises for another few years, mostly in the maintenance mode."

"There are one or two reputable vendors that still support Smalltalk (e.g. IBM) but they do not and will not introduce significant enhancements, recognizing the niche status of Smalltalk."

"Smalltalk applications should be relegated in the maintenance mode: do enhancements, do not do major new development!"

"As a strategic, long-term direction enterprises should choose a mainstream technology: either (or both) Java or/and Microsoft technology."

Now, these comments were made at a point when Cincom was about to release VisualWorks 7, IBM was about to release VAST 6, Gemstone was about to release Gemstone/S 6, and Object-Arts was about to release Dolphin 5 - all with major new features you can easily read about by visiting their sites.

So there you have it - the analysts recommend that you switch from technologies that have (at least) a 60% rate of success in project usage, to technologies that have a 30% success rate in project usage. Draw your own conclusions

I picked this link up from David Buck in the comments to this post. It's worth it's own extraction, IMHO.

Java's marketing issues aren't an insignificant problem, said Borland's Shelton. In a recent survey Borland conducted of "C-level executives," i.e., top corporate officers, the predominant response from those surveyed was "Java is over." Respondents perceived that Java had been pitched to them as a panacea for everything, and once it failed to deliver on that promise, they became disenchanted with the platform and receptive to the promises of Microsoft's .Net. "How have we, as an industry, led our C-level people to believe Java was going to solve the common cold and cancer, to the point where they're now so fed up with it? That's the problem we need to solve," Shelton said.

The amusing part to me is, here's a bunch of people who seem to recognize that Java was not a silver bullet. And yet, there they are ready to treat .NET as one. The industry continues to not get it.

Go read this now. I was rolling on the floor - I have the same problem ordering extra sauce!

There's some question as to whether IE usage is as high as reported - well over 90% according to this story. The question is, how many of the reported IE users are in Opera, Mozilla (et. al.) and simply reporting as IE to get around sites that only want to support IE (an astonishng number of sites are like that)?.

OneStat.com said that since it last published data in September 2002, IE 6 has picked up an additional 5.3 percent, moving from 52.3 percent to 57.6 percent share. IE 5.x has 35.2 percent of the market according to OneStat.com's metrics, while IE 4.0 holds 0.9 percent. The firm also showed Netscape 7 picking up 0.1 percent from 0.5 percent to 0.6 percent, with the Netscape offering overall holding 3 percent of the market -- making it second place in the browser wars. Meanwhile, the firm said its data shows Mozilla holds global usage share of 1.1 percent and Opera 6.0 holds onto 0.8 percent. It's in these details that OneStat.com's data begins to vary slightly with W3Schools. As of October 2002, W3Schools said Internet Explorer 6 holds 45 percent of the market, IE 5.x holds 46 percent of the market, and IE 4.x has 2 percent of the market. The methodologies of both firms are similar. OneStat.com said a global usage share percentage for a particular browser is generated by measuring the percentage of Internet users -- and which browsers they use -- that arrive at sites using one of OneStat.com's services. W3Schools does the same with data generated by TheCounter.com, a service run by internetnews.com parent Jupitermedia. However, Unix Systems Administrator Ben Rosenberg said such statistics should be taken with a grain of salt. Browsers use an identification string to identify themselves to Web sites, which is how counters and metrics firms can generate data about them. But a browser like Opera defaults to IE as its user string identification if the site is not configured to identify Opera. And both Konqueror and Mozilla users can change their user-agent string to IE to make sites accessible that are only geared toward IE. In fact, there is an add-on for Mozilla and Netscape that allows users to change the user string identification on the fly.

I doubt it makes a huge dent in the numbers - IE is certainly the market leader. But it does point out the limitations behind this type of research as the client side tools get more and more configurable.

The analysts recommend migration off of languages that don't appear in their top five (except for C# and VB.NET). Wait, call out the media - they just stated that PHP and Perl are doomed as well. And Python. And Ruby. Heck, C as well. Shhhhh. Better not tell any of the open source developers. What complete idiots.

I just got a copy of this Gartner report: Leading Languages for IT Portfolio Planning
Here's the money quote at the end:

Other languages and integrated development environments such as Pascal, Delphi, PowerBuilder, Smalltalk and Natural have already been pushed into a niche area, where we expect them to remain. We recommend that enterprises consider a migration to Microsoft or Java languages and technologies. Qualifying factor in their assessment would be the degree to which their vendors align their strategies with Microsoft or Java. Bottom Line: Enterprises must balance specific language requirements with the mainstream critical mass of skills. When possible, mainstream IT enterprises should first look to align application development initiatives with either Microsoft.NET or Java-related technologies, tools and programming languages. They should consider niche tools only when the risk is far outweighed by the limited use of these specialized toolsets.

So, in their discussions with clients, they recommend that you get off Smalltalk (and a raft of other technologies by implication). They do so even in the face of their own research. So they know that the recommendations that they give will lead to - in their words an inordinate chance of failure. That's expert analysis? That's worth paying for? Exactly what value is being provided, given that following this advice will lead to a large increase in a shop's risk? I, for one, am tired of this 'expert' advice.

The new Netscape - and apparently the current Mozilla as well - banish popups. Read the Register story.

Three More Days!

I posted yesterday on the wonderful logic behind the language/development analysis. Well comes today some more information: These are the language usage statistics that Gartner's analysts believe to be true:

Language Usage Statistics

Java	70%
VB	70%
Cobol	45%
C++	45%
PB	20%
Delphi	10%

This is supposed to represent language penetration. According to the report, if your language isn't there, you better stop using it. Looks like we have some news for all those Perl, Python, and C developers - time to migrate! But hey, if you are using Cobol or PowerBuilder, you are up to date and in the mainstream. Now recall, the analysts in question produced this report - which states that 70% of all Java projects fail. And in the comments to this old post, you get this lovely direct quote:

"Smalltalk has become a niche technology that will be used by less than five percent of enterprises for another few years, mostly in the maintenance mode." "There are one or two reputable vendors that still support Smalltalk (e.g. IBM) but they do not and will not introduce significant enhancements, recognizing the niche status of Smalltalk." "Smalltalk applications should be relegated in the maintenance mode: do enhancements, do not do major new development!" "As a strategic, long-term direction enterprises should choose a mainstream technology: either (or both) Java or/and Microsoft technology."

So I posted some fun with statistics yesterday. Let's revisit those numbers under a different set of assumptions. Recall that

1. Gartner's own numbers claim that 40% of all IT projects fail - and this is in line with other industry research - story here
2. Gartner's own numbers claim that 70% of all Java projects fail - story here
3. Gartner has been recommending (since 1997 at least) that IT shops migrate from Smalltalk to Java

In the post referenced above, I assumed 50% market share for Java. That's way, way too high - between existing projects, legacy work and what not, let's assume some different numbers: Assumption 1

Java has 10% market share in development

40% (failure rate) = 70% (Java failure rate) x 10% (Java share) + N x 90% (other dev languages share)

That boils down to N = 37% failure rate for all languages other than Java, assuming a 10% share

Assumption 2
Java has 20% market share in development 40% (failure rate) = 70% (Java failure rate) x 20% (Java share) + N x 80% (other dev languages share)
That boils down to N = 32.5% failure rate for all languages other than Java, assuming a 20% share Assumption 3
Java has a 30% market share in development 40% = 70% x 30% + N x 70% That boils down to N = 27% failure rate for all languages other than Java, assuming a 30% share

---

But you get the point - Gartner's analyst on this has been telling people to migrate from Smalltalk to Java for at least 5 years now, even though he has been in full possession of these facts. He has been telling people that Smalltalk vendors are not adding new features to their products - he said so earlier this year, in fact to some of my customers - even though he knew about the upcoming releases of VW 7, VAST 6, Gemstone 6, and Dolphin 5!. In short, the Gartner analyst who follows Smalltalk doesn't do minimal fact checking - and is in a position that enables him to do huge amounts of harm. Now, I don't begrudge an analyst expressing the opinion that Java skills are easier to find, or that Smalltalk is more of a niche tool - what I mind is the blatant lack of fact checking - i.e., the assertions that no new work is being done by vendors. I mind the fact that he tells people to migrate off, knowing full well that this increases the risk of project failure dramatically. In short, I'm sick and tired of experts deciding that Smalltalk is dead, and then making sure that it's true by pounding us in the head with a shovel.

has gotten some attention. This is the original post from Joel; it seems others are weighing in on the topic. For instance, I picked this up from Gordon WeakLiem, who got it from comments elsewhere:

Personally I think the heyday of really hard programming were the early 1960s, when the first big distributed electronic commerce systems like SABRE were being built. American airlines contributed the 1960 equivalent of a billion dollars to build SABRE over 5 years (I don?t know what other airlines spent). I believe these numbers and timeframe are similar to what Microsoft spent to develop the entire .NET platform. It?s hard to believe that if the airlines wanted to build a reservation system today they couldn't use mostly off-the-shelf software and get it done for 1/10 that cost (or less, I?m an optimist). Even if it feels like you have to run to stand still in this industry I think it's easier than ever to get things done.

Gordon then goes on with this:

Talking about the travel industry is always a good way to get me to pay attention ;-) If you want a good read on the construction of SABRE, chapter 2 of the book Hard Landing has the story. In fact, Sabre was the 2nd system American Airlines tried, another company (Burroughs, IIRC) tried and failed before IBM succeeded. I still work in the industry, and the amount of effort involved in making changes on the mainframe is absolutely incredible. One of my co-workers who's worked on the mainframe tells me that he used to maintain code where the last modification date was before he was born. Now that's legacy code.

I spent some of my own time in a Sabre offshoot - a wild attempt to rewrite the TravelBase system. It had started out, as all of the Sabre system did, as a mainframe system. There were stories galore there; it was written in HuBol - named after Hugh, who's office was in the basement. If you had a question, you could ask Hugh - if he felt like answering, he would. Being close to retirement, his concerns didn't always match ours.... This was an attempt to rewrite the system - out of the mainframe and the Cobol offshoot, and over to OS/2 and C. You haven't seen hell until you've seen a bunch of Cobol programmers trying to do their first even driven, GUI based system in C. I spent 6 of the longest months of my life on that death march, and all I have to show for it is the wrist wrest under my keyboard, which has the official launch date - June 2, 1992. Don't you believe that the system actually worked then....

I posted earlier on the Gartner reporting - they have statistics showing an overall industry failure rate if 40%, and of 70% if using Java. I posted this to comp.lang.smalltalk, and John Brant applied the following:

40% of all projects fail and 70% of all Java projects fail, so what's the
rate for non-Java projects :-)

40% * (# of projects) =
    (70% * (Java market share) * (# of projects)
        + (non-Java failure percent) * (1-Java market share) * (# of
projects))

If we assume that Java's market share is 50%, then we get:

40% * (# of projects) =
    (70% * 50% * (# of projects) + (non-Java failure percent) * 50% * (# of
projects))

This can be reduced to:
    40% = 70% * 50% + (non-Java failure percent) * 50%
==>
    40% = 35% + (non-Java failure percent) * 50%
==>
    5% / 50% = non-Java failure percent
==>
    10% = non-Java failure percent (assuming 50% market share)

So, if they actually believe their own statistics, they

1. Recommend that you use Java instead of (say, Smalltalk)
2. Based on their own stats, they know that following their recommendations has a 70% chance of failure
3. Based on their own stats, they know that not following their advice has only a 10% chance of failure

kind of sums it up, doesn't it? They don't check facts - they make claims that Smaltalk vendors aren't upgrading their products, when this is demonstrably not the case. They tout statistics that they can't possibly believe - if they did, they wouldn't make the recommendations they make. None of this is hard to check - heck, I did nothing but follow links on the net to gather this information. Seems to me that it's time someone pointed out that the emperor has no clothes

InfoWorld interviews the intrepid Scott McNealy. He goes on reasonably enough for awhile, and then gets here:

IDGNS: Do you think you waited too long to bring out a Linux on Intel server? Did you wait too long on an Intel-based system because SPARC is in your blood? SM: If you look at what Sun has done that no one else has done in the Microsoft era, we have developed a real live developer community. There is the .Net developer community and the Sun ONE (Open Net Environment), Java, XML developer community. After that, there really aren't many interesting developer communities. The rest are small and shrinking. We are doing everything we can to provide as much opportunity for the Sun ONE, Java, XML community. We think we can leverage the 32-bit price-performance points of the low end of the Intel space to make Sun ONE a better price-performance environment for some areas

Apparently, McNealy is unaware of all the Perl and Python work going on. Purposely unaware, maybe. Clueless, more likely.

If not, why not? The new STIC has been put back together through the efforts of Allan Davis and Jason Jones (who also sponsor the excellent Why Smalltalk site. Individual and corporate memberships may be purchased online - and individual members will get a nifty CD with all of the free and non-commercial Smalltalks on it. Join now!

One of my intrepid readers linked to my earlier Rational post, and, there are comments on this weblog.

I'd give rational more credit: a) They may have used eclipse because they recognized a need to have a better technical foundation for their product; b) they wanted to be more appealing to IBM; c) they recognized that they need to become more agile and saw eclipse as a step in that direction (it is); d) they relized that there was a market for a common tool set for dot net and j2ee deveopment in large organizations. e) a+b+c+d. I'm amazed that there was not more Slashdot interest in the Togethersoft connection. As half-troll pointed out, Borland just agreed to buy Togethersoft. Togethersoft Control Center offer support for multi-language, model driven development -- many Java developers prefer it to the WebGain and/or Rational tool set. Of course, Together Control Center addresses problems not normally encountered by the slashdoters such as deploying to multiple J2EE servers, object modeling, complex documentation that is generated from code, etc.

Read the whole post, he's got interesting things to say.

Projects don't fail for technical reasons. They fail for people/communication reasons What the analysts and pundits don't take into account is how technical choices aid or impede communication. One of the largest problems faced by IT shops is churn - there is always a new silver bullet technology that will solve all the problems. What this means is that most IT shops never gain enough expertise in any given set of tools to be truly productive; they are always moving on to new tools that will theoretically solve the problems better than the old ones. What developers need is tools that will help improve communication - both between themselves, and between their customers. If the technologies they choose to implement in are complex, then developers will consistently be speaking jargon - solving technical problems instead of business problems. If, on the other hand, developers are given tools that are not complex, they will spend more time solving (and discussing) business problems instead of technical issues. To use a trite example, simpler tools will allow developers to discuss requirements instead of compiler errors. Tools that mostly get out of the way and allow developers to express the intent of their customers are better; tools that layer on complexity and arcane rules stand in the way, and prevent or delay these expressions of intent. One thing to bear in mind is research from psychology. People can, on average, keep 7 (+/- 2) things in mind at once. Adding to the number of things that need to be kept in mind is not really possible - it's a human limitation. Choosing tools and/or processes that insist on throwing complexity directly in the face of a developer are as sure a recipe for failure as is possible - simply based on the reality of human capabilities. What does this mean? It means that choosing a strict process with many steps and lots of documentary steps is not going to work - the sheer complexity of the process will over burden the average developer. Likewise, choosing a set of development tools that require a steep learning curve will add problems. It will take longer for developers to internalize the rules well enough to be productive. It's a simple fact that projects will not normally be staffed with as many experienced people as you would like - so choosing technologies that make things simpler will get you started sooner. Where does this drive us? Processes - pick an agile methodology. A heavyweight, process driven methodology will wear developers down and prevent progress. Tools - pick an agile toolset. A set of complex tools will likewise wear developers down and prevent progress. What satisfies these? Visit the Agile Alliance for tips on process. For tools, take a look at Smalltalk. It's no secret that the Agile Alliance leaders are virtually all from the Smalltalk world; there's a reason for that. Smalltalk is simple and powerful. A beginner can learn it in minutes, and an expert can express a design clearly and tersely. One complaint you'll hear is that Smalltalk has a large learning curve. And Java or C# don't? Smalltalk has 5 reserved words and syntax that fits on a 3x5 card. C# and Java have 50+ reserved words and very complex syntactical rules. It simply is not the case that Smalltalk is harder to learn. If you want to beat project failure, the best way to do so is to use an agile methodology with Smalltalk.

Just follow this link to see what I mean. Scary, kind of...

Awhile back I had this to say about suggestions that Java, being mainstream, is safer than Smalltalk. Well, there's some fascinating numbers you can pull out on that. This Gartner information states that fully 40% of all IT projects fail:

A September survey by the Gartner Group, a technology consulting company, revealed that approximately 40% of information technology (IT) projects do not produce their intended results, an indication of how badly some companies need the consulting services of a tech-savvy CPA. Gartner's prediction that global IT spending will reach $3.3 trillion by 2002 highlighted the broader implications of this finding.

Now combine that with this Gartner study, in which they state that, to date, Java projects have a 70% failure rate - and that they expect the same failure rate for .NET. So, by using Java instead of what you already know, you increase your chances of failure dramatically. To see the weirdness here, merely note that they

1. Recommend that you use Java or .NET
2. Note that they report much higher failure rates for those decisions

and then decide whether they are worth listening to, since they apparently don't look at their own data when making recommendations. Heck, even political polling firms are smarter than that.

In response to my complaint here, (which I also sent in a slightly more judiciously worded email), I did get a decent response:

Me: Is the Java team completely blind to events outside the Java Universe, or is it worse than that? Sun: None of the above: we neglected to spend enough time supervising the hype generators closely enough. We know better, and I apologize for the indiscretion.

so I'll acknowledge the kind response. Now, let's see if they update the site....

This post from Joel has some really, really good points. Excerpt:

There was a time when if you read one book by Peter Norton, you literally knew everything there was to know about programming the IBM-PC. Over the last 20 years, programmers around the world have been hard at work building abstraction upon abstraction on top of the IBM-PC to make it easier to program and more powerful. But the law of leaky abstractions means that even as they built the abstractions that are supposed to make programming easier, the sheer amount of stuff you have to know to be a great programmer is expanding all the time.

I think this is part of why the Smalltalk community keeps being baffled about the C family of developers saying that Smalltalk is hard. Smalltalk is all about abstractions; a lot of the C style developers don't like looking that high up, and have to do a mental shift just to get there. Smalltalk is about simplicity, but it takes a mental leap to give up the familiar complexity.

If you forgot what email you registered with (here), there's a feature for having us email you your password. Unfortunately, I had never fully tested this feature, and it bailed with an error if you entered an email we hadn't seen. That will teach me to write unit tests. In any case, the server now responds to that situation appropriately - telling you sorry, try another email or register.

According to this story, Microsoft is also bidding on Rational. That's interesting. Well, one of the two will end up supporting the overblown, heavyweight cruft that is RUP, and the other will have another chance to look at the Agile side of things. Should be interesting either way, I think.

Apparently, someone thought it would be hilarious to launch a DOS attack on this server. Things seem to be ok now, but I'm working on some safeguards...

If you have downloaded a recent development build, you'll want to visit the site and grab the latest. There was an odd bug that arose when I added some code to check for a possibly running version - detecting one results in the auto-save feature being turned off. Unfortunately, I had the auto-save being turned off no matter how the check went.

This story left me rolling on the floor laughing. Either Gosling had no idea that the elisp in Emacs was part of something larger, or he's just completely clueless. Possibly both. Here's a quote from the page:

The Jackpot team is engaging in experiments using the open source NetBeansTM platform. NetBeans, the product of a small but widely-known company in Prague, the Czech Republic, is a modular, extensible IDE, written in the Java language, that has been in open source since June of 2000. The SunTM ONE Studio (formerly ForteTM for JavaTM) product line is based on NetBeans. By taking their experiments out of the lab and into the open-source developer community for real-world feedback, the team is opening the project to the wealth of talent in the open source community. "There have been a lot of good ideas and interesting approaches that haven't been reflected in the commercially available tools, particularly the IDE interface," says Michael Van de Vanter. "We're experimenting with plug-compatible tools on the NetBeans platform. By getting feedback from the open source community, we will further refine our prototypes."

Not available in commercial tools? Apparently, neither Gosling nor any of his team have ever seen a Smalltalk or Lisp implementation. Or if they did, they didn't understand it. Or I suppose they could just be making wild assertions that they are boldly going where no one has gone before, assuming no one will know the difference. That would make them lying weasels, of course, but hey - that's just my opinion.

Smalltalkers can now more easily connect thanks to the efforts of Janko Mivsek, Peter Hatch, and Rado Hodicak. This was posted to comp.lang.smalltalk this morning:

I'm glad to announce that a Smaltalk IRC Network is born. As you probably know, an IRC server run by Pete Hatch exist for a year or more already. To improve robustness and availability of IRC regardless of any internet related troubles, we decided to add two more servers and connect all of them together in IRC network. So, now you can connect to those three servers:

irc.parcplace.net (US, run by Pete Hatch, nickname pete) irc.4096.sk (Slovakia, run by Rado Hodicak, nickname rh) irc.eranova.si (Slovenia, run by Janko Mivsek, nickname Misolin)

After you connect to one of those servers, join a general channel #smalltalk . You can open your own channel like #squeak, or a channel for your project, for your group, etc etc .. And what is IRC chat good for?

1. staying in touch with Smalltalkers around the world
2. feel of community
3. fresh news, rumors, stories are heard on IRC an nowhere else ;)
4. real time "help desk" for your problems
5. good communication media for your Smalltalk group
6. remote XP like work
7. and many more.

If someone likes to join the net with his own server, he is welcomed. And specially squeakers are very welcomed too :) It is my desire to join all Smalltalkers to communicate together and being on the same IRC net, even on separate channels, is definitively a step towards that goal. So all of you are invited to join :) Janko

This really great - a lot of the BottomFeeder work was helped out via the IRC - it's been the primary means of communication between Dave Murphy and I.

Boris Popov has posted some interesting Logo possibilities. Personally, I like this:

Jason Ayers makes some good points on the c2 wiki on this topic. Check out his post yourself.

In September, Sam Shuster put out some information on the changes coming to the VW GUI with the upcoming 7.1 release of VisualWorks - the singleton UI process is gone, replaced by a more flexible system that will allow per window (or per application, or any other combination) processes. To get the lowdown, follow this link to the September Smalltalk Digest.

Readers of my blog will know that I'm skeptical (to say the least of the so called analysts - see here, and here, and here, and finally, here for my last round of rants on this subject. Still, many large companies seem to take what these people say as gospel, which means that this report on web services from the Meta Group will have a lot of influence:

According to META Group, more than 90% of large organizations will utilize host access products that externalize legacy applications via Web services by 2007 "We expect host access products to continue playing an important role for large organisations externalising legacy applications," said Mark Vanston, programme director with META Group's Enterprise Data Centre Strategies service. "Web-to-Host access solutions can reduce the cost of legacy integration, enabling organisations to leverage existing assets and capitalise on new IT opportunities"

Better go get the SOAP out...

I saw this usage report online, and it made sense. The approach those guys are taking seems much simpler than a SOAP basd approach:

At my company we are using a REST-based interface to allow the import and export of data to and from our trading system. We considered using SOAP, but felt that it would create an unnecessary extra layer of complexity without offering any benefits over a REST architecture. In fact SOAP's RPC approach seems to have many short comings versus the Representational State Transfer approach

With VW, this all ought to be pretty straightforward. You create servlets using Web Toolkit, and deal with the inbound and outbound XML using the XML support. A whole lot simpler than SOAP, and it's something that could be grown very incrementally.

The Call For Participation is out. Next year's show will be held in Toronto, Canada July 14-16. Hope to see you there!

And still trying to invent the future - take a look at the Croquet site. The summary page has useful information as well:

Croquet was built to answer a simple question. If we were to create a new operating system and user interface knowing what we know today, how far could we go. What kinds of decisions would we make that we might have been unable to even consider 20 or 30 years ago, when the current set of operating systems were first created. The landscape of possibilities has evolved tremendously in the last few years. Without a doubt, we can consider Moore's law and the Internet as the two primary forces that are colliding like tectonic plates to create an enormous mountain range of possibilities. Since every existing OS was created when the world around it was still quite flat, they were not designed to truly take advantage of the heights that we are now able to scale. What is perhaps most remarkable about this particular question is that in answering it, we find that we are revisiting much of the work that was done in the early sixties and seventies that ultimately led to the current successful architectures. One could say that that in reality, this question was asked long ago, and the strength of the answer has successfully carried us for a quarter century. On the other hand, the current environments are really just the thin veneer over what even long ago were seriously outmoded approaches to development and design. Most of the really good fundamental ideas that people had were left on the cutting room floor.

Go read the whole thing - it's well worth the time. They are using Squeak as the basis.

There were some issues with the arguments I was passing in the urls - specifically, they had spaces in them. This didn't cause any problems for newer revs of IE or Netscape, but older browsers had problems. I should have that licked; please send me email if you spot something.

I read this story with trepidation. Apparently, the 8-12 year old set wants a cell phone - and the Wired story says this:

If a child in this age group doesn't already own a cell phone -- 21 percent of them do, according to research by SpectraCom -- he or she is likely part of the great majority pestering mom and dad for one

Fortunately, my daughter still seems to like board games and Christmas decorations and Barbie more than this stuff. Whew!