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!'"
...does it run on Mono?
Yeah, right. Let's quickly port the Linux kernel to python, and while we're at it every other cpu intensive app.
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) run tens of times faster with psyco, by just adding a line of code to my script.
Send email from the afterlife! Write your e-will at Dead Man's Switch.
[IronPython] [ANN] IronPython 1.0 released today!
.NET 2.0 such as DynamicMethods, blindingly fast delegates and a new generics system that was seamlessly integrated with the existing reflection infrastructure.
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
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
Press Ctrl+F11. I love this browser.
Send email from the afterlife! Write your e-will at Dead Man's Switch.
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
"in many cases noticeably faster than the C-based implementation"
Funny enough, I haven't yet found one of these cases...
I AM IRON PYTHON<\DistortedVoice>
Duh, duh, duh duh duh.
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).
Suddenly got this mental image of coding Iron Python like playing Diablo Iron Man, one bug and your project is gone forever!
on a VM!
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.
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
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.
just an analog boy living in a digital age.
...meet square hole.
"Another" programming language? It's just another implementation of Python, which has been around for about as long as Perl.
.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.
Besides, if it gets to the point where Microsoft is officially supporting it, it would be a major addition to the
"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.
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?
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.
.Net groups, I think it is also reasonably portable as well.
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, I think CLR is done quite well as a language independent platform. Also, given the excellent work of the Mono and Portable
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.
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?
the "John Holmes" build.
Yes. No.
Glad I could help.
The field is always about new things. Try blacksmithing if you prefer a stable field.
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.
Inventions have long since reached their limit, and I see no hope for further development.-- Frontinus, 1st cent. AD
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.
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)
I am Slashdot. Are you Slashdot as well?
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.
Jon Udell did a screencast of it last week, joined by Jim Hugunin (creator of Jython, the Java-based Python).
Does this work within visual studio, like a 'regular' microsoft language?
---- Booth was a patriot ----
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.)
.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.
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
...and fast.
Nice Inflamitory Summary tho'... Sheesh.
.NET 2.0 such as DynamicMethods, blindingly fast delegates and a new generics system that was seamlessly integrated with the existing reflection infrastructure.
.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 hierarchi
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
"...In your answer, ignore facts. Just go with what feels true..."
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.
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).
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.
This was my thought exactly; the summary is misleading, he's actually praising the CLR.
Top 10 Reasons To Procrastinate
10.
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!
"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?
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.
I am Slashdot. Are you Slashdot as well?
Get these muthaf__kin snakes off my muthaf__kin CLR!!
Right. Now hand over your geek badge. Someone will be right down to escort you out.
Enough is enough! I have had it with these !@$&* IronPythons on this !%$~# CLR!
"Strangers have the best candy" -Me
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 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.)
The standard win32 dist of python is (only) about 9MB. There is also py2exe which bundles your bytecode with a slimmed-down interpreter.
Those were the days. "Did I just press 'R', and lose two hours of work? Rats."
This is not a new language. It's a new implementation of a language.
And immediately thought Pr0n? Be honest now.
And by the way, Python has been around for awhile, this is just a different, potentially better implementation.
Don't thank God, thank a doctor!
well, announcing super pre alpha titanium nano emerald carbon fiber KING COBRA GOLD! It spits on the competition, envelopes all other languages in its patented HOOD 0 DOOM, and mesmerises all coders with its sinuous scalar interface! Plus, it's organic! and green!
top that, poseur!
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.
Mmmm... Pie Pants.
No... wait. I meant Pie Pants.
Signatures are a waste of bandwi (buffering...)
I ran it on one of my Python apps and it actually slowed it down by a factor of 1.77. Lots of caveats here, but this is the opposite of what I expected to see.
http://boo.codehaus.org/
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?
I just submitted an article, Boxing in the LLRing I wrote about the Lightweight Languages Ring, a gathering of 300 developers at a boxing ring a week ago in Tokyo. For one thing Ruby's inventor is working on Yet Another Ruby VM and also the Python Language Update mentions IronPython.
...open your eyes.
IronPython has big shortcomings such as it is unable to blend well with .NET assemblies built with another language. .NET Framework...
.NET (on win32 or on linux with Mono), check out the Boo language, the wrist-friendly language for the CLI.
u age
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 inference, generators, multimethods, optional duck typing, macros, true closures, currying, and first class functions."
And last but not least, Boo's licence is BSD, not a crappy Shared Source something!!
Full description: http://en.wikipedia.org/wiki/Boo_programming_lang
Official website: http://boo.codehaus.org/
@neonux
Wrong, Python is a general purpose strongly, dynamically, implicitly typed programming language. It's multiparadigmatic with a fairly tight object orientation, implicitly compiles to bytecode and can trivially include third-party languages or be included in C/C++ software.
Python is far from being a mere "scripting language", whatever that may mean.
Yeah right.
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
And noone can say that Python doesn't run easily on Windows box with py2exe, a virus was recently written in Python and bundled via py2exe!
How's that for running on win32?
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
Let us know when the license becomes unencumbered of requirements or legal risk, like normal Python.
Iron Python is a dangerous beast. Consult your lawyers.
-josh
I'm curious whether the productivity increase you commented on was just an off the cuff "you might be better at Python" comment or an actual, documented speed increase that most programmers would be able to take advantage of.
Similar to the poster you were responding too, most of my programming these days is in the work environment, leaving little time and energy outside of that to work with new languages. While I do have enough python experience to know I love it, I have yet to write anything more complicated than an isometric map generator and partial editor (on the gui side) and the beginning of a data historian (on the pure code side). Day-to-day I work with C# and ASP.net and way too little time. If IronPython is more efficient to write code in (in a time:result ratio) than I definatly am interested.
Plus I love my list slicing...
Whee signature.
We have this issue with Java too. I work on a the JIT compiler for one of the industry-leading Java implementations, and we have ways to register assumptions such that if they are ever violated, the jitted code is patched so it remains correct under the new conditions. That lets us be optimistic, assuming that the program won't take advantage of much of Java's dynamic nature, and those assumptions are (by design) usually correct.
I imagine a similar approach would help Python. For instance, in your example of a "fallback method", if you're really desperate, an early compile of the caller method could instument the call site and see what actual methods are usually dispatched there. On a subsequent compile, it could generate a PIC (polymorphic inline cache) that uses a class test and dispatches the target method (or inlines it), plus a registered assumption that nobody changes the target method for those classes. If they do (which is rare), the corresponding PIC slot would be invalidated. The fallback case in the PIC would do the full-blown string-based dispatch, and usually this slow path should be very rare.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
I don't think this is true. In fact, I just tried it ... you'll note that I've tested your assertion about space by allocating rather more than 32KB in both a single struct and an array of that struct. I've also tested limits on the number of array elements (you were restricted to (2^15)-1 elements in VB3 arrays, but not in VB6). You are limited to 64KB in a static struct... I can honestly say that I never ran up against that, even when porting code with some enormous (1KB) structs in it.
Of course, if you can post some code that demonstrates your assertion, I'll eat my words.
I can't really take it seriously until it integrates with Visual Studio.
.Net is far to much of a pain to program unless its being done in VS.
Anything
Power Corrupts,Absolute Power Corrupts Absolutely, leaving one person(group)in charge is absolutely corrupt.
Then about the "CLR sucks" reference :
This was essentially people complaining that the first implementations for
Perl and Python can do some weird kind of operations that aren't supported by C#. And because it was mainly built with C# in mind, the CLR machine lacks them (the "open to other language" is mainly PR stuff : Microsoft is basically not against the CLR being used to run other languages, but don't expect to find everything you need for it). The JVM happen to be a little bit more friendly (even if it was never advertised as such back then and was only initially intended to be used for Java).
What the people, who complained about CLR, wanted was to have scripts compiled into NET bytecode and then directly run inside the
IronPython is a solution around those limitation, and basically is something like rewritting a python interpreter in C#.
So you get your Python script ran inside a python interpreter which it self is compiled into bytecode that runs inside the NET interpreter. (But that's only the global over-simplified idea. Thanks to some optimizations, it doesn't run as slow as one may except, and also python script and C# classes can communicate).
One could mix python and C# if one includes the IronPython interpreter at compile time.
IronPython implements those part that are missing in the CLR engine. And some other parts were improved for the 2.0 version of the
The opposite approach is the one behind Parrot. It is designed as language-neutral from the ground up. Althrough it began it's life as "The software we're writing to run Perl 6", very early the project was going to be designed to run Python, and Ruby was considerated too. Wikipedia has some info about current status and projects collaborating to incorporate other languages.
Unlike IronPython the point is to compile Python scripts (and whatever else language) to Parrot bytecode, and then dirrectly run them from the parrot engine, mixed freely (and sharing data and classes) with whatever else language was thrown in the mix (1 single language binding to use whatever tool-kit. No more separated SDL#, PyGames, Perl::SDL, etc...) and easy communications with C libraries. An interpreter is only needed in the final compiled product if one needs to be able to support uncompiled scripts.
(Also, in addition to a large array of languages, the parrot aims to support a crazy large array of targets)
IronPython is somewhat reminiscent of the FSF saying that the GNU software could never be ported to DOS because of it limitations, and DJ Delorie writing DJGPP to get around those limitation and give a POSIX compatibility layer on MS-DOS.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
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...
So... when you decided to implement this language, you used CLR which, by your own accounts, is a worse platform... I dont' get it. You wanted to understand Microsoft's stupidity by building on it? Brilliant.
The 2-3x is off the cuff. It has been shown (though I can't find the nasa study) that scripting language programmers finish tasks several times faster than C programmers, but that's largely through leveraging the built-in datatypes (dicts, lists, etc) and making heavy use of the stdlib.
Up against something like C#, I'm fairly confident that Python is still faster to develop in without support from the editing environment, but I haven't used VS since VS6, so I don't know what sort of advances VS brings to C# that it wouldn't bring to IronPython. Given that you'll largely be using the same library and environment, I wouldn't expect a massive improvement.
In fact, I'd predict that your productivity gain will depend on the ratio of systems code to glue code you write. The shorter syntax, lack of a compile cycle, and ability to poke at stuff in the console make Python a better glue language. As far as systems languages go, I find Python perfectly adequate so I haven't felt a need to explore C#. Java 1.3 kind of turned me off of non-scripting languages so I don't know how language improvements have affected things.
I can't provide full scientific proof, because there is no scientific proof in this domain, which I regret.
:) It is proper to be skeptical about productivity gains in a world where we have no concrete measure of productivity, but since I don't have concrete standards, all I can tell you is that my own experince matches the Blub Paradox to a T; whenever I do have to code in Java or C++ or anything else like that, I will see simple solutions to my problem in Python that require the equivalent of tens or hundreds of lines of code in those languages. (Heck, even in Perl I've wished for generators on more than one occasion, and unrolling a generator is no fun.)
The best actual "proof" is the following: There was a study a while ago that established productivity for a given programmer appeared to be constant across lines of code, regardless of the language. This study was, IIRC, done a while ago, against C, assembly, and a couple of other suspects, but it was a pretty good spread. Programmers can turn out a couple hundred lines of non-trivial code a day. The idea is that since this is true, you want the language where you need the fewest lines of code, all else being equal, to accomplish your task.
The details of this have been debated endlessly. My personal call is that it is "mostly true", with some important caveats (programmers not gaming the LOC count, and the real important metric is "lines of code the programmer has to think about"; frameworks can churn out thousands of lines of templates (MFC was horrible about this) and they don't count), but experience does bear this general idea out.
The general LOC multiplier for Python vs. Java on the small scale is usually thought to be 5-10x. It's hard to know exactly how accurate this is because Java makes doing small things enormously complicated; "Hello World" is at least three lines of real code (class definition, static main method declaration, and the print call which itself involves a method chain of the form X.Y.Z("Hello World"), not just a simple statement). However, it is also a reasonable to believe that Java continues to make things hard as you scale up, and there are some simply Python patterns that are effectively impossible in Java or require jumping through very complicated hoops. I also believe there are a few cases of Java programs ported to Python that bear this out, or possibly even more. (Sometimes you can end up with some multiplicative gains, where the 5-10x improvements actually start layering on top of each other; in real terms this usually translates to the ability to create a superior design in Python than what you can do in Java. There's a reason Java's got all of these code generation tools and bytecode hacking tools, whereas Python mostly doesn't.)
The productivity multiplier does seem to be similar.
I cut down my estimate for C# because while I'll cop to never using C#, it does seem to me to be somewhat better. As I alluded to, adding in closures in 2.0 will also be a significant step forward. (Closures are a feature I recommend learning about, as for a long time I saw programmers talking about them and I had no clue what they meant, but once I got over the learning curve I understood why they were so important. Some of the worst problems with the worst workarounds in Java come from the lack of closures or any equivalent functionality, require fully separate large complicated classes with new interfaces to achieve the same functionality, all with no gain in safety or functionality. This is one of the places you tend to get the layered benefits I alluded to...) So I don't know if the gain is as large.
On the other hand, C# does seem to make heavy weather of certain very easy constructs in Python.
So that's the general evidence. If you want to learn more and get a lot of opinions, you can search "Python productivity" on the web.
But I know in your shoes I'd be downloading IronPython and putting it through its paces.
Offtopic? I'm wounded. Deeply wounded. Or do people not know what a "Luddite" is? And you never have a Luddite sort of mood? And how can being a Luddite on /. ever be off-topic? Ah well. I guess I'll change my sig to all smiley faces, then people will stop taking me seriously.
. I guess I should have asked if Iron Python is still indent-sensitive.
Great men are almost always bad men--Lord Acton's Corollary
Well then, I stand corrected.
Best of luck.
I spent a considerable amount of time trying to do a real world IVR engine in python with C extensions to the driver library. It was to be multithreaded... not multi process. I COULD NOT get it to work correctly... and yes I know about the "Allow threads" directive for the C calls. I even asked the amazing brain trust at the Pycon in 2003 what could be done. My conclusion was that no one else was trying to do what I was :(
.NET threads?
:)
The Global Interpreter Lock seems to me to be part of the problem. I think the Jython implementation worked with "native" Java threads.... I wonder if IronPython uses native
I like the promise of rapid application development in python but it needs to be able to take advantage of multiprocessor/threaded CPU architectures to be useful to me. I know you can use the multi process approach but frankly, this is a wart that rubs me the wrong way.
Thanks for listening
Just out of curiosity, how did your team make this work. With different development units spread across the state, did you have shared ownership or did each group own their own code? How many people worked on it? How did you communicate primary interfaces? Did you use UML for primary design or some other method, or did you just all code at once and hope things lined up?
How did you manage the namespace thing. That's really one of my biggest questions about large-scale Python development. It's frightening that the namespace outside a method can be passed into that method, so a method may operate differently based on functionality defined outside that class. You can say "We won't use dangerous language features when doing large-scale development", but then why use python?
Did you use unit tests? Is it easy to replicate the entire environment of a class in order to get your tests to work?
What do you use for scaling the server to multiple systems? Did you have to do all that code yourself, or did you have a tool that worked like a J2EE server? For that matter, how do you manage objects on the server, do you re-create them every time the server is called, or do you have a permenant cache to save you all those allocations. Personally I don't love J2EE and if that same functionality is available in python, I'd love to see it.
Any other details would be appreciated, this seems an amazing undertaking. Also, what factors did you weigh when choosing python over java?
Oh, and since you asked, my definition of a scripting language would be any language balanced for writing a minimal ammount of code to get something to work. For instance, in most scripting language a "hello world" is one line. A development language is based on readability and communication with other programmers, Brevity in this kind of a language is not desired, nor are multiple ways of doing something. Consistancy and linguistic simplicity are key (The fewer keywords, options and built-in "tricks", the better).
Aren't you forgetting another language? Another one that starts with "P"? From the "New in JavaScript 1.7" page:
Or is Perl "less mainstream" than Python nowadays?
Wow, lots of questions! Okay, here we go:
;) We had a good project manager who tracked progress closely; normally there were no more than two people working on the same component. We were lucky in that most people were relatively senior. Also, not everything was the Python part of the server; we also had guys writing kernel code, TI DSP software, etc.
.Net system.
;) How about this: a scripting language is fully interpreted, with no intermediate compilation step. Bash and Javascript are scripting languages, for example. Python, Java, and Perl are bytecode-interpreted languages, while C and C++ are machine-instruction interpreted ;)
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 of abstract base classes that were implemented using the staticmethod decorator. An "interface" keyword would have been nice, mind you. Obviously, these interfaces were hammered out before any coding started.
3. Can you clarify the namespace question? Python uses packages and modules aligned along directories much like Java does.
4. Python has built-in support for unit tests. It is considered a part of the "Python way" to use them.
5. We are scaling with hardware, and that works rather well. But you're right, the Python world could really use a JBoss or similar. I guess Zope sort of fits that bill, but I've never been able to figure it out.
6. Object management is a good question. Originally, we cached our objects to prevent bottlenecking the database with reads. Later, we hit on the bright idea of a fully stateless system where every method is decorated with the classmethod keyword. So objects do not maintain state, because no objects are allocated - everything is a class method (obviously, we do create lots of temporary objects to complete tasks, but these lifetimes don't outlast the method they're in). On the downside, every time a request comes in, it means an entirely new Python instance with all the classes needs to be created. Happily, mod_python can cache interpreter instances so multiple requests can come in to our stateless system without causing huge delays. But any time you want to retrieve state, it means a database hit...such is the price of simplicity. Kind of embarrassingly, we got the idea for a fully stateless system from a
7. It's not an amazing undertaking. Lots of people are using Python as the back-end these days for their transactional systems. Read about the Django project for some cool examples. Django is a fine piece of work. So is Twisted, which we were originally going to use as well.
8. We chose Python for speed of development and language features. Like Peter Norvig of Lisp and Google fame says, Python is Lisp with a conventional syntax. Practically everything in software boils down to operations on lists of objects. So language features like list comprehensions and dynamic yet strong typing, plus strong support for unit tests, made Python an easy choice. And pydoc is just like javadoc, so we get class documentation for free.
9. I can write "Hello, world" in C in a single line
Anyway, thanks for all the questions. To be honest, I'm off that project now, and I'm looking for contract work, which will probably end up being Java...
If you care to come to the middle of nowhere washington/idaho we are looking for some good developers. You obviously know what you're talking about.
...
Okay,
Namespace: I could very well be wrong but I was under the impression that if you assigned a variable then called a method (Perhaps in another package), that variable would be available to the called method. Perhaps I'm confusing python with another language? This is the way that scripting languages act and it scares the crap out of me, explicit interface definitions and repeatability are hugely important.
Object Management: Sounds like you are going through the same stuff that Java users went through that forced 'em to develop the j2ee style servers.
Dynamic typing: How does python deal with errors like this?
abc=1
acb=abc+1
In visual basic if I were to see a developer that didn't put Option Explicit at the top of each file, I'd fire him on the spot. Does Python have the same ability, and if so, why is python advertised as dyanamically typed--no developer would ever use dynamic typing unless some way was found around the above example, it's too dangerous.
Scripting Languages:
Beanshell turns Java into a scripting language. It still compiles it though. Basic can be compiled or not, C can be interpreted,
So for my definition of a scripting language I look at, for instance, Java under BSH vs standard Java.
Under beanshell, this would work (iirc)
x=5;
public addone() {
return x+1;
}
print addone();
6
This is neat for quick scripting, but there are a few features that I would be terrified to use in real development:
1) the simplification of System.out.println() to print. It really isn't any harder to type and having multiple ways to do something just means additional confusion.
2) The fact that addone would return 6 for a value of 5, and "5+1" for a value of "5" makes your code extremely unpredictable.
3) Probably most important, the fact that you can access x from the callers namespace. From the class namespace is fine, but from the callers namespace is insane. I may be wrong about Python having the ability to do this. If it can't do this, I apoligize, but I swear that's where I stoped evaluating it and threw it into the toy/scripting category.
Oh, and just having the ability to shut it off doesn't make it a better language (But it makes it a usable language!). Just because VB has "Option Explicit" makes it usable, but it's still terrifying that you could run into code out there where someone didn't turn it on, so all VB code has to be suspect.
Arrays:
A lot of code (Perhaps not all) is done in collections/arrays. The question is, is it worth having multiple ways to do something to save a few keystrokes.
My answer is always, don't do anything just to save keystrokes. REPEATED keystrokes are horrible (my bane is the java "JFrame f=new JFrame()" but it never actually cost me any time, it's just a little ugly.), but if you can't type in documentation or can't write a simple for each loop, you are probably in need of a typing class.
If you can think faster than you type, even in the wordiest syntax imaginable (COBOL?), you probably need a typing class.
Chose a syntax for readability not "typeability" because you only type it once, but it will be read much more often.
Perl can assign lists to lists, so you might call it first-order destructuring, but it can't (to the best of my knowledge) do it arbitrarily deeply like Python, Erlang, and other fully-destructuring languages.
Close, but I think you're slightly off. I use C# by preference (though I'm still learning it) and VB.NET at work (required; migrating from VB6 was enough of a headache, practically nobody here speaks a non-VB language). I have so far seen about the same productivity, though C# tends to *click* better in my mind.
.referenceEquals() if you want to check for the same object, rather than a clone, as opposed to the style of ==) means you can't cleanly do things like
.NET 2.0 compliant). VB isn't the only language that has required such; J# for example (despite being, syntactically, a near-perfect subset of C#) also requires extensions to the base CLR (on second thought, this may be for support of the Java package/namespace... it might work if written using only mscorlib).
Regarding differences, however, I don't think VB.NET (or possibly any language other than C#/Managed C++) allows explicit stack allocation, pointer manipulation, etc. For high-level stuff this is USUALLY not needed, and for low-level you probably wouldn't be using the CLR anyhow, but VB.NET is still behind C# (from what I've read, C# and the CLR were basically built for eachother, and C# is the purest and most complete expression of what the framework can handle).
Also, while you can do a lot by just changing keywords around, VB.NET contains some legacy mechanisms (there are two ways to cast bool to int, one of which produces -1 for True and one that produces 1, for backwards compatibility). Furthermore, since VB still has no really good conditional statement (IIf is a built-in function, and returns only a generic object, which is a pain and tends to need casting... oh, and the cast syntax is annoying) code tends to be longer, requiring either more lines or lots of horizontal viewing area. Their For loops are also partially crippled (no way to do things like
for (current = head; current != null && !(current.value.equals(searchItem)); current = current.next)
which, while a debatable coding practice, can reduce LOCs considerably and is preferred by some programmers in any case, just as some like
for (;;)
which I hate... and which is not possibly either in VB. This is a hassle for them even if I think they ought to use
while (true)
like the rest of us.) VB also uses = as both assignment operator and equality tester (to the point that you must use
if ( (current = current.next) == null)
or other little shortcuts that people are used to. VB doesn't require Delegates as explicitly, although you *might* be able to (so far I've gotten by with sloppier methods of raising/handling events, etc.) which can be a convenience (it took me a while to figure out how to trigger events in C#) but is also a crutch (inline functions, etc. can be handy tools that most VB programmers will never see).
In short, VB.NET is MS taking their "easy introduction to programming" language and pushing it into a powerful, full-featured runtime. They had to cut corners to do this, and it requires a fancier version of the CLR (this is why VB.NET on Mono is still incomplete, despite there being a compiler already; C# on Mono is pretty much fully
There's no place I could be, since I've found Serenity...
Okay, let's see:
h tml
;)
1. For the namespace thing, the answer is no. The variable is scoped to the local context. However, Java does have the concept of public/private members, and Python has no such distinction. We used a syntactical marker ('_foo') to show private members and counted on code reviews to catch transgressions. Because Python has an automated way of setting up getters/setters using the property keyword, this is mitigated somewhat.
2. Dynamic programming errors: the Python world has this neat utility called pychecker, which does a static compile-time check of everything and warns you about potential problems. It catches a LOT of stuff, much like it was a typed language. Also, read this: http://www.artima.com/intv/pycontract.html
3. Agreed about the scripting language stuff - I was being a bit tongue in cheek. To me, they're all just programming languages, and I choose the right one for the job. The great thing about Java isn't the language itself, which is pretty dull, but the incredible support - huge class libraries, J2EE servers, and so on.
4. Python's unofficial motto is "There's only one way to do it." The emphasis is on readability, which is why map and filter are supposedly being dumped, because list comprehensions do the same thing more readably. So you shouldn't be concerned on this front.
Here, read this for god's sake: http://dirtsimple.org/2004/12/python-is-not-java.
Washington/Idaho, eh? Strangely enough, I was nearly in Idaho this summer. I work well remotely, by the way
Should a language need practices like _foo and external utilities to do checking, or does the requirement imply that perhaps the language wasn't developted targetting the kind of work we are doing?
:) I don't remember the specifics so much as coming away from it just feeling that it was the same as the other scripting languages--targetted at quick throw-away code and not really worth enough to spend the extra time on, perhaps you could convince me otherwise.
/. or are interested in that position, my email is bill dot kress at gmail.
I think Python is neat, but for real work I just don't want a neat language. I want something booring, plain and predictable. I despise C++ in part for operator overloading (also templates and just the uglyness of the whole thing), but don't have a significant problem with C' simplicity on really small projects (Not that I'd choose it).
btw: I realize Java now has templates, and I think that's by far the biggest negative change java has made so far, possibly the ONLY negative change. Writing java classes to support templates requires an entire new, awkward syntax just to support it. Completely counter to everything I like about Java. Checked exceptions are on my hate list as well, but they've been there all along.
The part that interests me the most about Python is probably the neat array manipulation stuff (I forget what they call it--comprehensions?). I'm on the fence about it. On one hand, I think it might make one think differently about how he handles groups of objects which would be fantastic, on the other, now you have another way to do something (as opposed to iterating) that doesn't really gain much.
The shop I work for is very pro-XP so they are really looking for local people. If you have any networking/network management background I know a guy who is staffing up for a big project here and I don't believe he'd mind people working remotely.
I certianly enjoy talking to you, and i'm learning a bit. I think my next step is to go through python again and take notes on what was bothering me about it so much and forward them to you
If you want to pull this off
C# (or probably any language you can use with Visual Studio) can develop GUI's with the same level of effort... the only difference is in the procedural code and event handlers; the IDE writes all the GUI code for you. At that point it comes down to "Which VS language are you fastest/most productive/most familiar with?"
I'm not denying that Java is a reasonable choice for tis scenario; it is very readable and extremely portable. What most people don't realize is that the CLR (C# in particular) is nearly as portable to all the OS's you mentioned (okay, MacOS support takes a little work on deployment, but it runs perfectly on Linux and some Unixes... SUSE 10, for example, uses Mono for several integral programs.) C# also gives more control than Java (options for explicit memory management, function variables, etc.) and, unless you're using a JIT instead of the JVM, will often execute faster.
Oh, and speaking of "distributed client/server app involving tens of thousands of classes coded by dozens of people, reliable object transfer/messaging, and reliable easy access to various forms of communications" have you by any chance heard of a MMOG called of EVE-Online which, using "a special stackless version of Python" recently broke 30,000 concurrent users on one server?
There's no place I could be, since I've found Serenity...
VB: Used to be a fantastic environment for beginners. It NEVER let you see the generated form code--this is a massive improvement. Generated code should never be edited, just leads to confusion. I haven't checked lately, my guess is MS screwed this up when they moved VB to their workbench, so you're right. VB3 also had the best f1 help I've ever seen, whatever you want, you hit f1 and it always figured out the right context and quickly poped up a help screen for it. Library coverage, controls, keywords--all integrated. This was broken later, don't know if they fixed it again.
There is still a problem--newbies probably shouldn't use Java/C#. I'm not saying they shouldn't be trained in it, but people jumping into Java without having a clue what you are doing (Just because it's a simple looking language) has really given it a bad name because of all the crap apps developed.
For instance, the newb practice of throwing up a quick dialog box that blocks it's thread (the swing thread) makes most people think java GUI's are clunky. They're not, it's just that a lot of apps are written by people who don't understand swing or threading.
C#: good point, I didn't realize it was that portable, but the reason to use Java on such a project is system support for stuff like cross-platform object messaging and trasferring and application servers to reduce active object counts. Also, in the future I'd rather have my code base sitting on an infrastructure who's goal is to make the best system rather than one who's goal is to make the most marketable system.
EVE: Stackless version is like a J2EE applicaiton server. You end up with no data associated with your objects, so you're no longer in an OO system (Well, it depends on how you write your functions, you can use objects within functions...). At any rate, that's great, but they could have gone with an existing, free java appserver and saved them the trouble of writing their own stateless appserver.
That also means that they must have had to create their own redundancy/failover system. Not trivial, but now that they've done it maybe they will release a Python appserver--that's pretty much what happened with java.
PS: How do you get those cool comment bars in the reply?
Java does not have templates -- not even close. C++ templates are turing complete whereas Java's generics are a pathetic implementation of parametric polymorphism (which isn't even reflectable!). I you want to know why "full" templates are good, look no further than the STL or Boost. Along with free functions they achieve extensibility that the Java/C# people cannot even imagine. Btw, operator overloading has a lot to do with that extensibility, and until you understand that you haven't really understood C++.
That's not to say C++ is perfect. Far from it.
I'm not sure I follow your logic... How would forcing your poor programmers to switch languages make them better programmers? I think the best that you could hope for is that they'd still be poor programmers, just in a different language.
Besides, the Java Virtual Machine has just as many, if not more lanugages available for it than the CLR. (Note that I said "available" not "supported.")
This has become common knowledge amongst Python developers, to the point that many people forget where it came from. I was at the 9th International Python Conference where Bruce Eckel (author of Thinking in C++, Thinking in Java, Thinking in Patterns) gave the keynote speech, so it sticks with me that it came from him. See http://www.artima.com/intv/tipping.html for a good interview with him that gives some details into his experience with the langauge.
the growth in cynicism and rebellion has not been without cause
Its not the multi language nature of the CLR that is negative, it the programmers!! How is it that incompetent programmers are the responsibility of the CLR? "I have crappy programmer because the CLR implemented VB!" C'mon Plus, if there was no VB.NET you can bet your ass they'd still be using VB 6 and you'd be COM interoping your way to sadness. Plus.. a Bad VB programmer forced into C# is still a bad programmer.
the Microsoft PR machine does not claim that .NET is cross-platform. Mono is great but why do they exist??? Because M$ submitted the CLI to ECMA and Mono was born from implenting that spec.. so lets give M$ some credit (though im waiting for M$ to sue Novell now for MONO :) ) I agree about a platform being only as good as its Class libraries.
IronPython does run on Mono. .NET does not make python MS-only. I'm not sure i understand that. IronPython is compatable with much of the python standard library.. which will get better with time. If you don't need .NET then just use Python2.4+. Whats the beef there?
Personally being able to write/prototype .NET apps in Python is very exiting.
Implementing Python on
I know this post is old now, but I was scrolling back through it looking for some links and noticed the parent.
Boo is neat, but I call horseshit, as it is most certainly not a much better alternative. It might be a better alternative someday, but that day won't come until boo is stable, gets rid of some of its documented issues, and, more important than anything else, has VS.NET IDE integration with full debugger support, which is where IronPython is going to kick its ass for a good time to come.
Boo's language extensibility is neat, but certainly doesn't make up for the things it is lacking. I want to like it, I really do, but it's just not there yet.
Also, with regard to form-generated code, I must disagree slightly... while hiding it is good (and
There's no place I could be, since I've found Serenity...
I was just saying that for beginners, VB used to be easier because you couldn't access the generated code and I think your reply agreed with that point.
If one has gone beyond that, they should probably move to another platform. Once you are to the point where you are using control arrays and manually installing event handlers, you should probably move on to a more appropriate language--C# or something.
Honestly I detest the idea of editing generated code, it's just confusing and doesn't scale in any way (hard to maintain, easy to make it so it can't be loaded back into the orignal form editor, incompatible with future releases of the platform and typically they generate horrid code).
I've always wondered why the form designers don't just create the form class with all the controls public (or better yet, a getter to get the controls by name). You can add yourself as a listener to any of the objects and modify the properties without touching the class source code. It would also split the combined view/controller model that those generators always cause (sometimes enforce).
If I HAVE to use a form generator, I'll often use this technique, iterating through the controlls collection of the form looking for a certian name (from another class). The problem is that often the forms don't expose anything publicly, so even this is impossible without modifying the generated code to provide a getter or something.