If Smalltalk Is So Good Why Does Nobody Use It

Time and again people say what a good language Smalltalk is, and compliment it on its features. It is mature, yet hardly anyone uses it.

(Sorry for the WikiName - it is overstating my point but I like them hard-hitting).

Seriously why is it not used as widely as VB, Java, C++ etc?
Some people use Smalltalk.

JpMorgan? Kapital (one of the Smalltalk poster-children back from the dead.)

From the ComputerWeekly case study: "With the size and complexity of the system (14,000 classes and 400,000 functions) written in an esoteric language and database, one would assume that the technology would be the limiting factor in its continued growth. However, the greatest difficulty for Kapital is not the technology, but understanding the business and business processes themselves."

Uhh... 14K classes and 400K functions?!? I would think that, yes, the technology is, in fact, a severely limiting factor.
Since Microsoft didn't invent Smalltalk (VisualBasic was their dynamic language); they didn't sell it. IBM sold it, but didn't push it. AT&T invented C++ and gave it away. Apple invented ObjectPascal for Macintosh (derived from ClassCal? for Lisa they developed with NiklausWirth), and later AppleScript, HyperCard, and DylanLanguage, and pushed those at various times (very briefly in the case of Dylan). BradCox invented ObjectiveCee (based on C and Smalltalk) and sold it for what many people thought was a too expensive a cost. Next built the NextStep class framework, and WebObjects on top of ObjectiveCee, and sold lots of copies on top of NextStep the operating system to developers, but it was expensive and not supported by Microsoft (no Word for you!) Sun invented Java as an anti-Microsoft-weapon and push it very hard.* Xerox invented Smalltalk, Ethernet, some personal graphical-based workstations and operating systems, and the prototype for PostScript, and didn't make any money off of any of those things -- they didn't know how to market anything except copiers.

* There is more detail at JavaHistory. -- TomStambaugh

So it all comes down to (1) who invented it and (2) who pushed it in the market. Everything could have been different if XeroxParc had been a research unit for Microsoft...

Except this doesn't explain why ethernet, postscript, and Wimp were a hit while Smalltalk wasn't. None of them were invented by Microsoft or IBM, and none of them were pushed by Xerox. C++ got popular despite never being pushed because Unix was tied to it. So why did Unix become popular? (I'm not gonna accept "on its merits"). I think it says something about the software industry that out of the 8 factors you list, only 1 of them's technical. In order: I agree; technical merit is rarely the deciding factor in market success of anything. On the other hand, you have no idea how much other OSes sucked, in general, back then (not that any of them are wondrous things of beauty today, either, but things have improved in general). Many OSes throughout history have had interesting features that were cool in isolation, but the overall experience of working under most of them was hideous (which didn't stop them from each having their own enthusiasts, of course).

I forgot an important technical feature of Unix: typesetting via nroff and troff, which actually was what sold Bell Labs management on Unix from the beginning. Unix was the cost effective platform of choice for fully computerized typesetting for quite some years. Many books were produced via running off camera-ready copy on PDP 11/40s and 11/70s on CAT-4 phototypesetters, and Unix helped increase the sales volume of such hardware.

The Macintosh gets most of the credit for revolutionizing desktop publishing, and any remaining credit for computer typesetting tends to go to Don Knuth, but Unix was there first (not that the CAT-4 was desktop). Knuth essentially does not acknowledge troff at all, which is uncharacteristic; he usually is much better at acting humble and giving credit freely. My speculation is that he didn't even know of the existence of troff until he was very far along with TeX, and that this warped his thinking. Troff was essentially as powerful as TeX, although certainly its somewhat cryptic syntax was something of a disadvantage (command names limited to two-characters).

Too object-oriented? and Because OOP is too difficult

Having a big procedural background, it is very difficult to shift to OOP. C was mainstream, most of these moved to C++ without learning OOP. Now they moved to Java, because Java is a great advantage (over C++). The same for these Basic to VB movers. If I have to maintain this code, I wouldn't complain about this non-OO, I would be happy if it is well-structured and redundancy free.

However, these are minor concerns in relation to its most glaring difference: Smalltalk greatly encourages programmers to write object oriented code while C++, Java, and VB do not. Most of the C++, Java, EJB, and COM objects I see just aren't. Smalltalk, on the other hand, makes writing procedural code difficult and messy (partly because of its library and partly because of its syntax). Writing good OO code takes discipline and a change of mindset that a lot of people just don't take.

Chuckle. Maybe somebody can enlighten me as to WhatIsGoodOoCode, or maybe as little as what is OO code. After years of experience (I haven't counted my lines of code though) and reading thousands and thousands of pages (books, research papers, patterns, the whole enchilada), I'm still searching for these answers. And in the meantime I'm smiling when I see a quasi-general introduction: in the recent years, OO has become the method (or whatever) of choice , bla bla, bla bla,...; pick almost any book on OO at random, and you'll see opening nonsense along these lines. I think this has unfortunately become a case of TheEmperorsNewClothes. -- CostinCozianu

Smalltalk greatly encourages programmers to write object oriented code while C++, Java, and VB do not. Most of the C++, Java, EJB, and COM objects I see just aren't.

>> How does Java not require to write object oriented code? Everything must be a class/object. Why does everything have to be ObjectOriented? Is that the only good style of programming? What about Generic Programming? -- sg

Does IsJavaObjectOriented address some of the issues about Java's OO-ness?

C programmers writing in Java tend to use classes as if they were namespaces, with lots of static methods, and very few non-static methods or sensible inheritance. I've seen it. Blech. -- KeithRay

Yuck, but seen it does not mean that the majority of Java programmers program that way. I know its possible but I have never seen anyone do it. -- sg

Most Java programmers I've met write in a semi-OO style, with few and big classes. It's not procedural, but it's also far from taking advantage of the OO features of the language. -- AndersBengtsson

Legacy of being expensive?

Because Smalltalk used to be expensive, while CFront was practically free.... after that, the 'network effect' snowballed...

Bad marketing?

Because it has a stupid-sounding name.
Not supporting types.

Apparently some people have assumed, without bothering to check, that it has no types, but of course Smalltalk is a dynamic strongly typed language.

This does not appear to be a wide-spread misconception, Smalltalk primarily being famous as an OO language, so presumably this is not a factor in Smalltalk's adoption one way or the other.
Too odd?

The SmalltalkLanguage is different in many respects. It used a VirtualMachine when VirtualMachines weren't cool. It's syntax is fundamentally different than C, C++, Java, VisualBasic or other AlgolLikeLanguages?.

MentalModel. Smalltalk (and SelfLanguage) are hard to understand from a static perspective. In CeePlusPlus, you can see how they start the application, then create a window, then initialize a bunch of data structures, etc. In Smalltalk, your application is already loaded. All of the global data is already initialized. Consider opening a BrowserWindow?. The source code tree, (ClassOrganizer?) with the class descriptions, MethodOrganizers?, and compiled methods, are sitting in the image, waiting to be used. If you didn't already have an image, it would be very hard to create one from scratch. (I know, because I've tried to do this in Squeak a few times, with little success.) In other languages, this data has to be persistently stored somewhere, because the environment isn't able to keep it around.

I understand that some Lisps are kind of like this. EmacsLisp comes to mind, and I think the LispMachine is similar.
Too slow?

About five years ago, I joined a project where the prior generation of code had been written in Smalltalk. The developers loved Smalltalk. Management abandoned Smalltalk for C++, mostly because Smalltalk was too slow. The C++ project ended up being a dismal failure, mostly due to politics, but the complexity of C++ did slow down development considerably. Most of the developers felt like C++ was a big step back from Smalltalk in terms of expressiveness and usability. Now, machines are a lot faster, but Smalltalk's competition (e.g. Java, Python) is also more mature. At least two of the ex-Smalltalk/C++ developers now program in Java. -- SteveHowell
Too much competition? Not open enough?

I have never found a compelling reason to switch to Smalltalk. For big projects, I wouldn't want to sacrifice the speed of C++. For smaller projects, I have never hit huge usability obstacles in OO Perl, Python, Java, etc. I still have an open mind, though. The best language advocacy for me is actual code. If some one were to take a nontrivial, well-written Python program, and then show a more elegant version in Smalltalk, then I would consider Smalltalk. -- SteveHowell

Python's a bad example for this page, because it does a lot of the same good things that Smalltalk does, language-wise. The main advantage of Smalltalk over Python, and also the main advantage of Python over Smalltalk, is the difference in environments. Smalltalk IDEs are just dazzling, but you need to be able to live with having the entire world wrapped up inside a monolithic image. Some projects, and some people, can't. -- AdamSpitz

Well, perhaps we have stumbled upon an answer here: "Smalltalk IS so good, but nobody uses it, because Python is almost as good language-wise and not so coupled with IDEs." -- SteveHowell

I think you're right, but not yet. :) Maybe in five or ten years you'll be right. I like Python a lot, but I don't think it's the one that stole Smalltalk's market share. :) Even if Python weren't around, I don't think Smalltalk would gain many users.

But you're right that Smalltalk's coupledness to its environment and image is one of the reasons that people don't use it. If RobertMartin's prediction of increased use of dynamic languages comes true, I expect that most people will use languages like Python and Ruby rather than Smalltalk, because they play more nicely with the rest of the world.

-- AdamSpitz
(Very) optimized for single programmers?

It may be better to say that it was optimized for non-programmers. A major design goal of SmalltalkLanguage was for it to be accessible enough that any casual user, after minimal training, could use it to customize their environment and perform basic tasks. It was even thought that there wouldn't be any need for professional programmers anymore, once everyone could write their own objects as needed. The irony in this almost tangible. -- JayOsako

I have been a full time Smalltalk programmer for ten years. Smalltalk is fantastic if you are a single programmer, writing an application that is built on top of the included class libraries.

I am only guessing, but I don't think multi-person programming was even a minor goal, let alone a major goal, of the original Smalltalk project.

One of the reasons XP works with Smalltalk is that it makes ten developers act like one developer with respect to the image - joint code ownership and frequent releases on one machine.

What causes this problem? Is it the highly integrated environment that makes cooperation hard?

I've been developing in Smalltalk since 1982. This problem was solved, in my opinion definitively, by EnvyDeveloper in the late 80's. Multi-person programming in Smalltalk, using Envy Developer, is several orders of magnitude easier than multi-person programming in any other language I've used, specifically including CeePlusPlus, JavaLanguage, PerlLanguage, CeeLanguage, and all the derivatives. The highly integrated environment makes the cooperation easier, not harder. There are many pages here where you may explore the multi-person aspects of Smalltalk in more detail.

True. Envy's main goal was to enable multi-person development and they succeeded quite nicely (imagine that). Smalltalk+Envy is great for team development.

But Envy wasn't built into Smalltalk from the start (it was later in IBM Smalltalk). Without Envy there is no code unit other than the class and the image, making sharing code, and delivering applications, quite difficult. (With Envy, an Application is larger than a class, but smaller than an image).

Only some fraction of Smalltalkers use Envy or IBM Smalltalk. Within a company, I have seen Envy Applications shared between people, and between projects, but I have yet to see an Envy Applications shared between companies (i.e. as a third party add-on).

And knowing how to code effectively with Envy is an additional skill set, on top of knowing how to code effectively with Smalltalk. Because individual developers don't use Envy, you only acquire this skill set by working on a group project. If you start a project using Envy, and no one on the project has used if before, you flounder, at least for a while.

The concept of a file pervades C (headers, includes, etc.). Java has a wonderful concept of packages. Python and Ruby use files (if I understand correctly).

Maybe our question should be if Smalltalk + Envy is so good, why does nobody use it?

I agree with your observations and questions. These are things that unfortunately have deep and lengthy, rather than short and pithy, answers. Let me try a few highlights, though.

One decision every language designer makes is a tradeoff between things that go "in the syntax" and things that go "in the environment". Lisp and Forth nail one extreme - virtually nothing is in the syntax, virtually everything is in the environment. Algol, Ada, Pascal, and similar languages define the other extreme - virtually EVERY change to semantics forces a change in the compiler. Smalltalk leans towards the Lisp/Forth end, C++ tilts VERY much towards the Ada end, and Java tries to strike a balance. Most teams who used Smalltalk before Envy had worked out ad-hoc strategies for team development. Most of us discovered idioms that worked - for example, file in all the class definitions first, then file in all the methods. Most of us consequently discovered that code changes that involved only methods (but not changes to the class definition) were easy to share and add or remove. This was the basic insight from which the Envy partitioning of "Class Definition" and "Class Extension" was born. I'm not sure if that was intentionally "designed in" or not, but I know that it is fundamental to the success of team development in Smalltalk, and its absence is a huge obstacle in Java.

I don't share your enthusiasm for packages in Java, unless you were being ironic, but that's a whole wiki in itself. My opinion is that Envy-style applications or configuration maps are a much more suitable packaging mechanism than Java-style packages.

I still maintain hope that we will eventually end up with an environment that is NOT based on files. Smalltalk and Envy get us much closer to that than Java. The java package is, unfortunately, little more than an ossified file directory badly wired into the guts of the language syntax. Java thus represents a huge step backwards along that dimension.

Finally, as to why "nobody uses it" - I think it is because it requires a genuinely difficult paradigm shift to grok and then internalize "object-think". Most developers don't or won't do it. Once the shift is made, Envy is compelling, obvious, and elegant. Until the shift is made, Envy is obnoxious, irritating, and unforgiving. My favorite expression for the system behavior during the transition is "EnvySpank?" - the environment simply insists that, for example, you not subclass another class unless you REALLY HAVE declared it as a prerequisite. Most Java and C++ programmers that I have worked with prefer to ignore those "picky details" - they view such constraints as stupid things that QA programmers who build makefiles worry about. An environment like Smalltalk and Envy punishes the developer until the developer internalizes concepts such as dependencies, prerequisites, modularization, and so on. I find most java and C++ programmers unwilling to accept the resulting design discipline. -- TomStambaugh

Tom, my curiosity is piqued. Can you describe your objections to java packages in, eg., CodeOrganizationAlternatives?
Supporting Only the ObjectOriented Paradigm

>> Smalltalk greatly encourages programmers to write object oriented code while C++, Java, and VB do not. Most of the C++, Java, EJB, and COM objects I see just aren't. <<

Whether the above is true or not is a matter of debate, but one hidden danger is that the term "ObjectOriented" has become a synonym for "good". Object has been tossed at everything in the market and attached to nearly every paradigm. As someone said above "what really is ObjectOriented?" The following is some ideas from JimCoplien: Pure objects aren't the answer either. Perfectly good paradigms have been marginalized by ObjectOriented hype. The tone in contemporary development shops is that no-one would be caught dead using procedural decomposition, even for a batch sorting routine - objects must somehow be crafted into the solution. That leads to designs in which square pegs have been forced into round holes. It has always been a good idea to mix multiple paradigms tastefully and great software designers have long kept several tools in their toolbox. The object paradigm itself is a hybrid of the paradigms that supported it, among them modularity, abstract data types. procedures, and data structures. C++ goes further to support procedural, modular, object-based, ObjectOriented and generic programming on an equal footing. Mixing paradigms is admittedly hard but is needed in many designs. By forcing essentially one paradigm Smalltalk has not been successful or ultimately as useful as C++. C++, contrary to what most people believe, supports MultiParadigmDesign with procedural, modular, object-based, ObjectOriented and generic programming on an equal footing. It directly expresses the intent of the analysis in a way that Smalltalk can only do by convention.

-- sg

But that did not stop Java's popularity. However, people often do write a procedural style with classes, it is just more verbose than full functions.
Vendors uncooperative, greedy

Because when they had the market in their hands, the vendors spent most of their time squeezing it as hard as they could and fighting each other, instead of building market share. It was a hard enough sell conceptually, but when you had to pay for a runtime licence for each installation then you could be hit with arbitrarily large costs if you got lucky. With C++ and VB at least you only paid for the development kit.
Deliberately non-commercial?

I love Smalltalk, but can't make a living with it. I got the feeling that the Smalltalk gurus did not want it to be popular. For example, Smalltalk would be the best possible language for electronic business, which requires dynamic adaptive models. But I think many (not all) of the Smalltalk gurus consider business to be crass, whereas Smalltalk is for fine art. -- AnonymousDonor

I don't know whether that's what the Smalltalk gurus were thinking or not, but that's something I've been thinking about lately. Should every good language out there try to be popular? There's something to be said for staying small and nimble. -- AdamSpitz

Smalltalk was definitely intended to be successful, but not in the sense that most of the posters mean here. As I said above, it was designed to be a universal language, in the sense that anyone could use it with little or no formal training in it. Appealing to professional programmers was simply not considered important, and indeed would have been thought pointless. Smalltalk was designed to make the conventional model of commercial software obsolete - after all, who would want to pay someone else for software, when they could just jot out a few lines of Smalltalk on their DynaBook in less time than it would take to ask for it? (Remember that this was before BillGates and PaulAllen invented the concept of CommoditySoftware, so 'commercial' software meant 'written to order'.) -- JayOsako
Cost, platform-support, and Look-and-Feel

This one has really hit me recently. I have been doing smalltalk programming, pretty much full-time, since 1989. First Digitalk V/Mac, then SmalltalkAgents?, then Digitalk V/OS2, then IBM VisualAge, then Dolphin, then more VisualAge and recently some VW (VisualWorksSmalltalk) for personal use. Smalltalk work has been getting harder and harder to find. For the last year or so I have had my own development company, and on two projects was given a free choice of which language to choose. Great, more for smalltalk right? Wrong, I had to go to PythonLanguage both times. The primary issues were cross-platform portability (VisualAge doesn't do Macintosh), and cost. VW licensing is a killer for small companies. Not only do you pay a lot for the environment (I could justify that on time saved), but you pay it EVERY YEAR, and you pay a percentage of sales AS WELL! I just couldn't sell that to my clients. (I don't think that's entirely accurate. You pay *nothing* for the development environment, Cincom has only deployment fees. There are multiple models for that, but if you choose the one that's a percentage of sales, that's *all* you pay, not an 'as well'. See http://smalltalk.cincom.com/prodinformation/index.ssp?content=commercial or http://www.cincomsmalltalk.com/CincomSmalltalkWiki/How+does+VAR+Pricing+work , but I concede the basic point that Cincom's background is enterprise systems and they aren't well-geared to selling to small companies. That's something we in the Smalltalk group have been working on, but changing corporate culture is a slow process. -- AlanKnight) So I have been using Python, and cursing it pretty much; it is nothing like as consistent and elegant as Smalltalk or Ruby, in my opinion, and the tools are pretty abysmal. On the other hand, it had libraries, particularly mature(ish) GUI libraries, that Ruby doesn't have, so there we have it. Oh yes, of course I could use Squeak for free, and that is cross-platform. I can't present the result as a professional application though, unless it has changed dramatically since I last saw it.

Don't get me wrong, in many ways I like what Cincom have done to VW since they took over, and finally providing non-commercial versions for free is a great boon (I could finally take a look at it, for example). But licensing costs is still a big issue (and ParcPlace killed off Digitalk, which was the otherwise close to ideal solution). The other problem has been the splitting of smalltalk into factions. Unlike Sun, who have kept close control on what gets into Java, ParcPlace allowed licencees to develop very different environments. Okay, the basic language is the same, but GUI classes in particular are quite different. As a contractor I was not even given an interview for a job as VW programmer, even though I had (at that time) 11 years smalltalk experience, because I had never used that particular implementation. -- AlunApRhisiart
Not designed to be widely used?

Good programmers produce products that meet their goals. The Smalltalk designers (in my personal opinion) sacrificed everything else in the pursuit of ease and fun of development. No trade-offs whatsoever.

Since the only design goal of Smalltalk was to have people love to program in it, everybody who programs in Smalltalk loves to program in it, but businesses do not use it. It does not meet their needs.

Why doesn't it meet their needs? The following list is redundant with the rest of the page, but here goes So Smalltalk was great at in-house apps that do not use databases. At a high cost. Is that enough to create a beachhead in early majority territory?

Having programmers love a language is a great goal, and Smalltalk achieved that. Catching on like wildfire is a great goal, too, and if the Smalltalk designers had had that goal, they probably would have achieved it, too. They were pretty smart.

-- StanSilver

Lack of Convincing Example Applications

One thing I like to study is actual code, or at least semi-realistic examples, hopefully in or near my domain, showing how and why something is allegedly better. Talking about how "elegant" something is will not sell me. I want to see code and know exactly why it is allegedly better than the alternative (with commentary).

[Not really a valid complaint, one only has to download squeak, or some other smalltalk, pop open the image and read till your brain explodes. There's a huge library of available source code to read readily available, for those who actually seek it, rather than wanting it spoon fed to them.]

I think people generally relate more to an example application rather than developer tools. For example, a sample airline reservation system. What works well for developer tools may not work as well for applications, and vise verse. Further, one is often not sure what is supposed to be better when reading code. You look at it and say, "Yip, it's code, no doubt about that, but what do the authors like about their own code?"

[Who said anything about developer tools? The image has plenty of sample applications, and you can readily fire up SqueakMap and find more, you only need open up the image and look for it.]

Is there a particular one that you could commit to defending against a non-Smalltalk version of the same thing? Could you tell us up front with clarity how it is better than say a Lisp or Java or Php version of the same thing? Otherwise, we could build a Php version of the same thing only to have you disappear into the fog without comment. If you really want to sell ST to the masses, hit-and-run evanglism won't cut it.

Maybe because it didn't run in a browser as applets and wasn't called Java when the espresso and quality coffee were catching on.

I think good marketing on Suns part made Java a commercial success. IBM switched to Java and that was it.

-- DougRansom
Moved from WhyHtmlSucks:

You know, it's not like Smalltalk's keeping any other language from building up to talk to it. Sure, it'd probably require reimplementing ST in that language, much like every powerful language eventually reimplements Lisp, but why should ST dumb DOWN to the level of other languages just to communicate with them? Do I know how Opentalk represents things at a low level? Haven't the faintest clue. Nor do I care. What matters is that at the end of the pipe I'm talking to Smalltalk objects. I'm pretty certain you could write a little package to verify the security of the objects you export, to keep them nicely passive.

For me, SmallTalk fails on critical mass and I suspect the reason SmallTalk doesn't have critical mass is that it is so different.

Speaking for myself, from Basic, I largely knew Pascal. Fortran wasn't much work after that and C was a breath of fresh air. C++ was, I thought at the time, just more of the same and Java, again, a breath of fresh air after C++. Perl, also, more of the same plus a zillion features I could learn at my own pace. SQL, Cobol, Forth, no challenge.

Then SmallTalk.

SmallTalk was a shock to the system. I had to unlearn everything I thought I knew. I'm glad I did. I discovered that I never really understood C++ or Java, I just thought that I had. But it was hard work. I completely understand why most people (wrongly) think it's not worth the effort to learn it.

No stand-alone applications Write a small app in (lets say) C++. Copy onto a floppy and give it to someone else to run on their computer. Now try and do the same with Smalltalk...

Well, let's see now: my computer is a Mac, whereas my parents' is a PC. If I write a stand-alone app on my computer, copy it onto a floppy and give it to them to run...failure will ensue, since C++ apps that do anything at all useful aren't stand-alone by any stretch if the imagination. Now, suppose that I write a Smalltalk app on my Mac, strip down the image and send that to my parents. Suppose that they already have a vm installed (and I'll make sure they do), success!

Are you saying it doesn't generate EXE's? That hasn't stopped other dynamic languages from enjoying some amount of popularity.


See: TooAdvancedForItsOwnGood, WorseIsBetter

View edit of November 28, 2014 or FindPage with title or text search