Smalltalk Tidbits, Industry Rants

Who knew that a bear could be a beer snob?

Gordon Weakliem makes some excellent points about how and when to worry about scalability:

Scalability usually brings up discussions of Amazon or Yahoo!, big websites with high loads. But I've seen discussions of scalability completely kill a project that never will see that kind of volume. Yahoo! and Amazon weren't always the size they are now, they grew into what they are. But people still go around wasting time on ill-advised caching schemes and what have you, when I think it's more important to get something working, get some good measurements, and let them guide you

You won't know what problems you have until you actually have them (in most cases). In my experience, developers are notoriously bad at guessing what the problems are when confronting a slow system; they are even worse when trying to predict what they might be if the load actually gets to heavy. Bottom line - make it work. If it's fast enough, don't worry. If it's not - profile. I'm always stunned at conversations that go something like this:

Them Our system is slow. We need to (insert complex solution to some presumed problem here)
Me Have you profiled the system? Are you sure that the problem is in (insert supposed problem here)
Them Huh?

Jonathan Schwartz points out that RedHat is trying to "lock in" their customers - ISVs in particular. This isn't a terribly big surprise; The Unix vendors have been doing this long before MS got into the game. He then tries to make a point that runs into one of the classic marketing brick walls - Perception Vs. Reality. Sun would like to push Solaris as more open (in the open standards sense) than Linux:

Folks in the IT community need to be more aware, in my view, of the lock-in to which they're exposing themselves if they don't take a more active role in understanding the difference between and open source and open standards. All the more reason more and more are seeing Solaris as a migration platform as they move off Fedora.

Good luck with that effort. Linux' "street cred" as open is too widespread at this point for Solaris to make any significant dent in it. Sun trying to make the "more open" point is a truly uphill battle against entrenched perceptions. There's also a cost issue to deal with - Sparc boxes (yes, there's Solaris on x86; no one cares) are far, far more expensive than commodity x86 boxes. Here's a tip - Sun isn't competing with RedHat. Sun is competing with Dell - badly...

Blaine Buxton points to an article advocating Python or Ruby rather than J2EE. Now, here's the interesting thing about that (to me). I attended an XP show in Brazil awhile back, and one of the things that I got hit with was "sure, Smalltalk is more productive... but we have all these libraries in Java!" Well, it seems that you might well have the wrong libraries in Java. To wit:

Well, people say that the J2EE solutions are more scalable. A Ruby or Python web app may take less time to get going, but if you're going to run an Amazon or eBay you need something that scales up.

Now, I have no idea if this is true, it's just what they say...

Note that the evidence for "J2EE is more scalable" is hearsay. Is it more scalable? Well, I don't know. What I do know is that Smalltalk scales just fine - we have plenty of customers using it on large scale intranet and internet projects - and it scales just fine. The key point to remember here is that you'll make much faster progress with Smalltalk than you will with J2EE. You'll also find it easier to modify and maintain the application down the road - dynamic typing makes for more malleable code. Java applications tend to get more brittle and hard to change as they get bigger; this is much less the case with Smalltalk - mostly due to the dynamic typing.

What Java has going for it - and it's an important and useful thing - is large vendor support (IBM) and marketing. What Smalltalk has going for it is stability (mature libraries, well tested over decades) and ease of use. If time to market is important to you, you owe it to yourself to at least have a look at Smalltalk. Evaluate it yourself and make your own decision - by all means, don't just take my word for it.

Allen Holub has an interesting article in the latest SDNews. He's charting the decline of JavaOne as a conference. Now, this doesn't actually have anything to do with Java itself - it has to do with the conference and how it's run. Allen says that the early shows were educational affairs - he ralates an experience in an AWT class at an early JavaOne:

I vividly remember a session on the Abstract Window Toolkit (AWT), for example, where the speaker analyzed the library in terms of the implemented design patterns and showed how the APIs fit into those patterns. The APIs were put into a context that allowed me to understand the whole library, including those APIs that were not discussed during this session. The talk, which didn 19t follow a rigid format, was packed with information. I came out of this session thoroughly understanding AWT and its architecture, and could immediately apply what I 19d learned.

He contrasts that with this year's show, where he found too much (Sun) marketing and too little technical information. So why do I care? Well, I'm one of the people involved in getting Smalltalk Solutions off the ground each year (although not nearly as much as Alan Knight, who is the technical chair, or Joy Murray, who does the most of the work around site selection). One of the things I hope we do a good job of is the talks at the show - do attendees find them useful and interesting? Do you learn new things?

Certainly there's a place for marketing and advocacy at this type of show, but interesting and useful content is what makes the rest of it possible. So how are we doing that way? Do we do a better job than shows like JavaONE? A similar job? A worse job? Let me know.

Dare Obasanjo asks some good questions about Google - are they prepped to be a flash in the pan, or a long term business? Here's the primary question:

http://www.google.com is non-sticky: Nothing on the main Google site encourages the user to hang around the site or even return to the website besides the quality of the search results. According to the company's founders this is by design. The problem with this reasoning is that if and when its competitors such as MSN Search and Yahoo! Search get good enough there isn't anything keeping people tied to the site. It seems unfathomable now but there was a time that it seemed unfathomable that anyone would use anything besides AltaVista or Excite to search the Web. It's happened before and it can happen again. Google seems ill-prepared for this occurence.

He raises a lot of other good points as well - the one above just strikes me as particularly cogent. I do recall thinking of AltaVista as the best search site years ago - and I really only go to Google for search. I rarely look at Google news, and - even with the hype - I'm still not impressed by GMail (mind you, I'm a skeptic of server based email in general, so this is not a Google specific issue for me). In any case, Dare raises some good questions. Food for thought... Update: Google cuts their IPO price

Charles Miller points out why dynamic languages make Java harder. Once you start using Smalltalk, or Python, or Ruby, it's hard to overlook all the flaws...

Peter Lount has spiffed up Smalltalk.org. Check it out.

I'm off to Disney for a few days - I'll be keeping up with news and mail in the mornings and evenings, but I expect blogging will be light. We are staying at the Beach Club with some friends - it's a marvelous resort with a great set of pools. I hope to come back tanned and rested :)

Now, the wives get payback for all those hours of NFL...

CNet reports that an unpatched (i.e., just shipped from the vendor) Windows PC will last 20 minutes (on average) before malware compromises it. It can be a lot less than that; when I first got a WiFi card, I wasn't using a software firewall on my PC (I have a hardware firewall in the office). The notebook was attacked within 5 minutes when I used public WiFi.

Blaine makes a nice post on why you need room for "squishiness" in software design. Go read it.

Jonathan Schwartz continues his free fall into Wonderland, where up is down, left is right, and everyone wants Solaris. First he excoriates HP for embracing Linux (he does the same to IBM) - and then he makes this statement:

As you well know, our operating system, Solaris, continues to set land speed records on SPARC, while branching into new territory on x86 - and it's the least expensive in the industry. I continue to hear customers disappointed in the realization that ISV's don't qualify to "linux" (or specifically, Fedora) - so they have to pay big bucks for RHEL if they want commercial support. And while HP stumbles into that reality, our commitment to Solaris (did I mention we're open sourcing it - check out http://www.blastwave.org) highlights the demise of HP/UX. HP/UX won't even run on HP's own industry standard servers. As an ISV told me last week, "I come to sun, you tell me to write to Java, then write to Solaris. Clear as a bell." If you're an HP customer or ISV, have some fun, ask your HP rep the same question - "what should I write to?"

Sheesh, where do I even begin with this stuff? There's a small island out in the south pacific near Pitcairn. That's where all the people who care about Solaris on x86 live. Second, there's the whole Java problem for Sun. Here's a hint - Java (like VisualWorks) is cross platform. That means that people writing in Java don't need to care about the platform they write for. So... are they going to invest in commodity intel boxes running Linux or Windows, or are they going to invest in expensive Sun hardware? The sales figures from Sun are pretty clear about this, unless you're Whistle Boy.

Here's the thing - promoting a cross platform development language/platform has this tendency to commoditize hardware. Especially if the language/platform gets to be popular. The more Java suceeds, the less relevant Sparc/Solaris is. This has been obvious to everyone for years, with the seeming exceptions of Schwartz and McNealy. The amazing thing is that Schwartz stands there and claims that IBM and HP are in "deep trouble" - meanwhile, both of them are profitable. "Pay no attention to the falling sales behind the curtain", he says.

Yes, Sun needs a rah rah guy. What they don't need is an utterly delusional rah rah guy. Right now, Sun looks like nothing so much as a company where no one can tell McNealy and Schwartz that Java is providing wood for the termites that other companies are unleashing. The other big players are busy making money in the Java ecosystem that Sun has created - and killing Sun's business while doing so. I don't know of any new, large commitments to Sun hardware - but I know of plenty of migrations from Sun to Linux. Most of these have been enabled by the cross platform nature of Java.

Now, before someone tries to tell me that this is all bile because Java "destroyed" Smalltalk - the Smalltalk business at Cincom is growing and profitable. Heck, we are in a better place with the Smalltalk business than we've been since the downhill slide started after the PPS/Digitalk merger. Personally, I used to really like Sun's hardware and OS - both as a developer and as a sys admin (way back in the late 80's for the admin role). Right now, Sun is a train wreck in motion, aided and abetted by the utter cluelessness of people like Schwartz. Sun might have a shot at stability if he and McNealy were replaced; I see nothing but decline so long as they stick around.

Wicked Questions asks whether Smalltalk (or other languages) use type safe enums or real objects. Well - In Smalltalk, all we have are objects. You would model the behavior you want (as guessed below)

The problem is this: in Java, methods can either return some value or return no value (void). There might be cases where one might have to do some processing after decoding (an enum) and return some value. I suppose the handler interface can be defined to return Object (oops! casting sneaks in!), but then there are also situations where there will be nothing to return (returning null is ugly). I suppose two kinds of handlers are needed one where each method returns Object and another handler where each method returns void.

Does projects using Smalltalk or Eiffel have these 'type safe enums' at all ?  Or is that when using those languages these entities are modelled as objects with behavior (this is my current uninformed guess)?

Don't drink the liquid nitrogen. Really :)

Mark Pilgrim classifies software developers. It's too funny to summarize - just go read it :)

KSC is still hiring Smalltalkers

Due to the continuing surge in demand for Smalltalkers across the US, KSC has a number of new opportunities available for both permanent and contract positions. We welcome Smalltalkers with all levels of experience with VisualWorks Smalltalk, IBM's VisualAge Smalltalk, Visual Smalltalk Enterprise as well as all other Smalltalk environments.

Kind of a nice response to this question

Blaine Buxton gets angry about Darren's comment (scroll down) to this post and makes some good points:

If you always assume the users of your code will be idiots then the code will be unusable by smart folks as well as idiots. I always think that the people that will be using my system will be smarter than me. I do not want to shackle them in anyway because I want them to be to adapt to circumstances that I never could have imagined when I wrote the code. I firmly believe this because Swing was built assuming the users would be idiots and it's the worst case of design I have ever seen. It just reeks bad design and part of that is because of developers assumed the developers were idiots. Never think of your fellow comrades like that, it's rude and not true. If you think they are idiots, it means they are not as educated as you. Well, your job is to educate them, not protect them.

That's probably the single most irritating aspect of the Java/C# culture coming from Sun and MS (I've heard it voiced in conversations with Joshua Bloch and Anders Hejlberg) - "the end developers are morons, and we have to protect them from themselves".

In response to Darren's comment on this post, I responded with a comment. However, the comment went long enough that I figured I should post it more prominently - here it is:

You say: "edit time checking is superior to compile time checking is superior to runtime checking"

Well, yeah. And in Smalltalk, edit time = compile time. And using SUnit, edit time = compile time = test time. So if there's a problem, we catch it when we write the code (assuming we are doing TDD). This is sooner than you'll catch it in any of the popular static languages. So if this is your premise, you want to do TDD in Smalltalk.

You then say: "I don't know about you, but I am a senior architect / developer in the real world. Many of the programmers I work with wouldn't be able to spell encapsulation, let alone explain what it means. If, when I build the core libraries people use, I give someone a way of doing something stupid... rest assured - they will."

Ok, I'll be blunt - you are working with the wrong people. Static typing won't save you if your staff doesn't understand basic development. They'll be making algorithmic errors abd worse. If this is the problem you have, then you are chasing the wrong problem.

As to your train example - Ariane V. Type checking doesn't solve your problem. If you have bad/non careful developers who use the wrong module - even though said module males the compiler happy - you still end up with an exploding rocket. Ditto your train. You have to run tests. Static typing verifies nothing of real interest for you in this case; testing will. If you rely on static checks, you'll end up very, very sad

Then you say: "You are not daily dealing with people who's entire programming experience is that 4 day introduction to VB course.. But that's the sort of person who ends up using my libraries, and I need every bit of safety I can get my hands on."

If you are happy with false safety, sure. What you've actually done is tied the hands of the end developers in the name of protecting them - and the worst part is, you haven't actually accomplished anything. If your developers make algorithmic errors (the most common and worst kind) - compiler checks won't help you.

Ultimately, you are worried about the most irrelevant problems, and pretending that it solves the big issues.

NewsForge reports that MS is interviewing Linux developers. What I'd like to know is, are they just looking for "line" Unix/Linux developers, or are they looking at the inner circle? Here's an interesting exchange:

Which brings us back to the original question: Why is Microsoft interviewing Linux developers? Are they needed to work on the Virtual PC product, or on Longhorn? I called Microsoft public relations -- actually, it was Waggoner Edstrom's Rapid Response Team, which handles MS public relations -- and put the developer's question to them.

The first response I received said "After speaking with my colleagues, I can confirm that Microsoft has no plans to port to Linux at this time." Since that was an answer to a question I hadn't asked, I asked again. The second response was unequivocal: "Unfortunately, we do not have further comment on your question."

Well, we didn't even get much rain from Charley. The storm slid east of here - a frontal system moving through kept it out on the shoreline. Today is sunny and pretty nice. We got lucky on this go around. I'm heading down to Disney next week for a few days, and I'm hoping that Earl doesn't take the same path that Charley did. We'll have to see what happens.

Looks like the XP SP 2 firewall isn't all it should be. It blocks inbound traffic, but does not block outbound. The firewall I use does both; the MS solution allows for malware that manages to get installed to connect out - not good. It also has an API that allows applications to turn it off. Not terribly impressive. Scoble says it's better than nothing - I'm not sure that I agree. Non-technical users (most of the audience) are going to be left with a false sense of security, and won't get something better. You could easily get malware via lax settings in IE (or an older, unpatched Outlook) - and have that malware disable the Firewall using the API. In some ways, this is worse than nothing.

Nu Cardboard notes that the Olympics website (Athens) has some rather bizarre linking rules. They actually expect people to send a written letter (as in, paper) before linking. Which century do these people think it is?

I've written a number of posts that demonstrate various aspects of VisualWorks. I've just reclassified them all into the examples category on my blog; you can see them all using this url

Awhile back, I made a post about HTTP Queries from VisualWorks. Let's have a look at how an HTTP Post would look. You are going to end up working with the same HttpClient (or HttpsClient) class as before - and you are going to need to craft a custom Request object. Let's presume that the post is like a post from a form - here's what we need to do:

	|  client request |
	client := HttpClient new.
	request := HttpRequest post: 'http://www.mysite.com/someForm'.
	request contentType: 'application/x-www-form-urlencoded'..
	request contents: 'arg1=true&arg2=Fred&arg3=Barney'.
	response := [client executeRequest: request]
		on: self httpExceptions
		do: [:ex | nil].
	response ifNil: [response := client originalResponse].
	^response

Now, you wouldn't want to hard code the encoding, or the data (or the URL). In the Http-Access and NetResources packages (in the Public Store), there's a simple API for doing posts with that data passed in. Encoding the data is a fairly simple thing; you need something like this:

| arg1 arg2 arg3 stream |
stream := WriteStream on: String new.
stream nextPutAll: 'arg1=', (URI encode: arg1).
stream nextPutAll: '&arg2=', (URI encode: arg2).
stream nextPutAll: '&arg3=', (URI encode: arg3).
^stream contents.

That will give you back a string suitable for passing as an url encoded string in a POST form. That's pretty much it though. By mucking around with the encoding and the data being passed, you can create any kind of POST request pretty easily. Next time I'll take a look at the way such a post might be handled by a VisualWorks Web Toolkit servlet.

It's already soggy here (we have had astonishing amounts of rain for summertime), and we are about to get more - the remnants of Charley will drop a load on us. Better than what Florida received, for sure. I'm heading to Orlando next week, so I guess I'll see some of the storm damage first hand. Looks like a lot of people lost everything on the west coast of Florida.

There's been a bunch of comments on this post and this post - both on Dynamic typing vs. Static typing. The static language argument that seems to come up over and over again can be summarized thusly: Better Safe than Sorry. For instance, with the vehicle/road analogy raised by Peter Lount, I saw this comment:

Dunno what sort of world you're programming in... but lets see... four extra days of programming time versus losing $1,000,000 on that bank transfer... or not notifying the customer of their flight change... or landing that plane 4 metres BELOW ground level hmmmmm... in programming, safer == better. ALWAYS. Because the impact of extra programming time is known and controllable. The impact of an unexpected bug is NOT.

That's the argument I hear over and over again. But "safety" is relative. We ask for certain levels of safety, but we trade it off vs. pragmatism. For instance - we could all be much safer if we mandated that everyone drive in minvans at 25 mph. Do we mandate that? No, because we have to look at the other issues (Do I really need a vehicle that large? What if I want to get somewhere in a reasonable interval of time?). Sure, we have some roads that forbid trucks and bicycles - but most don't. We make tradeoffs so that we can have a reasonable level of safety vs. a reasonable level of productivity

You can apply this to almost any field you want - take medicine. You can increase the level of safety by having longer testing periods (simulations, animal testing, etc) - but in the meantime, the people who might be saved by the drug aren't being helped. Do we allow safety to trump pragmatism here? No, we attempt a reasonable tradeoff.

There's another issue here as well - there's no actual evidence that statically typed systems prevent catastrophic failures. The Ariane V, for instance - that was a failure caused by lack of understanding and improper module usage - static typing did not prevent the explosion. Algorithmic errors - the sorts that are most likely to cause huge failures - are not going to be caught by a compiler. Subtracting the wrong numbers (and having the compiler chirp happily because they are both ints) won't help me if they are the wrong variables to subtract. You need testing, not irrelevant (and falsely comforting) static typing.

Stating that we must be safe (i.e., use static typing) is an over-extension of the "precautionary principle". It advocates doing nothing that could possibly bring harm. If that's your argument, you need to stop coding now - because static typing isn't going to help you. What you want is formal proof that your application is "safe". Good luck getting there...

We got a fairly nasty set of thunderstorms yesterday, but we caught a break with the remnants of Bonnie - it slid east of where we live. Last night's forecast was calling for over an inch of rain to fall, with the possibility of a lot of local flooding. None of that happened - we just have lots of clouds. Now, things aren't over yet - western Florida is going to get hammered by Charley, and that storm will track up the coast - whether we get a lot of rain (and wind) is still up in the air. Of course, we won't get anything like what they are about to get in Florida - the authorities have called for an evacuation of up to 2 million people from the western side of Florida, from Tampa on down to Fort Myers. It could get very, very ugly down there. I suppose eventually, a hurricane will run straight of the Chesapeake and wreak havoc on this area - hopefully no time soon.

I always liked Julia Child because she didn't seem to get caught up in the various "food fads" that come and go. Rest in Peace. The Baltimore Sun story is here

From CLS:

"Static typing prevents certain kinds of failures. Unfortunately, it also prevents certain kinds of successes." - Ned Batchelder, quoted by Peter Lount

I had one of these surprise successes today. Situation was: how to report progress to the interactive user of a very long running calculation in a remote image. I began by passing the remote calculator a value model:

		remoteObject longCalculation: 0 asValue.

The idea was the calculator's inner loop would periodically send #value: to the model with an update of % done:

RemoteObject>>longCalculation: aModel
   1 to: 10 do: [:each | aModel value: (each / 10).
	(Delay forSeconds: 1) wait. ]

So far so good. But the advantage of extreme late binding came when I changed my mind and decided to use a Block of arbitrary code to report status. Now it happens that Block also responds to #value: and so the client image can report status in a totally different way:

    remoteObject longCalculation: [:percent | Transcript show: percent 
printString;tab;flush].

Remote server doesn't know wether client is passing in a numeric ValueHolder or a Block -- it takes anything that responds to #value: . It stunned me and my teamates this worked! We're passing a block context in the client image across the ORB to the server, which evaluates it inside the client. This little block is far simpler than the distributed event-change notification mechanism!

Question: Remote blocks work Distributed Smalltalk. Will they still work in OpenTalk?

(ed: yes)

Anyway it was a nice late surprise. At compile time I thought I wanted a numeric ValueHolder, and later, during debug, I decided to use a block. (while in the debugger, 'natch). Extreme late binding is so liberating Alan Kay makes it part of his definition of OOP

"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them"

This is the same sort of thing as the various posts I've put up about dynamically updating a server (or for that matter, dynamically updating a client like BottomFeeder). It's the sort of success you'll never have with a static/late bound language. Heck, you likely wouldn't even try it - you would have to kill the remote server, update the type signatures, regenerate the IDL, and update the client. That's going to take time, and the most likely reaction will end up being "why bother". In Smalltalk, you can just go ahead and try it out. The lower cost of experimentation leads to a lower cost of actual implementation - and a much higher level of willingness towards trying things out.

John Dvorak has some unkind words for MS on Word. I often see Dvorak as a blustering talking head, but he's got something here. I've never been happy with Word's notions of "plain text" format or it's atrocious HTML generation either. I know I've gotten answers on why bullets and numbering are so screwed up, but it doesn't matter - they never get fixed. When I end up using the VisualWorks text editor instead of Word for document creation, you know I've gotten desperate....

This post has raised quite a conversation. As it happens, there's a similar thread over on cls. Peter Lount has also posted a response. I responded to the classic "what about bad message sends" argument like this:

I see this argument all the time. In practice, I rarely see Smalltalkers having issues that look tlike that. The most common reason for MNU (MessageNotUnderstood) in Smalltalk is sending a message to nil - which happens due to a failure to initialize.

So you can raise this argument all you want, and most Smalltalkers (and I suspect other dynamic language users) will yawn - because it's simply not a problem we see.

Personally, in coding I've done over the last decade in Smalltalk, I've had a problem that static typing would have solved for me... twice. That's right, twice. I recall the number because it's been so uncommon. Static typing does impose costs - in flexibility, in time to market, and in maintenance down the road. To my mind, given the frequency of actual type errors that static typing would have helped me with - that cost is not worth it.

I'll go further than that though - here's one of the more hysterical comments in my post thread:

Dunno what sort of world you're programming in... but lets see... four extra days of programming time versus losing $1,000,000 on that bank transfer... or not notifying the customer of their flight change... or landing that plane 4 metres BELOW ground level hmmmmm... in programming, safer == better. ALWAYS. Because the impact of extra programming time is known and controllable. The impact of an unexpected bug is NOT.

Sure, I can't protect against ALL problems. But I CAN protect against a car driving down the footpath. Any protection is better than no protection at all.

This reminds me of nothing so much as political arguments that rely on "what about the children" for their backing store. It means that you don't actually have an argument, so you've decided to make an emotional case instead. I give such arguments all the time they deserve....

Fnordistan notes how much Java owes to Smalltalk:

When I first started learning Java, I had no idea no idea just how much Java owed to Smalltalk! I still didn't really appreciate it until recently, when I started digging into Smalltalk more seriously. From the notion of everything descending from Object to garbage collection to the inheritance model to polymorphism, almost everything Java does is basically aping Smalltalk. Often not very well. I am using Java's Collections a lot, and even though Collections are a relatively new transplant from Smalltalk, compare this:

for (Iterator iter = myList.iterator(); iter.hasNext(); ) {
myThing thing = (myThing) iter.next();
thing.doSomething();
}

with this

myList do: [:thing | thing doSomething ]

Read the whole thiing

Peter Lount has an article up on Dynamic Typing - go have a look. I rather like this:

In a program the objects traveling through the program statements are like the train cars and the program variable statements are like the rails. If the variables are locked down with a specific type they become separate grooves that only allow that particular kind of object to travel along those pathways. Some think that this is a good thing which they call "type safety" because it's a simple way of organizing the information flows, much like a relational database is a simple view of the data that can be pigeon holed into restricted and limited "types".

Imagine traveling a road network that had different width tracks or groves in the road for each brand of car, truck, motor cycle, bicycle and pedestrian. It would be completely unworkable. That's exactly what a program with typed variables is like, especially the larger they get.

Ted Leung points out that many of the ideas that went into the Sun HotSpot technology came out of Self, which is Smalltalk based. It's actually more amusing than that. The Animorphic Smalltalk VM was offered around for sale in the mid 90's - it was a highly optimizing Smalltalk VM. Sun bought the technology, but somehow managed to forget that they already had the technology (Self). It then took Sun close to three years to apply the technology to Java... because the sort of optimizations that work well for a dynamic language are not necessarily the same ones that work well for a static language....

Petrilli shows us just how easy distributed development can be. Of course, the curly brace crowd thinks it has to be hard, poor devils...

Heck, if you have the right tools, you don't need generics. I recall the first time I realized what #doesNotUnderstand: really allowed for in Smalltalk - I was able to build simple proxies without needing a set of extra language features. Unlike, say, C# and Java. Have a look at Julia Lerman's post - it's simpler to do this in the .NET world than it used to be, but still not as simple as it can be. The heart of the message forwarding scheme in the VW CORBA implementation is really, really simple....