I think the biggest risk to IronRuby is the CLR, not the IronRuby
implementation itself. As noted, that’s in a reasonably open license.
I’m interested in why you think that the CLR is a risk? We’ve standardized CLR via the CLI and there is an open-source implementation of the CLR in Mono. DLR / IronRuby should just run on Mono in binary form.
Long-term risk. Microsoft could change how the CLR works to penalize a
forked IronRuby, at least in theory.
I think the biggest risk to IronRuby is the CLR, not the IronRuby
implementation itself. As noted, that’s in a reasonably open license.
I’m interested in why you think that the CLR is a risk? We’ve standardized CLR via the CLI and there is an open-source implementation of the CLR in Mono. DLR / IronRuby should just run on Mono in binary form.
Long-term risk. Microsoft could change how the CLR works to penalize a
forked IronRuby, at least in theory.
But in that way, you would still have Mono+ForkedIronRuby as an
alternative. I hope MS wouldn’t do such a thing though.
I rather disagree. Competing language implementations help clarify
ambiguous specifications and behavior.
What ambiguous specifications and behaviour would those be exactly?
Ruby doesn’t have a formal spec that I’m aware of. And don’t point to
that PHP-based wiki thing either because most of the links there lead
to non-existent pages.
It also may be the case that
implementations targetting the CLR or the JVM have benefits over the
existing interpreter for some customers.
Customers? As far as I know Ruby is free so there are no customers.
It is absolutely our intention to enable Rails running on IronRuby. If Rails doesn’t
run, how could our implementation be considered a compatible implementation?
Why not contribute to the existing Ruby project instead? That’s how real open source development is done. Making a M$ version of Ruby
doesn’t help Ruby much at all.
I don’t understand your apparent need to reinvent every wheel you see.
Real open-source develoment does not require everyone contribute to the
same codebase, especially when their design requirements or project
goals differ. If that were the only way to do “real” open source
development, we’d all be stuck using XFree86, vi (not vim), various
under-powered shells, and TWM. Innovation and openness do not require
boxing yourself into pre-existing implementations.
But in that way, you would still have Mono+ForkedIronRuby as an
alternative. I hope MS wouldn’t do such a thing though.
Anyone with genuinely good intentions would contribute to the existing
Ruby and leave all this separate implementation non-sense alone.
Their intent is clear.
I rather disagree. Competing language implementations help clarify
ambiguous specifications and behavior.
What ambiguous specifications and behaviour would those be exactly?
Ruby doesn’t have a formal spec that I’m aware of. And don’t point to
that PHP-based wiki thing either because most of the links there lead
to non-existent pages.
There are some links that don’t yet have articles; that’s to encourage
someone to pitch in and help. That’s pretty common among wikis in
general though…even wikipedia has “red” links.
Feel free to add content where you think you’re able
of the best of intentions. In any case, I agree to wait and see.
It’s hard to argue that case for Sun, where the JDK is now open-source,
the expectation is that money will primarily be made off hardware rather
than software (which is supposed to be open-source now across the
board), and JRuby remains a fully open, community-driven project with
its original licenses intact.
But in that way, you would still have Mono+ForkedIronRuby as an
alternative. I hope MS wouldn’t do such a thing though.
Anyone with genuinely good intentions would contribute to the existing
Ruby and leave all this separate implementation non-sense alone.
Their intent is clear.
Does this mean that the JRuby, rubinius, and Ruby.NET folks (none
of whom are MSFT by the way) are also intent on destroying Ruby?
I think it’s an awfully broad and underinformed brush you’re painting
with there.
But in that way, you would still have Mono+ForkedIronRuby as an
alternative. I hope MS wouldn’t do such a thing though.
Anyone with genuinely good intentions would contribute to the existing
Ruby and leave all this separate implementation non-sense alone.
Their intent is clear.
Anyone really interested in the welfare of Ruby would recognize that
having a wide range of implementations helps stabilize the API and
language and accelerates adoption.
Does this mean that the JRuby, rubinius, and Ruby.NET folks (none
of whom are MSFT by the way) are also intent on destroying Ruby?
I think it’s an awfully broad and underinformed brush you’re painting
with there.
thanks,
-pate
I’ll personally try to not do a broad brush stroke, but you have to
admit that MS, or M$ as some call it, is a shining example of
capitalism run awry. Now, I like MicroSoft – quite a bit actually –
but, the business practices every once and a while scream of
selfishness; Adam Smith to a tee.
So, where do the others (rubinius, JRuby, IronRuby, CLR, blah blah)
fit into the picture? I’m not sure. But, it will be interesting to
find out.
Off topic: Recently, the haiku-os (formerly openbeos) project lost two
of its main developers/contributers because they had other life things
they had to attend to. The original BeOS was swallowed up by Palm
INC., who, as far as I know, did nothing with the code (quite possibly
the most brilliant C++ code in history; I think I have the email
transcripts to prove it if anybody would want them). I would not like
to see a similar (wasting away/gobbling up) with Ruby.
I want a .NET native Ruby so that I can script .NET applications with
Ruby. That’s what IronRuby is.
None of the existing M$ language atrocities suite you?
No. Nothing (IMO) is as beautiful as Ruby for this sort of thing. If I
could reliably extend our code that’s written in C# with Ruby, then
Ruby would have a lot more uptake at our company. (Or extend our Ruby
with C#, vice-versa.) Right now, we primarily use Ruby as a code
generation language.
I guess I should clarify. I wouldn’t be revealing “secrets”; just
showing anyone who’s interested in the tech letters, which are
available to everyone (except for the fact that I can’t find them
anywhere on the internet).
Hmmm… you have the Be tech letters archived? I guess it’d be nice to
have them around. Maybe we could arrange for you sending it to me?.. (:
Off topic: Recently, the haiku-os (formerly openbeos) project lost two
of its main developers/contributers because they had other life things
they had to attend to. The original BeOS was swallowed up by Palm
INC., who, as far as I know, did nothing with the code (quite possibly
the most brilliant C++ code in history; I think I have the email
transcripts to prove it if anybody would want them). I would not like
to see a similar (wasting away/gobbling up) with Ruby.
Todd
I guess I should clarify. I wouldn’t be revealing “secrets”; just
showing anyone who’s interested in the tech letters, which are
available to everyone (except for the fact that I can’t find them
anywhere on the internet).
Just wanted to clear that up.
My computer says it will explode in 10 seconds (-:
On Wed, 24 Oct 2007 01:48:08 +0900, John L. (DLR) wrote:
I think the biggest risk to IronRuby is the CLR, not the IronRuby
implementation itself. As noted, that’s in a reasonably open license.
I’m interested in why you think that the CLR is a risk? We’ve
standardized CLR via the CLI and there is an open-source implementation
of the CLR in Mono. DLR / IronRuby should just run on Mono in binary
form.
Very cool to hear from someone at Microsoft. My concern, on reading the
above, is that Mono apps work great when going from Microsoft to Linux,
but not all Mono apps work great when going from Linux to Microsoft.
In and of itself, that’s a hassle. However, the long term effect would
be detrimental for Ruby on Linux, which would be viewed as a backwater.
Very cool to hear from someone at Microsoft. My concern, on reading
the
above, is that Mono apps work great when going from Microsoft to Linux,
but not all Mono apps work great when going from Linux to Microsoft.
In and of itself, that’s a hassle. However, the long term effect would
be detrimental for Ruby on Linux, which would be viewed as a backwater.
Are you talking about library compatibility or are there runtime
compatibility issues? If the latter, this would seem to be something
that is either:
a) a bug in one of our implementations vs. the CLI spec or
b) something unclear in the CLI spec
Both a) and b) have happened and we’ve been able to resolve those issues
with the Mono team. There’s also the other issue where their
implementation tends to lag behind the latest versions of the CLR / C#
as well, but that’s more of a resourcing problem rather than a technical
one (I’m sure they could use more help on their project too!)
of the CLR in Mono. DLR / IronRuby should just run on Mono in binary
Are you talking about library compatibility or are there runtime
could use more help on their project too!)
-John
Hi John, I was asking myself how much is Microsoft betting on dynamic
languages like Ruby, Python et al. I mean, they look interested because
they
're hiring people, but IronRuby (if I’m not wrong) is in pre-alpha and
has a
very small team…I’m sure Microsoft is not giving the Iron(.*) projects
the
importance they deserve.
I heard that in Silverlight 1.1 IronRuby is going to be one of the
alternatives to use, but I’m a bit puzzled, because SilverLight seems to
advance much faster than IronRuby…
