Live data from Hacker News

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

rubini.us

111–118 of 118 posts

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

#111
post #85

It's disappointing to hear about such problems with Ruby. I hit the same problem with the Groovy Language spec when I first came across Groovy. Its creator, James Strachan, initiated an implementation, test kit, and spec all within 6 months of each other (impl beta-1 in Dec 2003, and spec JSR-241 in May 2004). The project managers who took over from him, Graeme Rocher and Guillaume Laforge, changed direction by stopp…

Are you sure you're not assigning to malice that which could be due to ignorance or indifference?

When you see the same behavior repeated consistently over 10 years, it doesn't matter if it's done consciously (what you call "malice") or as an unconscious habit ("indifference"), the effect is what matters and the intent is the same. The Groovy 2.4 release candidate was released a few days ago and announced on the personal blog of the project manager, but not on the Groovy community mailing list, a consistent behavior which started about year ago. Also a year ago, he launched a weekly mailout newsletter he controls about Groovy separate from the Codehaus repository or the backing company Pivotal Inc, soliciting for subscribers. It all looks like a clear attempt to take over from the other developers involved in building the Groovy codebase. I listed plenty of previous examples of such behavior by these project managers going back 10 years that's harmed the ecosystem, probably irrepairably, and I hope Ruby doesn't go down the same path.

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

#112
post #98

Earlier quoted context omitted.

That's an absolutely terrifying attitude from a language developer....

Is it? Python is exactly the same . It has no language spec (defined by its implementatation), and it has a BDFL who hasn't pushed for one.

That other languages are equally badly specified is not a good argument for why it's not terrifying.

Then again, I don't care about Python. I do care about Ruby.

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

#113
post #54

Earlier quoted context omitted.

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.

See, iirc, Matz years ago specifically said "fork Ruby". He wants lots of different versions which I feel to some extent means diverging from a formal spec, and then occasionally maybe coming back to it.

And that's even worse. I'm working on a Ruby compiler. While it is far from being at a stage where this is a real problem, currently there's no sane way of knowing whether or not I'm "close enough" to MRI other than extensive testing of every single piece of Ruby code I want to work.

"Diverging from a formal spec" is one thing. As it is, many versions of MRI has diverged from how the core team thinks it works. If MRI is "the spec", then Ruby changes from revision to revision as the test coverage is nowhere good enough to prevent regressions or changes in behaviour.

Basically: Nobody knows Ruby.

Frankly, I very much hope that another Ruby implementations overtake MRI sufficiently in quality to out compete it enough to shift the initiative of definining the language to a more responsible team.

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

#114
post #85

It's disappointing to hear about such problems with Ruby. I hit the same problem with the Groovy Language spec when I first came across Groovy. Its creator, James Strachan, initiated an implementation, test kit, and spec all within 6 months of each other (impl beta-1 in Dec 2003, and spec JSR-241 in May 2004). The project managers who took over from him, Graeme Rocher and Guillaume Laforge, changed direction by stopp…

Wow. Fascinating bit of context. Thanks for sharing it here; it's the kind of narrative that is incredibly hard to appreciate if you're not directly affected/involved.

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

#116
Fuck, this idiot is now being pendatic in #ruby as well.

2015-01-02 14:45:30 brixen raise your hand if you have implemented Ruby and used MRI's tests

Glad he didn't get things to go his way. He cries too much. If you don't like some projects go write your fucking own.

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

#117

Earlier quoted context omitted.

https://bugs.ruby-lang.org/issues/7549#note-2 Apparently, he and some of the key devs don't like design by committee or much in the way of bureaucracy.

Matz: community members can deprive of the power of the dictator, when he apparently loose his ability to make rational decision. After deprivation, the community will make up new rules, hopefully flexible ones. I don't want that situation, but the day will come sooner of later I think that's a very disappointing point of view, and I say that as a someone who used Ruby in the past. In light of this I can say it will…

I am of the opinion that, while he took advice and help from the larger Ruby community, he never considered it a "community" project in the sense of communities surrounding other languages.

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

#118
post #30

Earlier quoted context omitted.

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 no…

hi dan,

i apologize, i must have been unclear because it seems that you (& some of the commenters below) are dissecting some of my statements quite literally whereas i put a lot of disclaimery type of statements to try to indicate that this is a combo of personal opinion / hazy memory (if the commenter below ever sees this he can also now receive my apology about mentioning datamapper as an ORM gaining traction, that must be a memory from years ago when i still did RoR). :D

I am aware that RoR has been successfully adopted many places, but i guess part of what i failed to explain here (that thankfully foobarian touches upon a bit) is that i believe that part of the power of "a spec" in a programming context is to maintain a solid core of functionality, that then also paves the way for expanded functionality in the future based on extensions of a similar style of syntax.

I know Ruby & Rails teams are not one and the same, I just have many memories of experiences in that community where library evolution is not incremental, does not expand functionality, deprecates as a rival lib rises in popularity.

In Java you see 2 things -- slow spec evolution & incremental expansion of features. It takes time (I know the fast-moving lang communities hate this) but I find it makes for much more robust codebases that survive upgrade processes with wayyyyyy less re-factoring/re-writing, and in type even some libraries that had their own syntax start to embrace/support the spec (Hibernate implements JPA now...).

So.... I suppose, yes, it is a personal matter perhaps. Some companies have used Rails successfully. But in freelance it has kindof bitten me (the overhead of dealing with security vulnerabilities / gem upgrades alone is astronomically more than I've dealt with in upgrading Java projects). I understand that a competent team can handle this & enterprises can pour money into making it work, but as a programmer who often works alone & hates forced unplanned maintenance, it is a tough pill to swallow.

Also, maybe it is because I am dealing with a lot of enterprise/legacy code at times. Sure, maybe business logic shouldn't go in the database. But if someone supplies me a library of highly complex Oracle functions & tells me i need to wrap these into services ASAP, am I really going to begin an immediate re-write? I would prefer that my framework is just able to wrap these functions until a re-write can be scheduled (if the codebase isn't retired before then...). Also in the enterprise community I don't find as much of a desire to have ALL logic in the app layer... often devs feel that as long as a stored procedure / view / whatever returns a meaningful coherent entity that is useful in the business logic layer, they don't really care where/how the query was aggregated.

I also understand anything can be made to scale & work for an enterprise... but it takes enterprise-level support!! I am more a champion of the rogue programmer trying to build an enterprise with a few lines of code a day. ;)

Best, john

Post reply on HN