Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Why Don't More People Use Smalltalk? 81

Posted by Cliff from the syntactically-incorrect? dept.
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.
This discussion has been archived. No new comments can be posted.

Why Don't More People Use Smalltalk? More

Why Don't More People Use Smalltalk?

Comments Filter:
  • 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...

  • 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 [geocities.com] one, of course).

    --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 [ncsu.edu].
  • at dinner parties or in front of a GUI.

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

  • C compilers are available on any platform you care to mention. More, the capabilities of the C compilers have become so standardised that many people mistake them for language features. This has created such a wide base that C has an unstoppable momentum.

    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 [jwz.org]. It's actually part of a bigger article about the failures and successes of Lisp, Lisp: Good News, Bad News, How to Win Big [mit.edu] 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. ;)
  • 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.

  • Lack of Speed and Efficiency (Score:3)

    by Valdrax ( 32670 ) on Monday September 11, 2000 @06:12PM (#787075)
    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.
  • You might as well ask "why don't more people use any functional languages?" The simple fact of the matter is they're a lot more difficult for people to wrap their head around at first. This may have something to do with the fact that most CS curriculums start students out with procedural languages (C, C++, Java) and barely give them a cursory glance at functional programming (which is kind of a shame).

    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

  • I had the same problem. Smalltalk was too expensive, and required more hardware than I could afford at the time. I still have that issue of BYTE...
  • You might as well ask "why don't more people use any functional languages?" The simple fact of the matter is they're a lot more difficult for people to wrap their head around at first. This may have something to do with the fact that most CS curriculums start students out with procedural languages (C, C++, Java) and barely give them a cursory glance at functional programming (which is kind of a shame).

    You are wrong on several counts.

    Smalltalk is an Object Oriented Language. As are C++ and Java. C is a procedural language.

    Having used all four I can state that in my opinion the reason Smalltalk has never caught on is due to a.) Lack of speed b.) Lack of libraries c.)lack of decent IDEs d.) Lack of compilers e.) Lack of good books/documentation (this in my opinion is the biggest flaw).

    Of course, the Squeak Project [squeak.org] plans to change this.



  • Proponent (long) (Score:5)

    by Lord of the Fries ( 132154 ) on Monday September 11, 2000 @08:15PM (#787079) Homepage
    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.
  • First let me say that I'm a big fan of virtual machine languages. My first real hacking was on lispms (I'm sitting next to a Symbolics 3640 as I type this), and I've actually been paid to write commercial software in Prolog. I've also hacked on the Squeak [squeak.org] SmallTalk VM.

    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.

  • I hate to knock everyone's pet design methodology, but OO design *really* is overkill for smaller projects; and all projects start off small.

    No, not all projects start off small. One of the rules of thumb of commercial software development is a product that takes less than six months to develop probably has no real value. Why? Because a group of average programmers can copy it in less than a year.

    I'd ask what experience you have, but I see you're posting from a .edu domain. However, even in school I found that careful design allowed me to trump the rest of the class at software projects. Usually by a lot. And in less time, too.

    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.

    I've written some extremely useful stuff this way! But there are words for this: hacking, cowboy coding, etc. Do not confuse this with software engineering.

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

  • No, not all projects start off small. One of the rules of thumb of commercial software development is a product that takes less than six months to develop probably has no real value. Why? Because a group of average programmers can copy it in less than a year.

    If you would have read my entire post, you would have realized the first part was not about commercial software. Sorry, but most Free software projects do start off small; the projects that start large are few and far between. I'd ask if you had any experience, but I see you don't even have the courage to list an e-mail address.

    I've written some extremely useful stuff this way! But there are words for this: hacking, cowboy coding, etc. Do not confuse this with software engineering.

    Again, if you actually read my post, you would know that I never mentioned the word engineering; so don't put words in my mouth. Perhaps you need to brush up on your reading comprehension skills, troll, rather than spending all of your time engineering software.

    My entire point was the non-adoption of Smalltalk has little to do with the language itself, and more to do with the people who haven't adopted it: in the Free software world, it doesn't fit the culture very well, in the commercial world, it hasn't been marketed.

    Pay attention next time.

  • Only my second post, I'm learning. I'd recomend that Plain Old Text be the default and that the /. programmers read "The Inmates are In Charge of the Asilum". Not letting me edit my post is sad.

    And thanks for the comment! There are advantages to being an old hacker :o)
  • it seems a similar speed to perl on many tasks; i.e. much slower than java, C, etc.
    Are you on crack?

    Perl is far faster than Java is, for every imagineable task. It's slightly slower than C, and in general will outpace even C++ with the STL.

    You obviously haven't used Perl.

    Jeremy
  • Development environment? The Squeak Smalltalk development environment is hands-down the best I've ever seen. Compared to any C++ environment (Visual Studio, Codewarrior, or Makefiles), Squeak is a developer's dream.
  • VisualAge for IBM was written in Smalltalk. That should say something about how well Smalltalk performs.

    --weenie NT4 user: bite me!
  • 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.

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

    Lack of prewritten Smalltalk? You can download Squeak at www.squeak.org. I highly recommend downloading it and giving it a whirl. Squeak Smalltalk comes with a tremendous amount of (mostly) well-written, extremely reusable code. If you're writing all your Smalltalk applications from scratch, you're doing something wrong!
  • Both IBM's VisualAge for Smalltalk and Java were written in Smalltalk. As much as people wanted to believe that Java was a mature programming language, it wasn't mature enough to write an IDE in.

    While I've never used VA for Java, I've never had any problems with the Smalltalk version. Was fast and responsive enough to write the huge app where I interned this summer which was responsible for defining products and generating C, C++, COBOL, and XML code...
  • Smalltalk has a strong tradition of being cross platform. The most notable example is Squeak [squeak.org] which runs on almost every platform out there. Most importantly, most of the big Unices (including Linux), Mac OS, and Windows. With binary compatibility. C as a portable assembler is a myth, and C code needs to be written with portability in mind.
  • One doesn't have to do huge UML diagrams to write OO code. I've done small Smalltalk (and Python) projects using just 2 or 3 classes. And to the way I think, it was a lot easier than writting functions to do it. While full-blown OO analysis and design may be overkill for a lot of small projects, OO programming is not.

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

  • Re:well, let see... (Score:1)

    by Anonymous Coward
    Yes Smalltalk was designed and developed at Xerox's PARC research lab nearly thirty years ago. They built machines especially to run it - in the process they invented personal computers and networks and laser printers. Xerox didn't want much to do with it sicne most computer stuff just didn't fit in with their idea of business. Thus we got 3Com and many others spinning out as people left to pursue their ideas. One spin-out was ParcPlace Systems, which developed VisualWorks/Smallltalk. PPS was nt a great deal better at marketing Smalltalk than Xerox.
  • Try download Squeak [squeak.org]. 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.

  • Re:Smalltalk? Hmmm.... (Score:1)

    by Anonymous Coward
    "what have you done lately"? Try reading a little and you might find out. http://www.squeak.org, http://www.stic.org etc. Just as an example, Squeak has:-
    • synthesized sound (including speech), sampled sounds, graphical MIDI player/creator with synchronized movie playing.
    • 3D graphics via an Alice-like control language.
    • Sophisticated colour graphics (take a look at some of the alternate theme pictures on the website)
    • network access including treating ftp sites as extensions of yout local filesystem, as well as IRC, a web browser, a web server, email, and network shared workspaces.
    ...and that's just the icing on the cake of it being a decent object development system.
  • You can do more with logo than draw little spirals on an Apple ][ ?! I thought it was invented for 5 yr. olds!

    --
  • SPair catches the essence of the problem. I think I can state things a little more simply: 1) The UI/IDE is hard to learn. Like most power tools, it takes time to learn to use it. 2) Not enough programmers like to read code. Smalltalk is a language for readers, not just writers. 3) Elitest culture. I have found that many experienced Smalltalkers don't tolerate things done "the wrong way" and don't give new people enough time to learn "the right way." 4) High software/hardware cost prevented a large enough mass of programmer talent from growing. My favorite C compiler cost $30 and worked great and I could do anything the big boys could. Of course I learned C! Hopefully, it is not too late to correct these problems. Smalltalk is fast and powerful, and the other posts about poor performance are uninformed. txb.
  • Ugh, I meant to say VisualAge for Java (not IBM) but I guess you figured that out.

    I don't have the link anymore, but you can download a free trial of VisualAge for Smalltalk somewhere on the IBM site. The Smalltalk section on the IBM website is very well hidden since they are trying hard to push Java.

    --weenie NT4 user: bite me!
  • >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? Sure. If you base your eval on older versions of Squeak, you'll see slow. But modern versions (i.e., all versions that sell commercially) use a JIT - just like Java. VisualWorks and VisualAge are fast - faster than Java for most operations (with the exception of primitive mathematical functions). Since most apps are database driven that's not much of an issue. >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. Fundamental design flaw in the language? Heck, I can find poorly written code in any language. Shall I condemn C++ based on Windows system code, or condemn Java based on early implementations of Swing? Sheesh, if that's what you think of as a language design flaw, then please stop programming now - you're dangerous ;-) James Robertson jarober@mail.com
  • 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?
  • OK - I'm Somecorp and I want to develop a new product. I'm about to invest a bucket of money, hire or assign a team of developers, and get this thing to market in a reasonable amount of time. Along the way I need to make it play nice on it's OS, be built using a standard set of tools my developers know, and consist of code I can revisit next year for V2 or just simple bug-fixes.

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

  • You can do more with logo than draw little spirals on an Apple ][ ?! I thought it was invented for 5 yr. olds!

    Hey, I wrote a (very crude) text editor in Atari Logo... granted it ran rather slowish on that 1.6 Mzh 6502, but it worked.

    Remember the days when if it didn't fit in 64K it just wasn't worth doing? <sigh>

  • Not completely from scratch, but the amount of code out there doesn't come close to the amount of, say, C, C++, or perl code. Practically anything I want to do is already done in any of those languages, especially perl.

  • Yes but... (Score:3)

    by X ( 1235 ) <x@xman.org> on Tuesday September 12, 2000 @07:55AM (#787105) Homepage Journal

    Certainly Smalltalk has it's merits, but it also has it's shortcomings:

    • It lacks Java's interoperability guaruntees, limiting the ability of end users to choose among multiple 3rd party vendors
    • It does not define a stable runtime (developers can and generally do modify almost all the fundamentals of the system) making it hard for 3rd party vendors to sell add ons.
    • A direct corollary of the previous point is that Smalltalk developers constantly reinvent the wheel. When I work with a Smalltalk team, a good deal of design effort is spent on architectural domains like exceptions, transactions, persistence, etc. With Java, all that is already there. Sure, a group of excellent programmers designing an architecture for a specific purpose will likely produce something better than a general purpose API, but it is hard from a business standpoint to justify the effort.
    • A strong NIH mentality within the Smalltalk community. A good example was your GC argument. In fact, Smalltalk GC's lagged LISP GC's in much the same way that Java GC's have lagged Smalltalk.
    • Slow adoption of modern OS capabilities, in particular threading comes to mind. You might get one vendor adopting a particular capability, but you didn't have something uniform.
    • Too much proprietary effort. Companies have tried too hard to wring profits out of Smalltalk, and as a consequence squandered it's commercial viability.

    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.

  • It's not terrible hard to find- it's right here [ibm.com].

    Actually, according to some discussions on comp.lang.smalltalk a few weeks ago, the next version of VisualAge for Java is done at least partly in Java, rather than in Smalltalk. We'll see how that turns out.
  • 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.
  • It lacks Java's interoperability guaruntees, limiting the ability of end users to choose among multiple 3rd party vendors

    There exists (final/draft?) a new ANSI Standard for Smalltalk. Many of the various 3rd party vendors (there is no primary vendor, analogous to Java's Sun) are moving toward ANSI support. There are many suppliers of Smalltalk systems.

    It does not define a stable runtime (developers can and generally do modify almost all the fundamentals of the system) making it hard for 3rd party vendors to sell add ons.

    Just because it's possible, doesn't mean people do it. Most developers won't touch Core/System (as it came with the initial install), lest they screw everything up. The people that do generally know what they're doing, and where it makes a difference, and are wise enough to know whether or not to do it. Making your claim irrelevant.

    A strong NIH mentality within the Smalltalk community. A good example was your GC argument. In fact, Smalltalk GC's lagged LISP GC's in much the same way that Java GC's have lagged Smalltalk.

    Are you saying that it is your response to reject Smalltalk over Java, even though Smalltalk may have a more mature GC, simply because some LISP dialects may have a better GC?


  • As you add stuff to your application you get a bigger and bigger image.

    Only when someone doesn't manage their image correctly. In the same way, you can have piles and piles of obsolete .pl, .C, .c, or .java files in your working directory. Many big shops use Envy, which manages applications well. When you're ready to deploy an app, just start with a clean image, file in what you need, and the packager will take out what you don't.

    The next problem was GUI. The GUI was 100% let's do it my way.

    While that was the case for the original Smalltalk-80, as well as Squeak, it's not the case for VisualAge for Smalltalk, Dolphin Smalltalk, and Smalltalk MT which all use native widgets. There's also VisualWorks, which tries to emulate a look and feel.

    Forsaking the hacker via cost is probably the single most killer and stagnation of a tool.

    I agree. Squeak and GNU Smalltalk are both quality systems which have a lot of hackability. Squeak may not be VA with Envy, but neither is Emacs and g++ the same as Visual C++.

  • To oversimplify, there are two big reasons

    • The first is that the syntax and the environment are a shock for people raised on file-based, statically typed, "edit it in vi" type of languages.
    • The second and more important are the business reasons. Smalltalk was doing quite well commercially in the early 90's, but mostly in the high-end corporate developer space, with costs of thousands of dollars per developer seat. IBM had a big push behind it. This frightened the two other big commercial vendors, who attempted to merge, failed disastrously, and left IBM almost alone in the market, a position it didn't want to be in. With the high-price policies there was no low-end or open source base to sustain it. Then Java came along and picked up a lot of the pieces.

    Nevertheless, Smalltalk has refused to go away. Significant open source efforts have started with things like Squeak [squeak.org]and Camp Smalltalk [campsmalltalk.com], and even in the commercial world VisualWorks has a free download [cincom.com] and Dolphin Smalltalk [object-arts.com] 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 [webgain.com]) to go work for Cincom [cincom.com] on Smalltalk development.

  • There exists (final/draft?) a new ANSI Standard for Smalltalk. Many of the various 3rd party vendors (there is no primary vendor, analogous to Java's Sun) are moving toward ANSI support. There are many suppliers of Smalltalk systems.

    Yup, there is the ANSI Standard for Smalltalk... how many decades after it's initial incarnation? and almost 10 years after Smalltalk had achieved a decent level of visibility in commerical circles. Too little too late. You also can't tell me that Smalltalk/MT and Visual Age are highly interoperable.

    Just because it's possible, doesn't mean people do it. Most developers won't touch Core/System (as it came with the initial install), lest they screw everything up. The people that do generally know what they're doing, and where it makes a difference, and are wise enough to know whether or not to do it. Making your claim irrelevant.

    Actually, it's been my experience that people do modify Object and Class in particular with great regularity. People also seem fond of hacking in changes to the events and exception systems. Even if they do know what they're doing it may have a subtle impact on a 3rd party library. More importantly, if you're a vendor of such a library, you have to allow for this possibility in your support model. This basically means having Smalltalk programmers on your support lines so they can evaluate changes to the image. Not exactly very cost effective.

    Are you saying that it is your response to reject Smalltalk over Java, even though Smalltalk may have a more mature GC, simply because some LISP dialects may have a better GC?

    Please try to read my entire statement. I was using the original posting's comments about GC as evidence of the strong NIH mentality that exists within the Smalltalk community. The gist of the argument had nothing to do with GC.

    Don't get me wrong, from a technical standpoint I love Smalltalk and lament the fact that it was not more successful. I'm just trying to outline the non-technical problems which have prevented it's success.

  • Actually, VisualWorks Smalltalk is more portable than even Squeak. With VisualWorks you get *binary* cross-platform portability, so a "port" of an application involves a simple ftp of the application to the new host machine. And VisualWorks is 2-4 orders of magnitude faster than Squeak :-)
  • Yeah - I wrote a symbolic algebra program on my C-64... that ran out of memory, so I took it over to the C-128... ah, sweet fast power.

    --
  • This is arguably good stuff. I could quible some points here and there, ultimately we'd degenerate into a discussion regarding Scott Adams ability to so avidly satire the business world.

    But what about outside of the conventional business world (which was the original question)? The open source/hacker/hobbyest/Linux community. Why not there?
  • I have written thousands of lines of Fortran, embedded C, poured over tons of Java and C++

    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.
    --
  • 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.
  • VW is quite a bit faster than Squeak and runs on all the platforms that matter (various Unices, Mac OS, Windows), but Squeak runs on more. Show me that port of VW which runs on bare metal, or on Acorn RiscOS and I'll shut up. :)

    Squeak is just as portable. In fact, last year, while I was learning Smalltalk, I would work on the exact same image file at home on my Mac OS/PPC and Linux/x86 boxes, and during slowtimes at work, Windows/x86.

    VW is cool, but for what I'm doing, Squeak's got some definately lovable features that you don't find in VW or other commercial environments (IMHO).
  • 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 [myhelio.com] and Agenda).
  • You've claimed to have used Smalltalk- can you elaborate one what's wrong with the IDE? Is it that it's different than the write-compile-run cycle of traditional languages? Most of those who have actually used Smalltalk believe it's IDE to be one of the best, perhaps only rivaled by those found on LISP machines.
  • That was my original intent in the submission, not so much why the business world hasn't adopted Smalltalk, but why the hobbist/open source crowd has not. It didn't come across clearly.

    For me, I don't care too much about the world of business. If the hobbists care about it, the business world will catch on eventually. I'm just awed when people rave about how great Java, and now C# are, bringing true innovation to the world of programming, making all of out lives as coders easier, when almost all of these ideas come from a language over 20 years old*!

    It's key that open source peeps pick up on the true beauty and power of Smalltalk. So many fellow hackers are so entrenched in the world of C and Perl, that things like Python can woo them to know end. ;) I'd just like them all to see what's even beyond Python.

    No, Smalltalk isn't for everyone, whether you be businessman or coder. Some people just like C and Perl (why- it's beyond me), but there are those who are looking for a better way that just haven't been exposed to Smalltalk, and other great languages.

    * Research on Smalltalk began around 1970, the first version being Smalltalk-72.
  • Maybe your Smalltalk bytecode interpreter optimizes scalar operations so they're not message sends; maybe, like most Java implementations, it does this with strings too. But it's still a fundamental organizational flaw that all of the looping constructs (for, while, etc.) are methods on Integer. Methods on Block rather than reserved keywords, maybe. But not on Integer.

    Also, call me old-fashioned, but the thing I miss the most is a filesystem. I can't use external tools like grep or find to search through my smalltalk code. I have "string search", but no "regexp search". I can't just take a file out of the Makefile and re-link to get the standard version of stuff; I can't even have two different files with different versions of something and switch between them easily. Unless I've bought Envy or some other version control tool, and even then it's not nearly so easy. It probably takes a version control tool to tar up one of my several programs and send it to someone else...

    "Browse Senders" is a cool feature, but for all I know it's not smalltalk, it's just the VW IDE.

    To say nothing of the fact that Smalltalk programmers are scarce enough, and Smalltalk is unpopular enough, that maintaining and developing on our Smalltalk code falls to the kids fresh out of school who don't know what they're doing even if they were taught OOD principles. (It's not just that it's unpopular; its unpopularity perpetuates its unpopularity.)

    For my projects, either I want a quick scripting language (in which case I might make it past sh or awk to python or perl), or I need something big enough that I may as well pull up C++ or Java. And if the project's big enough that it isn't a trivial procedural task, I can do a good design to start with, and implement that in the language of my choice, OO features or no OO, OO design or not. OOD's just the latest crutch/club to try to force people into thinking about design, plus the first major crutch/club to get people to do good abstracion on the way to loose coupling between modules.
  • So... have you experienced this personally, or just convenient FUD to back something you want to believe. Just curious.

    The whole speed thing is amusing. Ken Auer once gave a tutorial where he pointed out that the big speed gains are usually to be had from new and innovative ways to solve the same problem. While at the same time, compiler writers spend lots of time eeking out funky tricks and getting excited about a few percent here and there on a spec benchmark.

    So take a problem that just fundamentally breaks down well as an object solution involving lots of message dispatching. Smalltalk will do well. Very well. As the message dispatch get's more and more dynamic, as the program gets larger and larger, Smalltalk will outperform the same C++ code.

    I know, your going to argue that it's just another turing complete language, and you can code it in raw C just as well, and when you finally get done, the C version will be more efficient. I will not argue this. That's if you ever get done. Alan Kay tells of Apple's "Pink" project. This was to be a revolutionary OS design. He wanted them to *at least* use Smalltalk to prototype. They wouldn't; said it was too slow. But development was slow and lots of technical hurdles. And lack of progress ultimately got the project canned. He closes with the punchline, "There's not a lot slower than never done."

    Back to the new algorithms thing. It has been *my* experience that for many problems, Smalltalk allows me to think and program at a level that allows me to approach problems in a way that I just wouldn't have thought of/dared implement in C. We had a problem at work which was basically an (N^2)! algorithm. It was a real drag. It was burning over 800 seconds for 1000 inputs. So we worked out a brute force C implementation. It ran faster, like 100+ seconds. It was just a faster brute force version. Then I spent a little time looking at the ST version, began noticing some things. Noticed the problem was separable, could be pipelined and thus take advantage of some intelligent caching. It involved a specialized Dictionary implementation. Reduced the problem to N2 + N, at which point we dropped down to ~30 secs for the ST version. What was cool was how well it scaled. 4000 inputs, the brute force version (in either lang) fell apart. The optimized ST version ran fine (~280 secs). Experienced the same kind of thing with a document matching algorithm. Today we use it in image processing apps. Sure, ST stinks at batch byte bashing. But the lang is extensible, and adding your own primitive types with optimize primitive ops is easy. We're coming up with image processing algorithms that are competitors just can't. They can't abstract fast enough, they can't try new things fast enough.

    I do admit, that for people that don't get objects; Smalltalk is totally unforgiving. Your code will be spaghetti, and run like a dog. But once it sinks in... :)
  • OK, your're old fashioned. The thing I miss least is the filesystem, and make, and linking, and compiling, and running the debugger separate and using grep etc. :)

    As for greping... Don't have VW up and running on this machine right now, but
    load the RegExp parcel, and do something along the lines:

    | exp |
    exp := 'some regex statement' asRegEx.
    Browser browseMethods: (CompiledMethod allInstances select: [:each | exp match: each source]) asSortedCollection.

    2 lines. As for browse all senders... er, that's written in Smalltalk, because if you'd gotten past any initial VW hurdle, you'd know that VW is written and runs in itself. You'd know that all of the code is right there. And that you can extend it, like maybe adding a menu option to do your regex search.

    So, when you get done hacking your integrated filesystem/grep/regexp system together, with just a few lines of code that you can send as your buddies that they can just filein to their systems on the fly and improve their lives...

    Call me new fashioned I guess. :)

    And finally, we'll have to disagree on the organization flaw. Smalltalk is about messaging. Get Alan Kay's OOPSLA'97 KeyNote. It is totally appropriate, that even the everyday stuff, like looping and branching and arithmetic is ALL done via messaging. See, at the heart of most programs, they still do a lot of these sorts of things. And if there is benefit to be had from the messaging paradigm, then wouldn't you want it applied centrally, where it could have the biggest impact, not just the stuff on the edge?

  • I have never programmed in Smalltalk. I have no comments about the development environment, since I've never used it... but I've installed and maintained IBM's Visual Age for Smalltalk on AIX. I have some comments that I need to make, lest people actually use it.

    IBM's Visual Age for Smalltalk is, hands down, the worst piece of shit commercial program I've ever laid eyes or hands on.

    Let's start with the name. "Visual Age for Smalltalk". It sounds like an add-on product -- something that you'd install after you've installed Smalltalk, to add a GUI, right? Wrong. It is the Smalltalk compiler. And it is the GUI. And it is the runtime interpreter thingy. They're all inextricably entwined. (And yes, I'm pissed about the name because I wasted a good 30 minutes one day trying to find "Smalltalk", not realizing that "Foo for Smalltalk" is "Smalltalk".)

    Right, then. Let's move on to the installation.

    • You cannot install it from a command line. The installation is GUI. So you can't dial in from home for the installation -- you have to drive to where the computer is! Wow, just like Winders!
    • But wait, there's more! You can't install it if your X $DISPLAY is pointing to a Linux workstation! If your X display isn't pointing to an AIXwindows display, the Smalltalk installer goes into an infinite loop and spews an unending stream of incomprehensible error messages! Nifty, eh?
    • Oh, but wait! You thought AIXwindows would be enough? Wrong-O! You have to be running The Common Desktop Environment(TM) on the AIX display! If your X display points to an AIXwindows workstation that's just running plain old twm or fvwm or something, you get the unending stream of incomprehensible error messages all over again! So now you get to dig up an AIX CD set and install a whole bunch of crap you didn't want, just so you can begin the Smalltalk installation. Thank you sir, may I have another!
    • Now, to appreciate the Smalltalk installation in its full glory, be sure to open an AIXterm(TM) and run top (which AIX doesn't include, but which can be found with a few web searches). When you fire up the graphical installation program, the first thing you'll notice is that it runs a program called es. That's the Smalltalk runtime interpreter thingy which Smalltalk programs can't live without. More on that below. The second thing you're likely to notice (once you've typed in all the passwords to unlock the proprietary software) is that the es program goes into a busy loop and sucks up all the CPU time while it's not doing anything at all! (The Smalltalk installation uses the standard AIX package management software -- which is pretty decent (comparable to RPM in power, not as good as dpkg/apt-get) -- to install a few packages. The Smalltalk program busy-loops while it waits for the package installer to finish.) Wow, impress me some more!

    OK, so it's installed, kinda. But it's not running yet. So how do you start it up? First you've gotta run a program that spits out a magical "device number". This is a simple two-digit number in square brackets, in the middle of a line of text. You need to extract that number and then feed it to another program as a command-line parameter. Why couldn't they automate this? Any sysadmin who's ever picked up a copy of O'Reilly's Sed and Awk could automate this in less than a minute! But could IBM's brilliant programmers figure this out? Hell no!

    And wait... what's this? Why am I being prompted for my root password in order to shut down the Smalltalk daemons? Hello?!? I'm already root! I've been authenticated by AIX, as you can see by calling geteuid()! So why do I have to embed the root password in a shell script if I want to shut down Smalltalk gracefully at reboot time? Fuck it, let it die.

    Oh, but you haven't seen the best parts yet! Smalltalk doesn't use the AIX/Unix file system! Not at all! You can't open a file! You can't transfer your source code from one machine to another! All of your source code is contained within a gigantic (hundreds of MB) binary file along with everyone else's source code! If you need to install Smalltalk on a different computer, and transfer the source code, you get to copy this nearly-half-a-gigabyte binary file that you can't read. It's all or nothing.

    And since Smalltalk uses a runtime interpreter thingy, you can't build native applications. If you want to build a Smalltalk program to run on another machine, you have to ship a copy of es (remember him? the one that busy-loops during an install? and requires CDE? and can't exit gracefully if CDE isn't there?) with your program. And I have no idea what sort of license this es guy is under. I don't think I want to know. If I wanted to use a scripting language, I'd use sh or perl!

    Let's see... what else is there.... Oh yeah, the bugs! Despite the fact that Smalltalk's installer uses the standard AIX packaging system, the bug fixes are distributed as either tarballs, or replacement copies of the executable files. So much for the integrity of the packaging system! (And don't go thinking you can use it without those patches, either. Out of the box, Smalltalk is completely broken on SMP systems. And don't even bother to ask me why it cares how many CPUs are in the box. It's probably an embedded operating system or something. That would certainly explain why it has its own fucking file system and its own internal concept of device numbers (which have nothing to do with Unix major & minor device numbers), and why its developers can't master sed.)

    The good news is, I'm no longer assigned to that site. But when I see someone mentioning Smalltalk, it still brings back the horrible memories.

    Wanna know why I don't wanna learn Smalltalk? This is why!

    Thank you.

  • On The Fly Programming:

    You might be interested in a long post [egroups.com] 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.

  • That's pretty funny. For integer math Perl is very slow, as internally it's doing all math using double-wide floating point.
  • 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.
  • I don't have anything to add, but I would like to say that your article was good. I enjoy a good rant just like some folks enjoy watching wrestling, and yours was particularly good.

  • 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.
  • 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!
  • I don't know why people describe Smalltalk as inefficient. If this statement is true, then only because Smalltalk runs on a VM and is fully OO - just what Java claims to do. And my experience is that Smalltalk really runs much faster than Java, plus it's quite easy to connect to shared libraries for further speedups (although this of course infringes portability). You can't really compare Smalltalk or Java to C++ when it comes to performance. But develloping applications is much easier in Smalltalk than in C++ - it should not take half the time, plus there should be less bugs because of the great debugging facilities and the easy to learn syntax.
  • I agree with the point about marketing etc... But I completly disagree with the statement on existing code. I believe there is more smalltalk code to reuse and build uppon than all of the internet C's code. That's partialy what smalltalk is about. Talk Small and carry a big class library. Above that, most of the code in encapsulated which just simplifies the process if reusability. I think it all has to do with smalltalk no having the syntax that C does so people don't want to learn. But any oldie OO would knows that for reusability or implemented code Smalltalk is the way to go And another thing. It's not popular that's true but that doesn't mean that companies don't use it. Plenty of companies use it or the benifit and not just because they've invested into it in the past and now don't have enough money to switch. For instance IBM. Why would IBM be constantly updating it's Visual Age Smalltalk environment if the didn't like it? And why would they creat their Visual Age Java environment IN Visual Age Smalltalk if they didn't like it?
  • 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 ...

  • 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

  • You seem to have your definitions confused. While Smalltalk is certainly not statically typed, it is not "weakly" typed either. Smalltalk uses strong, dynamic typing (objects never change there types, while variables are typed at runtime). Weak typing refers to languages where objects may be easily cast from one type to another (as in C).

    Most of the major commecial Smalltalk dialects do detect a variety of "type" related errors at compile time. Smalltalk syntax actually helps you avoid many kinds of type errors that are common in other languages. It is absolutely untrue that Smalltalk apps have more errors at runtime or require more debugging. That is nothing but uninformed FUD.

    Smalltalk runtimes may be heavy or light depending upon the dialect. For most dialects, the runtime requirements are a lot less than they are for Java. Several Smalltalk dialects run reasonably well on 4MB 386 class machines and run extremely well on almost any hardware from the last decade.
  • Smalltalk *has* a real standard. It has one of the most extensive standards of *any* ANSI standard langauge (it is neither small nor "pitifull"). Java doesn't even have that (and may never have that, if Sun has its way).

    AWT and JDBC are no more standard than any Smalltalk vendor's GUI or DB class libraries. Both are proprietary to Sun (and will likely remain that way).
  • I've been using VisualAge for Smalltalk for several years, and I believe it is one of the *best* commercial development environments I have ever seen. I have never used the AIX version, but I have used the Windows and OS/2 versions. Both were very easy to install and a joy to use.

    As far as the name goes, oiginally it was just "VisualAge" (VisualAge for Smalltalk being the first member of the VisualAge brand). When IBM extended the brand to cover additional languages, you ended up with VisualAge for Java, for C++, for Smalltalk, etc., etc.

    Basically, your comments boil down to the fact that you don't want to learn Smalltalk because you don't like the installer on one particular dialect. Fine. The VisualAge Smalltalk AIX installer probably could use some work, but that doesn't have anything to do with Smalltalk itself.
  • Most looping constructs are *not* methods on Integer. Most of them are methods on Collection or Block. The few that are methods on Integer are infrequently used relative to the rest of them (and the ones that are Ineteger methods make sense to me there!).

    As to "regexp" search, that's fairly easy to come by in almost any Smalltalk dialect. Most commercial Smalltalk products *do* come with some form of source code control/versioning system so switching between different versions of code is *very* easy. ENVY is actually built into VisualAge Smalltalk.

    "Browse Senders" is entirely written in Smalltalk as is the rest of the VW IDE (and every other Smalltalk IDE).
  • Yes, I have seen several Smalltalk implementations that are *very* fast (and, no, Squeak isn't one of them). IBM's VisualAge, Cincom's VisualWorks and ObjectStudio, VisualSmalltalk, Dolphin Smalltalk, Smalltalk/X and Smalltalk MT are all quite fast and more than sufficient for almost any programming task. All of them make it easy to drop down to C in those rare occasions when Smalltalk isn't fast enough.

    As far as the Squeak Postscript problem, that is an *application* issue, not a Smalltalk issue. My guess is that the student was just using string concatination rather than streams...a common newbie/student error. That does not indicate any "fundamental design problem" in the language since you could have the exact same problem in almost any language.
  • 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*
  • 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.
  • While the bigest gains may come from choosing the right algorithms, in the real world it's often vital to choose the right algorithms _and_ choose a language which can be efficient and use the idioms which make it efficient. For tasks where performance is critical, choice of programming environments is restricted. For the many tasks where an extra 100ms doesn't matter, use whichever language lets you develop solid software most quickly. And if _anyone_ ever tries to persuade you to choose a particular language for a commercial project on purely technical grounds, ignore them. The availability of expertise and good development systems is usually more important than most technical issues.
  • FWIW, I'm a software developer for Purdue University (on the business side of the university). Our entire SSINFO system - registrations, class schedules, and more run on Smalltalk (with web-based and desktop-based interfaces). We now have a 9 year project in place to move all student systems (student aid, bursar, god knows what else) to this Smalltalk system. Already the investment we've made in reusable code is paying off.

    I'm moving to that team in Jan. as it atttracts, IMO, the best developers in the department. They go on and on about Smalltalk and how great it is. After almost 4 years, it's finally sunk in and I want to see it. I've definitely had enough of Oracle PL/SQL and PowerBuilder. Hold me back!

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

Slashdot Top Deals

"Protozoa are small, and bacteria are small, but viruses are smaller than the both put together."

Close