Posts by Anonymous Monk
Perhaps it's time to look at Perl 6 ? in Meditations
3 direct replies — Read more / Contribute
by Anonymous Monk
on Oct 12, 2018 at 22:48
    Interesting meditation on Perl from a programmer dealing with a "complete nightmare" after 8 years of Beautiful is better than ugly:

    https://news.ycombinator.com/item?id=18182921


    "But seriously, many computer scientists have fallen into the trap of trying to define languages like George Orwell’s Newspeak, in which it is impossible to think bad thoughts. What they end up doing is killing the creativity of programming.

    A more insidious trap, promulgated in many places these days (including the most recent Discover magazine), is that a computer program should be beautiful. Let me tell you that when it comes to computer languages, this is totally bogus. If you want to do beautiful art, you don’t go out and buy a beautiful canvas, and a beautiful brush, and a beautiful palette, and slather beautiful paints on it. If you want to write beautiful poetry, this doesn’t happen because you started with a beautiful language. Languages are an artistic medium. I don’t want Perl to be beautiful–I want you to write beautiful programs in Perl.

    Finally, I believe that any language essentially should be out of control, because no one person or institution is capable of controlling a language (or a culture, for that matter) without destroying it. Living languages are always a cooperative effort, and I want Perl to be a living language."

    From https://www.perl.com/pub/1997/wall/keynote.html


Is WebPerl the Holy Grail* of universal cross-platform Perl app distribution? in Meditations
1 direct reply — Read more / Contribute
by Anonymous Monk
on Oct 11, 2018 at 12:05
    # Is WebPerl the Holy Grail* of universal # cross-platform Perl app distribution? $_=q` ______________ | PERLAPP | <- Your Perl app here. |_____|______| ______v_______ | WEBPERL | <- The Holy Grail* |_____^______| | | | | <- Internet. ______|____|__ | BROWSER v | <- Everywhere! | WEBPERLAPP | <- Downloaded! |____________| ______|_______ | WINDOWS | <- Anything... | LINUX | | MAC | | ETC | |____________| * Of universal cross-platform Perl application distribution. `and print
Perl Web Security: 15 years of lessons not learned by inferior new languages in Meditations
No replies — Read more | Post response
by Anonymous Monk
on Oct 10, 2018 at 14:25
    2001: Perl CGI HTTP_PROXY bug fixed! (by Merlyn :-)
    www.nntp.perl.org/group/perl.libwww/2001/03/msg2249.html

    15 years before nginx:
    www.securityfocus.com/bid/91819/references

    15 years before Apache:
    nvd.nist.gov/vuln/detail/CVE-2016-5387

    15 years before PHP:
    nvd.nist.gov/vuln/detail/CVE-2016-5385

    15 years before Python:
    bugs.python.org/issue27568

    15 years before Go (Golang):
    nvd.nist.gov/vuln/detail/CVE-2016-5386


    Who do you trust?

    LOL: httpoxy.org/#why

    2018-10-21 Athanasius changed <h1> tags to <h3>

The joy of Perl, 20 years later in Meditations
1 direct reply — Read more / Contribute
by Anonymous Monk
on Oct 09, 2018 at 10:55
Writing Popular Perl Software in Meditations
3 direct replies — Read more / Contribute
by Anonymous Monk
on Oct 07, 2018 at 20:27

    Writing Popular Perl Software

    Recently https://perl.com published a list of top keywords for their googsearch:

    https://github.com/tpf/perldotcom/projects

    Having this information is like asking a sentient billion human brain AI the question, "perl"?

    The answer was nine nouns in precedential order:

    $ perl? $ sql linux python mysql cgi regex foreach cpan download $ _

    The world needs Perl to:

    1. Interact with SQL databases.
    2. Work with Linux.
    3. Do something (with, about, for, etc) Python.
    4. Interact with MySQL databases.
    5. Provide the Common Gateway Interface.
    6. Match regular expressions.
    7. Process each item in a list.
    8. Expand through modules.
    9. Download!

    From https://en.wikipedia.org/wiki/Google_data_centers#Production_hardware

    "As of 2014, Google used a heavily customized version of Debian (GNU/Linux). They migrated from a Red Hat-based system incrementally in 2013."

    From https://wiki.debian.org/Perl

    "Perl is just another high level programming language that supports object-oriented, procedural and/or functional programming.

    Lot of Debian and GNU tools, use Perl. Lot of system core components, packaging internals and other critical points, rely on Perl versions.

    If you've some unmet requirements about the Perl interpreter version, TIMTOWTDI

    (There Is More Than One Way To Do It)

    2018-10-20 Athanasius removed code tags, added paragraph tags, linkified links, etc.

The war against Perl, by random wikipedia editors in Meditations
2 direct replies — Read more / Contribute
by Anonymous Monk
on Aug 23, 2018 at 22:13
    For many years Perl was part of the Model–view–controller page at wikipedia. At some point the Catalyst and Maypole links were quietly deleted and now everything except Perl gets a nod. This is not an isolated incident.

    Of course anyone can edit wikipedia: Let's put Perl back on the map!

use Memoize; in Meditations
2 direct replies — Read more / Contribute
by Anonymous Monk
on Jul 16, 2018 at 15:18
    I was porting a script to a module and noticed it kept getting slower. The script could initialize its expensive data structure once at the top and be done with it, but in order to encapsulate, the module was calling the function several times. I remembered the core module Memoize and added one line to the top of the program and now it runs fast again, 4x faster than without Memoize!
    
    use Memoize; memoize('some_sub');
    
    
    Only 1.5 seconds to start a program that was taking 6 seconds!
How "old" is mod_perl, really? in Meditations
No replies — Read more | Post response
by Anonymous Monk
on Jun 12, 2018 at 12:16
    1918 ANSI 1947 ISO 1970 Unix 1972 C 1974 TCP 1981 IP 1983 GNU 1985 POSIX 1985 C++ 1987 Perl! 1988 Unicode 1989 Bash 1990 Python 1991 Linux 1991 HTTP 1991 HTML 1995 Apache 1995 Javascript 1995 Java 1995 Ruby 1995 PHP 1996 CSS 1996 mod_perl (Don't even be callin *me* old!)
Review of CGI::Alternatives in Meditations
11 direct replies — Read more / Contribute
by Anonymous Monk
on Jun 09, 2018 at 11:44
    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
    
Code Structure Changes in Meditations
8 direct replies — Read more / Contribute
by Anonymous Monk
on Oct 27, 2017 at 15:17
    You are usually hired to change the code to achieve a change in functionality. You begin to think that if the code is written in a different way, this type of problem could easily be solved. Having short of time, you always try to change the code and commit it, but the idea that you have power to change the structure of code and you should do it, keeps bothering you. What you should do?