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!'"
Finally! (Score:1, Insightful)
Re:Yes, but.... (Score:2, Insightful)
Re:Finally! (Score:1, Insightful)
Also think of it this way: Microsoft doesnt make any money if its programming partners for the Windows platform dont make money. Microsoft has a vested interest in making you happy. In most cases, OSS developers dont care if you use their product or not, or even if it helps you to be successful. After all, they are doing it to "scratch their itch". Microsoft has had an excellent reputation for backward API compatibility (better than any other software vendor on the planet). Microsoft wants you to keep using their API's because it ties you to their platform.
BTW, I don't know why you are mentioning
Does the world need more children (Score:4, Insightful)
Re:Yes, but.... (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.
Mimsy were the borogoves (Score:5, Insightful)
Comment removed (Score:4, Insightful)
Re:Hrm (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, but not all - since python's io speed is the same as C's and these are io-heavy applications. But i'll trade a lot of that speed for the advantages in maintainability & speed of development that I get with python.
Likewise, small scripts that we use for monitoring disk space, monitoring processing queues, checking for data quality issues, etc - are fine in python. C would be faster, but probably only 5% most of the time. So, who cares about the difference between 1.0 second and 0.95 seconds?
And if I felt like writing a small gui on a windows box I'd prefer to work with python over
Re:Sometimes I feel like a Luddite... (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'd conclude that their experience, although possibly extensive in roofing, mining and fence repairs, may not apply to machining airplane wings or automobile repair.
I've got a good deal of experience in quite a few languages and can tell you that Python, VB, C, C#, Java, etc are all "the most appropriate solution" for one solution or another. To not acknowledge such is really only showing a lack of experience in some area of programming.
A new programmer trying to use Java to build a small desktop app is kind of silly, he should probably use VB (He won't be able to build a gui faster with any other tool). If it's going to be a web GUI requiring DB access, try Ruby on Rails.
A web programmer maintiaing some simple sites should probably be acquanted with Ruby, Perl, PHP, Javascript and a few document formats. He's not going to get anything from Java unless he needs custom controls for his Javascript pages.
However, if your task is implementing a large, distributed client/server app involving tens of thousands of classes coded by dozens of people, reliable object transfer/messaging, reliable easy access to various forms of communications (Sockets, etc), the ability to run on Unix, coordination of multiple groups in many locations, etc.. and you want to be able to maintin it for a few years, your only rational choice is Java. (Heck, even without the "Unix" clause I think Java is by far the best choice, although then C# is a competitor).
platform-independent. (Score:3, Insightful)
Re:Hmmm (Score:2, Insightful)
Re:Sometimes I feel like a Luddite... (Score:2, Insightful)
Right. Now hand over your geek badge. Someone will be right down to escort you out.
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.
Re:Finally! (Score:2, Insightful)
eh? I would think that the majority of developers want something more GPL-like since 75%+ of all open source software uses a GPL license.
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.
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 small RPG. but they're old. They're creaky. They're limited, and they're dying.
Global interpreter Lock? (Score:2, Insightful)
Re:Yes, but.... (Score:3, Insightful)
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 rather say readable *shrugs*) syntax, nothing more, nothing less. As such, it is not of much practical use. It is not the spawn of evil you tried to present it either, though.
Re:Finally! (Score:3, Insightful)
Re:Finally! (Score:2, Insightful)
Perhaps people who disagree with me might actually like to challenge facts rather than abuse their mod points?
How can stating established issues (known to any developer who has been working with Microsoft tools, good though some of those tools have been - nothing I have said here is controversial) be "Trolling" - some strange new Slashdot definition of the term?
Re:Yes, but.... (Score:2, Insightful)
Most of that "design" and "thought" was "how did Sun do it with Java". And they still borked it up with the explicit override, virtual, and new keywords for methods. What's the point of an OO language's polymorphism if you have to go back and change the super classes in a third party library if you need to override a method? (And yes, I'm aware that C++ follows the same paradigm - who said they were right?)
Re:Yes, but.... (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 it work well for multiple languages.
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?
How does adding a port of Python to .NET make Python "MS-Only." Development continues on at least three other Python impementations for different runtimes. It's like saying that the existence of Visual C++ makes C++ MS-Only. It increases, not decreases the scope of Python.
As far as getting this IronPython on Mono, I don't see it happening. I use Mono and it is pretty nice. Mono has .Net 1.1 complete and .Net 2.0 is pretty much there now too. I just don't see IronPython ever getting enough development behind it to get a port to Mono, especially with a "shared" source license.
Would you please stop talking out of your ass? IronPython does not need to be "ported" to Mono. Mono adheres to the ECMA CLR spec. IronPython adheres to the ECMA CLR spec. Any divergence is a bug. Most beta versions of IronPython do run on most beta versions of Mono and any incompatibility between the two in the final release versions will be considered a bug by one of the parties involved.
Furthermore, the IronPython license is very liberal. What aspect of it would prevent a port to Mono?
Re:Finally! (Score:3, Insightful)
Awesome. Slashdot has just lost it.
Re:Yes, but.... (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 test for identical behavior whenever possible. Despite all of this work, there will still be differences between IronPython 1.0 and CPython. The most obvious difference is that IronPython is missing a number of standard C-based extension modules so things like "import bsddb" will fail. We maintain a detailed list of differences between the two implementations and aim to reduce the size of this list in every release."
None of the implementations of Python run every C-based extension module that pure Python does. But IronPython is already more compatible with CPython than Jython is.
If you write some IronPython stuff with with .Net using WinForms, well you just killed one of the best features of Python, cross-platform execution.
Well, "duh." But who has a gun to your head telling you to do that? Just pick up a standard Python book at the library and code in standard Python. How would you even LEARN about WinForms without learning that it was a Microsoft .NET thing?
And your point? All of Microsoft's .Net platform is not part of an ECMA spec. In fact, the most important parts of it, the framework, are not an ECMA spec. So just because Mono and IronPython adhere to the ECMA CLR spec doesn't mean they will work. IronPython was paid for by MS so if MS has anything put in IronPython that is MS-Only, like Winforms, etc. then IronPython has basically become MS-Only.
Yes. That's why I explained to you that IronPython adheres to the ECMA spec. WinForms is not part of the ECMA spec, so IronPython does not depend upon it. IronPython can ACCESS WinForms, just as Unix Python can access Gnome GUI stuff and Mac Python can access Cocoa. But Iron Python does not depend upon Winforms.
Re:Yes, but.... (Score:3, Insightful)