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)

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.

"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!

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

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