http://www.perlmonks.org?node_id=719063


in reply to Re^2: Parrot 0.8.0, "Pareto principle" released!
in thread Parrot 0.8.0, "Pareto principle" released!

I don't think I asked my question very well. Let's say that I'm looking at a brand-new small application at work for internal use. I've been given complete carte blanche to implement it as I see fit. In fact, my boss is very interested in getting a Parrot-based app in so that we can get some experience with it. I'm going to be using a single language (doesn't matter which one) and I want to just use Parrot as a VM.

The question is:

Personally, I think having software in a ready-to-ship state as soon as possible makes a lot of sense. I think that it makes even more sense with Parrot because of the "Duke Nukem Forever" tag that has been stamped upon the whole project. If there was at least one language that worked with Parrot and could be used for internal production use, that would go a long way. Then, as more languages are added, it just becomes a rolling boulder.


My criteria for good software:
  1. Does it work?
  2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
  • Comment on Re^3: Parrot 0.8.0, "Pareto principle" released!

Replies are listed 'Best First'.
Re^4: Parrot 0.8.0, "Pareto principle" released!
by chromatic (Archbishop) on Oct 23, 2008 at 17:33 UTC
    What language(s) are sufficiently implemented on parrot for internal production use?

    Lua reached feature parity with Lua 5.0 and it's close to 5.1, if I understand correctly. PIR is also stable.

    Is there a list of what needs to be done in order for Parrot to safely support a single language?

    That depends on the language's features.

    Would it make sense for the Parrot effort to put some work into polishing those pieces right now?

    That's what we're doing!

    Personally, I think having software in a ready-to-ship state as soon as possible makes a lot of sense.

    That's why we make monthly releases.