Ruby and Contract Programming (was Ruby vs. Ada)

[Robert Dober]

Hi list

I have had some thoughts about Contract Programming and Ruby, this
after the recent suggestion that Ruby might have to evolve into this
direction.
I am a complete ignorant of CP (also aka Programming by Contract and a
different copyrighted term) and that is why I was very defensive on
the subject.
Not having got any reply I will try to come up with some conclusions
based on the little I know, hopefully nobody will take offense and
rather take the opportunity to correct me where necessary.

My first assumption is that Ruby and other dynamic languages do not
shine on large scale projects if ( and mostly only if ) there can be
no automated testing, and thus BDD/TDD cannot be applied.
Whenever BDD (e.g) is applied I have much difficulties to see how CP
could come into the picture. As a matter of fact one can see all the
contracts in the testcases, only that we are talking behavior, which
is mighty efficient. There are other quite striking parallels between
CP and BDD, e.g. never write code unless it makes a failing test pass
vs. define the contracts first.

The remaining question would be could (and should) Ruby try to occupy
other niches (talking in terms of evolution?). For the sake of
argument let us say yes, I am however not at all convinced that it
really should, than I guess this shall be done without sacrificing any
of its dynamic qualities.
So the type of contract one could establish would be to check for
frozen modules/classes, or frozen traits, which I would prefer of
course .

A simple example of how a contract could look like

def my_method arg
my_module.instance_methods.all?{ |m| arg.respond_to? m}
...

I do not see what could be done more (maybe just checking the arity of
the methods?) but all more sophisticated enforcements as the interface
of a method
just do not bear any meaning in Ruby.

My conclusion would be not to go for the throat of strongly typed
languages (especially not Ada or OCaml) because it would be an error
to try to occupy all niches of the ecosystem in general. In particular
I see CP quite inadequate for the evolution of Ruby.

Ok I am duck (type-) ing now.

Cheers
Robert

 

[ThoML]

My conclusion would be not to go for the throat of strongly typed

languages (especially not Ada or OCaml) because it would be an error
to try to occupy all niches of the ecosystem in general. In particular
I see CP quite inadequate for the evolution of Ruby.

So don't use it then. Making it possible for others to incorporate
contracts in the source wouldn't oblige you to do so.

IMHO ada and ocaml are two rather different languages. The first
statically typed language that comes to mind when saying DBC would
IMHO rather be Eiffel.

Anyway, there is always a chance that an evolution comes to a quick
halt due to inadaptability.

 

[Robert Dober]

So don't use it then.
Making it possible for others to incorporate
contracts in the source wouldn't oblige you to do so.

Do you mean by this that CP could be done reasonably in Ruby now? I
believe that it cannot be done in Ruby nowadays, that
the contracts would be too weak and I believe "evolving" Ruby into
that direction would not be to Ruby's benefits. You cannot just add
features without paying a price now maybe this *is* the thing to do
creating a multi paradigm language, I somehow doubt it...

IMHO ada and ocaml are two rather different languages. Very different, indeed.
The first
statically typed language that comes to mind when saying DBC would
IMHO rather be Eiffel. True, a good example.

Anyway, there is always a chance that an evolution comes to a quick
halt due to inadaptability.

And not much one can do about it because it is rather difficult if not
impossible to anticipate the changes in the environment.

Robert

 

[ThoML]

Do you mean by this that CP could be done reasonably in Ruby now?

It depends what you mean with "reasonable". I have my doubts that such
a solution would cooperate well with all sorts of other meta-
programming libraries.

You cannot just add features without paying a price

Maybe it's a specialization of a more general feature or maybe better
support for metaprogramming that is currently missing (like the
ability to rewrite code blocks/lambdas, intercepting certain method
calls, making system hooks more general/robust so that several
libraries can use method_added without interfering with one another
etc.).

Maybe this will one day become a ruby quiz:

Quiz #1: Implement class invariants in a robust/unbreakable way.
Implement method advises etc.

Quiz #2: Implement a library that breaks the solutions from #1.

If there is still a solution left, the answer to your question would
be yes.

 

[Robert Dober]

It depends what you mean with "reasonable". I have my doubts that such
a solution would cooperate well with all sorts of other meta-
programming libraries.



Maybe it's a specialization of a more general feature or maybe better
support for metaprogramming that is currently missing (like the
ability to rewrite code blocks/lambdas, intercepting certain method
calls, making system hooks more general/robust so that several
libraries can use method_added without interfering with one another
etc.).

Maybe this will one day become a ruby quiz:

Quiz #1: Implement class invariants in a robust/unbreakable way.
Implement method advises etc.

Quiz #2: Implement a library that breaks the solutions from #1.

If there is still a solution left, the answer to your question would
be yes.

Yes that sounds very interesting indeed.
Thx
R.