In a message dated Sat, 9 Sep 2006, Mark Stosberg writes:
I do share your sentiment that CGI.pm shouldn't be a clone of how P5
works. I'd like the HTML building methods to stay out, which wasn't even
one of the differences you cared about yourself.
I agree with the sentiment, but as a practical matter, not having HTML methods
in CGI.pm could drastically limit Perl 6 adoption.
If Perl 5 programmers get used to how they can mechanistically port their
programs to Perl 6, they will do so with the same sort of "ah-hah" moments
you've posted about on the Pugs blog, and it will be a good experience.
In other words, if they can port at a very low level (more like paraphrasing a
complicated text for a child than like translating from Chinese to English)
they won't feel that *everything* has changed under their feet, and over time
they'll start to nibble at more advanced features, and before long they'll be
translating automatically rather than paraphrasing mechanically.
But the HTML methods are used everywhere. And the more novitiate the
programmer, the more likely they are to be using them spaghetti-like
throughtout their code. If they discover that every time they see a
C<start_form> it's going to entail new coding, they're going to rapidly get
discouraged about porting to Perl 6.
I'd suggest that perhaps a more workable solution is to just buck up and accept
that the HTML methods have to get ported along with the rest of CGI.pm, but put
them into a separate distribution and have documentation in Differences and its
successors that say something like:
was: use CGI ':standard';
now: use CGI;
use CGI::HTMLgenerators; # Available separately, deprecated
perhaps with some scary-sounding warnings about how you should only use the
latter if you have lots of preexisting code needing the generators, that it's
better to use these other good solutions, you may shoot your eye out, etc. etc.
I know I seem to veer from wanting everything to change to wanting nothing
change, but it really comes down to whether the changes will not just be good
for us in an eat-your-spinach kind of way, but will lead to a more pleasant
programming experience as well. Adoption of Perl 6 will depend on whether
programmers like it, regardless of how stable or beautifully-architected its
systems are.
Trey
