Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Saturday December 26 2015, @12:11PM   Printer-friendly
from the end-of-lifing-software-is-hard dept.

CGI.pm has been removed from the core Perl distribution. From 5.22, it is no longer included in a standard Perl installation.

There are good technical reasons for this. CGI is a dying technology. In 2015, there are far better ways to write web applications in Perl. We don't want to be seen to encourage the use of a technology which no-one should be using.

This does lead to a small problem for us though. There are plenty of web hosting providers out there who don't have particularly strong Perl support. They will advertise that they support Perl, but that's just because they know that Perl comes as a standard part of the operating system that they run on their servers. They won't do anything to change their installation in any way. Neither you nor I would use a hosting company that works like that – but plenty of people do.

The problem comes when these companies start to deploy an operating system that includes Perl 5.22. All of a sudden, those companies will stop including CGI.pm on their servers. And while we don't want to encourage people to use CGI.pm (or, indeed, the CGI protocol itself) we need to accept that there are thousands of sites out there that have been happily using software based on CGI.pm for years and the owners of these sites will at some point change hosting providers or upgrade their service plan and end up on a server that has Perl 5.22 and doesn't have CGI.pm. And their software will break.


What say you, fellow Soylents? How would you suggest "end-of-life"ing CGI.bin?

Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 0) by Anonymous Coward on Sunday December 27 2015, @03:52AM

    by Anonymous Coward on Sunday December 27 2015, @03:52AM (#281364)

    In 2015, there are far better ways to write web applications in Perl.

    Yes, it's called. nph-yourscript.pl. Non Parsed Headers. This allows my custom code direct access to the headers by telling the server not to fuck with my output. Interestingly this is also how I get Apache to run my C programs and ditch Perl (and HTTP) all together.

    Why the fuck would I do that? We'll in $CURRENT_YEAR there are much better ways to develop Internet connected applications (which is what webpages are today -- shitty wanna-be applications).

    Lucky for me, I never used CGI.pm except to get one-off scripts done. I'm ahead of the curve. I avoid needless throttling by making TCP connections look like HTTP, then "dowshifting" to raw packet streams. Where I have to provide browser support I use web sockets and Emscripten to compile my code for the browser (which compiles it into machine code and caches it, so it runs far faster than JavaScript).

    I love you Perl. You'll always be my favorite Shell / Glue language, but your new bells and whistles are stupid and you remove functionality that makes my dinky maintenance scripts break for no fucking reason. Python is sexier but is fat and slow (stop fat-shaming, I know). Straight up C99, here to stay. With the advent of open source code and cross platform compiler tool chains, all this virtualized scripted bullshit is deprecated.

  • (Score: 1) by Noldir on Sunday December 27 2015, @01:56PM

    by Noldir (1216) on Sunday December 27 2015, @01:56PM (#281429)

    What on earth are you trying to do? It sounds like you know one language and are trying to shoehorn that into every use case you have. And as you say so yourself there are better options available for web applications,so it sounds like a complete maintenance nightmare to boot...

    • (Score: 0) by Anonymous Coward on Sunday December 27 2015, @06:56PM

      by Anonymous Coward on Sunday December 27 2015, @06:56PM (#281476)

      What on earth are you trying to do? It sounds like you know one language and are trying to shoehorn that into every use case you have.

      You fool. You would consign yourself to a perpetuity of learning new language after new language, when instead we have the technology to compile any of your favorite compilable languages into any other language. I like C, so I can compile it into Java bytecode, or ASM.js, or Objective C. Fuck languages. They all suck. The future lies not in languages but the creation of API abstraction layers for each platform to adapt ANY language to run on ANY platform, and the barebones binding beneath it all will be in C, thus it is the language to use for best performance and barebones simplicity. Keep in Simple Stupid. And yet you complicate things with the moronic notion that there is a certain language for every problem space. BAH HUMBUG! That way lies obsolescence. You have been warned. The future is coming, soon you language zealots will be obsolete.

      Does not Perl's Parrot VM point the way, albeit a flawed approach, you could compile damn near anything to run on Parrot VM. Fuck the VM though. Tell me what platform your running and I will, with the push of a few buttons, generate a deployment of my C code to operate thereupon. Be your platform "Javascript enabled browser" or be it iPhone or Android, or Linux or BSD or Mac, or Windows with or without the interface formerly known as Metro.

      Cross platform and open source coding have made VMs obsolete -- I can simply compile for the target platform directly rather than write once and debug everywhere. Operating systems are irrelevant. No one buys an OS for its capabilities! They buy devices asking, "What software can I run atop it?" Well, if the devices and platforms will not come into standardization then that is fine, then applications will be written using a tool chain that allows deployment across EVERY platform regardless of how nonstandard the anti-competitive fuckwads desire to be. Don't like C? No problem. The compiler supports other languages as well... See? Just as the OS is irrelevant, so too will the Language be irrelevant.

      As for maintenance nightmare? What is this you speak of? Having a system that's deployed in half a dozen languages is a fucking nightmare. Having tens or hundreds of such systems is a fucking nightmare. Writing your code to one API and fixing the maintenance issues at the platform abstraction level so that ALL OF YOUR PRODUCTS benefit simultaneously... That is not a nightmare but a dream come true!

      Every problem in Computer Science can be solved by applying another level of abstraction. However, there is a special type of universal abstraction layer called Annealing whereby the surface interface is made uniform and the underlaying layer adapts freely to any problem space. Fool, I have proven my tool chain mathematically sound. While you learn $FLAVOR_OF_THE_WEEK language, I will merely add it to my compilation targets and release my entire software stack for that platform faster than you can get one product out the door.

      "Maintenance headache"? HA! You wallow in such headaches and deny the universal process of life, the universe, and everything. Evolution is a dumb way of saying that Life is a planetary Annealing process. You will either embrace the universal truth of adaptation, or become extinct.