Talk Like A Duck: Category smalltalk

Alan Kay, Super Hero

Rick DeNatale — Fri, 21 Nov 2008 00:03:00 -0500

Via Boing-Boing, Business week has just put a comic strip on their web site, which tells the story of how Alan Kay, inspired by a visit to Seymour Papert seeded the idea of portable computers.

Long term readers of this blog no doubt know that I hold Alan Kay in high regard. I got to meet him several times, first I think at an internal IBM conference on Object Oriented Programming in the mid 1980s, Another time was at a Digitalk developers conference, where I obtained a prize possession. At the time I was the IBM technical liaison with Digitalk. They released a new version of Smalltalk/V PM at this particular conference, and I was presented a copy of the supplemental manual for the release signed by all of the Digitalk developers, and also by Alan Kay, who wrote something like “to the most non-IBM like IBMer I’ve ever met.”

Reading the business week strip, I was reminded of an even earlier personal connection with Kay and Smalltalk. A year or so before I really got into Objects, I was working on IBM Mainframe software in Poughkeepsie, NY. One summer the project got an intern, named Radia Perlman, who was in graduate school at M.I.T. And is now known as the “mother of the internet” for her invention of spanning-tree protocol. It was only later that I learned that she was one of Papert’s students working on Logo and seeing how kids learned programming with Logo, and if I recall correctly she also visited Xerox PARC, and was involved in porting the concept of the Logo turtle model of graphics to Smalltalk, where it became the Pen object.

What a long strange trip it is!

The Pros and Cons of 64-Bit Architectures

Rick DeNatale — Sat, 01 Nov 2008 09:17:00 -0400

My former OTI colleague Andrew “Roo” Low just wrote an interesting article about the trade-offs involved in designing a VM (and software in general) to exploit 64-bit machine architectures. Although, Roo discusses JVM implementation, he also grounds it with his experiences developing the IBM/OTI Smalltalk VM, and the lessons would be equally applicable to, say, a Ruby implementation.

Will It Go Round in Circles?

Rick DeNatale — Wed, 15 Oct 2008 15:24:00 -0400

I really like seeing the resurgence of interest in my second most favorite programming language

One of the comments to the referenced Gartner Group blog post had a link to an IBM Developer Works article about using using Eclipse as a Smalltalk IDE.

It seems like a strange loop, since Eclipse is the descendant of IBMs old VisualAge. Now I happen to know a bit about this since I was involved at the beginning. I guess that enough time has passed that nothing I say here will affect anyone’s business.

IBM, Smalltalk, and VisualAge

VisualAge started out as a demonstration prototype I wrote using Digitalk Smalltalk/V. The idea was to make something like the NeXT interface builder in Smalltalk as an adjunct to the Smalltalk IDE. For those who are not hip to such things, the Interface Builder, originally a Lisp program before Steve Jobs hired the author, lives on as part of Apple’s XCode tool suite for OS/X for the Mac and the iPhone.

The demo got some key IBM executives excited, and so the VisualAge development organization was born. Development proceeded using Smalltalk/V, along with Object Technology International’s (OTI) Envy/Developer, which was the state of the art version and configuration management for Smalltalk team programming.

As the project progressed, IBM and Digitalk had a falling out over conflicting views of who should be doing what. I’d shown the prototype to them in my position as liaison between the two companies, and they launched their Look and Feel kit which was seen by IBM management as competition from a supplier. So since we already had a relationship with OTI because of Envy/Developer, and OTI was in the business of building Smalltalk VMs, including the VM used by Digitalk’s Smalltalk/V for the Macintosh, IBM switched horses and contracted OTI to build “IBM” Smalltalk. This eventually led to the acquisition of OTI by IBM Canada.

This was about the time we founded the ANSI X3J20 committee to forge a standard across the existing and emerging Smalltalk implementations. I served as the secretary of X3J20. Some of the other members included Peter Deutsch and Glenn Krasner of ParcPlace, which Xerox had spun-off from their Palo Alto Research Center to commercialize Smalltalk-80; George Bosworth of Digitalk; Allen Wirfs-Brock of Instantiations one of the more successful Smalltalk consulting companies in the Portland Oregon suburbs; David Simmons who was the brains behind the iconoclastic Smalltalk/Agents; and Bruce Schuchardt who worked for Servio-Logic or Gemstone, I can’t recall which name they were going under at the time. I’m sure that I’m forgetting some of the players, but I’ll plead senility.

One of the great joys of working in Smalltalk during it’s first “glory days” was the opportunity to work with and exchange ideas with such brilliant people in IBM, OTI, and other companies.

VisualAge grew to become an entire family of development environments for several of the IBM “SAA” programming languages. There was even a VisualAge for Cobol! All of the various flavors featured an IDE written in IBM Smalltalk.

Enter Java

When Java “reared it’s head.” IBM, of course came out with VisualAge for Java. Again, the IDE was written in Smalltalk, although, in order to accomodate Java execution, OTI developed what was called the UVM (or Universal Virtual Machine) whcih could execute both Smalltalk and Java byte-codes, and used Smalltalk to implement the Java primitive functions which were implemented in C in the Sun JVM.

IBM eventually switched its focus from Smalltalk to Java. After considerable thought about this, and conversations with those who were in a position to know, I’m now convinced that this had nothing to do with the relative technical merits, and everything to do with a combined IBM/Sun platform play against Microsoft.

VisualAge for Java did eventually move away from the UVM for Java execution, primarily because the Java language had evolved to provide a standard C api for extensions. OTI began implementation of a new JVM, which was dubbed J9, which was built from the ground up to be usable in embedded systems.

OTI had a reputation of fostering the use of Smalltalk in embedded systems. When I first became aware of them in the early OOPSLA days, they were showing off products like an HP Network Analyser, and a TekTronix Digital Oscilloscope which used Smalltalk to implement their user interfaces. They were also involved with a large semiconductor company in Texas which was planning to use Smalltalk in controllers in an automated IC fabrication facility.

Around the time of the birth of J9, IBM was becoming quite interested in embedded software, under an initiative called Pervasive Computing (PVC). Because of this, OTI now an IBM Subsidiary, started working on VisualAge Micro Edition, which bundled J9 with an cross-platform IDE written, this time, in Java. About this time, I moved from IBM to OTI, and ended up working on the VAME IDE.

The Emergence of Eclipse

Work on VAME was distributed between various OTI labs. The lab in Phoenix acted as the liaison with the IBM PVC folks, the J9 VM work was done in Ottawa, Raleigh did some applications work, and some UI work, but the bulk of the VAME UI framework was done by Erich Gamma’s team at OTI Zurich. The IDE used Swing, as most Java desktop apps did in those days, and apparently that was a bit of a struggle. OTI used to have an annual all-hands internal developer conference in sunny early February Quebec, and I’ll never forget Erich, who is quite the Alpine skier, talking about the UI while showing a slide he took at some ski report showing a sign with a precariously oscillating chair-lift and a skier about to fall, with the text “Don’t Swing!”

This led to the desire to develop a new UI framework and what is now known as the standard widget set or SWT.

And the overall IDE/UI framework which replaced VAME was, of course Eclipse.

And now it seems we’ve gone from a Smalltalk IDE hosting Java development to the reverse!

Where Are They Now

Digitalk eventually merged with ParcPlace to form ParcPlace-Digitalk. For a while, both Smalltalk/V and VisualWorks/Objectworks (the ParcPlace Smalltalk-80 products) were carried, but eventually VisualWorks survived. It’s now shepherded by Cincom, which bought the rights.

Similarly, IBM eventually sold the rights to market and develop VisualAge Smalltalk (a.k.a. VAST) to Instantiations. My old friend and colleague from IBM John O’Keefe “retired” from IBM to lead the development team.

Several of the X3J20 guys went to or through Microsoft. George Bosworth worked for several years on a precursor to today’s Microsoft DLR. Davd Simmons and Allen Wirfs-Brock both work on Javascript for Microsoft.

And, of interest to the Ruby community, Gemstone is now working on Maglev, a Ruby implementation with persistent objects based on their mature Smalltalk product.

What Would You Miss If You Had To Stop Using Ruby and Go Back to Smalltalk?

Rick DeNatale — Wed, 21 May 2008 16:58:00 -0400

Last night, James Robertson from Cincom, presented Smalltalk and Seaside to the Raleigh Ruby Brigade.

It was an interesting deja-vu experience, since in my younger days, part of my job with IBM was evangelizing Smalltalk, much as James does today. It was interesting to see what has and hasn’t changed. For the most part the things about Smalltalk which were blessings and curses (or many times both) haven’t changed. The IDE is still powerful. It gets much of it’s power from Smalltalk’s model of how source code and run-time implementation objects like compiled-methods, classes and metaclasses interact, but the consequence is that there aren’t really Smalltalk source files to use with popular editors like VIM or EMACS or Textmate. The question came up about whether the Smalltalk IDE supported the notion of giving the code to an external editor, and the answer was that the size of a typical Smalltalk method, which is the unit of editing, was so small (10 lines is a long Smalltalk method) as to make it ‘moot.’ I used to get the same kind of questions and give pretty much the same answers.

One area where Smalltalk really does excel is in it’s debugging and inspection tools. The same implementation object model which enables browser features, like finding all senders or implementers of a message using structural rather than textual searching, also allows live debugging, where you can not only inspect the run-time state at a breakpoint, or when an exception occurs, but actually make changes to the running code, and compile those changes, at which point the VM prunes the invocation stack down to the point of the change and allows you to restart from that point. Protestations from TDD/BDD adherents that you don’t need no steenking debugger if you follow TDD practice, the Smalltalk debugger was tool much favored by the very people, like Kent Beck, who invented TDD. Many Rubyists who were around for more than a year or two had an anti-debugger attitude, generated more, I suspect, by the lack of a decent Ruby debugger than any real hatred of debuggers.

Now that ruby-debug has been around for almost two years, the situation is much better. Ruby has a fairly competent debugger which allows stepping through code. It’s still hampered by Ruby’s rather simple run-time meta information, being forced to work on a line-by-line mode, rather than being able to step through individual expressions as can the Smalltalk debugger. And we’re still a long way from the live surgery capabilities I described. Perhaps as Ruby VM implementations mature we might see some of these advanced features emerge, perhaps this is something which the Rubinius implementers might also take as an inspiration from Smalltalk. This is one of the main things I miss from my Smalltalk days.

On the other hand, at this point in time, I’m really much happier working in Ruby than I think I would be were I somehow forced to work in Smalltalk again instead. Much as I love it, Smalltalk is now my second favorite language.

At one point last night, Brian Adkins asked me the question which is the title of this article. I think it’s a fair question, and I’m not sure I know exactly, but let me try to answer it.

What I’d miss from Ruby

I’ve said this before, but one of the things I like about Ruby is that it is more dynamic than Smalltalk in ways which I like, and cuts back on other aspects of Smalltalk which I don’t think are really that important.

One of the things I like about Ruby is the elimination of variable declarations. A good example of this was that during the Seaside demo last night, James showed how interfacing to the database requires attribute instance variables in model objects to be declared. Now the IDE provides tools for helping with this, you get prompted with a list of column names and can add them one by one just by clicking buttons. Contrast this with ActiveRecord where model objects just acquire instance variables dynamically at run-time. Now I know that some prefer more explicit mappings, but personally I feel that the dynamic mapping provides much more capability for much less ceremony.

The ways in which Ruby is more dynamic than Smalltalk seem to me to provide better facilities for building low-ceremony architectures and artifacts like Rails, Rake, etc. There are more dynamic languages than Ruby to be sure, such as Self, and from what I can sense JavaScript, but Ruby seems to strike a very nice balance.

Much has been made of the legacy of Smalltalk in pioneering metaprogramming, although some Lisp guys might quibble with that, and in truth, most Smalltalk metaprogramming was only used to support the IDE and never put to use by application programmers. Alan Kay used to say that he was disappointed that no one seemed to make new classes of Behavior (which is the superclass of both Class and Metaclass in Smalltalk). I know he said this to some of us at an IBM internal conference, which at least led to Dave Smith and Jerry Archbald developing a “behavior of behavior” tutorial which ran for several years at OOPSLA. But Rubyists have taken metaprogramming much further than I recall from my Smalltalk days.

On the other end of the scale, Smalltalk as James pointed out, as I used to, has a very simple syntax, a few reserved words (self, super, nil, true, and false), three types of messages (unary, binary, and keyword), two operators (:= for assignment, and ^ for return), and a few more things for defining block literals.

Now when I was doing James’ job, this got mixed reactions. Some people took to syntax like:

topLeft = Point x: 3+2*5 y: 15

While others found it just a little too strange, something which we Smalltalkers just couldn’t get.

Another thing which put off newcomers to Smalltalk was that, because of the simplicity of the language, and the lack of any form of operator precedence (remember the only operators are := and ^), that subexpression 3+2*5 evaluates to 25 and not 13.

Ruby trades off a little simplicity and does provide precedence between messages which seem like they should act as operators.

I’m not saying that Ruby is without quirks, just that different people react to different quirks in different ways. If you don’t like what you perceive to be the quirks of any programming language, you won’t be convinced, even by the most ardent supporter of those quirks.

One of the interesting effects of the Smalltalk syntax was that, as we observed back in Smalltalk’s heyday in the Enterprise (late ‘80s-early ‘90s), it seemed that a lot of COBOL programmers seemed to take to Smalltalk. We used to think that Smalltalk might actually become the 21st century COBOL, until the “Enterprise” got wooed away by EJBs and the like. The same things which made Smalltalk approachable by COBOL programmers made it seem weird to those who looked down on those COBOL programmers as “trade-school” programmers.

Another much-touted feature of Smalltalk, is that everything is done by message sending, even control flow. In Smalltalk a if/then/else control flow is achieved by sending an ifTrue:ifFalse: message to a boolean object as in:

 ^(x = 0) ifTrue:[a] ifFalse:[b]

Smalltalk evaluates this as if the the expression (x = 0) is evaluated by sending the message with the selector = and argument 0, to the object referenced by x. The result of that message, an object of course, is then sent the message with the selector ifTrue:ifFalse: and the arguments [a] and [b], which are two blocks. What happens is up to that object. Typically that object is either true (the sole instance of the class True) whose ifTrue:ifFalse: method evaluates the first argument, or false (the sole instance of the class False) whose ifTrue:ifFalse: method evaluates the second argument. Very neat and conceptually clean. It allows you to define your own control flow methods.

Ruby on the other hand compiles if statements and their kind as tests and branches, much as a C compiler would. We trade off a little flexibility for performance.

But, in my experience, that flexibility rarely got used in Smalltalk. Not only that but, in my day at least, the Smalltalk compilers would also compile ifTrue:ifFalse: to a test of the result of the ‘receiver’ and a branch. In fact I just tried defining a FakeBoolean class with an ifTrue: method and when I try to use it I see this:

That NonBooleanReceiver exception is like seeing the Wizard of Oz behind the curtain, this notion of no control flow, just messages is actually a bit of an illusion.

Again, while Ruby doesn’t even pretend to implement all control flow by messaging, it provides most of what the underlying Smalltalk mechanisms are really used for in the form of blocks used to implement iterators.

There are other aspects of Smalltalk which are both blessings and curses. The fact that Smalltalk has a persistent run-time image, containing all the development tools, which can be saved along with its state of execution, and restarted is quite powerful, alien to many programmers, and can drastically change your approach to deployment. Back when I was doing Smalltalk we always struggled with issues like the footprint of the image, how to strip out the development tools before deployment, and start-up time. Some of these problems might seem to be less severe with today’s hardware, but they are still issues.

I feel that I might be coming across a little too harshly on my old friend Smalltalk. It still provides a great programming environment, and serves as a source of inspiration which shouldn’t be overlooked, and I hope to see some of the powerful development tool features from Smalltalk appear with help from support in some of the emerging Ruby implementations. I’m glad to see that it seems to be making somewhat of a resurgence, along with dynamic languages in general. But for me right now, while I wouldn’t be unhappy if I had to go back to Smalltalk, but I feel happier with Ruby.

Best Practice Patterns, Accessors and Encapsulation

Rick DeNatale — Fri, 15 Feb 2008 08:29:00 -0500

One of the classics in the Smalltalk literature, which has also had a big influence on the Ruby community is Kent Beck’s “Smalltalk Best Practice Patterns”, which captures the best practices for designing and coding Smalltalk programs. Back when it was published, I used to see Kent a few times a year, and happened to be in the Bay area when he made an author appearance at the Computer Literacy Bookstore in San Jose, where I got my copy, and the autograph shown here.

The Ruby language has many similarities with Smalltalk, so much of Kent’s advice applies to Ruby. I frequently hear prominent Rubyists mention the book.

On the other hand, Ruby is not exactly Smalltalk, so Kent’s book isn’t an exact fit to Ruby. I’ve been wanting to start writing about adapting some of these patterns to Ruby for a while, so this article will hopefully be the first in a series.

The Motivation For This Article

Recently on the ruby-talk forum a thread discussing accessor methods vs. direct instance variable access came up. This was a hot debate topic in the Smalltalk community back in the 90s, and Kent addressed it in two competing patterns in the book, one of which Ryan Davis (a.k.a ZenSpider) brought up in the conversation.

Patterns Are Decisions, Not Prescriptions.

In their best form, patterns represent a network of decisions made during the creation of something, in this case software. A good pattern should describe the forces which affect the decision whether or not to adopt the particular solution it offers.

There can often be a tension between competing patterns, different patterns optimize different desirable characteristics, such as readability vs. flexibility.

The forces, or their relative strength, can be affected by technical factors such as the language, and features of the editor or IDE being used. To varying degrees many or all of Kent’s Smalltalk patterns have forces affected by the capabilities of the Smalltalk IDE. One of Kent’s main goals is readable code, so writing code to maximize the utility of the code exploration features of the Smalltalk browsers, inspectors, and debugger figures into the book.

A Tale of Two Patterns

Now to the specifics of the article at hand. The book has two patterns described in sequence,starting on page 89, “Direct Variable Access”, and “Indirect Variable Access”. Both address the same problem “How do you get and set an instance variable’s value?” and give two opposing solutions, along with a good discussion of the tensions.

The first pattern, as the name implies, advocates referring to an instance variable directly by name, so in Ruby, within a method, you’d just write @x, instead of using accessor methods, the second pattern.

As Kent points out in the discussion of the first pattern, direct vs. indirect access was a hotly debated topic in the Smalltalk community, although indirect access got to be popular since it was advocated by several Smalltalk training companies.

Tension Number One: Readability

In his argument for direct variable access, Kent explains that whenever he ran into an accessor method invocation, which in Smalltalk looks like this:

a = self x

He found himself pausing to remind himself that x was “just” accessing an instance variable, but that he would read the direct form:

a = x

without breaking his stride.

I might point out that Ruby is subtly different here. First, direct instance variable access is clearly marked with the ”@” sigil. On the other hand, a read accessor invocation in Ruby can be written without the explicit self receiver:

a = x

So it’s not as clear that this is a method invocation as opposed to a local variable access, although we know that it isn’t a direct instance variable access. Write accessor invocation usually requires an explicit receiver:

self.x = a

to disambiguate between a write accessor call and simply assigning to a local variable, at least the first time x appears in a particular lexical scope.

Tension Number Two: Subclassablity

Although direct instance variable is more readable, it does have a drawback in that it makes certain subclassing patterns harder to implement.

If a class uses indirect variable access consistently, then a subclass can leverage this by overriding the accessor. For example, lets say we want a subclass which audits changes to an instance variable. By overriding the setter accessor it can do things like logging changes very simply. Otherwise any methods which access the instance variable in the superclass need to be overridden.

Kent’s example is defining a PolarPoint subclass of Point which has radius and theta instance variables, and overrides Point’s accessors for x and y. One interesting aspect of the Ruby/Smalltalk comparison when you look at this example a little more deeply relates to my recent article about instance variables. In Smalltalk since the Point class has x and y instance variables, it’s subclass PolarPoint would have x, y, radius and theta instance variables, although the x and y variables would be vestigial and unused. In Ruby a PolarPoint instance wouldn’t acquire the unneeded x and y instance variables.

The Encapsulation Tension

One of the reasons why there was/is such a debate between proponents of direct vs. indirect instance variable access is the effect providing setter and getter accessors has on the apparent encapsulation of the object’s state.

First, in either Ruby or Smalltalk, the mere absence of accessor methods doesn’t prevent encapsulation intrusions. Ruby has the instance_variable_get and instance_variable_set methods, and Smalltalk has instVarAt: and instVarAt:put:, but these methods are ‘marked’ as slightly evil and reserved for dastardly deeds.

An accessor method on the other hand seems much more like any other normal method. In Smalltalk, convention is used to mark methods as private, although this is very weak consisting simply of putting private methods in a particular category in the browser, with no runtime check. Ruby does provide runtime checking of both private and protected methods, although even this protection can be circumvented, using send.

Summing Up

So in the end, the existence of and the tension between these two patterns demonstrates some key points:

Patterns present choices, and the best patterns provide enough information to make an informed decision on a case-by-case basis.
The languages and the tools we use have an effect on the patterns and the decisions they engender.

Whose Variable Is It Anyway?

Rick DeNatale — Fri, 08 Feb 2008 16:14:00 -0500

The more I think about Ruby in relation to other object programming languages I’ve worked with, the more I realize that there’s a continuum of static vs. dynamic typing.

Ruby fits close to one end of that continuum. Understanding this can help understand how to best use the language. I recently had a quick look at Russ Olsen’s new book Design Patterns in Ruby and looked at his section on the observer pattern. I’d just posted to ruby-talk about this pattern, how it was implemented in Smalltalk, and a more Rubyish implementation. I’ll get to that at the end of this article, but first I really feel the urge to talk about instance variables.

If we view a type as a particular interpretation of a memory layout, I see something like this

Language	Outside	inside
Java	static	static
Smalltalk	encapsulated	static
Ruby	encapsulated	dynamic

The two columns represent how the object’s innards “look” from outside the object, and inside the object (i.e. inside a method) respectively.

In Java, subject to access modifiers, instance variables, a.k.a. fields, can be directly accessed. No accessor method is required. In Smalltalk and Ruby, instance variables of an object are only accessible while executing one of the object’s methods. Although both languages provide a bypass mechanism, instance_variable_get and instance_variable_set for Ruby; instVarAt: and instVarAt:put: for Smalltalk, these are both methods, and are to be used only in “emergencies” since they break the encapsulation of the object.

Static Instance Variable Binding

By static here, I mean that the code which accesses the instance variable uses information which is statically bound by the compiler. This is a subtlety which misses a lot of today’s programmers who don’t understand what a compiler does, which is to take the textual, human written and readable source code and turn it into bits and bytes which can be executed by some form of computer. The older wiser guys might just want to skim this section.

That computer might be a real computer, like an Intel processor, or a virtual computer in the form of a software implemented virtual machine or interpreter. In the case of a real or virtual machine, there is an instruction set which gives the repertoire of the machine. The program is executed by moving step by step, instruction by instruction. Now, if we have a simple C statement like:

int a = b

Then the instruction sequence for an imaginary computer might be something like:

    load  reg2, 20(reg1)
    store reg2, 40(reg1)

Which loads the second machine register from a word which is at an address 20 bytes after the address contained in machine register 1, and then stores that value into another word offset 40 bytes from register 1. Here a and b are intended to be local temporary variables, and I’ve decided that my compiler is using register 1 to point to the current activation stack frame. Those magic numbers, 20 and 40 are computed by the compiler as part of it’s function to map variables to memory locations.

The idea that instructions might be different lengths is quite common in instruction set design. Usually some number of bits at the beginning of the instruction is used to encode an ‘op code’ like load or store, add, or subtract, etc. Other bits are used to determine the presence and format of parameters for the operation. Different instruction sets have different addressing modes, which allow memory to be addressed in various ways, such as the mode used above which addresses memory as an offset from a location held in a register. Other addressing modes might add another register used to index elements in an array, for example. Most real instruction sets have some unit of length for instructions, so for a given machine architecture, all instructions might be one or more words, or one or more bytes.

Bytecodes Are An Instruction Set Format

The term “bytecode” is simply a particular form of an instruction set, or rather a family of forms. Most people associate the term with Java, and a particular instruction set, although the term predates Java, being used by Smalltalk and probably before. It really means that the ‘machine code’ instructions are represented as a series of bytes. Many instructions are encoded by a single byte, although some require additional bytes in order to form a complete instruction. The general term bytecode simply means that the length unit for the instruction set is one byte.

Although Java and Smalltalk implementations typically use bytecode instruction sets for their virtual machines, the actual set of bytecodes differs, much as the instruction set for an Intel Core Duo 2, differs from the instruction set for a PowerPC G4.

Classical Instance Variable Binding, Smalltalk Style

Now lets look at similar code in Smalltalk. In this article, I’m using the bytecodes defined by the out of print, “Smalltalk:The Language and Its Implementation”, a.k.a. “The Blue Book”, other Smalltalk implementations might be slightly different.

Let’s say that a and b here are instance variables. The Smalltalk bytecodes

    a := b

Would look something like:

    push_iv_4            # push instance-variable #4 
                             # onto the stack
    store_and_pop_iv_6   # store the top of the stack in
                             # instance-variable #6

In Smalltalk, those magic index numbers used to access instance variables are determined when the class definition is saved. In this case b turned out to be the 4th instance variable, and a the 6th. Smalltalk bytecodes are optimized for small objects, the first 16 instance variables can all be pushed or popped with a single-byte instruction, if an object has more than 16 instance variables then those beyond the 16th need to be accessed via an extended push or store instruction, which allows up to 64 instance variables to be accessed.

In Smalltalk, although instance variables aren’t typed, they are declared in a class definition message executed when the class definition is saved. Any time a class definition is saved, the indices for the instance variables of that class, and of any subclasses are (re)computed, and any methods in the class and it’s subclasses are re-compiled to adjust the offsets. The instance variables defined in the topmost class get the first n offsets, each immediate subclasses instance variables get sequential offsets starting with the next available, and so forth.

This is why I said above that inside a Smalltalk object, i.e. within it’s methods, the object is mapped statically. Changing the instance variable definitions requires re-compilation to avoid ‘type-errors’ in the methods.

Note that those ‘emergency-only’ methods instvarAt: and instVarAt:put: map to the push_iv and store_and_pop_iv bytecodes, the first argument to both is the instance variable index. This also means that they need to be used with care, since you need to know the offset of the instance variable. Now, at least Smalltalk can tell you if you try to access a non-existant instance variable slot but it can’t tell that you’re accessing the wrong slot.

Java Field Binding

In Java, offsets are not compiled directly into the bytecodes, there’s a level of indirection. Peter Haggar, with whom I used to work at IBM wrote an article on Java bytecodes on developerworks. I hope he won’t mind if I borrow one of his examples. Here’s a simple accessor method

public String employeeName()
{
    return name;
}

And the resultant bytecodes. (The 0, 1, and 4 are offsets from the beginning of the method)

    Method java.lang.String employeeName()
    0 aload_0
    1 getfield #5 <Field java.lang.String name>
    4 areturn

What this code does first is to push a reference to the current object, this, onto the stack. Then the getfield instruction uses it’s operand to replace the top two items on the stack with the value of the field. So these two byte-codes (actually 3 bytes in total) are roughly equivalent to the Smalltalk push_iv bytecode, but for two differences:

The Smalltalk push_iv opcode implicitly uses the receiver of the current method, whereas the getfield opcode needs another argument referencing the object whose instance variable is being accessed.
In Smalltalk the argument identifying the variable is an integer index, but in Java the argument is actually a reference to a field descriptor associated with the class of the object whose instance variable is being referenced.

The first difference is because in Java, unlike in Smalltalk, you can directly get and set public fields outside of of the objects methods, so since the object in question isn’t implied, it has to be specified.

The second difference is to allow for separate compilation. The actual Java VM specification doesn’t dictate how fields are mapped within objects, but the abstraction is to allow this mapping to be adjusted at the time classes are loaded. If a subclass is compiled separately from it’s superclass, it might get a new starting position for it’s fields everytime it’s loaded if one or it’s superclasses has added or removed fields.

So in order to access a Java field, the compiler needs to know the type of the object containing the field. This is true whether we are inside a method or outside.

Instance Variables, The Ruby Way

In Ruby, instance variables aren’t declared, so offsets can’t be assigned statically. Instead, Ruby looks up instance variables dynamically, using the instance variable name rather than an offset. Again this matches the ‘emergency use’ messages, instance_variable_get and instance_variable_set take an instance variable name, complete with the ”@” sigil, where the Smalltalk instVarAt: methods take an integer.

In Ruby 1.8, this lookup is implemented in a fairly straightforward fashion. With a few exceptions, which I won’t take the time to go into here, a Ruby object has a pointer named iv_tbl which points to a hash table which maps the instance variable names to values. In Ruby 1.9, the implementation is a bit more clever, but the effects are the same.

So Whose Variable IS it Anyway?

Which brings us back to the title of this article. In Java and Smalltalk, every instance of a given class has the same set of instance variables, albeit each with it’s own value. The variables come into existence when they are declared, and the class is compiled or the class definition is saved.

One thing I didn’t mention in the discussion of Smalltalk is that, because traditional Smalltalk implementations don’t separate the development environment from the run-time environment, when a class definition changes, besides requiring method recompilation for the class and it’s subclasses, any existing instance variables need to be mutated to either add or remove the changed instance variables. Back when he was working on the language self, which has dynamic resolution of instance variables like Ruby, Dave Ungar used to like to kill various Smalltalk implementations by adding an instance variable to the Object class. The problem is that because we are trying to operate on the running system, the system usually trips over itself during such a change. I tried this a few weeks ago with Squeak, and although it warned me twice that I shouldn’t do that, it did try when I clicked that second “Are you sure” button, and crashed pretty quickly. Ruby does handle this as a matter of course, since instance variables are only added to individual objects when they are needed, and self inside a method really is duck-typed, actually more than duck-typed, since the needed instance variables appear just in time.

So you mentioned the Observer Pattern, What’s All This Have To Do With That

One of the things which got me thinking about this again was a thread on ruby-talk some weeks ago about Ruby garbage collection and some of the things which keep Object from being considered garbage and being collected. The Ruby GC tends to have problems if you use finalization and aren’t really careful about how you define your finalizers.

One of the classic gotcha’s in Smalltalk in this vein is the implementation of Object dependents, a.k.a. the Observer Pattern. Smalltalk provides a mechanism to add dependent objects to any other object which, when it want’s to notify it’s dependents that it has changed, can simply send itself the changed message, which in turn sends each dependent the message update: with the changed object as the argument.

This is the basis of the Model View Controller design in Smalltalk. Views register as dependents on Models, and when a model changes, any Views depending on it can react. This is the genesis of the Observer pattern from the well known gang of four Design Patterns book where Model, and View have been generalized to Subject and Observer respectively.

In Smalltalk the ability to manage a list of dependents and notify them on changes is something that every object can do, but very few objects actually use this capability. In order to avoid having an instance variable in every Smalltalk object to reference a dependents collection which is almost always empty, the default implementation actually keeps a global hash which maps objects with dependents to their dependent collection.

The problem with this default implementation is that once an object gains a dependent, the object and it’s dependent objects are permanently reachable, and therefore ineligible for garbage collection, unless the dependency is explicitly removed. As a result of this, the classes of most objects which actually have dependents reimplement the default methods to refer to the dependents collection via an instance value in the object with dependents. Squeak, for example provides a subclass of object called Model which provides such a GC friendly implementation.

Which brings me to the implementation of the observer pattern in Ruby. In his discussion of this pattern in his book, Russ Olsen provides a module which can be mixed into an object to allow it to have dependents:

module Subject
  def initialize
    @observers = []
  end

  def add_observer(&observer)
    @observers << observer
  end

  def delete_observer(observer)
    @observers.delete(observer)
  end

  def notify_observers
    @observers.each do |observer|
      observer.call(self)
    end
  end  
end

This is a nice Ruby spin on the pattern, in that the Observers can be blocks, or any other object which responds to a call method which takes the Subject as its argument.

Shortly before seeing the book, as a result of that GC thread, I’d written my own variation on this, which let’s any object be a subject, by opening up the Object class:

class Object
    def add_observer(&observer)
      (@observers ||= []) << observer
    end

    def delete_observer(observer)
      observers.delete(observer)
    end

    def notify_observers
      observers.each do |observer|
        observer.call(self)
      end
    end

    private
    def observers
      @observers || []
    end 
end

Because of the fact that Ruby only adds instance variables on the fly as needed, we get the benefit of universal support for objects to be Subjects without requiring an observers instance variable for those objects which don’t. The only cost is the potential namespace collision for the four method names.

Another Use of Dynamic Instance Variables

Recently I wrote an article for InfoQ about James Golick’s resource_controller plugin for Rails which allows you to write Rails controllers for RESTful resources which can automatically adapt for use in different resource nesting contexts. This plugin makes good use of the dynamic nature of Ruby instance variables, automatically defining different instance variables in the controller to correspond to the end resource and each of its parent resources.

Whew!

This has turned out to be a rather long article, which I’ve been meaning to write for some time. I hope that someone finds it useful, or at least interesting.

Alan Kay on the meaning of OOP

Rick DeNatale — Tue, 01 Jan 2008 14:39:00 -0500

I've written before in this blog about how the meaning of the term "object-oriented programming" got hijacked from it's original meaning. For example I go into this in some length in my mini-memoirs.

I recently ran into an interesting site with links to "Classical Computer Science Texts", which in turn led me to this e-mail exchange with Alan Kay on the meaning of OOP from July of 2003.

This exchange gives support, with details, for my description of Kay's concept of what Object-Oriented Programming was supposed to mean.

I'm not against types, but I don't know of any type systems that aren't a complete pain, so I still like dynamic typing.
- Alan Kay

As Kay explains, the key concepts came from biological cell communications modeled as networked "whole computers" and a desire to "get rid of with data"

As for the influence of Simula on Smalltalk's notion of classes and inheritance:

I didn't like the way Simula I or Simula 67 did inheritance (though I thought Nygaard and Dahl were just tremendous thinkers and designers). So I decided to leave out inheritance as a built-in feature until I understood it better. - Alan Kay

And summing it up:

OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them.

I'd argue that you can do this in Ruby as well. I don't know if Ruby was on Kay's radar in mid-2003.

Cool, but Stupid, Things I've Done

Rick DeNatale — Sat, 17 Nov 2007 06:18:00 -0500

One of the things about working with software is that you can pretty much do anything you imagine.

Many of these things can be cool.

And many of them, particularly in retrospect, can be less than brilliant.

Here are two of the more visible cool, but stupid things I've done in the past.

Visual VisualAge

Years ago, my position at IBM gave me the opportunity to visit other companies pushing the envelope in software development. One such visit was to a small company in Santa Barbera, CA called Expertelligence, which at the time produced a version of common lisp for the Macintosh called ExperCommonLisp

There I met an interesting young Frenchman by the name of Jean-Marie Hulot, who showed me a user interface tool written in ExperCommon Lisp.

Sometime later I ran into Jean-Marie again at a meeting with Steve Jobs at NeXT. Steve had hired Jean-Marie. The interface tool had been ported to Objective-C and had become the NeXT interface builder. It lives on to this day as part of the XCode tools for Mac OSX.

I was impressed by what I'd seen, but by then I'd been working with Smalltalk for a while. The visual construction of the UI was cool, but I didn't like the idea of being dumped back into the mundane world of compilers and make. After having seen "Paree" in the form of the Smalltalk development environment, it was hard to imagine staying down on the farm.

So, I thought, why not make something like the interface builder inside the Smalltalk environment, and a quick prototype was born.

For some reason, I dubbed this the "Application Builder" with the idea that the combined UI Builder/IDE was for building more than just UIs.

Well, after I showed the prototype around a bit, I got to show it to Earl Wheeler, who was the IBM executive responsible for IBMs software tools strategy (AD/Cycle). He apparently liked what he saw, and funded a Smalltalk project based on my prototype. This opened the door for the IBM Smalltalk products to come.

Rather than getting intimately involved with the product development group, I stayed in advanced technology research.

When Earl took on Smalltalk, the last thing he seemed to want was to introduce a new language. But, because of the visual UI construction in my prototype, he rationalized "positioning" Smalltalk as a "generator." Perhaps as a result of this, the product team got quite carried away with visual construction and made the project a complete visual programming language, and the product was dubbed VisualAge as a result of a christening contest among the development team.

In retrospect the streass on visual programming wasn't so smart. The resulting programs were hard to understand, debug and maintain. Ken Auer recently observed that it produced a lot of "Smalltalk" programmers who didn't learn Smalltalk.

It also had a marketing effect on Smalltalk. After IBM came out with VisualAge, ParcPlace renamed their ObjectWorks family of products as VisualWorks.

IBM did eventually release IBM Smalltalk, unbundled from the visual programming componentry.

Too Much Transparency Considered Harmful

Sometime later, I had another "cool idea" and led a small development team to turn it into a product. The idea was transparent distributed execution of Smalltalk programs, and the product was the IBM/Smalltalk Distributed feature.

This was, if I may say so, a technical tour-de-force. Completely written in Smalltalk, the feature allowed Smalltalk programs to comprise objects on different networked machines. It was much more transparent that other distributed object technologies like Rubys DRB, Javas RMI, or Corba. Everything worked off of Smalltalks reflection capabilities, there was no IDL. In fact we named it Smalltalk Distributed to distinguish it from HPs Distributed Smalltalk which was 'just' a binding of Smalltalk to CORBA.

And the development environment was fully distributed as well, without too much work on our parts. For example the regular Smalltalk debugger was able to follow execution threads (in Smalltalk threads are called Proessses) from machine to machine and back again. A Smalltalk block containing a return on one machine could be called from a method on another machine, and the distributed stack would unwind just like it would on a single machine. Normal process synchronization techniques would work as well.

The key to making this work was implementing what I called a "logical" process which associated each Smalltalk process with a single local process on each physical machine involved in the logical process. The Debugger worked, because the Smalltalk debugger is, at heart, a process inspector, and by making the logical process mimic a normal process, the debugger was none the wiser.

This was really cool technical stuff, but in reality it turned out to be stupid because making distributed method sends so transparent hides important facts such as that there can be orders of magnitude performance differences between a local and remote send and, probably more importantly, there are failure modes (like network outages) for a remote send which just don't occur for local sends.

So just like cases where a building owner decides that it's prudent to put some obvious visual clue on a large floor-to-ceiling window to keep people from trying to walk through it, sometimes it's better to eschew transparency and make the programmer deal with reality rather than perception.

A Chat with Matz, Classs Variable reversion, and A Mystery Explained

Rick DeNatale — Sat, 03 Nov 2007 02:51:00 -0400

I finally got to meet Matz in person today, and we had a nice little chat.

I was pleased to learn that he follows this blog. My readership might be small, but it's quality readership. One thing I told him was that as much as I love, and still love, Smalltalk, I really do feel that I love Ruby just a little bit more.

We talked a bit about the upcoming stabilization of 1.9, which will be frozen as far as language and standard libary changes for the Christmas 2007 1.9.1 release, at which time transition from development to stable status. He has been backing out some of the differences between 1.8.x and 1.9.0. He told me that he had recently, or was soon to, revert the changes to the scoping of class variables. It appears that class variables will continue to be shared between classes and subclasses.

He also cleared up a technical ruby mystery that's been puzzling me for some time.

About a year ago I wrote about a change in Ruby 1.9 which cleaned up the semantics when modules included by a class are re-included in a subclass. The mystery is that sometime after I wrote the article, in a subsequent revision of 1.9, this got dropped. I never could find out why this happened, so today I took the opportunity to ask Matz in person.

He agreed that the way that it worked temporarily was the right way for it to work, but it got dropped because YARV had difficulties with the change in implementing the super keyword.

We didn't go into further details, but here's my informed speculation on the situation.

When you send a message to a Ruby object, what happens, at least notionally, is that a linked list of (pseudo)objects is searched to find the first one which contains a method with that name in its method hash. Let's call this the method lookup chain. The head of the chain is pointed to by the receiving objects klass field, and is either the singleton class of the object if it has one, or the Class of the object, links in the chain represent modules and classes in the ancestry of the object. If the end of the chain is reached a method_not_found message is generated and searched for beginning again from the beginning of the receiving objects method chain.

Each link is either a class or a pseudo object marked as an "IClass" (for Included Class) whose method hash pointer points to the method hash of the Module it represents. Because module method hashes are shared in this way, changes modules methods will be visible to every class or module which includes the module immediately.

When the 'receiver' is super, the same kind of search occurs as for a send to self, but instead of starting with the receivers method chain, we want to search starting with the link in the chain after the one in which the currently executing method was found.

Smalltalk implementations typically reify methods as CompiledMethod objects which have an instance variable which refers to the class in which the method was defined. So a send to super simply starts the search with the superclass of the currently executing CompiledMethods definition class.

This approach doesn't work for Ruby because Modules can be included in multiple classes or modules, which means that methods defined in Modules can appear in multiple places in multiple method lookup chains.

One way to find the right place to start searching for a method with super as the receiver is to start from the beginning of selfs method lookup chain, search until we find the currently executing method, then start the super search with the next link in the chain. I believe that this is how Ruby works, except for that brief time in the evolution of 1.9.

In Smalltalk you must name the message when you do a send to super. In Ruby you can't. Smalltalk, unlike Ruby, allows you to send a different message than the current one to super. In Smalltalk, the keyword super effectively means "self, but resolve any messages starting with the superclass of the class which defined the currently executing method," while in Ruby it means something like, "the current message, but look for me after where you found the currently executing method." This difference simplifies finding the current method in the chain. We know we're looking for a method with the same name in both the first and second searches. Since each link in the chain has a hash of methods, it's generally faster to do a hash lookup on the name, and in the first stage of the search compare the value returned with the current method.

This two-phase search for super runs into a small snag when a modules method hash appears more than once in a given method lookup chain. The first stage super search can find the wrong place in the chain.

Here's some code similar to that in the earlier article.

module M
  def foo #foo_m
    puts "foo in M1"
    super
  end
end

class C1
  include M
end

class C2 < C1
  def foo #foo_c
    puts "foo in C2"
    super
  end
end 

class C3 < C2
  include M
end

Admittedly this code is contrived, it's specifically crafted to expose the issue in the simplest way, C1, C2, and C3 would probably have other methods which don't need to be shown here.

If every module inclusion in the above code created an IClass then the method chain for instances of C3 Would look like this:

The boxes with names inside represent the class objects, empty orange boxes represent IClass pseudo-objects, the blue box labeled M is the module object, and the blue labels represent the methods.

Okay, now let's say we evaluate the expression:

C3.new.foo

We first search the method chain for a foo method and the first one we find is foo_m in the first IClass, so we invoke it.
We reach the super in foo_m, so we start at the beginning of the method chain to find it which we do in the first IClass, since this is a send to super, we then look for the next mathod named foo, and we find foo_c in class C2, so we invoke it.
We reach the super in foo_c, so we start at the beginning of the method chain to find it which we do in the first IClass, since this is a send to super, we then look for the next mathod named foo, and we find foo_c in class C2, so we invoke that.
We reach the super in foo_c, so we start at the beginning of the method chain to find it which we do in the first IClass, since this is a send to super, we then look for the next mathod named foo, and we find foo_c in class C2, so we invoke that.
Houston, we have a problem!

So, including IClasses for a module more than once can lead to an infinite loop when there's a super, if the two-part re-search is used.

And this is most probably the reason why the code to include a module checks to see if the module is already included and doesn't actually re-include it in this, admittedly rare case.

So late last year, some other mechanism must have been being used to find the start of the super method chain, to allow real module re-inclusion. Perhaps, whenever a method was invoked, a pointer to the Class or IClass where it was found was placed on the execution stack so that it could be found if needed to resolve super, perhaps some other mechanism was used.

Whatever method was used, it was apparently incompatible, or hard to implement efficiently with YARV, so when YARV became a standard part of 1.9, the old module inclusion logic came back.

Oh well, being able to re-include really makes the semantics of Module inclusion clearer, seems a shame, albeit perhaps a rather small one.

To paraphrase Kent Beck...

Rick DeNatale — Sun, 02 Sep 2007 17:35:00 -0400

I’m catching up on my RSS feeds this afternoon, and I just ran across the latest from John Lam. Which exposed an interesting coincidence.

Oh yes, Merlin is the original code-name for our team, which was originally IronPython but has now expanded to include the Dynamic Language Runtime and IronRuby.
- John Lam

The codename for IBM’s original VisualAge project was “Camelot.” Various subcomponents and follow-ons were dubbed with various names from Arthurian legend. For example, there were components with names like “Lancelot” and “Guinivere.”

Sometime after the initial success of VisualAge, it was decided that IBM would actually produce a separate Smalltalk language and IDE packaging, a product which was originally named “IBM Smalltalk” at launch.

But during development IBM Smalltalk had Arthur’s wizard as its namesake. As usual there were tee shirts, and this article starts with a picture I just took of my copy of the IBM Merlin Tee, which my wife still uses as an exercise tee. And in case you can’t read them, the words in the crystal ball read “think BIG/TALK small” a combined reference to IBM, Smalltalk, and I suppose, Teddy Roosevelt. Now old Merlin might look more like a Swami than the wizard of Camelot, but here’s the proof from the front of the shirt:

So to paraphrase my old buddy Kent Beck, I knew that Microsoft was trying to implement Ruby, but I didn’t know it would be called Merlin!