Smalltalk Isa Failure
Smalltalk Isa FailureBefore reading this remember that WorseIsBetter.
There is no shortcut to good software. The SmalltalkLanguage is largely a failure. C++ is not the magic bullet, Java is not the magic bullet and Design Patterns are not the magic bullet. But, with the exception of Smalltalk, it's possible that they may all be weapons in the arsenal.
If this stings, it is only because there is a bit of truth in it.
I think we should all be able to learn something from Smalltalk - things that could be relevant to ExternalAndInternalDesign and other places XP doesn't reach today.
"X is a failure" is propaganda, designed to play on the emotions. Failure at what? Specify the criteria and then we can judge. But just as one can show that "Smalltalk is a failure at Y", one can show that "Smalltalk is a success at Z".
Tool vendors use DesignStarts as a metric. At Smalltalk's height there were still ten times as many DesignStarts in C++ as Smalltalk, hence vendors suffered. Right now the winner has got to be VisualBasic, a golden egg if not a silver bullet. -- WardCunningham
Methodologists like me use design completions as a metric. At Smalltalk's height, there were still more design completions in Smalltalk as in C++, despite the larger number of C++ starts. That made Smalltalk a winner. These days there are so few Smalltalk starts that the number of completions is almost moot. The ratio of completions to starts is still astonishingly high. --AlistairCockburn
When you say, "design completions" are you talking about implementations? Because design and coding aren't related other than that the code is an implementation of the design. One can't "design in" any particular language any more than one can "compose a symphony in" any particular musical instrument.
Part of this is that methodologists - and XP advocates - continue to mouth the blatant stupidity that smalltalk is too hard for the average developer. And they can handle Java and its (how many reserved words now?) syntax? It is well known amongst the XP elite that Smalltalk is 3x to 5x more productive than Java; it would help if they did more than mumble this fact periodically.
Quiz questions for the audience:
1) How many Java tools that existed are no longer maintained and/or sold? 2) Same question for Smalltalk
3) Smalltalk has an ANSI standard 4) Java is fully owned by Sun - and gosh knows what would happen if they went bankrupt. Before you say "that could not happen", ponder DEC.
so, which language is a safer long term choice based on actual data instead of "conventional wisdom"?
--James Robertson
Am I right in guessing that "DesignStarts" means "number of times people had to throw away what they'd got and start over"?. If so, that's a really interesting metric. I know developers (unfortunately) who like tools that encourage more DesignStarts, because then they can get the latest buzzwords on their CV every six months and/or blackmail their bosses over maintenance, instead of delivering good stuff. --RichardEmerson
I took DesignStarts to mean the number of projects started with the tool [language].
Design versus implementation. See above. Perhaps a new page is called for here...
SmallTalk is a roaring success:
Is Ferrari a failure? Compaq? CBS? Burger King? Avis? Smalltalk exists. People use it effectively. It isn't number one. The allusions above to quality products or services which are not the number one in their field suggests that perhaps "failure" is too strong a word.
There's certainly value of a high quality, profitable brand which is not the brand leader. The only question for me is whether Smalltalk is now profitable enough to have "bottomed out" on design starts.
I think one should also consider that many aspects of Smalltalk have been harvested for use in other languages and systems. A great deal of Java's OO was influenced by Smalltalk for example.
It seems like well-defined modules, components, and name-spaces were missing from the original Smalltalk-80 (and from Squeak today). How have modern commercial Smalltalks addressed these issues?
The keyword in the above is well-defined. The Smalltalk community followed reasonably well-defined packaging conventions during the 80's ("fileouts"). The language itself made it trivially easy to distribute code using this mechanism (each fileout was a file, something like a self-extracting zip, that allowed the packager to include code that ran upon subsequent filein). In the late 80's, Object Technology International (OTI) released Envy/Developer, which included a virtually universal module, component, and method sharing mechanism. Again, because the SmalltalkLanguage is so inherently flexible, the OTI approach was easy, effective, and compatible with all the then-extant Smalltalks. IBM formalized aspects of this in VisualAge/Smalltalk. The name-space "issue" was never an issue in Smalltalk, for a variety of reasons. Various vendors have supplied various mechanisms for supporting multiple name-spaces in Smalltalk. They all work -- none of them are particularly widespread because typical Smalltalk code doesn't need it. Rather than ask "How have modern commercial Smalltalks addressed these issues", a better question might be "will the modern commercial alternatives to Smalltalk ever support these as well as Smalltalk did?" -- TomStambaugh
Some people have held up successful elements of Smalltalk as evidence that it is not a failure. They are wrong. There is no dispute that Smalltalk had (and still has) some good things in it. But the entire package that is Smalltalk also has some bad things in it that have hung around for far too long. These things are the reason for Smalltalk's failure.
A major one is the cognitive dissonance in Smalltalk's syntax. It does things in weird ways that make it hard to learn and to read the language unless you put in a lot of effort to become an initiate. This is particularly surprising because the underlying engine of a byte-code message-passing vitual machine should allow a more human friendly syntax to be used. One problem is that there are too many odd symbols with particular meanings. ':=' is not too bad but things like ',' and '^' get confusing. In 1980 we needed to save every byte so we made source code compact. Nowadays we no longer need to do this. Also, every child learns something called algebra in public school but when they meet Smalltalk, they see something similar to algebra with lots of symbols but it doesn't work the same way, i.e. precedence rules. This creates cognitive dissonance. The same problem affects the popularity of Forth which really should have completely displaced C as the high level assembly language. Related to this is the cognitive dissonance caused by using weird jargon like "fileout" instead of standard terminology. I think that fileouts are similar to revision control deltas but if that is so, why not call them deltas or updates? The only reason I can see is that "fileout" is a sign of membership in the exclusive CargoCult of true devotees who follow the hallowed tradition laid down in the dawning times of the world.
The cognitive dissonance thing is a load of malarky. I taught beginning Smalltalk classes to a huge cross-section of developers for over five years, and I never saw anyone quit because they couldn't handle the symbols or the precendence rules, nor have I ever seen that as a major problem encountered by Smalltalk programmers. I'm sorry but this was a stupid lie thought up by the purveyors of C-derived languages to explain why Smalltalk was "so much harder to learn". In fact it ISN'T harder to learn -- good grief -- C++ and Java have way more complicated BNF's than Smalltalk! Let's do an experiment -- ask anyone doing Smalltalk for more than a week what the "up arrow" means. Then ask anyone doing Java for the same length of time what "synchronized" or "transient" (two language keywords) mean. See if there's a difference...
And the fact that you think a "fileout" is a revision control delta shows that you haven't taken even a few days to understand the language. It's not a delta. It's not even close. It's a source code representation of what's currently in the image for a particular class or method. In other words take the source code and put in in a separate output file (file...out...get it?) That's it. What the hell else would you expect to call it? Get a grip...
The other major problem area is this thing called an image. It would be appropriate to use images if Smalltalk was also the operating system, but in most modern computers it is not. To become more popular, Smalltalk needs to find a way to play fair within the modern OS which supports concepts like shared libraries, executable applications, data files, etc. I don't expect that any of the commercial Smalltalks would ever do this because they are used for specialized systems, but Squeak could be broken up and evolved in this direction.
WHY? There have been DOZENS of attempts to do this over the years, starting with Modular Smalltalk, and going on from there. None of them were adopted because REAL Smalltalk programmers (those who played with it for more than a few hours) found the image to be simpler and MORE useful than the insane multiple-file legacy format that assembly code has left us with.
It bears repeating:
Failure to do what, exactly? Failure to dominate computing? Failure to get a certain MarketShare?? Failure to decorate the shelves of Borders with a pile of ForDummies books? Failure to be a good, useful programming language? Failure to "revolutionize" computing? Failure to be a SilverBullet? Failure to be a consistent source of income for programmers who are experts in it?
In some of the above, Smalltalk has failed. In others, it hasn't. So what?
You could just as well write CeePlusPlusIsaFailure, CommonLispIsaFailure?, JavaIsaFailure?, VisualBasicIsaFailure, PythonIsaFailure?, and heck, HaskellIsaFailure?. And for each language, it's not difficult to find some observable metric that the language fails, and other languages succeed.
Smalltalk is there. If I want it, I can find it -- and so can the rest of you.
The languages that are true failures are the ones that nobody ever uses, and for good reason.
EditText of this page
(last edited April 10, 2012)
or FindPage with title or text search