Smalltalk is very simple:

  • stmt:
    ^ expr
  • expr
  • expr
  • . stmt
  • expr:
  • msg:
  • This is the genealogy of the programming language Smalltalk:

    Smalltalk is a child of Simula and Lisp.
    Smalltalk was first known as Smalltalk in year 1969.
    It became Smalltalk-72 in year 1972.
    It became Smalltalk-74 in year 1974.
    It became Smalltalk-76 in year 1976.
    It became Smalltalk-78 in year 1978.
    It became Smalltalk-80 in year 1980.
    Then it begat Objective-C in year 1983.
    Then it begat Java in year 1991.
    Then it begat Ruby in year 1993.

    This genealogy is brought to you by the Programming Languages Genealogy Project. Please send comments to thbz.

    Smalltalk is an Object Oriented langauge based on LISP and Simula. This language was developed to be used on a device (called the Dynabook) that Xerox was designing so that non-specialist users could have a progamming language with the power of LISP and the easy concept of OO from Simula.
    The first implementation of Smalltalk was completed in 1972 and went through many revisions until 1980 when Xerox decided to release it to the public, even though at this stage the Dynabook project had been scrapped. A special issue of Byte Magazine published some introductory articles and Xerox published 3 books (it was originally supposed to be 4) about smalltalk.
    These books were (not the actual titles):
    • The Blue book - describing the language and implementation
    • The Orange book - describing Smalltalks UI
    • The Green book - an aid to implementors (whatever that means)
    Xerox looked for partners to help develop on other platforms and Apple Computers, Digital Equipment, Hewlett Packard and Tektronix stepped forward. Problems were weeded out and eventually, in 1983, the VI2 version was released.

    Over the years, many more implementations have come and gone but the most notable ones around at the moment are; Squeak - a slightly smaller but very portable version being developed by some of the original designers of Smalltalk, and VisualWorks - a proprietry version for the Windows platform.

    Smalltalk is a programming language that includes a whole development environment. Since this is an OO language, everything is refered to as an object, even down to the source and executable. This allows a great deal of flexibility because it means that the environment can be configured more easily to the tastes of the user.

    The way Smalltalk carries out instructions is different from procedural languages such as C++ (once you get into Smalltalk, you'll know what I'm getting at). For example:

    (1 + 2) printNl!
    This prints out 3 as you'd expect but it does it differently from you would. 1 and 2 are actually instances of the integer class. Inside the brackets, 2 calls the + method in 1 whcih creates a new object, 3. The printNl method is then called from 3 which displays it on the screen.

    To declare and object, simply type this:

    Object
        YourObject
        YourOtherObject
    
    Where Object is the base class of everything in Smalltalk. You can use another class if you like though.

    To create a new class, you need to send a message to the Object class.

    You get the idea about what this language is about now? As usual, /msg me with problems.


    Bibliography:
    http://kaka.cosc.canterbury.ac.nz/~wolfgang/cosc205/smalltalk1.html
    http://www.cs.oswego.edu/~odendahl/manuals/smalltalk/tutorial/ - this tutorial appears to be very good!
    SmallTalk may very well be the one true language of civilization and progress (and yes, I need medical help).

    It is not, however, the language of the future :(
    It's more of a half-forgotten treasure, alight with the lost wisdom of the ancients (also see Symbolics, Lisp Machines, Eiffel, or Project Orion).

    There are those that sit and lament the decline of a superior, more enlightened technology, lost to the barbarian hordes of the latter days (more like to the lack of management and advertising competence by its owners) (don't even think about starting on the VHS vs. Betamax thing, tho. This is different).

    There are those that ask, "Why is it, that we do not yet hold in our hot little consumer hands, computer technology that was developed decades ago?"

    That way lies certain doom! Instead, keep the light of knowledge alive, all ye true believers! Teach your children, educate your coworkers, and scribe the legends of a long-forgotten age so that one day the technology can be resurrected. Rejoice in seeing the wisdom of the old ways run in the veins of its offsprings (Objective-C, Java, Ruby, Squeak...).

    Its time shall come again!


    Note: This is not to imply that SmallTalk is dead. Saying that would certainly be news to the vibrant Smalltalk community, or to the various Smalltalk vendors such as IBM (Visual Age Smalltalk) or Cincom (Visual Smalltalk Enterprise), and certainly to the many companies who use SmallTalk as their primary development environment that are doing quite well. However, Smalltalk's place in the industry today is a far cry from the Xerox PARC's project Dynabook days and the dreams of its inventor.

    Ahem. I suppose that, among all of this ranting, I have not mentioned what Smalltalk is at its heart, nor explained its uniqueness.

    Smalltalk, as others have mentioned, is an Object-Oriented programming language. That fact alone is not enough for me to waste electrons on -- there are several things one has to understand about Smalltalk.

    Purity and Simplicity of Syntax
    Each line of Smalltalk code is like a string of pearls - object message, object message message. That's it, that's all there is to the language. When I code, I can almost picture the objects as small orbs on the mindscape, with messages as pulses of light traveling between the orbs in a vast, delicate network. I can't make any claims of productivity gains solely due to the Smalltalk syntax. I can say, however, that it's a simple, intuitive joy to code in this language.

    Smalltalk is the IDE
    This may seem strange to many C++ or Java coders who are used to the command-line compiler, and regard an IDE as little more than a souped up text editor for the lazy. Those who swear by, and cannot live without, their MS Visual Studio or JBuilder environments can start to appreciate the importance of a good IDE to a language; however, the symbiosis between Smalltalk the language and its IDE goes even beyond that.

    For one, a class browser in a typical Smalltalk IDE is a feat of informational organization. A single screen lists all the known objects, their methods (either instance and class methods by the flick of a switch), the variables used by that class, and finally the source code for a particular selected method. This setup allows the programmer to traverse the complex informational space of a large software project with amazing speed. For instance, if you click on a variable, all the methods that refer to that variable show up. More importantly, for a given method, you can see all its senders (other methods that call this one), as well as its implementers (for a commonly named method, think Java's toString(), a list of objects who implement that method). Thus, following the execution path/crumb trail of (somebody else's) code, across dozens of objects becomes almost effortless. Finally, there's the...

    Live Brain Surgery Effect
    Smalltalk's virtual machine is its greatest strength; the fact that it's a byte-code based interpreted language enables a programmer to delve right into the code of a program while it's running. Like a doctor performing a brain surgery without anaesthetic, with the patient awake and coherent and able to answer questions, a Smalltalk programmer can look and probe at a living, running program at any moment, and examine the contents of every variable in every method on the callstack. So say your program gets an error. Instead of deciphering the cryptic error messages, hunting for the mistake through the source code, recompiling and restarting the program... a window pops up. The window puts you directly into the call stack at the moment of the error, and you can examine the living guts (suspended in time) of the program - the values of all the variables in the methods on the stack; you can even execute code on the objects in those methods. And when you track down the error and change code in a method, only the code in that method is recompiled, while the program is still running! At that point, you can close the error window, and continue with the (still uninterrupted) program, but now with the correct code.

    Log in or registerto write something here or to contact authors.