[kej]

> By writing Ruby specs you're defining Ruby.

And presumably the MRI devs would say that by coding MRI you're defining Ruby. What gives RubySpecs the authority to say they are the canonical definition of Ruby and everyone should follow it, when the people who created Ruby disagree?

[vidarh]

If that's their attitude, then frankly there's every reason to complain about that. Defining a language by implementation is absolutely horrible practice.

[vinceguidry]

You can't call code a spec. Saying you're defining Ruby by coding it just means you don't have a spec.

[sanderjd]

In my experience, executable specs are much more useful than their non-executable brethren. They prove their own correctness, and can't gloss over important details.

[vinceguidry]

> They prove their own correctness, and can't gloss over important details.

They most certainly don't, do either of those things. You can still have incorrect, incomplete specs even with an executable test suite. You only get those properties through constant work.

The idea behind TDD is to do that as you develop the application, but even then you're not automatically saved from incorrectness and incompleteness.

The only way to really do it is the way RubySpecs intended, create a third place for the specification of the language to live, that any implementation can use to measure its compliance against. If anyone running any implementation on any platform finds a problem and traces it to the implementation, then a new test case can get written and all implementations can then fix the bug assuming it's present. Code quality goes up for everyone.

Most other applications don't need to do it this way, they're intended for an install base of one. But since Ruby has multiple implementations intended to be able to run under multiple platforms on multiple architectures, a living collection of specs that ensures that each combination still has the same behavior would seem to be absolutely essential for one's sanity if one cares about the quality of the language. Each implementation then only has to maintain platform-specific test suites. It's ultimately less work.

But just like TDD/BDD, it requires organizational buy-in to really get the benefits. Everyone working on Ruby needs to be involved in maintaining the test suite or there's no way you can consider the suite canonical. If you can't consider the suite canonical, there's no point in having it.

I develop on MRI at present, but at some point I'm going to switch to either JRuby or Rubinius. If Brian actually follows through on his goals to implement even better ways of specifying Ruby than a test suite, I'll probably switch to Rubinius.

[sanderjd]

It's interesting reading your comment that purports to disagree with mine, while feeling that it instead agrees... I think perhaps the confusion is that I misread your comment that I replied to as suggesting that you can't have an executable spec, rather than (as I now think you meant) as merely claiming that an implementation can't be its own spec, which I definitely agree with.

I think something like RubySpec is fantastic, and that it's really too bad that, perhaps only because of personality conflicts with the maintainer, it hasn't been successful at standardizing behavior across ruby implementations.

[stormbrew]

I suspect from this reply that you're confused about what rubyspec is. Rubyspec is an executable spec. It is thousands of unit tests defined against the official ruby implementation (MRI).

[sitkack]

They dont define anything, they are tautological.

[Retra]

A program can't prove its own correctness in any useful way. Especially for a system that is under continual development.