Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

Review of CGI::Alternatives

by Anonymous Monk
on Jun 09, 2018 at 15:44 UTC ( [id://1216248]=perlmeditation: print w/replies, xml ) Need Help??

CGI::Alternatives is a module that "doesn't do anything"1 except vehemently deny and propogandize against the utility of one of the most useful forms of programming EVER conceived: CGI2 programming.

CGI::Alternatives perpetuates all the common fallicies against CGI that if heeded only disempower independent developers. This includes advocating the replacement of all of Perl's wonderful and extremely simple, stable, mature, powerful CGI modules with vastly more byzantine "frameworks"1 which rigidly enforce all sorts of corporate nonsense like "full separation of concerns"1, total object-oriented lack of any possible function-ality, and the absurd complication of allowing oneself to be used by something as annoyingly totalitarian as templates1 EVEN when they're not appropriate! All of these techniques have their place of course, mostly in big projects, with lots of tiny modules (to confuse management, ensure job stability, in competitive workplaces, stretching hours into months, for the children), but not usually in code written by us individuals for fun, prototyping, and extreme levels of pure: results.3

With all due respect to the author's efforts to change how we Perl into something his bosses find acceptable, the author of CGI::Alternatives is actually in charge of CGI.pm! How is this even possible? I realize the author is a talented programmer who has contributed significantly to CPAN, but this quote directly reflects his inappropriate state of mind towards the CGI paradigm (while CGI.pm is derided with that weird novelty-obsessed bigotry for being "old", as he removes perfectly sensible functions, only to prove his pointless point):

"You can't just hand a template to the web-designers and allow them to work their magic. Don't mix the business logic and the presentation layer. Just don't."

This guy doesn't even know what a CGI programmer does yet he dictates to us? This is CRAZY! We ARE the web-designers, OF the business logic, AND the presentation layer--ALL mixed together--like a SWISS ARMY CHAINSAW: this is our TECHINQUE! THIS IS Perl! Something YOU (Lee) obviously don't understand. Mixing it all up is exactly how some other language(s) seized the web from Perl (along with plenty of well-funded corporate FUD). Even though we still do it far better.

We have been here from the beginning and we remain no matter how many of our tools you try to disable or how much FUD you spread about our primordially awesome technique of producing ONE UNIFIED FILE, USING CORE MODULES, QUITE OFTEN VASTLY SUPERIOR TO FRAGMENTED TEMPLATES, WRITTEN BY ONE PERL GENIUS, RATHER THAN A TEAM OF HOPELESSLY ABSTRACTED CORPORATE DRONES: Because Larry wrote and maintains Perl that way; Blessed be.

How dare you tell us to stop doing what we love and what Perl empowers us to do? How dare you remove the HTML generation functions from CGI.pm? Who do you think you are anyway? People who come to Perl and say things have got to change don't appreciate Perl and should be led as far away from Perl as possible (Python), not in charge of (formerly, unfortunately) core modules!

Can someone who cares please take CGI.pm away from Lee Johnson (LEEJO)? I would feel far more comfortable with someone we can trust, like ikegami or Merlyn3, in charge of maintaining CGI.pm. At least we know they would give us what we want and need, and more, rather than inflicting torture by removing legacy functionality FOR EMOTIONAL REASONS thereby violating operational stability.

News for you Lee: What worked 20 years ago still works today: UNIX, POSIX, BASH, PERL, ME, AND MAYBE EVEN YOU. Mature technology never stops working! I appreciate innovation so don't necessarily stop trying to reinvent the wheel, but please do stop trying to shove your shiny new wheels in sheep's clothing down our throats because PERL ALREADY WON.4

If we stopped wasting time and spirit listening to ideologically driven flame warrior infiltrators who keep trying to change Perl we would already have a perfectly backward compatible and "fixed" (even though it has never failed me to this very day thank you Lincoln Stein5) CGI.pm on the corelist joined by other bits we desperately need and use EVERY SINGLE DAY like CGI::Carp, Data::Dumper and File::Slurp.

Some examples:

This extremely useful one-line CGI dubugger is now broken thanks to LEEJO (thanks!):

print header('text/plain'), Dumper $data; exit;

This is never ever going away:

start_html

CGI.pm now reduces efficiency by 100%!:

'</body></html>' end_html # removed from CGI.pm, for ideological anti-reasons

If you agree PLEASE respond! If you do NOT agree please DO NOT hijack the thread because you guys already kinda won and I hope this thread can be for CGI programmers to chime in and support this seemingly lost cause which is really not even close to lost in the real non-ideological world of actual programmers who GET STUFF DONE.

Footnotes:


1. CGI::Alternatives
2. en.wikipedia.org/wiki/Common_Gateway_Interface
3. www.stonehenge.com/writing.html
4. programming.tudorconstantin.com/2015/01/perl-already-won.html
5. en.wikipedia.org/wiki/Lincoln_Stein

Replies are listed 'Best First'.
Re: Review of CGI::Alternatives
by Your Mother (Archbishop) on Jun 09, 2018 at 17:25 UTC

    Prologue: I'm your target audience. I like CGI.pm quite a bit and have written a couple thousand scripts, production and personal, with it at several jobs including Amazon.com.

    I also love the (can't call them new at this point, Catalyst is 13 years old) frameworks and raw Plack/PSGI but I use CGI.pm (::Pretty) now and then for the odd test or to generation a little boilerplate. Has nothing to do with fad or some imagined new:old dichotomy. I do what I want. CGI is monolithic and has some punching power in its weight class because of it but it's inferior to modern practices and tools on most levels, especially as a calling card. I agree that CGI.pm should not be removing features.

    That said, your proposal contains some unflattering ironies and inaccuracies and boils down to anonymously insulting and cajoling others into doing what you have the power to do. I agree with your basic premise but still downvoted you for the presentation and "volunteering" others.

    CGI.pm isn't core anymore. It's never going back in. Apache's market share is on a strong downward trend. Nginx is the opposite and the only webserver that is. If these trends hold, nginx will be the most popular and widely used server in a few more years. Nginx doesn't even support CGI.

    Being out of the core means there is no reason at all not to fork CGI.pm at whatever version you feel is backwards stable and port fixes going forward. I'd help patch and such a project if were on github and run in a community positive, feud free fashion. On that note, I submitted a modernization fix to LEEJO and it was accepted and applied instantly.

    Epilogue: Anonymous Monks have no "we." Use your name or say "I."

      Apache's market share is on a strong downward trend. Nginx is the opposite and the only webserver that is. If these trends hold, nginx will be the most popular and widely used server in a few more years. Nginx doesn't even support CGI.

      Because Nginx is a toy compared to Apache. It fills one little niche very well: replace reverse mod_proxy, on high traffic sites, so the mod_perl application server can get even more action! My brand new Macbook Pro came loaded with Apache/2.4.29, mod_perl/2.0.9 and Perl/v5.18.2 (which still includes CGI.pm yay). Simply edit config, flip the switch, and throw code at it. Nginx is not present, needed, nor welcome for such tasks. Apple has been very good to us. None of my linux distros even include Apache let alone mod_perl.

        "...Nginx is a toy compared to Apache... My brand new Macbook Pro came loaded with Apache..."

        Sure. And a Macbook is a great platform to run a high-performance web server. And my cellphone is stronger than your fax machine. And my dick is a monster.

        Best regards, Karl

        P.S.: How many serious projects did you do with nginx - if any?

        «The Crux of the Biscuit is the Apostrophe»

        perl -MCrypt::CBC -E 'say Crypt::CBC->new(-key=>'kgb',-cipher=>"Blowfish")->decrypt_hex($ENV{KARL});'Help

        I'm an Apple user going back well before OS X; and an apache user since '98. Nginx is so much better than apache as a pure webserver that it is somewhat ridiculous. The idea that you think a toy, deeply popular with open source developers, could be eating the market share of every single other webserver because of fashion or corporate pressure shows that you're either not serious or don't know what you're talking about.

      Epilogue: Anonymous Monks have no "we." Use your name or say "I."

      I have to we , do your mother?

Re: Review of CGI::Alternatives
by haj (Vicar) on Jun 09, 2018 at 21:05 UTC

    If I were to single out one Perl module that has changed the world, then this would be CGI.pm. It opened the door to write Perl software for the then-young WWW before the full impact of how WWW would change everything could have been imagined. Maybe it considerably contributed to said impact.

    Occasionally I am contributing to an open source project which uses CGI.pm since its beginning (TWiki). About three years ago Lee Johnson informed the dev team about his plans, and as far as I can say, he put considerable effort into informing the public about the upcoming changes. Our project makes use of the features which are no longer available in CPAN's CGI.pm, in particular, the HTML generating stuff. Nobody wanted to spend the effort to eliminate all of that. So we could have forked a CGI::Legacy module which kept all the stuff. But actually I wasn't too happy with the HTML generating stuff because it became obvious that it is rather difficult to extend. So, instead, we decided to package a frozen version of CGI.pm together with TWiki, and eliminate that old stuff in our own time. No shouting required.

    I'm used to the fact that old code needs to be changed occasionally. Compared to other languages, Perl shines when it comes to allowing for long lifetime of software with just a few changes. Nonetheless I'm trying to keep up with best practices when writing new code. As of today, I am perfectly fine with the current CGI.pm. And quite often I won't use it at all in favour of PSGI. The concept of passing variables as environment variables was a kludge at best (not Lincoln Stein's fault), and I'm glad we can now work without it.

    Now, what about CGI::Alternatives? I appreciate that Lee Johnson has put some effort into showing ways to migrate from CGI.pm. He shows how to replace just the HTML generating stuff with TT, and then how to avoid direct use of CGI.pm altogether.

Re: Review of CGI::Alternatives
by chromatic (Archbishop) on Jun 09, 2018 at 19:55 UTC
    CGI::Alternatives is a module that "doesn't do anything"1 except vehemently deny and propogandize against the utility of one of the most useful forms of programming EVER conceived: CGI2 programming.

    Looks to me like it suggests alternatives to the module CGI.pm rather than CGI in general.

Re: Review of CGI::Alternatives
by leej (Scribe) on Jul 04, 2018 at 13:46 UTC

    Hey!

    You seem to be conflating the Perl module CGI.pm and the CGI protocol, it's a common and easy mistake to make. CGI::Alternatives is advice against the former, not the latter, like it states in the very first line of its documentation.

    I've already talked about CGI.pm at length in various places, so won't go into it here in more detail1.

    I will say that I'm happy to audit, profile, and fix your CGI.pm based public facing applications' security holes and bugs for a *very* reasonable rate.

    And, as others have said, patches are still welcome (despite what the CONTRIBUTING file says, as that is there to discourage people with big ideas).

    Cheers!

    Lee Johnson (current maintainer, with Dr. Lincoln Stein's full blessing, of the CGI.pm Perl module).

    Seriously though, I'm at TPC in Glasgow this year, and the London and Swiss Perl workshops if you want to talk more.

    1. For example: https://leejo.github.io/2016/02/22/all_software_is_legacy/

Re: Review of CGI::Alternatives
by Veltro (Hermit) on Jun 09, 2018 at 17:08 UTC

    I agree, but I also agree to disagree. Telling people to not respond after posting such a storng post is not going to work. People will respond.

    Breaking a long existing module is not done in my opinion. If someone thinks he or she can do better, then they can write their own module. One of the strong things of CPAN is that everyone is free to decide whatever module they want to use. And I think that you are right that this way that choice is taken away. However if it is decided that a module is no longer core, well that is up to 'them'.

Re: Review of CGI::Alternatives
by choroba (Cardinal) on Jun 11, 2018 at 15:08 UTC
    > on the corelist joined by other bits we desperately need and use EVERY SINGLE DAY like CGI::Carp, Data::Dumper and File::Slurp.

    Data::Dumper has been in core since 5.005 and isn't planned to go away.

    File::Slurp has problems, but there are alternatives, but that's probably something you don't like to hear about Perl modules.

    ($q=q:Sq=~/;[c](.)(.)/;chr(-||-|5+lengthSq)`"S|oS2"`map{chr |+ord }map{substrSq`S_+|`|}3E|-|`7**2-3:)=~y+S|`+$1,++print+eval$q,q,a,
      I did say corelist as you point out but was thinking perl should be able to dump data structures with a core function. But I know who's in charge so it's just my much-less informed opinion, from a purely practical standpoint of always having to add Data::Dumper when things go awry. If this was wrong they probably wouldn't have bundled dumping into Perl6. I have beaten File::Slurp to death (also core perl6 functionality afaik) and the only time it failed was write_file with 2GB of data (syswrite error). I just wish Perl5 had perfect versions of read_dir, read_file and write_file to expedite what's usually done with readdir, open and print.
Re: Review of CGI::Alternatives
by bliako (Monsignor) on Jun 14, 2018 at 12:46 UTC

    I agree with separating super-duper HTML production from CGI but it would be useful to have some basic stuff in there for quick printing out something. Maybe freeze existing HTML functionality in CGI.pm and that's it. Forcing templates on people is not the right approach although templates helped my productivity enormously.

    Otherwise I agree with the poster. ALTHOUGH I dont have much of commercial experience deploying CGI.pm based apps and bearing the responsibility for security etc. Neither have I built an app and then found that CGI.pm has changed so much that my app is not working anymore and I have to re-write it. I would not like it much either, but that's how the business process in the world is right now: make obsolete and re-write.

    Can anyone elaborate on any security risks posed by CGI.pm and if these are solved with alternatives? I kept reading that CGI.pm is insecure and alternatives is the way to go in the modern era ... but can anyone substantiate these claims?

    Any other points to compare CGI.pm with alternatives?

      I always thought the criticisms against CGI were lame, but using the later tools is so much more enjoyable that it's hard to care all that much. Nothing against OP, do whatever you want.

      List flattening made a guy really mad and he did some videos at a conference. To me, his argument boils down to: List flattening is a bad language design choice because it is easily misunderstood by reasonably well trained programmers. I'm sure there was more, but that is what I got out of it.

      I could not find a video referencing CGI that did not use the f word extensively. Sorry about that. That in itself is kind of funny though.

        Through the list of links you posted above I came across this:

        • PacSec Hype Security Team: CGI.pm param injection which from what I understand the vulnerability comes when parsing a request with multiple same-name params. Perl's list/hash idiosyngracies be what they may makes it possible to create a hash of parameters which is not what one had in mind.
        • and then this Re: Stop Using Perl :
          "... But you know whats even more amazing? They patched CGI.pm to warn about this ..."
      Otherwise I agree with the poster. ALTHOUGH I dont have much of commercial experience deploying CGI.pm based apps and bearing the responsibility for security etc.

      It was this false assumption that we're all using CGI.pm in ways that cause Perlmonks to run and hide their children (Matt's) that caused it's ejection from corelist and mutilation on CPAN. These days I usually use CGI::Simple::Standard anyway but CGI was exceptionally handy for writing portable (corelist) local administrative programs that don't endure the Internet. It's also capable of cranking out HTML under control of Perl to create things like dynamic templates and static resources in background processes run by cron that might hit a database once a minute or more to serve static resources rather than let live users make real requests that could range from 0 to Infinity per second... From what I can see there are still 3 modules on the corelist that generate HTML (and a lot more) but only from POD! With templates written in POD the Pod modules can crank out everything from HTML, XHTML, XML, RTF, man, etc. Hopefully they're SECURE! :-)

Re: Review of CGI::Alternatives
by Anonymous Monk on Jun 09, 2018 at 16:25 UTC
    If you agree PLEASE respond! If you do NOT agree please DO NOT This is not how discussion works...
      "...If you do NOT agree please DO NOT..."

      Don't you ever tell me to shut up.

      «The Crux of the Biscuit is the Apostrophe»

      perl -MCrypt::CBC -E 'say Crypt::CBC->new(-key=>'kgb',-cipher=>"Blowfish")->decrypt_hex($ENV{KARL});'Help

        I realize Perl is probably your first language but in English you were asked very nicely (PLEASE) to not hijack the thread in order to evangelize against the Common Gateway Interface. Of course you are free to ignore polite requests. Apologies if this was not clear in the OP.
      This is not how discussion works...

      I understand and agree. That's why I put this in Meditations rather than Discussion. I don't really need any more "discussion" of how much CGI sucks when I use it every day to kick ass. Anyway the monks will do what they wish with this thread. These anti-people are brainwashed by working for corporations and following their ridiculous programming ideology of maximum fragmentation, to deliberately disempower programmers. I have been there, laughed at them, and walked away... but I don't like their wacky cults invading my playground.

      One Script to rule them all, One Script to find them,
      One Script to bring them all and in the darkness bind them

        So people who disagree exclusively work for corporations? There will be no productive discussion in this thread.

        Steve
        --
Re: Review of CGI::Alternatives
by davebaker (Pilgrim) on Jun 09, 2018 at 18:17 UTC
    Agree, basically.
A reply falls below the community's threshold of quality. You may see it by logging in.
A reply falls below the community's threshold of quality. You may see it by logging in.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://1216248]
Approved by beech
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others cooling their heels in the Monastery: (6)
As of 2024-03-19 09:55 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found