language parallax

A while back I posted something on parrot. Recently someone stopped by to ask for a little more detail on that opinion.

First I should say that I haven’t done anything with Parrot since the very early days when things were very much still in flux and you could barely do arithmetic with the thing. I know it’s come a long way since.

I’m guessing that nowadays it solves the problems that it wants to solve very well. It’s just that those problems are not those that have been high priority for me.

My understanding is that parrot is a “fast virtual machine for dynamic languages”. That is its primary offering. I can see how that makes things easier for developers of dynamic languages (perl, python, as well as custom languages).

I’m coming at this from two perspectives. The first is as a developer of web applications in environments with a lot of people and rapidly changing requirements. The second is as a researcher.

After years of battling language wars, I now take the view that I may not have much (or any) control over what language will be used in any particular job. I need tools and methodologies that can adapt and apply to the range of situations I may encounter. That includes strongly typed languages as well as dynamic languages.

As I mentioned in the original post, “declarative language descriptors”, would be a big part of this. I’ve come to learn that this is a piece of what “metametamodeling” is about (though I still think I like the term “programming language universal grammar” (PLUG) better).

With that kind of framework, we get this:

* Distributing standard sets of fast, correct program transformations (including refactorings) along with the languages themselves
* IDE’s that can implement those transformations
* Custom transformation authoring
* Custom DSL authoring
* Binding DSL transformations to platform transformations (structured co-evolution)
* Better integration of source code control

My experience with complex architecture is that no matter how elegant the underlying technologies and languages are, the real pain is in tying them together. The marketing behind Parrot is seductively close to addressing this problem. But when I look close at what “tying them together” means, I see issues with refactoring, version control, and deployment, which is not really what Parrot is going after.

It’s still an ongoing search, but most of my attention is now focused on particular techniques within model-driven software engineering that lead to the need for “model to model” (m2m) languages like QVT.

One way in which Parrot could actually help perl move in this direction is by cleaning up perl interpreter so that it is easier to create better support for refactoring. I’ve used EPIC (the perl plugin for Eclipse) before and pretty much stopped after a couple nights after I realized how limited it was. I would guess that a parrot-based perl would be much easier to analyze and transform. However: To really help me with the range of architectures I work with, I would need Parrot capable of describing a larger class of languages as well automatically providing IDE, refactoring, and versioning support for those languages.