Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MRI Developers Don't Use RubySpec and It's Hurting Ruby

rubini.us

Post reply on HN
Print view View original

31–40 of 118 posts

Re: MRI Developers Don't Use RubySpec and It's Hurting Ruby

#31

Post by kej »

zem wrote: post #13
sams99 wrote: post #6

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…

Why is it unreasonable to expect the RubySpec dev to do additional work, but reasonable to expect additional work from the MRI devs to comply with RubySpec?

I get that "the implementation is the standard" is frustrating for people who want to make an alternate implementation, but why should that obligate the original developers to accept some third party's definition of what their project should be?

Re: MRI Developers Don't Use RubySpec and It's Hurting Ruby

#32

Post by thinkbohemian »

sams99 wrote: post #15
zem wrote: post #13

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.

> can't Heroku/GitHub/37 signals or someone sponsor a week of dev time to automate a system

Heroku does sponsor Matz, Nobu, and Koichi. We hired them and give them a full time salary to work on Ruby.We don't tell them what to work on (i.e. we don't dictate what features or projects get shipped in what versions) it's more like corporate sponsorship. GitHub hired tmm1. Beyond that CRuby has a host of other non-sponsored contributors that contribute code and doc patches as well as set up tooling. You don't need corporate sponsorship for that, you need a passion and some time. You, in fact, could be the very person that sets up this automated system.

I find the attitude of ' should sponsor ' a bit misguided. While I agree that companies who profit from a OSS should give forwards to OSS, individual contributors are ultimately they only way progress gets made. If you or someone reading this works for a company making money off of Ruby do that thing! Tell your boss you can't deploy on friday afternoon and have to fix a bug in the Ruby codebase. Ship the project on company time, and then boom...your company just sponsored that thing. It's like magic!

Anywhoo, yes finding out what things are blocking the MRI team from adopting a tool/technology and working around them can be extremely valuable. For example Matz has agreed to move the codebase development to github. This would make contributions a bit easier, however there is a blocker. There are a ton of SVN bots and tooling written around the current workflow. Right now the Ruby core team wants to spend time focusing on pumping out C code to fix bugs, improve performance, and progress the language forwards. They don't want to go off into the woods on tooling. These types of projects could be hugely impactful to the team and don't require C knowledge so most Ruby devs may be able to help. I encourage you and others to reach out to the core team to ask them what tooling projects they need and how we can help them. Understanding why someone isn't using a tool/technology is a really good start.

tldr; Good idea, let's talk to the core team about ways to help with tooling.

Re: MRI Developers Don't Use RubySpec and It's Hurting Ruby

#33

Post by headius »

nateberkopec wrote: post #22

Rubyspec is a great project for all the reasons Brian outlines. However, it's also a failure - in part, due to Brian and his attitude towards contributors. See this twitter conversation: https://twitter.com/the_zenspider/status/547527644535726080 He's been grinding on Rubyspec for years, bless him, but I think there's a reason why he was unable to rally the community behind his effort, both in terms of gathering more…

I came to the thread to make sure someone was spreading truth rather than FUD, and this was the first comment I saw. Bless you.

Re: MRI Developers Don't Use RubySpec and It's Hurting Ruby

#34

Post by sinistersnare »

mbell wrote: post #23
Terr_ wrote: post #8

Regardless of other warts with the language, I really love how the Java Language Specification lays down the law.

I find Java's approach to specs to be one of the worst parts of the ecosystem. I've come across numerous obvious bugs with various Java specced libraries that have been marked `won't fix` because the bug is actually either a bug in the spec or just got left out in order to rush the spec out the door (rush being a loose term here given how often Java actually updates it's various specs).

At least the bugs are documented. Ruby bugs just are, theres nothing confirming them.

Java bugs need to stay there because if they were fixed then it would be a backward incompatible change.

Re: MRI Developers Don't Use RubySpec and It's Hurting Ruby

#35

Post by headius »

stormbrew wrote: post #17
danielweber wrote: post #11

Earlier quoted context omitted.

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?

Honestly, just the fact that rubyspec exposes a segfault in a new release is more than reason enough that they should be using it. It is de facto a more complete test suite than the ad hoc one they've been making. 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.

They have used and contributed to RubySpec in the past, but many (like me) were turned off by the maintainers' attitudes toward contributors and lack of respect. For example, see the zenspider link elsewhere in this thread.

Nobody questions RubySpec as a project. But there are many nontechnical reasons why it was never adopted wholeheartedly by ruby-core.

Re: MRI Developers Don't Use RubySpec and It's Hurting Ruby

#36

Post by headius »

jes5199 wrote: post #27

I almost didn't catch the epilogue - he's shutting down the RubySpec project entirely, because it hasn't accomplished what he hoped.

I believe he's shutting it down as a political move. They're still going to use it to maintain Ruby compatibility and they'll still need to run it against MRI. It just isn't a standalone project now.

Re: MRI Developers Don't Use RubySpec and It's Hurting Ruby

#37

Post by headius »

dyeje wrote: post #9

Some of the discussions he links to in the article are disturbing. Many posts refusing to implement process because they don't want any process at all. Doesn't seem like a healthy approach.

Be wary of this cultivated list of links. There are others out there that would make it very clear why the proposed design process was a misfit given the projects and people involved.

Re: MRI Developers Don't Use RubySpec and It's Hurting Ruby

#38

Post by lgleason »

Both Charles Nutter and Matz are smart guys. They are also both great people. I say this having spent time with both of them. This whole, my implementation is better than theirs coming from Brian is crazy.

Matz and Charles have helped to set the tone for the community. While I appreciate Brian's passion, it sounds like he needs to check his ego. No matter how smart we are, we can always learn things from other people. Without the collaboration of others neither JRuby or Ruby would be what they are today which is why they are successful.

Re: MRI Developers Don't Use RubySpec and It's Hurting Ruby

#39

Post by Tobu »

nateberkopec wrote: post #25
joevandyk wrote: post #5

Why don't MRI developers use RubySpec?

As linked in another comment, basically: https://bugs.ruby-lang.org/issues/7549#note-2 1. Matz is, and always will be BDFL. 2. The core Ruby team wants to talk in terms of C and MRI being the Ruby spec, not a third party/written RubySpec

They could always have their own fork/branch for upcoming releases of Ruby. It's not like the spec has to freeze the language.

Re: MRI Developers Don't Use RubySpec and It's Hurting Ruby

#40

Post by mbell »

sinistersnare wrote: post #34
mbell wrote: post #23

Earlier quoted context omitted.

I find Java's approach to specs to be one of the worst parts of the ecosystem. I've come across numerous obvious bugs with various Java specced libraries that have been marked `won't fix` because the bug is actually either a bug in the spec or just got left out in order to rush the spec out the door (rush being a loose term here given how often Java actually updates it's various specs).

At least the bugs are documented. Ruby bugs just are, theres nothing confirming them. Java bugs need to stay there because if they were fixed then it would be a backward incompatible change.

That attitude is exactly why I have no interest in working with Java.
Post reply on HN