Slashdot Mirror
Why Don't More People Use Smalltalk?
RevAaron asks: "With Java, and now C#, we're seeing the same (then revolutionary) concepts and features that Smalltalk had over twenty years ago. With open source versions like Squeak and GNU Smalltalk, not to mention numerous other versions, most of which have an free (as in beer) version available, why hasn't the open source world adopted it to a larger extent? It boggles the mind that the open source community hasn't picked it up, even with almost all of the source of the entire Smalltalk system available to developers, even with the commercial implementations. Is it simply a case of 'once a C coder, always a C coder,' with languages like C++ and Java being used by virtue of their Algol-derived syntax?" The choice of language of most developers is a queer thing indeed. I'm still surprised that COBOL has lasted for as long as it has. So if anyone has any insight as to why Smalltalk use isn't more widespread, please share.
and development environment. But really, it is marketing.
I believe Smalltalk was developed by Xerox? Correct me if I'm wrong, but I think this is true. And no one needs a reminder of how great Xerox has always been at marketing their products. I believe if Smalltalk had been marketed correctly at the outset, Java would either never have been written, or at least not have the place it has today in the market.
I learned Smalltalk as part of my school's CS curriculum about 3 yrs ago, and although I don't remember much about it (aside from the fact that IBM's visual age tool was just as slow as the one they've created for Java) it wasn't a half bad language...
"Teachers leave us kids alone
It is interesting that you should ask this... I am a CS undergrad and for the last few years have heard almost every prof talk about smalltalk when discussion OOP languages or design. No-one has ever said anything bad about it and they all seemed to have used it at one time or another. Having said that, I have also not been required to learn (or even become familiar with) Smalltalk. I have used a few languages (both required and not) but have never had a reason to learn this one beyond having a passing interest in it.
It's one of those things I would like to do if I had the time... I kind of wish someone would assign a programming problem to be done with it so I would HAVE to learn it but I feel the same way about a lot of languages.
My question for Smalltalk is "what have you done lately"? :) No doubt a lot. I am always suprised by the way in which languages are being used... They seem to find niche environments (perhaps because the people using them are comforatable and skilled with the language and it does what they need---why change if this is the case?). Unfortunately, the fact is that unless a programming language is going to be used in the workplace or "for school" most people have very little motivation to learn it (with an exception being made for that Klingon one, of course).
--8<--
--8<--
Why don't more people use Emacs LISP? It has the features Java has, and a 'friendly' development environment. And everybody's favorite, the LISP language syntax! Therefore, no one cares that it's byte-compiled, architecture-neutral, blah, blah, blah...
That's what it all comes back down to: syntax and style. People don't use Smalltalk because they learned C, and procedural modes of thought (BASIC instead of LOGO, FORTRAN instead of LISP...).
Also, back then the paradigm was new, too; real hardcore OO Programmers still tend to migrate back to Smalltalk, if they find out about it, so you'll probably see more people using it, but not that many more. Lots of people aren't comfortable with functional programming, either.
Also, I don't know what sort of extensions Smalltalk supports now, but that's also a compelling reason to use a language. C, C++, Java and Perl all have a lot of built-in API functionality, and have gained a lot of third-party contributions. Many less popular languages don't, and therefore haven't.
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
The thing that waxed Smalltalk at first was lack of horsepower. We didn't learn it at school because there were limited resources, and it was hard to find an instructor who was anything but a COBOL/FORTRAN/RPGII nerd retreaded with C and BASIC. Yeah, Smalltalk worked, but it ate up the timeslots that would ordinarily go to five other terminals. So we used it (and LISP, and APL) late at night after the lab was closed.
I, for one, thought that micros would change things, and that Smalltalk and its OO brethren would move to their rightful places. Not so. Performance was king. After all, if it doesn't work from the customer's point of view, who care what language it's written in. Smalltalk didn't have the abilites of hardware manipulation or operationg system interaction that were needed to produce real-world programs. The only thing even close was Forth.
Then compute power got cheap, and I am once again expecting Smalltalk or its ilk to surface, not as a competitor to program-writing systems already in place, but as a method of reducing the labor factor during the maintenance life cycle of new programs. "Standards based" may have whacked this problem for now, but after the E-business thing gets really going, and business folks realize that changing program features will affect market share and profitability, custom code will make a comeback. Constant change to fit market conditions will require as easy maintenance as possible, and hardware will just be a minor cost.
Besides, I miss the damned turtle...
*whup* "Get along, little electrons. Heeyah!"
In some ways Pascal is a superior language (YMMV) which may people find easier to learn. Borland created an excellent compiler and language implementation. The smart-linking was much superior to the everything-linked-in-statically model of Microsoft's DOS C compiler. So why didn't it win on the DOS platform? It was a one-platform product, there being no cross-platform equivalents of Borland Pascal and the advantages of Borland's product on the DOS platform were irrelevant to other architectures/OS's. So it couldn't compete with the momentum of C and all the C-coded apps being ported to DOS (and mangled in the process).
A solution doesn't have to be the best to win, it only has to be just good enough. There's a great article by Richard P. Gabriel on this point, The Rise of Worse-is-better. It's actually part of a bigger article about the failures and successes of Lisp, Lisp: Good News, Bad News, How to Win Big which is all very relevant to your question.
There are a number of reasons.
;)
I'd wager the reasons the Free software crowd (however it is supposed to be these days, Open Source, Free, whatever) hasn't picked it up are: lack of large stores of prewritten smalltalk code, and the fact that OO design is overkill for small projects.
Allow me to elaborate. There is tons of existing C, C++, perl, etc code out there; seems like if there is anything that you would want to do, code is already out there. Why start in a language where you don't have quite as much to build on?
I hate to knock everyone's pet design methodology, but OO design *really* is overkill for smaller projects; and all projects start off small. Free software gets written because some developer has an itch. Rather than drawing up miles of uml charts for a design, [s]?he whips something quick out in a language they are familiar with (and one with lots of existing code, no less). Only afterwards does it start to grow into something that might benefit from a structured design.
The reasons the rest of the world hasn't picked it up probably has more to do with marketing than anything else. So (because no monopoly software maker has told them they need to) businesses aren't looking for people with smalltalk skills. So people don't bother to learn it as it won't further their career any.
Plus I just like perl and C.
This sig is false.
When you used smalltalk, you create an image. As you add stuff to your application you get a bigger and bigger image. The way most projects seem to work, the image continues to grow (similar to COBOL because nobody removes any code and VERY similar to FORTH which also had an 'Image' problem). The next problem was GUI. The GUI was 100% let's do it my way. Nothing looked like window, X, or Mac. Granted it was probably designed on a weird Xerox box and ported to other OSs - key is that it had little in common with the new GUIs. Next are the Bears. When you get a system that 'grows', you get sloppy and designs go from peoples brains and straight to image. Result:Sure it works, but what the hell is in it? Case in point: I had a team that did a review of a system last year that was written in Smalltalk. The team asked for the design and they never got it. They connfessed that they had lost the butcher paper table cloth they had initialy designed it on. All other work they gleefully confessed was developed in the debugger environment. End Note: The design never really worked or could scale what did. Today the system is happlily rewrittn in Java in JSP :o)
Oh My: Cost! Commercial systems were budget killers. Worse, the systems were much slower than C++ because there was no competiton to create a faster environment. There were at most only a couple of good vendors chassing too few projects. Forsaking the hacker via cost is probably the single most killer and stagnation of a tool. Mainframes vs affordable PCs or C/C++/Java vs Smalltalk and even the M$ languaged (cause you have to buy 'their' IDE. 'nuff said.
Personal note:
I tried a little programming via Digitalk's Smalltalk back in 93/94ish when you could get Digitalk for a song and a user group discount. I didn't like it too much and gave up after a couple of weeks. It is one step removed from C,C++,Java. It felt like using an HP45c calculator after a lifetime of using a TI-99A(boy does that show my age). Key pluses were a common API and you could program very quickly.
I must say that Java was simplistic compared to Smalltalk. A Duck to Water! Not to mention that warm fuzzy feeling you get when te compiler finds a mistake that would be a mystery pointer fault in C++. And the best reason for failure: There are one hell of a lot more Java jobs out there :o)
BTW remember NeWS? That was written by the former idiot Gosling. Imagine Postscript as an interpreted RPN GUI language that runs on X terminals. Can you say "crash your X Terminal?" Sure you can. I look at all the problems with NeWS and I see the genius of the Java Virtual Machine. And thus, I posit, Q.E.D. Java becomes a secure language. NeWS suffered from a sensitive stack. By controlling the stack and verification it programmaticaly (the byte code validator) and RT exception system and you have cured most errors too!
I was very interested in the language when it was written up in BYTE, many years ago. I even bought several of the books put out by Adele Goldberg and others at Xerox PARC. Unfortunately, someone decided that the way to make money on Smalltalk was to charge Lisp Machine prices for the software. After waiting years for an affordable version of the software, I lost interest in Smalltalk.
Mea navis aericumbens anguillis abundat
Now it's one thing for people to nitpick about the differences between C and C++, but has anyone ever seen any implementation of Smalltalk that could be described as fast? Smalltalk is a wonderful language. The design is beautiful, powerful, and simple. However, the actual implementation of language interpreters is usually heinously slow due to a number of design issues with the language. You can't even do a simple '2 + 2' without involving objects. The beautiful, but odd block statement syntax makes interpretation very awkward and tricky as well.
My college uses an open-source Smalltalk variant known as Squeak for it's OO classes. (It was made for Disney of all people -- hence the name.) One of my favorite stories of Squeak inefficiency came from a conversation I overheard about one student having a problem with Squeak running out of memory trying to create a PostScript file. The problem was that each time you appended to the object, it made a copy of the original object and then appended to the copy. These huge copies were being passed around in memory over and over again until the VM simply ran out of room. This ridiculous waste of memory and CPU cycles comes from fundamental design problems with the language. It's wonderful but way too abstract to get real-world performance.
If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").
There's a definite difference between procedural and functional languages, but maybe it's just simple luck of the draw that stuff like C and Java are infinitely more popular today than Scheme, Smalltalk, and Lisp are.
- A.P.
--
"One World, one Web, one Program" - Microsoft promotional ad
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
I have written thousands of lines of Fortran, embedded C, poured over tons of Java and C++, and done Smalltalk for 9+ years. Anywhere I *can* get Smalltalk to fit, I will use it. Why? Because it is different. And it's probably these differences that slow its adoption by the hacker/hobbyiest community. Namely: Everything is an object: It's all about message sending in Smalltalk. This is especially powerful in large/complex/evolutionary systems. It's also very elegant; a real sense of uniformity. Syntax: Took me a couple of weeks to get used to it. Now I laugh at most of the others. Five reseverved keywords. The majority of the language elements in one method. Approximates natural language very well. The Image Programing Model and IDE: Once you grok it, very powerful. But again, a hurdle that if approached with a shoehorn just punishes you. The object based browsers. People still insist on browsers that just show flat files and "jump" you to the appropriate code point when you navigate to a method. It's amusing to watch many struggle with (and ultimately reject) VAJ, which attempts to bring code navigation within reach of the 20 year old Smalltalk browsers. It's too easy: I get a certain rush out of eeking a few percent out of an embedded C program, by playing a number of "tricks". There's a real sense of "I climbed the hill!", even though it is small. It has been fascinating to watch even some members of the Smalltalk community spend the last 5 years in Java work there tails off to come up with shoddy re-implementations of something they did easily in Smalltalk. But in Java (or C++, or whatever), it's more of a challenge. So either be prepared to discover the good ol' problems have been solved, or start solving some new ones. Problems that have historically hindered, but no longer do: Vendor Viability: IBM does Smalltalk. Cincom (one of the most succesful privately owned companies in the software industry) does it. The Squeak project has enjoyed quite a swell of momentum; anyone who went to ANY of the last three OOPSLAs would know this. Speed: For raw number crunching, Smalltalkers cede to C. Most of the Smalltalk's have robust methods of integrating C code for tight/primitives to speed optimize that critical 5% of your code. And when it comes to message dispatch, Smalltalk has won a number of benchmark tests. GC implementations in the 8 major implementations leave other lang GCs behind. Price: Squeak is open source to the bare bones. And it's extremely portable. It's been ported to a plethora of chips. The high priced vendors have come out with better pricing models (though there is still room for improvement). There are different entry price models. OS integration: Again much improved. MT allows one to write ST DLLs (very fast too). QKS has a .NET implementation. There are Unix shell implementations. Dolphin has great Win32 integration. ST/X has a plethora of built in Linux tools.
I have watched a number of people take a run at Smalltalk. Seems that most are either wildly succesful; have the "aha" experience and fall in love. Others just never get what it is the rest of us get excited about. I have tried to track why some do and don't. The only distinguishing attribute I have been able to find is "ya gotta wanna." Those who have really had the desire to stick with and find out why a 30 year old language still has such strong advocates, is willing to eventually fall out of their box, and discover that in some cases, different has advantages. But many people can just never get beyond the differences.
It is interesting to note that in a spectrum drawn between Smalltalk and Assembly, languages have spent the last 30 years slowly evolving towards the Smalltalk end. In the end it may not be Smalltalk that we all use. But new languages will continue to be more and more like Smalltalk in spirit. Maybe Smalltalk will continue to innovate and offer these back to the evolution of mainstrema languages; maybe sufficient convergence will finally be achieved, and we'll all jump on whatever bandwagon has really caught up.
One man's pink plane is another man's blue plane.
I don't use LISP/CLOS or Smalltalk or Prolog for the same reasons that I do use Java for my home hacking: The textual representation of a Java class as a single source file will all details collected really works for me, and the typing system leads to self-documenting and correct-by-construction code. Sure, a single file can get cluttered. That's what JavaDoc fixes. On the other hand have you ever tried to grep a SmallTalk VM? Yes, builtin object browsers are cool, but I'm a hardcopy code reader. Same goes for LISP/CLOS. There isn't sufficient structure in the syntax to be self-documenting. Strong typing is also a big feature for me. I'm lazy, compile-time type checking is my friend. With SmallTalk you have to figure out why that message wasn't found rather than know ahead of time that it won't be found. Prolog just gives you a "No".
VMs really are very cool. My favorite hack on the Lispm was to search for CLOS methods that weren't polymorphic and recompile them automatically as defuns for efficiency, AND modify the source code to reflect the change. These days when I write code I just want to get the job done. SmallTalk doesn't get me there because the textual representation doesn't support the way my brain organizes and retrieves program structure.
10. it's an OO language
9. slower than C
8. syntax differences
7. paradigm differences
6. it required beefy hardware
5. missed the boat on web browser integration
4. too expensive
3. lack of marketing
2. potatoes taste great if you've never had filet mignon
1. you can't teach old hackers new tricks
Most of these things are no longer true of course. The combination of open source implementations such as Squeak (which I love by the way), strong commercial support by Smalltalk vendors, and entrenched usage by many Global 2000 companies (the only ones that used to be able to afford Smalltalk) all bode well for the future of Smalltalk. Perhaps the most exciting thing is that the better universities are now making Smalltalk an integral part of their cirriculum.
Cross-platform support is important, true. But how much of the C from your Window's apps can you take over to a Mac app? 75%?
There is a Squeak Smalltalk environment for just about every platform under the sun (I haven't seen one on a Palm yet, but it's probably out there) and 100% of the code you write on one platform can be taken to any other platform you choose. You don't have to port Smalltalk apps. That's *real* cross-platform support.
Fact #1 - Origin of Name
Squeak was started at Apple in 1996, and didn't move over to Disney until over a year later. The name has nothing to do with Disney, and those who came up with it are tight-lipped about its origins.
Fact #2a - Language Efficiency
The postscript problems you describe are not due to "fundamental design problems with the language". They are due to fundamental design problems with the application. You could write the same algorithm in C++, and it would still be slow. The difference would be that in C++ it would crash after running out of memory. Is this because of fundamental design problems with C++? Yeesh.
The Squeak compiler (which is written in Squeak) compiles most methods in less than 0.1 seconds. Squeak's garbage collection is well designed and efficient enough to operate incrementally without causing glitches in real-time FM sound synthesis. Try that in Java.
Fact #2b - Language Efficiency Revisited
Has anyone seen a fast implementation of Smalltalk? Well, pretty much every one of them is faster than Python (don't have benchmarks at hand). Squeak has a very fast pure bytecode interpreter, and (last time I checked) beat Python hands down in raw execution speed. Other Smalltalk implementations use JIT compilers, and are faster still.
Fact #3 - Message sends to Integers
Although Smalltalk maintains uniform semantics, arithmetic is actually implemented within the virtual machine for efficiency.
By the way, what school do you go to? It it's Georgia Tech (one of the few that uses Squeak in classes), come on up to the Squeak Lab and we can discuss this at greater length.
Try download Squeak. It's a very easy install on any platform you're likely to be using (WinCE/NT/95/98/2000, MacOS, Linux, BSDs, BeOS, etc.) It comes with many demos, including an interactive VR authoring environment.
When I was getting my undergrad degree I had classes in C, C++, ADA, etc... but the university offered a course in pure OO and the teacher used small talk. At the time I had never heard of the language so I tried to sign up, but the stupid school's online course registration system wasn't working. I tried several times, as did my friends. Eventually we go in and on the first day of class the prof was talking about how small talk is used and she mentioned that our online course registration software was developed entirely with small talk - not a good way to start.
Over the semester I gained an apreciation for small talk. I feel that any coder worth their salts (especially one with a BS or higher) should be able to learn almost any language by reading a good book in a week - just to learn the new subtle elements (note: learn a language != proficiency). However, small talk didn't jump right up and look like C, C++, ADA, etc... I feel it didn't fit the learning curve because it has a large amount of subtle differences.
IMHO it's partly due to "bad press" and large amounts of differences. Again IMHO ADA and S are very very very nice languages but they don't get the best talk time in Unniversities either, but I'd expect a new hire with a BS who new C/C++ to learn ADA or S readily quickly, whereas I would think small talk to take longer. When you put that into the cost equation for development it adds a price on that might put it higher than a competitor who does not need to retrain.
On a side bar I remember seeing an applicatioin that would take any C or C++ source and translate it to ADA code, but none exists to go the other way and I think there's a reason for that. Anyone see anything for other code translations (let's keep on topic and look for Small Talk translators) between other languages?
Wheeeee
So, Smalltalk? I bring it up at a meeting with the other enginners-turned-suits and a couple of annoying marketing folks. They all stare at me. Smalltalk? We code in C. Or C++. Or whatever. We don't have any Smalltalk experiance. We don't have any Smalltalk tools. We don't have any Smalltalk developers.
But we can hire the developers! We can buy the tools! We can integrate this into our company! We can learn to read it ourselves as so to manage it!
Then Bob, who's been around forever takes me aside and points out a few things.
We're a business. We're not about changing the world, or even rocking it unless there's profit in it. Sure Smalltalk may be great but we've already got a language we use, the licenses are paid for, it's an indistry standard. Good developers are hard enough to find as it is without requiring them to be Smalltalk coders. Frankly we've never managed a Smalltalk project and don't know any of it's dangers, what it's "best practices" are, how to optimize it, even have any code we can reuse in it.
Look son - there are lots of great languages out there. They're fascinating, faster, etc. But we're in business and that means getting a quality application out the door. We stick with what we know and not add any variables we don't need. Now go back in there and let the Marketing folks tell us it needs to be 'synergistic' and 'mauve'.
So we go back and I politely drop the whole Smalltalk thing. Yeah, it's a great language. Sure it can do things cleverly and elegantly but that's not what we're about. We're about standardized production and that botique stuff isn't for us. So no Smalltalk today thank you.
That's why Smalltalk isn't moe popular. Personally I'm all for renaming it Internet2000MultiMediaOpenSouceSexySexySexy!!! but short of that it's just another great idea passed over by history...
Modula3 however - now THERE's a great idea!...
I don't read ACs: If a post isn't worth so much as a nom de plume to its author then I wont bother either.
Certainly Smalltalk has it's merits, but it also has it's shortcomings:
Probably the biggest problem of Smalltalk though is that while it does a great job of leveraging an excellent programmer's work for a project, it also does an great job at leveraging the damage a beginning programmer can do. When Smalltalk DID get in the limelight, it didn't have enough excellent programmers around (and it takes a while to create more excellent programmers). While some companies are enlightened enough to focus on getting the top programmers, most are not (nor good they). This is where Java, Visual Basic and Delphi are much stronger than Smalltalk.
sigs are a waste of space
I don't think that the perception that Smalltalk is slow is correct. Back in the old Linux 0.99pl17 days I used a 40MHz 386 machine with 4MB of RAM. I used X Window and OpenLook running stuff like Netscape, so you can imagine I have a good idea of when things are sloooow.
I then downloaded Smalltalk/X, but it was not really usable. So I upgraded to 12MB and that made a huge difference. In fact, using its graphical text editor (which could read and write RTF files) become so much nicer than vi in xterm (it scrolled faster!) that it was worth loading ST/X to do mundane chores like editing shell scripts.
Don't forget that Self (a Smalltalk dialect that Sun killed to help boost Java) was able to run intensely numerical benchmarks at 50% of the speed of C (while fully checking array bounds, integer overflow and a bunch of other stuff). Self's adaptive compilation technologies now show up in Java HotSpot and Transmeta CodeMorphing products.
To oversimplify, there are two big reasons
Nevertheless, Smalltalk has refused to go away. Significant open source efforts have started with things like Squeak and Camp Smalltalk, and even in the commercial world VisualWorks has a free download and Dolphin Smalltalk is an inexpensive very nice, clean windows environment. For a language that doesn't get used much, it runs fabs, auto assembly lines, massive payroll systems, and untold numbers of financial systems including a very respectable fraction of the stock trades in the United States.
Disclaimer: I recently quit a Java startup (WebGain) to go work for Cincom on Smalltalk development.
You must be a shape shifter... err, maybe you meant "pore".
When I first learnt Smalltalk I felt it was mind-expanding. That was around 1985. I haven't ever used it (I'm strictly C/C++/assembler). But it doesn't matter - the act of learning it (and learning how the underlying virtual machine works) changed the way I thought about programming forever. I can recommend learning it to everyone.
--
-- SIGFPE
You might be interested in a long post I sent to two email lists where I develop the same application twice in the on the fly programming style. First in a pseudo Prolog and then in Self (a Smalltalk dialect). This is what Smalltalk is specially good at, so it seems strange that you feel it can't do it.
little demand for Smalltalk programmers:
This is probably true, but it is likely that the supply is even smaller so that it might be a good career move for someone to learn Smalltalk. Over the past few years three different US companies have contacted me asking if I wouldn't be interested in moving up there to work for them. In case you are thinking that they were just after cheap labor, I made it very clear that I would be expensive and they were still wanted me so there might be a genuine shortage.
Hmm - Have you taken a look at the code to see why it's slow? Most likely, the implementation is bad. Just ponder your post: Fast enough to serve web pages, but not fast enough to render them. So you apparently think that handling > 4 million hits per day doesn't require speed...
I don't understand your point at all. C or C++ is easier to just pound code in? Goodness, where do you get that idea? Smalltalk has support for incremental development, fixing in the debugger, overriding base classes where you need to - C or C++ have none of this.
It turns out that with a good compiler it can completely remove the inefficiencies relating to 2 + 2. No objects are needed at the end of the day, because the compiler knows that 2 is an integer. Even if it was 'a + 2' it can write code that checks the type of a and write code that is specific to integers, even before the function is called at all.
Anyway the fastest Smalltalk I knew was actually another language.
Huh? Ok bear with me. There once was a language called Smalltalk. Smalltalk begat Self (Sun prototype based OO language not totally dis-similar to Smalltalk). After they spent a few YEARS optimising Self it ran at about 1/2 the speed of OPTIMISED C, it is harder to optimise than Smalltalk even. And it ran several times faster in fact.
Anyhow, the last release of Self actually supported Smalltalk. At the time it was the fastest Smalltalk ever to the best of my knowledge, but it only ran on one or two types of Sun machines, but the Self project was canned.
Anyway the research for Self has been hugely influential:
Sun invented Oak, changed its name to Java, but the reason they did Java is because underneath the C syntax and the type system it's not a million miles from Smalltalk/Self infact (everything is passed by reference, GC etc. etc.) and has similar optimisation problems.
Ever heard of Transmeta? Well, that is based on Dynamo, which in turn was based on a byte code interpreter written for, you guessed it, Self.
Hotspot? Same thing. Self tech.
Ok. That's the upside. Downside of Self is that it had a nasty tendency to use great gobs of memory. Five years ago or so it wouldn't run in less than 20-60 meg or so and that was a lot, then. More if you had an application, and its speed varied as it recompiled lots of cached code 20 different ways to deal with different types; but once it got going- it was really very FAST. Java has only just passed it efficiency wise.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"Thanks for sharing that experience. I'm getting hooked on smalltalk. In fact, I'm almost scared to start learning it too deeply for fear I'll throw everything else away and won't be employable!
--- Millihelen -- The amount of beauty required to launch a single ship.
Sprint invested *BUX* on an advanced traffic routing system implemented in Smalltalk using GemStone as the database. Worked great in the lab but when they started to do real-world processing with it, nada. Didn't have enough oomph to accomplish the job. Now, whether this was due to any inherent limitations in the language, or due to crummy coding, I'm not sure. All I know is that they've started the process of redoing the whole thing in Java. If nothing else, it'll make it easier to get consultants to work on it ...
James
Perl wins hands down there, but once you get out of that niche, Perl slows down considerably compared to, oh, say, Java. Remember, I'm talking about general purpose. If you're doing stuff Perl is "Real Good At" (TM) (like massive string manipulation), Perl will be fast. Different problem domains.
--
Ben Kosse
--
Ben Kosse
Remember Ed Curry!
I still think C and perl both beat smalltalk in the amount of prewritten code out there.
CPAN has a module for anything I have ever wanted to do. C has tons of code available from all over the place, including several high quality, fully functional operating systems. There may be smalltalk code out there, but I don't think there is as much as there is C and perl.
*shrug*
This sig is false.
I love OO programming, and I've heard many things about Smalltalk. But I didn't get exposed to it in school (like I did to C, C++, Java, Lisp, Prolog, SML, Fortran, and assembly). Maybe there's just a lot of people out there like me who would like to learn about it, but have never found the time or was never taught about it in school.
I was there.
I read the BYTE article. I bought the first Smalltalk IDE for DOS (Digitalk) in 1986 and taught myself OO and Smalltalk programming. I architected dozens of large scale Smalltalk projects for several Fortune 500 companies. I endured the hype that (incredibly and unironically) predicted that Smalltalk would become the COBOL of the 90s. I made tons of dough.
I watched as Smalltalk use soared and then -- at last -- plummeted. I reeducated myself as a Java (gak) programmer and said goodbye to a language that I once thought could never be bettered and might someday dominate computing.
So Why Did Smalltalk Fail?
First: Why Not
Myth #1 Smalltalk failed because of poor marketing. Okay, Smalltalk marketing was not the textbook example of high tech marketing that was the introduction and distribution of Java but it was far from bad. If anything, the hype behind Smalltalk seemed to inspire an almost religious fervor. While Smalltalk use never approached the ubiquity of COBOL alot of very smart people believed that it would. Christ had St Paul and Smalltalk had Adele Goldberg. You should have heard the starry-eyed predictions of the execs leaving a ParcPlace road show.
Myth #2 Smalltalk failed because it was slow. Okay for some purposes and in some implementations Smalltalk provided less than optimal performance. But most enterprise applications do not require blazing performance at the Client (where Smalltalk was primarily deployed). The speed of Smalltalk development more than countered its performance hitches. Even if a Smalltalk application was dog slow, any reasonable thinking corporate IT manager just needed to requisition the latest PC hardware for the application's users.
Myth #3 Smalltalk failed because it was so expensive. Yes its likely that if the major Smalltalk vendors of the 80s and early 90s had given away their product more programmers would be programming in Smalltalk today. The simple fact is that at the time PCs and programming were not as widespread as they are today and most programmers or people interested in learning programming had access to computers through work or school and such institutions could and often did afford themselves access to Smalltalk.
So how come a language that by most accounts is elegant, powerful and expressive did not achieve widespread popularity?
Here's Why:
Reason #1: Enterprise Smalltalk application development was beyond the grasp of most corporate IT managers. Smalltalk fosters reuse of a very high order and tends to attract programmers whose focus is on reuse. This is not a bad thing at all. But (and that is a big but) code reuse and its benefits cannot be enjoyed in a unsupportive and uncooperative environment. Except in a few rare instances most organizations threw Smalltalk at their PC "front end" applications, allowed the applications developers (outside consultants usually) to create rich and highly reusable development frameworks and business models and then failed to share the work with the rest of the department. This happened simply because the amount of effort that went into sharing and managing code within an IT department was too great and the manager's bosses saw no value in the attempt. A professional software company sees their software as an asset. Many firms that may very well rely on software see (or did see until recently) their software as a replaceable resource.
Reason #2: Smalltalk, a simulation language at heart, was employed too often as a simple GUI builder. Okay, you are a project lead at a large Wall Street firm. You have nine months (why is it always nine months?) to complete a very important and high visibility application that could guarantee you a promotion. You are told by your IBM (or Microsoft -- believe it or not Bill Gates used to say good things about Smalltalk) representative that the latest and greatest language and GUI application builder is Smalltalk the OOiest of OO languages. So you dive in. What happens? Well nine months later you discover that your fancy graphical front end to your mainframe application has evolved into a large (okay, fat. okay, obese.) client application that is a generic screen-scraping/rdbms-to-Object mapper/business model with extra menthol eukeneuba three for more whitening power that is brittle to the touch (the more moving parts the more chance for breakage) and dog slow because the application designers in their zeal to objectify everything in sight (because they can) re-developed the key mainframe components and their business logic in Smalltalk. On a PC client. With 200 - 1000 ms latency for every data call to compose the applications objects. (This of course presumes you have found the developers who know Smalltalk well enough to put something this sophisticated together). Meanwhile the monkey down the hall has whipped up a huge bowl of visual basic spaghetti that may not be terribly elegant or useful to anyone except the end user but is working and in production. The simple fact is that Smalltalk which preceded the Client Server revolution by several years, belonged on the Server not the Client. Smalltalk grew into what little prominence it enjoyed in the bad old days of 2 Tier Fat Client Architecture. Because Smalltalk was graphically oriented and the client was where the money and the sex appeal was, Smalltalk ended up a GUI solution (and wrongly associated with the fat client problem) and not the business modelling solution it should have been.
Reason #3: The Learning Curve. Smalltalk syntax is odd and does frighten away the timid. Setting up a Smalltalk environment for enterprise programming is a nightmare and deploying the application once it is built is the nightmare you wake up into from the previous nightmare. More significantly, I think the "idea" of a stand alone Smalltalk program doesn't exist as such. A Smalltalk image is a large and often unwieldy executable. The novice programmer accustomed to taking their program home on a floppy and seeing the result of their effort encapsulated entirely in a single main function is bewildered by the image concept wherein the programmer does not use the development environment to build a program but modifies the development environment to be the program.
Reason #4: Java. Java in its ubiquity and immediate appeal (small programs, manageable memory footprints, familiar syntax and wealth of easy to follow examples) made Smalltalk as an OO choice irrelevant. Also, the Java folk ceded (mostly) the client to other languages and have concentrated on network computing thereby avoiding the pitfalls of GUI OO development. Java ain't pretty (unless you have been doing C++) and it ain't all that fast but it is programmer friendly and OO friendly enough to achieve some of the promises of Smalltalk. I like to think that spirit of Smalltalk lives on in Java and that Java is just yet another step in the evolution of C into Smalltalk. On bleaker days I look at the retarded in bred cousin that is Java and despair that his Daddy had more money and that's why he inherited the family business. Oh well.