Talk Like A Duck: Tag types

Yegge's At It Again!

Rick DeNatale — Tue, 12 Feb 2008 09:42:00 -0500

Another thought provoking piece from Steve Yegge.

Well, we also know that static types are just metadata. They’re a specialized kind of comment targeted at two kinds of readers: programmers and compilers. Static types tell a story about the computation, presumably to help both reader groups understand the intent of the program. But the static types can be thrown away at runtime, because in the end they’re just stylized comments. They’re like pedigree paperwork: it might make a certain insecure personality type happier about their dog, but the dog certainly doesn’t care. – Steve Yegge

And he’s getting the predictable responses from the static-typing advocates.

One quibble I’ve got with what I’ve just quoted, is that, in many languages, static types aren’t just comments. In the C++ implementations I’ve looked at, for example, the typing is used to generate runtime code which relies on the typing done at compile time. The other day I wrote about instance variable access in Java, Smalltalk and Ruby. In C++ instance variable (field) access is static and based on offsets. If a type error get’s past the compiler, say by a bad pointer manipulation, the run-time code can access a non-existant variable, possibly clobbering something vital.

In fact this “bug” is possible not in spite of static type checking, but because the compiler uses static type checking to affect the code, and “throws away” the information needed at run-time to avoid it.

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.

Perspective on the Static vs. Dynamic Type Debate.

Rick DeNatale — Fri, 29 Jun 2007 08:49:00 -0400

My RSS reader uncovered a thought provoking paper by Chris Smith entitled “What To Know Before Debating Type Systems”. It clears up a lot of the confusion around the differences between static and dynamic type systems.

Much of the debate comes from people with limited exposure to both static and dynamic typing. He observes that:

Many programmers have used very poor statically typed languages.

Many programmers have used dynamically typed languages very poorly.

Many programmers have used very poor statically typed languages. Many programmers have used dynamically typed languages very poorly.

He then points out that although there is a good deal of overlap in the problems which can be solved by the two approaches, they are fundamentally different techniques. According to the paper:

A static type system is a mechanism by which a compiler examines source code and assigns labels (called “types”) to pieces of the syntax, and then uses them to infer something about the program’s behavior. A dynamic type system is a mechanism by which a compiler generates code to keep track of the sort of data (called its “type”) used by the program. The use of the same word “type” in each of these two systems is, of course, not entirely coincidental; yet it is best understood as having a sort of historical or generalized significance. Great confusion results from trying to find a world view in which “type” really means the same thing in both systems. It doesn’t.

Most of the popular languages with static type systems use static types to mechanically prove that a program is type-safe. Programs for which this can be proven are accepted, and others are rejected. The paper shows that for any such type-system there will be correct programs which cannot be proven correct and will be rejected.

Languages with dynamic type systems allow execution of programs without prior proof of ‘innocence.’ However, the presence of meta-information at run-time allows for fast-failure and better context for correction when errors do occur.

The type systems of most popular statically typed languages are rather limited in the properties which can be proven. Not all program bugs can be statically determined. Seemingly easy checks such as arrray index checking are actually quite difficult to express statically, most languages don’t check this statically. As Smith says, “this is an unusually hard problem to solve without making the languages that solve it unusable, but it’s a popular one to work on” as a research topic. Reading this paper has motivated me to learn more about Haskell to explore how easy or hard it is to push the notions of what can be statically checked.

It occurs to me that a language like C++ has a Napoleonic-code where you are ‘guilty until proven innocent’, but once you’ve gotten through the trial, you are free to go where you want and do what you want to do. However this means that if you are guilty of something which the type-system doesn’t discover, like an array bounds violation, your malfeasance might be undetected for some time, and then require sophisticated forensics to debug. In Ruby or Smalltalk, you are ‘innocent until proven guilty,’ but your actions are under a higher level of surveillance by the system.

Smith wraps up by re-framing the static vs. dynamic typing debate:

Static type systems prove properties of code, but it almost appears that Rice’s Theorem means we can’t prove anything of interest with a computer. If true, that would be an ironclad argument against static typing systems. Of course, it’s not true. However, it is very nearly true. What Rice’s Theorem says is that we can’t determine anything. (Often the word “decide” is used; they mean the same thing here.) It didn’t say we can’t prove anything. It’s an important distinction!

What this distinction means is that a static type system is a conservative estimate. If it accepts a program, then we know the program has the properties proven by that type checker. If it fails… then we don’t know anything. Possibly the program doesn’t have that property, or possibly the type checker just doesn’t know how to prove. Furthermore, there is an ironclad mathematical proof that a type checker of any interest at all is always conservative. Building a type checker that doesn’t reject any correct programs isn’t a challenger that may be solved some day; it’s impossible.

That, then, is the trade-off. We get assurance that the program is correct (in the properties checked by this type checker), but in turn we must reject some interesting programs. To continue the pattern, this is the diametric opposite of testing. With testing, we are assured that we’ll never fail a correct program. The trade-off is that for any program with an infinite number of possible inputs (in other words, any interesting program), a test suite may still accept programs that are not correct – even in just those properties that are tested.

He then poses eight questions to ponder when considering where and how to use static or dynamic typing in our programming tasks:

For what interesting properties of programs can we build static type systems?
How close can we bring those type systems to the unattainable ideal of never rejecting a correct program?
How easy can it be made to program in a language with such a static type system?
What is the cost associated with accidentally rejecting a correct computer program?
For what interesting properties of programs can we build test suites via dynamic typing?
How close can we bring those test suites to the unattainable ideal of never accepting a broken program?
How easy can it be made to write and execute test suites for programs?
What is the cost associated with accidentally accepting an incorrect computer program?

Our Kind of Ducks, Odd Ducks, and Trained Ducks

Rick DeNatale — Mon, 30 Apr 2007 16:01:00 -0400

A couple of days ago, someone asked on ruby-talk how to implement a cyclic version of Enumerable#each_cons. In words, he was looking for a method:

class Array
   def each_cycle(size, start=0)
      #insert implementation here
   end
end

# So that this:
%{a b c d e}.each_cycle(2) {|cyc| p cyc}

#would print:
["a", "b"]
["b", "c"]
["c", "d"]
["d", "e"]
["e", "a"]

As usual, several helpful rubyists responded with suggestions, one of which leads me to YADTBE (Yet Another Duck Typing Blog Entry)

Here’s one suggested solution:

module Enumerable
  def each_cycle(window, start=0)
    (start...length+start).each do |i|
      yield((i...i+window).map {|n| self[n % length]})
    end
  end
end

Nice solution, but as soon as I saw it, I saw a problem.

While this will work if the method were defined in the Array class, it doesn’t work in general for Enumerables. Let’s write a Kernel method to try some different Enumerables.

def try(enum)
  puts "Trying this #{enum.class} ==> #{enum.inspect}"
  begin
    enum.each_cycle(2) {|cyc| p cyc}
  rescue => ex
    puts ex
  end
  puts
end

Is it a duck?

Okay, now that we’ve done that, let’s try some enumerables:

try(%w{and a one and a two})

# Results in
Trying this Array ==> ["and", "a", "one", "and", "a", "two"]
["and", "a"]
["a", "one"]
["one", "and"]
["and", "a"]
["a", "two"]
["two", "and"]

So this works if the receiver is an Array.

Not the kind of duck we’re looking for

Ranges are Enumerable, so let’s try one.

try(1..5)
# Results in
Trying this Range ==> 1..5
undefined local variable or method `length' for 1..5:Range

Aye, there’s the rub, the each_cycle method assumes that the receiver implements both a length method, and a [] method.

This is the kind of requirement which leads some “strong ducktypers” to use a respond_to? test. But does that really work?

Odd ducks

Well, Hash implements both of those methods, so it would pass the ‘responds_to?’ test. Lets try one:

try(Hash[*(%w{zero, one, two, three}.zip((0..3).to_a)).flatten])
# Which prints:
Trying this Hash ==> {"two,"=>2, "three"=>3, "one,"=>1, "zero,"=>0}
[nil, nil]
[nil, nil]
[nil, nil]
[nil, nil]

Hmmm, not exactly what we are looking for. So it’s not enough to just be an enum with those two methods. We’ve just exposed another requirement of Enumeration#each_cycle, that the receiver be indexed by integers. We’re getting all nils because all of those nicely generated indices don’t have corresponding values in the hash, and hash is lenient about indices (i.e. keys) which aren’t keys.

So what happens if we try a hash which does have integer keys:

try(Hash[*((1..3).to_a.zip(%w{one, two, three}).flatten)])
#now we get
Trying this Hash ==> {1=>"one,", 2=>"two,", 3=>"three"}
[nil, "one,"]
["one,", "two,"]
["two,", nil]

Now, that sort of works, but it exposes yet another requirement, that the indices of the enum be in the range (0…enum.size).

I dub thee Sir Duck

If we use a slightly different hash:

try(Hash[*((0..3).to_a.zip(%w{zero, one, two, three}).flatten)])
# We get
Trying this Hash ==> {0=>"zero,", 1=>"one,", 2=>"two,", 3=>"three"}
["zero,", "one,"]
["one,", "two,"]
["two,", "three"]
["three", "zero,"]

So for a hash which looks enough like an Array, the code in Enum actually works.

Teaching a range to be our kind of Duck

One final example. Let’s revisit the case of a range. We can easily train the range class, or using a singleton class an individual instance of range how to support the each_cycle method:

class Range
  def length
    (last - first) + (exclude_end? ? 0 : 1)
  end

  def [](i)
    first + i
  end
end

# Now if we try this again:
try(1..5)

# We get:
Trying this Range ==> 1..5
[1, 2]
[2, 3]
[3, 4]
[4, 5]
[5, 1]

Okay Rick, what’s your point?

Although this exercise might seem a little contrived, it points out that in a dynamically ‘typed’ language like Ruby, whether or not a particular object is suitable for a particular use can depend not only on it’s class, or which modules are mixed in, or whether or not it responds to a particular set of messages, but on how it responds to those messages.

Using my metaphor of casting for a role in a play, finding the right actor isn’t just a matter of finding someone who went to a particular acting school, (i.e. has (had) the right class or classes), but it’s a matter of fitting the individual to the requirements. It’s akin to being interviewed for a job, for the employer doing a successful ‘type-check’ is a subtle process, and often leads to a probation period (i.e. testing).

Strong-typing advocates will no doubt see this as a flaw in dynamic systems. I see it as a strength. If you think about it honestly, there are a wide variety of requirements which aren’t expressed in strongly typed language, either because the type system doesn’t choose to express subsets of types, such as positive numbers, prime numbers, even numbers, etc.; or because state-oriented requirements such as an open file, don’t really fit into the notion of a static type.

In my experience, I’ve gotten to the point where I rarely make the kind of errors which are caught by static types, and the flexibility of dynamic languages far outweighs the relatively minor benefit of early static type checking. I’d rather rely on a growing set of test cases to fight bugs.

Hungarian Ducks

Rick DeNatale — Mon, 09 Apr 2007 17:07:00 -0400

It’s interesting how events flow sometimes.

One of my major interests outside of software development is human spaceflight. Today I opened the local paper to the coming events section and discovered that the latest ‘rich cosmonaut’ to buy a trip up to the international space station, was arriving there today, and that his name was Charles Simonyi. As I’m writing this, he has just become the first Hungarian in space, or at least that’s what I heard him say over NASA TV.

Update: Actually that honor went to Bertalan Farkas who flew on Soyuz 36 in May of 1980.

Now that’s a familiar name. So I spent a little time this morning looking at his article on Wikipedia, and following some links. Thereby hangs an interesting tale which relates to duck-typing.

Charles Simonyi

Simonyi was the software architect at the Microsoft Applications Division back in the early days of Excel and Word. Before coming to Microsoft he was at Xerox Parc, at the same time as folks like Alan Kay, Butler Lampson, Robert Metcalfe, and Dan Ingalls. One of his most famous inventions was so-called Hungarian Notation, a way of encoding ‘type’ information into the names of variables. This became very popular among C programmers following the Microsoft programming bibles.

Now I never much cared for Hungarian Notation (which I’ll refer to simply as Hungarian for the rest of this article). As normally practiced it led to variable names which looked like they’d grabbed onto part of the C compiler’s symbol table entry. The variables would look like iX, and iY (for two different integer variables), or something like pudwGorp for a pointer to an unsigned doubleword.

Eventually Hungarian fell out of favor as more and more programmers realized that it didn’t contribute enough to pull its weight in ugly names.

Hungarian Dialects

What I learned today was that this form of Hungarian is actually a corruption of Simonyi’s original Hungarian which, instead of encoding the machine representation of the variable, encodes the intentional use of the variable. The Hungarian which most people saw was that used by the Microsoft Systems Division. Those in the know refer to this as Systems Hungarian to distinguish it from Simonyi’s original notation which is known by insiders as Apps Hungarian.

Here, from Simonyi’s original explanation of Hungarian Notation is how variables (or as he called them quantities) should be named:

Quantities are named by their type possibly followed by a qualifier. A convenient (and legal) punctuation is recommended to separate the type and qualifier part of a name. (In C, we use a capital initial for the qualifier as in rowFirst: row is the type; First is the qualifier.)
Qualifiers distinguish quantities that are of the same type and that exist within the same naming context. Note that contexts may include the whole system, a block, a procedure, or a data structure (for fields), depending on the programming environment. If one of the “standard qualifiers” is applicable, it should be used. Otherwise, the programmer can choose the qualifier. The choice should be simple to make, because the qualifier needs to be unique only within the type and within the scope—a set that is expected to be small in most cases. In rare instances more than one qualifier may appear in a name. Standard qualifiers and their associated semantics are listed below. An example is worthwhile: rowLast is a type row value; that is, the last element in an interval. The definition of Last states that the interval is “closed”; that is, a loop through the interval should include rowLast as its last value.
Simple types are named by short tags that are chosen by the programmer. The recommendation that the tags be small is startling to many programmers. The essential reason for short tags is to make the implementation of rule 4 realistic. Other reasons are listed below.
Names of constructed types should be constructed from the names of the constituent types. A number of standard schemes for constructing pointer, array, and different types exist. Other constructions may be defined as required. For example, the prefix p is used to construct pointers. prowLast is then the name of a particular pointer to a row type value that defines the end of a closed interval. The standard type constructions are also listed below.

State Your Intentions

Note that Simonyi here is really talking about the intentional use of the variable rather than it’s representation as a bag of bits.

While this isn’t really a duck-typing system, it relates in that it describes the usage of a variable in priority to the machine representation. Since the host language here is C, the notation still has to talk about things like pointers, and whether or not the pointer is being used as an array.

So in Apps Hungarian instead of iX, and iY, those variables would likely just be x and y if they were being used for x and y positions, or row and col for spreadsheet coordinates. Other names might be wrx for an x position relative to the window coordinate system, or wrxWidget1 for a particular window relative x coordinate.

And the two dialects are incompatible. As explained by Rick Schaut:

For those of us who have grown accustomed to Simonyi-style HN, the whole “i” means “int” prefix thing is doubly horrible, because the “i” prefix in Simonyi-style HN is commonly understood to be an index into an array. If I put a character into an int, I’m not going to call it iCh. I’m just going to call it ch. To me, an ich is an index to a character in an array of characters.

In comparison to System Hungarian, this seems to be much more useful information than a shorthand encoding of the underlying C datatype.

This schism between the two dialects came about because Simonyi used the word type where a better word such as usage or role would have better represented the idea. Perhaps this came from the fact that Simonyi’s native language was, not surprisingly, Hungarian rather than English. It was actually the technical writers in the Systems Division who created Systems Hungarian by editing earlier documentation of the concept without fully understanding it.

It seems to me that this is the same confusion which confounds so many discussions of duck-typing in dynamic languages.

Schrödinger's Duck

Rick DeNatale — Thu, 21 Sep 2006 11:27:00 -0400

Once again there’s been a recent furore about the meaning of Ducktyping on the ruby-lang mailing list.

A nice young man from Sweden, by the name of Ola Bini, announced “ductator” a ruby-gem which allows type validation of ruby variables. Now I think that Ola is young based on the photo on his blog site, and I know that he’s nice because only nice people inhabit ruby-lang.

The real question is just what kind of a type system ductator represents. I’ve taken a brief look at it and it seems to allow one to describe, via a hash, a list of rules which are applied to a variable’s value at run-time. These rules are things like a list of methods the value must have, a class which the value must be an instance of, or an instance of a subclass of etc.

The Cat is Dead, Long Live the Cat

In 1935 Erwin Schrödinger, proposed his famous thought experiment, in which a cat, a a radioactive atomic nucleus, and a cannister of poison gas rigged ot open if the nucleus decayedare placed in a sealed box. The half-life of the neucleus is such that there is a probability of 1/2 of the nucleus decaying within one hour. Because quantum mechanics states that until a decay is observed, the nucleus really exists as a superposition of decayed and undecayed states, that the cat is both dead and alive until the box is open and the observation is made.

Schrödinger’s experiment is really a dramatized version of a similar thought experiment previously published in a paper co-written by Einstein. Although Einstein intended it as a refutation of the probabilistic nature of quantum mechanics, the stochastic basis of quantum mechanics has held up over the ensuing seven decades, and such paradoxes have held up.

My point here is that, in a sense, the kind of type checker represented by ducktator. It attempts to observe certain aspects of an object, and in so doing, has a good chance of killing the duck.

Besides the questions of what duck-typing is or is not, such a set of checks fails under many common usages in ruby.

False Negatives

Relying on responds_to? fails under commonly used Ruby metaprogramming techniques.

It’s very common these days to use method_missing to provide pseudo-methods, or to create methods on the fly. ActiveRecord and other RubyOnRails componentry makes extensive use of this technique.

The problem is, of course, that an instance of a class which uses these techniques effectively gives an invalid response to responds_to?, or may reply false, until the missing method is invoked, creating the method.

Poking around a bit, I notice that some of the standard library classes, and others liek ActiveRecord, go to some lengths to make responds_to? track with phantom methods implemented via :method_missing, although fixing other reflection methods like :methods and the class method :instance_methods doesn’t seem to be commonly done. While this is good, it can greatly increase the expense of :responds_to?. ActiveRecord::Base, aliases :responds_to? as responds_to_without_attributes? before redefining :responds_to? for this reason.

In the case of Drb::DrbObject, which is used as the proxy object in Distributed Ruby, handling :respond_to? on behalf of a remote object, requires marshalling a :respond_to? message to the remote object, sending the marshalled message, then reading and unmarshalling the reply. This makes sending :respond_to? to a remote object much more expensive.

And irony of ironies, ductator uses :method_missing to supply phantom methods in it’s implementation, without implementing a compensating :respond_to?!

False Positives

Even if one accepts the philosopy posited by ductator, using it can get tricky. For example, one might check to see if an object responds_to?(:each), but exactly what :each does and how it interacts with it’s block argument, depends on the class itself. For example, most enumerables yield a single value to the block in :each, but Hash yields both a key and a value. The block can be written to accomodate this, but it doesn’t have to be. It’s not clear to me how to either express or check the type of such block arguments. I don’t see a mechanism in ductator even to check the arity of a proc, and although this could be added, it’s not really sufficient since it doesn’t express the types required of block arguments.

What’s the Value?

Some folks might find something like ductator to their taste, since it give the impression of making Ruby more like Java or C++. The problem is that in so doing, it makes Ruby less like Ruby. This kind of type checking seems to be an expensive add-on to the real checking which happens during program execution. The fact that everything is an object in ruby means that the really nasty errors in a language like C when you use an integer as a pointer don’t happen. It seems to me that the best that something like ductator can do is to make a more ‘meaningful’ error description when something goes wrong, but doing that correctly is harder than it first appears, and in most cases could be accomplished more efficiently by catching errors with rescue clauses and changing the error reporting, after the fact, which puts the cost of the error on the offender rather than taxing everyone with run-time pre-flight tests.

Wrapping up for now

The French word for “duck” is “canard.”

In computer jargon, the word “canard” means a “mistaken and confused belief”. In my humble opinion, the view of duck typing taken by ducktator and its ilk is in this sense really “canard” typing.

Le canard est mort, vive long le canard!

Or translated into English:

The canard is dead, long live the duck!

Ducks Can Be Subtle Birds

Rick DeNatale — Thu, 10 Aug 2006 11:09:00 -0400

One theory I’ve seen defines a “duck type” as a set of messages which an object bound to a parameter or value needs to understand. This leads some, who want to make type-checking happen a bit earler, to propose testing the values of such variables with oneor more respond_to? tests before using the object “in anger.”

But ducks can be subtle…

Sometimes it’s not enough just to have a certain set of methods in a duck’s repetoire.

Let’s look at an, admittedly cooked-up, example:

def reverse_lookup(value, dictionary)
     (dictionary.collect { |kv| kv[1] == value ? kv[0] : nil }).compact
end

The method is intended to return an array containing keys in a “Dictionary” which map to the given value:

irb(main):001:0> load 'reverse_lookup.rb'
=> true

irb(main):002:0> reverse_lookup(1, { 'a' => 1, 'b' => 2, 'c' => 1})
=> ["a", "c"]

Now, I said that this was a “cooked-up” example to illustrate a point about “ducks.” It would probably be more proper to implement a method like keys_for_value in Hash or a module which could be used to extend Hash or other “dictionary” classes.

The point here is that for this implementation of reverse_lookup, the only message sent to dictionary is collect, soaccording to the “respond_to?” theory any object which has “collect” in it’s repetoire is the right species of duck for the dictionary parameter.

So let’s try another duck:

irb(main):003:0> reverse_lookup(1, [1, 2, 3])
=> [0, 1]

Well, it works in the sense that nothing blows up, but the results look strange, where did that 0 come from?

While you weren’t looking, I snuck a debug parameter into my reverse_lookup method to give an “x-ray” view into what’s happening.

irb(main):004:0> reverse_lookup(1, [1, 2, 3], true)
kv = 1, kv[0]=1, kv[1]=0
kv = 2, kv[0]=0, kv[1]=1
kv = 3, kv[0]=1, kv[1]=1
=> [0, 1]

The reason that it works at all with an array of integers is a bit of an anomally due to the fact that Ruby integers define the [] method as a bit reference. When kv is an integer kv¹ and kv⁰ are respectively the least significant, and second least significant bits in the binary representation of kv.

Now let’s try another array;

irb(main):005:0> reverse_lookup(1, [Array, NilClass])
NoMethodError: undefined method `[]' for NilClass:Class
        from ./reverse_lookup.rb:2:in `reverse_lookup'
        from ./reverse_lookup.rb:2:in `reverse_lookup'
        from (irb):4
        from :0

So this doesn’t work at all.

To sum this up, “duck types” aren’t just collections of messages, whether or not an object will work in any given role also depends on subtleties of the semantics of theimplementation of the corresponding methods, and can also depend on the state of the object as well.

Now this shouldn’t be considered a weakness of “duck typing” compared to “strong typing,” or something in-between the two. Strong-typing systems have similar “flaws” for example strongly typing a variable to an integer won’t protect against division by zerowhcn the variable is used as a divisor, nor will it alone protect against out of bounds errors when it’s used as an array index. The errors which aren’t detected by strong-typing is a much larger set than those which are. In languages which provide limited run-time checking of code which has passed the strong-typing “hurdle” the effects can be disastrous. In my humble opinion, the benefits of dynamic typing far outweigh “unlearning” what has been taught by other languages such as C++ and Java.

Bjarne Stroustrup used to quip, in panel discussions over strong vs. dynamic typing (i.e C++ vs. Smalltalk), that he’d hate to be a passenger on a plane which flashed a light labled “message not understood” in the cockpit when the pilot tried to lower the landing gear. I’d hate even more to be a passenger on a plane whose control software seg-faulted under this condition instead because putting the landing gear down caused a buffer overflow.

The real answer to uncovering and routing out errors is testing, testing, and more testing.

About me

Rick DeNatale — Sat, 29 Jul 2006 09:34:00 -0400

For those who don’t want to read a lot, or dont care too much, here’s the executive summary:

I’m a long time object programmer.
I worked for IBM for 31 years.
I was one of the early adopters/advocates of Smalltalk in IBM.
I’ve done a lot of Smalltalk.
I’ve done a lot of standards work.
I’ve done a lot of Java.
I’m now free of IBM and Java, and I’m learning to love Ruby.

As a result of all of the above I’ve developed lots of strong opinions, weakly held, which I’d like to share.

Now for those with the stamina, some more details on my personal journey…

IBM Research – Smalltalk and ClassC

My early IBM career gave me a lot of experience with developing software. One of the things which struck me was how, despite its name, most software was hard. Hard to develop in the first place, and harder to change to adapt to new requirements.

Like many others, I first became aware of Smalltalk when Byte magazine published a special issue on the langage in 1981. I led a small team at IBM Watson Research which developed a language called ClassC which was inspired by that Byte issue, and added Smalltalk message sending to C, it was similar in concept, but not in syntax to Brad Cox’s Objective-C. We found out about Objective-C after we’d already done our worst. ClassC got some use for internal projects in IBM after I moved to a new IBM development lab in Cary, NC in 1984.

While I was working on ClassC, the late David N. Smith was dealing with the lawyers at IBM Research, Xerox, and UC Berkeley to get Smalltalk-80 into research. Dave and I became good friends, along with other folks in the IBM Research User Interface Institute like Dave’s “sidekick,” the late Jerry Archibald, and John T. Richards, and we formed an OO-Smalltalk cadre within IBM. These three were also key participants in the birth of the ACM OOPSLA conference. Although I personally missed the first OOPSLA, I was a steady participant for the first decade or so, moderating several panel discussions, participating in workshops, and serving on the commitee for OOPSLA ‘93.

One of the advantages of being part of the OOPSLA community was being able to forge friendships and working relationships with many very bright people such as Ward Cunningham, Kent Beck, and all four of the “Gang of Four”

Research to Internal Consultant

After moving to the new lab in Cary, I primarily worked as an inter-divisional consultant, working to drive the requirements of my division, which was writing what was then a new style of applications with graphical direct manipulation user interfaces, into the plans of the Personal Systems division. This got me into a lot of interesting meetings with not only other IBM folks, but also staff from other companies. For example, I was present at the shotgun marriage between IBM Boca Raton, IBM Hursley, and Microsoft which led to OS/2.

My job had given me the opportunity to visit various companies which IBM was investing in, or considering investing in. I got to meet people like Jean-Marie Hulot of Expertelligence whose interface builder implemented in Lisp got re-written in Objective-C to become NeXTStep’s Interface Builder, after he moved to NeXT. A little later, after IBM had made an investment in NeXT, I got to meet Jean-Marie again along with Steve Jobs. I got to argue with Tony Williams and Bill Gates and his team over the merits of their approach to the early design of what became COM, which made the C++ type system a little more dynamic andwith the IBM designers of SOM which tried to make a statically typed systems more resilient to “schema” evolution. Both of these were also (failed) attempts to forge an entente in the “Language wars”

Smalltalk and IBM

With the availability of Digitalk’s SmalltalkV, our little OO cadre started to push for adoption of Smalltalk inside IBM. One of my biggest contributions was to implement a prototype which extended the Smalltalk/V development environment with a direct-manipulation UI and UI Logic (i.e. controller) tool inspired by the Interface builder, which I dubbed Application Builder. When SmalltalkV/PM came out, I ported the Application Builder to it.

The division’s mission had been shifting towards building application development tools, so this prototype fit in. Most of those tools were focused on old big-iron ideas and languages, such as ISPF, and Cobol adapted to personal computers, although targeted for mainframes. I arranged to demonstrate Application Builder to Earl Wheeler, the group executive who oversaw our division and who was in charge of a grand IBM strategy called Systems Application Architecture. Wheeler seemed quite impressed with the App Builder demo and directed us to turn it into a product, and get Smalltalk to be part of SAA, although he wanted it positioned as a “generator” instead of a language for internal IBM political reasons.

I took the point on getting Smalltalk into IBM product plans, while others took the prototype and turned it into what became VisualAge. In my opinion they took the visual programming idea a bit too far, but it did the job of getting Smalltalk out to the world from IBM. And it resulted in IBM Smalltalk, which was implemented by Object Technology International, a company founded by Dave Thomas, although a different Dave Thomas than PragDave. As an aside, what is it about guys named Dave Thomas? Besides OTI-Dave (who is well-known to the Smalltalk community as Big Dave), and PragDave, we have the Dave Thomas from SCTV and Doug of the McKenzie brothers, and the Dave Thomas who founded Wendy’s. Two Canadians, and two Americans.

I also spent a lot of time talking to IBM customers about how object-oriented approaches, and Smalltalk in particular, could help them solve the problems they were having with software being hard.

Smalltalk Distributed

One of my big-idea products was Smalltalk Distributed, a feature for VisualAge/Smalltalk. I led the development on this one.

Distributed applications were the rage at the time. There was another approach to distributing Smalltalk from HP called Distributed Smalltalk, but this was really a Smalltalk implementation of the Object Management Groups CORBA. Although I had been serving as one of the IBM representatives to OMG (as a Smalltalk expert), I didn’t find this idea particularly interesting or appealing. The goal of Smalltalk Distributed was transparent distribution of Smalltalk. Our approach was to implement a distributed implementation of the Smalltalk object model including object storage and garbage collection, message sending, and distributed threads of execution complete with non-local returns. This was all done completely in Smalltalk, using lots of tricks in using metaprogramming much like what the wizard Ruby metaprogrammers do.

This project was technically interesting, and got some use by customers, but it was most valuable as a learning experience. In retrospect, the transparency was both a neat idea, and a problem. Putting a black box around a distrubuted system is probably not as good an idea of putting a distributed system together out of black boxes.

As a result of the Smalltalk Distributed work, I got to spend a month in Sydney Australia, working with Jeff McAffer of OTI, to re-implement some of the ideas such as the distributed threads in a toolkit for building server applications which he called Surfer (or Server) Smalltalk. Jeff subsequently became one of the technical leads of the Eclipse project.

Smalltalk Standardization

Another piece of work I did at IBM was to write a report characterizing the similarities and differences between the various Smalltalk implementations. At that time these were ParcPlace VisualWorks/Smalltalk-80, Digitalk Smalltalk/V, and IBM/Smalltalk (from OTI). By focusing on the externals of the classes and taking inheritance out of the picture, I wrote a report called “Smalltak: A Common Base” which was in effect a rough draft of a reverse-engineered specification for a common Smalltalk language specification.

When the various Smalltalk vendors expressed interest in forging a Smalltalk language standard, X3J20 was formed to develop an ANSI standard, and the common base document became one of the early inputs. I became the secretary of X3J20. The standard was published in January of 1998.

Language Wars – Dynamic vs. Static OO

Of course back in the days before the turn of the century, there was a great debate raging in the “object-oriented” programming community, centered around the value of dynamic languages like Smalltalk vs. static languages like C++.

One of the things which always attracted me to Smalltalk was that it placed encapsulation above all else. As Alan Kay noted in his memoir about the origins of Smalltalk, his original conception of object-oriented programming was that software should be composed of objects which were, in effect, little computers themselves, which encapsulated both data and behavior, and hid the implementation of both from other objects, with objects interacting via sending messages to each other and replying. This uniform object model separates languages like Smalltalk and Ruby from other “object-oriented” languages. The various versions of Smalltalk all shared this model, although they varied as to some of the semantics of message sending and reception.

The idea of classes and inheritance as a way of factoring implementation was actually a rather late addition to Smalltalk. Although Kay acknowledges the Simula language, which also lacked classes and inheritance, as one of the influences on his thinking leading up to Smalltalk, it’s been a popular misconception that the better known Simula-67 was his real influence, when Smalltalk and Simula actually evolved independently.

Kay’s term “object-oriented” got hijacked when Peter Wegner published paper entitled “Dimensions of Object Based Language Design” at the second OOPSLA conference in which he defined “object-oriented” as “objects + classes + inheritance.”

Simula-67 spawned a family of languages which called themselves object-oriented but really used classes and inheritance to create hierarchies of abstract data types. In thes languages which include C++, Oberon, and to a lesser extent, Java became popular bacause they were seen as an easy entree into “object-orientation” to programmers who were more comfortable with the notion of programs manipulating data from “a distance.” This led Alan Kay to observe that

It is unfortunate that much of what is called “object-oriented programming” today is simply old style programming with fancier constructs. Many programs are loaded with “assignment-style” operations now done by more expensive attached procedures.

Because of this morphing of the meaning of object-oriented programming I started to use the term “object programming” instead. In 1991, I wrote an IBM Research Report called “Types From the Client’s Viewpoint,” which very much relates to duck typing and which got cited in a few places. It’s long out of print. So I’ve scanned a hard copy of a draft, to show my thinking at the time.

This debate lives on. It pops up as some of the uneasiness of new Ruby programmers coming from the strong-typing/abstract data type community over thinks like “duck typing.” I plan to explain my thinking about duck typing and other related topics here.

My point here is, I’ve got strong opinions about this topic. While I do believe that the key to wisdom is strong opinions weakly held, I haven’t seen any reason, over twenty-something years to let go of this set of opinions.

Smalltalk to Java

Smalltalk was quite successful with our customers. In some ways it looked like it might become the Cobol of the 21st Century.

Then Java came along. It gave some of the benefits of Smalltalk like languages in a package which was appealing to the C++ community, a lot of who were starting to become jaded over how C++ (if they actually used the compiler to do more than compile normal C programs), seemed to make development harder. It kind of looks like C++, and has a more “regular” syntax than Smalltalk, which some found wierd, although to the Smalltalkers it was beautiful in it’s sparseness and elegance.

And IBM made the jump to Java. Most of us who had been working on Smalltalk were encouraged to start working on Java and Java tools.

About this time, I took an assignment to OTI, which had been acquired by IBM Canada as a wholly owned subsidiary.

OTI itself was making an investment in Java. The first step was to turn the IBM/Smalltalk virtual machine into what was called the UVM or Universal Virtual Machine. This could run both Java and Smalltalk bytecodes. The Java “natives,” the equivalent of extensions in Ruby were written in Smalltalk instead of C. The first VisualAge for Java was written in Smalltalk on this UVM.

Eventually, as Java evolved this approach became less tenable. So OTI started building a new IDE in Java. Our first use for this was for a system to develop embedded Java applications. IBM was getting very interested in embedded software, which they called “Pervasive Computing” and had formed a division called PvC to pursue it. Embedded applications (e.g. code inside an oscilloscope, or a cell phone) written in Smalltalk was an early focus of OTI predating the relationship with IBM. Java, which was actually first developed within Sun for such embedded applications, was a natural language to employ.

The resulting development was called VisualAge/Micro Environment or VAME. The IDE and UI design was done at the OTI Zurich lab by a team led by Erich Gamma of the “Gang of Four.” This code was almost completely reworked and combined with Jeff McAffer’s component run-time architecture to become the basis for Eclipse.

After working on VAME, I moved over to a group working with customers on embedded Java applications. We majored on automotive applications, since there were a lot of car companies and suppliers who were interested in telematics systems with sophisticated software. As a “standards guy” I represented IBM in standards organizations such as the “Vehicle Expert Group” within OSGi

Back to the Mother Ship for a while

By this time, OTI was being gradually assimilated into the Borg of IBM. My group was first. Although we continued to work out of the OTI lab in Raleigh, NC, we now reported to IBM PvC management in Austin Tx.

Then because I was “the standards guy,” I got re-assigned to the PvC architecture department in Austin which was the home of all the PvC standards guys.

Eventually, OTI got “reorganized” (i.e. broken up) with various pieces going to different IBM divisions.

Free at last

After a year or so of this, and 30+ years of IBM, I realized that I was tired of life in a big corporation. Since I was old enough to still have a traditional pension, it was time to see what life was like on the outside, so I retired in the spring of 2005, and I’ve been happily pursuing my own muse, happily learning and working on new projects that I wanted to work on.

I’ve recently discovered Ruby, and as an old Smalltalker, I’m excited to see what looks like the reincarnation of an old friend. I’m starting this blog to see what I can share with the Ruby community based on my experiences.

On Hunting Ducks

Rick DeNatale — Wed, 26 Jul 2006 15:39:00 -0400

Five doctors go duck hunting, they draw lots to determine the order in which they will shoot from the blind.

The Psychiatrist gets the first chance.

A flock of birds fly over. He looks down at his shotgun and says

They look like ducks! They sound like ducks! I wonder how they feel about being ducks?

Meanwhile the birds fly by.

Next up is the internist:

They look like ducks! They sound like ducks! But we can’t rule out the possibility that they might be geese.

Then the general practitioner:

They look like ducks! They sound like ducks! What do you guys think?.

The surgeon takes his place next. He confidently feels the trigger of his shotgun with his highly skilled right forefinger. The next flock flys over.

Bang! Bang!

And the surgeon turns to the pathologist and says:

Check them out and see if they are ducks.

I’ve known this joke for quite a few years, but I’ve never thought about it in relationship to software, until I started playing around with Ruby, and discovered an old friend under a new name, “Duck Typing.”

Last week, I ran across a thread on the ruby forum called “I’ll have the Duck!” which quickly got lots of responses, and seems to have ended up with jokes.

Most of this thread seems to miss the point of duck typing.

Once you’ve really grokked duck-typing you become like that surgeon. Your perception of the properties of objects that really matter changes. And you learn to use the pathologist (testing) as a powerful ally.

Many programers coming to ruby from languages like C++ and Java are like the psychiatrist, internist, and general praticioner in the duck hunting story.

They want certainty in their typing. They’ve developed the expectation that early type-checking by a compiler will keep them from making mistakes.

The problem with this expectation of the power of early type checking is two-fold.

It doesn’t really work
It is overly constraining

It doesn’t work because the bugs caused by type-checking errors is a small subset of buges in general. Besides, in a fully object—oriented language like Ruby or Smalltalk, they are rare (because the methods which actually operates on the data is actually automatically strongly type-bound to the data by virtue of it being a method. It’s overly constraining because it unnecessarily couples the implementations of the provider and users of the services provided by an object.

Rather than droning on about the failures and contraints of early-type checking, which I suspect I’ll address more fully here as time goes on. Allow me to introduce the notion of types in an object-oriented languagethat I’ve come to accept over many years.

Let me suggest that in a fully object-oriented language types are not properties of objects or classes, but properties of variables which code using an object uses to refer to those objects. In saying this I’m recapping the key idea behind an IBM Technical Report I wrote back in 1991 entitled “Types fromthe Client’s Viewpoint” Which is available here as a pdf file.

“But wait a minute!”, you say. “Aren’t types for matching objects with variables, so that programmers won’t make mistakes when they manipulate the object?” To which I reply, “That’s not object-oriented.”

Now of course many will argue with this, but I’d like to revisit the original conception of object-orientation, a term which was coined by Alan Kay, the inventor of Smalltalk, a language from which Ruby has borrowed a lot.

The key idea behind “object-orientation” a la Smalltalk and Ruby is the encapsulation of implementation behind an interface defined by a set of messages. Kay felt that the traditional way of structuring software as programs which processed data, and the attendant separation of program and data was somthing to be avoided. His view is that it isbetter to compose software out of components which all look like little computers, which contain and bind the programs and state together. This was a synthesis of ideas which he had seen over many years, although they had never been codified before he did it.

For an insight into Kay’s thinking, have a look at the article he wrote some years ago about “The Early History of Smalltalk”

Another way of looking at this idea, is that objects should be like little server machines, the exact set of services available and their implementation can vary from server to server, but clients can still use those services in isolation from those details.

In both Ruby and Smalltalk, classes and inheritance are used for implementation sharing, in order to achieve economies in implementing those little computers (objects). This is not an essential feature in Kay’s conception of OO. The original versions of Smalltalk had neither classes nor inheritance which were introduced in later versions.

In parallel with the evolution of Smalltalk, a family of languages based around the concept of Abstract Data Types became an important Computer Science research topic. Abstract Data Types arranged data types into a hierarchy so as to categorize their use as a way to structure more traditional procedural programs, and they called these abstract data types, classes, and the relationship between classes inheritance, so subclassing was simply a synonym for subtyping.

Since, by the time Smalltalk had been made widely known by the publication of a special issue of Byte magazine devoted to Smalltalk-80 in 1981, it had added classes and inheritance, most observers mistakenly thought of classes and inheritance as essential features of the language. One of these was Peter Wegner who wrote an influential paper Dimensions of Object based Language Design which was published in the proceedings of the 1987 OOPSLA conference. In this paper, Wegner defined “object-oriented” languages as those cobining “objects+classes+inheritance.” What he missed was that in Kay’s conception of object-orientation classes and inheritance were merely implementation artifacts, and that the encapsulation of implementation within an object was the big idea which separates object-oriented languages from procedural languages, and despite the similarity in terminology, abstract-data-type languages, which presented instances of those data types as things to be manipulated from the outside, were far from object-oriented, at least as Kay conceived it.

So to wrap this up for now, duck-typing is a natural consequence of the nature of how objects with strongly encapsulated implementations should interact. The notion of objects containing the code which manipulates them, and hiding that implementation behind a wall, through which messages are sent, is a paradigm shift with powerful consequences. Because many so-called “object oriented” languages missed this paradigm shift, many of their users are uaware the power of thinking about software design from this new perspective.

I hope, that in some small way, this blog will help expose the beauty of this paradigm shift.