in reply to Re^2: Perl 6 and CPAN
in thread The Perl Hacker Inferiority Complex
It is possible for multiple languages to agree on a shared calling convention, and hide all mismatches behind their different object types; that's what the PMC design set out to do, and it's a reasonable solution to that problem. It is also possible to implement things in the most general possible way (e.g. resumable continuations for exceptions), and all high-level languages then build their specific ways based on them.
Based on my own experience in targeting Parrot, and also because I've seen how they are solved in CLR, I think Sam's problems have technical solutions, and the design of Parrot is sound.
However, JVM and CLR are getting much better support for dynamic languages in their upcoming versions (especially CLR, now both VB and IronPython people are pushing it): Features such as AUTOLOAD, per-object methods, and constraints on dynamically-typed variables are finding their way into CLR. It's also possible to add runtime resolution to CLR's already Perl6-compatible static MMD (known as "method overloading" there).
Jython and IronPython exist for a reason -- Python people want to access the existing libraries readily available in both cultures. Furthermore, I think CLR people did a pretty good job in coming up with a BCL (Base Class Libraries) that are larger than Python's core library, so it's reasonably easy to reimplement the standard Python libraries on top of them.
Parrot doesn't yet have the equivalence of BCL, so the language implementor's job is much harder. However, the Tcl people are working on that (e.g. the OS.pmc for files and directories handling), so there is indeed progress.