On second thought, I also want to argue this point: * Johan Vromans <jvromans@squirrel.nl> [2013-05-24 14:05]: > And, if you want something quick and simple, use CPAN search and find > yourself drowned in houndreds of CGI handling modules. Good luck > finding one that suits your needs. And works. If you want something quick and simple, why are you starting with CGI in the first place? Maybe because you knew of it already, but then finding CGI.pm among the hundreds of hits won’t be an issue. But if you didn’t know of it already, where did you get the idea to look into CGI in 2013? Not from any recent “web dev 101” intro. > The bottom line is: Do we want to ship perl such that it is easy to > get started with simple web applications? If so we either need to > include CGI.pm in the core, or put it on CPAN *and*make*sure*it*works. > No change in maintenance burden. Come again? How does “ship CGI.pm in core” equate to “make it easy to get started with simple web applications”? Who should *ever* be writing new code against CGI.pm? In terms of merit? No one. Only one final reason to target CGI.pm in new code remains: that it has always shipped with core. And making use of that advantage comes at high cost for the code you write. If improving the ease of getting started with web dev is your priority, then your argument would really have to be about coring Plack (on which I’d be -0) – even if you intend to deploy as a CGI. The ones who are actually better served by keeping CGI.pm are those who deploy existing CGI applications – not writers of new web applications. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>Thread Previous | Thread Next