Ted Leung on the air: Open Source, Java, Python, and ...
The IronPython and JRuby announcements have been making the rounds in the blogosphere. and of course I want to add my 2c.
I think that these announcements are very significant and should be welcomed by people in both the Python and Ruby communities, because I believe that Microsoft and Sun's support of these languages will make it much easier to persuade people to look at Python and Ruby. Today people's biases are still against dynamic languages as whole, as opposed to particular languages, so I think that getting "corporate legitimacy" for either Ruby or Python helps both.
IronPython is already faster than CPython, and JRuby appears to be headed in a similar direction, although we won't actually know until JRuby beats one of the C-based VM's. There is a huge amount of effort being expended on the performance of the JVM and CLR implementations, and if that effort starts to benefit Ruby and Python users, then think that is a good thing too.
I've read some postings speculating on Microsoft and Sun anointing either Python or Ruby over the other, and/or over all other dynamic languages. I don't believe that this is the case. At OSCON in 2003, I attended a BOF organized by Microsoft people who were interested in improving support for dynamic languages on the CLR. If I recall, many of the "major" dynamic languages were represented. Also I know that Microsoft has been talking to folks like John Lam and others who are working on getting Ruby onto the CLR. As for Sun, JSR-223 is aimed at all scripting languages, Sun accepted a JSR for Groovy, and Tim Bray (who helped the JRuby thing get done) also helped organize a meeting at Sun for lots of dynamic language folks. I think that in part, IronPython and JRuby got picked up because the people involved were willing to work with the companies involved.
Other commentary has focused on whether or not Sun or Microsoft is ahead of/behind the other in this area. I suppose this makes sense if you are a partisan of one language over another. It's probably more true if you look at Python, since IronPython's baseline for comparisons is Python 2.3, while Jython is still catching up to Python 2.2. Overall, I think that we are still early in this game, and that neither side has an insurmountable lead over the other. If you look at the pace of VM support, I think that it's not so one-sided. Yes, Microsoft has been at this longer, but they also seem to have a longer cycle time to pick stuff up, since the pace of CLR improvements is gated by releases of Windows. Yes, you can download new versions of the CLR, but that makes deployment a harder deal. Sun still has to get its extensions specified, much less implemented in the JVM, and the cycles on the JVM are also long, but I also think that the window for broad adoption of dynamic languages still has not arrived, so both companies still have time, which also blunts the potential advantage of being first.
I'm happy to see all this going on, but the CLR stuff is far away from me, since my primary platform doesn't really have good CLR support. There's Mono, but it doesn't seem to be getting much uptake on OS X. I am basing this on the amount of buzz and/or actual Mac apps being developed on Mono, not on actual statistics, and I am sure that Miguel will be quick to disprove me with facts... I can at least see a world where I might use something like JRuby or Jython, since I have done a bunch of Java in previous lives.
These announcements also create some interesting points for observation. Here are some things that I am going to be keeping an eye on as these projects march forward:
- Community building around the implementation - I will feel most comfortable if these language implementations are community driven, and not vendor driven. I know from listing to Jim at PyCons that this is a goal, and the JRuby guys have been very clear about this as well. The recent buzz about these two projects gives them that PR bump that might allow them to draw more people into their communities. It will be interesting to see if they can convert attention into participation
- Compatibility - Both Ruby and Python are "open source" languages. By that, I mean that cross platform compatibility has been accomplished by having a single reference language implementation. It will be interesting to see if the JVM and CLR dialects are able to achieve a decent compatibility story or whether they end up essentially forking (or if you are suspicious, embracing and extending) the languages. One possibility is that we end up with some kind of standardization in order to keep this from happening. Of course, standardization doesn't mean compatibility - just look at the situation with Javascript 1.7, where you have a standard, but you have significant uncertainty about whether all browser vendors will implement it, thus reducing its usefulness.
- Performance - The IronPython team has shown that they can beat the performance of CPython. The JRuby folks have yet to do that, and both the Python and Ruby communities have higher performance VM implementations underway. This situation reminds me a lot of the situation with x86, Alpha, Sparc, and PowerPC, where you had different architectural approaches which were supposed to produce performance benefits. But in the end, large amounts of money, process technology and non-architectural considerations produced an outcome that was different that what you might have expected by just analyzing the processor architectures.
- Velocity - Having people who are working full time on these implementations is going to make a difference in the velocity of these projects. The question is how much, and at what expense versus creating a sustainable community?
- Tooling - Much has been made about the JRuby folks being chartered to work on tooling in someway. There's been speculation about NetBeans versus Eclipse, and there are also other Ruby IDE's. I haven't heard much about tooling on the CLR side, but it seems plausible that you could see Visual Studio support for IronPython and/or one of the CLR Ruby's should people at Microsoft decide it was worthwhile.
In the end, I think that having languages like Python and Ruby be "legitimized" by the recognition of big industry players, makes easier it is for me. It gives me one more argument to use when talking to people, which I hope reduces the amount of time I have to spend trying to convince people of the merits. That leaves me more time to work in a language that I like. Then again, we have Erlang, Scala, and Io just around the corner...
IronPython 1.0 baseline is CPython 2.4.3, not CPython 2.3, as you can see here:
<a href="http://www.codeplex.com/Wiki/View.aspx?ProjectName=IronPython&title=Differences">http://www.codeplex.com/Wiki/View.aspx?ProjectName=IronPython&title=Differences</a>
IronPython 1.0 also implements a couple CPython 2.5 features like conditional expressions.
Also, you can set breakpoint and step into IronPython code in Visual Studio debugger, right now, and Jim even demoed this couple of times. All with mixed stacks as in C# calling IronPython calling C#. Unfortunately Mono's debugger is not advanced enough to support this.
Posted by Seo Sanghyeon at Mon Sep 11 00:06:32 2006
Posted by dado1945 at Mon Sep 11 04:49:02 2006
but my biggest "problem" with them is the libraries.
(i work with python)
for me, python is not just the language. it's also it's libraries. now let's say i migrate to IronPython. are those libraries available? no, they're not. well, some of them (which are in pure python) are, but the rest (which are in C) are not. so basically the whole library as such, is not available. (at least this was the case some time ago, please correct me if i'm wrong)
(i assume it's the same with JRuby)
or, to turn around the question:
let's say i develop with IronPython. and i have to use a http-library let's say. now, will i use the python one or the .NET one?
also, many people think about IronPython as a way to access .NET from python.
and that's fine.
but then your application is not a "clean" python application anymore. now i cannot just download your program and run it with cpython.
Posted by Gábor Farkas at Mon Sep 11 07:04:37 2006
"We continue to make significant progress on the IronPython web sites/projects and other enhancements."
See http://msdn.microsoft.com/vstudio/extend/
Posted by Brian Lyttle at Mon Sep 11 09:34:17 2006
Posted by Kevin at Mon Sep 11 12:18:35 2006
I have to wonder if they can really "get there from here" with this stuff.
In the end, they still lack the basic live code development environment I'm addicted to and I can't really take them too seriously.
Posted by Todd Blanchard at Mon Sep 11 16:44:12 2006
Thanks for the corrections.
Gabor,
Yes, it's true that the libraries are different, and that cuts in both directions, since the relative quality of libraries between the C VM's and the CLR/JVM is subject to debate.
The point is not that we'll have complete portability between the JVM/CLR versions and the C versions. The point is getting people to take the languages seriously in the first place. Also, I've seen C libraries which didn't build on my default platform (OS X) which I then had to hack. So the existence of C libraries doesn't guarantee portability either.
Kevin,
It also doesn't come with any of the Javascript 1.7 stuff
Todd,
I don't necessarily believe that these implementations will be best of class. I do believe that they will help those of us trying to get these languages and languages like them into the doors of our employers, clients, and so forth.
Posted by Ted Leung at Mon Sep 11 21:47:00 2006
I just can't wait for a better windows text editor (I still haven't gotten used to emacs). Right now I use ScITE.
Thanks for the interesting article.
Posted by Jared Nuzzolillo at Wed Sep 13 09:10:36 2006
To insert a URI, just type it -- no need to write an anchor tag.
Allowable html tags are:
<a href>
, <em>
, <i>
, <b>
, <blockquote>
, <br/>
, <p>
, <code>
, <pre>
, <cite>
, <sub>
and <sup>
.You can also use some Wiki style:
URI => [uri title]
<em> => _emphasized text_
<b> => *bold text*
Ordered list => consecutive lines starting spaces and an asterisk