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.)

http://www.slideshare.net/yannmonclair/13YannDMonclair (ESUG 2008)
http://gemstonesoup.wordpress.com/2007/10/03/case-study-featuring-jpmorgans-kapital-and-smalltalk/
http://www.cincomsmalltalk.com/blog/blogView?showComments=true&entry=3261775747
http://www.cincomsmalltalk.com/blog/blogView?showComments=true&entry=3272163751
http://www.cincom.com/pdf/CS040819-1.pdf
https://secure.cwheroes.org/briefingroom_2004/pdf_frame/index.asp?id=4909 (BrokenLink) for mention of

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.

Ethernet was pushed by many companies, but most especially Sun Microsystems with BSD Unix with TCP/IP, which ended up winning a vicious LAN war and made ethernet ubiquitous.
Postscript was pushed very well indeed by Adobe (and Xerox doesn't get credit for Postscript anyway)
WIMP was pushed by AppleMacintosh, and then by MicrosoftWindows.

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").

C++ got especially popular because Microsoft pushed it. C++ originated on Unix, but it didn't get particularly popular until MS. It also has been viewed as a better version of C, which was already tremendously popular. Unix obviously has many problems by today's standards, and although it still has strengths relative to other OSes, they have been copied just sufficiently to make them less obvious to non-Unix fans - but it succeeded because, amongst other reasons:
(1) it was the first relatively portable OS, which made it attractive to port to new CPUs rather than designing a whole new OS,
(2) it was cheap,
(3) not controlled by a single vendor as MS does Windows,
(4) it was seeded into universities, where students graduated into industry and then selected it because they were familiar with it and liked it (similar to what contributed to the success of Apple),
(5) it offered capabilities such as multitasking and virtual memory that other small operating systems did not,
(6) it was selected by the DOD as the initial host for Internet technologies following BBN,
(7) it offered some powerful technologies relative to other OSes (a wide array of regular expression tools; pipes and components suitable for use in pipes; scriptable shells),
(8) widespread access to source code

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:

(1) accident (first to do something)
(2) political economics
(3) politics
(4) politics
(5) technical (smaller than other OSes with these capabilities)
(6) politics / accident
(7) economics (you can build useful libraries on top of any OS, so long as the OS is popular enough to begin with to justify the effort)
(8) politics

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).

[I thought I remembered TeX having outline fonts, long before PostScript, and I don't remember troff doing that -- am I mistaken about TeX? I don't remember troff having anything comparable to TeX's ability (through glue) to adjust leading and page breaks. Scribe was reasonably well-accepted outside the unix community. It seems to me that the relationship between troff-style document production and desktop publishing is comparable to mainframe report generation vs spreadsheets. My recall of the early unix years is polluted by my years at Digital using RT/RSTS/RSX/VMS -- I don't remember unix taking hold until the workstation market exploded in the early 80s. Surely Sun is responsible for most of Unix's availability, not to mention IBM's endorsement in 85 with AIX. I think the main reason that Unix was so widely accepted was the decision by AT&T and Sun to make it essentially free -- the same force that also drove X-windows and C++. Technical superiority (or even suitability) played virtually NO role.]
I don't mean that Knuth didn't innovate; he certainly did. Troff did not have outline fonts; nor did the troff-related tools have any font-creation tools, let alone something as capable as Metafont. TeX's boxes and glue are in fact a superior approach to layout compared with every other approach I've ever heard of, before or since. And TeX/LaTeX math layout is superior to eqn/troff.
But those are refinements. I just mean that lots of technical books were published with fully computerized typesetting via troff before Tex came out (also before Scribe; Brian Reid's Scribe PhD thesis was 1980, and its big innovation was separating out logical document structure -- it lead directly to SGML). It was also used for lots of lighter-weight purposes, like many people's resume's. :-)
It's true that Unix popularity didn't explode until the workstation era, because workstations meant a huge proliferation in quantity of computers that before would have been minicomputer-class price and power; that explosion wouldn't have happened without the previous boom of Unix popularity on minicomputers.
Sun certainly helped with Unix popularity, but the PDP 11 and VAX lines arguably helped even more. And a bunch of smaller players also helped.
I already cited cost as a driving force, and that technical merit wasn't the primary reason, so I feel comfortable rejecting the idea that technical merit played "NO role". That's unnecessary hyperbole. It played A role, but it wasn't primary.

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

The dedicated RealProgrammer can write ForTran code in any language.

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

The network affect - it didn't have the fantastic niche specialty and good pricing with which to "cross the chasm" into widespread use.
Database connection was difficult.
- For much of Smalltalk's early life, database connection wasn't an issue - the standalone RDBMS is a relatively recent phenomenon. In the bad old days before RDBMS's were popular and widely available, many programmers looked to programming languages and their toolsets for database functionality - hence the popularity of products such as dbase and the like. Smalltalk, if marketed correctly, might have been able to compete there. Certainly Smalltalk had numerous advantages over early C++ implementations in this regard (C++ of this era didn't have the StandardTemplateLibrary or anything else like it). A more likely reason for Smalltalk's lack of acceptance in corporate America--especially during the 80s and early 90s - is its rather stringent graphics requirements (and the expensive workstations that were implied). Smalltalk was a non-starter on a GreenScreen terminal, and it was a non-starter on any bitmapped PC display until VGA came along. Plus, it was expensive, and as you allude to, it didn't play well with others.
- First, databases. I had not thought about Smalltalk coming before the popular RDBMS's. Interesting idea about Smalltalk being a sort of database. But could there have been multiple users?
- Second "if marketed correctly". I agree with you there. Since Smalltalk was not designed with a business use in mind, a business use had to be invented. Inventing such a business use (i.e. marketing), if done correctly, might have helped. Perhaps it is easier to be driven by a "we gotta meet the customer need" focus than a "we gotta sell this product" focus.
- But, you got me thinking. Other than having programmers love to program in it, Smalltalk did shine at one thing. Making visual tools. The designers of Smalltalk built all of Smalltalk's visual tools in itself, and so had to evolve the design to support themselves. In 1991, I made a visual code generator with Smalltalk that I could not have done in any other language (except LISP, on a $100,000 LISP machine!!). Hmm. I just looked - I said this already two lines down - Smalltalk was great at CAD. How would you market to CAD builders? What if you were a CAD builder. If one of the Smalltalk venders had done double duty as a CAD builder, perhaps they could have flourished that way??? It sure is fun to Monday-morning quarterback!
Awk and perl were better for short scripts for manipulating text.
Smalltalk was great at writing CAD programs.
But normally you don't write CAD programs to use in house. You write them to sell.
And Smalltalk is not good at writing apps to sell.

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?

No reason in an absolute sense (except that it's harder to smart-up than to dumb-down), but pragmatically, XML won, everyone knows it and uses it for interchange, whereas most people have never heard of Smalltalk and aren't interested in accommodating Smalltalk. See also Sony VHS vs Betamax. Everyone agreed VHS was inferior. But it won.
But at least people realize that Betamax was better. Bragging rights have got to count for something.
Looking around the wiki, I think Smalltalk does have realized bragging rights; it's admired even by many who don't actually use it.
- IfSmalltalkIsSoGoodWhyDoesNobodyUseIt?

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.

For your own projects, no problem, go for it. Convincing the rest of the world to do something, however, is always an extremely difficult to impossible proposition.
Sure, but if you know ST then it should be simple to explain why HTML sucks. Compare it to ST. :)
For the purposes you have in mind, yes. Most of the world just wants plain text plus the ability to do minor markup like highlighting, as with wiki markup, so they don't see the issue with HTML.

I'm pretty certain you could write a little package to verify the security of the objects you export, to keep them nicely passive.

In an ideal world. In the real world, Microsoft immediately embraces any given technology, extends it to include Direct-X controls that can do anything to a Windows system, and makes sure it can be transmitted as a virus over the internet via web pages and emails.
- This would happen in Linux/GNU too, if it were a popular OS. There's probably a "DirectX is not DirectX" out there somewhere, or there would be. Nothing is secure, except the things that are unpopular.
  - False. This is Microsoft propaganda. (Except in the vacuous sense that nothing at all is ever perfectly secure - which isn't a very interesting point.) All variants of Unix have been far more secure than all variants of Microsoft Windows, and there are well known OS design reasons, and Microsoft business reasons, for why. This has all been hashed out over and over. This is not a matter of opinion of Unix fanatics versus Microsoft fanatics, it's a matter of Microsoft and its apologists trying to downplay one of Microsoft's worst weaknesses.
  - Although this kind of thing has been obvious to us operating systems programmers from the beginning, it's not obvious to the business world. Or wasn't in the past. But now, see these links I just found with a bit of googling (thanks, I had meant to keep some of these on hand and never got around to it):
    - Microsoft a threat to National Security: http://www.astreet.com/article.php?sid=262&mode=thread&order=0&thold=0
    - Debunking "it's just that Windows is more widely used": http://www.theregister.co.uk/2003/10/06/linux_vs_windows_viruses/
    - Linux is a hostile environment to viruses: http://librenix.com/?inode=21
  - And note that most web servers are running Unix or a variant like Linux; this is not a minority operating system at all.

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.

--BenAveling

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.

SoftwareEngineeringCriticism

See: TooAdvancedForItsOwnGood, WorseIsBetter

CategorySmalltalk