Talk Like A Duck

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

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

Posted by Rick DeNatale Sat, 03 Nov 2007 06:51:00 GMT

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

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

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

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

Posted in ruby, smalltalk | Tags matz, railsconf, railsconf2007 | 4 comments | no trackbacks

Town Meeting with Matz at RubyConf 2007

Posted by Rick DeNatale Sat, 03 Nov 2007 00:50:00 GMT

Photo by Nathaniel Talbott.

This was not quite the largest audience Matz has faced there were about 500 in attendance at this evening's "Town Hall Meeting", he asid that he had spoken to a group of over 1000 in Japan, but that was not to an exclusively Ruby audience.

I captured most of the questions and answers as best as I could. Any errors of paraphrasing are mine:

Q1

What about backwards compatibility. My program broke when Ruby 1.9 changed File.exists? to File.exist?

A1

We try to keep the language as backwards compatible as possible, but File.exists? was an old method inconsistent with the naming of predicates.

Q2

(From an Engineer from TI looking at putting Ruby into new calculators) I don't like the licence on the regexp library function in 1.8. The regexp engine in 1.9 isn't "encumbered" by the GPL?! When will 1.9 be out.

A2

Ruby 1.9.1 will be out by Christmas 2007, but might not be as stable as we want.

Read more...

Posted in ruby | Tags matz, railsconf, railsconf2007 | 3 comments | no trackbacks

RubyConf 2007 Friday Morning - Jim Weirich

Posted by Rick DeNatale Fri, 02 Nov 2007 13:32:00 GMT

Jim's talk was entitled "Advanced Ruby Class Design"

He started out talking about his own background with various programming languages and how influences from experience with other languages can both help and hamper learning Ruby. He said that while some things from Java/C++ like modularity carry over usefully to Ruby, but, that some very useful Ruby techniques are inconceivable to Java/C++ programmers.

Unlike Wallace Shawn's Vizzini, I'm pretty sure that Jim really does know what that word means.

He gave some examples of this from his "Classics", unfortunately, my note-taking skills are such that I can't capture enough to go into them in detail.

1. From Rake, an example of why the FileList class, which acts like an Array broke because it was initially implemented as a subclass of Array. The fix was to NOT make it a subclass of Array, something which can blow the mind of someone coming from a statically typed OO language.
2. From Builder, which uses "method_missing" to turn Ruby method calls into XML, a problem caused by interference between domain names, like 'class', and core Ruby object methods. The solution was to create a BlankSlate class which undefines most of it's inherited methods (it spares methods like __id__, and __send__). Then he found that he also needed to deal with methods added to Kernel and Object after BlankSlate was loaded. To do this he used method_added_hooks in Kernel and Object so that BlankSlate could remove newly added methods as they were defined. This later changed to use the append_features hook instead to catch methods added to Object or Kernel by module inclusion. Again, this is something which really requires coming from a less dynamic language to "Think outside the box."

He made another foray into "Parsing without Parsing" a Ruby technique for tracking the execution of a Ruby block with method_missing and proxy objects to "parse" the "source" of the block and capture an object graph representation. His motivating example was doing something like Err the Blog's Ambition which generates SQL queries from Ruby blocks. He gave lots of useful Ruby metaprogramming tips, up to and including where Ruby limitations led him to abandon this approach for SQL generation. Because of things like the inability to handle "syntactic sugar" operators like && and || since they aren't implemented as methods, he felt that these restrictions on contents of the block left him short of his goal to express the query in "natural" Ruby.

But the technique itself is quite useful, and finds use in tools like FlexMock and RSpec.

All in all a very thought provoking presentation from Jim. I hope he makes the slides available soon.

Posted in ruby | Tags rubyconf, rubyconf2007 | no comments | no trackbacks

RubyConf 2007 Friday Morning - Jim Weirich

Posted by Rick DeNatale Fri, 02 Nov 2007 13:32:00 GMT

Jim's talk was entitled "Advanced Ruby Class Design"

He started out talking about his own background with various programming languages and how influences from experience with other languages can both help and hamper learning Ruby. He said that while some things from Java/C++ like modularity carry over usefully to Ruby, but, that some very useful Ruby techniques are inconceivable to Java/C++ programmers.

Unlike Wallace Shawn's Vizzini, I'm pretty sure that Jim really does know what that word means.

He gave some examples of this from his "Classics", unfortunately, my note-taking skills are such that I can't capture enough to go into them in detail.

1. From Rake, an example of why the FileList class, which acts like an Array broke because it was initially implemented as a subclass of Array. The fix was to NOT make it a subclass of Array, something which can blow the mind of someone coming from a statically typed OO language.
2. From Builder, which uses "method_missing" to turn Ruby method calls into XML, a problem caused by interference between domain names, like 'class', and core Ruby object methods. The solution was to create a BlankSlate class which undefines most of it's inherited methods (it spares methods like __id__, and __send__). Then he found that he also needed to deal with methods added to Kernel and Object after BlankSlate was loaded. To do this he used method_added_hooks in Kernel and Object so that BlankSlate could remove newly added methods as they were defined. This later changed to use the append_features hook instead to catch methods added to Object or Kernel by module inclusion. Again, this is something which really requires coming from a less dynamic language to "Think outside the box."

He made another foray into "Parsing without Parsing" a Ruby technique for tracking the execution of a Ruby block with method_missing and proxy objects to "parse" the "source" of the block and capture an object graph representation. His motivating example was doing something like Err the Blog's Ambition which generates SQL queries from Ruby blocks. He gave lots of useful Ruby metaprogramming tips, up to and including where Ruby limitations led him to abandon this approach for SQL generation. Because of things like the inability to handle "syntactic sugar" operators like && and || since they aren't implemented as methods, he felt that these restrictions on contents of the block left him short of his goal to express the query in "natural" Ruby.

But the technique itself is quite useful, and finds use in tools like FlexMock and RSpec.

All in all a very thought provoking presentation from Jim. I hope he makes the slides available soon.

Posted in ruby | Tags rubyconf, rubyconf2007 | no comments | no trackbacks

Chicken Typing Isn't Duck Typing

Posted by Rick DeNatale Mon, 22 Oct 2007 14:43:00 GMT

Stress
© David Friel

It seems that he uncovered a conflict between the facet's library and the Ruby standard open_uri library. Open-uri defines a module called Meta which it uses to extend certain StringIo instances. The Meta module adds several methods including one called meta, which returns a hash of meta information. In two places in open_uri, the message "respond_to? :meta" is used to test whether a particular StringIO instance has been extended.

The problem is that Facets also defines a method in either Object or Kernel called meta which provides a clever way to access the singleton class of an object. So the respond_to? in open_uri was getting false positives.

Trans asked "So where lies the fault in this conflict? Are extensions the bad guy, or is respond_to? really not a good oop concept? Or..?"

David Black replied that he thinks "this is just the age-old issue about adding methods to existing classes and hitting conflicts. #respond_to? is relatively dumb; it can't tell you what the method actually does. I think of it as an important tool for "soft" duck typing, in contrast with "hard" duck typing where you just send the object the message. "

Reading this made me realize that a much better name than "soft" duck typing, for using kind_of?/is_a?, respond_to?, or other such "sniff first" techniques, is Chicken Typing

Posted in ruby, best_practices | Tags chickens, ducks | 5 comments | no trackbacks

You Can't Judge a Book... Some Mental Traps in Learning Ruby

Posted by Rick DeNatale Wed, 17 Oct 2007 17:01:00 GMT

Bo Diddley, Hoyer
© Andy Field

a[10]

What's the class of a?

Many beginning, and intermediate, rubyists whould instinctively say Array! The real answer is that given just this code, you don't know.

Recently, on the rails-talk mailing list there was a discussion of this idea from Jamis Buck. Jamis uses alias_method in ActiveRecord::Base so that he can use shortcuts like:

Person[1]

as a shortcut for:

Person.find(1)

This is particularly nice when playing with ActiveRecord in the rails console, but many seem to think that this should be made part of Rails core, and I don't see a real objection.

Now one objection raised by the folks who answer Array to the opening question is that, since ActiveRecord rows can be deleted, Person[2] might fail even though Person[1], and Person[3] work. The reasoning is that the [] makes it "look like an array" and arrays don't act like that.

To me this is a case of judging a book by looking at it's cover. Something which I strongly suggest needs to be resisted in order to achieve ruby mastery.

Let's have a look at a couple of "can't see past the cover" traps in Ruby.

Posted in ruby_for_nubys, ruby, best_practices | 7 comments | no trackbacks

Refactoring With Continuous Testing - a Guided Tour

Posted by Rick DeNatale Thu, 11 Oct 2007 10:47:00 GMT

Refrigerator Censorship
©

So I've taken Frank's code and run it through the re-factoring machine several times. A word to the 'squeamish' because of the use case, there are a few words in the code which some folks, and spam filters might find mildly offensive, but we're all adults here right?

Now I've got to admit that I really came up with the final solution pretty quickly after seeing the blog post, but then I went back and eased up to it for pedagogical purposes. So if you're in the mood, sit down and lets re-factor some ruby!

Posted in ruby, best_practices | Tags autotest, bdd, refactoring, tdd | 8 comments | no trackbacks

Refactoring With Continuous Testing - a Guided Tour

Posted by Rick DeNatale Thu, 11 Oct 2007 10:47:00 GMT

Refrigerator Censorship
©

So I've taken Frank's code and run it through the re-factoring machine several times. A word to the 'squeamish' because of the use case, there are a few words in the code which some folks, and spam filters might find mildly offensive, but we're all adults here right?

Now I've got to admit that I really came up with the final solution pretty quickly after seeing the blog post, but then I went back and eased up to it for pedagogical purposes. So if you're in the mood, sit down and lets re-factor some ruby!

Posted in ruby, best_practices | Tags autotest, bdd, refactoring, tdd | 8 comments | no trackbacks

Ruby Blocks, do or brace?

Posted by Rick DeNatale Tue, 02 Oct 2007 11:04:00 GMT

Red Block
©

Thanks to ruby-talk, I just became aware of Jim Weirich's suggestion to use braces for blocks when the value is being used, and do/end for blocks which are primarily sequences of statements. Jim actually posted this over three years ago, and Joe O'Brien brought it up more recently.

On the whole, I like this idea and will probably adopt it to tune my use of do/end vs. braces.

Posted in ruby, best_practices | Tags rubystyle | 3 comments | no trackbacks