Author: Whiteknight Date: Mon Nov 10 16:24:13 2008 New Revision: 32503 Modified: trunk/docs/book/ch01_overview.pod
Log: [Book] Revision and editing pass for chapter 1. Decrease line lengths where dangerously long, fix wording, tone, and flow. Fixed some grammar issues. Modified: trunk/docs/book/ch01_overview.pod ============================================================================== --- trunk/docs/book/ch01_overview.pod (original) +++ trunk/docs/book/ch01_overview.pod Mon Nov 10 16:24:13 2008 @@ -7,79 +7,87 @@ X<Parrot> The heart of Parrot is a grandiose idea that turned out to be more realistic than anyone originally could have believed: why not have a -single interpreter for several languages? Up till then, dynamic -languages such as Perl, Python, Ruby, and Scheme had all used their -own individual interpreters, which were often not easily extensible, -not modular, and not capable of interoperation. The solution was to -create a single virtual machine for all such languages, a virtual -machine called Parrot. The planning for Parrot progressed slowly, in -bits and pieces, over the period of a year. +single interpreter for several languages? Before this question was +asked, dynamic languages such as Perl, Python, Ruby, and Scheme had +all had their own individual interpreters; most of which were not +easily extensible, not modular, and not capable of interoperation. +The solution, it was decided, was to create a single virtual machine +for all such languages. That virtual machine is called Parrot. On April 1st, 2001, Simon CozensX<Cozens, Simon> published an article titled "Programming Parrot" as an April Fools' joke (U<http://www.perl.com/pub/a/2001/04/01/parrot.htm>). It contained a contrived interview with Larry Wall and Guido van Rossum detailing their plans to merge Python and Perl into a new language called -Parrot. This was plausible because both languages were undergoing -massive redesigns: Perl was being rewritten as "Perl 6", and Python -was being reconsidered as "Python 3000". A few months later, when the -Perl 6 internals project began to take an independent path from the -rest of the Perl 6 design effort, they dubbed the subproject "Parrot" -in a fitting turn of life imitating art. - -The goal for the Parrot project was to create a language-neutral run-time -environment for dynamic languages like Perl and Python. It would support -all the features of those and other dynamic languages such as Ruby, -Scheme, Befunge, PHP, and others. Threading and Unicode would be supported -from the start, mitigating two thorns that had plagued Perl 5 developers for -years. A robust exceptions system, a capability to compile into -platform-independent bytecode, and a clean extension and embedding mechanism -would be just some of Parrot's standard features. - -The irony is that the language-neutrality of the interpreter was originally -just a side effect of good design. Keeping the implementation independent -of the syntax would make the codebase cleaner and easier to maintain. -One practical advantage of this was that Parrot development could begin even -though the Perl 6 language specification was still in flux. - -The bigger win in the long term, though, was that since Parrot would -support the features of the major dynamic languages and wasn't biased -to a particular syntax, it could run all these languages with little -additional effort. It's generally acknowledged that different -languages are suited to different tasks. Picking which language to use -in a large software project is a common planning problem. There's never a -perfect fit. The decision usually boils down to settling for the -language with the most advantages and the least noticeable -disadvantages. The ability to easily combine multiple languages within a -single project, something which is typically possible of most compiled -languages such as C but rarely possible with dynamic interpreted languages, -could be a huge benefit to developers. Using well-tested libraries from one +Parrot. This was a plausible ruse because both languages were +undergoing massive redesigns: The Perl community was laying the +groundwork for the next version, "Perl 6", and the Python team was +working hard on a spec for "Python 3000". The Perl 6 project started +moving in two different directions at once: the underlying interpreter +architecture and the language grammar and semantics. As people +realized that the two projects could become completely indepent, it +was decided to create a proper language-agnostic virtual machine to +support the high-level efforts. The virtual machine was later dubbed +"Parrot" in a fitting turn of life imitating art. + +The goal for the Parrot project was to create a language-neutral runtime +environment for dynamic languages like Perl and Python. Of course, these +two languages weren't the end, not for the Parrot team. They were +thinking big. Parrot would have to support all the features other +dynamic languages such as Ruby, Scheme, Befunge, PHP, and others. +Threading and Unicode would be supported from the start, mitigating two +thorns that had plagued Perl 5 developers for years. A robust exceptions +system, a capability to compile into platform-independent bytecode, and +a clean extension and embedding mechanism would be just some of the +necessary and standard features. Parrot needed to have more then any of +these languages had ever had by themselves, and it needed to do all +these things right. + +The irony is that the language-neutrality of the interpreter was +originally just a side effect of good design. Keeping the implementation +independent of the syntax would make the codebase cleaner and easier to +maintain. Plus, the Parrot team could get to work long before the Perl +6 group even had their plans written. + +Since Parrot would support the features of the major dynamic languages +and wasn't biased to a particular syntax, it could run all these +languages with little additional effort. It's generally acknowledged +that different languages are suited to different tasks, and picking which +language to use in a large software project is a common planning problem. +There's never a perfect fit, at least not for all jobs. Developers find +themselves settling for the language with the most advantages and the +least noticeable disadvantages. The ability to easily combine multiple +languages within a single project could be a huge benefit to developers. +Before Parrot, language interoperability was a feature typically reserved +for compiled languages such as C. Using well-tested libraries from one language, taking advantage of clean problem-domain expression in a second, and using languages according to their inherent strengths is the ultimate -goal, one which is only becoming possible through Parrot. +goal, one which the Parrot team is hoping to make a reality. -Modular design also benefits future language designers, not just designers of -current languages. Instead of targeting I<lex>/I<yacc> and reimplementing -low-level features such as garbage collection and dynamic data types, -designers can leave the details to Parrot and focus on the high-level features -of their language: syntax, libraries, capabilities. Parrot does all the -necessary bookkeeping, exposing a rich interface with capabilities that few -languages can make full use of. +Modular design also benefits future language designers, not just +designers of current languages. Instead of targeting I<lex>/I<yacc> and +reimplementing low-level features such as garbage collection and dynamic +data types, designers can leave the details to Parrot and focus on the +high-level features of their language: syntax, libraries, capabilities. +Parrot does all the necessary bookkeeping, exposing a rich interface with +capabilities that few languages can make full use of. + +=head1 The Parrot Team As is typical of open source development projects, managing the -development of Parrot is quite different from managing a commercial project of -the same size and complexity. There are no schedules, no deadlines, no -hiring and firing, and no salaries, bonuses, or stock options. There are -no employees or bosses; there is very little hierarchy whatsoever. -Management in this context isn't about giving orders, it's about making -sure everyone has what they need to keep moving forward. Like most open-source -and open-content projects, the best leadership is to set a good example and -stay out of the way. - -The Parrot development team is broken down into several distinct roles, which -people assume according to their merits and their talents. This is a list of -those roles, with a partial list of the folks who have taken responsibility -for them. +development of Parrot is quite different from managing a commercial +project of the same size and complexity. There are no schedules, no +deadlines, no hiring and firing, and no salaries, bonuses, or stock +options. There are no employees or bosses; there is very little +hierarchy whatsoever. Management in this context isn't about giving +orders, it's about making sure everyone has what they need to keep +moving forward. Like most open-source and open-content projects, the +best leadership is to set a good example and stay out of the way. + +The Parrot development team is broken down into several distinct roles, +which people assume according to their merits and their talents. This is +a list of those roles, with a partial list of the folks who have taken +responsibility for them. =head2 Project Team X<Project Team> @@ -88,21 +96,22 @@ =item Architect -The architect has primary responsibility for setting overall direction of the -project, and to facilitate team communication and understanding of -architectural issues. The architect is primarily, but not solely, responsible -for making design decisions and documenting them in Parrot Design Documents; -responsibility for design and documentation of project subcomponents may be -delegated to other members of the Project Team, or may be held jointly. -The Architect also works with the Release Managers to develop and -maintain the release schedule. Allison RandalX<Randal, Allison> leads the -Parrot project as chief architect. +The architect has primary responsibility for setting overall direction +of the project, and to facilitate team communication and understanding +of architectural issues. The architect is primarily, but not solely, +responsible for making design decisions and documenting them in Parrot +Design Documents X<Parrot Design Documents>; responsibility for design +and documentation of project subcomponents may be delegated to other +members of the Project Team, or may be held jointly. The Architect also +works with the Release Managers to develop and maintain the release +schedule. Allison RandalX<Randal, Allison> currently leads the Parrot +project aschief architect. =item Release Managers Release managers have responsibility for executing a product release -according to the release schedule. The release schedule is developed and -maintained jointly with the project Architect. +according to the release schedule. The release schedule is developed +and maintained jointly with the project Architect. Current release managers are, in this order: @@ -120,15 +129,18 @@ X<Randal, Allison> Information on the release procedure can be found in -F<docs/project/release_manager_guide.pod>. +F<docs/project/release_manager_guide.pod>. Parrot releases a stable +version, under the direction of one of these release managers, every +month. =item Metacommitter -All Metacommitters are responsible for managing commit access to the Parrot -repository. Once the Architect or Pumpking approves a request for a -Contributor to be given commit access, a Metacommitter provides that access. -The Architect is a Metacommitter, but other Project Team members -may also hold this role. +All Metacommitters are responsible for managing commit access to the +Parrot repository. Once the Architect or Pumpking approves a request +for a contributor to be given commit access, a Metacommitter performs +the necessary magic to give the new committer access to the SVN +repository and the bugtracker. The Architect is a Metacommitter, but +other Project Team members may also hold this role. Current metacommitters are: @@ -143,19 +155,20 @@ Jesse Vincent X<Vincent, Jesse> -The procedure on how to manage the list of Parrot committers can be found in -F<docs/project/metacommiter_guide.pod>. +The procedure on how to manage the list of Parrot committers can be +found in F<docs/project/metacommiter_guide.pod>. =back =head2 Committers X<Committers> -Contributors who submit numerous, high-quality patches may be considered to -become a Committer. Committers have commit access to the full Parrot -repository, but generally work only on one or more subprojects; Committer -categories are described below. Contributors may considered for commit access -either by being nominated by another Committer, or by requesting it. +Contributors who submit numerous, high-quality patches may be +considered to become a Committer. Committers have commit access to the +full Parrot repository, but generally work only on one or more +subprojects; Committer categories are described below. Contributors may +considered for commit access either by being nominated by another +Committer, or by requesting it. =over 4 @@ -171,35 +184,37 @@ =item High Level Language Developer -Developers who work on any of the high-level languages that target Parrot such -as TCL, Lua or Perl 6, are High-Level Language Developers. Many of these -language projects are located in the Parrot repository, although some are -maintained separately as well. It is the intention that all languages be -developed separately from Parrot before the 1.0 release. +Developers who work on any of the high-level languages that target +Parrot such as TCL, Lua or Perl 6, are High-Level Language Developers. +Many of these language projects are located in the Parrot repository, +although some are maintained in separate locations. It is the intention +that all languages be developed separately from Parrot before the 1.0 +release. =item Build Manager -Build Managers maintain and extend configuration and build subsystems. They -reviews smoke reports and attempt to extend platform support. +Build Managers maintain and extend configuration and build subsystems. +They reviews smoke reports and attempt to extend platform support. =item Lead Tester -Developing, maintaining, and extending test suite coverage and testing tool -are the key tasks for the Lead Testers. Lead Testers are also responsible for -testing goals, including complete coverage of core components on targeted -platforms. +Developing, maintaining, and extending test suite coverage and testing +tool are the key tasks for the Lead Testers. Lead Testers are also +responsible for testing goals, including complete coverage of core +components on targeted platforms. =item Patch Monsters -Hackers and developers submit patches to Parrot every day, and it takes a keen -eye and a steady hand to review and apply them all. Patch Monsters, as they -are affectionately known, are in charge of checking patches for conformance -with coding standards and desirability of features. +Hackers and developers submit patches to Parrot every day, and it takes +a keen eye and a steady hand to review and apply them all. Patch +Monsters, as they are affectionately known, are in charge of checking +patches for conformance with coding standards and desirability of +features. =back -A list of committers that have a role they've taken responsibility for can -be found in F<RESPONSIBLE_PARTIES>. +A list of committers that have a role they've taken responsibility for +can be found in F<RESPONSIBLE_PARTIES>. =head2 Contributors X<Contributors> @@ -208,24 +223,24 @@ =item Cage Cleaners -Parrot's cage, the development working environment, has a tendency to get -messy and disorganized over time. It's the responsibility of the aptly-named -Cage Cleaners to ensure coding standards are followed, that documentation is -complete and accurate, that all tests are functioning properly, and that there -are plenty of coding examples for new users to learn from. A class of tickets -in the RT tracking system has been created especially for use by this group. -This position encompasses tasks that run the gamut from entry-level to -advanced, and is a good entry point for new users who want to get more -familiar with Parrot internals. +Parrot's cage, the development working environment, has a tendency to +get messy and disorganized over time. It's the responsibility of the +aptly-named Cage Cleaners to ensure coding standards are followed, that +documentation is complete and accurate, that all tests are functioning +properly, and that there are plenty of coding examples for new users to +learn from. A class of tickets in the RT tracking system has been created +especially for use by this group. This position encompasses tasks that +run the gamut from entry-level to advanced, and is a good entry point +for new users who want to get more familiar with Parrot internals. =item General Contributor -Contributors are volunteers who write code or documentation patches, take -part in email or online conversations, or contribute to the project in other -important ways. All volunteer contributions are appreciated and recognized, -with their names being added to the F<CREDITS> file in the Parrot -repository. When a new contributor submits patches which have been accepted, -they should add their name to this list. +Contributors are volunteers who write code or documentation patches, +take part in email or online conversations, or contribute to the project +in other important ways. All volunteer contributions are appreciated +and recognized, with their names being added to the F<CREDITS> file in +the Parrot repository. When a new contributor submits patches which have +been accepted, they should add their name to this list. =back @@ -235,11 +250,11 @@ X<Hansen, Ask BjE<oslash>rn> X<Spier, Robert> -Last, but not least, is the glue that holds the project together. Ask +Last, but not least, is the glue that holds the project together. BjE<oslash>rn Hansen and Robert Spier manage the email, revision -control, and bug-tracking systems, as well as the web site for Parrot, -U<http://www.parrotcode.org>. Without these systems, the project would -grind to a screeching halt. +control, and bug-tracking systems, as well as the web sites for Parrot, +U<http://www.parrot.org> and now U<http://www.parrot.org>. Without +these systems, the project would grind to a screeching halt. In the end, it is the developers themselves who hold the project together. Individuals bear their own share of responsibility for @@ -250,23 +265,23 @@ X<Parrot;mailing lists> Mailing lists are an important tool for communication, and the Parrot -Development team maintains a special-purpose mailing list to coordinate the -efforts of the many team members. The mailing list for Parrot is called -"Parrot-Porters", and you can subscribe to it by sending a blank email message -to U<[EMAIL PROTECTED]>. The list is archived at -U<http://www.nntp.perl.org/group/perl.perl6.internals> +Development team maintains a special-purpose mailing list to coordinate +the efforts of the many team members. The mailing list for Parrot is +called "Parrot-Porters", and you can subscribe to it by sending a blank +email message to U<[EMAIL PROTECTED]>. The list is +archived at U<http://www.nntp.perl.org/group/perl.perl6.internals> and available via NNTP at U<nntp://nntp.perl.org/perl.perl6.internals>. -Despite the presence of the term "perl6" in the list name, the list is not -used to talk about Perl 6. The name is just a historical throw-back to the -time when the Perl 6 and Parrot projects were operating together. +Despite the presence of the term "perl6" in the list name, the list is +not used to talk about Perl 6. The name is just a historical throw-back +to the time when the Perl 6 and Parrot projects were one and the same. You can also read the Parrot-Porters list via Google Groups at U<http://groups-beta.google.com/group/perl.perl6.internals> X<Parrot;sites> -Parrot information and documentation can be accessed on the web in a variety -of locations. The following web sites should have all the Parrot information -you need to get started: +Parrot information and documentation can be accessed on the web in a +variety of locations. The following web sites should have all the +Parrot information you need to get started: =over 4
