Future Of Smalltalk

Not more than a week after I was asked to give a talk on the FutureOfJava and the FutureOfObjects I was asked to give my thoughts on what the FutureOfSmalltalk would be. This one stumped me a bit more. I came up with two:

OpenSource will become more important. SqueakSmalltalk has had a big impact on the Smalltalk community. ObjectShare made an interesting half-step in that same direction with VisualWorksNonCommercial. I think that the other Smalltalk vendor (you know who that is) will need to do either one or the other - give it away, or give it all away.
One of the great things about the EnterpriseJavaBeans spec is that it doesn't 'require' you to write your EJB's in Java. What about the idea of a SmalltalkEnterpriseJavaBeansServer

-- KyleBrown

The notes by John M. McIntosh? on the recent Smalltalk Solutions conference

http://www.smalltalkconsulting.com/html/SmalltalkSolutions2001%234.html

raise a lot of issues on the past and future of Smalltalk. For instance, a speech by David Thomas apparently included something like "We had the Python guy come talk at a conference and he gave us the same talk that Adele Goldberg gave years ago as something new. We were saddened. But what we have done is created a Smalltalk black hole were no ideas or light gets out. The Python guys rediscover our work and they become front page news."

I think the "black hole" worked both ways ... ObjectiveCee (and the NextStep/OpenStep/CocoaFramework), which is the "son of Smalltalk" and the "father of Java", has been evolving quietly for the last ten+ years into WebObjects and MacOsx. Have any Smalltalkers been paying attention to it?

Another interesting snippet:

: "What child would use a image in which you can't find anything of interest. 'Hey you can make games' we respond, but no games are supplied. It needs to be very simple. Why not separate the IDE from the execution environment. Microsoft .NET can do this!!!!"

-- KeithRay

Hmmm. I think Dave's taking things out of context. The reference Dave made is to an OTI internal conference last year (2000). Kent Beck was speaking on XP (actually he spoke on Frederick Taylor - interesting talk) and I spoke on WebSphere. Guido Van Rossom came in and did a talk on his latest Python thingy - his grand idea was to build a Python teaching environment and use it to teach Python to new programmers (I think Guido was discussing high-schoolers). At the end of the talk I made the comment that I had heard the exact same talk four years previously at the first SmalltalkSolutions conference, when Adele Goldberg did a talk on LearningWorks. I mentioned that this seemed like the same idea, so what was new about it? (By the way Kent kicked me when I said that). My comment wasn't on Python per se - it was that the idea of a simplified language learning laboratory hasn't worked out before, so why did he expect it to work now? -- KyleBrown

Perhaps XP will breath new life into Smalltalk also. Argument goes ... look at how fast people can develop, refactor and test in Smalltalk. You can do it Java, but it'll take a little longer, and you can do it in C++, but it'll take even longer. Someone ought to sit a manager down to look at a Smalltalk developer and a C++ developer side by side. "Let's see. Developer A is working, Developer B is working, Developer A is working, Developer B is compiling, Developer A is working, Developer B is compiling... "

One of the big problems I've seen which prevents the take-up of any "workspace" based language (Smalltalk, APL, Forth etc.) is that it's really hard to work out what it is that is delivered to the customer. This makes it increasingly hard to get past the layers of non-technical management which have to approve such things. With (say) a C++ project, there can be a "real" executable program at the end, and most managers and policy makers understand that. Especially good in these paranoid times is the fact that the source code isn't included in the delivery, so if it fails to work some other team can be blamed. Even with an interpreted language like Java (and especially with "executable" jar files) there's a program which can be put on a disk or emailed to someone. In short, there's a product.

What do you actually deliver from a Smalltalk project? A set of patches to an environment? That sounds worrying already. It's not clear what (if anything) is the difference between the development environment (open to easy change and analysis) and the delivered product (needs to be bulletproof and secret).

How would a practical Smalltalk evangelist overcome these objections?

-- FrankCarver

I'm sorry, I'm not getting what your concern is. Perhaps some explanation of how one ships Smalltalk will help.

A Smalltalk app ships just like any other: an EXE, some DLLs, and some random other files. There's no need to ship the source, and most commercial Smalltalks actually prohibit shipping the development environment as part of the app.
In C++, you build up your EXE by assembling object files into it. The object files are created by compiling methods from your source control system.
In Smalltalk, you always have an EXE, which you build up and revise by loading methods from your source control system. Any time you save an image, you have built a version of the development system, with your app in it. That, of course, isn't what you probably want to ship.
To build a shippable image, you start a clean image, load your source, strip out things you don't want to ship, and save. Voila, an EXE that works just like the one you built in C++.

More questions? Please explore further. -- RonJeffries

This is something that came up out of the discussion that I had on the FutureOfSmalltalk as a problem. Ron, your steps (load, strip, save) are backwards from what would be best. It would be easier if we had a way to ship an .EXE that instead went (pick, click, done) that involved picking a set of classes, letting a packager traverse the dependency tree down from that and result in a single file (either a .im or .exe) that was "the program". I think the idea is that the process could be made simpler. I know OTI's ENVY/Packager did this once - it'd be great to have a free thing like this for Squeak.

-- KyleBrown

I think every good commercial Smalltalk allows programmers to do what Ron describes (that's part of the definition of a good commercial Smalltalk). It used to be an extra-cost feature (thinking waaaaaay back to my limited Digitalk experience circa 1991), and I don't think most of the non-commercial implementations (e.g., Squeak) support it. (For example, there's a no-cost (binary only) distribution of DolphinSmalltalk 1.1, but you have to pay for an add-on "Application Deployment Kit", or for 2.1; see http://www.object-arts.com/Products.htm for details.) All (nearly?) C/C++/Pascal implementations 'always' provide this as the only option. Maybe it's "only" a problem in the perception of Smalltalk, but then, isn't its perception one of Smalltalk's biggest problems?-(

-- PaulChisholm (who's also used to the "the program is a process that starts at the beginning" model, which is very different than the Smalltalk model, in my perhaps flawed perception)

AlanKay likes to mention in talks about OpenCroquet that he sees the emergence of dedicated applications as a retrograde step. Perhaps this explains why SqueakSmalltalk seems to be a completely self-contained environment. If people can be invited to download a toy operating system from a newsgroup and build it up into what linux is today, perhaps it's not so outrageous to think that we could see Smalltalk as an open-source operating system. Perhaps a first step would be to implement some really useful things in squeak, rather than just cool research-focused demos. I'd love to spend my free time computing in the squeak environment, but the tools (web browser, mail reader,...) aren't really anywhere near useful enough to entice me to stay in there for long. If Linux can go from a tiny, broken, intellectual toy to an enterprise server environment, I don't see why an open sourced squeak couldn't go the same way.

The Squeak3.6-5424-full.image, which I downloaded in November of 2003 to play with and explore, seems to still suffer from the MESS (MutuallyEncapsulatedSoftwareSystem) syndrome that the ParcPlace flavors have always suffered. I believe this is the most current download available to the average Google user. It does not use the native toolbox. It certainly doesn't use the WinXX key binding conventions, nor offer an obvious way to make it do so. It doesn't even conform to the "normal" Smalltalk filein/fileout format. It doesn't offer any compatibility to Envy/Developer tools, nor suggest how I might provide such compatibility. In short, more than twenty years after Smalltalk-80 was first offered by Xerox, Smalltalk still demands that any newcomer enter a completely isolated world where nothing is familiar. I believe this will continue to have a devastating impact on its ability to have any influence whatsoever.

I therefore suggest that if the Squeak community wants to avoid going the way of the Shakers, it might consider adding the following to Squeak:

Native toolbox compatibility. IbmSmalltalk has offered this for years. The relevant standards have been defined for years. The relevant code is surely straightforward. If it has already been done, then perhaps make its presence more obvious.
Key binding compatibility. Follow the mouse and keybindings users are already accustomed to on whatever platform is running it.
Compatibility with other Smalltalks. Provide support for Redbook Smalltalk and/or ANSI Smalltalk. Cooperate with the other Smalltalk's in supporting a "portable" set of common API's and abstractions. Provide modules to support Filein/Fileout with VisualWorks, IbmSmalltalk, and others.
Integration with current efforts at net-based computing - such as EJB (as mentioned above), the .net initiative, webserver backends (some of this is already present), and so on.
Integration with existing relevant standards - ODBC connections to databases. Quick and easy XML reading and writing. SOAP compatibility. Read and write MSWord, MSExcel, MSVisio and MSPowerPoint files. And so on.

My point is that if the Smalltalk community wants to provide a future for Smalltalk, than we must lower the barriers rather than raise them.

Oh, dear. I can sense one of those open source "if you don't like it - fix it" style answers looming here. Fixing the key bindings to Ctrl-whatever rather than Alt-whatever shouldn't be that hard. The key bindings in Squeak have been driving me nuts for a while now. (Which classes should I browse to find out about these bindings?) I don't think most Squeakers care about native widgets because they can't do cool stuff like rotate them or fit them 'round a Bezier...

I've seen people connect Squeak to SQL Server for one thing. (I believe that there's some kind of SQL Server driver on the squeakmap.)

If you want compatibility with Windows specifically, the DolphinSmalltalk people have done a fantastic job of integrating against the windows API and COM. Trouble is, I rather enjoy being able to take my Java and python code and run them on Linux and the Mac... and the idea of churning out executables that only run on windows is particularly nasty, as I'd rather remain independent of Windows. The big name Smalltalks look like they might help me here, but they're insanely priced considering how cheap Java development runtimes and development tools are today.

I've pretty much given up on the idea that I'll find somebody that wants to employ me to work in Smalltalk. So I'm looking Smalltalk as a something of a hobby. Most open source projects have a lot of statically compiled, nasty, unobject-oriented code. They're much more hassle than the XP produced Java code I handle at work. So, even if you give up on selling Smalltalk software, I don't see why neat, useful open source projects can't be done in squeak (however weird it looks). Perhaps it's a matter of getting squeak out to enough teenage hackers and giving people enough out-of-the-box, useful apps to make them stay in the environment for more than five minutes.

Fixing the key bindings to Ctrl-whatever is surprisingly hard in Squeak, because none of the underlying support is in place. The KeymapManager? does some of the heavy lifting, but can't touch the the hard parts. The use of the shift key to extend the selection region, for example, requires the entire selection mechanism to be rewired -- Squeak does not preserve the initial index of the selection region, and therefore can't pivot it correctly.

I fear you missed my point about native toolbox compatibility. Smalltalk excels at allowing itself to be customized to exploit the features of a specific platform, while preserving common cross-platform features. IbmSmalltalk, building on the approach of Digitalk's Smalltalk/V, solved this problem a decade ago. The "Common Graphics" framework is surely no harder to incorporate into Squeak then Morphics, yet it hasn't happened yet. I hope to find time to attempt this, but my point remains that the barriers seem much higher than they need to be.

Do any Squeakers still browse here? If so, is there any support within Squeak for constructing a Squeak image intentionally designed to play well with existing platforms? Here are my suggested platforms, in order:

WindowsXP (Client-side)
Linux (Headless, with industrial-strength UDDI/WSDI/SOAP support)
Mac

(25-May-2004) Could SharpSmalltalk be a way in a better future for SmallTalk? Its a .net implementation like some here seem to demand.

It appears that there are significant technical hurdles within the .net environment that block a "real" .net Smalltalk.

In fairness to Squeak, I have to point out that there are preferences to duplicate/swap the Ctrl and Alt keys, a package, ShrinkSelection?, on SqueakMap to get you orthodox shift-selection behaviour, and there are packages for ODBC (haven't tried it yet), XML (built-in, in fact), and SOAP. There is lots of work going on in translating between dialects - this isn't just a Squeak issue. Finally, I don't know how you expect to be able to read MS* formats, since they are notoriously not published; something like OLE would be required (which, admittedly, I can't find either).

I do entirely agree with the MESS part of it. In my personal opinion, there are three reasons why Squeak has a very low profile in the OpenSource community. One is that its license does not prevent competitors from simply taking contributed code (this is the *BSD vs Linux HolyWar, so I'll leave it at that). Secondly, it is hard to leverage other open source libraries (and there is a vast number of them). Finally, Smalltalk in general suffers really badly from the NotInventedHere syndrome, and that completely undermines any sense of a friendly community. The second and third points reinforce each other.

MikeAnderson

For the same reason that the QWERTY keyboard and the steering wheel and the duodecimal/sexagesimal time system are nearly impossible to dislodge from our consciousness and from our practical existence, in computer programming, procedural languages and file-based storage systems are solidly entrenched in our collective psyche. This is why purely functional languages, for example, have never achieved universality, and why object-oriented programming (or OOP) has only been grudgingly incorporated into what are essentially procedural languages. (While there is a plethora of languages from all manner of programming styles, and many of them have devoted followings, very few have achieved the ubiquity that can be found among the likes of C/C++/Java, Python, and Algol-type languages.)

There is a glimmer of hope, however. Steering wheels may give way to self-driving cars. Stardate may replace our beloved time system in a few centuries. And Smalltalk, with its image-based environment (and system of "live" objects), may eventually find its place in the pantheon of mainstream software engineering tools in the latter half century of programming language history thus far.

Hey, you never know!

Richard Eng

CategorySmalltalk