Live data from Hacker News

Perl code that is syntactically correct only on Fridays

github.com

31–40 of 233 posts

Re: Perl code that is syntactically correct only on Fridays

#31

Pro tip: add test cases to your CI runs with modified system date.

Amen.

Worked for a few years at a company with a medium-sized codebase whose tests only worked before 6PM.

(Run the tests later than that, and you wind up with some timeframes that span calendar days and therefore break things. Was the underlying code broken, or the tests, or both? Who knows!!)

Was never allowed to fix and investigate. Or to be specific, we were never given the time to fix it. Management simply didn't see it as a problem.

In my younger days I would have gone all HERO HACKER and fixed it anyway on my own time. But now, I know how that turns out. You waste a bunch of evenings fixing it, and usually introduce some other regressions, and you get zero glory and lots of blame. Best case scenario is no regressions and zero glory.

So, screw it. Old-and-jaded me never lifted a finger. If the company doesn't care, why should I?

But, that is an excellent protip. If you are working on a team that actually values things that work. Time/date dependent code is very tricky to get right, especially when multiple time zones are involved. If your test suite doesn't cover multiple possibilities, your code is nearly guaranteed to be wrong.

It's not even like you have to write brand-new, cleverer tests. Just "brute-force" it, assuming your tests are performant:

before:

    some_tests
after:

    [time_zone_1, time_zone_2, time_zone_3].each do |tz|
       [time_of_day1, time_of_day2, time_of_day3].each do |tod|
         some_tests(tz, tod)
       end
    end
...that kind of thing. That's what I did when I wrote new code at that company, even though I refused to fix the legacy stuff. My tests were faster, too. Almost like I knew what I was doing...

Re: Perl code that is syntactically correct only on Fridays

#32

Why only things like these float up to the front page, and not elegant and/or wholesome things written in Perl?

Right, it’s elegant Perl that would be newsworthy, not gruesome Perl.

(Tongue-in-cheek, I’m actually rather partial to Perl.)

Re: Perl code that is syntactically correct only on Fridays

#33

Pro tip: add test cases to your CI runs with modified system date.

Amen. Worked for a few years at a company with a medium-sized codebase whose tests only worked before 6PM. (Run the tests later than that, and you wind up with some timeframes that span calendar days and therefore break things. Was the underlying code broken, or the tests, or both? Who knows!!) Was never allowed to fix and investigate. Or to be specific, we were never given the time to fix it. Management simply didn'…

Was it a German company? If so "you can only do work during working hours" would be considered a feature not a bug ;)

Re: Perl code that is syntactically correct only on Fridays

#34
post #9

Somewhat related: Perl Cannot Be Parsed: A Formal Proof (2008) https://news.ycombinator.com/item?id=5770531

Well, to be a little pedantic, Perl cannot be statically parsed, since some constructs require runtime context. If it could not be parsed it could never work! And this is totally OK in my book, I use Perl for prototyping ideas and an expressive language that allows creativity from me the programmer is a feature as it promotes looking at a problem from multiple aspects.

“Cannot be X” most often means “in the general case”. (In the context of computability.)

Re: Perl code that is syntactically correct only on Fridays

#35
post #9

Somewhat related: Perl Cannot Be Parsed: A Formal Proof (2008) https://news.ycombinator.com/item?id=5770531

Well, to be a little pedantic, Perl cannot be statically parsed, since some constructs require runtime context. If it could not be parsed it could never work! And this is totally OK in my book, I use Perl for prototyping ideas and an expressive language that allows creativity from me the programmer is a feature as it promotes looking at a problem from multiple aspects.

> Well, to be a little pedantic, Perl cannot be statically parsed, since some constructs require runtime context.

If you're going to be pedantic, it's important to be correct; there's no such thing as dynamic parsing.

> If it could not be parsed it could never work!

What's the logic here? An interpreter doesn't have to operate on an AST, a language doesn't have to have a nontrivial grammar (consider Brainfuck). Perl is just a language in the same category: it doesn't have a (true) nontrivial AST, it doesn't have a (true) nontrivial grammar, and it can't be (truly, nontrivially) parsed.

Re: Perl code that is syntactically correct only on Fridays

#37
post #10

I had an intern once who wrote similar code. They confused 12 hour and 24 hour clocks, so the code would break after lunch. Unfortunately, the intern only worked the mornings, so it took several days of back and forth before the bug could be finally put to rest.

Fantastic. We had a similar problem with test code that always worked on a remote team's computers during their work day but failed when we got into the office and tried to run it in a different timezone.

Reminds me of an app I worked on a while ago where both the server it was running on and the datetimes in the database had to be in a specific time zone. Change either (including changing both to an identical but different TZ) and the app just failed to run.

Re: Perl code that is syntactically correct only on Fridays

#38
post #4

This leverages Perl's BEGIN block which runs before the main part of the code. I suppose the same fun could be had in other languages: if day_of_week is "Friday" eval(piece_of_incorrect_code) else do_sane_operation

Most other languages would require `eval` and having incorrect code as syntactically correct string literal. But because Perl is parsed as it is executed, incorrect code raises syntax error only when it is reached by execution.

Ruby has that latter quality in many scenarios. For example:

    p 'Friday!' if Time.now.wday==5 || h

Re: Perl code that is syntactically correct only on Fridays

#39

Why only things like these float up to the front page, and not elegant and/or wholesome things written in Perl?

Because with its declining popularity, most people here are unfamiliar with the language except for its meme status as "that weird line noise language". Things that confirm pre-existing beliefs are easy to accept and upvote, whereas good Perl code would require (a) some actual thinking, and (b) challenging the socially accepted narrative - both of which are relatively much harder.

Re: Perl code that is syntactically correct only on Fridays

#40
This is how it works:

BEGIN { # an execution block that runs when the module is compiled

    *f = # assigns to the symbol "f" inside the symbol table ...
(localtime->wdayname eq 'Fri') # is it Friday?

        ? sub() {} # ... on friday an anonymous subroutine taking no arguments

        : sub {}; # ... on every other day a subrouting taking arguments
} # closes the execution block

# The following line executes the subroutine "f" and divides the result by 1 on fridays

# but on other days causes the interpreter to trigger a syntax error because it expects

# f to take an argument list "(...)" but receives an operator "/".

f/1;#/+

Post reply on HN