Smalltalk, risk and success stories

In the comments section to an earlier post  Göran Krampe brought up some excellent points, backed by experience, on my remark that more dynamic languages increases risk in projects, especially if all developers in the project are not on the same level. Here are some of my comments on those, but please do read Göran’s entire comment for more context. Since I find the discussion to be very interesting, I thought I’d bring it up as a new article.

Just read your article at IDG regarding Alan Kay/Smalltalk – and it was good. For once not a single glaring misconception regarding Smalltalk 🙂 – I am a bit jaded by all people throwing around ”truths” about Smalltalk without having actual experience themselves. So kudos for that. 🙂

Thank you! However, I must confess that my Smalltalk experience is limited to playing around with Squeak in my spare time, so I have never used it in a large project. Bear this in mind when you read my response…

Above though it sounds like you are saying that Java would mean a lower risk than Smalltalk for larger projects or projects in which the developers are of ”average” or ”mixed” level. That I definitely do NO agree with on the other hand. 😉

[…]

So my experience is the exact opposite. I claim that less experienced developers can more easily be made productive in Smalltalk than in Java. I have repeatedly taught OO *and* the basics of Smalltalk in a single day including practice and then had these pupils find bugs and complement a working small system the next day.

I suspected that a smalltalker might not agree with that 🙂 Please not that I’m only talking about risk, not programmer effiency. Risk isn’t inherently bad, since it usually goes hand in hand with opportunity. Your points about new programmers learning Smalltalk quicker than Java is obviously backed up by experience, but a little beside the point.

The reason that I feel projects done in more dynamic environments (I’m going to lump Smalltalk, Python and Lisp together here, which might not be entirely fair) to have a higher level of risk is that the dynamic properties of the language will allow your system to take on aspects of a domain specific language, especially if some members of your team understands the Zen of Smalltalk/Lisp/Python. For example, in both Lisp and Smalltalk you can essentially redefine parts of the syntax, like the if/then/else statements, and if it makes sense in your design, you might very well want to do that. But if another programmer, who has yet to be enlightened (sticking with the Zen theme) on the expects the syntax to work like default, this might trip him up (Operator overloading in C++ and .Net gives us essentially the same problem). This risk increases if the programmer has been taught more traditional imperative programming in the style of Java/C# and have not been given a good introduction to Smalltalk.

Things like tail recursion, higher order functions, metaclasses and even polymorphism cam be difficult to wrap your head around, especially since you can get a lot of stuff done without them, and in not-so-dynamic environments, you usually do.

Or to put it more soundbite-friendy way: The more dynamic and open-ended a language is, the more choices you have at any given time. Every choice introduces opportunity — and risk.

However, since I haven’t done any large projects in either Smalltalk or Lisp (I did a elevator control system in Scheme in school, though :-)), maybe my opionions should be taken with a grain of salt. I’d be happy to hear your opinions on why the things I’ve mentioned above aren’t such big risk factors after all.

Also, the idea that there is something inherent in Smalltalk making it unsuitable for large scale development is simply not true either. And there is ample evidence for that.

There are very large systems having been built in Smalltalk with great success over a long period of time. And I mean *large*. 14000 classes, 65 developers/staff, 500 users etc, see for example the ”Kapital” system at JP Morgan Bank, https://secure.cwheroes.org/briefingroom_2004/pdf_frame/index.asp?id=4909)

I don’t think I’ve implied anything like that. It is interesting to hear about these big successful projects, but I keep wondering why we don’t hear more about them. Paul Graham published an essay about how good Lisp was for building ViaWeb, and most people that are familiar with XP has at least heard about the C3 project, but there must be more stories, right?

The point of my column that started the debate was that while many of the inventions and discoveries that come from the Smalltalk community are now used everywhere (MVC, JIT, design patterns…, XP), the language itself isn’t. I don’t believe it’s as simple as Sun and Microsoft having a larger marketing budget, but I’m very interested in a discussion of what the real reason could be, as I still think there are more that the general programmer community could learn from Smalltalk.

17 svar på “Smalltalk, risk and success stories”

  1. Being invited like this I must of course reply. 🙂

    First, you wrote "Thank you! However, I must confess that my Smalltalk experience is limited to playing around with Squeak in my spare time, so I have never used it in a large project. Bear this in mind when you read my response…". I will keep that in mind. 🙂

    What I meant was that it was refreshing to read a text from an author that doesn’t know much about Smalltalk – but is aware of that and thus keeps the statements on the proper level. It is all too common for people to shoot off "facts" about Smalltalk when in fact they do not have any experience to back them up.

    Then you wrote "Please note that I’m only talking about risk, not programmer effiency.". The word "risk" probably mean different things to different people. In my mind I here think about the probabilities of project failure or project problems due to the choice of Smalltalk instead of Java.

    And in that respect it is very pertinent that the language is easy to learn and use. Or phrased another way – if I can get 9 out of 10 project members productive using a language that is easier to master compared to say 5 out of 10 using a language of higher complexity – then that in a very dramatic way translates into less risk. So I do not agree that this would be "a little beside the point.". 🙂 And also, if the programmers are more productive it also very much translates into less risk of project failure.

    I know this wasn’t your main point – and I am getting there soon – but the above is so important it can not be disregarded when talking about project risk. If a development team can be 2-3 times more productive (and that is of course just a number) the risk of not being able to deliver the result is vastly lowered.

    Ok, you write "For example, in both Lisp and Smalltalk you can essentially redefine parts of the syntax, like the if/then/else statements, and if it makes sense in your design, you might very well want to do that.". This is an aspect often brought up by non-Smalltalkers as a perceived problem.

    First of all – an important thing here is that being *able* to do something is not the same thing as *doing* it. If I would say that Java is less suitable for OO because you can in fact write your whole program in one single main function and use only static methods as procedures – then the obvious response is "Sure, but you just don’t *do* that!". Same goes here. Smalltalkers don’t sit around inventing their own control structures just because they can.

    You write that "you can essentially redefine parts of the syntax, like the if/then/else statements". This is a misconception. (Yes – you *can* redefine the syntax of Smalltalk, by modifying the class Compiler and friends, but that is actually not what you are referring to. 🙂 )

    You are referring to the fact that many things that are expressed using special syntax in other languages – like control structures – are instead expressed using messages in Smalltalk. Which means that we can easily implement such messages in our own classes – or modify those that exists in the base classes. This is definitely not "redefining the syntax" – it is still just plain old message sending. I have never once though in all my years of Smalltalking seen the ifTrue:ifFalse-message (if/then/else in Smalltalk) being redefined or reimplemented in another class. It just doesn’t make sense to do that.

    But… when it *does* make sense to do it – for example the do:-message (for-each) then there is nothing confusing or wrong about it. It is in fact just Good Ole polymorphism. An example to show what I mean, I assume you wouldn’t be surprised to see this in Java:

    anObjectThatCanHoldProducst.addProduct(aProduct);
    anotherObjectOfAnotherClassThatCanAlsoHoldProducts.addProduct(aProduct);

    …now, you write that an unenlightened developer that "expects the syntax to work like default" might get confused. What you are saying is that if the developer has an object in her hand that someone else has authored and she sends a message to it – then if the object behaves *unexpectedly* it would be a problem. Of course.

    Above we expect that both those objects do what we ask them, possibly *differently* of course (polymorphism) but hopefully still with results that we can expect. For example, we probably expect that the objects will put the reference to aProduct in some collection or something. And we probably expect that that the order in which the two above statements are executed doesn’t affect anything – because we don’t expect other "side effects" from these messages. So the problem is a generic problem which exists in all OO languages. Does the object behave as expected?

    Anyway – the bottom line is that "it is not a problem". Just ask any Smalltalker. Like me. 🙂

    Then you mentioned "recursion, higher order functions, metaclasses and even polymorphism" as complex things that you perhaps can do better without – or something like that. Well, I agree with your intention here, that powerful techniques can sometimes make like hard for less experienced developers. Sure. But don’t use it then! 🙂

    Saying you don’t want polymorphism in an OO language is a bit weird though, I don’t want to even discuss that – it is one of the most important pillars of OO next to encapsulation IMHO. And it simplifies so many things so I can’t view it as something "bad" at all.

    Meta programming isn’t used much in Smalltalk – unless you are modifying the Smalltalk environment itself (the IDE so to speak). In fact – most Smalltalkers don’t know much about it and they don’t need to.

    Recursion is a technique more often used in Scheme/Lisp than in Smalltalk. Sure, it is useful and used sometimes in Smalltalk too – but you aren’t forced into using it.

    Higher order functions sounds very "scary" to people but it is in fact very simple stuff in Smalltalk. It is so simple and so pervasive in Smalltalk (blocks) that as a Smalltalker you don’t think of it as something advanced at all.

    Ok, the final two questions – where are the large Smalltalk projects? And why didn’t Smalltalk "catch on"?

    The large Smalltalk projects are often big in-house systems and you seldom learn about such projects in general. But there are many, many such case stories to be found on the net if you go and look. Start here for example: http://www.whysmalltalk.com/production/index.htm

    The reason for Smalltalk not catching on, well – first of all – I think Smalltalk *did* catch on!
    But besides that, why didn’t it go like a Rocket like Java? I think it has to do with poor marketing (the primary Smalltalk companies have done very poor in this department including IBM), a bit too early (performance issues compared to C or assembler, which today are moot), and the strange developer obsession of syntax. Yes, really. 🙂

    regards, Göran

  2. Gamp;#246;ran

    Thank you again for your comments! I’ll address them in an slightly
    out-of-order fashion.

    Re: confusion resulting from redefining syntax. You’re right in that I
    considered things like if/then/else or for-each to be part of the
    syntax of the language, and not just plain message-sending. I guess
    this is where my inexperience with Smalltalk shows 🙂 Regardless of
    whether one is redefining syntax or just changing the way messages are
    handled, the end result is that one could end up with code that looks
    to do one thing but really do something other. As both you and I
    mentioned, this is not a problem unique to Smalltalk (my example was
    operator overloading in C++/.Net), but I suspected the problem could
    be larger in smalltalk as it allows for more changes. If I recall
    correctly, one of the reasons given for not introducing operator
    overloading in Java was that experience had shown that the freedom
    gained by it was not worth the added complexity.

    But, if this is no problem in practice in Smalltalk, I shall stop
    thinking that it is 🙂

    Re: Smalltalk not catching on: What I said was that while some key
    concepts from the smalltalk world did catch on (MVC, JIT, design
    patterns, XP, you know them all), smalltalk itself didn’t, or att
    least not to the same extent. And it seems to me that the concepts
    didn’t need any marketing at all, which ties in with another risk
    aspect that I forgot to menton in my previous answer; that
    of the risk with a smaller development community. For example, when I
    sat down with Squeak a couple of weeks ago, and was just trying out
    some things (adding methods to the Object class as described in
    http://squeak.org/tutorials/cphoenix_tutorial/intro.html), I got a
    couple of error messages ("Nothing more expected" and "End of block
    expected"). I had no idea what they meant, and couldn’t find anything
    in the online help. Now, had this been C#, I could just have entered
    those phrases into Google and probably get a explaination fairly
    quickly, or failing that, I could have asked any of my friends that
    know C#. With Squeak, however, I found myself stranded. I figured it
    out eventually, but here my experience was that I immediately hit a
    brick wall.

    And I have to think that, if I was to use Squeak in a real project, I
    would encounter this experience over and over again. For example, if I
    want to connect to a Mysql database (not an uncommon scenario), the
    top ten results for "squeak mysql" are pretty thin in information,
    while "C# mysql" returns a bunch of tutorials and howto’s. Similarly,
    there’s the issue of available components to build upon; the more code
    that is available for your environment, the more you can lower the
    risk by avoiding to write it yourself. In highly popular environment,
    you can often choose between different implementations of the same
    functionality (like grid controls or HTTP libraries) which further
    lowers risk, in the case that the one you initially chose turn out to
    be a bad choice. A similar problem is that there are fewer people that
    have good Smalltalk experience, which translates into a potential
    maintenance problem.

    Of course, neither of these things may be Smalltalk’s "fault", but
    I think they do increase the risk when using the platform.

    Re: Polymorphism as a complex concept. I think I’d better clarify my
    position on polymorphism. Of course it’s (mostly) a good thing. I’m
    just saying just that it can be harder to get right. For example,
    encapsulation is something that most people get instinctivly and can
    start to apply to their own code at once. While polymorphism may be
    easy to explain (using familiar concepts like a Car Is-a Vehicle or
    Triangle Is-A Shape), it’s harder in practice as most of our programs
    doesn’t deal with vehicles or shapes, they’re more along the line of
    database backed websites, where it’s more difficult to realize which
    concepts make good base classes (should I make Manager a subclass of
    Employee, or just have a title field on the Employee class?), where a
    interface would be appropriate (are interfaces used in Smalltalk?) and
    so on.

    I think I’ve just seen too much code that has been prematurely
    generalized to think that increased abstraction (which polymorphism
    encourages) is unconditionally a good thing. It’s only good when used
    properly. That’s of course true for anything, but contrast this with
    encapsulation, which is much harder to get wrong (and in most cases
    easier to change once you realize it). This is where it pays of to
    have good lead designers who know the problem domain 🙂

    I actually wrote another blog entry of the dangers of premature
    generalizations a while ago:
    http://blog.tomtebo.org/PermaLink.aspx?guid=854820f8-2f40-42c6-af78-eed20596eb3a

    However, now I’ve really let the subject wander off Smalltalk… Have
    you tried out any of the Smalltalk compilers for .Net (#Smalltalk and
    #S.Net)? I guess Squeak is better for learning Smalltalk, but it would
    be good to know if I can use it in an environment with which I’m a
    little more familiar.

  3. Hi!

    | Thank you again for your comments! I’ll address them in an slightly out-of-order fashion.

    And I will try this |-style this time. 🙂

    | Re: confusion resulting from redefining syntax. You’re right in that I considered things like if/then/else or for-each to
    | be part of the syntax of the language,

    Right, which it isn’t in Smalltalk. 🙂

    | and not just plain message-sending. I guess this is where my inexperience with Smalltalk shows 🙂 Regardless of whether
    | one is redefining syntax or just changing the way messages are handled,

    No, sorry. "Wrong" again. By implementing any of these common messages
    in your objects (or existing ones) you are *not* "changing the way
    messages are handled".

    | the end result is that one could end up with code that looks to do one thing but really do something other.

    Eh, no. 🙂 Ok, let’s take an example more resembling the Java world
    (assuming you know Java). Iteration in Java:

    Iterator i = anObjectAuthoredBySomeoneElse.iterator();
    while (i.hasNext()) {
    SomeClass elem = (SomeClass)i.next();
    elem.doSomething();
    }

    Now, if you would see this code you would simply assume that the quite
    common message "iterator()" gives you an Iterator. And that hasNext()
    tells you if you are done etc. Right? This is as close we can get to a
    for-each in Java – well, we can mess with anonymous inner classes
    (shudder) but I will abstain. So you will simply assume this is the way
    it works and you would get pretty confused if it didn’t work as *you
    expected*.

    […rest below, testing if a shorter post might work…]

  4. Hehe!

    Staffan, you need to fix your blog – it didn’t handle too large postings. What is it written in? 🙂 Rest follows:

    Ok, let’s see how it looks in Smalltalk:

    anObjectAuthoredBySomeoneElse do: [:each | each doSomething]

    What are we looking at here? Let me just change the syntax a bit:

    anObjectAuthoredBySomeoneElse.do([:each | each.doSomething()])

    Ok, this is bastardized Java/Smalltalk code – not sure it helped – but
    anyway. We send a message "do(aCodeBlock)" to the object with an
    argument that is an anonymous function that takes one argument called
    "each". After the "|" and before the "]" we have the actual code of the
    function. It sends the message "doSomething()" to the object bound to
    the parameter "each". The "do(aCodeBlock)" message is thus a so called
    "higher order function", since it takes a funtion as its argument.

    So – my point being? 🙂 Well, by being able to have anonymous functions
    (so called blocks) as objects that can be sent around we can very easily
    solve the for-each problem by simply implementing a "do(aCodeBlock)"
    method and have it run the block of code for each element in itself.
    Have we changed the way "messages are handled"? Not in the least.

    Does it "look to do one thing but really do something other?" Nope.
    Whenever I see a "do:" then I think "Aha, iteration.". No magic involved
    at all. No syntax has been changed. Just plain old polymorphism. All
    Collections understand do: in Smalltalk.

    | As both you and I mentioned, this is not a problem unique to Smalltalk (my example was operator overloading in C++/.Net),
    | but I suspected the problem could be larger in smalltalk as it allows for more changes. If I recall correctly, one of the
    | reasons given for not introducing operator overloading in Java was that experience had shown that the freedom gained by
    | it was not worth the added complexity.

    Operator overloading is different. A "+" isn’t a message in C++/Java/C#.
    So suddenly you need to invent a new term "operator overloading" to
    handle redefining them. And sure as hell people will get confused
    because since it isn’t a message they sure as hell don’t expect it to be
    overloaded in the "default case"! And since operators are different you
    get into all sorts of interesting trouble in those languages. In
    Smalltalk it would be trivial to redefine "+" because it is just a
    message. But it is still seldom done, because as I said – not many
    things are additive. 🙂

    | But, if this is no problem in practice in Smalltalk, I shall stop thinking that it is 🙂

    Goodie. 🙂 In fact, I would say as having lots of languages "under my
    belt" that Smalltalk is the language giving me the least surprises –
    both in my own code, or other’s. It has multiple reasons of course, but
    that is the way it is.

    | Re: Smalltalk not catching on: What I said was that while some key concepts from the smalltalk world did catch on (MVC,
    | JIT, design patterns, XP, you know them all), smalltalk itself didn’t, or at least not to the same extent. And it seems
    | to me that the concepts didn’t need any marketing at all, which ties in with another risk aspect that I forgot to menton

    Well, I think it has to do with the fact that the concepts can be moved
    into other languages/tools gradually. But the language/environment
    itself is a much bigger "jump" for many people. Funny though, because it
    is such a simple language if you just take a little, little time to
    learn it.

    I find it very interesting that if you look at the "script languages"
    (don’t like the term, but anyway) they are moving closer and closer to
    Smalltalk. Perl is a dynamically typed language, but not very OO. Python
    moved gradually closer by being cleaner and more OO. Ruby is so close to
    Smalltalk the only things missing are the superior syntax :), the meta
    model and the image concept, and perhaps a few more things! 🙂 But it is
    *very* close. I spoke to Yukihiro Matsumoto when I was at OOPSLA and he
    is very frank about this.

    So eventually someone will come up with the language "Saphire" and
    people will think it is an improved Ruby, while in fact it is simply
    Smalltalk. 🙂

    | in my previous answer; that of the risk with a smaller development community. For example, when I sat down with Squeak a
    | couple of weeks ago, and was just trying out some things (adding methods to the Object class as described in
    | http://squeak.org/tutorials/cphoenix_tutorial/intro.html), I got a couple of error messages ("Nothing more expected" and
    | "End of block expected"). I had no idea what they meant, and couldn’t find anything in the online help. Now, had this
    | been C#, I could just have entered those phrases into Google and probably get a explaination fairly quickly, or failing
    | that, I could have asked any of my friends that know C#. With Squeak, however, I found myself stranded. I figured it out
    | eventually, but here my experience was that I immediately hit a brick wall.

    Well, there are very good channels to learn and get help. Two of the
    best places are:

    http://www.iam.unibe.ch/~ducasse/FreeBooks.html
    http://minnow.cc.gatech.edu/squeak

    And Squeak has an extremely helpful and active mailinglist with newbies
    and professionals mixing together. Even Alan Kay and Dan Ingalls are
    active on that list. Circa 1000 subscribers and 30-50 postings per day.
    Newbies are very welcome.

    How many *professional quality* Java books can you get for *free* in pdf
    from the web?

    […rest below…]

  5. And the last part:

    | And I have to think that, if I was to use Squeak in a real project, I would encounter this experience over and over
    | again. For example, if I want to connect to a Mysql database (not an uncommon scenario), the top ten results for "squeak
    | mysql" are pretty thin in information, while "C# mysql" returns a bunch of tutorials and howto’s. Similarly, there’s the

    Sure, you can always say that a more popular language is better, just
    because it is more popular. My personal experience though is that it
    doesn’t counter the disadvantages. Now I am primarily comparing
    Java/Smalltalk. And sometimes you just need to look a little bit closer.
    For example, the treasure chest I mentioned above (the free books) is
    almost unparallelled AFAIK.

    Btw, here you have 400 packages for Squeak neatly cataloged:

    http://map1.squeakfoundation.org/sm

    And just to show some db stuff you were looking for:

    http://map1.squeakfoundation.org/sm/packagebyname/mysql
    http://map1.squeakfoundation.org/sm/packagebyname/postgres
    http://map1.squeakfoundation.org/sm/packagebyname/goods
    http://map1.squeakfoundation.org/sm/packagebyname/magma
    http://map1.squeakfoundation.org/sm/packagebyname/odbc
    http://map1.squeakfoundation.org/sm/packagebyname/berkeley
    http://map1.squeakfoundation.org/sm/packagebyname/minnestore
    http://map1.squeakfoundation.org/sm/packagebyname/omnibase

    And perhaps I missed a few. Most of these you can install by a *single
    menu choice* from inside Squeak. It will download and install all for
    you. Sure, not perfected yet as it is in Debian/apt-get – but I am
    working on it. (SqueakMap is my baby)

    | issue of available components to build upon; the more code that is available for your environment, the more you can lower
    | the risk by avoiding to write it yourself. In highly popular environment, you can often choose between different
    | implementations of the same functionality (like grid controls or HTTP libraries) which further lowers risk, in the case

    As I said – there is more out there than you may know. And if popularity
    was the *only* criteria then we would all be hacking VB, right? 🙂

    | that the one you initially chose turn out to be a bad choice. A similar problem is that there are fewer people that have
    | good Smalltalk experience, which translates into a potential maintenance problem.

    That argument is a common one – and I really don’t buy it. IMHO a good
    OO developer can pick up any OO language in a pretty short period of
    time. Smalltalk, Java, C#, Python, Ruby, Delphi etc. Not C++ though. 🙂
    And of these languages Smalltalk is one of the simplest to pick up.
    Really. I have seen it multiple times in practice – it is not a problem.

    A language is a tool and a developer is an craftsman. If he/she couldn’t
    learn how to use a new tool then he/she isn’t a good craftsman.

    | Of course, neither of these things may be Smalltalk’s "fault", but I think they do increase the risk when using the
    | platform.
    |
    |
    | Re: Polymorphism as a complex concept. I think I’d better clarify my position on polymorphism. Of course it’s (mostly) a
    | good thing. I’m just saying just that it can be harder to get right. For example, encapsulation is something that most
    | people get instinctivly and can start to apply to their own code at once. While polymorphism may be easy to explain
    | (using familiar concepts like a Car Is-a Vehicle or Triangle Is-A Shape), it’s harder in practice as most of our programs

    Now you are talking about inheritance. Just because inheritance is more
    or less needed for polymorphism in many statically compiled OO languages
    doesn’t mean it *is polymorphism*. Polymorphism is just the ability to
    have different objects understanding the same message but potentially
    responding differently. Period. (this is btw the primary reason for
    C++-people so fixated with multiple inheritance and Smalltalkers just
    don’t get it – in C++ you very much need MI to get polymorphism, in
    Smalltalk inheritance has nothing to do with it)

    | doesn’t deal with vehicles or shapes, they’re more along the line of database backed websites, where it’s more difficult
    | to realize which concepts make good base classes (should I make Manager a subclass of Employee, or just have a title
    | field on the Employee class?), where a interface would be appropriate (are interfaces used in Smalltalk?) and so on.

    Now you are wandering off into the OO vs RDB mess. Sure, hard as hell.
    Has always been. But people just can’t let go of their RDBs can they? 🙂

    I have worked quite a lot with OODBs and I dearly recommend *anyone*
    serious about OO to try one sometime. Poof, problem goes away. But
    again, this has nothing to do with polymorphism IMHO. It is simply the
    OO/relational-mismatch problem. You also mention issues related to the
    general problem of good OO design – and good design is always tricky –
    OO or not. Definitely not an issue related to Smalltalk.

    […rest follows…]

  6. | I think I’ve just seen too much code that has been prematurely generalized to think that increased abstraction (which
    | polymorphism encourages) is unconditionally a good thing. It’s only good when used properly. That’s of course true for
    | anything, but contrast this with encapsulation, which is much harder to get wrong (and in most cases easier to change
    | once you realize it). This is where it pays of to have good lead designers who know the problem domain 🙂

    Hmmm, I agree – premature generalization is a common mistake. You can
    see it in full bloom today in various Java frameworks – often
    overengineered as hell IMHO. Not that it doesn’t happen in Smalltalk
    too. But I definitely don’t agree that this has anything to do with
    polymorphism – you are again talking about complex inheritance I think.
    Well, shades of gray and all that of course. STTCPW is a good motto
    regardless of language. Anoter simple rule is to not create abstract
    classes until you have two concrete subclasses. 🙂

    | I actually wrote another blog entry of the dangers of premature generalizations a while ago: > http://blog.tomtebo.org/PermaLink.aspx?guid=854820f8-2f40-42c6-af78-eed20596eb3a

    Yes, I am actually working on an article in a similar direction – it is
    called "The Art Of The Minimal". It will show how simple and easy things
    *can be* if you pick the right tools (Smalltalk, OODB, a good web
    framework). Well, it isn’t ready by a longshot yet, but anyway.

    […rest follows…]

  7. Sigh, sorry for messing up your blog like this:

    | However, now I’ve really let the subject wander off Smalltalk… Have you tried out any of the Smalltalk compilers for
    | .Net (#Smalltalk and #S.Net)? I guess Squeak is better for learning Smalltalk, but it would be good to know if I can use
    | it in an environment with which I’m a little more familiar.

    Yes, first of all – you have the variants for .Net, SharpSmalltalk is quite nice.
    It is very free, I ran the benchmarks without problem on both Mono and
    MS .Net. It has quite good .Net integration. Sure, lacking the image
    environment it sure doesn’t feel as a Smalltalk – but it is neat to know
    we have it. This is a Smalltalk to CIL compiler.

    I haven’t played with Smallscript much but this is a very capable Smalltalk with tons of
    features and very, very good performance. It can run both on its own
    high performance runtime and .Net. Not free. No image concept. David Simmons, the primary
    developer is one of the most experienced Smalltalk VM implementors
    around. Very interesting guy to talk to over a beer or two. 🙂

    But if you tell me your requirements a bit more I can probably give you
    some more pointers to other interesting options. Squeak is IMHO the best
    place "to be" simply because of its powerful community, people really
    will help you. There are so many, many things going on there right now –
    a true buzz. For example, just the other day this saw the light:

    http://homepage.mac.com/rgayvert/wxsqueak.html

    I played with it and it looks like we now can write native UI apps in
    Squeak too. 🙂 Unfortunately my little hobby Gtk binding suddenly
    doesn’t look as cool:

    http://anakin.bluefish.se/gohu/25

    But I will probably keep working on it just for fun.

    regards, Göran

  8. <<… For example, when I sat down with Squeak a couple of weeks ago, and was just trying out some things (adding methods to the Object class as described in http://squeak.org/tutorials/cphoenix_tutorial/intro.html), I got a couple of error messages ("Nothing more expected" and "End of block expected"). I had no idea what they meant, and couldn’t find anything in the online help. Now, had this been C#, I could just have entered those phrases into Google and probably get a explaination fairly quickly, or failing that, I could have asked any of my friends that know C#. With Squeak, however, I found myself stranded. I figured it out eventually, but here my experience was that I immediately hit a brick wall. …>>

    If you are using VisualWorks/Smalltalk, http://www.cincomsmalltalk.com/, you have a lot of info on-line; Blogs, tutorials, wikis, docs (usually in pdf) etc etc.

    There are also a VWNC mailing list, vwnc@cs.uiuc.edu, and a news group, comp.lang.smalltalk.
    Just ask anything. Usually you get an answer in minutes!

    If you want to try VisualWorks NC (a non-commercial full fledge version of VisualWorks) just download it from http://smalltalk.cincom.com/downloads/index.ssp.

    /Björn

  9. Btw, now that I have utterly filled this page with comments I can do one more.

    I wrote "this is silly" up there and I meant the chopped up comments, just wanted to make that clear.

    Furthermore I also noticed I didn’t answer if interfaces are used in Smalltalk. Well, yes and no. Yes as in "there are groups of messages commonly referred to as protocols", at leat if you look in the X3J20 ANSI standard for Smalltalk.

    But there is no mechanism in Smalltalk for interfaces – meaning it is purely by convention. Although since Smalltalk is so malleable there have been many language experiments (just like in the Lisp community) like:

    http://map1.squeakfoundation.org/sm/packagebyname/smallinterfaces

    and

    http://map1.squeakfoundation.org/sm/packagebyname/aspects

    regards, Göran

  10. Göran,

    > Staffan, you need to fix your blog – it didn’t handle too large
    > postings. What is it written in? 🙂

    C# 🙂 I’m sorry about that. The problem wasn’t actually the size of the post, it was that the ASP.NET framework considered some of your comments to be potentially dangerous. 🙂 (The offending character sequence seems to be "script" followed by a ":" – this is a built-in safeguard against XSS attacks, and the reason you didn’t get a sensible error message is that by default, informative error messages aren’t sent to remote clients to prevent information disclosure). A well-written ASP.NET application is supposed to catch the resulting security exception and do something sensible, I think.

    Anyway, thank you for further clarifying my concerns about Smalltalk. I’m not going to address all points, since I think you’ve explained them in such detail that I do not really have anything to add:-) How come you aren’t blogging? So, what follows is mostly questions.

    > Does it "look to do one thing but really do something other?" Nope.
    > Whenever I see a "do:" then I think "Aha, iteration.". No magic involved
    > at all. No syntax has been changed. Just plain old polymorphism. All
    > Collections understand do: in Smalltalk.

    So, is the "do:" message with accompanying code block similar to the way you would use map with a lamdba function to iterate over a list in Lisp?

    > Well, I think it has to do with the fact that the concepts can be moved
    > into other languages/tools gradually. But the language/environment
    > itself is a much bigger "jump" for many people. Funny though, because it
    > is such a simple language if you just take a little, little time to
    > learn it.

    I can understand that the environment is a big jump for people, since it’s very different from what they’re used to. The entire concept of an image (no source code files? no compiler that produces some sort of executable file? the development environment is the virtual machine?) is a bit unusual to me. And I’m a heavy Emacs user!

    Yet is seems that the environment/image (what exactly is the definition of an "image", in the Smalltalk world, by the way?) is almost as big a part of the Smalltalk way as the language itself. Is this correct?

    > How many *professional quality* Java books can you get for *free* in pdf
    > from the web?

    Well, I learned most of what I know from Bruce Eckel’s "Thinking in Java", which is freely downloadable, but I see your point…

    By the way, which book would you recommend that a programmer new to Smalltalk, but looking to start out with Squeak, should start with? I took a look at the Squeak specific books, but they seemed to deal mostly with specific programming areas and how to do them in Squeak, I didn’t find a general introductory text. Are there large differences between Squeak and other Smalltalk environments?

    > And perhaps I missed a few. Most of these you can install by a *single
    > menu choice* from inside Squeak. It will download and install all for
    > you. Sure, not perfected yet as it is in Debian/apt-get – but I am
    > working on it. (SqueakMap is my baby)

    Interesting. SqueakMap seems to be similar to CPAN in the Perl world.

    > As I said – there is more out there than you may know. And if popularity
    > was the *only* criteria then we would all be hacking VB, right? 🙂

    Of course (although there are several good reasons besides popularity to choose VB, IMHO), but here I’m really only talking about why a Smalltalk project may have higher risk than, say, a Java or VB project. Not why one should choose one over the other.

    > And of these languages Smalltalk is one of the simplest to pick up.
    > Really. I have seen it multiple times in practice – it is not a problem.
    >
    > A language is a tool and a developer is an craftsman. If he/she couldn’t
    > learn how to use a new tool then he/she isn’t a good craftsman.

    I’m not sure I agree with that. The general language concepts may be a tool, but they really go together with the toolbox that is the frameworks we use. To be a good C# programmer, you have to not only master the language itself, you have to understand the underlying runtime environment, a good deal of the base class library, plus any other frameworks you might use (like the entire ASP.NET model).

    Now, Smalltalk as a language may be easier to learn, and the class libraries may be better designed (I have no idea if they are, but I give them the benefit of the doubt here) and so easier to get familiar with, but I still don’t think my successor I’d be up to full speed so quickly that it would not matter to the people paying the bills.

    Also, you qualify your statement with "a _good_ OO developer can…" (emphasis mine). One of my initial statements in my "Smalltalk increases risk" theory was that it’s especially true when not all developers on the team are that good. And just to anticipate your comment: I’m sure exposure to Smalltalk will make any developer better 🙂

    > Now you are talking about inheritance. Just because inheritance is more
    > or less needed for polymorphism in many statically compiled OO languages
    > doesn’t mean it *is polymorphism*. Polymorphism is just the ability to
    > have different objects understanding the same message but potentially
    > responding differently. Period. (this is btw the primary reason for
    > C++-people so fixated with multiple inheritance and Smalltalkers just
    > don’t get it – in C++ you very much need MI to get polymorphism, in
    > Smalltalk inheritance has nothing to do with it)

    Well, it’s true that I look at OO from a more static viewpoint. But the hard part when using polymorphism is to look at the problem and figure out what concepts share similar behaviour and thus make sense to act on in a similar way. We are told that "it’s good OO" to identify such cases and thereby creating a more generalized system with less code, which leads to systems which have a very abstract view of the concepts. More often than not, I find that this is done through interfaces, not inheritance — sometimes with only a single class implementing said interface.

    > But if you tell me your requirements a bit more I can probably give you
    > some more pointers to other interesting options.

    Well, I have been toying with the idea of writing a combined blog/wiki engine, sort of like SnipSnap or the Bliki that Martin Fowler has. My intention was to write this in C# on the ASP.NET framework, but since this discussion has awoken my interest in Smalltalk, I thought it would be a useful test to write a similar system in that language. I guess Squeak together with Comanche is the best way to get started?

    > I played with it and it looks like we now can write native UI apps in
    > Squeak too. 🙂

    Speaking of which: Is it possible to package a squeak image/VM so that it appears as a normal program for the user (double-click the .EXE and the program pops up windows?)

  11. Hi Staffan!

    More answers coming soon – just first Squeak vs VW vs the rest:

    My answer is "it depends". 🙂 You can learn Smalltalk using either one. Both are direct descendants to Smalltalk-80, so the language and a lot of the base classes are more or less the same.

    VW is a polished high performance commercial product so it has a faster VM, much better support for "commercial UIs" etc. I also assume it is more or less ANSI compliant, but I am not sure. It runs on tons of platforms.

    Squeak 3.7 (currently in beta) is also ANSI compliant and runs on tons of platforms. Squeak’s biggest strength is IMHO the community. A very vibrant open source community with lot of things going on. Squeak also has very good multimedia support, especially 3D.

    So it depends a bit what you want. If you are into webapps then Squeak is IMHO the scene where things are going on right now – Seaside from Avi Bryant is redefining how to build webapps and even though it has been ported to VW the home platform is Squeak. 🙂 Squeak is IMHO "the Linux of Smalltalks", it grows in popularity day after day and it is a joy of participating in its development.

    Take a look at both. And btw, there are a bunch more interesting Smalltalk environments too. Like Dolphin or VAST (IBM) etc etc.

    regards, Göran

  12. Lots of good questions and I will try to answer them all.

    Sidenote: Noticed that gnuheter.org is also mentioning your article.

    > So, is the "do:" message with accompanying code block similar to the way you
    > would use map with a lamdba function to iterate over a list in Lisp?

    Yes. Here is a more powerful example of code blocks:

    (#(1 2 3 4 5) select: [:elem | elem odd ])
    collect: [:elem | elem * 2]

    "#(1 2 3 4 5)" is the literal syntax for an instance of the class Array. First we send "select:" to it with a block taking one argument. It will return a new Array with only those elements that the block evaluates to true for, in this case the elements that answer true when we send the message "odd" to them. Then we send "collect:" to that Array which creates a new Array with the values that the block returns – in this case we multiply the elements with 2. This evaluates to "#(2 6 10)".

    > How come you aren’t blogging?

    Well, not sure. I have been thinking of doing it but well. 🙂 I do write sometimes at people.squeakfoundation.org.

    > I can understand that the environment is a big jump for people, since it’s very different from
    > what they’re used to. The entire concept of an image (no source code files? no compiler that
    > produces some sort of executable file? the development environment is the virtual machine?)
    > is a bit unusual to me. And I’m a heavy Emacs user!
    >
    > Yet is seems that the environment/image (what exactly is the definition of an "image", in the
    > Smalltalk world, by the way?) is almost as big a part of the Smalltalk way as the language
    > itself. Is this correct?

    Yes, it sure is. In later years I have come to the conclusion that the "image" is one of the great pillars of Smalltalk.

    So, what is it? Well, it is a "place" where objects live. 🙂 Truly. Technically one could say that the image is a snapshot of the RAM. When I run Squeak it is a VM that loads an image file into memory. The image is the exact snapshot from yesterday – including live Processes and everything. Then when I work in Smalltalk I am "running it" and all my tools are instances of objects living in this "world of objects".

    This makes Smalltalk a truly interactive "world of objects" which I can manipulate, inspect, send messages to, debug, analyze etc. And all my classes are objects too. And all my tools are objects too.

    Think Emacs on steroids. 🙂

    One very cool little essay called "Cult Of Dead" on this subject was written by Jim Benson:

    http://minnow.cc.gatech.edu/squeak/2950

    Read it, it is *very* good.

    > By the way, which book would you recommend that a programmer new to Smalltalk, but looking
    > to start out with Squeak, should start with? I took a look at the Squeak specific books, but they
    > seemed to deal mostly with specific programming areas and how to do them in Squeak, I didn’t
    > find a general introductory text. Are there large differences between Squeak and other Smalltalk
    > environments?

    The Squeak books are actually article compilations. Not very suited for beginners. It was such a long time ago I read any Smalltalk book so I can’t remember which ones where good. But one of the books at the URL I gave you is swedish, might be a good first book, I vaguely remember that it was good and since Björn is a member of SweSUG (Swedish Smalltalk User Group, http://swiki.squeakfoundation.org/swesug) I would say it is superb! 🙂

    Other popular books are "Inside Smalltalk" and "The Art And Science of Smalltalk". But hey, just download them all and have a look!

    Perhaps some more links here: http://minnow.cc.gatech.edu/squeak/377

    > Interesting. SqueakMap seems to be similar to CPAN in the Perl world.

    Yes, but more geared to be a catalog than an archive. Debian is my primary source of inspiration.

    > > As I said – there is more out there than you may know. And if popularity
    > > was the *only* criteria then we would all be hacking VB, right? 🙂
    >
    > Of course (although there are several good reasons besides popularity to choose VB, IMHO),
    > but here I’m really only talking about why a Smalltalk project may have higher risk than,
    > say, a Java or VB project. Not why one should choose one over the other.

    Hmmm, I think that looking at risk would surely affect "why" one would choose one over the other. 🙂 Anyway, personally I have lots of experience with Java and Smalltalk. I haven’t worked in VB, though I think I have a grasp about its strengts and weaknesses. As always, the right tool for the right job.

    The arguments that have been laid forward here (Smalltalk risk etc) are arguments that I haven’t *experienced* and thus I am replying. 🙂 If you want me to list arguments against Smalltalk I could do that of course – but not in general – I need a case first because as always the "job" dictates the choices.

    > > And of these languages Smalltalk is one of the simplest to pick up.
    > > Really. I have seen it multiple times in practice – it is not a problem.
    > >
    > > A language is a tool and a developer is an craftsman. If he/she couldn’t
    > > learn how to use a new tool then he/she isn’t a good craftsman.
    >
    > I’m not sure I agree with that. The general language concepts may be a tool, but they really go
    > together with the toolbox that is the frameworks we use. To be a good C# programmer, you have
    > to not only master the language itself, you have to understand the underlying runtime
    > environment, a good deal of the base class library, plus any other frameworks you might use
    > (like the entire ASP.NET model).

    Sure. And also note I wasn’t thinking of consultants but of employed developers. I still maintain that a good developer with experience in several tools and environments/frameworks/libraries can pick up new ones quite easily. In fact – that is what we do all day, right? How long has .Net been around?

    When I say "quite easily" I am of course still talking months – but for an employed developer that isn’t a problem, he/she can be productive with mentoring quite fast and then pick up the rest along the way. You learn what you use. I don’t know the whole Smalltalk class library – but I do know "how to fish" and I do know "enough" about several parts. And when I need specific parts I just learn it on the fly.

    > Now, Smalltalk as a language may be easier to learn, and the class libraries may be better
    > designed (I have no idea if they are, but I give them the benefit of the doubt here) and so easier
    > to get familiar with, but I still don’t think my successor I’d be up to full speed so quickly that it
    > would not matter to the people paying the bills.

    It sounds like you are thinking of consultants, and that is a special case. The libraries in the Smalltalk world are generally of very high quality IMO.

    > Also, you qualify your statement with "a _good_ OO developer can…" (emphasis mine). One of
    > my initial statements in my "Smalltalk increases risk" theory was that it’s especially true when
    > not all developers on the team are that good. And just to anticipate your comment: I’m sure
    > exposure to Smalltalk will make any developer better 🙂

    Yes, but this is a different situation. I agree with you in general, in fact that has been one of my primary arguments against C++ for a very, very long time. "Not all team members are good".

    But now I was saying that if you want to employ a developer you should not stare blindly on the languages he/she knows. It would be like staring at the tool box of the carpenter in order to judge if he is a good carpenter. If he is a good carpenter he will quickly learn new tools.

    And I still also maintain that Smalltalk is much easier to be productive in for an averaged developer than Java, simply because it is much simpler, more streamlined, less special cases, less complex yaddayadda.

    > Well, it’s true that I look at OO from a more static viewpoint. But the hard part when using
    > polymorphism is to look at the problem and figure out what concepts share similar behaviour
    > and thus make sense to act on in a similar way. We are told that "it’s good OO" to identify such
    > cases and thereby creating a more generalized system with less code, which leads to systems
    > which have a very abstract view of the concepts. More often than not, I find that this is done
    > through interfaces, not inheritance — sometimes with only a single class implementing said
    > interface.

    IMHO one problem with statically typed languages is that you need to decide these things "up front". They encourage "premature design" because until you have written that interface or created that class hierarchy you simply *can’t* send the same message to those objects!

    And sometimes it feels bothersome so you cheat. Ok, I will just make a little if-then-else here and that will be it. Or perhaps a little instance-of test, just a single line instead of having to create an interface, blabla…

    In Smalltalk these things grow on you instead. You suddenly realize that hey, these guys could actually use a superclass. Mmm, nice rafactoring. Or, ok, I just use the same message here to these guys and tada polymorphism! No problem. Want to change it tomorrow? Easy!

    Another problem is "other people’s code". Hmmm, I could use polymorphism here, but darn – then I need to add an interface to that class with Anders wrote. Bah, skip it.

    Anyway, you get my point. In Smalltak it is easier. 🙂 I don’t spend much time "figuring it out" – let it grow on you, let the realizations come as you work along, remember YAGNI.

    > Well, I have been toying with the idea of writing a combined blog/wiki engine, sort of like
    > SnipSnap or the Bliki that Martin Fowler has. My intention was to write this in C# on the
    > ASP.NET framework, but since this discussion has awoken my interest in Smalltalk, I thought it
    > would be a useful test to write a similar system in that language. I guess Squeak together with
    > Comanche is the best way to get started?

    Do this:

    Pick up Squeak, install Seaside (superb web framework, beats all) and take a look at SmallWiki and SmallBlog (a blog written in Seaside). Those are all on SqueakMap.

    Seaside:

    http://beta4.com/seaside2/

    Here is some about SmallWiki:

    http://kilana.unibe.ch:9090/smallwiki

    Some SmallBlogs:

    http://www.wiresong.ca/seaside/blog/colin
    http://blogs.inextenso.com/seaside/blog/learning

    And join squeak-dev and/or Seaside’s mailinglist for answers. 🙂

    > Speaking of which: Is it possible to package a squeak image/VM so that it appears as a normal
    > program for the user (double-click the .EXE and the program pops up windows?)

    Yes and no. Squeak is a bit special here. Sure, you can rename the vm to myapp.exe and change the icon and then double click on it to start the app. It will use the image called myapp.image by default IIRC. There are even some trickery to merge the image with the VM into a single .exe file but hey, who cares. 🙂

    Regarding multiple windows – that is trickier. Squeak is a desktop on its own and does currently all of its stuff inside its own window. Squeak can in fact run on the bare metal – no OS needed at all. If you want to do win32 "native UIs" then Squeak is not the best choice today. Dolphin or VAST are better. VW works like Swing does. But wxSqueak looks promising.

    regards, Göran

  13. Maybe it is just my opinion but I get this feeling of an old environment in Squeak and even more boxed than in other Smalltalk environments. The latter I personally think had been the biggest hindrance to Smalltalk’s success for the common programmer. I mean ”the simplest thing that could possible work” is not that simple as writing a few lines of code and just run it (maybe after a compilation step). Don’t interpret me wrongly I think the tools in a Smalltalk environment are the most awesome there is. Maybe I find the tools in VisualWorks even more awesome than the ones in Squeak.
    For instance look at John Brants’ refactoring browser (which is the standard browser in VisualWorks nowadays), or the various means of version handling and sharing code, or just the plain benefits of having a GUI builder around.
    But it is hard for a newcomer to write the simplest possible program. You have to learn a lot of tools first. As an experienced user you couldn’t live without all these tools and the interactivity the image gives you.
    But related to the image is the question the new comer always asks, ”How can I build a freestanding application”? Even an experienced developer could hesitate before ”striping” an image to make a deployed image/application. The latter is by the way a known issue by Cincom and they are working on a way to build an application up instead, i.e. one adds the tools needed instead of removing at deployment time.

    Talking about multi media, I lack some of the Squeak’s fancy graphical tools in VisualWorks. But today VisualWorks have 3D-tools to interface to OpenGL, reasonable powerful GUI builders, provisions for audio (especially since Stephen Pope moved Sirene from Squeak to VisualWorks), a quite lively community (look at the goodies directory or the on-line shared repository handled via Store), etc. There are also quite good tools for building for the web, but I am sorry I have not looked at Avi Bryan’s work yet.

    I have not looked much a Squeak lately but some things I lacked on the language level, in comparison to VisualWorks, are Name Spaces, packages and parcels. I know there is some work going on in this direction in Squeak, but I still lack them.

    Cheers,
    Björn

  14. A few comments about Squeak’s shortcomings:

    – The Refactoring Browser is available in Squeak. Not installed by default though. Also don’t know how it compares.
    – There are some new browser tools available on SM, StarBrowser and OmniBrowser are two very interesting packages.
    – Source code management is a dream with Monticello IMHO. It is IMHO the perfect match of "CVS auto merge" and "semantically aware ENVY".
    – Granted, there is no GUI builder. Squeak has Morphic which is really, really cool. But there hasn’t been any strong committed focus on "business UIs" yet. wxWindows and Gtk are two interesting "trails" in that respect I think.
    – Stripping/lockdown etc isn’t that hard, but Squeak is also moving towards a "build it from the ground and up" approach (combination of Squat, Monticello and SqueakMap).
    – Namespaces/packages,parcels. Well, I have a namespace implementation that I think is cool, we will see what you think when I present it on our meeting :). Packages I think is more or less nailed now with Monticello/PackagInfo/SqueakMap.

    One of the really, really cool things Squeak has and VW doesn’t is Croquet. I am betting Croquet will become the "killer app" for Squeak. Mark my words.

    regards, Göran

  15. Yes, I know that John’s RB browser have been around.
    But I think it has improved lately.

    I think I must take a deeper look at Squeak. And other things as well. At the moment I investigate various data bases for VisualWorks, with an aim to provide for a new kind of server.

    But now I have to run
    Björn

  16. Hi Björn!

    As you know GemStone rocks. 🙂 But if you want a more "lightweight" solution I have also heard great things about Omnibase.

    Here at Bluefish I and Jonas are currently playing with GOODs (Java and Squeak) and Magma (Squeak).

    Oh, and if you want to look at something *new* in the OO/RDB field, take a look at Roe from Avi Bryant. A completely new deal on how to mix Smalltalk and RDBs.

    regards, Göran

Kommentarer kan inte lämnas på detta inlägg.