IronPython 1.0 is Born 285
dougblank writes "IronPython version 1.0 was just released after 3 years of development. Jim Hugunin, the creator of Jython and the lead developer of the Shared Source IronPython, made the birth announcement earlier this week. From the announcement: 'I wanted to understand how Microsoft could have screwed up so badly that the CLR was a worse platform for dynamic languages than the JVM... I found that Python could run extremely well on the CLR — in many cases noticeably faster than the C-based implementation. [...] Shipping IronPython 1.0 isn't the end of the road, but rather the beginning. Not only will we continue to drive IronPython forward but we're also looking at the bigger picture to make all dynamic languages deeply integrated with the .NET platform and with technologies and products built on top of it. I'm excited about how far we've come, but even more excited by what the future holds!'"
Yes, but.... (Score:5, Interesting)
Re: (Score:3, Informative)
Is it as easy to learn as [Microsoft's] Visual Basic?
Can it be used to create GUIs, add [business] logic to these GUIs as easily as VB?
Re: (Score:2, Insightful)
Re:Yes, but.... (Score:5, Informative)
No, it is not as easy for non-programmers.
Can it be used to create guis...? Yes it can. At some point it could be made as easy as it is in VB.net; if I were on the development team then that would not be high on my priority list. Leave the toy languages for interactive GUI prototyping, and leave IronPython for code-driven development. However, that's just me and other people have different itches they want scratched.
I see IronPython as a very valuable development and it will make interacting with standard Microsoft-only developers on windows much easier since I will now be able to use a language I like while maintaining 100% compatability and interoperability.
Re: (Score:3, Insightful)
Re: (Score:3, Informative)
Boo is not Python, but rather a middle ground between C# and Python. It is an easy to learn statically typed functional language with a Python inspired syntax.
Re:Yes, but.... (Score:5, Informative)
Re: (Score:3, Informative)
http://www.voidspace.org.uk/python/weblog/arch_d7
Re: (Score:2, Insightful)
He asked if it was as easy to learn as Visual BASIC, implying that Visual BASIC is easy to learn. He didn't say "Is as good an idea to learn as VN" or "Is ideologically sound as a beginners programming language."
Maybe if you took your monocle off before reading what's on your screen, you'd be a little less shocked when you do read it, and so would lose it less often.
Re: (Score:2)
Whats that about reading the screen?
Re: (Score:2, Informative)
Re:Yes, but.... (Score:5, Interesting)
I really wish MS just let VB die with VB 6, it would have been for the best. The VB 6 fans could have continued with VB 6 until they learned a real programming language and real programming techniques.
I agree. I think Python is a good language and most importantly it is cross-platform. Why would someone want to kill Python by making it MS-Only? As far as getting this IronPython on Mono, I don't see it happening. I use Mono and it is pretty nice. Mono has
Even though the MS-PR-machine says
Re: (Score:2)
Re: (Score:3, Insightful)
There are practically no serious semantic differences between C# and VB.Net. You can often get away with converting code from one to another by replacing curly braces with If .. End If, and similar changes.
This is not to say there is any point whatsoever in existence of VB.Net when there is C#. It's essentially the same language with slightly uglier (but some
Re: (Score:3, Funny)
Yes, but VB programmers are
oh, and C# programmers who think that they are the only ones who can write 'clean', maintainable, wonderfully object oriented code.
Re: (Score:3, Insightful)
I actually find the multi-language of of the CLR to be a negative. I work at a fortune 500 and most of us use C# and/or Java. There are a few groups of "programmers" that have always been VB-only/ASP-Only "programmers". ...
Surely this is a corporate policy problem and not a technology problem. There is no way to make a virtual machine that will only run one language. Even if you totally optimize it for a single language, someone can implement another language in that language. So you might as well make i
Re: (Score:3, Insightful)
However, once cannot expect to write something in IronPython and have it run in regular (CPython). Most of the other Python forks/implementations just tweak Python to make it faster or work better for certain things. So they still run your regular Python code.
According to Jim, the creator of IronPython: "To drive our Python compatibility, we run a large portion of the standard Python regression test suite in addition to a large custom test suite we added that runs IronPython and CPython side-by-side to t
Re: (Score:3, Interesting)
Yes, indeed, it provides a "very Windows-like look and feel"; unfortunately, it does so on every platform, including Linux and Macintosh.
What Java doesn't do is support/follow well conventions about menus, shortcuts, keyboard layout, preference files, drag-and-drop, window management, device access, scripting language access, desktop search integration, and a
Re:Yes, but.... (Score:4, Insightful)
This kind of comparison, it seems to me, invites comparing apples and oranges.
The Visual Basic language has certain irregularities and peculiarities, but MOSTLY the issue with it is that it is very primitive. As such, you can certainly learn elementary programming concepts with it without suffering permanent brain damage; you just don't get the benefits of learning to think "in the large" the way you do with a more expressive language.
However the language is only 1/3 of the three distinct items that make up the whole package: the language, the runtime system and the IDE. A lot of stuff you "do" in VB is actually done by libraries written in C++.
When most people thinking about "learning" a system like VB have in mind is learning how to accomplish specific tasks. For those tasks that are well supported by the runtime system and the IDE, VB is highly productive. We're talking common business tasks that can be supported by bolting together VB controls and some ActiveXs with a few event handlers. The useful scope of such applications is very wide indeed.
However, if you're trying to do something that doesn't fall into that range of tasks, the primitive nature of the VB language is a dreadful hobble.
WRT brain damaging effects of VB, I'd say this: very few people in this world are cut out to be programmers. For some people it's almost natural thing. For others it is a latent talent that can be trained. But most people, regardless of their intelligence, dilligence and personal virtue, could only be trained to the level of mediocrity, at least with the ways we know how to teach. Many would not even reach the level of mediocrity.
VB's runtime system and IDE can mask that. Sit two people down. The first is a reaonably intelligent person who has been trained in VB, the other is a gifted programmer who has to work with vim, the language of your choice, and a GUI toolkit. Give them a common business data entry problem to solve, and they both end up with something that works in a reasonable time. Task them with creating a program which finds economically optimal air travel itineraries using various data sources and meeting certain user defined criteria, and the first guy is out of his depth.
I call myself out (Score:5, Insightful)
My apologies for making a trollish post. I was in a pissy mood earlier, firing from the hip, and should have thought my words more carefully. I completely agree with you, actually, regarding your point to the following:
A lot of people I went to school with couldn't get it. It may have been that the people who didn't get it were the ones that I met in the Information Systems classes (which, where I went to school, was a concentration on a Business Major, where they taught VB as the intro language) were those that were not cut out to be programmers in the first place, thus affecting my perception of languages causing dain bramage.
Anyway, I still don't like VB, but, at least you made me consider my words and thought processes. Apologies to the community at large for being a dick.
Re: (Score:2)
Re: (Score:3, Interesting)
I don't know what "primitive" is really supposed to mean here. If it means simple, I would say that a language can both be simple and flexible (e.g. Scheme and Smalltalk are). But I do find that irregularities in a language are generally a Bad Thing: they may seem acceptable or even convenient while the language is being used for simple tasks in a small domain, but once the s
Re:Yes, but.... (Score:5, Informative)
IronPython on Mono howto [google.com]
About speed. (Score:5, Informative)
Actually, that's not really something to be proud about (though I'm not downplaying the huge achievement of running python on the CLR). The C implementation of Python is not very optimised, and that's why projects like PyPy or psyco are trying to speed Python up (and succeeding very well). I've had CPU-intensive scripts (such as SortSize [poromenos.org]) run tens of times faster with psyco, by just adding a line of code to my script.
Re:About speed. (Score:5, Interesting)
Was that Pyrex or Pie Pants? (Score:2)
No... wait. I meant Pie Pants [snpp.com].
platform-independent. (Score:3, Insightful)
Re: (Score:2)
Link is unreadable! Jeez! (Score:5, Informative)
Jim Hugunin Jim.Hugunin at microsoft.com
Tue Sep 5 13:27:12 PDT 2006
* Previous message: [IronPython] ipy support in msxsl:script blocks
* Next message: [IronPython] [ANN] IronPython 1.0 released today!
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
I'm extremely happy to announce that we have released IronPython 1.0 today!
http://www.codeplex.com/IronPython [codeplex.com]
I started work on IronPython almost 3 years ago. My initial motivation for the project was to understand all of the reports that I read on the web claiming that the Common Language Runtime (CLR) was a terrible platform for Python and other dynamic languages. I was surprised to read these reports because I knew that the JVM was an acceptable platform for these languages. About 9 years ago I'd built an implementation of Python that ran on the JVM originally called JPython and later shortened to Jython. This implementation ran a little slower than the native C-based implementation of Python (CPython), but it was easily fast enough and stable enough for production use - testified to by the large number of Java projects that incorporate Jython today.
I wanted to understand how Microsoft could have screwed up so badly that the CLR was a worse platform for dynamic languages than the JVM. My plan was to take a couple of weeks to build a prototype implementation of Python on the CLR and then to use that work to write a short pithy article called, "Why the CLR is a terrible platform for dynamic languages". My plans quickly changed as I worked on the prototype, because I found that Python could run extremely well on the CLR - in many cases noticeably faster than the C-based implementation. For the standard pystone benchmark, IronPython on the CLR was about 1.7x faster than the C-based implementation.
The more time I spent working on IronPython and with the CLR, the more excited I became about its potential to finally deliver on the vision of a single common platform for a broad range of languages. At that same time, I was invited to come out to Microsoft to present IronPython and to talk with members of the CLR team about technical issues that I was running into. I had a great time that day working through these issues with a group of really smart people who all had a deep understanding of virtual machines and language implementation. After much reflection, I decided to join the CLR team at Microsoft where I could work with the platform to make it an even better target for dynamic languages and be able to have interesting technical discussions like that every day.
The first few months at Microsoft were a challenge as I learned what was involved in working at a large company. However, once the initial hurdle was over I started experiencing the things that motivated me to come here in the first place. The team working on dynamic languages in general and IronPython in particular began to grow and I got to have those great technical discussions again about both how to make IronPython as good as it could be and how to make the CLR an even better platform. We began to take advantage of the great new features for dynamic languages already shipping in
We were also able to release IronPython publicly from Microsoft with a BSD-style license. In the agile spirit of the project, we put out a new release of IronPython once every three weeks (on average) over the course of the project. This helped us connect well with our daring early adopters and receive and incorporate their feedback to make IronPython better. We've had countless excellent discussions on the mailing list on everything from supporting value types to calling over
Or, if you're using Opera... (Score:2)
Re: (Score:2, Funny)
Re:Link is unreadable! Jeez! (Score:4, Funny)
Summary is confusing... (Score:5, Funny)
Signed, IronConfused
Hmmm (Score:2, Interesting)
Funny enough, I haven't yet found one of these cases...
Re: (Score:2, Insightful)
OB Black Sabbath (Score:5, Funny)
Duh, duh, duh duh duh.
Snakes... (Score:4, Funny)
Re: (Score:2, Funny)
Re:Snakes... (Score:5, Funny)
Re:Snakes... (Score:5, Funny)
Dealing with UI (Score:4, Interesting)
So, if I'm using Iron Python under .NET, would I use be compelled to use WinForms at that point or would libraries like wxPython still be available?
Re: (Score:2)
http://wxnet.sourceforge.net/ [sourceforge.net]
Re: (Score:2)
Re: (Score:3, Informative)
It would be interesting to see how similar wxPython is to wx.NET with Python.
Re: (Score:2)
Re: (Score:2)
Sort of "I want my cake and eat it too." It'd be nice to get all of .NET's framework libraries (insomuch as they are available in Mono), and to get the nice native-looking apps wx gives you on Windows and Linux (I'm not a huge fan of GTK+ on Windows, they never seem "native" but maybe that's just the apps I've run into and I'm sure that makes me lame, but whatever) -- this post isn't meant to debate the virtues of GTK, the parent was jus
Bad article summary... (Score:3, Informative)
If you read the whole comment, you will see that in fact, the CLR implementation does very well, the designer is now at MS working on the CLR, and all in all, IronPython is a decent Python implementation.
Given this work and the F# compiler work http://research.microsoft.com/fsharp/fsharp.aspx [microsoft.com], I think CLR is done quite well as a language independent platform. Also, given the excellent work of the Mono and Portable
Hrm (Score:5, Interesting)
Well, the links to the FAQ don't seem to work thanks to some kind of site move (I am asked to download the HTML instead of view it and ... well ... am too lazy tonight). But a few thoughts based on what is already there:
I guess I just don't get it.
Re: (Score:3, Interesting)
The question is does ironpython run on mono.
Re: (Score:3, Informative)
Re: (Score:2)
Please god no.
There seems to be an army of people dedicated to ensuring that we never actually see the benefits of faster hardware. We're throwing more crap layers of software on our machines faster than the CPU speeds can increase.
All hail James Gosling!
James Gosling is the person I curse at when I visit a
Re: (Score:3, Insightful)
> like Psyco can give pretty big speedups (say 10 to 100 according to their website).
> It seems fundamentally impossible to make a language like Python or Ruby fast.
fast or slow are relative and somewhat meaningless terms.
I use python to transform tens of millions of rows of data every day in the running of a data warehouse. C would be faster for most of these processes, bu
Re: (Score:2)
Re:Hrm (Score:4, Informative)
Yes, you can, though not all builtins are available. All you need is this line in IronPython\Lib\site.py:
import syssys.path.append(r"E:\python24\lib")
As for the rest of your comment: You do realize, that there are Python programmers on Windows ? I enjoy happily the ActivePython distribution, with which I can even automate my deskopt/applications. Now, in addition, I have full access to the
I consider this to be one of the best software-relases within the last few months.
Re:Hrm (Score:5, Informative)
Consider the way every object can implement a fallback method that is called if somebody invokes "foo.bar" and bar does not exist in foo. It implies that every single method invocation must be identified by string not a number, and matched by string comparison.
It doesn't imply that at all. Smalltalk implementations figured out how to make that fast decades ago. The initial, most obvious, step is to hash method selectors so the lookups are done with numbers and to create a hashtable (either per-class, or global, with a sparse structure) for looking up method addresses given method selectors. There are a few optimizations that can be applied to make that pretty fast -- on the order of two or three times slower than C++-style vtable lookups. Next, many dynamic language implementations take advantage of the fact that nearly all method invocations are static -- the same line of code always calls the same method on objects of the same class, so there's no real reason to do any lookup at all. Such systems statically or dynamically rewrite the code, turning it into a simple test that the target object is of the "right" type, and then jumping directly to the method. Further, most method invocations can be proven at compile time (or at run-time, whichever is more convenient) to always go to the same target class, so even the object type test can be optimized away. Oh, and if it makes sense they can inline the method as well.
That's just the little that I've read about, too. This stuff has been heavily researched by very smart people for a very long time now. The net effect is that lots of dynamic language implementations approach C code in performance, on average, and there are situations in which they can produce code that is even faster than a C compiler could, because they can make use of run-time information which is unavailable to any compiler that translates to "static" machine code.
Python implementations may need work to make them faster, but there's nothing that says the language has to be slow.
Re:Hrm (Score:4, Informative)
And if you want speed, I have two words: Boost.Python [boost.org]. It makes wrapping C++ code into Python near-trivial; I just wish they had some sort of quick-start documentation. I was intimidated by Boost.Python until I sat down to work with it. Sample (cleaned up) fragment from production code:That little snippet exposes the Loader class to Python. Boost will take care of wrapping the code up into a Python shared library (.pyd), exposing the interface, converting between standard Python types and STL types, even converting C++ exceptions to Python exceptions.
And if you don't want to go there, you could also use ctypes (part of the std Python distribution) and drive any win32 DLL using Python, unchanged.
Re: (Score:3, Informative)
Re: (Score:3, Interesting)
This is huge.... (Score:3, Interesting)
Re: (Score:2)
Of course, you may have meant Perl 6, the primary thing targeting Parrot, but they are quite distinct terms
Re: (Score:2)
Just call it... (Score:2)
Parrot (Score:2, Interesting)
Re:Parrot (Score:4, Informative)
2. The CLR is optimized for static languages, but not innefficient for dynamic ones. In fact, that's all the article is about.
3. RTFA!
Re: (Score:2)
Mimsy were the borogoves (Score:5, Insightful)
IronPython screencast (Score:4, Informative)
Visual Studio? (Score:3, Interesting)
Re:Visual Studio? (Score:4, Informative)
IronPython Needs a Lawyer To Fix the License... (Score:2)
Typical Slashdot... (Score:4, Informative)
The whole (and far less baiting) summary:
I started work on IronPython almost 3 years ago. My initial motivation for the project was to understand all of the reports that I read on the web claiming that the Common Language Runtime (CLR) was a terrible platform for Python and other dynamic languages. I was surprised to read these reports because I knew that the JVM was an acceptable platform for these languages. About 9 years ago I'd built an implementation of Python that ran on the JVM originally called JPython and later shortened to Jython. This implementation ran a little slower than the native C-based implementation of Python (CPython), but it was easily fast enough and stable enough for production use - testified to by the large number of Java projects that incorporate Jython today.
I wanted to understand how Microsoft could have screwed up so badly that the CLR was a worse platform for dynamic languages than the JVM. My plan was to take a couple of weeks to build a prototype implementation of Python on the CLR and then to use that work to write a short pithy article called, "Why the CLR is a terrible platform for dynamic languages". My plans quickly changed as I worked on the prototype, because I found that Python could run extremely well on the CLR - in many cases noticeably faster than the C-based implementation. For the standard pystone benchmark, IronPython on the CLR was about 1.7x faster than the C-based implementation.
The more time I spent working on IronPython and with the CLR, the more excited I became about its potential to finally deliver on the vision of a single common platform for a broad range of languages. At that same time, I was invited to come out to Microsoft to present IronPython and to talk with members of the CLR team about technical issues that I was running into. I had a great time that day working through these issues with a group of really smart people who all had a deep understanding of virtual machines and language implementation. After much reflection, I decided to join the CLR team at Microsoft where I could work with the platform to make it an even better target for dynamic languages and be able to have interesting technical discussions like that every day.
The first few months at Microsoft were a challenge as I learned what was involved in working at a large company. However, once the initial hurdle was over I started experiencing the things that motivated me to come here in the first place. The team working on dynamic languages in general and IronPython in particular began to grow and I got to have those great technical discussions again about both how to make IronPython as good as it could be and how to make the CLR an even better platform. We began to take advantage of the great new features for dynamic languages already shipping in
We were also able to release IronPython publicly from Microsoft with a BSD-style license. In the agile spirit of the project, we put out a new release of IronPython once every three weeks (on average) over the course of the project. This helped us connect well with our daring early adopters and receive and incorporate their feedback to make IronPython better. We've had countless excellent discussions on the mailing list on everything from supporting value types to calling overloaded methods. Without the drive and input of our users, IronPython would be a much weaker project.
IronPython is about bringing together two worlds. The key value in IronPython is that it is both a true implementation of Python and is seamlessly integrated with the
cheers to the IP team (Score:4, Informative)
They've been very helpful on the mailing list, checking in any bugs/differences to CPython behaviour and getting it sorted and into builds available for use.
Obligatory (Score:2, Funny)
Global interpreter Lock? (Score:2, Insightful)
IronPython, and new Ruby VM! In my pending article (Score:2)
Boo language is a much better alternative! (Score:2, Interesting)
Also it doesn't use much of the niceties available through the
If you like Python syntax and want to try
It is amazing!! => "while using a Python-inspired syntax and a special focus on language and compiler extensibility. Some features of note include type inferen
Does the world need more children (Score:4, Insightful)
Re:Sometimes I feel like a Luddite... (Score:4, Informative)
Besides, if it gets to the point where Microsoft is officially supporting it, it would be a major addition to the
Re: (Score:2, Insightful)
Python is a great scripting language, but to compare it to Java is really useless.
If you hired someone in your machine shop and they brought their trusty hammer and said "This is all I need", or "I don't like that big piece of equipment over there--it takes too long to drive in a nail, my hammer does it much quicker" you
Re: (Score:3, Interesting)
Oddly enough, I just finished a 3.5 year project very much like what you described, a
Re: (Score:3, Informative)
1. There were around 25 people working on our product, with people spread around the province (not state
2. We used UML and well-defined interfaces in the form
Re: (Score:3, Informative)
Re: (Score:2)
Re: (Score:2, Insightful)
Right. Now hand over your geek badge. Someone will be right down to escort you out.
Re:Sometimes I feel like a Luddite... (Score:5, Informative)
I think IronPython compiles down to CLR bytecode, so if you're shipping managed C#, you could just as well ship IronPython and nobody would notice, which is the entire point of this article in the first place.
However, whether or not you could benefit from learning Python is a decision only you can make. Python may increase your productivity 2-3x over C# or more (and that's fairly conservative, usually), but only after you learn it, which could be months.
However, if you end up always choosing the short-term expedient answer of sticking with the language you know (and the environment you know), you lose out on any productivity gain you might get from another environment or language; this is a general point, not one specific to this case.
In general, the "common environments" (Java,
Again, I'm not trying to push you, just point out that for the costs there are benefits, too. I say what I'm saying because I believe (and see) too many developers trapping themselves in local maxima by always making the short-term decision. Ultimately, it's no skin off my nose.
You can, but the lack of namespacing starts to get troublesome as you start trying to build libraries, or use the libraries of others. Later versions of Javascript, which JScript will presumably track, will help with this a lot. Although based on what I see, it's nearly learning a new language anyhow. (In fact, the next version of Javascript [mozilla.org] borrows a lot from Python; generators are basically from Python, array comprehensions are from Haskell IIRC but the syntax is the Python one, and the most main-stream language with de-structuring assignment is Python.)
Re: (Score:3, Informative)
All of the existing ones suck. (Score:2)
Re:Faster than C? (Score:5, Informative)
Re: (Score:3, Funny)
Comment removed (Score:4, Insightful)
Re: (Score:3, Interesting)
6. That the patent rights, if any, granted in this license only apply to the Software, not to any derivative works you make.
So, being that there's nothing mentioned in the license that specifically grants any patent rights, aside from:
You may use the Software for any commercial or noncommercial purpose, including distributing derivative works.
...so, basically, if you use the software to make a derivative work
Re: (Score:2)
(at least not expressly),
so I'm not sure whether the problems are unique
to this license.
But yes, if there are patents on Iron Python, then
anyone downstream of Microsoft wouldn't be able
to distribute a patched version unless they also
removed anything covered by patents, as I understand
it.
Although you are right that the "including derived
works" language could possibly contradict the patent clause.
Not sure what this all means, but the license raised
my eyebro
Re: (Score:2, Insightful)
Huh? No it is not. The "Shared" source license is not the CPL license, if it were, it would be called ... the CPL license! Read the FAQ at the bottome of the license [codeplex.com] page for IronPython.
Re: (Score:2)
Re: (Score:3, Insightful)
I *AM* a VB6 developer (Score:2, Insightful)
And these days, I wouldn't go back for any reason. VB6 was quick-and-dirty nice. But the language was gimped. 32KB limits for arrays of types? Guh. Ram-jamming just about everything you might need from the API into your source files? At least C/C++ let you #include it, and most API functions end up with a wrapper in
I really liked VB5 and VB6. They were great tools. I wrote a MUD in VB6, and a
Re: (Score:3, Insightful)
Awesome. Slashdot has just lost it.
Re: (Score:2)
Apparently a troll moderator modded the parent post down to 0, currently.
Re: (Score:2)
You're thinking of Turbo Pascal... (Score:2)