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

191–200 of 233 posts

Re: Perl code that is syntactically correct only on Fridays

#191

Post by artdigital »

bentcorner wrote: post #61
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…

Personally I really don't like code that deals with time - it's too easy to place a "get time stamp" call anywhere in code. If it's down in the bowels of some piece of functionality trying to test it becomes a headache.

Move the date up a layer and pass it into the code that deals with it, makes it easy to write tests for it

Re: Perl code that is syntactically correct only on Fridays

#192

Post by barbs »

knodi123 wrote: post #51
johnnyo wrote: 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.

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

Re: Perl code that is syntactically correct only on Fridays

#193

Post by jamesfinlayson »

ljm wrote: post #91
salawat wrote: post #65

Earlier quoted context omitted.

Many people think that test suite authoring is easy mode. It really isn't. Making a good test suite that actually does a good job of tracking invariants is a royal pain.

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.

Re: Perl code that is syntactically correct only on Fridays

#194

Post by zaphirplane »

knodi123 wrote: post #103
darkwater wrote: post #98

Earlier quoted context omitted.

A cronjob to sync the time instead of a proper NTP client doesn't sound that good either. I know that each place has its own weird things because historical reasons but NTP is quite ancient.

Our sysadmin was being paranoid about how many memory-resident programs we ran. he figured time syncing wasn't important enough to justify a daemon, so he just ran the ntpdate command on a daily schedule. It wasn't that bad - after all, how far can clocks drift in a single day!? ;-)

It’s the size of the correction that can cause problems

Re: Perl code that is syntactically correct only on Fridays

#195

Post by zaphirplane »

sandinmyjoints wrote: post #66
bentcorner wrote: post #61

Earlier quoted context omitted.

Personally I really don't like code that deals with time - it's too easy to place a "get time stamp" call anywhere in code. If it's down in the bowels of some piece of functionality trying to test it becomes a headache.

This is one of those pieces of software engineering wisdom that only comes from experience. Try explaining to a newish dev why they shouldn't `const now = Date.now()` or whatever anywhere they want, but rather do it in one place for the lifecycle and pass it around, and they will look at you funny and think it's a waste of time. Classic case of simple vs easy. Time has the potential to complect everything it touches.

Using the same time from the start of the whole operation doesn’t sound broadly right, I’m thinking deadlines retries expire logging

Re: Perl code that is syntactically correct only on Fridays

#196

Post by hondo77 »

bastardoperator wrote: post #118

I worked with Randal L. Schwartz for several years in the Los Angeles area. I was already doing Perl but getting an opportunity to see his code and ask him questions was something that changed my career for the better. Thanks Merlyn!

Ditto, except s/several/a couple of/

Re: Perl code that is syntactically correct only on Fridays

#197

Post by chii »

zaphirplane wrote: post #195
sandinmyjoints wrote: post #66

Earlier quoted context omitted.

This is one of those pieces of software engineering wisdom that only comes from experience. Try explaining to a newish dev why they shouldn't `const now = Date.now()` or whatever anywhere they want, but rather do it in one place for the lifecycle and pass it around, and they will look at you funny and think it's a waste of time. Classic case of simple vs easy. Time has the potential to complect everything it touches.

Using the same time from the start of the whole operation doesn’t sound broadly right, I’m thinking deadlines retries expire logging

you pass around a time provider module, which you can (and should) mock in tests to ensure that nothing catastrophic happens if time drifts in ways you don't really expect.

Re: Perl code that is syntactically correct only on Fridays

#198

Post by hwc »

munk-a wrote: post #178
Spoom wrote: post #88

Earlier quoted context omitted.

Oh yes. Any time I see code that tries to do some kind of scheduling, the first thing I ask is if they have considered using a library someone else has written. Way too many things can subtly go wrong, but new folks tend to think it should be easy, because how hard can it be to work with dates?

There are seven time zones in Indiana in the tz database[1] - this doesn't count the two most used ones America/Chicago and America/New_York there's also a Kentucky tz that slightly spills into the state. Whenever anyone makes any comment about dates and times being easy to compute I just mention that yes, there are seven time zones in Indiana . Now the actual issues tend to arise when software makes assumptions like…

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

Re: Perl code that is syntactically correct only on Fridays

#200

Post by hnick »

mmaunder wrote: post #63
metalliqaz wrote: post #50

Earlier quoted context omitted.

Thank you for this. I hate trying to read Perl so much. What is the "#/+" for?

Worked as a Perl dev for 15 years and enjoyed it. The hardest thing was the number of ways to do OO Perl using Perl5. Everyone has their own flavor. And TMTOWTDI was a motto the community was proud of. Having said that, nothing could touch mod_perl performance under Apache in the late 90s. Massive web apps were built on this including eToys dot com where I worked before it imploded in the dot-com bust.

Perl makes you think differently. True for all languages I guess, but maybe a little truer for Perl than most.

I've moved on but still use it for simple scripting tasks despite doing my best to learn Python. I just feel so expressive and unconstrained writing it, for better or worse.

Post reply on HN