That is not entirely true. ISO itself is funded by the member bodies (the national subgroups so to say), member organizations and selling standards. This gives the concrete figures for 2011 [1] on page 2.
Well, of course, they make money by selling standards, since they sell them.
From your link (2011):
55 % through membership fees
45 % through sales of publications and other income from services
2010: 53/47
2009: 55/45
2008: 60/40
..
2006: 62/38
2005: 65/35
..
2002: 80 % - financed directly
20 % - member body subscriptions and publications income
I think they can operate without paid publications. They could, at least.
Am I reading your link right that they receive 45% of their revenue from selling publications? I don't know many organizations that could stand losing 55% of their revenue.
And more importantly, why does it cost a whole 238 francs (~$261)? I mean, a nominal fee for distribution I could understand, but you can buy a whole computer capable of running Ruby for that much.
I'm not sure what this buys Ruby or its community. Could someone explain? The Ruby community is already fragmented a bit with MRI and JRuby (and others, but primarily those two). Does it really need an ISO standard to slow those two implementations down whilst they try to become ISO compliant and maintain ISO compliance? Won't this be an opening for some other opensource group to implement some other ISO certified version that will also fragment the community further? Finally, adherence to an ISO standard and the red tape involved almost seems juxtaposed to the existing self-organized, small, agile culture that makes up the Ruby community. Don't get me wrong- ISO is great. I just don't think it fits.
The question I have, is how good a standard is it? Sometimes language standards are put together in a political way, so all the vendors can say they comply, and the standard has no teeth and no effect on portability.
Since there aren't many players in the Ruby language space, this is probably not an issue, and it's all down to how good a job the standard writers do. (Basically, I understand it's basically only matz who determines what is and isn't Ruby.)
What this should buy the community: protection from future vendor/implementation fragmentation. (But only if it's a strong standard with "teeth.")
Aren't there anomalously MANY players in the Ruby language space?
* The super-important MRI/YARV team
* The mruby team
* The super-important MacRuby team
* The IronRuby team, to the extent it still exists
* The super-important JRuby team
* The super-important Rubinius team
Other languages also have multiple implementations, but they aren't really in viable competition with each other like they are in Ruby (a good thing for Ruby).
Jython vs CPython vs PyPy vs Stackless Python vs IronPython
HotSpot vs OpenJDK vs Dalvik vs GNU Classpath (libraries only) vs Jazelle VM, etc
There is some argument as to which feedback into the language and which are "pure" implementations but I think the point still holds, many languages are pulled in many directions by either their runtime or their compiler.
But isn't Jython years behind the CPython version, PyPy still experimental and on Python 2.x, and IronPython mostly a novelty? Stackless seems in better shape, though, and couldn't say anything in respect to usage.
The argument for Java is clearer and it's a well known case of the interaction of multiple implementors, and thus it has an standardization process.
I would say that CPython, PyPy and Stackless are in pretty strong competition in different areas. PyPy only supporting 2.x seems to be a relatively unimportant metric given the slow adoption of 3.x. As for it being experimental, perhaps technically but I do believe its used in production in many places. From what I know Stackless gets a large portion of its support from CCP games due to its use in Eve Online. I'm sure there are others but its use case is relatively unique.
In the grand scheme of things, the differences between CPython and PyPy are minor. Stackless is a special case. Relatively Python has very little language fragmentation. It has more of what I'd call "implementation fragmentation," but not too much of that either.
Different definition of "player?" I don't think mruby is meant to compete with MRI. JRuby is said by many to be a fork, and I would understand it to be a competitor, but I don't think their intentional focus is forking the language. The same goes for Rubinius. I didn't think of MacRuby to be a language fork. IronRuby isn't a player.
MRI, JRuby, and Rubinius were or are running significant populations of web apps. I wasn't aware that MacRuby was widely used for other than building apps on OS X.
Contrast this with Smalltalk, which at one point simultaneously had VisualWorks, Smalltalk Agents, Digitalk VSE (merged with other vendor), Smalltalk MT, IBM VisualAge Smalltalk, ObjectStudio, Smalltalk/X, Dolphin Smalltalk, and Squeak, all of which were actively being used to build or maintain desktop apps, and all but two of which were running on Windows. On top of that, there were significant semantic and syntactic differences between all of them, which make the differences between Ruby implementations seem quite minor. (Really messy and fundamental differences like namespaces and what does one expect Dictionaries to return when you insert something?)
Back in 1999 or so, most of the Smalltalk implementations were commercial, and many of the companies had no incentive to interoperate and some incentive not to. In contrast, I think there's more incentive to interoperate and avoid language forks for the Ruby community.
Also, if one considers the population of Smalltalk devs back then compared to Ruby devs today, then no, I wouldn't say anomalously many per capita. BASIC and Forth seem to be in a different league for number of implementations. One would have to do some digging, but it might be argued that Ruby has relatively few implementations even for its relative age.
The MRI implementation is way more important than the other implementations. Compare Ruby to something like C, where there is no reference implementation:
* GNU (gcc)
* Visual Studio (mscl)
* Intel (icc)
* ARM (armcc)
* TI (cl6x)
* LLVM (clang)
* ...
Having used all of these compilers (plus more), all implementing the same language, I would say that there is much more meaningful competition in the C space.
Having a standard is a good way to allow better competition, but it does depend on how good the standard actually is.
http://www.rubyinside.com/ruby-iso-spec-draft-2900.html describes the reason behind the standardization. Seems it's more about allowing Ruby to be used in project dealing with the Japanese government than it is about insuring portability.
Though I'm surprised that this is a real rule, because I know Perl has no ISO standard and that it's being used by the Japanese government (and probably everyone else with a Linux box).
@developer9 -> Your comments seem to be dead on arrival, although I cannot figure out why - your comments and submissions look ok to me. Not sure if HN has a silent ban, but just thought you should know.
30 comments
[ 2.9 ms ] story [ 77.9 ms ] threadSo it's probably to maintain neutrality.
Does that mean submitters and downloaders pay or just downloaders?
[1] http://www.iso.org/iso/about/iso_in_figures.htm
From your link (2011):
I think they can operate without paid publications. They could, at least.That's a bargain compared to other ISO standards though.
Since there aren't many players in the Ruby language space, this is probably not an issue, and it's all down to how good a job the standard writers do. (Basically, I understand it's basically only matz who determines what is and isn't Ruby.)
What this should buy the community: protection from future vendor/implementation fragmentation. (But only if it's a strong standard with "teeth.")
* The super-important MRI/YARV team
* The mruby team
* The super-important MacRuby team
* The IronRuby team, to the extent it still exists
* The super-important JRuby team
* The super-important Rubinius team
Other languages also have multiple implementations, but they aren't really in viable competition with each other like they are in Ruby (a good thing for Ruby).
Jython vs CPython vs PyPy vs Stackless Python vs IronPython
HotSpot vs OpenJDK vs Dalvik vs GNU Classpath (libraries only) vs Jazelle VM, etc
There is some argument as to which feedback into the language and which are "pure" implementations but I think the point still holds, many languages are pulled in many directions by either their runtime or their compiler.
The argument for Java is clearer and it's a well known case of the interaction of multiple implementors, and thus it has an standardization process.
MRI, JRuby, and Rubinius were or are running significant populations of web apps. I wasn't aware that MacRuby was widely used for other than building apps on OS X.
Contrast this with Smalltalk, which at one point simultaneously had VisualWorks, Smalltalk Agents, Digitalk VSE (merged with other vendor), Smalltalk MT, IBM VisualAge Smalltalk, ObjectStudio, Smalltalk/X, Dolphin Smalltalk, and Squeak, all of which were actively being used to build or maintain desktop apps, and all but two of which were running on Windows. On top of that, there were significant semantic and syntactic differences between all of them, which make the differences between Ruby implementations seem quite minor. (Really messy and fundamental differences like namespaces and what does one expect Dictionaries to return when you insert something?)
Back in 1999 or so, most of the Smalltalk implementations were commercial, and many of the companies had no incentive to interoperate and some incentive not to. In contrast, I think there's more incentive to interoperate and avoid language forks for the Ruby community.
Also, if one considers the population of Smalltalk devs back then compared to Ruby devs today, then no, I wouldn't say anomalously many per capita. BASIC and Forth seem to be in a different league for number of implementations. One would have to do some digging, but it might be argued that Ruby has relatively few implementations even for its relative age.
* GNU (gcc)
* Visual Studio (mscl)
* Intel (icc)
* ARM (armcc)
* TI (cl6x)
* LLVM (clang)
* ...
Having used all of these compilers (plus more), all implementing the same language, I would say that there is much more meaningful competition in the C space.
Having a standard is a good way to allow better competition, but it does depend on how good the standard actually is.
They should be thinking about 2.0 instead.