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
