# A vision for Parrot

**URL:** <https://rubytalk.org/t/a-vision-for-parrot/2653>\
**Category:** ruby-talk\
**Created:** [4 November 2002 22:00 UTC](https://rubytalk.org/t/a-vision-for-parrot/2653 "2002-11-04T22:00:59Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Claird](https://avatars.discourse-cdn.com/v4/letter/c/7ba0ec/32.png) [@Claird](https://rubytalk.org/u/Claird)\
**Post date:** [4 November 2002 22:00 UTC](https://rubytalk.org/t/a-vision-for-parrot/2653/1 "2002-11-04T22:00:59Z")

</div>

In article [20021105221004.339206f3.occitan@esperanto.org](mailto:20021105221004.339206f3.occitan@esperanto.org),

> Hi,
> 
> this morning it struck me that it would be nice to have Parrot not only  
> run Perl 6 and similar byte code, but that any of the common interpreted  
> languages be compiled to this same byte code.
> 
> Then no matter whether running a Perl 6, Python, Ruby, Tcl maybe even  
> bash script the same interpreter library would be used. Then likely it  
> would already be in memory speeding up start time.
> 
> And this would also ease cross language module/library inclusion.  
> Imagine instantiating some Python class from Perl!
> 
> Apache would essentially have a mod\_parrot. Maybe, if this can be  
> tested very hard, we’d even have a Parrot kernel module for all Unices  
> supporting that. Then exec() could perform compiled scripts right away,  
> like machine code 🙂  
> .  
> .  
> .  
> This thought inspired enthusiasm in others long ago–from  
> before it was named “Parrot”, at least.

Availability of all the pieces your vision requires is at  
least several years away, barring miracles. I don’t par-  
ticularly expect it to happen.

> **···**
>
> ## Daniel Pfeiffer [occitan@esperanto.org](mailto:occitan@esperanto.org) wrote:
> 
> Cameron Laird [Cameron@Lairds.com](mailto:Cameron@Lairds.com)  
> Business: [http://www.Phaseit.net](http://www.Phaseit.net)  
> Personal: [Home page for Cameron Laird](http://phaseit.net/claird/home.html)
