Smalltalk Died because Of Greed, Speed, Mis-Development, and Hype.
Adele Goldberg's greed killed it early on three ways:
1) High licensing fees in thousands of dollars contrasting Microsoft's $100 market.
2) Profit share fees - attempted to get a share of a company's benefit from using Smalltalk.
3) Stopping development by other licensees such as Tektronix.
These items resulted in diverse competitors such as Digitalk, Apple, etc. causing incompatibilities instead of a strong unified language, eventually resulting in other languages such as C++ adopting objects.
Speed was always a problem because it is an interpreted language instead of a compiled language - everything that isn't in the Virtual Machine is evaluated during execution. Early pauses for garbage collection were annoying. A painfully slow example was Digitalk's Goodies code to train Neural Networks. As a rule of thumb applications that can tolerate relative slowness are those where the human doesn't use it rapidly. A bank teller's terminal is used more slowly than an insurance claim operator's faster data entry to get through many claims per hour. Real time applications require more speed - a self-driving car is likely to crash with a 100 millisecond delay at the wrong time. Thus Python's ability to disable garbage collection can make it a safer choice.
Mis-Development has been a plague on Smalltalk's usability. The earliest item is calling a bit copy function a bit block transfer. There is no good reason to make things that much harder to understand, especially when you're trying for self documenting code. A big misstep was the Patterns fad. Many books were written pretending to show the form of best practices in writing algorithms with zero algorithm content, making them unusable by programmers who need algorithms. Had the efforts of these misguided authors gone into making advanced application libraries as one finds by searching "Free Open Source" which finds projects like OpenCV and Tesseract, Smalltalk would not be so dead. A similar fad was pursued by people trying to make object analysis a more complicated "paradigm" even in the name of simplicity. CRC cards became another excuse to keep ideas on paper instead of writing Smalltalk code. Contrasting these mis-Developmets is the development of languages which focus more on practical usable objects which make real work go faster and easier for programmers.
Reduced Hype i.e. social death is a natural consequence of all these problems but it must be mentioned in light of Sun's super star burst hype promoting Java as the best computer language ever. Although Sun died, the hype did get Java into many places Smalltalk should have been in. Had anyone bothered to rewrite Smalltalk from an interpreted language into a compiled language then counter advertised that Smalltalk was the best, it might have regained market momentum. Of course there is lots of false hype such as promoting the need for profiling before deciding on another language in an application where simple math proves Smalltalk is literally deadly.
There are several interesting things still going on in Smalltalk. Making it easy with a linker window or documentation to access C++ libraries like OpenCV would help.
Smalltalk isn't dead - it's just living slowly.
The year is 2013 and Smalltalk is very much alive.
Pharo-project is doing a great job of increasing its popularity. Watch this space.
Summary of possible or alleged reasons why Smalltalk dropped in popularity:
- Was too expensive (USD 5,000 for VisualWorks Smalltalk by 1990).
But USD 199.95 Smalltalk/V286 March 7, 1988
- Ownership possession was volatile
- Equipment at the time couldn't handle it
- C++'s momentum (since 1990)
- Java's momentum (since 1996)
- It's "scripting" nature tends to turn off big organizations
- Lack of security: A rogue programmer can change the behavior of basics objects and destroy the system.
- Doesn't use an AlgolFamily-influenced syntax style making it seem "strange"
- There were no open source Smalltalks to be used as learning tools for university students or for professors to teach the language at university courses (except for Smalltalk/X since 1998).
- Fragmented industry. Not all Smalltalks were compatible, which was true also for C. Developers needed to perform manual tweaking in order to port from one environment to the next. This was resolved almost entirely in Java, which also was open source.
- Lack of proper multithreading at a time when Sun was proposing computers with multiple CPUs.
- It's an ImageBasedLanguage, and developers have voted against that with their feet.
- Lack of multi-paradigm constructs such that it tended to only attract OOP extremists.
The rumors of my death have been greatly exaggerated.
Why is Smalltalk dead? Or rather why is the SmalltalkLanguage
dead as far as the mainstream is concerned?
There are still people getting work done with Smalltalk and starting projects with it, but Smalltalk isn't as successful as Java, C# or VB. What went wrong?
Discussion below seems to center on what went wrong since 1995. But I was wondering well before 1995 why Smalltalk didn't catch on with the mainstream. Why wasn't it popular in 1990 or earlier?
That's easy. Smalltalk was its own operating system and took over the computer. When Windows came out, there was no way to run it under Windows. You could buy other development environments in a computer store, go home and install them on your Windows machine, even if they ran under DOS. You could not do this with Smalltalk. I remember developing for Momenta pen based computer in 1992 that used Digitalk Smalltalk. Momenta didn't make it for several reasons...one reason being that it was a Windows wanta-be when windows was new and coming on strong and so didn't have a chance of main streaming. (ignoring the fundamentally flawed Momenta battery pack quickly got to the state of not charging well because its batteries, unlike all real lap tops, charged in lock-step, being in strict series with attendant unintended consequences)
Think of the devices that were commonly found in the data center (let alone on anyone's desk) in the 80s. GreenScreen terminals, PC's with CGA graphics (if that), etc. 640x480 screen resolution was a luxury back in the 80's, and most displays that did have such resolution were monochrome. Mainframes/minis and associated dumb terminals were still rather popular in the enterprise.
Implementing SmalltalkLanguage on computers of that vintage simply wasn't practical; the work that TimBudd did nonwithstanding. If you wanted to run Smalltalk, you needed to purchase an extremely expensive workstation from TektronixInc or similar. We're talking five figures apiece (US), in 198x money.
Few businesses were willing to shell out that kind of money just to support a programming language - especially one which was such a radical shift from what most enterprise software of the time was written in. ObjectOrientedProgramming itself was controversial at the time. (The path of least resistance, of course, was CeePlusPlus - something that was compatible with what they already had, was widely available, and didn't require buying new computers everywhere).
[''Historically, languages catch on when they're (a) free or very cheap (e.g. Turbo C and Perl) and (b) can be used on readily available platforms (C again).
Smalltalk circa 1990 strikes out on both counts.'']
Makes sense... but what about... (moved to IsSmalltalkWithoutGraphicsAnyGood
Smalltalk didn't get into the mainstream due to one very large event - the merger of ParcPlace
and Digitalk in 1995, and the ensuing madness. 18 months were wasted on a failed merge of the products (i.e., no new releases). Then VSE was put on ice, and VisualWorks
was owned by a much smaller company that had lost faith in Smalltalk - and proceeded to lose a boatload of money trying to sell Java tools. Result - another year of very little progress. VW 3.0, in 1997 was a nice release, but the changes were not interesting to a mainstream audience, and the product lacked all the network libraries that it really needed. It wasn't until the 5i.3 release from Cincom in January of 2001 that a release of VisualWorks
shipped that had all the requisite pieces to be interesting. In the meantime, with the main Smalltalk vendor killing itself, IBM had gone full bore to Java.
The problem was that the development community made an equivalence (in mindshare terms) of Smalltalk = ParcPlace
. And when ParcPlace
) committed suicide, that mindshare went elsewhere. There were no releases of VisualWorks
(or its successors) that were really able to compete on an even footing (technically) with Java from 1995 - 2001 - for all intents and purposes, to the outside world, it looked like the product was standing still.
That will kill any product. Smalltalk hasn't been rejected by the development community; it was never really offered to them. That's changing slightly now, with the resurgence of VisualWorks
, the appearance of DolphinSmalltalk
and SmalltalkMT, the new work on GnuSmalltalk
, and the widespread interest in (and work on) SqueakSmalltalk
NC gets 1300 downloads per month - which demonstrates a pretty healthy interest in Smalltalk. This page makes a lot of assumptions, but they are all technical - and the problems Smalltalk had starting in 1995 had absolutely nothing to do with technical issues, and everything to do with business issues.
James A. Robertson, Cincom Smalltalk Product Manager
Your description seems to overlook the elephant in the room - IBM's decision to dominate the Smalltalk marketplace with IBM Smalltalk and VisualAge (at the time, "VisualAge" was synonymous with "Smalltalk" - there were no other VisualAge products). The merger of ParcPlace and Digitalk was forced by IBM's utter dominance of the market - the development community didn't matter. The entry of IBM was, in turn, strongly influenced by Digitalk's self-defeating destruction of the Digitalk/EnvyDeveloper combination. That combination was selling strongly in multiple business-oriented markets (which is how it got on IBM's radar screen). The native look-and-feel that Digitalk offered and the rock-solid repository that EnvyDeveloper demonstrated combined to create a product that represented a genuine strategic threat to a number of business market suppliers, including IBM. The "client-server" and screen-scraper markets (using PC's to replace 3270's in RDB-centric applications) were particularly vulnerable - witness the Easel Workbench fiasco, and subsequent replacement with the original Enfin "Smalltalk". Meanwhile, ParcPlace was being pushed further and further into the backwaters by its resistance to a native look-and-feel. Digitalk got scared of OTI's control over its destiny, and chose to poison the relationship between OTI and Digitalk. OTI responded by selling itself (along with its own competing virtual machine) to IBM. All three Smalltalk vendors - ParcPlace, Digitalk, and IBM - killed the commercial success of Smalltalk by charging excessive prices, attempting to apply coercive licensing terms, and demonstrating colossal arrogance towards virtually anyone with money to spend. I do share the conclusion that the problems with Smalltalk "had absolutely nothing to do with technical issues, and everything to do with business issues". I am reminded of the manner in which Steve Jobs and John Sculley managed to single-handedly squander the compelling business advantage the Macintosh look-and-feel offered over the green-screened doorstops being purchased by the ENTIRE business community at the time, thereby handing the opportunity to Bill Gates who was only to happy to oblige. With the benefit and wisdom of 20-20 hindsight, it seems pretty clear to me that both were superior technologies, created by XeroxParc, whose obvious and apparent benefits were squandered by astonishingly inept, naive, and self-destructive business decisions.
From James A. Robertson, Cincom Smalltalk Product Manager:
Nope. In 1995, ParcPlace
had something like 40% of the Smalltalk market, and was profitable - more importantly, our business was growing. IBM's presence in the market had actually helped PPS - by validating Smalltalk as a solution. After they entered, sales jobs got easier, not harder. What drove the merger was paranoia and stupidity. HP was close to buying Digitalk and there were (utterly unfounded) rumors that Microsoft was bidding for them. ParcPlace
bought Digitalk because it feared those things. Those of us in sales at the time had this kind of thought: "How would that be a bad thing?". Management didn't see it that way. They panicked, and bought Digitalk. Digitalk was only too happy to be acquired, since their management team wanted that result (acquisition, that is).
Our recollections of that period are probably not too far apart, perhaps we just saw the same market from different vantage points. I certainly agree that IBM's entry helped PPS by validating Smalltalk. By late 1995 (when I joined IBM), we at IBM faced the dilemma that if we crushed PPS and Digitalk, the market would view Smalltalk as a proprietary solution. There was also concern that such a move would be viewed as predatory - still a concern in the 1995 IBM culture after the problems IBM had in the eighties. We in the OTP therefore embraced the "rising-tide-lifts-all-the-boats" model, and enthusiastically attempted to support both PPS and Digitalk where we could. The marketing dweebs who managed the "VisualAge" brand blind-sided all of us (but probably not upper management) by slapping a "VisualAge" brand on the IBM C++ product - resulting in a product that was an utter disaster. It became clear that "VisualAge" was viewed by the business side as a gui-builder. IBM walked away from the "IBM Smalltalk" brand - it didn't even have a SKU - and consequently killed its Smalltalk business. It then further diluted the dwindling appeal of the "VisualAge" brand by using it in the Java world. Since nobody in IBM understood how strong the IBM Smalltalk technology was or what it was good for, nobody knew how to position VisualAgeJava - and the entire line died.
I am under the impression that PPS dominated the "scientific" market, defined primarily by "unix and macintosh users", and that Digitalk dominated the "commercial" market, defined primarily by "pc users". The principle differentiators in the commercial market were native support for the Windows LookAndFeel? and EnvyDeveloper. IBM's entry therefore crushed Digitalk much sooner than PPS. I therefore agree with your estimate of 40% for PPS in the 1995 Smalltalk market - I suspect IBM had 40-50%, Digitalk had about 5%, and everybody else carved up the remnants. -- TomStambaugh
Perhaps language adoption is dependent on two things:
- Backing of a large corporation that makes successful applications. Java, C#, and VB all have the support of a major company. Smalltalk and Squeak, backed by Xerox and Disney respectively, didn't have enough big name clout to make adoption possible.
- The language helps solve appropriate tasks. This explains the success of PerlLanguage (quick and dirty system admin), PythonLanguage (Object-oriented rapid development).
I think a much more useful question is: Why isn't
Smalltalk dead? Given the huge disadvantages of using an unpopular language, why does anybody
still use it?
When I asked myself that question a few years ago, I didn't know the answer - but I was curious enough to go out and try Smalltalk for myself. Today, I could
give you an answer - but you'll learn a lot more if you try it out and find your own.
Smalltalk is kept alive by people who favour pure OO image-based languages. Its strengths are also its weaknesses. The environment makes it hard to work in large mixed-ability teams without good tool support. And blocks (whilst making many useful techniques easy) aren't as powerful as higher order functions. By this I mean that everything you can do with a block can be done with a HOF but not vice versa.
HOFs (HigherOrderFunctions) and blocks are two different beasts. Blocks capture an environment in the form of an object with a single method (
with: in SmallTalk), which is similar to closures. HOFs are functions that have functions as parameters. Compare the following (SmallTalk vs. HaskellLanguage):
^ aList select: [:n| n > value].
= filter (\n -> n > value) aList
In this example both
select: are HOFs, while both
[:n| n > value] and
(\n -> n > value) are closures (aka blocks).
Aside from Ruby, Smalltalk and Smalltalk derived languages like Squeak, SmallScript
and Kew what other languages have blocks?
Well, the whole Lisp family and the FunctionalProgrammingLanguages, although the syntax is different.
"And blocks (whilst making many useful techniques easy) aren't as powerful as higher order functions. By this, I mean that everything you can do with a block can be done with a HOF but not vice versa."
In Smalltalk, a block is just syntactic sugar for creating a function. And a function is just an object with a "call" method. Blocks can be passed to and returned from methods and to/from other blocks. Blocks and methods that take or return blocks
are HigherOrderFunctions. So what exactly do you mean that "everything you can do with a block can be done with a HOF but not vice versa."?
Blocks, as far as I'm aware are always anonymous, HOFs give you a choice about naming them.
No, A HigherOrderFunction is a function that takes a function as parameter, or returns a function as a result. Whether those parameters/results are anonymous or not has nothing to do with the higher-order-ness of the function that takes/returns them.
Also, blocks can be named. They are just objects, and so a reference to a block can be stored in a variable. They are also named by the parameters of methods that take blocks as arguments.
I heard the opinion voiced several times (from co-workers in one of the former Smalltalk companies) that if they had only pushed Smalltalk more in the direction of Internet applications back before Java became real, it might have taken off. Sun did a lot of things wrong with Java but one thing they apparently did right was keep their crosshairs on that Internet space.
I don't get it. Java's idea for the Internet was applets. A bad idea, never took off. Now it's just another server technology. This is not to say that Smalltalk vendors did not commit suicide, they clearly did. And the Smalltalk gurus never understood the Net until too late. And Sun's marketing was clearly superior. But Java and the Internet?
Sorry, I didn't mean to imply that Java has taken off on the Internet the way Sun people probably hoped. But Smalltalk had the "every object heaped together in the image" model, while Java forsaw that they would need packages, access protection, etc. Smalltalk used a VirtualMachine
with internal compilation to ByteCode
s, while Java forsaw that it was in everybody's interest to have one standard
set of bytecodes to be shared among all platforms. I guess because they were thinking "Internet", the Java folks made various design decisions for their language and tools that the Smalltalk folks didn't make. It turned out that these decisions made Java practical for lots of things where to use Smalltalk would have required programmer ingenuity.
Perhaps it was this requirement for "programmer ingenuity" that killed Smalltalk? Managers always seem to be interested in technologies in inverse proportion to their requirement for programmer ingenuity. If the technology you're promoting doesn't require ingenious programmers or is marketed as such, then you can sell it to the kind of conservative mainstream organizations that believe in PlugAndPlayProgrammers.
Why do you think that Smalltalk - a language designed to teach programming to youngsters - requires more "programmer ingenuity" than does Java?
IMO, it is because nobody could justify its "unusual" features without a kind of YouJustDontGetIt
haughtiness. IOW, bad marketing. Some have accused Smalltalk of being MentalMasturbation
has an essay about what makes languages popular: http://paulgraham.com/popular.html
Caveat: Java is popular despite being completely ridiculous to write quick programs in.
See also http://members.aol.com/kgb1001001/Articles/CLEVER/clever.htm
I don't understand what link my article has to this topic. Could whoever posted it explain this? -- KyleBrown
As a former Digitalker, I recall VSE having the per unit sales lead while Parc had the revenue lead, primariliy due to PP's charging for run time licenses. The failed merged product and subsequent killing off of V & VSE left many users with only one place to go, IBM. Moving from VSE to VA required less effort than VSE to VW. Regarding OTI and Envy, VSE had an adaptor layer that would allow you to use the source code repository of your choice. Many developers objected to the lack of check-in/out and the concept of class owners enforced by Envy. VSE gave you a choice. In the end, it was wishy-washy, scared management that abandoned Smalltalk and lead to the demise. Requests for multi-threading, networking, HTML support, etc., were too little to late. Now if Cincom would only do something with V/VSE...since it was considered a "toy" for mac, win, os/2 by VW users, why not convert it to a .NET managed language?
At any rate...Good to see Jim Robertson is still keeping it real. Thank you for your tenacity Jim!
The UniversityOfWashington ComputerScience
department has a languages class, with a problem set or two in SmalltalkLanguage
. Most students in this class conclude that SmalltalkLanguage
is a toy language, not suitable for real programming. Why? Because the development environment does not provide for any code security. Any user can change any code in the system.
Are there any SmalltalkLanguage
Known reasonable starting points:
Unknown (to me) but free.
TomStambaugh (a drive-by submission)
- are free (or at least very cheap for educational institutions) Yes, Cincom and Squeak, see below
- have easy-to-get-started-in development environments Yes, Cincom and Squeak, see below
- have useful error messages Yes, Cincom and Squeak, see below
- make beginning programmers confident that their code won't change when their backs are turned Yes, Cincom and Squeak, see below. Your image is your own. Any "code security" system can be abused.
- have good input/output Yes, Cincom and Squeak, see below. "Good" is in the eye of the beholder, however.
- allow students to easily mix/match or copy/paste code between different projects Yes, Cincom and Squeak, see below
- allow problem sets to be automatically graded (or at least automatically compared to each other, to prevent "cheating") Probably not -- that's an interesting question. Sounds like a good starter problem to me.
- have easy-to-use RefactoringTools ?? See the RefactoringBrowser, which works in most Smalltalks.
- have easy-to-use TestingTools SUnit, the origin of all modern testing tools, is written in Smalltalk.
- have a short tutorial available on how to write a useful program, aimed at ComputerScience majors? Yes, in abundance. Try google.
This comment sould probably be under the topic of Why ST sould not be dead (or dying, which I don't believe it is, but I am addressing comments made above.
At the risk of creating a firestorm, nowhere in this discussion list have I seen reference to ST’s didactic usefulness. It has been my experience ( I can be more specific if needed) that there is no better way to learn the OO paradigm than to learn ST. In my opinion making the paradigm shift doesn’t just mean that one can create objects (classes) that send messages. It means (in my opinion) that before anything else, one sees programming an application as the process of creating a set of collaborating objects (classes) that together fulfill the functionality required of the application. The complaint above that only 'OO purists’ are still using ST has a grain of truth if ‘OO purists’ is understood to mean one who has made the paradigm shift and is ‘thinking objects’. It is my experience (from coding and application classes I have seen in Java and C++) that programmers of other modern, OO based languages do not create or use objects in the same way as an 'OO purist'. They have not learned to ‘think objects’. For this reason alone, ST is an extremely valuable programming language.
Bill Kohl, Houston, TX
This is my own personal experience, not a claim to universal applicability.
I have been Smalltalking since the mid-1980s. Wonderful personal language - my favourite is Pharo. I use it for prototyping and research. It is the lack of separation between the development environment and run-time which makes it perfect for exploratory software development. Run code - and explore the complex objects you have created as your go. Smalltalk is Lisp++. [See WhyIsLISPDead :)]
I can never recommend Smalltalk for corporate applications - too small a talent pool for support. In most corporate environments the first question is "How do we support this". If the application is developed in house it will be Java, .NET or perhaps LAMP. We can go to the market place and always quickly get developers with these skills. If the application is developed externally, how can I guarentee my supplier will continue if they lose key personnel.
Even in the middle ground of small specialist systems development I believe Smalltalk will struggle. The thousands of open source projects in Java are available for analysis, modification and adaptation. Many frameworks, tools and plug-ins available, such as Eclipse. The Java eco-system provides a leg-up that the minuscule Smalltalk community cannot match.
Smalltalk - too good to die, not enough mass to thrive.
My suggestion to the Smalltalk community is to find some niches which are really Smalltalk friendly and provide good tools (and documentation and training guides) in this space. I would focus on assisting in teaching software. Convince the teaching communities they need to teach programming, not specific languages, and that Smalltalk is the ideal tool. Squeak has targeted primary schools and I hope they can continue to grow their community. I believe Pharo should look at the tertiary education market. Both are suitable for the secondary education market - perhaps with a transition plan for moving students from the "naive" Squeak style to the more mature Pharo style (with apologies to the Squeak community).
, Sydney, Australia.
Execution speed is/has been an issue. The degree of dynamism is too great to allow much in the way of static optimizations. Source management is also an issue. I saw the same thing in older Forths based on blocks and FSAVE - each developer builds up an environment in their local image which greatly supports heroic programming but creates a barrier to entry for other developers.
Pharo certainly shows that there's life in the old dog yet, though.
The idea of each delevloper building their own environment reminds me of something in ThePsychologyOfComputerProgramming
. -- JohnFletcher
See also: FutureOfSmalltalk