Live data from Hacker News

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

rubini.us

51–60 of 118 posts

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

#51
post #31

Earlier quoted context omitted.

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?

It's not a third-party definition, it's their definition, should they want to contribute to it. By writing Ruby specs you're defining Ruby.

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

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

#52
post #47
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.

> reports spec failures to ruby-bugs But why should the Ruby developers work to fix 'bugs' against an unsupported 3rd party specification?

It's essentially regression testing. Rubyspec specs out the behaviour of Ruby according to what MRI implements, so any failure is a change in behaviour from the initial implementation. Most of the time this is undesirable/unintentional.

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

#53
post #51

Earlier quoted context omitted.

It's not a third-party definition, it's their definition, should they want to contribute to it. By writing Ruby specs you're defining Ruby.

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

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

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

#54

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…

He might need to check his ego, but the state of Ruby specification is deplorable, and despite being a big fan of Ruby, it's also a big road block to development.

The small number of mature Ruby runtimes is a bad sign.

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

#55

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…

> JRuby, currently the only non-MRI ruby implementation that you can seriously consider for production use

Are there concrete shortcomings when using Rubinius in production, or is it just not battle-tested yet?

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

#56
post #51

Earlier quoted context omitted.

It's not a third-party definition, it's their definition, should they want to contribute to it. By writing Ruby specs you're defining Ruby.

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

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

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

#57
post #30

Earlier quoted context omitted.

When did it become a serious Enterprise™ language? Not being flippant or denigrating Ruby, but when I do work for established enterprises, it's never in Ruby. Java, .NET, PHP, and occasionally Python. Just because startups use it to get off the ground quickly, or to build the front end of their website doesn't make it enterprise.

yes I don't want to get into a flamewar either, but I am an ex-RoR dev and since switching to enterprise Java I hear almost nothing about it largely due to enormously widespread acceptance of Spring (JavaEE is even re-gaining some traction). Long story short (and hope my facts are right! not swearing by this, was just some googling...), I had to optimize some old code for an RoR client I freelance for and wanted to a…

You are ignoring a decade of history in declaring Rails to be "dangerous for enterprise use". The reality is that Rails apps are used in thousands of enterprises around the world, as well as in "web-scale" businesses like Github, Airbnb, and Groupon.

However, Rails (and specifically ActiveRecord) has a very specific design philosophy (see http://david.heinemeierhansson.com/2012/rails-is-omakase.htm... ) which does not include support for stored procedures (because business logic belongs in the app, not the database).

Of course, there are ways to make stored procedures work with Rails (see https://github.com/leopoldodonnell/uses-stored-procedures ) but they are likely to end in tears, since you are working against the grain of the framework.

The basic argument for Rails is not about support for or against any specific underlying technology (if you can reach Facebook-scale on PHP, then you can make anything work), it is that using a mature and well-crafted framework maximizes developer productivity.

For most startups, as well as most enterprises, that is the critical resource.

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

#58

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…

[deleted]

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

#59
post #51

Earlier quoted context omitted.

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

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

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.

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

#60

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.

> It is de facto a more complete test suite than the ad hoc one they've been making.

This is a _huge_ stretch. It's hardly surprising that the suite of tests MRI is running against aren't failing against a _released_ version.

Post reply on HN