Programming, Software and Code

whiteknight:

I think this is a good outline and is similar to ideas I heard in discussions with allison and dukeleto and at the Gathering last week in Portland.

I agree that we need users and that the needs/demands of users has to guide our development. As we develop users, I suspect that the Product Management team will have to recruit particular members as to manage our relationships with individual major users. Concretely, right now that means recruiting someone to be our 'relationship manager' with Perl 6. If we get an implementation of Python, then we'll need such a liaison to the Python community. And so forth.

PART 1
---------

Hi, Whitenight

Sometimes, I log onto the #parrot channel under the pseudonym "shockwave".

I would like to say that I've read a few of your blog posts regarding the Parrot project and they feel like a breath of fresh air. I specially like your openness regarding your perceived state of Parrot. Like you, I feel that open discussion regarding the merits and shortcommings of Parrot is the only way to build a truly solid, long lasting foundation upon which others can base their work.

I'll take this oportunity to give some 'user feedback'. I'm sorry if there is a better place for this kind of discourse than as a reply to your article. If so, please feel free to migrate this feedback to such place and place a link to it here, instead. Myself, I couldn't find a more suitable place.

I've been working on a new programming language, and an implementation for it (in the form of a compiler), targetting Parrot for about 14 months. The language is designed to be embeeded in C++ applications needing support for a high level language. It's statically typed, with C++/Java like syntax. I'm under a time constraint: this language will be used to write the AI for some video games I'll be working on, hopefully sooner rather than later. This language will be interfacing with an off-the-self 3d game engine. This new language is not the end product; the games are.

About a month ago, I had come to a point where I felt I had enough completed to actually start making use of the language. I had over 6500 validation tests, a language specification about 70% done (for first draft), and, most importantly, a compiler that properly translated the language into PIR. Needless to say, the compiler performs its necessary duties properly, including parsing and complete semantic analysis. As far as I knew, things were ready to go. I only needed to connect the Parrot and the 3D engine's runtime, and possibly write some glue code to interface custom C++ libs with Parrot. But, it turned out not to be so easy.

What follows are some critical words. I don't mean to be offensive, specially to any individual. I'm only trying to get some things across as viewed from my perspective.

[CRITIQUE]
I started to have issues embedding Parrot as soon as I tried to embed it.

First, there's barely any documentation for embedding it. Most of the documentation I found was just the listing of function prototypes. The actual embedding documentation is not much, and of the little there is, its duplicated and outdated. Parrot has some pretty good documentation but it needs to be kept up-to-date. If it were not for the helpful support of some fellas under the #parrot channel, I don't know if I would have been able to find my way around. The tutorial and PDDs are specially important. To be clear, Parrot is something designed to be embeeded, and there is no documentation on how to do that. That's not good.

One of the people on #parrot said something like "use Parrot_load_bytecode(), IIRC, that's what I used when I tried it." While I appreciate the help (and I do really mean that), its not very encouraging when the documentation for that functions says this:

"void Parrot_load_bytecode(PARROT_INTERP, STRING *path)
Reads and load Parrot bytecode ... . Due to the void return type, the behavior of this function on error is unclear."

Basically, if a file doesn't exist, the program state then becomes undefined. Not good.

Following the documentation, I couldn't get Parrot to load a PBC (Parrot ByteCode) my compiler had created. I tried different ways, different functions, but nothing. I know the bytecode could run because when I ran it from the command line using the Parrot executable, it ran well. I know there's a million reasons why it didn't run, and that the error could have been PICNIC -- but, c'mon; it shouldn't be that hard. And this time, people in #parrot didn't have the answers. What made debugging the issue even worst was that...

Parrot seems to be built with a command line mentality. Not all the actual users(end-users, not developers) of Parrot will be running the end product from a command line. The video game engine I'm using, for example, runs under Windows, MacOS, XBox 360, and PS3. I'm trying to run it from Windows 7, as a GUI application; the errors are outputed to nowhere. Parrot can't just spit out error messages to the command line and expect that they will always be seen. There's no built-in way to place the errors in buffer, so that I could choose how to print those errors. And because this is being loaded by library X, which loads library A through ad-infinitum, which finally loads libparrot, this thing can't be stepped through using the debugger (but this is not Parrot's issue).

PART 3
-----------

I have so say that after spending a full day trying to get that to work, I wasn't trilled with Parrot.

It's been 10 years since this project was started. This should work. I heard someone on #parrot say that such time shouldn't be an indication of anything. That's retarted. Of course it should. In my opinion, it is absolutely reasonable to expect that Parrot should be able to be embedded within a 10 year timeframe. At least, it shouldn't just do nothing.

After spending a whole day trying to do something that I felt I should have accomplished in 5 minutes, I decided to put plan B into action.

I built my compiler with a retargetable target language, so that if I needed to make the compiler output another language in addition to PIR, say C++, I could. But I needed to updated some code generation sources, as well as the target language templates. Its about a month process, in my estimates. I also have to create a C++ runtime for it; 2 weeks in my estimate. After one week into the C++ as a target language thing, I felt pretty burned. It had been many months that I've been on this thing without a break. So I decided to turn off the computer for a couple of weeks and focus on some math studies, while my brain goo resolidified. It's almost been about that time, and I'm getting ready to go back to work.

When I hit the keyboard again, I'm going to focus on making sure that the compiler can output C++, in addition to PIR, but I'm going to hold off on creating a C++ runtime for the geneterated code. I want to use Parrot as the runtime, because of business and personal reasons. but I can't base my business and future on hopes and dreams alone. I'd really like to go with Parrot as the runtime for the game engine, but if it can't stand on its own feet, I'm gonna have to shelf it for some, possibly long, time.

As another point of critique, I like to mention about a not-so-great attitude I see among some Parrot vm hackers, even among some of the senior ones. Sometimes, there seems to be an attitude that the code they write for Parrot is just for fun, something they do on their spare time, and as such, they don't need to do an excelent job. Something like, "as long as it works on my machine, I'm checking it in." This thing is meant to be used by many. If you're committing code, I feel it should be nothing less than your best. You're code could potentially be there for a long time, and it could possibly be the foundation upon which other code is built. A code that's pretty good doesn't need to be refactored as much as sucky code, which enables people to focus on writing new things, as opposed to continually reworking the same parts over and over. Just because you're not getting paid is not an excuse to commit junk. Please, keep the long term in mind, for all of us. Think of yourself as professionals.
[/CRITIQUE]

I really have high hopes for Parrot. I'm confident that with the leadership structure that Andrew and the others are instituting, that Parrot's best days are yet to come.


Regards,
V.

Rakudo project is currently the major user of Parrot. This is HLL that is currently being developed and not ready yet, kind of startup dynamic HLL project. I think, that startup kind of projects is the the way for Parrot (and this team) to go. This team can try to attract authors of new HLLs that are currently being developed from scratch (same as Rakudo currently is, but also much smaller projects too) to consider Parrot and, if they are likely to use Parrot, join the team. I think there may be several special-purpose as well as research-oriented startup dynamic HLLs currently being developed out there. In particular, dynamic HLLs are often developed by students as part of computer science education process, so if you manage to to contact them and attract them to using Parrot as underlying VM in their research or education projects, this would be great.

Yet another way to go is attracting members of communities of established dynamic HLLs. These people, however, will be highly skeptical, since they already have all they need. To attract at least some (most adventurous) of them, we would need to give them proof of the concept that Parrot can work as the riding horse for already established dynamic HLL. I think unless we can prove that Parrot can run Perl 5, you can't persuade at least some of, say, Ruby or Python guys to even consider Parrot. May be perl 5 is the way to start. If Parrot cannot be better VM for Perl 5 (for any its major future revision), the same is true for Ruby, Python, etc. This way is at least worth trying, but here much of skepticism is expected.

In general, the activity of this team looks like to attract cooperation from other established communities and - most importantly (!) - authors of startup HLL and a like projects.

PS: Since there are many things to discuss here, I think that you need to select some convenient centralized discussion place (e.g. on some of those fancy services, may be DISCUS) for the team to discuss their things and put ideas into.

Alex, parsels at mail dot ru

Alex wrote on October 23 2010:

... [s]tartup kind of projects is the the way for Parrot (and this team) to go. ... [T]here may be several special-purpose as well as research-oriented startup dynamic HLLs currently being developed out there. In particular, dynamic HLLs are often developed by students as part of computer science education process, so if you manage to to contact them and attract them to using Parrot as underlying VM in their research or education projects, this would be great.

Alex, I agree that Parrot has great potential as the basis for computer science educational projects. As a matter of fact, several years ago it was used as the basis of a course in compilers in France. And, of course, we have participated for two years in the Google Summer of Code and from which we have recruited developers. We would certainly welcome suggestions as to particular universities that could use Parrot in this way.

However, we want Parrot to be more than an academic project. Ultimately, we want it to run underneath established dynamic HLLs and in applications built in those HLLs running in production situations. You are certainly correct when, referring to people using established dynamic HLLs, "To attract at least some (most adventurous) of them, we would need to give them proof of the concept that Parrot can work as the riding horse for already established dynamic HLL." We are hoping to have a suitable implementation of Python ready within the next year for precisely that purpose.

"Since there are many things to discuss here, I think that you need to select some convenient centralized discussion place (e.g. on some of those fancy services, may be DISCUS) for the team to discuss their things and put ideas into." Here, I would disagree about the advisability of any such 'fancy services'. Between Parrot mailing lists, the Parrot wiki and individual Parrot contributors' blogs (such as this one), we already have more than enough communications media. I'd like to encourage you to contribute your ideas to the places with highest visibility to Parrot developers and users, namely, the parrot-dev and parrot-users mailing lists. Thanks for your comments.

Jim Keenan

Alex wrote on October 23 2010:

... [s]tartup kind of projects is the the way for Parrot (and this team) to go. ... [T]here may be several special-purpose as well as research-oriented startup dynamic HLLs currently being developed out there. In particular, dynamic HLLs are often developed by students as part of computer science education process, so if you manage to to contact them and attract them to using Parrot as underlying VM in their research or education projects, this would be great.

Alex, I agree that Parrot has great potential as the basis for computer science educational projects. As a matter of fact, several years ago it was used as the basis of a course in compilers in France. And, of course, we have participated for two years in the Google Summer of Code and from which we have recruited developers. We would certainly welcome suggestions as to particular universities that could use Parrot in this way.

However, we want Parrot to be more than an academic project. Ultimately, we want it to run underneath established dynamic HLLs and in applications built in those HLLs running in production situations. You are certainly correct when, referring to people using established dynamic HLLs, "To attract at least some (most adventurous) of them, we would need to give them proof of the concept that Parrot can work as the riding horse for already established dynamic HLL." We are hoping to have a suitable implementation of Python ready within the next year for precisely that purpose.

"Since there are many things to discuss here, I think that you need to select some convenient centralized discussion place (e.g. on some of those fancy services, may be DISCUS) for the team to discuss their things and put ideas into." Here, I would disagree about the advisability of any such 'fancy services'. Between Parrot mailing lists, the Parrot wiki and individual Parrot contributors' blogs (such as this one), we already have more than enough communications media. I'd like to encourage you to contribute your ideas to the places with highest visibility to Parrot developers and users, namely, the parrot-dev and parrot-users mailing lists. Thanks for your comments.

Jim Keenan

shockwave:

Your critique is the sort of feedback we need. We're trying to encourage greater use of our parrot-users mailing list for precisely this purpose.

Would it be possible for you to join that list, then re-work your critique as a post to that list?

Thank you very much.

kid51

shockwave: I'm going to make it my personal responsibility to ensure that Parrot supports all the API functionality that you need for your project. I think I have the problem of loading bytecode files figured out. If you can get in touch with me, I will make sure the 2.10 release contains what you need.