Why Is Smalltalk Dead
Why Is Smalltalk DeadSmalltalk 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 Smalltalk's early inability to deliver working applications for sale by developers - one had to sell a Smalltalk platform along with the application, leaving little profit. Another 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.
A motivation for mis-development is Smalltalk idolatry, putting Smalltalk on a balloon instead of on the ground where people live. The thought that Smalltalk was in itself the next big thing instead of applications that people use. For example web browsers are probably the single most used computer program - yet Smalltalk doesn't have a built in browser that most newbies can find. List all the other programs people use or want to use from a sound recorder to Pixar quality animation and Smalltalk may have tools to build it but Smalltalk doesn't come with built in highly useful applications beyond demonstration toys that go nowhere. Nor is there much of an external library. You can find lots of free open source software in C++ that does useful things but you can't even buy a library of Smalltalk goodies that will get you far toward your goal - the demo apps remind me of a math teacher's statement that in the USA roads are mostly all connected, they go somewhere - but in Russia most of them are dead ends. Smalltalk's core may have been connected internally but applications suffer the lack of a unifying vision. The original vision of Smalltalk as a replacement for the operating system got lost. You could only address 2GB files, not 2TB files and many other peripherals were unsupported. Some versions had lack of attention to keeping things simple.
A more recent path of mis-development has been attempts to make Smalltalk tools for kids such as EToys to try to hook them at an early age on a platform that has not adequately kept up with state of the art application development, failing to make it easy to control hardware so it could have been used for microprocessor work, and failing to include it in educational projects like Raspberry Pi. To be useful a tool must continue extending the state of the art instead of doing it once.
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 a real time application like self driving vehicles where simple math proves Smalltalk is literally deadly.
There are several interesting things still going on in Smalltalk and derivatives but some see Smalltalk as a place to develop thought objects into new stand alone languages such as Scratch. Smalltalk needs a new vision that includes full support of all peripheral hardware and applications that sell computers with simplicity so kids can use all of it plus speed that makes it safe for real time. If anyone wants to revive Smalltalk, start looking at what cutting edge scientists use for Artificial Intelligence such as Scala, R, Hadoop, and how people are extending Smalltalk to develop a free clean powerful do-all language.
Smalltalk isn't dead - it's just living slowly.
The year is 2014 and Smalltalk is very much alive. http://pharo.org/ is doing a great job of increasing its popularity. Watch this space.
Summary of possible or alleged reasons why Smalltalk dropped in popularity:
The rumors of my death have been greatly exaggerated. - MarkTwain
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) - JKS
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 (PPD, ObjectShare) committed suicide, that mindshare went elsewhere. There were no releases of VisualWorks from ParcPlace (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. VisualWorks 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).
See WhoIsDougPollack.
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:
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.
-- AdamSpitz
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):
selectGreaterThan: value
^ aList select: [:n| n > value].
selectGreaterThan value
= filter (\n -> n > value) aList
In this example both filter and 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 ByteCodes, 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.
PaulGraham 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!
A Bitter-Digitalk-Bigot
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 environments that:
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).
Alan McNamara?, 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.
TWW
About the recurring issue of source code management, see CuisSmalltalk. It's a small fork of Squeak. It uses a Moticello variant + Git & GitHub to do distributed source code management.
Distributed code management in smalltalk.
The main focus is simplifying and reducing the core image, especially the Morphic system.
The idea of each developer building their own environment reminds me of something in ThePsychologyOfComputerProgramming. -- JohnFletcher
This article does a pretty good job explaining why Smalltalk didn't succeed in the marketplace. And while I wouldn't say Smalltalk is "dead", per se, it is currently occupying a niche, like so many other languages that it keeps company with (eg, Vala Mal Doran, Julia, HaXe?, Ada, Rust, and Racket).
The article is an historical account. It doesn't really say anything about the future. I suggest that we may regard Smalltalk (and, in particular, Amber) as *a new programming language*, one that was invented just a few years ago and is well-represented by PharoSmalltalk and Amber. When viewed in this manner, Smalltalk enters the ring in competition with all the other "modern" languages that are vying for developer attention. What Smalltalk then needs to focus on, moving forward, is:
Ash: You still don't understand what you're dealing with, do you? Perfect organism. Its structural perfection is matched only by its hostility. Lambert: You admire it. Ash: I admire its purity. A survivor...unclouded by conscience, remorse, or delusions of morality.Richard Eng
Squeak probably has more of a chance than Pharo, but the likelihood of a grand consolidation into "ONE Smalltalk" is almost nil. What distribution is going to commit suicide for the benefit of another? What user of a favourite distribution is going to give it up to support consolidation on a Smalltalk he or she doesn't like?
A better goal is strong interoperability, so that various Smalltalks become a means to collaborate rather than isolate.
This is the same problem with the desktop Linux market. Too many distros to choose from. What distro is going to commit suicide for the greater good?
For this reason, Smalltalk also needs a major corporate backer. But Google, Apple, Microsoft, Facebook, and Oracle are out. How about IBM? However, IBM abandoned their own Smalltalk years ago, and at any rate they don't have much clout in the developer community.
See also: FutureOfSmalltalk, HowToSellGoldenHammers, SeriousVersusScriptingLanguages
EditText of this page
(last edited December 18, 2014)
or FindPage with title or text search