Rick DeNatale wrote: > On Nov 11, 2007 6:39 PM, Charles Oliver Nutter <charles.nutter / sun.com> wrote: >> Rick DeNatale wrote: >>> Unless and until extensions can be written which are portable against >>> Ruby, JRuby, IronRuby, Rubinius ... the Ruby 'market' will be >>> fragmented. >> It's the very fact that Ruby extensions are written in C and compiled >> with C compilers to shared libraries with very specific constraints that >> limits their general applicability to other implementations (and limits >> evolution of core Ruby development as well). >> >> So I would propose that what you're saying is right...and that writing >> C-based extensions by hand just aggravates the problem, since C-based >> extensions are never going to be generally applicable to all >> implementations. > Well I never said that portable extensions needed to be written in C. > > So maybe we should be rooting for Evan, and hope that we can soon be > writing extensions in a ruby-like version of Squeak's Slang. Welll ... there are only a few reasons why one would write an extension in the first place: 1. To work with a data type not native to the language. As far as I know, the only commonly-used data type that doesn't have native operations in MRI is large multidimensional arrays of floating point (possibly complex) numeric data. So we need NArray and Ruby interfaces to C code like GSL, and Ruby becomes a "control language" rather than a data processing language. 2. To use existing functionality already written in another language. This is why most extensions get written, and since most of the functionality is in C/C++, most of the extensions are written in C. In jRuby, of course, rather than use existing functionality in C, one uses existing functionality written in Java. Again, Ruby becomes a "control language" rather than a data processing language. 3. To get more processor- or memory-efficient operation. 4. Because it's open source and we can. :) I think, of all these reasons, 4 is the only *legitimate* reason to write an extension in a language other than Ruby. For 1, as I noted, as far as I know there's only one missing data type, and I think it could be easily integrated into any of the implementations. It's just a matter of the community deciding that it should be there and coming up with a syntax and semantics workable in all of the implementations. For 2, given that Ruby operates on most platforms, it's almost always possible to accomplish 2 using "loose coupling" with little or no penalty. For 3, I think YARV and jRuby have both shown that one can stay in Ruby and still gain significant efficiency. And Rubinius has as its goal minimizing the size of the C core without losing efficiency, and I think they're well on their way to that. So that leaves 4 ... because it's open source and we can.