Adding virtual methods to Ruby

During a short conversation on the #ruby-lang IRC channel, someone asked whether Ruby supported C++ pure virtual methods. Out of the box, the answer is no. But the implementation is trivial:

class VirtualMethodCalledError < RuntimeError
  attr :name
  def initialize(name)
    super("Virtual function '#{name}' called")
    @name = name
  end
end

class Module
  def virtual(*methods)
    methods.each do |m|
      define_method(m) {
        raise VirtualMethodCalledError, m
      }
    end
  end
end

The usage is beautifully simple:

class VirtualThingy
  virtual :doThingy
end

class ConcreteThingy < VirtualThingy
  def doThingy
    puts "Doin' my thing!"
  end
end

begin
  VirtualThingy.new.doThingy
rescue VirtualMethodCalledError => e
  raise unless e.name == :doThingy
end
ConcreteThingy.new.doThingy

Please comment!

RubyBeans, a short example of Ruby metaprogramming

As I explained in my recent post about metaprogramming, implementing a JavaBean is a task that would greatly benefit from metaprogramming. Here, I illustrate how this would be done in Ruby. Note that the resulting code has little interest for Ruby as JavaBeans are a Java idiom. I hope however that it demonstrates my purpose. Let’s dive straight into the code:

class RubyBean

  def initialize
    @listeners = []
  end

  def register_listener(l)
    @listeners.push(l) unless @listeners.include?(l)
  end

  def unregister_listener(l)
    @listeners.delete(l)
  end

These methods implement the management of the property change listeners on the bean. It is a subset of what java.beans.PropertyChangeSupport provides. Now comes the most interesting part:

  def RubyBean.property(*properties)
    properties.each { |property|
      class_eval(%Q[
        def #{property}
          @#{property}
        end

        def #{property}=(value)
          old_value = @#{property}
          return if (value == old_value)
          @listeners.each { |listener|
            listener.property_changed(:#{property},
                                     old_value,
                                     value)
          }
          @#{property} = value
        end
      ])
    }
  end
end

I define property as a class method that takes a variable number of arguments. For each of its arguments, property dynamically creates and adds to the RubyBean class, a getter and a setter to the bean. This follows the Ruby conventions for accessors: the getter is simply the property name, the setter is the property name followed by the equal sign. The setter also notifies the registered property change listeners. Note that in Ruby, you would use the attr_accessor method to create these accessors.

Now, writing a bean is as simple as:

class TestBean < RubyBean
  property :name, :firstname
end

Simple, no? Finally, here is how this code could be used:

class LoggingPropertyChangeListener
  def property_changed(property, old_value, new_value)
    print property, " changed from ",
      old_value, " to ",
      new_value, "\n"
  end
end

test = TestBean.new
listener = LoggingPropertyChangeListener.new
test.register_listener(listener)
test.name = "Parker"
test.firstname = "Charlie"
test.firstname = "Maceo"
test.unregister_listener(listener)

and the output it generates:

name changed from nil to Parker
firstname changed from nil to Charlie
firstname changed from Charlie to Maceo

Do not hesitate to comment if you have any query, suggestion, critic or simply if you want to say Hi!

• Update 06/03/2006: see RubyBeans revisited for a better implementation.
• Update 01/05/2007: see RubyBeans revisited (again) – Closures in Ruby for a more elegant solution.

Little Prolog challenge

Another candidate for Paul Bissex’s Let’s play a game: BASIC vs. Ruby vs. Python vs. PHP, this time I implemented the REVERSE game in Prolog. I thought my LISP was a bit rusty when I started my Little LISP challenge. Where does that put my Prolog? Ashes?

I had to peruse the SWI Prolog documentation and google extensively to end up with these lines. I do not know whether this program is portable or not, it was tested on SWI Prolog 5.2.13. I welcome any criticism to improve it.

First a couple of utility functions:

%% choose(List, Elt) - chooses a random element
%% in List and unifies it with Elt.
choose([], []).
choose(List, Elt) :-
        length(List, Length),
        random(0, Length, Index),
        nth0(Index, List, Elt).

%% shuffle(ListIn, ListOut) - randomly shuffles
%% ListIn and unifies it with ListOut
shuffle([], []).
shuffle(List, [Element|Rest]) :-
        choose(List, Element),
        delete(List, Element, NewList),
        shuffle(NewList, Rest).

%% split(List, Index, Front, Back) - splits List
%% at index Index and unifies the first list with
%% Front and the second one with Back
split(List, 0, [], List).
split([Head|Tail], Index, [Head|HeadList], TailList) :-
        NewIndex is Index - 1,
        split(Tail, NewIndex, HeadList, TailList).

Now the game itself:

playgame(N) :-
        numlist(1, N, InitialState),
        shuffle(InitialState, State),
        play(State, Moves),
        format('Done! That took ~d steps.~n', Moves).

play(State, 0) :- sort(State, State).
play(State, Moves) :-
        format('~w~nHow many to swap? ', [State]),
        read(HowMany),
        split(State, HowMany, Front, Back),
        reverse(Front, ReversedFront),
        append(ReversedFront, Back, NewState),
        play(NewState, NewMoves),
        Moves is NewMoves + 1.

I had forgotten how Prolog can be so elegant and how satisfying writing Prolog code can be. I am particularly proud of the clause that checks whether a given state is the goal state, play(State, 0) :- sort(State, State).. Any questions, critics or ideas?

Updated 06/08/06

Markus Triska mailed me a couple of improvements. First of all he points out that choose([], []). is incorrect. I can only agree!
He also offers a far cleaner implementation of the split predicate, using append/3:

split(List, Index, Front, Back) :-
	length(Front, Index),
	append(Front, Back, List).

Finally, he optimizes play by making it tail-recursive:

play(State, M, M) :- sort(State, State).
play(State, M0, M) :-
	format('~w~nHow many to swap? ', [State]),
	read(HowMany),
	split(State, HowMany, Front, Back),
	reverse(Front, ReversedFront),
	append(ReversedFront, Back, NewState),
	succ(M0, M1),
	play(NewState, M1, M).

This requires a slight modification in the playgame predicate:

playgame(N) :-
	numlist(1, N, InitialState),
	shuffle(InitialState, State),
	play(State, 0, Moves),
	format('Done! That took ~d steps.~n', Moves).

Thanks Markus!

Little LISP challenge

Last night, I happened to land on Paul Bissex’s Let’s play a game: BASIC vs. Ruby vs. Python vs. PHP. Obviously this competition has degenerated into a brawl involving a great variety of programming languages including Rebol, Haskell and JavaScript, for example. I decided to set myself a little challenge: come up with a LISP competitor (at the same time, I’ll prove to Jer that I’m not afraid of a pair of parenthesis or two). I quote Paul for the rules of the game:

The game of REVERSE requires you to arrange a list of numbers in numerical order from left to right. To move, you tell the computer how many numbers (counting from the left) to reverse. For example, if the current list is 2 3 4 5 1 6 7 8 9 and you reverse 4, the result will be 5 4 3 2 1 6 7 8 9. Now if you reverse 5, you win.

I came up with two versions. But first, let me introduce two self-explanatory utility functions used in both versions:

(defun shuffle-list (l)
  (loop for i below (length l) do
	(rotatef
	 (elt l i)
	 (elt l (random (length l)))))
  l)

(defun prompt (l)
  (format t "~{~a~^, ~}~%How many to swap? " l)
  (read))

Here is the non-recursive version:

(defun playgame (n)
  (let ((goal (loop for i from 1 to n collect i)))
    (do ((count 0 (1+ count))
	 (state (shuffle-list (copy-list goal))
		(let ((howmany (prompt state)))
		  (append
		   (reverse (subseq state 0 howmany))
		   (subseq state howmany)))))
	((equal state goal)
	 (format t "Done! that took ~d steps.~%"
		 count)))))

and the recursive version:

(defun play (state step)
  (if (equal state (sort (copy-list state) #'<))
      step
      (let ((howmany (prompt state)))
        (play (append
               (reverse (subseq state 0 howmany))
               (subseq state howmany))
              (+ step 1)))))

(defun playgame2 (n)
  (format t \"Done! That took ~d steps.~%\"
          (play (shuffle-list
                 (loop for i from 1 to n collect i)) 0)))

Can you improve on this? Do not hesitate to comment!

Has Dvorak lost it? (part 2) Yes says TWiT 42

On the 17th of february, I asked the question Has Dvorak lost it?. I just realized that the latest TWiT (#42) is entitled Dvorak’s lost it. I sincerely hope the patient improves!

Metaprogramming, Java’s downfall

I have been a Java developer for almost 10 years and I must admit I really enjoy coding in Java. When I first discovered it, I was amazed by its API, the quality of its documentation, its simplicity and most of all its portability. With experience came a better understanding of the Java philosophy and a deeper understanding of Object Oriented concepts. Lately though, I have found Java to be a limiting factor to my productivity. I have identified the main reason behind this: Java lacks metaprogramming. Briefly put,metaprogramming is writing programs that write programs (see metaprogramming on wikipedia).

Here is an illustration of the problem. Everytime I want to write a JavaBean object, I have to make the class serializable, make sure the class has a default constructor, write getters and/or setters for all properties, write methods to register and unregister listeners for the bound properties, etc. It has to be done for every single bean you ever write. Coupled to the fact that unit tests for getters and setters are rarely written, leads to a very error prone process. It is easy to see that there is a definite pattern to this extremely repeatitive task, and obviously there are ways to ease the pain. Code generating tools like xdoclet and eclipse for example, do a decent job in this case. However, these tools suffer because they each use their own templating language and their functionality is usually limited to a C/C++ macro style of behaviour, agnostic of the language itself. By contrast, in a metaprogramming language, this templating and the code it generates are implemented in one language only. It is therefore possible to extend the language itself, by adding new constructs, rather than just develop the object hierarchy.

LISP is probably the quintessential metaprogramming language. LISP’s macros are so powerful that it has been able to adapt and incorporate every new programming paradigm. To my knowledge (and wikipedia’s), LISP (1958) predates all OO languages, as the concept was only being born, and yet CLOS is implemented in LISP itself and supports some features that other OO languages can only dream of (multiple dispatch for example). When AOP came about, it did not take long for LISP to have its own implementation: AspectL.

People usually object that LISP is unreadable. I suppose we will all agree that parentheses, like everything in life, must be used in moderation. But metaprogramming does not have to be implemented in a heavy and unreadable way. In order of increasing readability, I will point you to Io and to Ruby. Ruby uses metaprogramming, for example, to define accessors. But Ruby’s killer-app, Rails pushes this usage even further to provide a DSL for web development. See for yourself, I doubt you will find that Rails’s productivity claims are exaggerated.

For more information on metaprogramming and DSLs, I would recommend listening to the latest Rails podcast with Glenn Vanderburg and to check out Glenn’s blog, starting by this post. I also found Jose Antonio Ortega Ruiz’s blog, programmings musings to be a goldmine, see particularly: this post and follow the link to this good introduction to metaprogramming.

Has Dvorak lost it? or is it a case of “any publicity is good publicity”

Dvorak has dropped the bomb in a PCMag article entitled “Will Apple adopt Windows?“. Dvorak does not actually answer the question, he speculates on an idea expressed by one of his friends, Yapov Epstein. Dvorak is convinced he [Yapov Epstein] may be right. The combination of “convinced” and “may be right” does not presage for great journalism.

Dvorak’s first symptom of this upcoming switch to Redmond’s OS is that Apple’s switching ads did not work, and that nobody switched. This argument falls appart when looking at Apple reports for Q4 2005. I seriously doubt that “48 percent year-over-year growth in Mac shipments in Q4″ involves only new users. More and more developers are switching to Mac OS X, simply look at the ruby community (and the fantastic screencasts from ruby on rails). On the podcast scene too, Macs are more popular than any other system.

The second argument regards the deprecation of the firewire port for iPods in favour of USB. This seems like a cost cutting measure to me: why support two interfaces when one is far more widespread than the other?

Dvorak’s third argument goes like this: iPod was created to bring people to mac, this didn’t happen. Isn’t that just a repeat of the first argument?

Finally, the switch to Intel is Dvorak’s fourth ace. This is probably the only point that actually can make sense. I won’t dispute it, even if I do not agree.

I’ll skip over the circumstancial evidence that Dvorak uses in the next part of the article. Just to give you an idea, the following sentence “a Microsoft spokesperson [commented] that Microsoft Office will continue to be developed for the Mac for ‘five years.’” leaves Dvorak wondering what happens after that. I would think that after five years this support would have to be negotiated again. Nothing really surprising or uncommon here!

Dvorak continues by affirming that Apple does not have full control of OS X because of its ties to the Open Source community, whereas Windows would allow a better control with its proprietary format. He seems to somehow confuse the issue by using the “linux not ready for the desktop” argument (I’ll have to debunk that one soon).

Before concluding, Dvorak exposes his one and only counter-argument, a one-liner: mac fanatics would go crazy. Sure they would. I’ve actually send this article to a Mac fanatic friend of mine… boy, did I hit that sweet spot!

I do not think that Dvorak seriously believes what he wrote. His article is loud and flashy. It is written to attract the attention of a lot of people. Publicists supposedly say that there is no such thing as bad publicity. Is that Dvorak’s agenda? I think so. What about you?

Io, Io, it’s off to work we go…

First of all, sorry for the title of this post, I just could not resist!

For the last few days, I have been working on the coroutine code in Io. Coroutines are implemented in a system dependent way.

For Windows, Io uses the fiber API. This is nice and simple.

On Unix platforms where it is available, Io uses ucontext.h which is also nice and simple (although the makecontext function call has a bit of an odd signature, understandably).

On other Unix platforms things get very hairy. Io uses setjmp to save the current stack context, modifies the stack context and eventually, when the coroutine gets called, uses it with longjmp. The modification of the stack context cannot be done in a portable way, for the very least because different systems have different registers and stack frame formats.

For linux x86, for example, this involves:

1. changing the instruction pointer register (EIP for a 32bit machine) to point to our coroutine start function
2. allocate a stack frame for the coroutine start function call
3. push the start function parameters on top of the stack
4. have the stack pointer register (ESP for a 32 bit machine) point to this made up frame

Note that for linux, ucontext.h is probably a better choice (is it guaranteed to be there on recent kernels, I’d need to check).

Things are entirely different on OS X, where stack frames are more complex to setup. Good luck Steve!

On a much lighter note, I setup a frappr map of the Io community.

Io: small is beautiful

I have always enjoyed learning a new programming language, especially when the language in question opened my eyes to new idioms. Lisp had a profound impact on me. Prolog too. (I confess, I still have to learn Smalltalk – it would no doubt make this list). Recently I have been teaching myself Ruby. Ruby shares a lot with Lisp (so thinks Eric Kidd). It looked familiar enough very quickly. Ruby’s “principle of least surprise” works for me! While reading about Ruby I stumbled upon an interview of Yukihiro “Matz” Matsumoto, Ruby’s creator. When asked what languages he would recommend to learn, Matz answered Io and Haskell.

I do not know why I chose to have a look at Io rather than Haskell. What I know is that I really like the Io language. Io is beautifully simple. It might not appear so to a newcomer. I suppose this is due to the documentation lagging a bit behind a fast changing implementation.

Here are a list of places to check out if you are looking for information:

• The Io Manual: great introduction
• type-z wiki: another great introduction
• Code samples: short but informative examples
• irc channel: a very friendly and knowledgeable community, good place to get some help, discuss features… I have met some very interesting people there
• Pipapo wiki: more advanced information

Have a look, you will be charmed!

Thanks to everyone on the IRC channel, I have learned so much on so many interesting concepts in so little time.

Behaviour Driven Development

A few days back, I was listening to Dave Astels talk on Behaviour Driven Development on the Agile Toolkit Podcast. It struck a chord!

As a brief overview, Behaviour Driven Development (BDD) derives from Dave Astels experience with Test Driven Development (TDD). In TDD you write your tests before you write your code. Dave argues that this has been misunderstood (see A new look at TDD) and that TDD isn’t about testing the code but about specifying its behaviour. He suggests that changing the vocabulary might improve the quality of TDD, and coins BDD as a way forward.

This resonates with my experience so well! How many times have I seen developers misusing unit tests. Here is an example of what I mean: there is an idiom in Java that says one unit test class per class in the system, and one test method per method in the tested class (Eclipse’s “JUnit test case” wizard does that – note that I am not trying to bash Eclipse here!). This has to be one of the main culprits for the bad usage of JUnit. A TestCase should be about one case, not all use cases! So there should be multiple test cases per class to test. With BDD, the shift in vocabulary tends to force the developer to split the test case in multiple specifications contexts. The tests are not expressed in terms of assertions (prefixed with assert) but in terms of duty (prefixed with should). This helps reinforce the purpose of writing tests first.

Some might say that BDD is only a thin layer on top of TDD. This might be true but I think it is missing the point. BDD is not a paradigm shift, it is an evolution of TDD based on experience. BDD is a pragmatic refactoring of TDD.

I would recommend having a look at RSpec, Dave’s BDD framework in Ruby.