Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Perl code that is syntactically correct only on Fridays

github.com

Post reply on HN
Print view View original

221–230 of 233 posts

Re: Perl code that is syntactically correct only on Fridays

#221

Post by amalcon »

dheera wrote: post #129
tentacleuno wrote: post #124

Earlier quoted context omitted.

> because how hard can it be to work with dates? Oh man, tell me about it. Timezones are the worst. No wonder so many people just give up and use Moment.js.

Use UTC UNIX timestamps (i.e. Date.now()) for ALL time-related processing and only convert to hours/minutes when taking input/output from the user.

I once had briefly traveled into a different time zone (so briefly that I hadn't thought about it) when I received a phone call asking to reschedule a doctor appointment. I entered the new time into my calendar. Then, I was an hour late to the appointment. My phone had adopted the timezone of the cell tower, and the calendar assumed I had meant "local time where I scheduled the appointment".

Re: Perl code that is syntactically correct only on Fridays

#222

Post by salawat »

jamesfinlayson wrote: post #193
ljm wrote: post #91

Earlier quoted context omitted.

As far as I'm concerned, writing tests is a different skillset and its often underdeveloped. It then snowballs into hating testing, because all you've experienced is a poor test suite that gets worse over time. It's hard to do well as you say, and it also gets glossed over in code review as long as the tests pass. Do the tests actually verify anything useful? Who knows, build is green! That's how you get an applicati…

My favourite is the test suite where each test relies on data from every other test, so running a test in isolation fails, and adding a new test is almost impossible without breaking a bunch of other tests.

Ugh. Cross test dependency.

Mine is lack of future-proofing. Using dates stuck at one point in time. Or worse, the test suite that fails because of local clock skew.

Re: Perl code that is syntactically correct only on Fridays

#223

Post by dheera »

misnome wrote: post #190
dheera wrote: post #129

Earlier quoted context omitted.

Use UTC UNIX timestamps (i.e. Date.now()) for ALL time-related processing and only convert to hours/minutes when taking input/output from the user.

But I want my 4pm weekly meeting to always happen at 4pm, even if DST changes.

If DST changes and you live in a democracy, it's your fault. Vote against DST. If you don't get what you want unleash the wrath on your congress member, not the software.

Re: Perl code that is syntactically correct only on Fridays

#224

Post by knodi123 »

barbs wrote: post #192
knodi123 wrote: post #51

Earlier quoted context omitted.

Ha. I had an intern who wrote code that blew up if the timestamp of our DB server was ever >= 1 second after the timestamp of our app server. It couldn't fail at his desk, because he ran both servers locally while developing. And it wouldn't fail in production in the morning, since we had a cron job that synced the clocks at midnight. It took until after 5pm for the clocks to drift enough, meaning I was on call and t…

I'm surprised that got through code review

This was the early 2000s, at a very small startup funded privately by a non-technical guy, and most of the technical staff was under 25. It's a big world, and best practices are not universal.

Re: Perl code that is syntactically correct only on Fridays

#225

Post by hnu0847 »

jwilk wrote: post #170
hnu0847 wrote: post #164

Earlier quoted context omitted.

Why does the following expect arguments: : sub {}; Don't all perl subroutines allow any number of arguments (including 0) to be passed? Does the fact that the above is an anonymous subroutine affect the answer to my question?

A sub without prototype (anonymous or not) indeed allows any number of arguments. That's sufficient to trigger the syntax error.

So basically this:

    sub() {}
does not try to parse the /1;#/+ as an argument because the () indicates there are no arguments (although they could be explicitly included if f were called with (), whereas this:

    sub f {}
does try to parse the /1;#/+ as an argument because that's perl's behavior if () are omitted?

Re: Perl code that is syntactically correct only on Fridays

#226

Post by etherealG »

withinboredom wrote: post #216
hwc wrote: post #198

Earlier quoted context omitted.

I just want to specify International Atomic Time, relative to some universally-agreed-upon epoch, in nanosecond units.

So without leap seconds/days, how does one keep their clocks in sync with reality?

One realises that one’s time is relative anyway and any universal time is just one’s own will to join a collective agreement that one doesn’t have to abide by. Then one puts this notion aside and prefers not to worry oneself with such things.

Re: Perl code that is syntactically correct only on Fridays

#227

Post by withinboredom »

etherealG wrote: post #226
withinboredom wrote: post #216

Earlier quoted context omitted.

So without leap seconds/days, how does one keep their clocks in sync with reality?

One realises that one’s time is relative anyway and any universal time is just one’s own will to join a collective agreement that one doesn’t have to abide by. Then one puts this notion aside and prefers not to worry oneself with such things.

Uh. No. In the northern hemisphere, winter is January for centuries and centuries. Almanacs that farmers use also agree with that, so we have food to eat. Reality is much more than just rich first-world comforts. The world is deadly, and we use calendars and time-keeping as a basic survival skill. So basic, you probably don’t even realize it’s there.

Re: Perl code that is syntactically correct only on Fridays

#228

Post by everforward »

withinboredom wrote: post #227
etherealG wrote: post #226

Earlier quoted context omitted.

One realises that one’s time is relative anyway and any universal time is just one’s own will to join a collective agreement that one doesn’t have to abide by. Then one puts this notion aside and prefers not to worry oneself with such things.

Uh. No. In the northern hemisphere, winter is January for centuries and centuries. Almanacs that farmers use also agree with that, so we have food to eat. Reality is much more than just rich first-world comforts. The world is deadly, and we use calendars and time-keeping as a basic survival skill. So basic, you probably don’t even realize it’s there.

There's a difference here between time as a fundamental property of the universe, and "time", which is how we relate a bunch of physical phenomenon to that fundamental force.

That's the primary driver for complexity here. Time as a property is hard to deal with because we take something simple, like how many seconds have passed since some other point in time, and then we have to correlate it to the sun and the moon and how close the Earth is to the sun and what side of the Earth we're on, and etc.

It forces computers to wrap a simple understanding of the passage of time in a lot of context that makes no difference to the computer.

Getting rid of calendaring doesn't imply that no one knows when winter is; winter is still a function of time. It's a pretty simple algorithm to figure out whether a given month is winter or not. It's easy to derive that context from an absolute measurement of time. It's an incredible amount more difficult to go from our calendaring system to any kind of absolute time, because our calendaring is kind of arbitrarily made up to keep things in sync. It bears little semblance to the passage of time, because it's purpose is more about maintaining context (i.e. the sun rises early in the morning, it's winter in January, etc) than actually measuring the passage of time.

Re: Perl code that is syntactically correct only on Fridays

#229

Post by withinboredom »

everforward wrote: post #228
withinboredom wrote: post #227

Earlier quoted context omitted.

Uh. No. In the northern hemisphere, winter is January for centuries and centuries. Almanacs that farmers use also agree with that, so we have food to eat. Reality is much more than just rich first-world comforts. The world is deadly, and we use calendars and time-keeping as a basic survival skill. So basic, you probably don’t even realize it’s there.

There's a difference here between time as a fundamental property of the universe, and "time", which is how we relate a bunch of physical phenomenon to that fundamental force. That's the primary driver for complexity here. Time as a property is hard to deal with because we take something simple, like how many seconds have passed since some other point in time, and then we have to correlate it to the sun and the moon a…

I take it you don’t work remotely with a global team or been homeless? I understand your philosophy and largely agree with it. However reality is much more nuanced.

Re: Perl code that is syntactically correct only on Fridays

#230

Post by recrof »

JohnHaugeland wrote: post #95
WesolyKubeczek wrote: post #25

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

possibly because no such thing exists

because of your taste of perl syntax? that's only thing that makes it different from any other scripting language.
Post reply on HN