Talk Like A Duck

Yegge's At It Again!

Posted by Rick DeNatale Tue, 12 Feb 2008 14:42:00 GMT

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.

Posted in ruby | Tags statictyping, types | no comments | no trackbacks

Alan Kay on the meaning of OOP

Posted by Rick DeNatale Tue, 01 Jan 2008 19:39:00 GMT

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.

Posted in ruby, smalltalk | Tags alankay, types | 6 comments | no trackbacks

Perspective on the Static vs. Dynamic Type Debate.

Posted by Rick DeNatale Fri, 29 Jun 2007 12:49:00 GMT

1. Many programmers have used very poor statically typed languages.
2. 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:

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

Posted in best_practices | Tags dynamictypes, statictypes, types | no comments | no trackbacks

Our Kind of Ducks, Odd Ducks, and Trained Ducks

Posted by Rick DeNatale Mon, 30 Apr 2007 20:01:00 GMT

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)

Posted in ruby | Tags ducks, types | 3 comments

Hungarian Ducks

Posted by Rick DeNatale Mon, 09 Apr 2007 21:07:00 GMT

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.

Posted in ruby | Tags ducks, types | 2 comments

Schrödinger's Duck

Posted by Rick DeNatale Thu, 21 Sep 2006 15:27:00 GMT

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

Posted in ruby | Tags ducks, types | 4 comments | no trackbacks

Ducks Can Be Subtle Birds

Posted by Rick DeNatale Thu, 10 Aug 2006 15:09:00 GMT

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…

Posted in ruby | Tags ducks, ruby, types | no comments | no trackbacks

About me

Posted by Rick DeNatale Sat, 29 Jul 2006 13:34:00 GMT

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…

Posted in ruby, war_stories, smalltalk | Tags memoirs, oop, smalltalk, types | 7 comments | no trackbacks

On Hunting Ducks

Posted by Rick DeNatale Wed, 26 Jul 2006 19:39:00 GMT

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.”

Posted in ruby, smalltalk, humor | Tags oop, types | 6 comments | no trackbacks