Blue Sky Development
Preface
My point with this article is to document my thought process in choosing a development platform. I am not out to start a language war. I’m pretty comfortable that my facts are correct, and I know that my opinions are correct, because they are just opinions and they are mine. You may choose to disagree with my opinions, if you wish. If you do find a factual error in here, please do add a comment to the posting.
Introduction
Ahh,… wide-open, blue sky development, with no legacy to hold you down. Legacy code can be handy because it incorporates a lot of useful knowledge about your problem domain, even if the way it’s implemented makes you cringe. On the other hand, when you’re entering a whole new area, you get complete freedom to explore and to use the best current tools and practices.
What could be better than doing fresh development with no legacy? Having no legacy and being the boss, of course! Technology choices can be made on technical (and business) merit without politics getting in the way. If given a complete choice of tools platforms, would developers truly go for Java or .NET (or “legacy” Microsoft APIs) or would they choose LISP or Python or OCAML?
I would imagine that developers would be all over the map in terms of their ideal choices. Some would certainly pick one of the dominant platforms. Choosing Java for a project is not unreasonable, for a programmer that’s familiar with it. Java is reasonably high-level (most importantly, you don’t have to manage your own memory) and has lots of good open source libraries.
Some background
I’ve been largely working in Java for the past four years. There’s also been plenty of Perl mixed in there, and even a little PHP. Having worked in several languages, choosing Java straight away is not a slam dunk. Here are the characteristics of my app:
- Has a component that runs on desktops (consumer/individual business user)
- Likely maintaining a database in the tens of megabytes
- Has a web-based component
- Needs to support some level of plugins/scriping
- Needs to be cross-platform (I use both Macs and PCs)
- The app is not free.
Running on the desktop means that the application should not be too resource hungry, and the download size should be kept reasonable. I don’t think everyone has a JVM installed. It may not be too onerous to require people to install one, but that’s one more headache. People are a lot less inclined to buy something if they need to jump through hurdles. I can probably get away with static compilation with gcj so that people don’t need a JRE. It’s nice to have that option.
Lots to choose from
Embeddable databases are available for Java (Derby, Axion, HSQL, plus a number of non-SQL databases). Embedding a webserver with Java is easy. Supporting scripting and plugins is easy, with the many good choices. Java is certainly cross-platform.
So, Java meets all of the criteria required for the app. So does Perl. So does Python. So does Ruby. Heck, so does Squeak Smalltalk. CompSci is all about tradeoffs, so I need to look at the tradeoffs between these choices.
I love Perl for quick, one-off scripts. I hate it for anything else. Perl is very easy to write, because there are so many ways to accomplish something. Just use the first that comes to mind. Perl is a pain to read because of that same reason. Your mind actually has more work to do to figure out what that piece of code you wrote three months ago does. And, if you didn’t write that code, it takes even more thought.
Ruby looks nice and Rails is attracting a lot of attention for good reason. Seaside on Squeak should be attracting attention, because it looks like a very productive way to put together apps. There are two problems with both of these: 1) I don’t know them, and 2) they are less mature and have smaller communities than Python or Java. I can certainly overcome (1), but that would slow me down initially. The clock is ticking, because I need to generate money to pay my mortgage and all that… The second point also means slower velocity: there are fewer places to turn for help. There are fewer prepackaged modules, and those modules may be less-tested.
That brings me to Python. I’ve used Python on and off since ‘95, so I have a comfortable familiarity with it. My last go at self-employment was based on work in Python. That was five years ago, though, so there are some new things I need to pick up. I think there are some Java-isms to unlearn as well. But, the ramp-up time with Python would not be as great as with a language that I haven’t worked in.
Java-the-language
A bit of opinion: Java sucks. Not Java-the-platform, but Java-the-language. First of all, there’s the whole static vs. dynamic typing argument. Going beyond that, though… static typing in Java is not as safe as it could be. Until Java 5, Collections were dynamically typed constructs (with the annoying extra typing of doing a cast). Autoboxing in Java 5 is a nice convenience feature to avoid manual casting and conversion, but it leaves some ambiguity about what happens if you have a null value.
Java is practically unusable without an IDE, because Java’s implementation of static typing requires a lot of keyboard typing on the part of the programmer. It doesn’t have to be that way. Some statically typed languages use type inference, because the compiler can often figure out exactly what you mean without requiring you to type it in. Here’s an example:
String foo = bar.toString();
The compiler knows that bar.toString() returns a String, and yet you still have to type String at the beginning of the line.
Java doesn’t support operator overloading. Many people call this a good thing, largely because operator overloading can be and certainly has been abused. But, because of this, using a Map requires mapName.get(key) and mapName.put(key, value), rather than the more natural mapName[key] and mapName[key] = value.
Java doesn’t have first-class functions and reflection can be somewhat painful to use. You’re forced to create an interface for every kind of operation that you might want to be able to perform (for example, Comparator). If you use reflection, you have to deal with the painful syntax and you lose your static typing.
Java doesn’t have any kind of multiple inheritance, so mixing in behavior requires using AOP, static utility methods, or using composition and delegation. I do understand how multiple inheritance complicates things, but Java doesn’t provide any convenient mechanism for sharing behavior. Java 5 static imports do provide one mechanism to help here, which is a good start.
Making the distinction between Java-the-language and Java-the-platform is an important distinction. The Nice language fixes all of these Java language problems with the exception of operator overloading. Groovy even includes operator overloading and the ability to be dynamically typed. I’ll come back to these two choices.
What about performance
Java is fast. That’s the bonus you get from static typing… many operations can just become a quick lookup or jump to a memory location. In Python, every name lookup essentially requires a hash lookup. While this is an O(1) operation, it’s still going to be slower than memory referencing.
I can’t find the reference now, but I recently saw someone write that making a language choice based upon performance is the ultimate premature optimization. As long as there are ways to get acceptable performance, the language should be chosen based upon the expected level of productivity.
So, what about Python’s performance? Many people have called it “slow”. I don’t think Python is slow. Sure, it’s slower than Java. But, it’s fast enough on even late-’90s hardware to do many tasks at a speed that is comfortable to users. Depending on your specific needs, Ian Bicking offers some tips for improving your performance without leaving Python.
Let’s assume that Python is still too slow for something you’re trying to do. If you’re using an x86 machine, you can use Psyco to speed up parts of your code with a trivial amount of work. I’m not only targeting x86, though. For me, there’s Pyrex, which looks kinda like Python, but compiles into C extension modules.
Finally, it’s worth pointing out that a lot of heavy lifting in Python is done in C code (and much of that C code is tried-and-true, having been around for a long time). Python itself is written in C, so things like hashtable lookup are as fast as they’re likely to get. If you want to add something like encryption to your app, that would most likely be done by adding a C extension module. This helps contribute to the notion that putting together an app in Python is likely to be fast enough. In fact, Python is popular in scientific circles because it’s easy to write code in and experiment, while the parts that need to be fast are written in C and are plenty fast.
The JVM is fast. Dynamic languages, like Groovy, incur the same kind of overhead that Python does, since name resolution needs to be done at runtime. One nice thing about JVM languages is that if you need more performance, you just switch that bit of code over to Java. That would certainly seem easier than moving that bit of code into C. (Pyrex mitigates this a bit, though.)
The JVM has been shown to be almost as fast as C, but not quite. So, a dynamic language on the JVM will likely be a little slower than a dynamic language implemented in C. Similarly, optimized modules in C will likely be faster than those written in Java. Despite the fact that Python is, without question, slower than Java, I think there are enough optimization options that most apps can reach the performance level needed.
Packaging Options
Sun really wants people to have a JVM installed (just as Microsoft wants everyone to have the .NET Runtime). Maybe there are enough people with the JVM installed now that it really isn’t an issue.
Sun has improved desktop integration considerably, which is important for making usable, consumer-oriented products. Kudos on that count.
Though Sun may not like it, the Azureus folks have shown how good Java packaging can be. They used GCJ and SWT to create a solid app that feels like it belongs on the Mac or PC that you’re using.
Python has great desktop integration (you can call Windows and Mac APIs directly, and wxPython provides cross-platform GUIs). Extra nice, though, is that people have put together py2exe and py2app that create standalone Windows and Mac apps, respectively. Since the Python interpreter is bundled right into the executable, you don’t lose any of Python’s dynamic nature.
Final thoughts
I’m sure it’s clear by now that I chose Python to implement my project. Of key importance is productivity, and I think that dynamic languages win in that regard. Though I’m using Python, there are plenty of good languages to choose from. Even if you’re targeting the Java platform, I’d recommend checking out the dynamic languages that are available. Some of them are more mature than you might expect and, since they’re written in Java, it’s usually quite easy to figure out how they work and decide if you like the implementation.
Every project has its own requirements. If you’re lucky, you’ll be free to choose the right tools for the job.
I’ve been writing Java for over 5 years using gvim and never had a problem typing type names. In fact, typing the name of a type while declaring a variale is not even 1% of the amount of work involved in writing an application. Being able to avoid typing type names is a pointless optimization.
You could code in assembler; there’s no types there. You could write in PERL, there’s no types there.
The expressiveness of non-statically types languages has nothing to do with the fact that you don’t need to declare variables.
You also are forgetting to consider maintainability. Using some obscure wacky language (which I defined to be something other than C, C++, Java, PERL, PHP, or something from M$) is gonna make it that much harder to find people who can work on the code.
And what about Jython?
[I'm just curious because I didn't use it in production]
I only briefly mentioned the finger typing aspect of Java, because I agree that having to declare the types is only a part of what makes languages like Python quicker to use. The other benefits you get from judicious operator overloading, multiple inheritance, dynamic message passing and creation, etc. are a bigger deal.
My goal is to be productive. Working in assembler, while fun at times, is not productive. Particularly if you’re angling for a cross-platform app.
I did talk about Perl. Perl is the fastest way to write code that I’ve seen, but writing maintainable and readable code in Perl is almost unnatural. If you subscribe to the notion that code is read more than written, going with a more naturally readable language seems like a good bet.
Your point about getting people to work on the code is one that I did not address in my article. Though Python is not *that* obscure, I’m sure that finding people with Python on their resumes is more difficult than finding folks with Java on their resumes.
I’m more interested in seeing people who have object oriented design and automated testing experience on their resume. Picking up the Python syntax and learning the Python standard library would be easy for any good programmer.
Even though Perl and PHP are similar to Python in their dynamic properties, I would be more likely to hire a Java programmer who has been doing real OO programming and that has been actively writing unit tests.
Computer science is all about tradeoffs, and language choice is definitely one of those things that heads into the realm of unprovable opinion… which is why I wanted to document my choice without getting into a language war. If something is factually inaccurate, I’d be happy to make a correction.
Kevin
This article could have used a bit more specific discussion of Java-the-platform vs. Python-the-platform (if you can call what Python has a platform).
Jython is a nice piece of software and I used it extensively in 2001. Its development has lagged considerably behind Python’s. Python 2.4 just came out, and the Jython folks are still working on the 2.2 version. Admittedly, Python 2.2 had very significant architectural changes, so it’s not surprising that the Jython leads would need some time to implement those.
Those 2.2 changes mean that many Python modules wouldn’t work with Jython. Why is this a big deal?
Part of what makes Python efficient to work with is the way the modules are designed. They’re generally quick and simple to use and don’t require many layers of instantiation and configuration.
Though I stand by what I said in my last comment about how learning Python is easy, I’ll add that with a few weeks of use you come to understand the term “Pythonic”. There are certain ways of doing things in Java that are common conventions, and users of Python have their own ways of doing things. That’s where a lot of the productivity gain comes from… it’s not just the language, but also how the language is used. And, that’s why it’s important to be able to use Python modules.
So, I opted to not use Jython because I’ll be more productive with the Python way of doing things, and CPython lets me access many libraries that I cannot currently access in Jython.
First of all, great article. I am a huge fan of Python for many of the same reasons that you mentioned above. I have also been writing Java code since the very beginning, and while I have had some great successes in Java, its rarely my language of choice.
Now, on to the commenter above (Dave):
You are correct that not having to “type” the type names is not really important. Its not important at all. The whole point is that being a static language like Java prevents you from all sort of solutions that you could use if you were using a dynamic language like Python.
> You also are forgetting to consider
> maintainability. Using some obscure wacky
> language (which I defined to be something other
> than C, C++, Java, PERL, PHP, or something from
> M$) is gonna make it that much harder to find
> people who can work on the code.
Number 1: Python is not a “wacky” or “obscure” language. It is on the same level as Perl in terms of its distribution and use, and why does this matter? I can find millions of Java/.NET drones in India and pay them nothing to write shitty code. In my experience, people that know and embrace many languages, and know when to use the right tool for the job are way smarter anyway. This is only my opinion, but it seems to be shared by others, and has been very well supported in my experiences.
On top of this Python code is more maintainable than Java because:
1. There will almost always be far less of it than a
comparable Java application. Less code means
less code to maintain.
2. The solution will likely be simpler because
Python allows you to focus on the problem,
and you work with it, not around it.
3. Python code is more readable. Even if you
know Java, and have never seen Python, code
in Python is far more readable than code written
in Java. This is one of the main strengths of
Python over other languages (Perl, Java, etc).
Honestly, you have never written code in Python (since you call it “obscure” and “wacky”) so you really have no place or knowledge to speak on the issue. Try learning Python — it will probably take you less than an hour to get your feet wet, and you might be surprised by what you find.
I work for a company that has significant amounts of Python code deployed in the world, along with lots of Java code. I can tell you that the Python products really shine (even when compared to our own Java apps).
Now, Python isn’t perfect for every project, but having more than one language in your tool belt will always help you to come up with a better solution to your problems.
Python is also popular in scientific circles because we can start with folk with little or no formal programming training, and they can become productive python programmers very quickly. Sure we can do the same with Perl, but we can never maintain the resulting code …
Also, we find that python with numeric is twice as fast as java for real calculations …
1) How do you protect Python apps from copyright abusers?
2) Py2exe works, but if one expects Python already installed: which version of Python? Which version of Java? .net?
3) It is not easy to write C extensions to Python programmer. It is easy for C/C++ programmer pick up Python, but not other way around.
This [The app is not free.] part also makes me wonder, could you elaborate?
/Every sufficiently large C++ program is worth to start writing in Python./
Thanks for the comments, all. Good questions, Girts.
> 1) How do you protect Python apps from copyright abusers?
This is a good topic for another article. In general, you’d protect Python apps the same way you would any other app. I believe that if you’re making software for which there is a real market, marketing is a far bigger problem than piracy. It’s worth taking some measures to avoid and stop piracy, but spending too much time on that is time away from improving the product and marketing it.
> 2) Py2exe works, but if one expects Python already installed: which version of Python? Which version of Java? .net?
Actually, py2exe makes *standalone* apps. The Python interpreter gets included in the package. No version problems, no worrying about whether the user has Python. Just one installer to run, and they’re all set!
> 3) It is not easy to write C extensions to Python programmer. It is easy for C/C++ programmer pick up Python, but not other way around.
Writing a C extension is really a last resort. As I mentioned in the article, there are two native code optimization strategies that don’t involve C: Psyco (on x86 machines) and Pyrex (everywhere). Pyrex looks very similar to Python but translates to C, making it easy to speed up tight loops. There are very few spots in a typical application that really need that kind of speed, so you can isolate that as much as possible and then just rewrite that part in Pyrex (or C, as a last resort).
I’d like to respond to the question, “How do you protect Python apps from copyright abusers?”
First of all, if you just want to obfuscate your code, you can distribute the compiled Python files without the original source code (the compiled files have a .pyc extension). This provides a simple way to keep people from copying your source or stealing your algorithms. Remember that compiled executables can be disassembled, and I’m sure there are similar tricks for Java byte-code files.
As far as making sure that every person who uses the program has paid for it, I don’t think any anti-piracy measures will protect you from a determined software pirate, regardless of your implementation language.
Nick
I write Perl code all the time that is easy to read and maintainable. I don’t know why people keep harping on that. Ah, maybe the same reason people keep saying Java is slow? Old perceptions die hard.
I’ve written plenty of Perl code through the years, and it’s still my language of choice for quick one-off scripts. I’ve written well-structured, OO Perl programs and I do agree that Perl is certainly capable of not being hackish.
The problem is the very slogan “There’s More Than One Way To Do It”. Sure, there are multiple ways to do everything in every language. In Perl, though, there isn’t really an obvious route that every programmer would take. Reading your own Perl code may be fine, because it was written in a way that matches your brain. Reading someone else’s Perl code may be more work, though, because they will probably use language constructs that you don’t use as often.
I also find Perl’s particular punctuation constructs to be less pleasant to read than Python’s. This whole comment is strictly my opinion, though. YMMV.
Jython is just another prove how completely visionless and stupid Sun is. They completely missed the evolution of software development in the last years, heading into integration of scripting (typeless) languages and by that way lost their complete headstart against MS. MS now has the “inventor” of IronPython on its payroll (and is also investigating in a ML for .NET) and Jython is still versions behind CPython.
Maybe Groovy will catch up in 2015
“Actually, py2exe makes *standalone* apps. The Python interpreter gets included in the package. No version problems, no worrying about whether the user has Python. Just one installer to run, and they’re all set!”
I agree with that. py2exe has it’s quirks, but that works.
What I asked is how do you manage on MacOsX, and other *xes When you expect interpreter installed? You can obviously install several interpreters (several python/.net/java versions).
Deploying and updating several versions of software, that depends on various independent components is generaly hard problem.
Compiled exe files somehow fix it, but they also depend on some ‘windows runtime’ installed.
As with ‘copy protection’, that’s our business. I have to talk to CEO, who is selling copyprotection solutions and tell that python program is opensource. Even when it’s bytecompiled and zipped with py2exe.
py2app has an option to bundle a Python interpreter in your Mac OS X, just like py2exe will. That gets around version problems. As far as other *xes, I’m not yet convinced that there’s a market for my product there. If I get requests for Linux version (and I’ll certainly leave the door open for that), I’ll figure out packaging then.
Java and Python bytecode can both certainly be decompiled. That is not my number one concern. It is my plan to provide good value and good incentives for people to buy my product.
I just want to recommend you trying Ruby on Rails. Make a small project, one you approximate to take about two weeks to get done. Four-five days later, having finished the project far sooner than you expected, you’ll _begin_ to figure out some of the inner workings and intricacies, but you’ve already managed to write a neat webapp, even though you don’t know that much yet. Rails lets you do that, it let’s you produce stuff even though you barely know Rails nor Ruby.
Take it from me, I know — I mean I _don’t know_ neither Ruby nor Rails very well — and yet my first project is half finished, in less than half the time it would have taken me to develop it using a language or environment I’m more familiar with. That’s because you spend much less time fighting with the language — which requires knowledge and experience in it — and more time just building logical constructs and flows, no hassle.
Try Rails for real, you will not regret it.
I followed David’s trackback earlier and realized that I had shortchanged writing about an important part of my decision-making process. Here’s the followup:
http://www.blueskyonmars.com/archives/2004/12/31/followup_to_blue_sky_development_looking_at_alternatives.html
So, I did scrutinize Rails before making my choice, but there were other considerations beyond language and web frameworks involved in my Python choice. (Check out the other story above for the details)
cx_Freeze is supposedly roughly equivalent to py2exe in functionality for Linux (and Win32, actually).
With or without a distribution tool, distributing non-free software for *BSD/Linux (without also distributing the OS) is one hell of a job - good luck if you attempt it!
It gives me a headache just trying to envision packaging up my app for the Linux “market”. If I become convinced that there is a market there, I’ll think about it further… but, there are so many different distros, each with their own idiosyncracies. There’s even two major competing GUIs.
My app is a consumer app. I think it would appeal to Linux geeks, but probably not enough of them to warrant the effort.
Kevin Dangoor writes:
> I love Perl for quick, one-off scripts. I hate it for anything else.
> Perl is very easy to write, because there are so many ways to
> accomplish something. Just use the first that comes to mind. Perl is
> a pain to read because of that same reason. Your mind actually has
> more work to do to figure out what that piece of code you wrote
> three months ago does. And, if you didn’t write that code, it takes
> even more thought.
As a long time Perl programmer I find this argument a bit perplexing. My comments that follow are less an attempt to contest your assertion and more to solicit feedback so I can understand this line of thinking better.
It’s not that the general idea is inaccurate. You can certainly write illegible code in Perl, and given Perl’s efficiency, you can write bad code faster.
But you can write illegible code in Java or Python too, just that it might take more lines of code to reach the same level of complexity.
Part of what Perl suffers from is being a language with a wide dynamic range. Its heritage goes back to being a replacement for sed and awk and was used to write system administration scripts. Over the years it has grown up into being an OO language that regularly gets used on 10,000 line projects.
While I consider the wide dynamic range to be a great advantage, it does open up the possibility for inappropriate use. If you’re writing a large application and you’re using automatic iterator variables ($_) all over the place, you’re writing bad code.
On an individual statement level you might be able to write functionally equivalent code in more different ways with Perl than with other languages, but take a step back to the function (method) level and it seems like you’re facing the same problem in any language - the programmer can choose to implement common functionality in dozens of different (and non-standard) ways.
To me either of these problems can be addressed with software engineering practices, coding style guides, and discipline (and of course code reuse). A programming language should be about making things possible, easy, and efficient, not boxing in the programmer to constrain their choices - no? Perl lets me write illegible code, sure, but it doesn’t prevent me from writing maintainable code. And it doesn’t make doing so hard, once you get past the idea that the compiler isn’t a style enforcer.
I do keep my eyes open for new technologies that provide real benefits. It’d be foolish to ignore something that could improve ones coding efficiency. (I’m currently looking at Ruby on Rails.) But in casual research into Python, the impression I get is that it is Perl cleaned up to appease suits. That doesn’t strike me as a compelling reason to chose a language. (I’d be happy to see URLs to more compelling reasons.)
What would have made far more sense to me is if someone had developed a compiler pragma or source filter for Perl that “cleaned up” the language. Then you’ve got the benefit of CPAN, a highly optimized compiler/interpreter, widely ported platform, a large based of programmers, etc.
To an extent this may end up happening in the future, as there are already efforts under way to port many of these languages to run on Perl’s Parrot virtual machine.
> I also find Perl’s particular punctuation constructs to be less
> pleasant to read than Python’s. This whole comment is strictly my
> opinion, though. YMMV.
Personal preference for Python’s aesthetics is something I’ve seen cited before, and I wouldn’t fault anyone for choosing a language on that basis, but there needs to be more benefits to the core language to make it compelling to switch to if you’re already well invested in another language that efficiently addresses the same problem space.
It’s the way of open source to have competitive solutions to similar problems, but a concern I have is that the alternative (not Microsoft, Java, or C/C++), dynamic language market is being unnecessarily fragmented to their own detriment.
These days if a company is enlightened enough to try out something more efficient than Java they have to choose among Perl, Python, PHP, and now to a greater extent Ruby. It’s not practical to develop expertise in all of these languages, and the result is that the programming community is smaller for each, and the market for support tools is smaller, both of which make these languages less appealing to corporations.
I’m obviously Perl centric, but I do wonder what the market might have been like if instead of PHP, we had a Perl module for Apache that was easier to install than mod_perl (which was not so easy back in the early days), bundled with a templating package and a web framework. If instead of Python, Guido van Rossum applied his ideas to refining the syntax of Perl 6 or writing a pragma for Perl 5. If instead of Rails being written in Ruby, it was developed on Perl. (Though I hear it’s been ported.)
-Tom
Thanks for the long and thoughtful comment, Tom.
The problem that I have with Perl is what I talk about in my comment of December 30th. Larry Wall comes from a linguistic background and made a language that “fits the brain”. The slogan “there’s more than one way to do it” represents a big asset of Perl, as well as a big liability. When writing a quick script, Perl is probably the fastest there is because nearly everything can be done in several different ways. The first thing that comes to mind will get the job done. But, when it comes to reading other people’s code, there are so many possible ways to do many things that it often takes a bit of thought to piece together what someone else is doing with their Perl code.
I’m not talking about basic readability (good variable names, etc). I’m talking about how Perl offers different, but equal, ways of doing many things.
Python, on the other hand, is designed with the philosophy of offering one “Pythonic” way of doing things. When you learn Python, most Python code is easily readable because the same idioms and tools are used all over. The past couple of Python versions have added some features that reduce the usefulness of other features that will likely be deprecated, but the philosophy generally holds and has served Python well.
PHP, Python, Perl and Ruby were all created with different ideas in mind. Those ideas all have merit, which is why they have all been successful. Those ideas are often sometimes in conflict with one another, which is why we’re not likely to see an uber language that makes everyone happy. (Lisp people would probably figure that they have the ultimate uber language)
Regarding Python’s aesthetics, you’re absolutely correct that there needs to be more to it than that in order to make a reasonable choice of development tools. Visual Basic is a hideous language, but I can understand why people use it.
It might be interesting to wonder what it would be like if there was one dynamic language, but that’s certainly not the scenario we have and it’s not one that will ever be. It’s worth noting that even in the static platform worlds (.NET and Java), there is fragmentation among dynamic languages (Boo and IronPython on .NET, Groovy, Nice, Jython, etc. on Java). The advantage they have is the interoperability provided by the underlying platform.
To some extent, Ruby, PHP, Perl and Python also have interop with baseline C code because of tools like SWIG. Quite a bit of C code is made available to all of the dynamic languages because of wrapper tools.
By the way, rather than applying his ideas to Perl 6, GvR has learned from watching Perl 6 development. There’s been talking of a fabled “Python 3000″ that will be less concerned with backward compatibility… and, at least partly because of Perl 6, I’ve gathered that Python 3000 will come to be incrementally rather than in one fell swoop. Perl 6 has been in development a *long* time.