I'm curious about how .NET will affect Python and Ruby applications.
Will applications written in IronPython/IronRuby be so specific to the .NET environment, that they will essentially become platform specific?
If they don't use any of the .NET features, then what is the advantage of IronPython/IronRuby over their non .NET counterparts?
I can't say anything about IronRuby, but most python implementations (like IronPython, Jython and PyPy) try to be as true to the CPython implementation as possible. IronPython is quickly becoming one of the best in this respect though, and there is a lot of traffic on Planet Python about it.
The main thing that will encourage developers to write code that's different from what they would write in CPython is the lack of C extension modules like NumPy (This is a problem in Jython and PyPy as well).
An interesting project to keep your eye on is IronClad, which will let you call C extension modules from within IronPython. This should eventually mean that you can develop code under CPython, using whatever modules you like, and it will run unmodified on IronPython.
http://www.resolversystems.com/documentation/index.php/Ironclad
So to answer your questions:
It should be easy enough to write IronPython applications that work on CPython as well, but I would probably aim to go the other way around: CPython programs that work on IronPython as well. That way, if it doesn't work then it's more likely to be a known bug with a known work-around.
The advantage of IronPython et al existing is that they provide alternative implementations of the language, which are sometimes useful for spotting bugs in CPython. They also provide alternative methods for deploying your Python applications, if for some reason you find yourself in a situation (like silverlight) where distributing the CPython implementation with your application is not appropriate.
Will applications written in IronPython/IronRuby be so specific to the .NET environment, that they will essentially become platform specific?
IronRuby currently ships with most of the core ruby standard library, and support for ruby gems.
This means that it will support pretty much any native ruby app that doesn't rely on C extensions.
The flipside is that it will be possible to write native ruby apps in IronRuby that don't rely on the CLR, and those will be portable to MRI.
Whether or not people choose to create or use extensions for their apps using the CLR is the same question as to whether people create or use C extensions for MRI - one is no more portable than the other.
There is a side-question of "because it is so much easier to create IronRuby extensions in C# than it is to create CRuby extensions in C, will people create extensions where they should be sticking to native ruby code?", but that's entirely subjective.
On the whole though, I think anything that makes creating extensions easier is a big win.
If they don't use any of the .NET features, then what is the advantage of IronPython/IronRuby over their non .NET counterparts?
Performance: IronRuby is already faster for the most part than MRI 1.8, and isn't far off MRI 1.9, and things will only improve in future. I think python is similar in this respect.
Deployment: As people have mentioned, running a native ruby cross-platform rails app inside IIS is an attractive proposition to some windows-based developers, as it lets them better integrate with existing servers/management infrastructure/etc
Stability: While MRI 1.9 is much better than 1.8 was, I don't think anyone could disagree that CLR has a much better garbage collector and base runtime than C ruby does.
IronPython/IronRuby are built to work on the .net virtual machine, so they are as you say essentially platform specific.
Apparently they are compatible with Python and Ruby as long as you don't use any of the .net framework in your programs.
If you create a library or framework, people can use it on .NET with their .NET code. That's pretty cool for them, and for you!
When developing an application, if you use .NET's facilities with abandon then you lose "cross-platformity", which is not always an issue.
If you wrap these uses with an internal API, you can replace the .NET implementations later with pure-Python, wrapped C (for CPython), or Java (for Jython) later.
According to the Mono page, IronPython is compatible with Mono's implementation of the .Net runtime, so executables should work both on Windows and Linux.
You answer your first question with the second one, if you don't use anything from .Net only the original libs provided by the implementation of the language, you could interpret your *.py or *.rb file with another implementation and it should work.
The advantage would be if your a .Net shop you usually take care of having the right framework installed on client machine etc... well if you want python or ruby code, you now need to support another "framework" need to distribute install, take care of version problem etc... So there 2 advantages, using .Net framework power inside another language + keep the distribution/maintenance as simple as possible.
It would be cool to run Rails/Django under IIS rather then Apache/Mongrel type solutions
© 2022 - 2024 — McMap. All rights reserved.
