Old Dudes Who Know Smalltalk

Joseph Moore has some nice things to say about Old Dudes Who Know Smalltalk:

Ah, there it is -- These are Old Dudes! I love Old Dudes! And I really love Old Dudes Who Know Smalltalk! I was nurtured, sculpted, and brainwashed by Old Dudes Who Know Smalltalk from my very first day as a professional programmer, and they universally "get it". Young whipper-snappers out there, take note: if you ever here some Old Dude say the words "in Smalltalk you could blah blah blah" or "In VisualWorks you could yada yada", spend as much time with this person as possible. You will learn more from them about software development than the Young Dude who only wears black and thinks that the bash shell is "too bloated".

And what does "get it" mean? Maybe I'll get into that some other time (it will be ugly, as this is one are where I am very opinionated), but the important thing is this: these guys don't come from the school of web scripting hackery in vi, they come from the land of building real enterprise applications, where real tool support is appreciated. And at this point in the Ruby IDE game, I'd place my bets on them to produce the first a truly usefully development tool.

Joseph mentions that he is an "Eclipse zealot." Eclipse is also a product of "Old Dudes Who Know Smalltalk."

---

• Chronos blog home page
• Chronos Date/Time Library web site

Time for Smalltalk to focus on its future, not its past

Bob Nemec, the new director of STIC, recently made a point in a blog post that echoes a point I made recently on the Squeak-Dev mailing list.

Excerpt from what I said (e-mail sent Wed, 17 May 2006 -0700):

"Those of us `old timers` who went through the learning curve on Smalltalk years ago no longer clearly remember what it was like, nor what the conceptual stumbling blocks were. We have now fully internalized the `Smalltalk way,` and don't really grok why newcomers don't instantly realize why its so superior.

I think our attitude is wrong, even if we're `right.` We absolutely should enable more `traditional` approaches for doing Smalltalk programming. If the Mountain won't come to Mohammed, then Mohammed must go to the Mountain."

Excerpt from what Bob said:

"We had a rare sighting at last night’s meeting: a couple of Smalltalk newbies. One of them, Chris, was very willing to talk about his frustrations in getting into Smalltalk, which he’s been looking at for only a few weeks. He’s a webmaster with an interest in Seaside. In his opinion, the Smalltalk community presents a significant barrier to entry by coming across as arrogant and aloof. It was difficult defending some of his criticisms; in many ways, he was right. I had thought those days were behind us.

He made some very good points. Basically, we don’t provide the baby steps needed to learn our environment. There are virtually no easy to find introduction materials on the web for people poking around with Smalltalk for the first time. The fact that Smalltalk was able to do things 15 years ago that some languages struggle with today is irrelevant to him. He wants to learn, not be preached to."

I would add that educational materials accessible to beginners is only one approach. Another is to enable newbies to use Smalltalk in ways that much more resemble the tools and environments they already understand. Just because we know that such "traditional" tooling is actually inferior is no reason not to provide it--especially when that's one of the main stumbling blocks to early/easy acceptance by newcomers.

Who knows, perhaps we will discover that the "traditional" tooling has certain advantages, and/or that there is a synergistic effect when the traditional Smalltalk approach is combined with the traditional Unix/Windows approach.

But the bottom line is simply that Smalltalk needs to get rid of its "holier than thou" attitude, stop mumbling about all the great forward-looking achievements of its past, and start dealing with the issues of today and planning for its future.

---

• Chronos blog home page
• Chronos Date/Time Library web site

Static typing is so last century

In the article Schizoid Classes published on the ACM Queue, Rodney Bates (of Wichita State University) does a good job of explaining what's wrong with the class models of the curly-braced mainstream langauges.

However, in his last paragraph, he says:

"Smalltalk pays a high price elsewhere for taking object orientation to the extreme, notably in complete loss of static typing and serious runtime efficiency penalties. Special, one-instance forms of classes are, for many programming problems, not as good a conceptual match as modules. But at least it provides a single, consistent, and syntactically explicit call mechanism."

He's right to say that "special, one-instance forms of classes are, for many programming problems, not as good a conceptual match as modules." But he's demonstrably wrong to say that "Smalltalk pays a high price elsewhere for taking object orientation to the extreme, notably in complete loss of static typing and serious runtime efficiency penalties."

Firstly, it is only sometimes true that Smalltalk pays a measurable performance penalty due to the lack of primitive types. In fact, it is very often the case that Smalltalk programs benchmark as faster than equivalent programs written in C++, C# or Java--for any of a variety of reasons I won't go into here.

Secondly, Smalltalk pays no net penalty for its lack of static typing--commonly-believed myths to the contrary notwithstanding. In fact, it receives the net benefit of making developers more productive and making code more generic and reusable.

Static typing is so last century. Interest in dynamic languages is growing. A Kuhnian revolution may be brewing. I sense that it won't be long now before the general community of programmers wakes up to reality, and stops believing the myths of the past.

---

• Chronos blog home page
• Chronos Date/Time Library web site

Taking Exception To Smalltalk Exceptions

About 3 weeks ago, Cincom's James Robertson posted a blog entry that showcased Smalltalk's exception handling capabilities.

About three days later, some posters at Lambda The Ultimate took exception to the power of Smalltalk's exception handling capabilities [fixed URL]:

"So what you're saying is that you want to be able to bind exception throw behaviour dynamically, rather than lexically. The end result being that a caller can bind handler code into any (uncaught) exception throw, without having any way of knowing the source(s) of the possible exceptions, or their root cause.

How, exactly, is one supposed to document the exceptional behaviour of a library class in that case? What possible security gaurantees could one give, if a calling library can inject arbitrary code on any error condition, and ignore or mask the error as it will? How would you even exhaustively test such a thing, other than by ignoring the horrible stuff that your caller could have done to you and pretending you're in some some language?" -- Dave Griffith [I assume that "some some language" was intended to be "some sane language."]

I have news for Mr. Griffith: Programs Are Data. That truth is one of the pillars of computer science. Deal with it.

If programmers can't be trusted with the stack, they can't be trusted to assign the right value to a variable, nor to pass the right value as a parameter to a function. Compilers are tools, not hall monitors.

---

• Chronos blog home page
• Chronos Date/Time Library web site

A Strategic Opportunity for Smalltalk

Mark Shuttleworth:

"Instead of fighting over turf or syntax, I sensed a genuine willingness to synthesize the best work from both camps into something that could have both Python's pop-culture widespread appeal, and pedagogical foundations that build on years of Alan's experience in the Squeak world. The mouse might yet become the snake's strongest ally."

The computational model (which depends heavily on the VM) is strategic.

Syntax (which is just a matter of which compiler one happens to use) is tactical.

Avi Bryant had the right idea: Strategic thinkers in the Smalltalk community should create strong, compelling implementations of Python, Ruby and Perl, hosted on Smalltalk VMs--such as Squeak's.

Adding Erlang, Haskell, Io and Ocaml wouldn't hurt, either.

When it comes to advanced, dynamic programming languages, it's "United we stand, divided we fall."

---

• Chronos blog home page
• Chronos Date/Time Library web site