Ruby Gets An Official Spec: Heading To Become An ISO International Standard | Hacker News Reader

Ruby Gets An Official Spec: Heading To Become An ISO International Standard

rubyinside.com

55 pointssant0sk129 comments

Are there any languages for which international standardization processes have not been either tombstones (like Smalltalk, repeatedly) or vehicles for inter-corporate bullying?

That was my first thought too...

"Well, there goes innovation in Ruby".

It's based on 1.8.7, so no worries on that front.

Just because there's a standard doesn't mean you have to follow it. I'm sure MacRuby for example will keep its divergent selector syntax; they just won't advertise themselves as conformant to the standard.

"they just won't advertise themselves as conformant to the standard."

But they should advertise themselves as non-conformant to the standard.

Not even likely. The spec/standard is based around 1.8.7 and does not yet address 1.9->2.0. Most of the innovation in Ruby lately has been in how things have been used, not syntactically.

My understanding is that the standard will largely be compliant with RubySpec, pioneered by Rubinius.

Who was it that said something like "standards are always outdated... that's why they're standards"?

And as it says in the draft spec, the reason they are using 1.8.7 is basically because it's a dead end version of Ruby and, therefore, isn't changing.

My favorite: "Standards are great. Everyone should have one."

Are there any languages for which international standardization processes have not been either tombstones (like Smalltalk, repeatedly)

We're zombies!? Actually, that's kinda cool.

You can consider the Smalltalk image as a single program, with branching, mutating clones, which has been running continuously, modulo suspending (image save) since sometime in the 1970s. Maybe that's where our unkillable, repeatedly come-back-from-the-dead nature comes from?

(You can't build a Smalltalk-80 image from scratch because of "strange loops." We've been doing binary transformations to pre-existing images all this time! Even the Squeak image was produced this way. (Dolphin image as well, I believe))

But back to "standards." The Smalltalk standard was pretty wimpy for most if its iterations. It was a watered-down inter-corporate Détente. Not sure about the most recent one.

"(You can't build a Smalltalk-80 image from scratch because of "strange loops." We've been doing binary transformations to pre-existing images all this time! Even the Squeak image was produced this way."

Wow! You mean a Squeak image can't be fully built from source?

That's kind of... scary.

It also reminds me of how we do Plone upgrades... I always cross my fingers.

That's kind of... scary.

Lots of things in Smalltalk evoke that reaction. But while others get to tremble in fear of imagined disasters, we Smalltalkers get to know the truth: that lots of the "conventional wisdom" is nonsense!

Is it that crazy? Aren't most C compilers self-hosting too?

Rather than doing binary translations, though, wouldn't it be easier to just establish a primitive in the smalltalk VM that constructs, as an atomic operation, a graph of interrelated object references, then hands out the IDs to be populated with data?

Then you make the VM larger. ObjectStudio (the old Enfin) Smalltalk has "primitive classes." Classes largely implemented in the VM. With that Smalltalk, you can build the image from source files. The strange loops are resolved this way.

> You can consider the Smalltalk image as a single program, with branching, mutating clones, which has been running continuously, modulo suspending (image save) since sometime in the 1970s.

You could sort of say the same thing about C, except that the "image" is a *nix partition.

Not hardly. When a Smalltalk image comes back, it's in the exactly the same state as it was when it took a "snapshot" then quit. Can't say the same for a Unix box.

There are some deliberate modifications. Like the "command line" array is whatever the command line was when the VM was re-invoked. Sockets deliberately aren't active for security reasons. But where the state isn't exactly the same, it's for a specific reason.

Even processes (green threads) are frozen halfway through, and continue chugging along when we return from snaphot!

C and C++ for starters.

Hopefully this turns out well for the community.

Some advantages I can see being based on ruby 1.8.7 is that now people will have a specific language to develop libraries for, also new people to ruby can have something specific to start with (rather than having to chose between 1.9/1.8).

Those that still want to move so quickly can still choose to do so and continue to use and support 1.9 they just might not have the same following as before.

I really enjoy the speed improvements that 1.9 affords, I can't help but think this will bring back the arguments that Ruby is a slow language simply because the "standard" implementation is slow.

Just because 1.8.7 will be 'standard' doesn't mean that MRI has to remain the standard interpreter for it.

In fact, standardization and a written spec will make it more likely that faster interpreters will be written for it.

I think it's a mistake to believe that this has a big impact on new users or which implementations any of us support in our code.

Plus, it's important to note that the current draft spec actually supposedly covers the existing 1.9 implementation and all other existing implementations by excluding features that differ between them. From the Drafting Guidelines (http://ruby-std.netlab.jp/):

Second, we intend that existing implementations such as Ruby 1.8.7, Ruby 1.8.6, Ruby 1.9, JRuby, Rubinius, and IronRuby can conform to the specification without modifying them. There are some features which are not implemented in some of the implementations or are different among the implementations. Those features are excluded from the specification, or described as either "implementation defined" or "implementation dependent."

I want to be excited about this, but there are big gaps in this spec.

For example, "blah"[0] should return an Object instance which represents "b". Could be a Fixnum. Could be a String. Could be a JPEG of some ASCII art representing the essence of "B." Any of those responses would be valid according to RubySpec.

What happens when you shadow a local variable with a block variable is unspecified, too. In 1.8.x, it overwrites the variable. In 1.9, it doesn't.

Even with a "RubySpec-compatible" implementation, you have no way of knowing if your application will run or not, which kind of defeats the purpose.

I think it's an opportunity to test whether the damage the approval of OOXML caused caused to ISO affects this standardization process or not.

...and RoR to become the new J2EE.

hey, certification-backed trolls! Time to get new certs! =)

This is a formal language spec (e.g. Here is what happens when you call the "foo" method), not a developer certification. Previously, there was no spec, so official Ruby behavior was "whatever the interpreter did". This would have been really useful when projects like JRuby and Rubinius were earlier along.

There will be lots of RoR certification, because certification is a business itself. Think of SAP or Cisco.

Usually certification does not required for a gifted artist, because his abilities are self-evident, but for low-skilled craft man to prove that he possibly could not fail. It is a trick to not to show your abilities each time, because it is extremely difficult to you - think a certificate of sexual ability for impatient - for a healthy man it is not a problem to "prove his ability" =))

mr. Nabokov, for example, didn't got TOEFL before he wrote his "Lolita". TOEFL is required only for pidgin-speakers, like me, and after some amount of practicing it become useless.

Well, looks like Ruby just got boring.

Reply on news.ycombinator.com