Ted Leung brings up some important points and collects some good links in his latest post. To quote:
Once they [MS] get everything into managed code, people working in predominantly unmanaged environments are going to be hard pressed to keep up.While I agree with the general sentiment, I think the FS/OSS communities aren't being left behind, but they aren't doing it by following a commercial effort. To me, Python is the response to managed code (maybe one of several responses, but I also believe the most important response).
Right now I believe Python is a clear forerunner among high-level languages. It might be elitist, but I don't consider Perl to be high level, or to be a successful general application development language; PHP is both low level and still solidly server-side; Object C has some newfound potential, but it still skirts the high level/low level border... which leaves Java (2500 projects on Freshmeat as opposed to 1200 Python projects). I'll let you decide on Java's potential on your own. (I know why I like and can distinguish Python from Java, I don't know why I would distinguish C#'s "managed code" from Java's model -- which isn't necessarily praise of Java!)
Anyway, to return to our topic, I see high level languages as the future for development. At the same time, using Python we don't have to forgo our low level roots by using C extensions (the old Worse is Better cliche [truism?]). This layered system gives us the potential to build wonderful and beautiful new things, without reimplementing every little thing everytime we make another go at figuring out what "beautiful" means. I see the goal as a place where, struck with a notion for a new program (novel or just customized) a developer can implement, reimplement, refactor, and redesign quickly. Our applications come and go, they become important and obsolete over time -- but as long as our fundamental foundation becomes further enriched, further refined, even just further understood we will still have accomplished something. I imagine the wonderful applications emerging from our communities as a matter of course -- when the prerequesites have been created, those applications will appear, and their emergence will seem more inevitable than dramatic.
I think high level languages have made significant progress as well. Python programs are popping up all over the place, both in core tools and end-user applications. (And it's probably about time people start dropping the "py" prefix from application names -- it's like a qualifier, and the time has come that appications don't need to be qualified by this implementation language, Python has become a basic piece of the OS infrastructure, not a novel prerequisite)
Python programming also makes backward compatibility issues very manageable. The core has been successfully backward compatible, and even when there are issues with third-party library compatibility it is usually quite easy to work around those issues (much like Python makes it easy to work around OS differences). Python provides all the fundamental tools to handle problems as they come up -- things like exceptions, introspection, or even the crudeness of sys.path manipulation to get known versions of libraries. (Relatedly, I believe Javascript's greatest flaw has not been its lack of standardization, but the lack of the fundamental programming constructs to work around those problems) I believe Python provides (right now) a much more robust and flexible technology for platform independence than found in Java (and probably .NET) -- I think the same will be revealed in terms of backward compatibility.
Which is all to say: I'm optimistic. People complain that we just copy commercial software and designs -- but if you think we should do more you should look for the ways people are already innovating, not expect the open source/free software community to innovate in the same way as commercial development. Our path has always been dramatically different than Microsoft's, and it's gotten us this far.
One of the biggest problem for dynamic language (say python) is design time support.
For example, in C#, after you define the
datatype for ISomething, when you type the
variable name, the editor can pop up a list
of functions that are available for this
variable. In python, you have to look up
the document to see what function is supported since datatype is determited at
runtime. The same is true for a good
GUI builder system.
Chong
# chong
# chong
That's why you should develop most of your Python code in the interactive interpreter, which CAN show you the auto-complete information (PyCrust does a particularly good job of this, and IPython is very neat as well). It gives you the additional benefit of testing every single line of code as you write it. Once you've got it working right, copy it in to your editor.
While I agree with most of what you've said and would like to agree with the rest, I have to say that backwards compatibility has been a nightmare. This is not because the language hasn't been generally backwards compatible, but because of the internals and install.
When you upgrade Python on a Red Hat Linux box, everything may stop working. It turns out that the 'python' in the path is now /usr/lib/python2.2 (or whatever) which doesn't have the same site-packages. Fine, try to find the same packages and re-install them. Oops, half of them aren't recompiled for 2.2/2.3, etc. Recompile? You can copy the packages to the new site-packages directory, but then you get warnings (must go turn those off *in the code?!* or in another site.py!) and sometimes crashes.
The C interface is terrible. The old style/new style dichotimity is a nightmare. (Note to people starting a new language project: Make sure you plan for binary upgrades.)
We need a "final" binary format that will allow the C code to be upwards compatible, not forcing new versions to be backwards compatible. That's looking at the problem backwards.
Once that is accomplished, we need a *global* site package directory that all versions can use.
New versions should *replace* old versions, not co-exist. (Obviously co-existing should be supported, but the old version should be moved from the "default" install.)
I'm sure there's more -- this is off the top of my head.
.NET (and C#) is not so bad
As far as I understood the .NET framework, they mixed up Java, Python and C++ and tried to get the best out of each language. The framework itself seems to be very powerful, since it lets a developer decide, which language he will actually use. In a year or two, the Python .NET project will be able to convert Python Code to the intermediate language as well.
I am happy about all this, because this would make our life in the *bad* windows world hopefully so much easier in the future!
Imagine no more COM, but clear and easy-to-use interfaces to Windows!
For example, if a Windows C# Developer must have to write a interface to an Python-Application, this should be easy to solve with .NET.
But to be honest: I myself do not believe, that .NET works, because Windows itself is a pain.