93% of random OCR outputs are valid Perl programs. The paint splatters are a distraction.
Its sigbovik. The entire conference is a distraction. That's the whole point.
93% of Paint Splatters Are Valid Perl Programs
71–80 of 135 posts
Re: 93% of Paint Splatters Are Valid Perl Programs
#72Because of the frequency I see undecipherable strings like this in actual Perl code, I don't like Perl the programming language. However, I love Perl the project. Take a look at the config file for Perl and how many systems and architectures it accommodates: https://github.com/Perl/perl5/blob/blead/Configure It's clearly such an incredible labor of love by Larry Wall et al. that I'm sad for them it isn't more popular…
> Take a look at the config file for Perl and how many systems and architectures it accommodates: https://github.com/Perl/perl5/blob/blead/Configure
25249 lines (23725 sloc)
Re: 93% of Paint Splatters Are Valid Perl Programs
#73Because of the frequency I see undecipherable strings like this in actual Perl code, I don't like Perl the programming language. However, I love Perl the project. Take a look at the config file for Perl and how many systems and architectures it accommodates: https://github.com/Perl/perl5/blob/blead/Configure It's clearly such an incredible labor of love by Larry Wall et al. that I'm sad for them it isn't more popular…
> Take a look at the config file for Perl and how many systems and architectures it accommodates: https://github.com/Perl/perl5/blob/blead/Configure 25249 lines (23725 sloc) Good grief. This is incredible. Thanks for sharing that.
Lots of the comments are really funny.
Re: 93% of Paint Splatters Are Valid Perl Programs
#74Earlier quoted context omitted.
Interesting. Similar to how typescript can be added with a rename from foo.js to foo.ts.
even on something with dependencies? i.e., with a few requires or ES2016 imports?
Yes, if your tsconfig is sufficiently permissive it will simply give any imports for which it can't find a type definition the 'any' type and assume that you can do anything you like with them. Obviously this doesn't give you any help from the type checker but it will work fine and you can go back and add typings later when you decide you need them.
Re: 93% of Paint Splatters Are Valid Perl Programs
#75I miss Perl. Why did PHP win again, in the late 90s? (though I'm mostly Python these days and shan't complain, there was a good 10 year stretch of PHP there I'm not proud of).
mod_perl couldn't live safely on shared servers. You had to rent the whole box if you wanted to use mod_perl.
Re: 93% of Paint Splatters Are Valid Perl Programs
#76I love this footnote so much: > This feature does enable a neat quine: the Perl program “Illegal division by zero at /tmp/quine.pl line 1.”, when saved in the appropriate location, outputs “Illegal division by zero at /tmp/quine.pl line 1.” The reason for this behavior is left as an exercise for the reader.
The part that left my office in stitches:
> (To be fair to Perl, when perl is run with the -w flag to enable warnings, it does helpfully inform the user that at some point in the future, the Perl developers will most likely pick gggijgziifiiffif as a new reserved word:
>> Unquoted string "gggijgziifiiffif" may clash with future reserved word at - line 1.)
Re: 93% of Paint Splatters Are Valid Perl Programs
#77I recently wrote a little program that will create a Markov Chain from on our perl codebase, generate a few sentences and check against `perl -c`. It takes less than 10 attempts to generate a bunch of lines of [very funny] valid Perl code.
Hey! I did that too! Except my version ran the Markov chain against its own source code, which was padded with a bunch of meaningless subs that did were never called but were valid code. It also ran in an infinite loop, which worked well. I had to kill it after a few minutes because I was afraid it would start running shell commands.
Re: 93% of Paint Splatters Are Valid Perl Programs
#78is it true with all OCR engines
Re: 93% of Paint Splatters Are Valid Perl Programs
#79Earlier quoted context omitted.
The parent nailed it. It's easy to complain about PHP from various standpoints both pragmatic and PL-centric, but it has an amazing superpower which might be summed as "serverless for the web, v0".
No deployment setup will ever match the pure joy of dragging a .php file into WinFTP, watching the little blue progress bar, and refreshing your browser.
I practically have that level of “luxury” in my Awful[0] (CHICKEN Scheme) web app that I’m working on right now. With a couple lines of code[1] added to my project (that I have only running in development mode), I can simply save my source code file in Emacs, have it automatically saved on the server through Emacs’s TRAMP feature, reload the page in Firefox, and instantly see my changes. If I like it, I make a commit through magit and I’m off to the next task.
Of course, I don’t run it like this in production (to refresh the production app I have to go to "/reload" from a certain IP address and be logged into the admin account).
Don’t worry: the “old ways” are still here, even if no longer mainstream.
[0]: http://wiki.call-cc.org/eggref/5/awful#a-hello-world-example
[1]: http://wiki.call-cc.org/eggref/5/awful#reload-applications-c...
Re: 93% of Paint Splatters Are Valid Perl Programs
#80I miss Perl. Why did PHP win again, in the late 90s? (though I'm mostly Python these days and shan't complain, there was a good 10 year stretch of PHP there I'm not proud of).
mod_perl couldn't live safely on shared servers. You had to rent the whole box if you wanted to use mod_perl.
Not even mentioning the memory leakiness of it, it even had a module for tracking leaks:
https://perl.apache.org/docs/1.0/guide/performance.html#Memo...