Live data from Hacker News

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

rubini.us

61–70 of 118 posts

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

#61
post #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]

If MRI fails RubySpec specs, and the MRI developers didn't write those specs, is that a bug in RubySpec or MRI?

It's egotistical because he's saying they should make their project conform to his third party specification.

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

#62
post #58

Earlier quoted context omitted.

[deleted]

If MRI fails RubySpec specs, and the MRI developers didn't write those specs, is that a bug in RubySpec or MRI? It's egotistical because he's saying they should make their project conform to his third party specification.

> If MRI fails RubySpec specs, and the MRI developers didn't write those specs, is that a bug in RubySpec or MRI?

If the specs were written based on (and working in) a previous MRI version, how can it be anything but an MRI bug? Especially when previously working code segfaults?

> It's egotistical because he's saying they should make their project conform to his third party specification.

How could he do anything but a third-party specification when the first-party refuses to produce a specification?

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

#63
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…

The main benefit of Ruby seems to be the ability to catch method names and treat them as an argument. I bought "Metaprogramming in Ruby", and the author seems delighted that you can do "mycvsrow.columnname". Several other people have confirmed to me that it is really just being able to drop off quotes around what would otherwise be strings in other languages. I don't get it, at all. Maybe it's a knee-jerk reaction to verbose languages like Java. But I fail to see what Ruby offers over a Haskell or F#-like.

I got excited by seeing how passionate and excited people like patio11 were about Rails. But then seeing how Rails prefers insecure defaults and had exploits because they were essentially eval'ing user posted data really hampered my enthusiasm.

Seeing articles like this reinforces the idea that Ruby is cowboy programming, just making stuff up as they go along. Like PHP but with class.

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

#64
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…

Although I agree with what you are saying, this is hardly new. (And still disappointing IMO).

Developers in the RoR community have a tendency to say that "Rails is very good for one set of problems (Basecamp), and using it for anything else is problematic". This has been the answer for every attempt that tried to introduce some worthwhile idea to the Ruby community, be it OO design, TDD or something more "enterprisey" like hexagonal architecture. It's not the Rails Way™, move on.

I've heard developers whom I respect (ie. Avdi Grimm, Sandi Metz) shrug this inherent limitation of Rails off, and I find it really weird. It's akin to Stockholm syndrome really.

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

#65

Earlier quoted context omitted.

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.

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

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

#66
post #44

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?

That's basically how I read this. It seems that Ruby is specified de facto by what MRI does. Reading this blog post it sounds like the developer of RubySpec did this: 1. Decided Ruby needed more formal specification 2. Made their own formal specification 3. Kept telling the core developers to use it 4. Is giving up after years of the core developers not bending to the way he thinks that Ruby should work The whole thi…

> 1. Decided Ruby needed more formal specification 2. Made their own formal specification

RubySpec isn't a formal specification in any way, shape or form. RubySpec is an implementation test suite, and for MRI a regression suite. It uses language constructs and expects a behaviour A based on Ruby version B (which is itself assumed to match MRI version B).

RubySpec isn't somebody thinking up his own definition of Ruby (let alone doing so formally), it's somebody encoding MRI behaviour into a test suite because he needed that to code his own Ruby implementation.

> Why should the ruby developers have to follow his specification?

There's nothing to follow, there's a test suite to run. A test suite which encodes existing MRI behaviour. Why should ruby developers run it? Because it catches bugs is a pretty good reason.

> The fact that there is a bug that causes a segfault only indicates there is a bug, I don't see it as an indictment of the core language process.

How is segfaulting on existing code not an indictment of the core process when just running an existing test suite would have caught it?

> Instead of saying "you should be using my test", you could commit mew tests and patches to upstream.

Have you missed the laundry sheet of issues in the existing MRI testing system?

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

#68

Earlier quoted context omitted.

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.

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

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

#69
post #58

Earlier quoted context omitted.

[deleted]

If MRI fails RubySpec specs, and the MRI developers didn't write those specs, is that a bug in RubySpec or MRI? It's egotistical because he's saying they should make their project conform to his third party specification.

A segfault from running interpreted code is definitely an MRI bug.
Post reply on HN