Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Smalltalk Solutions 2001 Trip Report 99

Posted by timothy from the gayle-force-winds? dept.
John Squeaker writes: "Last week while the rest of the world was worrying about corporations warning, and dot coms failing, 300 smalltalkers got together in Chicago to plan for the future. Given the fact corporations like Dell have canceled their user conference this year we were very pleased with the attendence figures. The conference hosted a key note by Alan Kay, a *must* read, and the mood and general feeling of the show was captured in this excellent trip report. More information on the conference plus links to the papers/tutorials presented there can be found at the conference site. Do you want to know where OO languages like Java, Ruby, Squeak, and SmallScript come from? Then come visit us for the real story, and see what you can expect to hear in the next five years." The whole thing is interesting, but I particularly liked Tuesday. Smalltalkers seem to have a secret from everyone else sometimes ...
This discussion has been archived. No new comments can be posted.

Smalltalk Solutions 2001 Trip Report More

Smalltalk Solutions 2001 Trip Report

Comments Filter:
  • How about the web-based application that Purdue students use to get class schedules, vote on issues and student elections, order concert tickets, get grades, get transcripts, get exam schedules, arrange for housing, and pretty much do all of their interaction with the university that doesn't include actually attending class? Yep, it's SSINFO [purdue.edu] and it's all (VisualWorks) Smalltalk, all on the web. The project is expanding over the course of 9 years to include financial aid and a host of other applications. Come to Purdue - home of Gene Spafford and some serious cutting edge software development.

  • I have been a big fan of Alan Kay's for years, so I read the story and many of the links even though I've never done smalltalk. I was encouraged by the report [smalltalkconsulting.com]. Reading the content, I thought: I wish I were as idealistic as Alan: It's immoral to build systems that aren't deconstructable. It's not just about making money. and Children are the message we send to the future.

    Then I read his bio and saw he is Vice President of Research and Development for The Walt Disney Company. Disney is evil. Alan is living a lie.
  • It is not possible to evaluate a language without seriously trying it out. Learning a new language is usually a mind altering experience, especially with Smalltalk.

    You can't miss what you don't know about.

    On Perl: Perl's power comes from it's reflexivity. And Smalltalk is almost equally reflexive except in a cleaner and more systematic way.

    ----
    INTP

  • A couple of Qs:

    1) the oopsla 99 BOF on Squeak had a fun presentation on the new Jitter for squeak -- written in a weird self interpreting style, IIRC. It seemed pretty cool. (also one of the best stories on what to use C++ for. "C++ is a great language for implementing langauges to solve your problem". Interestingly, this is the same story many of the functional programming people sing, only they use bigger words like monads and combinators) How is this jitter coming along?

    2) I also seem to remember a product that compiled smalltalk to JVM bytecode. They were very cagey about how they would get around the dispatch issues without resorting to reflection. Any word on this?

  • Re:How about some Bigtalk (Score:3)

    by Spiritwalker ( 109806 ) on Wednesday April 18, 2001 @08:17AM (#283269) Homepage
    Indeed, VisualAge Smalltalk and VisualAge for Java are both written in Smalltalk. The portability of the OTI implementation allowed VA/Smalltalk and VA/Java to be shipped on Win32, OS/2 (oohhh), and Unix's. The VM was also responsible for running a Tectronic oscilloscope. Just some of the examples of successful ST products.
  • back pointers? I suppose you mean a collection of weak references.

    which languages implement this, outside of the DB world (where you could argue it is explict as well, being stored in a table) or UML (which so far has resisted all attempts at being executable)?
  • Yes, Smalltalk has been around for awhile, but it is still the source of new ideas and trends in certain areas. For example:

    Extreme Programming. The extreme programming [extremeprogramming.org] (XP) methodology grew out of a Smalltalk project 3-4 years ago. The founder of extreme programming, Kent Beck [c2.com], advocates Smalltalk as the most productive language for XP, as does Ron Jeffries, the author of the Extreme Programming Installed book.

    Refactoring. The term "refactoring" has become popular in the last few years, due in large part to the work done on the Refactoring Browser [uiuc.edu] for Smalltalk by John Brant and Don Roberts. (Martin Fowler's book on Refactoring includes a section on the Refactoring Browser.) The Refactoring Browser lets you perform automated behavior-preserving code refactorings, such as abstracting references to an instance variable, pushing a method up into its superclass, etc. (There have also been some refactoring tools written for Java, but the nature of the Java language will make it difficult to create a tool as powerful as the Refactoring Browser for Smalltalk.)

    IDE's (Integrated Development Environments). Smalltalk has generally been considered a leader in this area, with its integrated code browsers, the ability to reliably look up all senders or implementors of a method, etc. (There is the occasional effort in other languages to catch up in this area, such as VisualAge Java with its integrated browsers, but VA/Java was also written in Smalltalk.) Also, to shamelessy toot my own horn for a minute, I've created an object-oriented "stacking" code browser for Squeak/Smalltalk called Whisker [mindspring.com]. I used Smalltalk to create this because the IDE supports this sort of experimentation well.

    So, to claim that Smalltalk is somehow dead or obsolete is obviously false. True, it doesn't have the marketing hype (and market penetration) that Java does, but then, what else does? :-)

    (Also, I still consider the language features of Smalltalk to be more technically "advanced" than those of Java. My personal hunch is that if you conducted a random poll of developers with *significant* experience with both languages (say, a minimum of 1 year full-time experience with each), probably 90-98% would agree with this. Of course, the same is probably true of Scheme vs. Java, or CLOS vs. Java, etc.)

    Anyway, Smalltalk is obviously not the answer to all programming problems. (I wouldn't use it to write a device driver, for example.) But it is still one of the best (if not *the* best) options for many larger programming problems.

  • 6) "just catch messageNotUnderstood"... If it's that easy why isn't it built into the language? (Of course it isn't, quite that easy.) But we're talking about mistakes in the language, not hacks to get around the mistakes in the language...
  • (contained objects don't know about their containers unless you create an explicit link back to the container. That makes instantiation in context more complicated.)

    That's what weak dictionaries are for: they allow you to create such bidirectional associations easily.

  • I thought this was funny too. But I'm not sure I get the reference.

    It sounds like Hunter S. Thomson though.

    Gonzo programming?
  • Disclaimer: I've used Smalltalk for about a year, but haven't used Cocoa that much (except for toy projects). Here's my take:

    You can think of Smalltalk as a simplified Objective-C, say a "script" version (even though the evolution happened in the opposite order). So, there are no types in your code; there's no reference counting garbage collection to worry about, no header files - no files at all in fact. There are no protocols, no categories or poseAs: (although the latter two aren't really needed, since you can simply replace the class in the image or add to it). The equivalent of writing a category on NSObject, say, is just to add methods to the Object class. forwardInvocation, sure, Smalltalk has doesNotUnderstand:.

    One of the nicest features of Smalltalk, which I really miss in Objective-C, is blocks. You can put any code in brackets and have it be sent as an argument to a function. Blocks can take arguments, so they can be used for iteration (collection do: [ :each | each doSomething]) - or for storing actions, which Objective-C usually does with selectors (i.e. when you're doing something in IB). And there's no compilation; you interact with and change your code and objects while they're running. That's probably the best performance enhancement there is.

    There is a version of Objective-C with blocks, called POC (http://www.ibiblio.org/pub/Linux/devel/lang/objc/ !INDEX.html). I don't know how (or if) it's compatible with Apple's compiler though.

    Programming Cocoa in Smalltalk would absolutely rock. For applications that aren't hugely performance-sensitive, it would be far superior to things like REALbasic. The GUI frameworks of the versions of Smalltalk I've used (VisualWorks and Squeak) tend to be a bit rough around the edges; whereas NeXT stuff has been more carefully designed and evolved. Apparently there are some nicer frameworks for VisualAge Smalltalk, but I've never used them.

    Part of my problem is, after using Smalltalk, a lot like using the Mac, it's really hard to go back to something else. You just start to notice how complicated, inelegant, downright SLOW developing in another language is. Having to keep all your data structures in your head, guessing how they'll respond to something while you're writing code, is such a pain - when in Smalltalk, you just send the objects messages, see what happens, and when you have something that works, just put it in your code! (Granted this is not unique to Smalltalk, you can do it in any language with the appropriate runtime support, it's just that with Smalltalk it's all there to start with.)

    And sorry, I've never used CLOS or OCAML :-(
    --
  • The problem with JavaScript is not lack of expressive power; it has plenty of that. It is poor scoping rules, poor error handling, serious limitations on available APIs, and subtle differences among implementations. If TIBET manages to work around some of those problems, that would be great. But I have my doubts. I guess we'll have to see.

    But a prototype-based scripting language with JavaScript semantics isn't very Smalltalk-like. Smalltalk has much better development tools, better APIs, and better error handling. It can also be compiled more efficiently.

  • Like so many things that recently have made a splash (extreme programming, refactoring, patterns, etc.), this is really just giving a name to programming practices and ideas that have been around for two decades. Smalltalk was one of the languages where such ideas originated (Lisp was another major one), they just didn't originate recently.

    Right... it's a good thing that a name was finally given to these practices, though.

    Quite to the contrary. While Java isn't as convenient to program in as Smalltalk, the additional type information that Java source code contains lets you do more kinds of refactoring safely. In fact, one of the reasons refactoring has not been such a big deal in the C++/Java world is because static type checking in those languages already helps you with a lot of refactorings. ...

    True, it does cut both ways. The main thing in Smalltalk's favor is the simplicity of the syntax (e.g. there are only 5 reserved words), which makes things a lot easier for the writer of the refactoring tool. And also the fact that you don't have primitive types vs. objects to worry about. But static typing helps Java refactoring. (Declarations like public/protected/private and abstract probably help too.) Still, my impression is that the Refactoring Browser for Smalltalk is still the most powerful one out there. I'll have to take a look at jFactor to see how it compares, though.

  • a contraire.
    HotSpot JVM tech is adapted dynamic compilation created in the Self project 89-94. Self is a Smalltalk dialect from sun research (http://www.sun.com/research/self/).

    Squeak runs on PPC, X86, StrongArm, Mitsubishi... a basic VM port is supposed to take 2 weeks, though I haven't done one.

    It's true that standardization was never a strength, but a standard now exists and compliance tests+changes to existing platforms are being done. Not that I see how this is an interesting problem, at least technically...
  • Where is that link to the Smallscript stuff. Ah, here it is The Smallscript Language and Platforms [smallscript.org]
  • Not that this is a very good example, but I did get to play with the TIBET workspace (itself in a web browser window) at a recent demo of a preliminary version of the system. After a bit of instruction, I entered some code to explicitly generate HTML in an ad hoc fashion into the workspace text area. I wanted to create a primitive class browser (the TIBET "classes" are called "types"). It didn't use any of the TIBET widgetry so the HTML construction is rather escapish, but it does show some of the Smalltalk flavor. It went something like this:

    typeHTML=TPMutableString.create();
    typeHTML.concat('<form><table>');
    TPObject.getTypeMethodNames().sort().perform(funct ion(elem){typeHTML.concat('<tr><td>',' <input type=button name="',elem,'" value="',elem,'" onClick="',elem,'.getMenu()">','</ td></tr>')});
    typeHTML.concat('</table></form>');
    newwin=window.open();
    newwin.document.open();
    newwin.document.write(typeHTML);
    newwin.document.close();

    Then I clicked the EXECUTE button on the workspace and, as expected, a browser window opened up with a column of buttons named for the various TIBET types. I didn't define the "getMenu" method so it didn't actually work, but it wasn't bad for just sitting down and messing around for 10-15 minutes.

  • Correction, that was creating a method browser -- not a class browser because the "getTypeMethodNames" method returns the names of all methods that have been defined. If I had wanted it to work, the getMenu method would probably have to have been defined as an instance method on the TPMutableString type which would generate HTML for a menu of all types that implemented the named method.

    Not exactly first top notch factored design, I know.

    Such is the fate of a first-time workspace doodle.

  • Amen, brudda. About Smalltalk in general and Dolphin in particular. I've managed to solve problems in Smalltalk I could never get my head around in languages like C++. Take a look at http://www.nls.net/mp/jarvis/Bob/DolphinGoodies.ht m where you'll find my framework called "SmallWorlds" for implementing text adventure games like the old Colossal Cave game that a lot of us wasted a lot of time on (oops, make that "did a lot of research on" :-) in college. I futzed with this stuff on and off for years, attacked it a few times (in C, Pascal, and C++ IIRC), but never got it actually working until I tried Smalltalk.

  • T_f_J, you're entitled to an opinion, of course, but your vocabulary in itself demonstrates the problem. To serve the economic and egoistic purposes of various Influential Entities, programming languages have become like car styles and Parisian fashions. Who judges that a programming language "belongs in a by-gone" era? What's the basis for that judgment? Is it that it hasn't a Roy Oily animal character and book assigned it yet? Is it that there's no John Wayne icon picked for it? Surely, a programming language is judged based upon the readiness with which its practitioners can build real systems [cincom.com] while keeping an eye on long term costs and adaptability to changes in requirements.

    If popularity were the test of achievement, then Visual Basic is (and remains, despite some deflation) king of the hill. You can't really mean that.

    Most people who embrace Smalltalk have tried many other languages in professional contexts and are simply compelled to use it [object-arts.com]. There are lots of reasons why programmers unfamiliar with Smalltalk are missing out, even if they don't or can't use it. It's a powerful idea [barnesandnoble.com]. I've described some of these [algebraist.com] in a letter to the editor of Dr Dobbs [ddj.com] about a year ago. Smalltalk repeatedly surprises even its afficianados with rediscovered power and grace.

    And if you want to see some of the other reasons Smalltalk wins, check out John McIntosh's site [whysmalltalk.com], Peter Lount's place [smalltalk.org], and the nifty (IMO) Dolphin Smalltalk [object-arts.com].

  • IB wrote:

    I think Smalltalk's biggest problem by far is that it's too insular. It's hard to talk with the rest of the world, or interact with what other programs are doing in other environments. That's the price of elegance, I suppose -- purity only comes when you won't sully yourself. But it's hard to work with.

    Ian, you're kidding, right? I find Smalltalk much easier to work with than, e.g., Java when working with, say, relational databases because at some level in Smalltalk the cursor is just a pointer to a Collection of some kind. With Java, the writer of a query is obligated to decompose its result set rows down into Java typed variables 1-1 with their SQL counterparts, whether the class doing the query really "cares" about that level of detail or not. For instance, blobs are really problematical. The corresponding Smalltalk interface might need to do some conversion of types to standard form, but that can be built into the database API.

    The same is true regarding interactions with results gathered by code from other programming languages.

    Ian, I'm not sure what you mean by The runtime environment is just too limiting (Smalltalk over FTP?). Do you mean what's come to be known as distributed Smalltalk, or synchronous, remote procedure calls via message passing, or asynchronous method calls?

  • When I say Smalltalk is too insular, I mean in the really simple ways. Like, developing Smalltalk code when you can only access the server with shell and FTP access. It's hard to partition -- you can't easily split the Smalltalk application from the giant environment that comes with it. How do you ship an application based on that?

    Yes, these things can be done (well, I still don't know about developing Smalltalk code and uploading it), but they can't be done easily. This is the sort of thing that comes almost for free when you use C or Python. But just getting started can be a royal pain in the butt with something like Smalltalk, or heck, even Java.

    I spend an inordinate amount of time dealing with the environment already. (inordinate being anything more than zero -- but in practical terms it can be quite high)

    I can learn new things -- any decent programmer should enjoy learning all sorts of new things -- and when I learn them I know them. I'm always moving forward (even though expectations always increase). But with the environment stuff I always feel like I'm wasting time, and that the time I spend I'll just have to spend again when I move, or set up something new. I guess it's time spent that would be considered accidental, rather than essential -- and it's totally unsatisfying.

    It's petty, I know, which is probably why I sound really annoyed in this post. It annoys me that petty things create serious blocks to being able to use something cool. I wish it weren't so.

  • Ah yes, a newbie. I suggest you go read the FAQ.
  • Can anyone provide a URL to any real world work done in Smalltalk? Or is it just an abstract base language for the other OO tools named in the posts?

  • Some of us use it (Score:5)

    by hding ( 309275 ) on Wednesday April 18, 2001 @04:26AM (#283288)

    I have to do some of my development in Windows, and boy was finding Dolphin Smalltalk [object-arts.com] a nice thing for me. And no, I'm not some holdover from the 80s - when I started to do programming in the past couple of years (my training is really in mathematics; I wound up here via a winding path), I looked into various languages, tried them out for some of the things that I need to do, and found that two "old-timers" languages (Common Lisp and Smalltalk) fit many of my needs (which, incidentally, are not at all exotic - I do programming for a small trading firm).

    It's a shame that so many people have preconceptions about various languages (often formed on the basis of where they were twenty years ago rather than where they've advanced to today) and therefore avoid checking them out to see what good things they can do.

  • Where Java came from. (Score:4)

    by Carnage4Life ( 106069 ) on Wednesday April 18, 2001 @04:37AM (#283289) Homepage Journal
    The story submitter states:
    Do you want to know where OO languages like Java, Ruby, Squeak, and SmallScript come from?

    Although it is true that Java is heavily influenced by Smalltalk, there are also distinctive parts of Java that are based on Modula [compaq.com]. Most prominent of which are the Exception handling mechanism [cs.sfu.ca] and threading model [uni-siegen.de] based on Monitors.

    --
  • At one point, a bunch of banks were using it to do front-ends for employees, etc. in front of IBM datasystems. It apparantly had a presence in financial. IBM had (they may still sell) a really nice VisualAge Smalltalk development environment. The IDE from this product actually migrated out into IBM's other development tools, if I remember correctly.

  • Not so, Joe! (Score:3)

    by werdna ( 39029 ) on Wednesday April 18, 2001 @04:43AM (#283291) Journal
    Language bigotry has no place in this forum, particularly when propounded in a naive and uninformed fashion. The author of the comment has apparently not built too many enterprise back-office systems, a venue in which Smalltalk has yet to be surpassed, or been following the extraordinary work at Disney R&D with Squeak.

    Smalltalk has its place in the cannon, just as does Perl and other languages. It has aged quite well, in fact, among those who have taken the time to learn something about it.

    The bigots are free to their own views. I commend to the rest of us, however, a second look. Consider Squeak, an excellent, modern and free Smalltalk implementation. Play with it a bit, and see if you don't begin, at least, to "get it."

  • After 14 years of working with it ... (Score:4)

    by crovira ( 10242 ) on Wednesday April 18, 2001 @04:44AM (#283292) Homepage
    I can report that Smalltalk it the best computer language out there despite its only flaw (contained objects don't know about their containers unless you create an explicit link back to the container. That makes instantiation in context more complicated.)

    It consists of a few fundamental rules, ruthlessly applied and a huge library of functional objects.

    I have done things in Smalltalk that are years ahead of what I accomplished in previous languages (C, COBOL, PL/I, APL, BASIC etc.) because the environment is reflexive and additions are interactive.

    Its not that I couldn't have done all this, even in assembler, but that I'd still be scratching out code and waiting on compile-links. With the Smalltalk IDE it was there waiting for me to use it and to build on it.

    The closer other languages and IDEs get to where Smalltalk was (because its a moving target,) the better Smalltalk looks.

  • IBM's Visual Age IDE is written in Smalltalk (yes, even the Visual Age for Java IDE, although I believe they are trying to move this to Java).

  • How about a single substantive argument to that end? Perl is useless for Object-oriented design. Python is better than Perl in this regard, but different, in many ways.

    Have you anything to offer us but a conclusion?
  • I gathered, inferring mostly from Stroustrup's writings, that it is an academic tool requiring a few ponies under the hood to peform reasonably.

  • Squeak does have some rough edges since it is mostly a research platform (although companies (other than Disney) are starting to use it for real world projects). However, to prevent your comments on Squeak from being generalized, I have some objections to your rant:

    And don't ask them to try and learn the language either, because there's no documented API, and the purportedly self-commented code really isn't.

    Learning Smalltalk is probably the easiest thing in the world, if you know the conceptual OO stuff, which is the same as for Java,C++,CLOS,... There are only 5 reserved words (true, false,nil,self,super). It literally takes you half an hour to learn Smalltalk syntax.

    Since Squeak is mostly a research platform, the code might not be documented so well in some places. However, you have superior code browsing in every Smalltalk IDE and the entire code of your library is open source. So you do not only have the comments to the code, but also the code itself, if you care. BTW, the Smalltalk frameworks have been refined for over twenty years now. Talk about clean frameworks.

    Also (and yes, I realize I'm reaching here), but the syntax is all backwards. It's not sufficiently like natural laugnage to be easy for beginners to use, and it just frustrates experienced programmers used to nearly every other language (i.e., based on C).

    I came from C++ to Smalltalk and I cringe whenever I have to go back. Smalltalk code is readable as almost normal text, whereas you often do not see the forest for all the parenthesis in C++ or Java. For example:

    In Java:

    ...
    synchronized (this) {
    while (aNumber > 0) {
    try() {
    wait();
    } catch (InterruptedException) { ... }
    }
    TheCriticalCode
    }
    ...

    The equivalent in Smalltalk:

    ...
    self synchronized:
    [ self waitWhile: [aNumber > 0].
    TheCriticalCode ]
    ...

    Squeak might not be what you want for normal product development (checkout VisualWorks [cincom.com] or one of the other 8 commercial Smalltalk implementations), but within the Squeak world, certainly the most exciting stuff is happening.

  • The extreme programming (XP) methodology grew out of a Smalltalk project 3-4 years ago. The founder of extreme programming, Kent Beck, advocates Smalltalk as the most productive language for XP, as does Ron Jeffries, the author of the Extreme Programming Installed book.

    Like so many things that recently have made a splash (extreme programming, refactoring, patterns, etc.), this is really just giving a name to programming practices and ideas that have been around for two decades. Smalltalk was one of the languages where such ideas originated (Lisp was another major one), they just didn't originate recently.

    (There have also been some refactoring tools written for Java, but the nature of the Java language will make it difficult to create a tool as powerful as the Refactoring Browser for Smalltalk.)

    Quite to the contrary. While Java isn't as convenient to program in as Smalltalk, the additional type information that Java source code contains lets you do more kinds of refactoring safely. In fact, one of the reasons refactoring has not been such a big deal in the C++/Java world is because static type checking in those languages already helps you with a lot of refactorings. For example, in Java, if you change an interface or move instance variables around, the type checker will point out every single place that you need to change. If you use a good IDE, you can breeze through those places and a refactoring only takes a single edit, compile, edit cycle. You still need to make the changes by hand, but that's pretty quick, actually faster than any of the refactoring browsers I have used in many cases.

  • Until Microsoft releases Visual SmallTalk tm
    Or is that redundant?
    -----------------
  • Smalltalk suffers mostly from lack of marketing and bad management of the companies that sell Smalltalk implementations. Apparently, the Sun team that worked on the Oak project (which ended up producing Java) first wanted to use Smalltalk but couldn't get a good deal from ParcPlace, vendors of VisualWorks. So they invented their own language. See this post [google.com] from comp.lang.smalltalk.
  • It obviously does't work because no one uses it!

    On my favorite web job site: The living:- C++ 10251 matches. JAVA 9454 matches. PERL 2451 matches. And the dead:- COBOL 1254 matches. RPG 306 matches. ADA 224 matches. PL/1 132 matches. SmallTalk 53 matches. VAX BASIC 22 matches.

    Hmm, by your logic there are only three living languages, then? (C++, Java and Perl?)

    I guess Python and Ruby must be even more dead than Smalltalk, since they have fewer hits on job sites.

    Market Share can be *a* factor in determining whether or not to use a programming language, but it should never be *the only* factor. If market share is your only factor, you should be using Microsoft stuff and not hanging out on slashdot anyway.

    (Ok, I'll grant you that the Smalltalk Solutions report had a stream-of-conciousness feel to it, but it's not easy to write the large volume of material that John did on each day of the conference. He covered most of the important stuff going on.)

  • I didn't think it had any specific reference. It was a joke based on what a trip report usually is for people with experience with psychedlics. Examples of "trip reports" can be found at Erowid [erowid.org] and at the Lycaeum [lycaeum.org].
  • Actually.... QKS a Smalltalk vendor for the last 10 years, is working with Microsoft to produce SmallScript.

    It is a new scripting based Smalltalk that runs (will run) on .NET. It is being developed "With" Microsoft in the same way that the Eiffel people are developing a version of Eiffel for .NET with Microsoft... IOW, it won't be a MS product, MS is just lending a hand to get Yet Another Language on their .NET platform.

    This of course has nothing to do with the evilness of MS or the foolishness of .NET... or the lack of same.

    And So It Goes
  • If you think that all available developer jobs are listed on job web sites, well, there's a bigger world out there. The job web sites are good for "coding grunt" jobs, but if you're looking to play in the $150K-250K/year league, you're not going to find many of those jobs there, because that kind of developer doesn't typically get hired off the street - it usually involves more networking, word of mouth, or specialist agencies.

    I do architecture & design work, and some of the projects I've worked on have been implemented in Smalltalk. It's used especially in situations where the requirements are very complex. Most business programming is brain dead - some basic accounting, workflow/groupware/document management, and the rest is just tailoring to individual requirements.

    But in some areas of things like financial services, where the requirements can get truly complex and require math PhD's to develop the specs, languages like Smalltalk (and Scheme et al) can come into their own. In these systems, the problem domain is such that the last thing you want to have to worry about is the sort of infrastructure detail that lower-level languages like C++, Java, or PERL force you to deal with in developing large, complex systems.

    Anyway, the real reason to learn Smalltalk is to learn what object-oriented programming is supposed to be like. C++ and Java, which I'm intimately familiar with, are pale imitations that make significant compromises which dilute OO in a pervasive way, limiting the degree to which pure OO concepts can be applied. Perl isn't worth a mention when it comes to OO - sure it can do it, but not in a way that you'd want to use in large, complex systems. Python is a bit better, and Ruby seems even better, but they still don't quite achieve the level that Smalltalk does.

    Even though I don't develop in Smalltalk day-to-day, it's an important language to have gotten your head around, if you're interested in expanding your skill as a developer.

  • REPLY WHORING / REQUEST FOR INFORMED FLAMEWAR

    Seriously. I don't know why i should use this language. Convince me.

    I recently started developing with Objective C and the Cocoa/Yellow Box/NextStep API in Mac OS X. I think Objective C is fantastic, and have no terrible problem with living without exceptions or garbage collection. How would you argue that Smalltalk is better?

    What is significantly better about one language as compared to the other? Has one features or elegance the other does not? Has anyone used both? How does smalltalk provide the things that protocols and categories give you in ObjC and multiple inherhitance gives you in C++? Is there way to do the nifty things that you can do with the ObjC forwardInvocation method?

    Also: is there any reason that the smalltalk language could not interface with the Cocoa/Yellow Box/NextStep APIs? Would doing so be clumsy, or in some way degrade the concepts of the language? If you messed with the compiler, could Smalltalk objects and ObjC objects communicate transparently with each other through the objective c messaging system?

    P.S. If i could somehow touch off a flamewar here that involved in ANY way the subjects of CLOS and Objective CAML, i would be completely overjoyed.

  • Well, the experience reports [uiuc.edu] section of the Smalltalk Solutions wiki would be a good place to look.
    The EZBoard slides aren't up there yet (the second largest online community site, serving 4.5M hits/month out of a pure Smalltalk web server) but the OOCL/Gemstone in the Large presentation (sorry, it's encoded in Microsoft-specific technologies to help keep slashdotters out) talks about the technical details of using Smalltalk and an OODB to run one of the world's largest shipping operations. Elastolab is on a completely different scale, but more fun to play with, and of course the web site hosting the proceedings is running purely in Smalltalk. I've just singled out a few. There's also a Smalltalk article in this month's Communications of the ACM, for those who read offline.
    Is that enough of a start?
  • > The main possible problem would be interfacing between memory management systems. (Still, it can be done with the Obj-C/Java bridge; it may be clumsy though.)

    Um, i don't know much about anything but i see no reason why this wouldn't be relatively easy.. i mean just play with release/retain. Assuming the garbage collector in smalltalk works in terms of some kind of reference counting. I mean, just capture the -release and -retain messages before they hit the smalltalk objects and feed them to the GC, and then have the GC send -retain/-release as it determines they are necessary. Maybe keep track of how many of each refs for a given object are from the objc side, and how many are from the smalltalk side and if someone sends a -dealloc then you just remove all the objc refs. Seems to me that would be pretty clean. RIght?

    this of course gets into the issue of what happens if someone uses @defs on a smalltalk object, but anyone using @defs in the first place is just asking for trouble -_-

  • The Technical Pursuit web site does not have any example code or docs. Do you have any more information you can share about what a TIBET program looks like?

  • You can think of Smalltalk as a simplified Objective-C, say a "script" version (even though the evolution happened in the opposite order). -- sabi

    Well said. I used to explain Objective-C as a language created by those who thought in Smalltalk with some extra junk added to make c programmers more comfortable.

  • My personal hunch is that if you conducted a random poll of developers with *significant* experience with both languages (say, a minimum of 1 year full-time experience with each), probably 90-98% would agree with this.

    I'll put my hand up: 5 years Smalltalk, 2 years Java.

    I think Smalltalk is a much more pleasant language to program in: closures (blocks), the IDE (especially senders and implementers), no casts and numerous other features. (Although Brewmaster [objsoft.com] provides some of the nicer IDE aspects.

    Smalltalk also has software engineering features that I would love to see in Java, particularly open classes. Open classes prevent the hell of library classes not anticipating your every need; it's one of the nicest things about Smalltalk and every other OO language seems to have utterly missed the point. (MultiJava [washington.edu] has these).

    What Java does have is standards, such as EJB, JFC, JMS and so on. They may not be particularly good or coherent standards. But they do encourage component development and interoperability. Smalltalk is good at the core language level, but differences in GUI building and other libraries between vendors can make Java a more attractive option if you want to avoid legacy lock.

  • Well even if language foo was the best tool to create said device driver I would still use Squeak to design, model, simulate, test and prove the driver. Then use Squeak to generate the foo source code for the final product. The same way that Squeak creates it's own Virtual Machine inside itself with Smalltalk and can generate the source for a gnu make and gcc.

    "Beware of bugs in the above code; I have only proved it correct, not tried it." --Donald Knuth (1977)

    It is ok to Squeak your horn, Whisker is one ChangeSet my image always requires.

  • without anybody knowing. I remember lots of stuff happening with Linux conferences and no one knew what was going on either.

  • If you understand and are comfortable with Simula there is the Smalltalk-72 emulation [1] created by Dan Ingalls you can file into Squeak.

    Doug Engelbert pioneered the use of Graphic Human Tool Interface with bitmap displays starting in 1957 and going public with his oNLine System in the "MotherOfAllDemos" in 1968.

  • The interface that "put you off" is the original Smalltalk Human Interface. It is the same reaction that caused Apple to change that Human Interface to the one they created for their Lisa and Macintosh. Smalltalk-80Mac v0.x was one of the original Xerox License One Virtual Machines of the Smalltalk-80 image along with Dec and TI. That also means it had 100% of the source and all of the Changes as opposed to the dialects of Smalltalk that have since been derived from the code that was published in the books.

    The "new" Morphic interface has been inside the image since it was renamed to Squeak and licensed by Apple as Open Source. The Squeak3.0 production release is the first to launch into a Morphic Project, and you will find the quality of the demonstration projects completely different from those in Version2. And yes... there are still some other new human interfaces hidden in the image that are being developed. Think of them as Easter Eggs, that include all of their source.

    The Dolphin Education Center Information is great source of information and patterns about Smalltalk though the free version has not changed since 1998. Their document explaining the issues with the Model-View-Controller model in Squeak and the Model-View-Presenter approach used in Dolphin is an excellent explanation of both models. I am not aware of a Mvp Project being created for Squeak, yet.

  • It wouldn't be "smalltalk" now would it?

    DanH
    Cav Pilot's Reference Page [cavalrypilot.com]

  • Actually the project is called "Squeak No Operating System" because the intent is to get rid of the OS underneath Squeak so you just work in the Smalltalk environment as you did with Smalltalk-80.

  • Smalltalk trip report. (Score:5)

    by pallex ( 126468 ) on Wednesday April 18, 2001 @03:32AM (#283316)
    Its now been 3 hours. Attempted to virtualize base methods into my new class, but got distracted by hairs on my right thumb. Also, humming from PC now becoming unbearable. Will go for a walk outside, its sunny and i can hear the birds sing. Mellow/not confusing at all, but nice visuals, especially the traces, which persist for several seconds.
  • Ahhhhhh!!!!!! Do not mention Scheme! It is the bane of my past semester at college.

    And it reminds me that I have an assignment due in about 4 hours. Waaaaaaa......

  • Pioneered in the 1970s at Xerox Park. Inspired the first object-oriented language Simula from Norway.

  • Re:Smalltalk is obsolete (Score:1)

    by Anonymous Coward
    I've programmed in C++, Java, Perl, Objective-C, Scheme, and Smalltalk, among others, and I still prefer Smalltalk. (Though I've never tried CLOS...)
  • First off, it was Xerox PARC, you idiot, not Xerox Park.
  • I only used Smalltalk a few times. Boy it was a good language, (although I didn't go any further with it myself, prefering Scheme). But it's dying because nobody bothered to solve the interesting problems that Java addressed - perfect portability of source and byte codes, a single standard and just-in-time compilation. If Smalltalk wants to survive it needs to deal with this. At least Scheme has Kawa [sandsmachine.com]. I'm a bit concerned about the future of programming languages what with the overly dominant Java. Java's mediocre but is good enough and ubiquitous enough that it's gaining an inordinate share over better alternatives.

  • Various links for Smalltalk (Score:5)

    by merigold77 ( 156634 ) on Wednesday April 18, 2001 @04:53AM (#283323)
    Smalltalk Links [enteract.com]

    I believe EZBoard [ezboard.com] is written in Smalltalk

    Volkswagen Beetles [cnn.com] with code in Smalltalk

    Extreme Programming [slashdot.org] was invented while Kent Beck was consulting on Smalltalk projects

    I think that's enough for a start :)

  • Dead wrong! (Score:5)

    by werdna ( 39029 ) on Wednesday April 18, 2001 @05:00AM (#283324) Journal
    nobody bothered to solve the interesting problems that Java addressed - perfect portability of source and byte codes, a single standard and just-in-time compilation

    No, that isn't the case. The free Disney R&D implementation of Smalltalk, Squeak [squeak.org] addresses these issues, in some cases profoundly better than does Java.

    Indeed, Java hardly offers "perfect portability," the "write-once, run anywhere" claim is marketing hype at its best. It is, in practice, quite difficult to get identical results from any but the most trivial Java programs.

    In comparison, a multimedia GUI-based application in Squeak runs pixel-for-pixel IDENTICALLY across a vast array of platforms. I wrote a video game for my wife's birthday in Squeak, complete with animation sound and graphics, from the machine at my Office, a Dell PC Laptop. I sent the image by e-mail to my home, flipped it on her iMac while she slept, fired it up, and it just worked. Identically.

    On the other counts, Squeak has a JIT (plus many other nice internal features including object send caching, a sweet and super-fast generational garbage collector), and there is, in fact, an ANSI standard.

    Indeed, Smalltalk's source code is virtually identical across implementations. (The syntax, which --in this sense only-- is super-elegant, can be trivially described in a handful of rules). Except for one religious issue (closures for code blocks). Differences in and interoperability problems between implementations derive primarily from the underlying framework libraries provided with those codes -- a problem hardly unique to Smalltalk.
  • here [squeak.org] and here [extremeprogramming.org]
  • First off Kawa exists for java. (I'm too lazy to track down the link.)

    Secondly, Smalltalk has the portability of java explained in the following post. Moderate it up!

    Go to computerjobs.com or whatever and do a search for smalltalk you will see that smalltalk is still used as a programming language.

    Refactoring is a large part of the (deservedly) hyped Extreme Programming. Squeak(smalltalk) comes in with a built in refactoring browser. It can *automatically* refactor code. I believe it finds dupblicated code, and makes large methods smaller. Incredible.
    Go to www.squeak.org [squeak.org] and download smalltalk today.

    Now to go offtopic a bit...
    Finally, I'm a bit sick of the omnipresence of Java. ( flamearmor.setON() ) I know and have enjoyed the benefits of java. But I'm a little bit tired of people convincing me how great jsp pages are, javabeans, ejb etc... without knowing much about any of the alternatives. It seems like there are some great platforms out there zope/php, open-acs/tcl which allow people to build powerful flexible websites much cheaper then the java solution. Unfortunately those other ones get no coverage as Java's marketing is incredible.

  • Smalltalk In JavaScript (Score:3)

    by Baldrson ( 78598 ) on Wednesday April 18, 2001 @05:45AM (#283327) Homepage Journal
    A couple of Smalltalkers have teamed up to write a very Smalltalk-like system written in Javascript [technicalpursuit.com]. There was a technical presentation at the most recent Hackers in Santa Rosa and people in attendance said it looked like the entire system including base classes (collections, widgets, MVCesque stuff, formatter/validators etc.) fit into a cached page with less bytes than that required to load one Hotmail inbox index page.

    Apparently, page 144 of Flanagan's otherwise Definitive Guide to JavaScript [oreilly.com] concerning inheritance in that language misled many to believe that multi-level inheritance would not be possible in JavaScript. As it turns out, not only is multi-level inheritance possible, but so are class methods/attributes, meta-classes and even multiple inheritance and fun stuff like instance level programming ala Self [sun.com]. Apparently JavaScript is a lot more capable than most people, even some of the better experts in it, give it credit for being.

    It would be great if TIBET got released at the WWW10 conference, but I think registration deadlines for vendors has passed.

  • But of course, Modula was influenced by Pascal which has designed by Niclaus Wirth. He is said to have worked on the same floor as the Smalltalk people at PARC at one time. It's a small world.
  • I've used Smalltalk as well. I've found it had other flaws:

    1) performance is usually a lot less than C (and subject to garbage collection slowdowns; although modern GCs are better); [however Self showed that slowdowns of only 50% over optimised C are possible.]
    2) one image fits all (and the image tends to be big, that's one thing that Java has cleaned up some; although Java admittedly has done some other things less well)
    3) 4 metalevels? What were the designers smoking? Self had this right. Smalltalk should have had 1 or 2 at the most.
    4) proprietary... (has been and remains to some extent)
    5) typing IS useful sometimes (although its not as necessary as you'd expect from using C)
    6) multiple inheritance is useful sometimes and most Smalltalk... doesn't (actually MI is not as necessary in run time typed languages but it's still handy sometimes)
  • Hmm - First, Smalltalk is hardly dead. Cincom now owns the VisualWorks implementation (from ParcPlace) as well as the ObjectStudio implementation (originally from Easel). Our sales last year were very strong, and we are exceeding them this year. You can try Cincom Smalltalk out free: http://www.cincom.com/smalltalk And two things: 1) VisualWorks was cross platform and binary portable long, long before Java was even pondered (it's been that way since the late 80's). We were there long, long before Java got there. 2) The site above is implemented in VisualWorks; we actually eat our own dog food. James Robertson Product Manager, Cincom Smalltalk jarober@mail.com
  • No. C.

    Java lacks:

    - templates
    - operator overloading
    - multiple inheritance
    - anal worrying about performance...
    - performance (historically, although it's getting better)

    ;-)
  • only flaw (contained objects don't know about their containers unless you create an explicit link back to the container...
    That's its only flaw? I think Smalltalk has other flaws, but not knowing about containers only makes sense. What if you are contained by several containers? What if you really don't care about your container (and want to save memory)? What if your real container is far away (linked lists)?

    No, that's not a feature, or if it is it isn't a feature that fits with Smalltalk.

    I think Smalltalk's biggest problem by far is that it's too insular. It's hard to talk with the rest of the world, or interact with what other programs are doing in other environments. That's the price of elegance, I suppose -- purity only comes when you won't sully yourself. But it's hard to work with. The image is a big part of the problem (as much as I think the orthogonal persistence that it implies is cool).

    I really love Smalltalk, but I don't actually use it for anything real (even though I often have my choice of languages). The runtime environment is just too limiting (Smalltalk over FTP?)

  • It most certainly does not. I've just spent a semester here at Georgia Tech taking a course on OO-design and -programming, with Squeak being the language of (instructor, definitely not student) choice. Our ongoing semester project was to build an MP3 player (seems cool, right?). However, nobody seemed to notice that people who ran Squeak under Windows (a majority of the class, I believe) had no MP3 support. Oops. They were delayed at least two weeks while someone scrambled to find (or write, I dunno) the appropriate library. Even then, the Windows users had to use a specially-modified Squeak binary.

    Squeak itself didn't have an MP3 driver (we call them plugins) until just a few months ago, and it did take some time to sort it out cross-platform (there were also some licensing issues). I thought that they had this sorted by now, but I'm not sure one way or the other to where John Macintosh's excellent work has been ported.

    It is most certainly true that C-language plugin code is not automatically cross-platform portable, even when plugged into Squeak.

    God, someone just had to bring up Squeak. Ugh.

    Wow, someone who uses Squeak in the real world! I hope you're getting paid a very large sum of money to do so, since I can't imagine anyone doing it out of personal preference.
    As stated above I'm currently in a OOP class using Squeak, and maybe 75% of the people I know in there would agree with me when I say Squeak has been the worst programming language I've ever had to deal with (out of the seven or eight I've learned).

    Interesting, my personal preferences were exactly the reverse, but I suspect this may be the difference between "learning seven or eight programming languages" and building real commercial code in one. Smalltalk is an excellent tool for prototyping and building OO systems, and then for extending the prototype to a solid commercial result, at least in my experience. Perhaps this may not be apparent when writing toy programs for a class in school, but in time, you may come to understand the virtues of a programming language that makes programming easier and more efficient.


    The Squeak IDE is one of the most frustrating pieces of software I've ever had to use. Slow, ugly as sin (both the original MVC and the newer Morphic GUI), and bloated as all hell. You must have superhuman patience to be able to create a game for your wife using it.

    De gustibus non disputandum est. My experience is much to the contrary. While I am regarded by some as an excellent hacker, capable of generating high quality code with breakneck speed. I have never been as efficient as I was since I started hacking in Squeak, or as happy while coding and debugging.

    I met Squeak in early November a year or so ago after it was demonstrated by Ted Kaehler at Hackers. I went home, downloaded it, spent a little time with the old Smalltalk books, and had the product running in production form in time for her December 26 birthday, and still attend all the holiday parties.

    Since that experience, in which I was a rank newbie to Smalltalk (and now, I realize to OOP -- though I had been writing in OOPLs for years), it has only gotten better.

    I suppose we will have to take our respective positions as reasonable people, and agree to disagree.

    It's *really* hard to believe that Squeak was supposed to become the language used on the Dynabook, If a bunch of college students can't get the hang of it, I don't see how elementary-school kids could either.

    I'm trying to be polite here. MMy experience is to the contrary. For example, my 9-year old son codes in Squeak, having picked it up, indeed with some decent coaching, in just a week or so. His code is awkward at times and unpolished, but hey, he's actually writing code and thinking its fun.
  • Ironically, Wirth's B&D style of language design is complete the opposite of Smalltalk's philosophy, which generally trusts the programmer to do the right thing (while allowing them to do the wrong thing), and encourages transparency rather than firm borders. Oberon, Wirth's latest (most minimalistic) language completely annoys me with its utter lack of any sort of coolness. (I kind of liked the Oberon OS's UI, though)
  • I think you meant to say inspired by the first OO language, Simula. In one speach, Alan Kay said he felt the first case of OO programming he has found was an unnamed sargent in the army, who make a tape-based file system where the first few records of the tape contained procedures on how to access the rest of the records on the tape.

    This was something akin to the tape as an object, where you could ask it to do something (by running the programs at the known locations), but it was free to perform your queries as it saw fit.

  • Odd that we can see it so differently . . . (Score:3)

    by werdna ( 39029 ) on Wednesday April 18, 2001 @12:04PM (#283336) Journal
    It most certainly does not. I've just spent a semester here at Georgia Tech taking a course on OO-design and -programming, with Squeak being the language of (instructor, definitely not student) choice. Our ongoing semester project was to build an MP3 player (seems cool, right?). However, nobody seemed to notice that people who ran Squeak under Windows (a majority of the class, I believe) had no MP3 support. Oops. They were delayed at least two weeks while someone scrambled to find (or write, I dunno) the appropriate library. Even then, the Windows users had to use a specially-modified Squeak binary.

    Squeak itself didn't have an MP3 driver (we call them plugins) until just a few months ago, and it did take some time to sort it out cross-platform (there were also some licensing issues). I thought that they had this sorted by now, but I'm not sure one way or the other to where John Macintosh's excellent work has been ported.

    It is most certainly true that C-language plugin code is not automatically cross-platform portable, even when plugged into Squeak.

    God, someone just had to bring up Squeak. Ugh.

    Wow, someone who uses Squeak in the real world! I hope you're getting paid a very large sum of money to do so, since I can't imagine anyone doing it out of personal preference.
    As stated above I'm currently in a OOP class using Squeak, and maybe 75% of the people I know in there would agree with me when I say Squeak has been the worst programming language I've ever had to deal with (out of the seven or eight I've learned).

    Interesting, my personal preferences were exactly the reverse, but I suspect this may be the difference between "learning seven or eight programming languages" and building real commercial code in one. Smalltalk is an excellent tool for prototyping and building OO systems, and then for extending the prototype to a solid commercial result, at least in my experience. Perhaps this may not be apparent when writing toy programs for a class in school, but in time, you may come to understand the virtues of a programming language that makes programming easier and more efficient.


    The Squeak IDE is one of the most frustrating pieces of software I've ever had to use. Slow, ugly as sin (both the original MVC and the newer Morphic GUI), and bloated as all hell. You must have superhuman patience to be able to create a game for your wife using it.

    De gustibus non disputandum est. My experience is much to the contrary. While I am regarded by some as an excellent hacker, capable of generating high quality code with breakneck speed. I have never been as efficient as I was since I started hacking in Squeak, or as happy while coding and debugging.

    I met Squeak in early November a year or so ago after it was demonstrated by Ted Kaehler at Hackers. I went home, downloaded it, spent a little time with the old Smalltalk books, and had the product running in production form in time for her December 26 birthday, and still attend all the holiday parties.

    Since that experience, in which I was a rank newbie to Smalltalk (and now, I realize to OOP -- though I had been writing in OOPLs for years), it has only gotten better.

    I suppose we will have to take our respective positions as reasonable people, and agree to disagree.

    It's *really* hard to believe that Squeak was supposed to become the language used on the Dynabook, If a bunch of college students can't get the hang of it, I don't see how elementary-school kids could either.

    I'm trying to be polite here. MMy experience is to the contrary. For example, my 9-year old son codes in Squeak, having picked it up, indeed with some decent coaching, in just a week or so. His code is awkward at times and unpolished, but hey, he's actually writing code and thinking its fun.
  • My impression is that a lot of the real-world use of Smalltalk is for in-house development. I feel I've heard it's particularly popular in financial institutions. Lots of places that are otherwise very boring.
  • Squeak itself didn't have an MP3 driver (we call them plugins) until just a few months ago, and it did take some time to sort it out cross-platform (there were also some licensing issues). I thought that they had this sorted by now, but I'm not sure one way or the other to where John McIntosh's excellent work has been ported.

    Ok, the code was taken from a intel Linux source tree, then ported to the macintosh, then various folks ported it over to windows, lots of time was taken trying to get the MMX code to work since various compilers have different viewpoints about syntax. But in about three weeks it was ported and has not been a problem. Among all this we also worked out the license issue to ensure we could distribute it. Lurking on the smalltalkconsulting.com site is the source code for C and smalltalk, with links to other DLLs like for Linux and for Windows. Note a key thing here is that if you have someway to play sound from a bit stream, and someway to display bits, then you can play MPEG movies or MP3 files without relying on hosting OS specialized sound support. This can be a major issue in embedded systems. But with this solution from the ground up you have full control over manipulating the bits, which can be useful if you want want to run close to the metal
  • I think we need more information
  • Sounds like a pretty good summary. For the most part, it seems that you're better off just going with C++ if you really need the speed, or going with Smalltalk if you need a *real* high-level language for handling complexity well. There's not much of a middle ground where Java is a better option than one of these. (As the old Bertrand Meyer adage goes... Java: all the elegance of C++ with the speed of Smalltalk. :-) )
  • Yup, EZBoard is in VisualWorks Smalltalk, using a modified VisualWave.

  • Now wait for the language Nazis... (Score:3)

    by WhyteRabbyt ( 85754 ) on Wednesday April 18, 2001 @03:51AM (#283342) Homepage
    Yesterday : Ruby is crap because its too new and we have other languages that do the same thing...

    Today : Smalltalk is crap because its too old, and we have other languages that do the same...


    Morale of this? : 90% of Slashdot has the mindset "The way I do it is best. Anyone else doing it a different way is an ignorant asshole."


    Pax,

    White Rabbit +++ Divide by Cucumber Error ++

  • a multimedia GUI-based application in Squeak runs pixel-for-pixel IDENTICALLY across a vast array of platforms.
    It most certainly does not. I've just spent a semester here at Georgia Tech [gatech.edu] taking a course on OO-design and -programming, with Squeak being the language of (instructor, definitely not student) choice. Our ongoing semester project was to build an MP3 player (seems cool, right?). However, nobody seemed to notice that people who ran Squeak under Windows (a majority of the class, I believe) had no MP3 support. Oops. They were delayed at least two weeks while someone scrambled to find (or write, I dunno) the appropriate library. Even then, the Windows users had to use a specially-modified Squeak binary.

    God, someone just had to bring up Squeak. Ugh.
    <rant>
    Wow, someone who uses Squeak in the real world! I hope you're getting paid a very large sum of money to do so, since I can't imagine anyone doing it out of personal preference.
    As stated above I'm currently in a OOP class using Squeak, and maybe 75% of the people I know in there would agree with me when I say Squeak has been the worst programming language I've ever had to deal with (out of the seven or eight I've learned).
    The Squeak IDE is one of the most frustrating pieces of software I've ever had to use. Slow, ugly as sin (both the original MVC and the newer Morphic GUI), and bloated as all hell. You must have superhuman patience to be able to create a game for your wife using it.
    But good luck trying to turn it into a binary to distribute to your friends, because you can't! And don't ask them to try and learn the language either, because there's no documented API, and the purportedly self-commented code really isn't. Did I mention that that same code sometimes breaks on you, fresh from an install? Yep, believe it.
    Also (and yes, I realize I'm reaching here), but the syntax is all backwards. It's not sufficiently like natural laugnage to be easy for beginners to use, and it just frustrates experienced programmers used to nearly every other language (i.e., based on C). It's going the way of Hypercard, Apple's old natural language-based multimedia programming environment.
    It's *really* hard to believe that Squeak was supposed to become the language used on the Dynabook, [utexas.edu] If a bunch of college students can't get the hang of it, I don't see how elementary-school kids could either.
    </rant>



  • Smalltalk is sleeping. Please don't wake it up.
  • Heh. How can I be the only one who thinks that was hillarious? A darn shame I've no mod points. Maybe it's just the poppy tea talking...
  • Smallworld's proprietary Magik is a smalltalk descendant language. Smallworld is a GIS vendor (geographic information systems) currently in vogue for the large scale modeling of gas, electric, telco, and other large scale networks. They've probably got 40% of the US market (more in europe) including some of the biggies like ComED, Niagara Mohawk, Level 3, etc... I'm no computer scientist, but I've been making a hell of a living for four years programming magik (smalltalk) as a consultant. And all this with a geography degree. ps. the real world is modeled with maps.
  • IIRC, at least the first version of VisualAge Java was actually written in Smalltalk. Or so I was told back when I was working for Big Blue...

  • The free Disney R&D implementation of Smalltalk, Squeak addresses these issues, in some cases profoundly better than does Java.

    Aye, I'm a Java programmer, but I rather agree with what you said....

    But wait....I still love Java. Thanks to the hype, Java has rich set of API; PDA has java, mobile has java, database has java.....we could choose what we like to do, and not be bound by the scope of its API.

    "write-once, run anywhere" claim is marketing hype at its best.

    The hype might come from nowhere, but it isn't going to nowhere. Java might not live up with its claim, but Java programmers are "learn-once, jobs everywhere".

  • More like C++ and Smalltalk, IMHO... borrows syntax from C++, but the object model is pure Dynabook.

    /Brian
  • Perl OO isn't dreck per se, it's just... uh... very... uh... it likes to, uh, solicit more user input than most.

    /Brian

  • ha (Score:1)

    by rodentia ( 102779 )
    was funniest thing I ever read on slashdot what I didn't write myself.
  • Particular instances where I know personally Smalltalk is used:

    Progressive Insurance: Smalltalk is behind a *huge* amount of their operation. I interned there. VisualAge for Smalltalk as client as well as GemStone/Smalltalk (OODBMS in Smalltalk) and IBM DB2 on the backend. Mission critical, enterprise wide, blah blah blah.
    Medtronic: You ever heard of Pacemakers? Smalltalk is used to prototype the GUI for the "programmers" (devices which speak with the Pacemakers and other in-your-chest devices to, well, prorgam them). Prototyping in a very complex way- there are medical doctors, psychologists, and human-computer interface experts all over it. The department decided that Smalltalk was the best tool, being dynamic and fluid enough (where as most languages and IDEs are not).

    And I get to use it for "real world" (?) plant population and hydrological data analysis and visualization at the NRRI [umn.edu] this summer. :)
  • Smalltalk could probably interface to Obj-C pretty transparently if someone wrote a bridge. (I don't know how hard it would be; ask the TipTop guys.)

    I know that Marcel Weither (sp?) wrote a simple hack for a Squeak -> Objective-C bridge for the Mac OS X (+ Server) version of Squeak. I think it was only one way, as a proof of concept.
  • If ST is such a great system for throwing up code in a day or less, why doesn't anything like that ever come out?

    There is a company working on windows GUI bindings. Lesser Software [lesser-software.com]. The Squeak list is a valuable resource . (whodda thunk?) Otherwise, people who want it should do it. Isn't that what this whole open source thing is about? Not bitching about the lack of features or bugs, but doing ir yourself, or convincing someone else to do it for you?

    BTW IBM did write much of their Java in ST, but they have replaced it with something else since.

    Last I heard, VA/Java was still written largely in Smalltalk. They started replacing it with Java, as Java has matured a little since the last release. VA/J still has a fair amount of Smalltalk in it, AFAIK.
  • Monty Kamath has a huge list of organisations doing real world work in Smalltalk (220 entries): http://www.goodstart.com/whoswho.shtml [goodstart.com].

    Another list is on the VisualWorks Smalltalk Wiki, at http://wiki.cs.uiuc.edu/VisualWorks [uiuc.edu].

    A list of Cincom Smalltalk (i.e. VisualWorks or ObjectStudio) success stories is at http://www.cincom.com/scripts/smalltalk.exe/smallt alkSuccess/index.asp?content=customerProfiles [cincom.com]. Unsurprisingly perhaps, that site is running on VisualWorks...

  • When I first heard about Smalltalk I downloaded Squeak and it put me off completely. The default demo looks decades out of date; blocky clashing colours, alien look-and-feel and (by their own admission) poor documentation. Looks awful to the uninitiated.

    The Dolphin demo and tutorial is completely different - much more in the vein of Sun's excellent Java tutorials. That's one of the things Smalltalk needs if it is ever going to recover some mainstream interest.

  • The UI that it comes with is so oddball that it turns off about 90% of the people who try to get started with it.

    I'm sure you took a poll.

    Alt-Spacebar, the standard Windows way to move a Window? No, this is a cross-platform tool, doesn't do Windows stuff. Five mouse clicks on the demo they pop up to show off, and my computer is hostage to a Window that won't go away. Great modern UI.

    Here, Squeak is critcized for failing to emulate Windows. To me, this is blessing with faint criticism. True, Squeak is not a Windows or MacOS emulator. So what?

    I note, with interest, that the specific "features" you request could be added with a few lines of code. Unlike NT, however, this can be added in Squeak by ANY user, since 100% of the system's source code is persistently available and immediately modifiable in seconds.

    Squeak's GUI is quite modern. Unlike Windows, which has not embodied any significant new ideas or developments since the 80's (when it was ripped off from Apple and Xerox), Squeak's Morphic (which was designed by a team comprising many of the Xerox PARC research scientists) interface is a novel, interesting and exciting new GUI framework that is well worth studying. Sure, its a research tool -- that's why its fun.

    Competent Squeak users routinely modify the appearance to taste. True, Squeak isn't market driven to suit people such as the poster who would prefer it was Windows NT. So what?

    About every 6 months someone points out that Squeak would be ten times more popular if it came with a user interface that didn't look like the 1937 version of Klingon to a Windows user.

    And, indeed, every year or so someone posts a Windows look-and-operate-alike skin to appease them. These skins and corresponding codes are not generally adopted or used by the community, and routinely fall into the bit-bucket of neglected and unsupported code.

    BTW, I do like ST, but the trap is that you've got to commit really big bucks to get the professional versions that can really deliver. Maybe $20k per seat and up, since you have to buy lots of training because the docs are bad and its a culture that you can't catch from a book.

    People who say things like this tend not to be the same people who "really deliver" things for a living. I have delivered ST-based product using software costing far less than $20K a seat, and in fact costing exactly $20K a seat less than that. I never spent a dime on Smalltalk, and found the printed books more than adequate to give me all I needed.

    Maybe $20k per seat and up, since you have to buy lots of training because the docs are bad and its a culture that you can't catch from a book. And then your user gets an app that runs a little slower and takes a little more hardware, and you've got some run-time issues, etc.

    BTW, the biggest multimedia gizmo, the Times Square Jumbotron, is programmed in Ada. Let us know when Squeak gets that one.

    Non sequitur. I admit that Squeak doesn't implement the Jumbotron. So what?

    I note that the Jumbotron doesn't support Alt-spacebar either. This much is certain, Jumbotron is not portable at all, let alone pixel-for-pixel identical across virtually every modern software platform. On the other hand, Disney is presently using Squeak and other non-Ada software to run its attractions and demonstrations.
  • I've done some stuff that a few people think is somewhat interesting, and I use Smalltalk for pretty everything I do...

    For instance, I'm using Squeak on a Linux PDA as the brain for my autonomous submersible MicroSeeker (http://www.huv.com/uSeeker).

  • You like dynamic binding, Smalltalk is tuned to do it right and sweet. And it has blocks, which are wonderful things. Can you see what this does?

    #(1 2 3 4 5) select:
    (Array with: [:e | e even]
    with: [:e | e odd]) atRandom

    How's that in Obj-C (I'm curious, actually)? Java?

  • Uh, am I thinking of the same Comal here? The Comal I remember was this crocky BASIC/ Pascal hybrid that had a cult following among academics in Europe for a while.

    Either you are smoking some serious rock, Anonymous, or this has to be the Mother of all Trolls...



  • I would hardly consider Perl to be the future generation of language. I am doing all I can to avoid Perl personaly as (IMHO) better alternative exist (Python?) for the problems ->I- need to solve.

    I would probably consider Java the future ... at least in terms of what Smalltalk could of been.


    --------------------
    Would you like a Python based alternative to PHP/ASP/JSP?

  • Re:Smalltalk is obsolete (Score:3)

    by WolfWithoutAClause ( 162946 ) on Wednesday April 18, 2001 @04:06AM (#283362) Homepage
    Java is the direct decendent of (some would say bastard offspring ;-) of C and Smalltalk.

Slashdot Top Deals

"Tell the truth and run." -- Yugoslav proverb

Close