93% of paint splatters are valid Perl programs (2019) (mcmillen.dev)

As it happens, basically anything is a valid CSV.

If the input is wrong, the server responds with an XML error. This got interpreted as a CSV. Every line became a record, but no column headers were found so every expected field is null/NA. All these nulls get nicely sorted and processed, which causes more string errors, etc ... Mayhem ensues when thst stuff ends up in a database.

93% of paint splatters are valid Perl programs (2019) - https://news.ycombinator.com/item?id=40197013 - April 2024 (124 comments)

93% of Paint Splatters Are Valid Perl Programs (2019) - https://news.ycombinator.com/item?id=27929730 - July 2021 (163 comments)

93% of Paint Splatters Are Valid Perl Programs - https://news.ycombinator.com/item?id=20834351 - Aug 2019 (7 comments)

93% of Paint Splatters Are Valid Perl Programs - https://news.ycombinator.com/item?id=19576425 - April 2019 (132 comments)

  The remainder of the valid Perl programs are mostly valid due to a Perl
  language feature that is not commonly present in most programming languages.
  Namely, Perl has a feature called “unquoted strings”, in which a sequence
  of alphanumeric characters by itself is parsed as though it were a quoted string.
  As an example, Figure 5 is read by OCR as the text ME, which evaluates to the
  string “ME” even though the ME isn’t quoted. This would result in a syntax
  error in most other programming languages.

  (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.)

"An interesting thing about these images is that they’re not particularly Perl-specific; for example, the program shown in Figure −3 also evaluates as the number −3 in Python (and presumably several other programming languages.)"

We live in the age of Python, which I use every day. But I still also use Perl when it's the better tool for the job. And it often is!

Obviously, it's been improved a lot since then - but traditional OCR is mostly about black text on white backgrounds. Or at least, the text being high-contrast relative to the rest of the document.

Light gold text on a white background, while there are black splatters? That's the sort of thing it would struggle with for sure.

[1] https://static.googleusercontent.com/media/research.google.c...

  $ touch temp.pl; perl temp.pl; echo "exit code $?"
  exit code 0

  $ echo "stitch & shutter" > temp.pl; perl temp.pl; echo "exit code $?"
  exit code 0

    Illegal division by zero at /tmp/quine.pl line 1.

See also:

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

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

https://codegolf.stackexchange.com/a/48394

For anything more complex than a one-off script, Perl is pretty much always written with `use strict`, which disables unquoted strings and certain other (mis)features.

Perl has never disappointed me. Many years ago during just 2 weeks I'd written a few clever automations and orchestrations in Perl that had lasted with 100% availability for a decade after I changed that job. Even though my superior, the self-proclaimed "top coder manager all-in-one god" despised it (and me), he was incapable of comprehending and rewriting that. It was not because I obfuscated the code, but because of what I wrote in the first sentence above. In the end he hired a consultancy and got a monstrous solution in Java. But finally it was "his".