Comment by rmoriz | Hacker News Reader

Comment by rmoriz | Hacker News Reader

It seems to me the massive "investments" made in mainly web-related frameworks (Rails, Merb, Sinatra + ORMs) didn't help the foundation of the Ruby ecosystem: Take rubygems, take RAA, take the MRI development process.

If you got "brainwashed" in the last 5 years about code quality (DRY etc.) + test methods (TDD/BDD) and then look at today's Stdlib, you'll scream and want to put bleach into your eyes…

To me it seems the "übercool" guys already moved away to their NoSQL/node.js/whatever next party, so it's not easy to motivate people to change such "messy" and large projects anymore.

I'm also not sure about the number of Ruby interpreters around and their useful impact: If you e.g. change something for Ruby 1.9.x / 2.0.0, it will cost a lot of manpower to port those changes to JRuby, Rubinius, maglev, IronRuby and BlueRuby (if SAP's Ruby is still alive?) and most of them are just used by very few people.

Maybe resources are better spent in creating a new Stdlib, improve the rubygems infrastructure (already started with gemcutter) and do something with RAA?

Gems has been significantly improved in the last year-two years both under the hood and in the frontend (not to mention since it first came about…I refused to use it until 2007).

RAA has been obsolete since RubyForge (which was subsequently succeeded by Gems and Github), I am not sure why you would even bring it up.

The MRI development process is very conservative, yes, but that is offset by the very dynamic development processes of Rubinius and JRuby (even if in part driven by the conservativeness). There are few things in the language itself that need change, and those are to be resolved for 2.0. The main development cost is in actually setting forth the changes, not in implementing them.

The Stdlib sucks, sure, even if some of the libraries are better-maintained than others. Better alternates can be installed via Gems in almost all cases. There is an ongoing proposal to gemify the rest of the Stdlib (some parts are needed just to support Gems itself) mainly to reduce the distribution size and there are some arguments back and forth. By and large, however, it is pretty irrelevant to day-to-day life with Ruby.

In the meanwhile, if you are serious about the problem: spend your own resources to adopt one of the stdlibs and update it as necessary. This is open source, and that is how problems get solved.

Edit: removed tautology in 4th paragraph.

RAA is basically considered dead for all intents and purposes. I have rarely ever gotten anything useful from there considering it was considered "outdated" when I started Ruby some 5 years ago.

yes, considered dead but still having a few updates a month. A zombie project that needs to be ended "officially".

Rubygems has gotten a few improvements from the popularity of Rails. Github gem hosting may have been a stepping stone, but it did help. Bundler and gemcutter are definitely an improvement.

rubygems still lacks a mirroring and is heavly amazon AWS dependent.

see the slides of my recent talk about it:

http://www.slideshare.net/rmoriz/rubygems-behind-the-gems

The Ruby language specification (http://www.rubyspec.org/), to which all Ruby VMs are written, helps as far as the "number of Ruby interpreters around and their impact" goes. (Assuming I understood your concern correctly.) A new Ruby VM is considered legit if it passes Ruby Spec. That should help in both transparency and compatibility across implementations.

Would you agree?

but you still have to implement a "language change" into all different VMs. This does cost time and money but delivers redundancy that has to be maintained. Which is great, if you don't have more important problems.

A horrible Stdlib is imho a more important problem today.

Following your link: "This website is presently being redesigned. We expect to be back soon."

But I knew already that "rubyspec" wasn't a spec in the ordinary sense but a test-suit built with MSpec.

The thing is that real spec actually fully specifies a language - at least up to syntax. There are real specs for Python and Java for instance. The only real spec for Ruby is still crufty Yacc code for MRI.

A test suit doesn't do that and the whole Rubyspec thing is a testimony to people drinking too much of the Test Driven Development Cool Aid. TDD may be fine for some things but some formal design is needed for things like the creation of interpreters.

Part of the challenge is that MRI has such a fluid syntax that specifying it conventionally would be quite hard. But I suspect that's what will have to happen if Ruby's going to go forward.

Java has a real spec. Python has documentation, but it isn't really sufficient for a spec, and for the most part alternative implementations copy down to the last implementation detail (gc details notwithstanding). A test suite is probably better than what it has.

It depends what you mean by "better".

Maybe Python has lousy spec but as I recall, the documentation does include a BNF breakdown of what Python is.

A test suite can be good for a lot of things BUT it cannot be a specification, it cannot be even sort-of a specification. Test suites only "prove a negative", only prove that an application won't do X. A specification is at least a rough assertion of a positive, that a language does follow this pattern.

Yeah, there's an EBNF syntax description. I must have missed the part where the GP thought that's all that was necessary for a "real spec". I guess I just disagree.

Java specifies the semantics of Java and the JVM remarkably fully. Python, not so much.

Reply on news.ycombinator.com