Slashdot Mirror

But see also http://onestepback.org/articles/TddMeetsDbc by the same author, who presents a combined DbC/Unit Testing framework for Ruby. (Unfortunately, it relies on Ruby syntax to create a mini-language within Ruby itself.)

Apart from "it's too hard", I think Unit Testing has overtaken DbC as an approach.

- You can write unit tests in any language, with or without a framework. (I saw a "mini-framework" for C that consisted of three macros and a coding convention.)

- In a test, you can specify assertions before and after each method call. It's a little more tedious to represent classic DbC assertions, but the Abstract Test pattern among others allows you to collect common code.

- You can strip out assertions in production code simply by leaving test code out of the product.

- Unit tests also run scenarios automatically, without an extra "test driver".

The one thing Unit Testing *can't* do is check production code as it's running. On the one hand, that's great at catching conditions you never thought of. On the other hand, customers tend to get annoyed if their app shuts down. I'm sure there's some work on partial in the Eiffel world, but so far I haven't seen any.

See also http://onestepback.org/index.cgi/Tech/Programming/ DbcAndTesting.html and particularly the postscript.

The Java comparison is inappropriate, because while the subclass of the type pointed to by the reference might change, the reference remains the same -- the actual type doesn't change. So declaring everying as an Object is useless for doing any real work, because a String or Integer (or anything else) referenced as an Object must be cast in order to call subclass methods. This doesn't work in Java:

Object o = "Hello, World";
System.out.println(o.length());
// This works:
System.out.println((String) o).length());

In Ruby, the actual type is changed, yet any behaviour not specific to the current type of the object is invalid. Hence the type is strong, but dynamic. You can't call "downto" on a String (or "downcase" on a Fixnum), because it doesn't make sense.

Heh, well, no offense but, people that use to reply like you haven't tried Ruby, or don't understand it. Otherwise you would be in love with it already.

We cannot compare PHP and Ruby. It's like comparing BASIC and Perl, you get the idea. Remember when you discovered Perl and all its magic? Well, that's what happens when you get into Ruby. It's a true object oriented and dynamic language ready for real applications.

This might or not make sense to you. It depends on the use you are giving to your language of choice. If you write one-liners in Perl, you might not feel motivated to move to Ruby. If you are writing templates in PHP for your web applications and you're doing fine, you might not need Ruby either.

You see the light :) when you want to write OO applications/scripts. PHP used to have an awful hack (I haven't seen PHP 5), so does Perl 5. Python would be your choice, but for some reasons I cannot explain (yes, this is subjective) Ruby feels more natural.

Ok, I have fallen again in the "I love Ruby so much" that gets you so bored. So, here is some homework for you (some very nice presentations and small articles):

Ruby: A transparent, object-oriented programming language
10 Things Every Java Programmer Should Know About Ruby
The Ruby Programming Language (by Matz, Ruby's author)
Thirty-seven reasons I love Ruby
Blocks and closures in Ruby

Mark Windholtz - Member of Team 32.

Jim Weirich - Member of Team 8.

...a torrent of all the presentations is here.

Anyway, he had some interesting things to say about micropayments; a summary of his talk is at the bottom of the page in Jim Weirich's blog here.

Java *is* quite verbose. But, that's just Java. Fortunately we're getting some more sane iterator constructs in the 1.5 release, but Java will probably always be a highly verbose language (declaring types everywhere, semi-colons at the line ends, etc.)

I'm a big fan of Ruby, but as far as Java integration goes I'm not sure how actively developed it is. The JRuby project may or may not have a lot of steam behind it. Groovy, on the other hand, is being developed pretty actively and does eliminate a lot of the verbosity.

Jim Weirich has an excellent presentation about Groovy that shows a simple Java app convert into Groovy, bit-by-bit &explains the steps along the way. highly recommended! http://onestepback.org/articles/groovy/