Microsoft lessening commitment to IronPython and IronRuby
Neil Hodgson
Microsoft on IronRuby about the state of dynamic language work there.
http://blog.jimmy.schementi.com/2010/08/start-spreading-news-future-of-jimmy.html
Neil
Lawrence D'Oliveiro
> http://blog.jimmy.schementi.com/2010/08/start-spreading-news-future-of-jimmy.html
Frankly I never understood the point of IronPython and IronRuby. They seemed
like a desperate attempt to keep Dotnet relevant in the modern world of
dynamic languages. Looks like it was a failure. Yawn.
Tim Roberts
>
>Frankly I never understood the point of IronPython and IronRuby. They seemed
>like a desperate attempt to keep Dotnet relevant in the modern world of
>dynamic languages. Looks like it was a failure. Yawn.
I'm not sure that's really fair. The .NET Common Language Runtime is a
vast and very useful class library, including two complete GUI systems. The
thought was that IronPython and IronRuby would let people who were
comfortable in those languages tap into the CLR.
In the end, it seemed to me that writing an IronPython program was mostly
an exercise of writing it in C# and then translating. .NET is just too
"tuned" for C# and VB. Although IronPython was a good fit, it was just not
a great fit.
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
Lawrence D'Oliveiro
> The .NET Common Language Runtime is a vast and very useful class library,
> including two complete GUI systems.
Used only by corporate code-cutter drones.
Go on, name one creative thing which was ever done in Dotnet.
Stefan Behnel
Erm, this is Microsoft. It's not about being creative, it's about selling
stuff to users.
Stefan
Gregory Ewing
> I'm not sure that's really fair. The .NET Common Language Runtime is a
> vast and very useful class library, including two complete GUI systems. The
> thought was that IronPython and IronRuby would let people who were
> comfortable in those languages tap into the CLR.
Is there any way for a non-.NET program to access a .NET library?
Or is it necessary to drink the entire bottle of .NET kool-aid?
--
Greg
Steven D'Aprano
Not just Dotnet, but Python on Dotnet.
http://www.python.org/about/success/resolver/
http://blog.jonudell.net/2007/09/27/first-look-at-resolver-an-ironpython-based-spreadsheet/
--
Steven
Steven D'Aprano
Stefan Behnel
> On Tue, 10 Aug 2010 18:42:35 +1200, Lawrence D'Oliveiro wrote:
>> Go on, name one creative thing which was ever done in Dotnet.
>
> Not just Dotnet, but Python on Dotnet.
>
> http://www.python.org/about/success/resolver/
At the very end of that article, I found this statement:
"Resolver One is Windows only"
This sounds like a major drawback to me. It might be an acceptable "early
project priority" if the app is only targeting the desktop, but this system
additionally claims to be a "web-accessible spreadsheet". If this is
supposed to run on a server, it means that it will always suffer from the
"headless click-here-to-continue" problem.
It might not be too hard to port the app to Mono, but the rather explicit
claim above doesn't make me feel very comfortable about that upgrade path...
Stefan
Ben Finney
Anyone thinking of using Mono needs to be aware of the dangers of
software patents in general, and of .NET in paticular.
The copyright license for Mono is under free software terms. But that
gives no license at all for the patents. Novell, who have an exclusive
deal for those patents, happily encourages use of Mono by third parties.
The controversy has raged for a number of years. For more coverage than
you have time for, see <URL:http://techrights.org/wiki/index.php/Mono>.
The issue has polarised discussion, unfortunately, and there is a lot of
name-calling and hyperbole on the record now.
As the Mono site hints, the patent situation for .NET is *very* muddy.
Microsoft hold patents covering much of .NET, but have made a
(non-binding) “Community Promise” that applies to *some* parts of .NET
<URL:http://www.mono-project.com/Licensing#Patents>.
--
\ “It is seldom that liberty of any kind is lost all at once.” |
`\ —David Hume |
_o__) |
Ben Finney
Michael Torrie
Well the only way for a non-.net program to access a .NET library is to
either embed .NET or use some kind of bridge via RPC.
So basically, the answer is "no." You pretty much have to embrace .NET
or not use it.
Jason Earl
Which is more of a promise than Microsoft has given to Python. I am not
arguing for Mono, as I am not a fan. But if you honestly think that
Python doesn't infringe on some of Microsoft's patents you are crazy.
So where is the promise from Microsoft saying that they won't sue the
Python development team into oblivion, or Python end users, for that
matter?
There isn't one.
So while the Mono promise doesn't cover all of Mono, it does cover
*some* of Mono, which is better than what Python can say. If you happen
to be believe that Microsoft is likely to attack Free Software via
patents then Mono is arguably the safest choice. Especially if you
confine yourself to the ECMA-sponsored core and the Free Software
libraries that are not re-implementations of Microsoft's technology.
Jason
Ben Finney
> Which is more of a promise than Microsoft has given to Python. I am
> not arguing for Mono, as I am not a fan. But if you honestly think
> that Python doesn't infringe on some of Microsoft's patents you are
> crazy.
It's quite true that anyone can be sued, at any time, for anything. And
any program can, because of the crazy patent system in many countries,
be infringing any (usually large) number of software idea patent claims,
without the programmers having done anything unusual to cause that
situation.
Microsoft, or any other party for that matter, very well may have any
number of software idea patents that could be interpreted to cover
Python's code.
The main difference in the case of Mono is that Microsoft has widely and
repeatedly asserted that such patents do exist, their assertions seem
quite plausible since they wrote the specifications on which Mono is
implemented, its “Community Promise” very carefully does *not* grant any
kind of binding permission to implement or use software ideas from those
patents, and it has consistently wielded other such patents aggressively
and maintains the willingness to continue to do so.
None of that is true for Python. Which is why people aren't saying
Python is a patent trap, but rather that Mono is.
--
\ “Most people, I think, don't even know what a rootkit is, so |
`\ why should they care about it?” —Thomas Hesse, Sony BMG, 2006 |
_o__) |
Ben Finney