ServerWatch content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
“What I will be revealing in these columns will be the design of Perl 6. Or more accurately, the
beginnings of that design, since the design process will certainly continue after I’ve had my initial say in
the matter. I’m not omniscient, rumors to the contrary notwithstanding. This job of playing God is a
little too big for me. Nevertheless, someone has to do it, so I’ll try my best to fake it. And I’ll expect all
of you to help me out with the process of creating history. We all have to do our bit with free will.”
What I will be revealing in these columns will be the design of Perl 6. Or more accurately, the
beginnings of that design, since the design process will certainly continue after I’ve had my initial say in
the matter. I’m not omniscient, rumors to the contrary notwithstanding. This job of playing God is a
little too big for me. Nevertheless, someone has to do it, so I’ll try my best to fake it. And I’ll expect all
of you to help me out with the process of creating history. We all have to do our bit with free will.
“If you look at the history of Perl 6 up to this point, you will see why this column is subtitled The Ugly,
the Bad, and the Good. The RFC process of last year was ugly, in a good sense. It was a
brainstorming process, and that means it was deliberately uglynot in the sense of incivility, since the
RFC process was in fact surprisingly civil, but in the sense that there was little coherent design to the
suggestions in the RFCs. Frankly, the RFCs are all over the map, without actually covering the map.
There are contradictory RFCs, and there are missing RFCs. Many of the RFCs propose real
problems but go off at funny angles in trying to propose solutions. Many of them patch symptoms
without curing the underlying ailments.”
