11–20 of 118 posts
Why should they have been using RubySpec?
Did you read the article? It contains 10 reasons why the MRI tests aren't sufficient.
Why is RubySpec the special sauce that is so special that the devs not using it is horrible?
Earlier quoted context omitted.
Did you read the article? It contains 10 reasons why the MRI tests aren't sufficient.
The Ruby devs also doesn't use any libraries I wrote, and that's okay. Why is RubySpec the special sauce that is so special that the devs not using it is horrible?
The thing I find depressing and frustrating about this kind of discussion is the fatalism and non-constructiveness. I really wish it was: "I set up a server that runs ruby spec on ruby-head daily and automatically reports spec failures to ruby-bugs" So many companies are making big bucks off Ruby, yet so little are willing to fork out a bit of money and time to make Ruby better.
Earlier quoted context omitted.
Did you read the article? It contains 10 reasons why the MRI tests aren't sufficient.
The Ruby devs also doesn't use any libraries I wrote, and that's okay. Why is RubySpec the special sauce that is so special that the devs not using it is horrible?
Assuming TFA isn't actively lying[0]: because it fixes the issues outlined which allow (amongst other things) cross-implementation and cross-version uses, because it tests behaviours not tested by the MRI suite anyway and because it's there as an extensive test suite for the language.
Oh, and because according to TFA it found regressions in just about every release it's existed for. Regressions which could thus have been caught before the release was cut.
[0] and I don't see any reason to assume otherwise, quite the opposite.
The thing I find depressing and frustrating about this kind of discussion is the fatalism and non-constructiveness. I really wish it was: "I set up a server that runs ruby spec on ruby-head daily and automatically reports spec failures to ruby-bugs" So many companies are making big bucks off Ruby, yet so little are willing to fork out a bit of money and time to make Ruby better.
it's unreasonable to expect the dev who has already put a ton of work into developing and maintaining rubyspec and making it work nicely with all the ruby implementations and versions he could to have to put in the additional work to do this as well. I don't blame him for getting discouraged at having to chase a moving target on top of all that - I agree with him that having the MRI devs contribute to rubyspec was a…
It's just such a better outcome, nobody needs to change workflows its just that information gets reported upstream earlier in a much more useful time.
Earlier quoted context omitted.
it's unreasonable to expect the dev who has already put a ton of work into developing and maintaining rubyspec and making it work nicely with all the ruby implementations and versions he could to have to put in the additional work to do this as well. I don't blame him for getting discouraged at having to chase a moving target on top of all that - I agree with him that having the MRI devs contribute to rubyspec was a…
Throwing away a project that is clearly working is depressing. can't Heroku/GitHub/37 signals or someone sponsor a week of dev time to automate a system that runs the suite on latest? It's just such a better outcome, nobody needs to change workflows its just that information gets reported upstream earlier in a much more useful time.
Earlier quoted context omitted.
Did you read the article? It contains 10 reasons why the MRI tests aren't sufficient.
The Ruby devs also doesn't use any libraries I wrote, and that's okay. Why is RubySpec the special sauce that is so special that the devs not using it is horrible?
Given that, the onus is on the MRI developers to demonstrate why they are actively avoiding the use of a tool that could improve the stability of their language and environment.
Has Matz stated the reasons they are not using RubySpec? Knowing him, I can't really believe he has chosen to ignore RubySpec without good reasons.
Apparently, he and some of the key devs don't like design by committee or much in the way of bureaucracy.
Earlier quoted context omitted.
Throwing away a project that is clearly working is depressing. can't Heroku/GitHub/37 signals or someone sponsor a week of dev time to automate a system that runs the suite on latest? It's just such a better outcome, nobody needs to change workflows its just that information gets reported upstream earlier in a much more useful time.
The Ruby devs attitudes in the discussions linked FTA makes me question the longevity of Ruby as a serious Enterprise language.
Earlier quoted context omitted.
Throwing away a project that is clearly working is depressing. can't Heroku/GitHub/37 signals or someone sponsor a week of dev time to automate a system that runs the suite on latest? It's just such a better outcome, nobody needs to change workflows its just that information gets reported upstream earlier in a much more useful time.
The Ruby devs attitudes in the discussions linked FTA makes me question the longevity of Ruby as a serious Enterprise language.
Note that I'm not trying to criticize this position, rather, I'm pointing out that the core Ruby team seems to have different goals than, say, the community around Java or C#.