Talk Like A Duck: Tag java

Big Dave on Video

Rick DeNatale — Tue, 29 Apr 2008 22:24:00 -0400

InfoQ recently published a video interview with Dave Thomas (of OTI fame).

In his inimitable style, Dave covers lots of interesting topics in software development, both today and with a historical perspective.

I agree with almost everything he says, and find the rest food for thought.

His comments about Java as a platform are quite germane to the article I published yesterday. If you’ve been exposed to Big Dave before, you’ll enjoy this, and if you haven’t it’s a good introduction.

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.

Where I Come From

Rick DeNatale — Thu, 21 Jun 2007 15:06:00 -0400

Maybe I’ve gotten a bit sensitive of late to the perception some Rubyists seem to have of Smalltalk-bred Rubyists like me. So I thought that I might say a bit more of what I think of the current and future of Ruby as a language. What follows is much longer than what I expected it to be when I started writing it yesterday, I hope that some will find it some combination of interesting, useful, thought-provoking, or at least amusing.

This weeks meeting of the raleigh.rb group was a recap of railsconf 2007. Some of the attendees seemed to have gotten a feeling that Avi Bryant was attacking Ruby in his keynote. I can’t speak for him, and I wasn’t there so this might just be my reaction.
Heard this week on ruby-talk in a discussion of the fact that Module#ancestors doesn’t include a singleton class of the receiver should it have one:
I do not want to argue with the wise guys if it is an error – I clearly thought so but that is not important ;)

But it really would have saved me an hour of debugging if the doc stated clearly that singletons are not included. I thought this might help others and as it took me 20s to vim the missing line into class.c

- Robert Dober
To which I replied:
As far as I can tell, singleton classes aren’t mentioned in the doc. The documentation borders on folklore.

Singletons as a means of implementing both individual instance, and class behavior have a position like “the man behind the curtain” in “The Wizard of OZ.” We’re really supposed to disregard them.

Coming from a background in Smalltalk, my preference would be if this machinery were more visible and official, but Matz has his reasons for not doing so. For one thing, not documenting it, and hiding it from methods like ancestors and class makes it easier to tinker with as the language evolves without “officially” breaking backward compatibility.

Which prompted:
Does that mean that no one who’s ever used Smalltalk can ever think that it’s right for Ruby to deviate from Smalltalk? :-) I ask in a humorous spirit—and also because it gives me an excuse to mention:

http://www.infoq.com/articles/coming-from-ruby

—David A. Black

To answer David’s humorously posed question, No, and I present myself as “exhibit A,” because I certainly think that it’s right for Ruby to deviate from Smalltalk. My main motivations in writing about Ruby in the context of my Smalltalk background are first to help myself, and I hope others, understand Ruby a little better by providing some perspective from another, earlier, dynamic language, and second, to a much lesser extent, to air ideas of how some of the features of Smalltalk might be incorporated or adapted as useful additions to Ruby as it evolves.

In many ways, I like Ruby better than I like Smalltalk. To name a few reasons, Ruby is more dynamic, has a more flexible deployment ‘model,’, and albeit it’s not a technical reason, it’s not carrying the burden of the old business model of trying to get thousands of bucks for each development seat.

This is what really allowed Java to pop Smalltalk’s balloon. Smalltalk was seen by IBM and it’s competitors as “enterprise” technology, and they expected the same kind of prices which other corporate level software development tools commanded. When Java came out and was free “as in beer,” it gained a large popularity with language hobbyists/hackers who could easily get it to play with, and a lot of those guys worked for the companies to which IBM, ParcPlace-Digitalk, and the others were catering.

The other aspect of Java which helped at the time was it’s relationship in syntax, and a lot of its semantics, to C++ at a time when there was a lot of corporate C++ activity and some frustration was starting to be felt with the complexity of C++. Java felt enough like a simplified and friendlier C++ being a language which was more dynamic without “going all the way” and which felt familiar to both C++ advocates and C++ approach to strongly typed class hierarchies, and C++ programmers with symptoms of the Stockholm syndrome. These self-same aspects of Java caused many Smalltalkers to be uneasy with the language.

The real salvation of Smalltalk, as it exists today, was and is Squeak. I remember when I first encountered Squeak, it was at a Birds-of-a-feather session at OOPSLA, right when Java was really starting to get most of the mind-share. My impression was that the atmosphere in the room must have been somewhat like that in the Roman catacombs when the early Christians were hiding out.

I guess that there is still a bit of the old “Enterprise” Smalltalk market, Instantiations, which took over the old IBM/VisualAge Smalltalk base when it fell out of IBMs strategies, sells it for an entry price of $6,995. There must be enough of the old legacy corporate Smalltalk customers around who buy it.

Personally, it’s been quite a while since I was an active Smalltalker, I made an oddyssey through Java-land with IBMs shift in priorities. I plan to write about some of my feelings during that period in retrospection but that’s for a later date.

I haven’t been keeping up with Squeak enough to know how and how much it has evolved the Smalltalk technology and community.

Old Smalltalker’s perceptions of Ruby

I always thought that Smalltalk would beat Java, I just didn’t know that it would be called ‘Ruby’ when it did.

—Kent Beck

I ran across this quote for the first time a few weeks ago. It sounded like something that Kent would say, and also something that I would like to quote myself, but just to make sure, I asked him. He told me that ‘yes’ he had said it in a private communication to someone else, and both he and the original recipient had only recently found out that it was becoming an internet meme. Googling “I always thought that Smalltalk would beat Java” garners over 250 hits.

Kent tells me that he’s a Ruby fan. Ward Cunningham is also.

I asked Ward, just before RailsConf, if he was going since it was in his home-town. He said that he had found out about it after registration was closed, but he was planning to hang out at the hotel anyway. From what I heard last night he was recognized and invited to attend.

Several of my other old Smalltalk buddies, who had also gone through a period with Java, seem to have the same feeling which I do, that looking at and using Ruby feels like being a widower who meets a new woman, who just seems to be a partial reincarnation of the former spouse.

Where You Are Come From Depends On Where You Came From

Getting to David Black’s article. He certainly has a point about letting Ruby be Ruby. As I’ve said, I’m quite happy with Ruby.

Getting back to the early perceptions of Java, and making an analogy with natural languages let me suggest that if we think of Smalltalk as Italian, and C++ as German, Java is Alsatian, and Ruby is French.

Were it not for Squeak, Smalltalk might be Latin instead of Italian.

The most un-Smalltalk like thing about Ruby, to me at least, is the syntax, Smalltalk has almost none, many Smalltalkers say that Ruby has too much. I thought so initially, but now I’d argue that the flexibility and “sugarary” aspects of Rubys syntax are what makes it so successful as a host for internal DSLs like Rake, Rails/ActiveRecord, RSpec, etc. etc. which would be far less natural in Smalltalk with its extremely limited syntax.

One of the complaints I often heard about Smalltalk was it’s ‘different’ syntax just unary, binary, and keyword message send expressions, blocks, parentheses for expression grouping, the use of ’;’ to send a message to the object which got the last one, and single value assignment, and a way to return a value, everything else, including class and method definition, and control flow was built from these atoms.

Ruby probably appeals to a broader audience since it looks enough like something like Java not to be considered too wierd, at least not at first. For one thing in ruby 1 + 2 * 3 is 7, instead of 9 in Smalltalk due to its total lack of operator precedence.

But, syntax differences aside, conceptually both Smalltalk and Ruby are romance languages, as compared to the Teutonic C++ and it’s kinder-gentler relative.

Language Evolution and Cross-Breeding

Programming languages evolve much like natural languages. They pick up influences from other languages and incorporate them with modifications. English is the equivalent of a multi-paradigm language, it has been influenced by the languages spoken by both the conquered and counquerors of English speaking lands. It’s been influenced by Vikings, Normans, and Indians (both the Asian and American meanings of the last). English has a lot of synonym pairs one from French and one from Anglo-Saxon with it’s Germanic roots. Pork and pig; beef and cow; fraternity and brotherhood. This comes from the days after the Norman conquest when the language of the English court was French. Bill Bryson describes this in his book The Mother Tongue””The Mother Tongue”.

Many of the words considered “fancy” by English speakers are of French origin. Kent Beck told me that while he was working in Zurich on a contract with a Swiss bank, he found that an effective way of communicating with the programmers there, was to use simple English grammar, but “fancy” English vocabulary. The latter helped because the Swiss programmers facility with French increased the chances that they would share such word.

Multi-lingualism

There’s an old joke which goes:

What do you call a person who speaks two languages?
Bilingual.

And what do you call someone who speaks only one language?
An American.

Most good programmers, even the Americans, are multi-lingual when it comes to programming languages. As it does with natural languages, this gives a broader perspective.

But multi-lingualism sometimes makes it hard to compartmentalize language concepts. Once on a trip to Zurich, I was having dinner with Erich Gamma, some other Zurich OTIers, and a couple of customers in a very nice restaurant on the Bahnhofstrasse. My facility with German fills a small thimble, but as I perused the large menu, with no obvious English to be seen, I realised that I was reading it rather easily, and thought to myself, “Hmmm, I’m starting to understand German.” Then I realized that the menu was in fact bi-lingual, but the second language was French, a language with which I do have some facility.

I suspect that the “coming from x” quotes in David Black’s article are the result of this difficulty in compartmentalizing by newcomers to Ruby.

A Living Language

Programming languages, like natural languages, survive best when they evolve, this is what distinguishes live languages from dead ones. Languages die as the number of speakers diminish, despite revival attempts like Winnie Ille Pu, Quomodo Invidiosulus Nomine Grinchus Christi Natalem Abrogaverit: How the Grinch Stole Christmas in Latin, Harrius Potter et Philosophi Lapis (Harry Potter and the Philosopher’s Stone, Latin Edition), or the Vicipaedia.

Ruby is evolving, the core-team isn’t asleep, right now ruby1.9 is the cauldron to which new potions are being added to brew what will emerge as the next major Ruby revision.

This is another area where Ruby and Smalltalk have similarities. Smalltalk started as a paper design by Alan Kay to win a hallway bet challenging his assertion that he “could define the ‘most powerful language in the world’ in ‘a page of code’.” Dan Ingalls then actually implemented it in Basic on a NOVA minicomputer, this begat Smalltalk-72, which begat Smalltalk-76, which begat Smalltalk-80. Smalltalk-80 was the basis for the commercial Smalltalks of the pre-Java era, VisualWorks Smalltalk (ParcPlaces commercial Smalltalk-80), Smalltalk/V which merged with VisualWorks when ParcPlace and Digitalk merged, and IBM/VisualAge Smalltalk. Squeak is also a child of Smalltalk-80.

Smalltalk started to freeze when it became commercial. We tried hard to forge a standard in X3J20 which allowed evolution and variation by underspecifying things as much as we could, but broad enterprise acceptance slowed things down quite a bit.

So it’s exciting to see that Ruby is evolving. I hope that it too doesn’t get bogged down in it’s success.

Personal Preferences

Finally getting back to my “Coming from Smalltalk” quote in ruby-talk, I expressed a personal viewpoint that Ruby would be well-served if the mechanisms of singleton classes, and their use as metaclasses were made visible and officially documented parts of the language. If the rationale for not doing so is to preserve “freedom-of-action” in changing the implementation in future versions, I can understand it, but to used a mixed language expression, that is a “two-edged katana.” One of the things which Alan Kay told me a long time ago was that he was disappointed that so few Smalltalkers experimented with changing and extending Smalltalk by building off of the mechanisms of Class, Metaclass, and Behavior. In Ruby, despite the fact that knowledge of the equivalent implementation is only known “sub-rosa,” there is much more such experimentation. Metaprogramming in Ruby is au courant, and lots of code is being written which depends on undocumented “stuff.” I have to ask if this, being undocumented that is, is a good thing.

So, to wrap this all up, while I do “come from Smalltalk,” Today, I live in Ruby!