Smalltalk Advocacy

JosephBacanskas hosted a BOF at OOPSLA '98 that talked about ways to raise Smalltalk's visibility.

People mentioned that the Linux community is open to new ideas and needs a powerful programming environment, and both VisualWorks and SqueakSmalltalk might fit the bill. Join your local Linux users group and show them the power of Smalltalk. There was much interest in writing/porting a "killer Smalltalk app" for Linux, but nobody had a concrete suggestion. Anybody got any ideas?

''Yes. A fully free and unrestricted implementation that is ported and packaged to every system in sight and, where possible, lobbied into vendors' software collections. Without it there is little hope as there's a threshold and that threshold is not worth climbing just to try something obscure. This applies to all technologies that want to thrive in free software world. Iff the technology is interesting enough, someone might do the work for the advocates and so it goes unnoticed. But it's there. See gcc, guile, perl... Easy to get and available almost everywhere "out of the box".''

''That bit is a RefactorMe candidate. The point could be repeated after almost every sentence here and elsewhere.''

A key part to this is understanding the LinuxCommunity.

At the very least, it has to be FreeSoftware and play well with PosixApi? and CeeLanguage (The SimplifiedWrapperAndInterfaceGenerator is a must). Also having it developed by someone other than GNU helps.

People mentioned that ParcPlace/ObjectShare/GemStone seems to downplay Smalltalk and emphasize Java, when they are making money on Smalltalk but probably not much on Java. If you are a Smalltalk fan, call them and tell them they are making a mistake. Especially if you are one of their customers!

Any more ideas?


Some Java users groups are full of people interested in the latest language features and APIs from Sun, but most don't know nearly as much about objects or how to build them as the Smalltalk community does. This is another community that could benefit from the presence of some helpful Smalltalkers.


VisualWorks is not a good candidate; as AlanKnight hints at, languages whose implementation is not FreeSoftware stand chanceless in the LinuxCommunity. SqueakSmalltalk, while slightly more apt, isn't either. Linux developers don't fancy large, monolithic environments in which all work takes place. They like their EmacsEditor, their xterm, their cc, and their ld to be standalone and well-understood entities. I think what SmalltalkLanguage needs is the following: --MikaelBrockman

Why is GNU Smalltalk ignored ? MikaelBrockman: it fits the bill perfectly. free+filebased+extensible . If only more people contribute to GNU Smalltalk. --Krish

Smalltalk (and especially SqueakSmalltalk) made a lot more sense to me after I started thinking of it as an operating system, rather than just a language. Of course it feels weird to developers for other operating systems - we're not just asking them to try a new language, we're asking them to try a whole new OS too. (SmalltalkAdvocacy has all the difficulties of language advocacy and OS advocacy. :)

If the goal is to make a killer app for Smalltalk, I think we're going to have to, um, embrace our OS-ness. :) We could split apart the SmalltalkLanguage from the SmalltalkOs? and turn it into something that plays nicely with the surrounding OS, but the RubyLanguage guys have already done a really good job of that; if the goal is to make a killer Linux app for a Smalltalk-like language, I don't think it would be any shame to use Ruby instead of Smalltalk.


I think a GemStone-like database with really fabulous migration features (like integrated with the RefactoringBrowser) would be an enabler for BazaarStyle projects. --KentBeck

Check out the amazing OpenSource ZopeProject? at -- they have a database and web system for PythonLanguage. -- MartinPool

There is no need to write a "killer app". Smalltalk itself is the "killer"! It's a "killer development environment". There is simply NOTHING in the Linuxworld like Smalltalk.

But. There is a problem. The Linux development-tools that exist today are all FreeSoftware (or: "OpenSource (tm)). And these development-tools are part of all distributions, they are considered to be an integral part of Linux itself. While most of the Linux-freaks are open (or: not hostile) towards proprietary software, it is some kind of unwritten law that the System itself has to be Free. ("free" from "freedom". Think at "free speech", not "free beer").

(But apparently the free beer aspect is also important, since charging money for the tools is a no-no). -- AlanKnight

Paying, ie sending money or other goods to who knows where is insanely difficult in/toward many corners of the world and to many people. The price might not be bad, but add laws and banks and cultures where not everyone has a Visa/MC, it is very difficult.

''Commercial software also comes with other significant baggage like restrictions that prevent porting, packaging and redistributing the product. It's effectively non-integrateable. The software vendor probably only supports some corner case like an obsolete RedHat and their packagers lack the networking and skills needed to do real high-quality packaging and keeping up to date with things fast enough.''

Conclusion: VisualWorks non-commercial for Linux is cool, it will help ObjectShare (and the Smalltalk-community) to gain new developers, but: VisualWorks Smalltalk will NOT be part of the LinuxCommunity.

A visual IDE is not a BigWin? for Linux. You know how many of those guys consider VI an IDE?
What about GnuSmalltalk? It's a fast interpreter and recent versions have a JIT compiler as well. True, it lags behind in the GUI department but the FFI has stabilized and it's easy now to integrate modules written in C. IMO, it is an ideal tool for scripting applications. Anybody tried the recent versions?

SqueakSmalltalk is the way to go... But Squeak is not enough integrated into the normal Linux environment to be really usefull. A real "killer" would be a OpenSource Smalltalk with the ability to write "real Linux apps". But: what is a "Linux app."? That's one of the sad stories of Linux (and all Unices) -- The most interesting target environment would be (IMHO) The GNOME Desktop, -- MarcusDenker

(why gnome? Why does everyone like gnome so much? Why not kde?)

GnomeDesktop? is written in CeeLanguage, and many Gnomists are shopping for a viable high-level-language to replace it. JavaLanguage and DotNet (through Mono) are popular candidates, but unfeasible for licensing reasons. Many are holding out for a faster PythonLanguage implementation. The KayDesktop? folk, OTOH are happy with CeePlusPlus.
According to Freshmeat (, there are development projects underway to integrate the GTK and QT graphics libraries with Squeak. This could allow Squeak to become a more natural part of the linux development landscape.

Back to the thought about raising Smalltalk's visibility: I have often thought it was very ironic that the best development language for building large industrial-strength enterprise applications should be named "Smalltalk." No one encountering it for the first time would ever guess! It sounds like something you might embed in a PDA or a calculator or something. It would have been better if it had been called "BigTalk?," for heavens' sake! Has anyone else ever had this same thought? -- Ned Earle

If you're targetting Linux people (and I realize your comment wasn't directed at them specifically) the phrase "Industrial-strength enterprise applications" is like cryptonite to PerlMonks and BashShell? hackers.

I couldn't agree with you more Ned. I do think that part of the Smalltalk's marketing problem is its name. I made the same argument a couple of months ago on CLS -- George Santamarina
And I couldn't agree less with you guys :-) I am kind of buffled by the search for a new grand name for Smalltalk; a name which will "clean" our reputation, and will "enlighten" all those uneducated folks out there.

Well, in the spirit of AlanKay, here is a new name which says it all: NoTalk?. Or even better: Silence.

This reminds me of ECM, a German music company which carries the logo: "ECM ... the most beautiful sound after silence". (And they fullfill their promise...) -- BennySadeh
If I remember correctly, Alan Kay said they chose the name SmallTalk because all the other computer languages at the time were named after Greek gods. Personally, I can see the issue with the name, but I'm glad they didn't go for the most arrogant name out there.

In a way the name is not the issue, it is more a symptom of the issue. The SmallTalk/Squeak core of supporters consists of researchers that are far more interested in constructing the next revolutionary step than making the platform widely usable. Their agenda doesn't really coincide with our agenda, that's the issue.

If you want a pure OO language that's gaining a lot of ground, go to RubyLanguage. Ruby is not SmallTalk, but it's the closest thing we've got that's going somewhere. -- StephanBranczyk

Smalltalk was very visible in Seattle on Dec. 2. The Northwest Component Technology Symposium featured 3 experience reports, two of which were Smalltalk success stories. The third report was from a large company doing an all Microsoft solution. Travis Griggs from Key Technologies showed how Smalltalk is used to simplify the man machine interface of an extremely complex sorting machine. I talked about using Smalltalk at Mutual Travel to build a suite of web applications. The point that was really brought home by both presentations was that you can have very high productivity with very limited resources with Smalltalk.

Later, in a panel discussion with the rest of the presenters and the 2 keynote speakers (Jim Rumbaugh and Bob Marcus) we talked about how much lower the cost of change was when you work in Smalltalk. When we were discussing the kind of exploratory design/coding that is common for Smalltalkers, Bob Marcus warned the audience to remember that I was working in Smalltalk, and that if any his C++ programmers were to try working that way, he would shoot them! (Bob, I hope I got this right, I was VERY nervous).

The symposium was attended by about 60 people, most of whom paid at least $200 for the day. Smalltalk looked really good at the end of the day.

Perhaps, when evangalizing Smalltalk we need to introduce it to Domain Experts _and_ their programmers at the same time. That is, when introduced to an audience of programmers they tend to dismiss it because it doesn't let them showcase the skills they've spend years building, namely memory management and typing. Their Domain Experts aren't there to remind the programmers that _they_ are the ones who need to be satisfied. When it's just Domain Experts they like it, go back to their programmers and ask them about it, the programmers ask them afew questions which the DE's can't answer because they're not programmers, and the programmers advise against it. But to test this thesis, how would you get the Domain Experts and their Programmers to the same talk...?

Jim DuWaldt?
ObjectShare seems to have done an about-face on Java. There was no trace of Java in their booth at Linux World Expo in San Jose. --DaveSmith
Smalltalk's Real Problem

Don't get sidetracked by comparing Smalltalk's success with Java's success. This opens up a lot of issues that I don't think apply here. (It's also not <i>that</i> popular on Linux.) Compare Smalltalk instead to very successful Linux languages like Perl, Python and C/C++. What do they have that Smalltalk doesn't?

I'd guess that Squeak or GNU Smalltalk has the best bet at achieving something. (But GuileScheme has not taken off, "even" with GNU support). But, what's really needed is a way to fix these problems. I think that until you can have something like a Smalltalk CPAN, Smalltalk won't be successful. (Yes, I know about UIUC. I don't think it matches up to CPAN for a lot reasons.) Now this would be a VERY interesting project: building features into Squeak necessary to let it work in a global, component-based way.


What's wrong with SqueakMap?

I agree. The success of Java is on the Server-side and SmallTalk doesn't really lend itself well to server-side applications. SmallTalk still has a chance to thrive as a rich internet application development environment, but the much hyped success of Java on the client-side never actually materialized, so trying to emulate the success of Java is not going to work. -- StephanBranczyk

It would really require a development model different from Squeak's. They are doing BurnTheDiskpacks style development.

I don't see what the problem would be actually - I'd guess that the real issue is that implementing things like ease of naming/packaging/deployment have to be seen as important. - RobbShecter

The recent "Squeak World Tour" project aims to do exactly this-- create a stable, modular Squeak for commercial (and other) uses. See

You could use Squeak as a cross-platform compatibility engine. (Implement something like namespaces to help out with this. You'd have a different class library for each platform supported.)

Let's all just get out of the business of building a VM, and just build on top of Squeak! Then all of the Smalltalk companies would be pooling their resources to make the best possible platform!

Also, speaking of Perl, why not implement Perl on top of the Smalltalk VM? Why not everything? We could run Perl, Java, and Lisp comfortably on top of the Squeak VM. How's that for a plan to take over the world?

-- PeterKwangjunSuk

[Yes - this is the way for success, I think, and it's happening with Java. See: - RobbShecter]

At last year's OOPSLA someone presented info on the DoD's JWARS system, and how it was simultaneously developed in both C++ and ST. Does anyone have a phone number or email address for them?

Write to: "Donald Malcolm MacQueen?" <>

Jim DuWaldt?

Has anyone done anything with COM Automation and VWNC 3.0? Does anyone have any books to recommend on COM Automation? The 'Blue Book of COM' struck me as too Microsoft-language specific; Essential COM was great but not as an intro; and I couldn't find Effective COM.

Jim DuWaldt?

I wonder if Smalltalk has potential as an object modelling tool? Tools like Rational ROSE are pretty heavyweight and take quite a bit of getting used to. It is much quicker to create a few classes and objects in Smalltalk and play about with them. For testing out an AnalysisModel it would be unbeatable, especially if you create unit tests so that you can refactor your model as you learn more about the ProblemDomain. Even better if there some way to get a graphical view of the message sequence between objects in a particular test case. -- MikeHowells
CampSmalltalk was a Smalltalk advocacy event held February 14-18, 2000, in San Diego.

View edit of January 3, 2006 or FindPage with title or text search