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.
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
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.
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.
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
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
I have to agree with you on that one... Smalltalk has the best dev environment I've ever seen. While I use Squeak myself, I interned at a place which used VisualAge, and would say that I liked it more in some respects, and I would guess that the other commercial implementations have a dev env better than Squeak. Which says a lot about Smalltalk.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
There's also a port (albeit an incredibly slow moving one) to the Linux fb, with the intent of running it on Linux PDAs (I'm targeting the Helio and Agenda).
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
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!