11 ms·

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

55 points by sant0sk1 17y ago

francoisdevlin 17y ago
Well, looks like Ruby just got boring.
bugs 17y ago
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.
- incomethax 17y ago
  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.
  - steveklabnik 17y ago
    Just because 1.8.7 will be 'standard' doesn't mean that MRI has to remain the standard interpreter for it.
    - philwelch 17y ago
      In fact, standardization and a written spec will make it more likely that faster interpreters will be written for it.
- deleted 17y ago
  [deleted]
  - deleted 17y ago
    [deleted]
- carbon8 17y ago
  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/ 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."
blasdel 17y ago
Are there any languages for which international standardization processes have not been either tombstones (like Smalltalk, repeatedly) or vehicles for inter-corporate bullying?
- mbreese 17y ago
  That was my first thought too... "Well, there goes innovation in Ruby".
  - steveklabnik 17y ago
    It's based on 1.8.7, so no worries on that front.
  - jdminhbg 17y ago
    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.
    - jamesbritt 17y ago
      "they just won't advertise themselves as conformant to the standard." But they should advertise themselves as non-conformant to the standard.
  - halostatue 17y ago
    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.
  - deleted 17y ago
    [deleted]
- j_baker 17y ago
  Who was it that said something like "standards are always outdated... that's why they're standards"?
rbanffy 17y ago
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.
c00p3r 17y ago
...and RoR to become the new J2EE. hey, certification-backed trolls! Time to get new certs! =)
- jon_dahl 17y ago
  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.
  - c00p3r 17y ago
    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.
codahale 17y ago
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.

55 points by sant0sk1 17y ago

Well, looks like Ruby just got boring.

bugs 17y ago

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.

incomethax 17y ago
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.
- steveklabnik 17y ago
  Just because 1.8.7 will be 'standard' doesn't mean that MRI has to remain the standard interpreter for it.
  - philwelch 17y ago
    In fact, standardization and a written spec will make it more likely that faster interpreters will be written for it.
deleted 17y ago
[deleted]
- deleted 17y ago
  [deleted]
carbon8 17y ago
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/ 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."

blasdel 17y ago

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

mbreese 17y ago
That was my first thought too... "Well, there goes innovation in Ruby".
- steveklabnik 17y ago
  It's based on 1.8.7, so no worries on that front.
- jdminhbg 17y ago
  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.
  - jamesbritt 17y ago
    "they just won't advertise themselves as conformant to the standard." But they should advertise themselves as non-conformant to the standard.
- halostatue 17y ago
  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.
- deleted 17y ago
  [deleted]
j_baker 17y ago
Who was it that said something like "standards are always outdated... that's why they're standards"?

rbanffy 17y ago

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.

c00p3r 17y ago

...and RoR to become the new J2EE. hey, certification-backed trolls! Time to get new certs! =)

jon_dahl 17y ago
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.
- c00p3r 17y ago
  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.

codahale 17y ago

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.