Earlier quoted context omitted.
Aliens landed on this planet, found out about the date format MM/DD/YYYY, and left in a hurry. They are currently preparing a gamma ray burst out of pure compassion and pity but also a hint of disgust!
Is that date format used anywhere outside the US? We have always used YYYY-MM-DD. Which is very nice, if for nothing you can use a single string sort if for whatever reason need to sort them.
Perl code that is syntactically correct only on Fridays
151–160 of 233 posts
Re: Perl code that is syntactically correct only on Fridays
#152Earlier 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.
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?
> because how hard can it be to work with dates?
Man they are so hard that you could go on for hours about it.
Re: Perl code that is syntactically correct only on Fridays
#153Earlier 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.
> Worked as a Perl dev for 15 years and enjoyed it
Similar situation here. Perl is awsome and I'm still bitter that Python won. I mean significant whitespace - what great madness is this???
Anyway, yes, mod_perl ran the Web for about a decade in the early 2000s and I built and maintained huge websites which were all Perl on the back end.
BTW the book "Perl Best Practices" by Damian Conway [0] is the best general programming book I have ever read. Every software engineer should read it no matter what language they program in. So much good advice which applies to pretty much any significant software project. IMHO right up there with the "Mythical Man Month", though obviously much more low level.
[0] https://www.oreilly.com/library/view/perl-best-practices/059...
Re: Perl code that is syntactically correct only on Fridays
#154Earlier 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…
> an intern who wrote code .... his code had been in production You get what you pay for, eh?
No post body was provided.
Re: Perl code that is syntactically correct only on Fridays
#155Earlier 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!? ;-)
> he figured time syncing wasn't important enough to justify a daemon
Time synchronization is very arguable THE most important thing on a server (for numerous security related reasons).
How many moons ago was this incident? It's perhaps forgivable ignorance in the 90s... not so much today.
Re: Perl code that is syntactically correct only on Fridays
#156C code in similar spirit:
$ gcc weird-0.c
$ ./a.out
$ gcc weird-1.c
$ ./a.out
foo(42)
$ cat weird-0.c
#include
void foo(int x)
{
printf("foo(%d)\n", x);
}
int x = 42;
int main(void)
{
#if __LINE__ % 2 == 0
typedef int foo;
#endif
foo(x);
return 0;
}
$ diff -u weird-0.c weird-1.c
--- weird-0.c 2022-02-16 12:09:29.565563802 -0800
+++ weird-1.c 2022-02-16 12:09:38.185718722 -0800
@@ -7,6 +7,7 @@
int x = 42;
+
int main(void)
{
#if __LINE__ % 2 == 0
{
#if __LINE__ % 2 == 0 // If this line number is even
typedef int foo; // foo is a typedef name for int
#endif
foo(x);
return 0;
}
If the typedef is missing, then foo(x) refers to the file-scope identifiers: the function foo and variable x. It is a call to foo passing the value 42 of x.
The preprocessor conditional could easily introduce a syntax error, but the issue in Perl is that a parsing decision (how the / token is lexically categorized) is made based on the compile-time value assigned to f. This is similar to the compile-time meaning of foo we are setting up with the presence or absence of the typedef.
Re: Perl code that is syntactically correct only on Fridays
#157C code in similar spirit: $ gcc weird-0.c $ ./a.out No output from weird-0 $ gcc weird-1.c $ ./a.out foo(42) Output from weird-1. What is weird-0? $ cat weird-0.c #include void foo(int x) { printf("foo(%d)\n", x); } int x = 42; int main(void) { #if __LINE__ % 2 == 0 typedef int foo; #endif foo(x); return 0; } OK, how does weird-1 differ from weird-0? One blank line! $ diff -u weird-0.c weird-1.c --- weird-0.c 2022-02…
With a small change to the weird-0 and weird-1 programs:
$ gcc -O2 -Wall -W weird-0.c
weird-0.c: In function ‘main’:
weird-0.c:15:7: warning: unused variable ‘x’ [-Wunused-variable]
foo(x);
^
$ gcc -O2 -Wall -W weird-1.c
weird-1.c: In function ‘main’:
weird-1.c:16:3: error: too few arguments to function ‘foo’
foo(x);
^~~
weird-1.c:3:6: note: declared here
void foo(int x, int y)
^~~
void foo(int x, int y)
{
printf("foo(%d, %d)\n", x, y);
}
Re: Perl code that is syntactically correct only on Fridays
#158I have seen some code that would fail based not on time but location.
Once we had a client from the Netherlands that complained about a bug that we could not reproduce. We tried to reproduce it by simulating his position, but to no avail. Turns out he was in a very specific, slightly depressed, area that was a few centimetres below mean sea level and that the code didn't like negative altitudes.
Another one only happened in the southern hemisphere. Given we were based in Europe and it was winter, we asked whether we could do some more tests in Australia to make sure there were no more bugs, but sadly it was denied.
Re: Perl code that is syntactically correct only on Fridays
#159Earlier quoted context omitted.
Aliens landed on this planet, found out about the date format MM/DD/YYYY, and left in a hurry. They are currently preparing a gamma ray burst out of pure compassion and pity but also a hint of disgust!
Is that date format used anywhere outside the US? We have always used YYYY-MM-DD. Which is very nice, if for nothing you can use a single string sort if for whatever reason need to sort them.
In my world, there are two date formats: yyyy-mm-dd and dd.mm.yyyy.
Anything involving a slash is asking for trouble.
Re: Perl code that is syntactically correct only on Fridays
#160Earlier 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.
That's a good starting point, and certainly good advice for marking current time and past times. But keep in mind that future event absolute UTC can change due to politics, e.g. a change in daylight savings rules, which is less rare than you might imagine (https://en.m.wikipedia.org/wiki/Daylight_saving_time_by_coun...). That concert scheduled a year from now at 8pm in UTC+5 might actually end up occurring at 8pm in UTC+6.