Talk Like A Duck

Why I Don't Mind Using RSpec - In Fact I've Come to Love It.

Posted by Rick DeNatale Tue, 29 Jan 2008 21:24:00 GMT

About a year ago when I first encountered RSpec, I thought that the idea sounded good, but I was concerned about how much the implementation at that time pushed new methods into Object and Kernel. It felt to me as though it could interfere with the code being specified/tested. Indeed back then there were some problems when RSpec and Rails bumped heads over the use of certain Ruby metaprogramming techniques. I’d been a TDD user advocate for many years, heck I was there right after Kent Beck, “test-infected” Erich Gamma and sat in on some of their early pairing sessions during an annual OTI company technical conference at Montebello in Quebec, when JUnit was in it’s infancy. The cleaner language of RSpec did have it’s attractions, particularly in trying to get across the idea to newcomers that TDD was really writing mini-specifications rather than tests, which helps put them in the right mindset, but for those of us who had already crossed that paradigm shift, or been born on the right side of it, it didn’t seem so important.

Since then the RSpec implementation has matured, and after talking to David Chelimsky and Dave Astels at RubyConf, I decided to give it another look, and, armed with a new perspective on the use of mocks and stubs to isolate specifications and tests in BDD/TDD, I quickly became a convert. I still use other frameworks as external requirements dictate, but RSpec has become my first choice.

These days, though the choice of testing/specification framework seems to have become one of those religious issues which divide the community, almost as much as emacs vs. vim vs. textmate. I run into people all the time who reject RSpec because it’s “too magical!” Although I’ve never been able to get them to expand on that thought. Perhaps it’s based on the kind of concerns I had about it at first, maybe it’s something else. I’d love to have it explained.

And like advocates do, other arguments get expressed, some of which don’t get the scrutiny they deserve.

Alan Kay on the meaning of OOP

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

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.

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