Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

IronPython 1.0 is Born

ScuttleMonkey posted about 8 years ago | from the metal-snakes dept.

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!'"

cancel ×

285 comments

Sorry! There are no comments related to the filter you selected.

Yes, but.... (5, Interesting)

gnud (934243) | about 8 years ago | (#16055898)

...does it run on Mono?

Re:Yes, but.... (2, Informative)

bogaboga (793279) | about 8 years ago | (#16055923)

It technically could run or to be more precise, it could run with minor changes. My question though is:

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:Yes, but.... (0)

Ana10g (966013) | about 8 years ago | (#16055953)

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.

Re:Yes, but.... (2, Insightful)

Anonymous Coward | about 8 years ago | (#16056088)

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:Yes, but.... (1)

CaymanIslandCarpedie (868408) | about 8 years ago | (#16056202)

He did ALSO as Can it be used to create GUIs, add [business] logic to these GUIs as easily as VB?

Whats that about reading the screen? ;-)

Re:Yes, but.... (0, Troll)

lakeland (218447) | about 8 years ago | (#16056253)

VB is a language that poor programmers find very easy to hack up (unmaintainable) solutions in.
I imagine that the same programmers will find Python (and therefore IronPython) considerably harder to hack up solutions in.

Because it is CLR, it is easy for you to integrate python code with the ugly solutions poor programmers have written in VB.net. So next time some non-programmer shows you their awful business-critical program and asks you to add a feature, you will be able to do it in (Iron)Python. I see that as a good thing.

I don't see IronPython being adopted by the non-programmers though.

Re:Yes, but.... (2, Informative)

Shados (741919) | about 8 years ago | (#16056366)

Hmm, are we talking about the same VB.NET? I'm a C# programmer myself, not VB.NET (though I did do VB.NET for a year or so), but VB.NET is only VB in syntax.. its definately not the RAD tool VB6 used to be. In its simplest form, you could say its Java with VB keyword and a bit of syntax sugar. You won't shoot yourself in the foot any more quickly than you would in any other language commonly used in multi-tier development (Java, C#, and so on). I only quickly looked at Python, but aside maybe for the GUI part, how is it harder to hack up some garbage than it would be in a .NET language?

Re:Yes, but.... (5, Interesting)

JimDaGeek (983925) | about 8 years ago | (#16056477)

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". They have really no understanding of programming maintainable code. The majority of the junk they churn out is MS-Only/IE-Only crud. The bad part is if one of us programmers ever have to maintain the crappy VB.Net code. C# is a pretty nice language that flows well with .Net and is not overly verbose. VB.Net is the exact opposite, one might as well code in COBOL.Net. It really stinks to have the majority of a code-base in C# and then have some VB.Net assemblies thrown at you that you that you later have to maintain. IMO, it really kills productivity to have to switch to VB.Net from C# for a few bits of a project. To me it seems as if no real design went into VB.Net in contrast to C# which seems like a lot of thought went into how to do things and how not to do things.

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 don't see IronPython being adopted by the non-programmers though.
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 .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.

Even though the MS-PR-machine says .Net is cross-platform, it really is not. MS only released a C# compiler for FreeBSD. The compiler is not a big deal. The thing that makes .Net, just like Java, is the extensive framework. MS made an MS-Only framework. It is only because of the hard work of the Mono team that we can enjoy C#/.Net/ASP.Net/ADO.Net/etc on Linux, Mac OS X, Solaris, OpenBSD, FreeBSD, NetBSD and even MS Windows. Mono is cross-platform, Microsoft .Net is not. When Sun did Java, they put the effort in to make the most important part, the framework, cross-platform. I wish MS did the same.

Re:Yes, but.... (0)

Anonymous Coward | about 8 years ago | (#16056599)

You mean the bit where he wasn't referring to what you just quoted and actually was replying to the fact VB and "Easy to learn" were in the same sentence?

Re:Yes, but.... (2, Insightful)

Ana10g (966013) | about 8 years ago | (#16055978)

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.

Re:Yes, but.... (4, Informative)

lakeland (218447) | about 8 years ago | (#16056292)

As a .net CLR language, it can integrate with any other .net language including VB.net very easily. This integration is tight enough that you can write each function in your program in a different language, or write the GUI in VB.net and the support code in IronPython.net

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:Yes, but.... (2, Informative)

jma05 (897351) | about 8 years ago | (#16056572)

As far as I know, IronPython at the moment is not seamlessly integrated into VS2005. If you want VB GUI simplicity (drag control, add event handler), you might want to try Boo. Boo is well integrated into SharpDevelop (in fact SharpDevelop bundles Boo now). While, this is no Visual Studio, it does a pretty good job.

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.... (1, Informative)

Anonymous Coward | about 8 years ago | (#16055927)

for awhile and then they use a new ms-only feature and it breaks and then mono implements the feature and it works, lather-rinse-repeat; one of the features of 1.1.17 was the ability to compile and run ironpython 1.0rc

Re:Yes, but.... (5, Informative)

jupo (717073) | about 8 years ago | (#16056204)

Sure does

IronPython on Mono howto [google.com]

STOP THE INSANITY! (-1, Flamebait)

Anonymous Coward | about 8 years ago | (#16056377)

For god sakes people all this blathering over a. Python and b. Micro$oft's CLR. Python lost its sexiness years ago. It is just another language of which there are many. I know the script kiddies may get a boner over it, but come on this is /. I thought people here were a bit more sophisticated?

And it is just lovely that sheeple acutally do want to be locked to a proprietary environment such as Micro$oft's CLR. And don't give me any crap about Mono making it portable. Mono will always 1) lag Micro$oft and 2) not have analogs for Micro$oft-isms and Windows specific functionality.

STOP THE INSANITY!

Faster than C? (0, Funny)

Anonymous Coward | about 8 years ago | (#16055929)

Yeah, right. Let's quickly port the Linux kernel to python, and while we're at it every other cpu intensive app.

Re:Faster than C? (5, Informative)

cduffy (652) | about 8 years ago | (#16056059)

Faster than CPython (ya know, the original upstream Python implementation), not faster than C.

About speed. (5, Informative)

Poromenos1 (830658) | about 8 years ago | (#16055930)

I found that Python could run extremely well on the CLR in many cases noticeably faster than the C-based implementation.

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. (1)

danhs7 (970647) | about 8 years ago | (#16056082)

Your sortsize [poromenos.org] program seems similar to the knapsack problem [wikipedia.org] . Perhaps you can solve it as a knapsack problem much faster.

Re:About speed. (4, Interesting)

grammar fascist (239789) | about 8 years ago | (#16056114)

My favorite so far is Pyrex [canterbury.ac.nz] , which lets you write C extension modules in a Python-like language. (It adds things like C data types and support for importing header files. I wish it would do generators, though.) A lot of times you can move a hefty inner loop into a Pyrex module and see tremendous gains.

platform-independent. (2, Insightful)

SanityInAnarchy (655584) | about 8 years ago | (#16056460)

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.

Link is unreadable! Jeez! (5, Informative)

Anonymous Coward | about 8 years ago | (#16055934)

[IronPython] [ANN] IronPython 1.0 released today!
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 .NET 2.0 such as DynamicMethods, blindingly fast delegates and a new generics system that was seamlessly integrated with the existing reflection infrastructure.

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 .NET platform. Most features were easy and natural choices where the language and the platform fit together with almost no work. However, there were challenges from the obvious cases like exception type hierarchies to the somewhat esoteric challenges concerning different methods on strings. We spent long days and sometimes weeks looking for the best answers to these challenging problems and in the end I think that we have stayed true to both Python and .NET.

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.

IronPython has also striven for deep integration with the CLR. For the implementation this is a great thing as it lets us take advantage of highly-tuned components developed for other languages such as the just-in-time compiler, garbage collector, debugging support, reflection, dynamic loading and more. This integration is also valuable to IronPython developers as it lets them easily use any and all libraries built for .NET from their Python code.

This is the 1.0 release of IronPython. It's more complete and well tested than any other 1.0 product I have personally released in my career. However, like any other software product it's not perfect. You can search for known issues and let us know about any new ones that you find in our public bug database. We're continuing to work on IronPython and we want your input on how to make 1.1 and future releases even better.

It's been an exciting journey for me to see IronPython go from a rough prototype playing around with some ideas to a solid 1.0 release. This never could have happened without all the people who've contributed to this project along the way. My thanks go out to all the users who braved our early releases and passed along their problems and suggestions. My thanks also go out to the amazing group of people here at Microsoft who've come to join this project and drive it to this quality 1.0 release.

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!

Thanks - Jim Hugunin (for the IronPython Team)

        * 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 ]

More information about the users mailing list

Or, if you're using Opera... (1)

Poromenos1 (830658) | about 8 years ago | (#16055940)

Press Ctrl+F11. I love this browser.

Re:Link is unreadable! Jeez! (4, Funny)

kwark (512736) | about 8 years ago | (#16055973)

And here I thought whitespaces were very very important to python.

Summary is confusing... (4, Funny)

creimer (824291) | about 8 years ago | (#16055946)

Is Python being used to fix Microsoft's mistakes? Or did a python got run through the Iron Chef competition? Either way, does it taste like chicken?

Signed, IronConfused

Hmmm (2, Interesting)

Anonymous Coward | about 8 years ago | (#16055947)

"in many cases noticeably faster than the C-based implementation"

Funny enough, I haven't yet found one of these cases...

Re:Hmmm (2, Insightful)

ThePub2000 (974698) | about 8 years ago | (#16056526)

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.

OB Black Sabbath (5, Funny)

Anonymous Coward | about 8 years ago | (#16055949)

<DistortedVoice>I AM IRON PYTHON<\DistortedVoice>

Duh, duh, duh duh duh.

Finally! (1, Insightful)

Anonymous Coward | about 8 years ago | (#16055950)

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).

Re:Finally! (1, Insightful)

Anonymous Coward | about 8 years ago | (#16056021)

Why, would the current .NET runtime suddenly not work for you? What if the OSS library developers decide to radically change their API in the next version and remove the API that you are using?

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 .NET. The guy is talking about the CLR, not .NET.

Re:Finally! (0)

Anonymous Coward | about 8 years ago | (#16056318)

Is that why windows patches keep making various pieces of software my company uses break? Their extremely good API backwards compatibility with the last patch?

Re:Finally! (3, Insightful)

squiggleslash (241428) | about 8 years ago | (#16056191)

Shared source and open source are not mutually exclusive. According to the only document I can find on the subject, the Wikipedia page (IronPython's webpage sucks) the license is the CPL, an IBM-authored license which is incompatible with the GPL but is nonetheless considered a Free Software license by the FSF, and Open Source by the OSI.

Despite it's incompatibility with their own GPL, the FSF sounds like they actually rather like it:

This is a free software license but it is incompatible with the GPL.

The Common Public License is incompatible with the GPL because it has various specific requirements that are not in the GPL.

For example, it requires certain patent licenses be given that the GPL does not require. (We don't think those patent license requirements are inherently a bad idea, but nonetheless they are incompatible with the GNU GPL.)

So I really wouldn't worry about the "shared source" write-up. It's an unusual choice of license, but it is considered Free Software and Open Source, the patent license requirements are actually fairly positive from the point of view of protections from Microsoft itself. Microsoft have chosen the same license in the past when releasing other code they want to be seen as completely open.

Re:Finally! (2, Interesting)

drakaan (688386) | about 8 years ago | (#16056525)

Speaking of the patent licensing portion, can someone explain what exactly this part means:

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 (which is an unspecified term in the license), the generous granting of rights to use the software for any commercial or noncommercial purpose do not apply (if there's a patent involved)?

That pretty much makes me not want to have anything to do with IronPython development at all. After SCO and a few other "IP" related sagas, I've become a bit less trusting, so I now read the licenses that tools like this come with. I was all set to download it and start playing, but now I'm worried about even trying.

Is there anyone out there who has a more generous reading of the license or who can address the apparent gaping hole in the license concerning what your rights are once you use the software to create something?

I think I played too much Diablo (1, Offtopic)

Hinhule (811436) | about 8 years ago | (#16055955)

Suddenly got this mental image of coding Iron Python like playing Diablo Iron Man, one bug and your project is gone forever!

Sometimes I feel like a Luddite... (-1, Offtopic)

DrVomact (726065) | about 8 years ago | (#16056017)

But does the world really need yet another programming language? Arent' there enough of them around already? One might say the same of *ux distros, "emerging" standards, and anything that begins with the letter "X".

Does the world need more children (3, Insightful)

Colin Smith (2679) | about 8 years ago | (#16056050)

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.

 

XTremez (1)

Ana10g (966013) | about 8 years ago | (#16056056)

Well, Yea! Please tell me that the current state of the art is not our crowning achievement in Computer Science. If it is, I quit.

Re:Sometimes I feel like a Luddite... (3, Informative)

Jerf (17166) | about 8 years ago | (#16056071)

"Another" programming language? It's just another implementation of Python, which has been around for about as long as Perl.

Besides, if it gets to the point where Microsoft is officially supporting it, it would be a major addition to the .Net platform. If I could both develop in Python and in .Net I might actually be willing to develop in .Net. What stops me from wanting to develop in .Net or on the Java platform is the god-awful primary languages they are built around. Java makes me want to scream, and C# is only slightly better, all in all.

Re:Sometimes I feel like a Luddite... (0)

Anonymous Coward | about 8 years ago | (#16056089)

"Another" programming language?

Someone else already bagged on you for this, but really. That was a very stupid comment. It's not "another" programming language. It's been around for two decades, dummy.

Re:Sometimes I feel like a Luddite... (0)

OzPeter (195038) | about 8 years ago | (#16056167)

Its funny about your thoughts on the languages. I've never programmed in Java (so I must be a /. guru when it comes to it :-) but I have been doing some work with C#. I have done a heap of C++ programming with the STL and C# feels to me what C++ should have been. There is an ease of putting together classes and functionality in C# that you have to do manually in C++ but you get a lot of the functionality of C++. Although I haven't used them yet the .Net 2.0 generics seems equivelent to a lot of what can be done with the STL.

However I am not going to go out on a limb and same that C# beats C++ hands down. What I really like about it is that to me it is a nice fun/easy language to program in that has a lot of the power of C++. It fits really nicely between basic scripting languages like MS's JScript and full blown C++

Personally I have never been a big fan of Python for stylistic and other issus, and I prefer languages for which I know I can deploy to a machine without having to install a speparate package. (And 100% of my OS work is on W2000 & XP)

Re:Sometimes I feel like a Luddite... (1, Insightful)

bill_kress (99356) | about 8 years ago | (#16056379)

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).

Re:Sometimes I feel like a Luddite... (2, Interesting)

abigor (540274) | about 8 years ago | (#16056470)

"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."

Oddly enough, I just finished a 3.5 year project very much like what you described, and we rejected Java in favour of Python. It worked out great. Java feels so clunky now - no list comprehensions!

By the way, what's a scripting language? Python compiles to an intermediate object code, runs on a virtual machine, and is very portable. I guess that makes Java a scripting language, too?

Re:Sometimes I feel like a Luddite... (2, Informative)

Jerf (17166) | about 8 years ago | (#16056383)

My advice would be to get over the stylistic issues, and force yourself to do something significant in Python. (Ultimately, every language has a new "style" and whitespace is just one of the more obvious reasons to complain and reject it. Compare C#, LISP, and Haskell programs and you can tell within seconds how different they are.) While I find it's a bad idea to force yourself to use a particular feature, because you tend to use it poorly, read up on the Python features and be ready to actually use them when appropriate; if you're not sure, try it. If you're just writing C# in Python, you're not getting much benefit.

The danger to this plan is that you might find it hard to go back.

If that's just too much, try Ruby. My understanding is that its aesthetics come from Perl, which will probably let you "do your thing", whatever that is.

Python's better than JScript and you can build full, real apps in it, too.

I'm not saying this to "advocate Python", as evidenced by my Ruby suggestion. You'll be a better developer for trying it; everybody should learn a new language every couple of years, to keep in practice. And you might understand the C# features coming down the pike like closures that much better for developing in another environment that has them.

Re:Sometimes I feel like a Luddite... (1)

OzPeter (195038) | about 8 years ago | (#16056499)

The problem in doing something different in Python is that in general I am using the systems to build tools for other people to use. Thus I need to use a language that will "just run" on systems that I have no control over. And the platforms I work in are MS platforms. As such it is in my best interests to use a language that is already installed with the OS. I would not get very far if I came out with "Oh here is areally useful tool, but um .. by the way you need to install this other package of which you have no idea what it is, just so you can run this one tool". JScript is built in. C# (and all the other CLR) languages are built in) and C# is as close to what I have the most experience in with C++. And my productivity matters.

You could argue that I should be dabbling in Python just for the novel learning experience. But 100% of my programming is work orientated, so working in Python is a bit of a dead end for me. (However I have dabbled with it in the past) What I am doing now is learning a new system (C#) and applying that to my work tasks in a way that benefits me and the company.

BTW you can build full real apps in JScript. Before C# I was doing just that.

Re:Sometimes I feel like a Luddite... (2, Insightful)

Anonymous Coward | about 8 years ago | (#16056666)

But 100% of my programming is work orientated

Right. Now hand over your geek badge. Someone will be right down to escort you out.

Re:Sometimes I feel like a Luddite... (1)

Anonymous Coward | about 8 years ago | (#16056177)

Surely the advantage would be that you could run Python on the CLR as a stopgap until VMs actually designed to host dynamic languages are stable? This being MS, they're going to try everything they can to tie you into their platform. Overall, I think I'd prefer to code in binary using smoke signals than install a CLR. I'm not a huge fan of python either.

How about jython? (1)

Anonymous Coward | about 8 years ago | (#16056261)

IronPython seems like a Python based front end for .Net. In the same way, jython seems like a Python based front end for java. In other words, it seems to me that you write in Python and produce java. The result is greater portability because people don't need the python interpreter to run your code. (You can tell I've never used jython.)

I've been using Python for a few years for our in-house apps. Most of the people I have to share code with are old C programmers. They find Python code very easy to read and understand. The code is easy to maintain and it is easy to write self-documenting code. Those are very attractive attributes.

Being able to write Python code for .Net or java seems like quite a good thing. The code is cheap to produce because it takes less time to write and it is cheap to maintain because it is easy to read.

Re:Sometimes I feel like a Luddite... (0)

Anonymous Coward | about 8 years ago | (#16056156)

Yes. No.

Glad I could help.

The field is always about new things. Try blacksmithing if you prefer a stable field.

Snakes... (4, Funny)

Cameron McCormack (690882) | about 8 years ago | (#16056032)

on a VM!

Re:Snakes... (1)

SB_SamuraiSam (962776) | about 8 years ago | (#16056098)

Hilarious! If only I had mod points. :-D

Re:Snakes... (2, Funny)

Twisted64 (837490) | about 8 years ago | (#16056228)

I don't find that funny at all. As soon as this finishes posting, I'm going to mod you down.

Re:Snakes... (1)

Cameron McCormack (690882) | about 8 years ago | (#16056243)

Sheesh, just because you haven't watched the movie yet!

Re:Snakes... (1)

Twisted64 (837490) | about 8 years ago | (#16056260)

...movie?

Re:Snakes... (4, Funny)

Matt Perry (793115) | about 8 years ago | (#16056397)

Bill Gates: "I have had it with these muthafuckin' snakes on this muthafuckin' VM!"

Re:Snakes... (5, Funny)

neuro.slug (628600) | about 8 years ago | (#16056641)

Or even better.. shit, they have Ruby on Rails--we need Python on Planes (or Python on MUTHAFUCKIN' Planes)

Cut to Next Scene (0, Troll)

ClamIAm (926466) | about 8 years ago | (#16056040)

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.

Somewhere in a billion-dollar mansion (OK it's in Washington), Gates and Ballmer are doing a very good "evil scheme" laugh.

Yeah, yeah, I know, Mono. Software patents aren't valid everywhere, Microsoft is failing anyway, blah blah. But if you think this wasn't the design all along, you may want to check into an institution that helps folks deal with reality.

Re:Cut to Next Scene (1)

vinsci (537958) | about 8 years ago | (#16056322)

Please mod parent up, insightful. It's not the first time we see Microsoft do this. In fact, it's the only thing they do, all the time. Feeding the monopoly.

Apparently a troll moderator modded the parent post down to 0, currently.

Round peg... (1)

Anonymous Coward | about 8 years ago | (#16056067)

...meet square hole.

Cool team (1)

mynickwastaken (690966) | about 8 years ago | (#16056081)

Look on People link on their website.
11 coordinators and only 5 developers.
now they need 22 people on marketing.

An IronShitPython was just born in my toilet... (-1, Troll)

Anonymous Coward | about 8 years ago | (#16056085)

and damn it felt good.

Dealing with UI (3, Interesting)

Carcass666 (539381) | about 8 years ago | (#16056101)

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:Dealing with UI (1, Informative)

Anonymous Coward | about 8 years ago | (#16056133)

No you pretty much lose any existing Python library that is not 100% Python and pretty much must use the .NET equivalents.

Re:Dealing with UI (1)

jsoderba (105512) | about 8 years ago | (#16056172)

A quick google shows wx.NET [sourceforge.net] , a C# wrapper around wxWidgets. I haven't tried it, though. The Mono project provides GTK# along-side their Windows.Forms implementation, of course.

Re:Dealing with UI (1)

gnud (934243) | about 8 years ago | (#16056205)

The ironpython faq explains how to load native python libraries. So I expect you can use wxPython (or even better, pyqt :)

Re:Dealing with UI (2, Informative)

Tyger (126248) | about 8 years ago | (#16056265)

Probably not wxPython, but you would be able to use wx.NET [sourceforge.net] with it. (Though the development looks to have stopped on that judging by the timeline on that page.)

It would be interesting to see how similar wxPython is to wx.NET with Python.

Re:Dealing with UI (1)

Fearless Freep (94727) | about 8 years ago | (#16056332)

If you wanted to use wxPython, why would you be using .net anyway?

Re:Dealing with UI (1)

Carcass666 (539381) | about 8 years ago | (#16056500)

If you wanted to use wxPython, why would you be using .net anyway?

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 just asking "why"?

Re:Dealing with UI (0)

JanneM (7445) | about 8 years ago | (#16056465)

You should be able to use Gtk# just fine.

Bad article summary... (2, Informative)

ndykman (659315) | about 8 years ago | (#16056102)

The snipped out part of the announcement seems to me to leave a bad impression. Given this is /., I can almost hear everybody filling the blanks with "and it's still is slow, because MS sucks" or the like, which is not the opinion or intent of the comment actually quoted.

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 .Net groups, I think it is also reasonably portable as well.

Mod Parent Up (0, Redundant)

0kComputer (872064) | about 8 years ago | (#16056425)

This was my thought exactly; the summary is misleading, he's actually praising the CLR.

Hrm (4, Interesting)

IamTheRealMike (537420) | about 8 years ago | (#16056126)

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:

  • It says they are maybe 1.7 times faster than CPython, which is not that great, because CPython is incredibly slow and things 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. By their very nature everything has to be done at the last minute, based on string comparisons, and you can't do global optimizations really because at any moment the program might change itself and invalidate them. 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.
  • If IronPython can't make Python fast .... seems like its only purpose is to give people who like Python and .NET some half way point between the two. But it's not quite Python, because you can't use its standard library, and it's not quite .NET so in a way you seem to get the worst of both worlds

I guess I just don't get it.

Re:Hrm (2, Interesting)

killjoe (766577) | about 8 years ago | (#16056168)

I think the point is to discourage the use of cross platform libraries and languages. MS figures if they can tie python programmers to windows then less programs will be written that can run on linux or the mac.

The question is does ironpython run on mono.

Re:Hrm (2, Informative)

squiggleslash (241428) | about 8 years ago | (#16056254)

It's quite simply an attempt to make Python available for .NET (and presumably the CLR in general.) That's it.

This is the way programming is going. We're moving from CPU-specific unmanaged programming to platform independent abstracted managed environments. One day your entire operating system will run that way. But even today, you see these environments popping up in places where they add security and robustness.

Web applications, for instance. So you have a giant web-app, maybe you're using components from three or four third parties. If you're using .NET or Java, you can integrate these components with any language that runs on the .NET or Java platforms. That means something simple, that can be done in two lines of Python (which my loves-Java-like-a ricer-loves-Gentoo collegue assures me is the average length of a complete Python application ;-) can be run in that environment simply by using IronPython or Jython. And when I say "that environment", I mean your two liner will have as much access as a C# or Java program would have. No writing of C stubs to link the two environments necessary.

That's why IronPython (and Jython) are great things. Indeed, the fact you can integrate Python and Java/C# and half a dozen other languages so transparently in these types of environments gives you some idea of the power managed environments give you. We haven't seen anything like this since Unix.

All hail James Gosling!

Re:Hrm (1)

WilliamSChips (793741) | about 8 years ago | (#16056339)

(which my loves-Java-like-a ricer-loves-Gentoo collegue assures me is the average length of a complete Python application ;-)
I think that's just a perspective issue. Java has so much filler code that something that should take two lines takes about twenty ;)

Re:Hrm (2, Insightful)

kpharmer (452893) | about 8 years ago | (#16056369)

> It says they are maybe 1.7 times faster than CPython, which is not that great, because CPython is incredibly slow and things
> 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 .net or vb. It might be slower, or it might not. Either way it'll probably run fine on a 1ghz desktop.

Re:Hrm (1)

IamTheRealMike (537420) | about 8 years ago | (#16056424)

Sure, but that doesn't make fast or slow meaningless. It just means that for your specific applications performance isn't a big deal.

Re:Hrm (4, Informative)

amix (226257) | about 8 years ago | (#16056451)

But it's not quite Python, because you can't use its standard library

Yes, you can, though not all builtins are available. All you need is this line in IronPython\Lib\site.py:

import sys
sys.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 .NET2 framework and can use IronPython to write cmdlets for PowerShell (aka: Monad).

I consider this to be one of the best software-relases within the last few months.

Re:Hrm (0)

Anonymous Coward | about 8 years ago | (#16056512)

I think for attribute/method access in Python, it's mostly the hashtable lookup. If you have foo.bar, "bar" is stored in an internal string list so it just needs to check that the two pointers to "bar" are the same, without a string comparison. I believe Psyco optimizes it further. I'm no expert on Python internals though.

There's tons of other dynamic things that hinder optimization, unfortunately.

This is huge.... (4, Interesting)

SumeyDevil (906408) | about 8 years ago | (#16056142)

This is huge, as now people have access to ALL the .NET libraries. Ironically, maybe Microsoft could be the company to take Python mainstream. First Google, now Microsoft...who's next? Additionally, anyone ever think how powerful Visual Studio could be if they implemented something like Parrot runtime into .Net?

Re:This is huge.... (1)

Nataku564 (668188) | about 8 years ago | (#16056197)

Parrot is a VM. I'm not entirely sure why you would stack VMs. One is more than enough.

Of course, you may have meant Perl 6, the primary thing targeting Parrot, but they are quite distinct terms ... so ... dunno. Besides, with the way Parrot is going, you could just create a COLA -> CLR compiler and be done with it. That way the same language backend that produces COLA for compilation into PASM could be used and pipe the COLA into the equivalent CLR thingy and have everything work.

Re:This is huge.... (1)

quick_dry_3 (112334) | about 8 years ago | (#16056414)

mod parent up. All these posts bashing IP and MS, this one hits on one of the coolest things about it - access to all the .Net libraries.

Just call it... (1)

SensitiveMale (155605) | about 8 years ago | (#16056144)

the "John Holmes" build.

Parrot (2, Interesting)

Watson Ladd (955755) | about 8 years ago | (#16056158)

Yeah, they did screw up. Parrot will beat CLI for speed in dynamic languages by huge magnitudes of speed because it is designed for them. CLI is optimized for static languages. It's a very different idea. Calling conventions, instruction sets, internal types, even stack vs. register. They are very diffent animals.

Re:Parrot (1)

Anonymous Coward | about 8 years ago | (#16056249)

Have you ever seen the prophetic Monty Python sketch from whence parrot got its name? I'd like to see parrot happen, but it clearly isn't. Lua has a fast register based VM, then there's neko, a stack based VM with JIT. Why wait for parrot?

Re:Parrot (1)

WilliamSChips (793741) | about 8 years ago | (#16056348)

Can you link me to this 'neko' VM?

Re:Parrot (0)

Anonymous Coward | about 8 years ago | (#16056426)

http://nekovm.org/ [nekovm.org]

Re:Parrot (1)

Ian Bicking (980) | about 8 years ago | (#16056355)

HLVM [hlvm.org] seems kind of interesting as well.

Re:Parrot (3, Informative)

gregorio (520049) | about 8 years ago | (#16056373)

Yeah, they did screw up. Parrot will beat CLI for speed in dynamic languages by huge magnitudes of speed because it is designed for them. CLI is optimized for static languages.
1. RTFA. It talks about naive and uninformed (generated by hate) opinions like yours, and says that they are wrong.

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:Parrot (0)

Anonymous Coward | about 8 years ago | (#16056610)

Yes, the CLR with its JIT can perform slightly better than pythons unoptimized C runtime. Big deal [sidhe.org] .

This post generated by hate (apparently) and if you're not a mono guy yet, they all think like you over there :-o


Re:Parrot (0)

Anonymous Coward | about 8 years ago | (#16056668)

So where is this parrot thing at? Is it gonna happen before Nuken Duken comes out?

Mimsy were the borogoves (4, Insightful)

davmoo (63521) | about 8 years ago | (#16056162)

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.

Re:Mimsy were the borogoves (0)

Anonymous Coward | about 8 years ago | (#16056311)

As far as I can tell, IronPython seems to be some kind of inside joke. If only Slashdot had a laugh track so I knew when to laugh...

IronPython screencast (4, Informative)

eastbayted (982797) | about 8 years ago | (#16056221)

Jon Udell did a screencast of it [infoworld.com] last week, joined by Jim Hugunin (creator of Jython, the Java-based Python).

Visual Studio? (2, Interesting)

nurb432 (527695) | about 8 years ago | (#16056241)

Does this work within visual studio, like a 'regular' microsoft language?

Re:Visual Studio? (3, Informative)

quick_dry_3 (112334) | about 8 years ago | (#16056329)

yes. There are a few hoops to jump through, but afterwards you can code and debug from VS

IronPython Needs a Lawyer To Fix the License... (1)

sweetnjguy29 (880256) | about 8 years ago | (#16056344)

...and fast.

Typical Slashdot... (3, Informative)

His name cannot be s (16831) | about 8 years ago | (#16056359)

Nice Inflamitory Summary tho'... Sheesh.

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 .NET 2.0 such as DynamicMethods, blindingly fast delegates and a new generics system that was seamlessly integrated with the existing reflection infrastructure.

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 .NET platform. Most features were easy and natural choices where the language and the platform fit together with almost no work. However, there were challenges from the obvious cases like exception type hierarchies to the somewhat esoteric challenges concerning different methods on strings. We spent long days and sometimes weeks looking for the best answers to these challenging problems and in the end I think that we have stayed true to both Python and .NET.

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.

IronPython has also striven for deep integration with the CLR. For the implementation this is a great thing as it lets us take advantage of highly-tuned components developed for other languages such as the just-in-time compiler, garbage collector, debugging support, reflection, dynamic loading and more. This integration is also valuable to IronPython developers as it lets them easily use any and all libraries built for .NET from their Python code.

This is the 1.0 release of IronPython. It's more complete and well tested than any other 1.0 product I have personally released in my career. However, like any other software product it's not perfect. You can search for known issues and let us know about any new ones that you find in our public bug database. We're continuing to work on IronPython and we want your input on how to make 1.1 and future releases even better.

It's been an exciting journey for me to see IronPython go from a rough prototype playing around with some ideas to a solid 1.0 release. This never could have happened without all the people who've contributed to this project along the way. My thanks go out to all the users who braved our early releases and passed along their problems and suggestions. My thanks also go out to the amazing group of people here at Microsoft who've come to join this project and drive it to this quality 1.0 release.

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!

Thanks - Jim Hugunin (for the IronPython Team)

cheers to the IP team (3, Informative)

quick_dry_3 (112334) | about 8 years ago | (#16056361)

just wanted to give a "cheers" to the MS dev team working on this.
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.

Snakes on .NET? (0)

Anonymous Coward | about 8 years ago | (#16056611)

Get these muthaf__kin snakes off my muthaf__kin CLR!!
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>