> 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.
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.
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.