Slashdot Mirror
IronPython 1.0 is Born
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!'"
I can tie all my critical business programs to a platform that Microsoft controls without regard for anything but its own bottom line! Just think, when Microsoft decides one day that the .NET runtime will be a $500 "extra feature", I'll be the first in line to be forced to buy a thousand copies or watch my entire business go down the drain! Wooot! Shared Source is SO much better than that crappy "Open Sores" stuff. Where would the world be without all this Microsoft Innovation(tm).
One other thing. Visual Basic from Microsoft is an IDE, and their name brand for a language. IronPython is not an IDE, so, no, it probably cannot be used to create GUIs and add business logic as easily as VB.
just an analog boy living in a digital age.
There are plenty of them round already. Basically you're getting old, the world is moving on and leaving you behind. Welcome to middle age.
Deleted
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.
Instead of trying to impress us with innuendo and Microsoft bashing, the summary would have been a lot more helpful if it were written a different way. Oh, I don't know...like maybe for instance...TELL US WHAT THE FUCK "IRONPYTHON" IS! But then I guess, after all, that is the Slashdot Way. Why waste time on informative content when you can print Microsoft jabs instead.
I want a new quote. One that won't spill. One that don't cost too much. Or come in a pill.
> It says they are maybe 1.7 times faster than CPython, which is not that great, because CPython is incredibly slow and things
.net or vb. It might be slower, or it might not. Either way it'll probably run fine on a 1ghz desktop.
> 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
You are quite right. People (like the grandparent of this post) who are uncomfortable with Java are typically programmers who haven't had exposure to quite as many programming environments.
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).
Psyco doesn't work on 64-bit. Pypy doesn't work for me at all. But IronPython does work. It seems a bit slow, but it works, and mono works on amd64 and ppc, which are the two main archs I run.
Don't thank God, thank a doctor!
Most of the benchmarking takes place after the CLR loads up, which is why they can say that. For short stuff though, just the load time of the CLR to load the python interpreter can easily kill your start to finish times.
Right. Now hand over your geek badge. Someone will be right down to escort you out.
Visual Basic? Easy to learn? I don't believe that these two statements belong in the same sentance. IMHO VB is a terrible tool to learn, as when used to teach programming fundamentals (as is often done with information systems students in business departments), it corrupts the student's understanding so grotesquely that often, they can never recover.
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.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
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.
just an analog boy living in a digital age.
Or, rather, I was. Then I downloaded the freebie VB.NET Express.
.NET (and those that don't are easier to deal with).
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.
"You can either have software quality or you can have pointer arithmetic, but you cannot have both at the same time."
IronPython threads can take different CPU's in SMP systems? Does anybody knows?
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.
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?)
The cesspool just got a check and balance.
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?
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.
A GUI designer does not make a language a toy, it makes it a language where time is saved in building the GUI painstakingly trial and error fashion - time that can be spent working on the logic. And given that most languages have GUI designers now that would make them all toys, which, having learned C++, makes me wonder what sort of toys you had as a child :P