Perl code that is syntactically correct only on Fridays(github.com)
github.com
Perl code that is syntactically correct only on Fridays
https://github.com/jwilk/perl-friday
232 comments
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 the intern was not.
But the bug didn't crop up until his code had been in production for a couple of weeks, so it was a real pain in the neck to track down.
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 the intern was not.
But the bug didn't crop up until his code had been in production for a couple of weeks, so it was a real pain in the neck to track down.
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.
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 "every second will actually occur", "each second only happens once", "every minute has 60 seconds", "every day has 86400 seconds" amongst a plethora of other bad assumptions... but those are a lot more complicated to explain. I like leaning on Indiana.
1. https://en.wikipedia.org/wiki/Time_in_Indiana#tz_database
1. https://en.wikipedia.org/wiki/Time_in_Indiana#tz_database
A great collection of those "every minute has 60 seconds" assumptions and why they are incorrect:
https://yourcalendricalfallacyis.com/
https://yourcalendricalfallacyis.com/
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.
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.
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.
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.
> because how hard can it be to work with dates?
Man they are so hard that you could go on for hours about it.
https://www.codingblocks.net/podcast/why-date-ing-is-hard/
Man they are so hard that you could go on for hours about it.
https://www.codingblocks.net/podcast/why-date-ing-is-hard/
> 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.
Oh man, tell me about it. Timezones are the worst. No wonder so many people just give up and use Moment.js.
I've been bit by bugs when coming to moment.js from other languages. It's the only datetime library I knew of, before you'll tell me about all the others, that mutates the datetime object when you do arithmetic.
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.
> certainly good advice for marking current time and past times
But not too far past!
But not too far past!
Uh oh, we’re going there again. If you’re doing anything in the future, that’s not always the correct thing to do. (Instants vs wall time etc)
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".
Hmm, I think you should use TAI over UTC because UTC has leap-second corrections, Which means that the current time + X seconds might not actually be X seconds from now
I learned this the hard way. Now I wrap interactions with system time in a container class so that, if need be, I can finely control time inside my app in unit tests and debugging.
In Haskell, getting the time is an IO operation. Because of this one tends to use the exact pattern you recommend.
It's also one of those things that actually is simple in restricted cases, then when you try to generalise it blows up badly, and it blows up like a time bomb rather than a landmine. When a time bomb explodes you don't quite know when it was triggered, but you have to deal with it then and there, learning a heck of a lot about time libs in general before you can proceed. What's a leap second, which years have a leap day, are time zones connected to places somehow, and so on. Just so you can fix your calendar that's part of a larger app.
> Classic case of simple vs easy.
Personally, I think my definition of "simple" changed over time. Much of that was influenced by the depth of my knowledge of particular paradigms, whether that be software or knowledge of the subjects I was writing code for.
Personally, I think my definition of "simple" changed over time. Much of that was influenced by the depth of my knowledge of particular paradigms, whether that be software or knowledge of the subjects I was writing code for.
Love the Rich references.
The PHP interops group recently added a Clock interface for this purpose. There were many comments along the lines of “what’s the point?”
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.
[deleted]
Move the date up a layer and pass it into the code that deals with it, makes it easy to write tests for it
Not too bad testing these things with mocking libraries.
> an intern who wrote code .... his code had been in production
You get what you pay for, eh?
You get what you pay for, eh?
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.
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.
For security? Kerberos usually has a 5 minute tolerance. Are you saying that's wrong? Because if your hardware/firmware isn't literally broken you won't drift anywhere near that in a day.
NTP can't properly fix a clock like that either since it's often capped at adjusting the speed by one part per two thousand. At most, with a consistently wrong clock, that can handle about 30 seconds per day. Any worse than that and you won't see much advantage over ntpdate.
NTP can't properly fix a clock like that either since it's often capped at adjusting the speed by one part per two thousand. At most, with a consistently wrong clock, that can handle about 30 seconds per day. Any worse than that and you won't see much advantage over ntpdate.
The bigger the clock skew, the harder it is to correlate events from logs. The harder it is to corelate, the more information needs to come from your machine-fueled winnowing stage, to the final inspection by eyeballs.
1-2 seconds is (probably) well within manageable. But, since you now know for SUER that you have clocks running at different speeds, you need to over-estimate the skew. And hope that the daily skewing is approximately constant over time.
So, yes, clock skew can have an impact on your security, because it makes event correlation (and followup on security incidents) harder.
1-2 seconds is (probably) well within manageable. But, since you now know for SUER that you have clocks running at different speeds, you need to over-estimate the skew. And hope that the daily skewing is approximately constant over time.
So, yes, clock skew can have an impact on your security, because it makes event correlation (and followup on security incidents) harder.
"It makes logs more annoying, and sometimes security needs logs" is a pretty weak connection, though. And it's a far cry from precise timing being "THE most important thing on a server". Is there anything more direct at all?
It's basically a whole bunch of small "make it harder to correlate" issues. If you have a distributed system (which you probably do, if you care about time to the point of considering if daily ntpdate or continually running ntp-or-equivalent is better), you will probably end up with timestamps somewhere in a protocol.
This could be timestamps in a DB server, or similar.
You can then, if you have too-large skew, end up in the weird position that one of "things that have been commited in the DB is not yet showing up on the frontends" (if the time used as a cut-off for the frontend's query is lagging behind the DB server and the timestamp is set by the DB server) or "things that have been commited are not showing up when you query for SELECT timestamp <= NOW()" (if the DB server is lagging, and the timestamp is set by the client).
If that maters, well, that's really a business and data quality issue.
Some distributed systems will also try to figure out what skew you have across the whole system and then end up taking N times that skew, before it can consider data persisted (see for example Spanner ,and probably CockroachDB). If your distributed system relies on timestamps for consistency, and it doesn't self-discover the skew, you're basically not guaranteed whatever consistency guarantees that the distributed system claims to have.
Again, is this important? It really depends. Is it OK of your distributed data store drops some of your data on the floor and lets you clean up the mess? Sometimes, yes, totally. Is it OK if you get uniqueness guarantees violatedl because two thigs got the same unique ID? Again, sometimes, almost-unique is enough.
Fo most people, log correlation is probably the biggest point, though.
This could be timestamps in a DB server, or similar.
You can then, if you have too-large skew, end up in the weird position that one of "things that have been commited in the DB is not yet showing up on the frontends" (if the time used as a cut-off for the frontend's query is lagging behind the DB server and the timestamp is set by the DB server) or "things that have been commited are not showing up when you query for SELECT timestamp <= NOW()" (if the DB server is lagging, and the timestamp is set by the client).
If that maters, well, that's really a business and data quality issue.
Some distributed systems will also try to figure out what skew you have across the whole system and then end up taking N times that skew, before it can consider data persisted (see for example Spanner ,and probably CockroachDB). If your distributed system relies on timestamps for consistency, and it doesn't self-discover the skew, you're basically not guaranteed whatever consistency guarantees that the distributed system claims to have.
Again, is this important? It really depends. Is it OK of your distributed data store drops some of your data on the floor and lets you clean up the mess? Sometimes, yes, totally. Is it OK if you get uniqueness guarantees violatedl because two thigs got the same unique ID? Again, sometimes, almost-unique is enough.
Fo most people, log correlation is probably the biggest point, though.
Admin like that sound a lot worse than the intern. Unless maybe if it's an intern-admin...
If you are to be paranoid about time, better be paranoid about stepping time. Time discontinuities can trigger bugs in the best of software.
Guess it's time to change the `0` in that cronjob to a `*/12`.
after all, how far can clocks drift in a single day!?
Well, having run a Linux kernel on OpenBSD's vmm: they can drift more than a single day in that time. I did have to resort to using an ntpdate cron job because ntpd just couldn't cope with the time dilation effect. The cron job was configured at * * * * * (i.e. every minute), which roughly translated to once every 180 wall-clock seconds (+/- 30s).
Well, having run a Linux kernel on OpenBSD's vmm: they can drift more than a single day in that time. I did have to resort to using an ntpdate cron job because ntpd just couldn't cope with the time dilation effect. The cron job was configured at * * * * * (i.e. every minute), which roughly translated to once every 180 wall-clock seconds (+/- 30s).
It’s the size of the correction that can cause problems
I've done equally stupid things as a senior dev. The biggest difference, I guess, is that I had to fix the stuff I broke.
Delivering real functionality in production (with code review from your mentor, of course) is absolutely standard at a Big Tech or hot startup internship.
Depends. FAANG interns can make (annualized) income at or near 6 figures.
[deleted]
To be honest, I wrote code that blew up after the time server updated the time from the network, a few seconds after booting.
I once had to implement date picker that returned the date to be sent to backend to fetch the day's reservations. It seemed to work fine the day I implemented it. Next day it broke. Turned out the widget returned MM/DD/YYYY instead of DD/MM/YYYY.
And I implemented it on 10th of October.
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.
Anything involving a slash is asking for trouble.
I'm a big fan of ISO 8601. Eliminates the confusion, and sorts lexicographically too.
Yeah, me too. I had severe time constraints (heh) and just wanted to be done with it with minimal conversion. Which I then had to do anyway later. I also learned on that day that Javascript's getUTCMonth() is zero-based (January is month 0). And I had to sync time between timezones as well. I don't want to work with dates ever again.
I've learned the hard way that this is also dependent on the user's date format set on their computer in some libraries(iirc it was jquery ui date picker a few years back). its liberating when you decide to throw it all out and just use integers for all things not facing an end user.
We had situation where if you worked late, the test suite would consistently fail.
Since developers rarely worked late and would give up when hitting the "random" test suite failure and go home, the bug persisted for months before the true cause was understood.
Our time zone was UTC-5, and the test suite contained a local-vs-UTC bug which only triggered between 7pm and midnight.
Since developers rarely worked late and would give up when hitting the "random" test suite failure and go home, the bug persisted for months before the true cause was understood.
Our time zone was UTC-5, and the test suite contained a local-vs-UTC bug which only triggered between 7pm and midnight.
I feel like this is relatively common (unfortunately)
It is. I'm in London which means that our time is +/- 1 hour of UTC depending on daylight saving time.
There's been a couple projects where if I pushed a commit between 11pm and 1am some tests would break. I'm pretty sure the issue is inconsistent use of UTC vs local time which during that period will differ by one day.
There's been a couple projects where if I pushed a commit between 11pm and 1am some tests would break. I'm pretty sure the issue is inconsistent use of UTC vs local time which during that period will differ by one day.
One of the perils of working in the UK is _assuming_ that you've been using UTC timestamps this whole time, and then summer rolls around and suddenly a bunch of tests start failing, and all your production logs are an hour out because you were wrong, and actually used local timestamps everywhere. Oops.
I had to fix tests that broke from 11pm-midnight because some assumptions that now() + 1 hour was the same local date.
I worked with date range in a service that expected start date to be inclusive, but end date to be exclusive. So when you wanted to get data from dates 12-15, you'd have to send query for 12-16.
That sounds like a naive date->datetime conversion rather than explicit boundary exclusion. If you convert a date to a datetime, you get midnight at the start of day, which is fine if you're only comparing dates, but fails spectacularly in the way you describe for date ranges.
MSSQL not supporting a DATE data type has been the bane of my existence for a long time (of course, Postgresql has supported it since forever, but try telling your application vendor that). And since it took so long to include it, hardly any application uses it even today, because of inertia and compatibility with existing databases.
MSSQL not supporting a DATE data type has been the bane of my existence for a long time (of course, Postgresql has supported it since forever, but try telling your application vendor that). And since it took so long to include it, hardly any application uses it even today, because of inertia and compatibility with existing databases.
I had a coworker working on a data-pipeline sort of thing once. They for some reason wrote their own date parser (Akamai logs) and used a regular expression to find the month. For whatever reason, the RegExp didn't work for March (I think) and so at midnight 1 March the year of first deploy, we started dropping all the logs as un-parseable (causing the NOC to think the traffic had gone to 0 or our system was buggy). We all got paged and eventually figured out it. It had been running in live for several months without problems at that time.
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.
I've seen something similar where some automated unit tests always passed and when I tried to run it locally would always fail. After digging around I realized it was making assumptions about the timezone it ran in, which was on the east coast, whereas I was on the west.
I've had to fix any number of test suite bugs as well as regressions that happened because the people who wrote the tests had ensured the test suite didn't (most of the time) test what they thought it would by relying on date arithmetic from current date and time...
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 application with 50,000 unit and integration tests that you can't run locally, and requires massive parallelism in CI to finish in any reasonable timeframe.
That's how you get an application with 50,000 unit and integration tests that you can't run locally, and requires massive parallelism in CI to finish in any reasonable timeframe.
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.
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.
That's standard runtime issue right? This is syntax error at compile time.
Kind of sort of. The catch here is that because runtime is compile time with Perl, it's not exactly the same. Looking at the code, it's kind of like having something like
Another equivalent piece of code could be something along the lines of the JS
#if (some C preprocessor expression that's true on Fridays
printf("Hello world!);
#else
printf;
#fi
Another equivalent piece of code could be something along the lines of the JS
if (today_is_friday()) {
eval("2+2")
}
else {
eval("--2abc")
}>(a) there exists a C-preprocessor instruction as per the above
There's no day-of-week but you could cause mayhem with __DATE__
>(2) if the compiler will notice errors in the unexecuted branch of an #if
Compiler only gets to see preprocessor output, it won't.
>if printf; would give a syntax error
Perhaps surprisingly but no, it's just statement without effect (containing expression returning function pointer to printf).
There's no day-of-week but you could cause mayhem with __DATE__
>(2) if the compiler will notice errors in the unexecuted branch of an #if
Compiler only gets to see preprocessor output, it won't.
>if printf; would give a syntax error
Perhaps surprisingly but no, it's just statement without effect (containing expression returning function pointer to printf).
> you could cause mayhem with __DATE__
It takes some patience, but people do try: https://stackoverflow.com/questions/11697820#16472369
It takes some patience, but people do try: https://stackoverflow.com/questions/11697820#16472369
[deleted]
One perhaps apocryphal story that's kicking around out there was that Draper Labs had a hard-real-time navigation system which... took too much time computing something when the moon was full.
Saw some tests that had the same pattern. Passed half the day, and failed the other half of the day. I assume it always worked during India work hours.
Fortunately we rarely use 12h clocks where I live. But that opens up other avenues: if you are not much of an early riser, a build script failing to deal with single digit hours can remain undetected for a very long time.
It could have been much worse. At least you didn't have a leap year or timezone bug. I've exterminated more than one of those in my time as an engineer, and it's never really any fun.
[deleted]
Like many here, I’ve faced similar challenges in debugging time-dependent code.
What is the best way to set or mock system time during testing?
What is the best way to set or mock system time during testing?
I once took over code which only worked in single digit month numbers.
This is how it works:
BEGIN { # an execution block that runs when the module is compiled
# 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;#/+
BEGIN { # an execution block that runs when the module is compiled
*f = # assigns to the symbol "f" inside the symbol table ...
? sub() {} # ... on friday an anonymous subroutine taking no arguments
: sub {}; # ... on every other day a subrouting taking arguments
# 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;#/+
> # 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
You have this the opposite way round to what's happening (and the description). It only compiles on a Friday, i.e. when the sub takes no arguments.
Removing all the "only on a Friday" stuff boils down to the difference between these two:
However, when the sub does accept args, `f <stuff>` tries to compile `<stuff>` into arguments to send - and it's a regex pattern `/.../` so the # isn't a comment, it's part of the regex, and the + is where modifiers go - but it's invalid, and is the syntax error. A valid pattern modifier would also compile, e.g.:
> # but on other days causes the interpreter to trigger a syntax error
You have this the opposite way round to what's happening (and the description). It only compiles on a Friday, i.e. when the sub takes no arguments.
Removing all the "only on a Friday" stuff boils down to the difference between these two:
# this compiles
sub f() {}
f/1;#/+
# this doesn't compile
sub f {}
f/1;#/+
sub f {}
f /1;#/;
However, when the sub does accept args, `f <stuff>` tries to compile `<stuff>` into arguments to send - and it's a regex pattern `/.../` so the # isn't a comment, it's part of the regex, and the + is where modifiers go - but it's invalid, and is the syntax error. A valid pattern modifier would also compile, e.g.:
sub f {}
f/1;#/m
use feature 'say';
sub f { shift ? "matched" : "unmatched" }
$_ = 'this matches 1;#';
say f /1;#/;
$_ = 'this does not match';
say f /1;#/;
matched
unmatched
use feature 'say';
sub f { int shift }
$_='1;#';
say f/1;#/+1 # prints 2> You have this the opposite way round to what's happening (and the description). It only compiles on a Friday, i.e. when the sub takes no arguments.
Isn't that what the parent said, going by your quote? They said "the following line [...] on fridays but on other days causes the interpreter to trigger a syntax error".
Isn't that what the parent said, going by your quote? They said "the following line [...] on fridays but on other days causes the interpreter to trigger a syntax error".
Yes! You're right. Not sure what happened to my brain there. Too much staring at Perl, I suspect.
This is generally correct, but your final analysis is slightly wrong and this is a perfect example of why Perl can be difficult to parse.
If you add a 1 to the end of the "f/1;#/+" line, so that it becomes "f/1;#/+1", the code will become correct.
What's actually happening is that on Fridays, the "f/1;#/+" line means "call f, divide the result by 1, and throw away the result", followed by a comment. On any other day, it means "call f with the regex parameter /1;#/ and add an unspecified parameter to it". Since the right hand side of the + operator isn't specified, it is syntactically incorrect.
If you add a 1 to the end of the "f/1;#/+" line, so that it becomes "f/1;#/+1", the code will become correct.
What's actually happening is that on Fridays, the "f/1;#/+" line means "call f, divide the result by 1, and throw away the result", followed by a comment. On any other day, it means "call f with the regex parameter /1;#/ and add an unspecified parameter to it". Since the right hand side of the + operator isn't specified, it is syntactically incorrect.
Why does the following expect arguments:
Does the fact that the above is an anonymous subroutine affect the answer to my question?
: sub {};
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() {}
sub f {}
That's right.
Thank you for this. I hate trying to read Perl so much.
What is the "#/+" for?
What is the "#/+" for?
> What is the "#/+" for?
I am sure this is not necessary for the behavior described. It's just a comment.
BTW: I am working for a company still maintaining a large Perl code base and I think this is rather obscure stuff. You rarely need to run something at compile time, hack the symbol table and you almost never need "sub() {}" to define subroutines with an empty "prototype". If I saw this in a code review I would most definitely had a closer look and would decline a PR if that was unnecessary. Meta programming should not be done lightheartedly and better serves a serious purpose.
I am sure this is not necessary for the behavior described. It's just a comment.
BTW: I am working for a company still maintaining a large Perl code base and I think this is rather obscure stuff. You rarely need to run something at compile time, hack the symbol table and you almost never need "sub() {}" to define subroutines with an empty "prototype". If I saw this in a code review I would most definitely had a closer look and would decline a PR if that was unnecessary. Meta programming should not be done lightheartedly and better serves a serious purpose.
On Fridays, it's just a comment.
Otherwise, "f/1;#/+" is equivalent to something like:
Otherwise, "f/1;#/+" is equivalent to something like:
f(/1;#/ +)
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.
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...
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...
The Damian was a phenomenon of pure inspiration. In fact Perl community in general had a pantheon of acolytes I've never seen in any other programming community. Ruby has a few but nowhere near as many as Perl. Perl in the early 2000s really was on fire.
> 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.
One of my frist dev jobs was slinging perl script, I loved that attitude and it made for a fantastic learning environment. I really dislike the feeling of having to write code in a straightjacket because tHe TeAm CaN't UnDeRsTaNd iT!!!
We minimized the negatives of TMTOWTDI by incorporating a house style, but it was flexible because we were all smart people whose minds didn't crash because we saw a statement we didn't expect.
One of my frist dev jobs was slinging perl script, I loved that attitude and it made for a fantastic learning environment. I really dislike the feeling of having to write code in a straightjacket because tHe TeAm CaN't UnDeRsTaNd iT!!!
We minimized the negatives of TMTOWTDI by incorporating a house style, but it was flexible because we were all smart people whose minds didn't crash because we saw a statement we didn't expect.
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.
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.
Ruby is a much better option than Python for expat Perl geeks.
Moose, Mouse, Moo, Mo ... bah! Just give me The Damian's simple blessed hashref.
[deleted]
Flavor? "#" starts a comment, so the "/+" characters are ignored by the interpreter.
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_operationMost 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.
But because Perl is parsed as it is executed, incorrect code raises syntax error only when it is reached by execution.
Right, the beauty of this is that it's a syntax error he's produced. Sure any language can write code to produce a runtime error under any condition at all. And a lot of languages have features that allow them to run code at compile time, and similarly produce errors then too. But those languages don't allow you to ruin the syntax of the language. I guess it's something that requires macros. Would it be safe to say that any language with macros can do this? Or is there something even more interesting with perl going on here?
Common Lisp is another language in which this should be possible. Common Lisp allows you to run arbitrary code at compile-time, and that code is allowed to modify the language syntax (*READTABLE*, SET-MACRO-CHARACTER, etc). So code could make itself syntactically invalid on Fridays by changing the language syntax depending on the day of the week.
This goes beyond mere Lisp macros, in that ordinary Lisp macro invocations still look like Lisp lists, while with this you can make arbitrary changes to the syntax, you could even make Common Lisp look like Pascal (if you really wanted to)
The designers of Scheme intentionally left this feature out (which was also found in some of Common Lisp’s ancestors, such as Maclisp), but some Scheme implementations/descendants included it anyway (as an extension), such as Racket, Guile and Chicken Scheme.
This goes beyond mere Lisp macros, in that ordinary Lisp macro invocations still look like Lisp lists, while with this you can make arbitrary changes to the syntax, you could even make Common Lisp look like Pascal (if you really wanted to)
The designers of Scheme intentionally left this feature out (which was also found in some of Common Lisp’s ancestors, such as Maclisp), but some Scheme implementations/descendants included it anyway (as an extension), such as Racket, Guile and Chicken Scheme.
[deleted]
i can do something like this with macros in pike:
the following code produces a syntax error if the time is less than 10 seconds after a full minute.
the following code produces a syntax error if the time is less than 10 seconds after a full minute.
#define T __TIME__
#if T[6]-48
#define X 1
#else
#define X /
#endif
void main()
{
write("%d, %c, %O\n", X, T[6], T);
}Bash parses as it runs so something as simple as this works
if [ $(date +%u) -ne 5 ]
then
exit
fi
(Bash even reads the file as it goes, so if you run a "long-running" script (a sleep is enough), edit far enough down, and write the file again, the previously started bash will end up running the new content once it gets up to reading where the change happened.
You can exploit it do distinguish whenever script is `curl | bash`'ed.
Add `sleep 1`, and detect pause on server. Then, if pause detected - serve attack payload. If not - somebody is careful enough to download and audit, so serve just the script.
Add `sleep 1`, and detect pause on server. Then, if pause detected - serve attack payload. If not - somebody is careful enough to download and audit, so serve just the script.
https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...
Discussed on HN:
2020: https://news.ycombinator.com/item?id=25356757 (133 comments)
2018: https://news.ycombinator.com/item?id=17636032 (146 comments)
2016: https://news.ycombinator.com/item?id=11532599 (122 comments)
Discussed on HN:
2020: https://news.ycombinator.com/item?id=25356757 (133 comments)
2018: https://news.ycombinator.com/item?id=17636032 (146 comments)
2016: https://news.ycombinator.com/item?id=11532599 (122 comments)
You could check syntax of the whole file (even the unreachable parts) with the -n option.
But that's not bulletproof; consider this code (adapted from <https://hal.archives-ouvertes.fr/hal-01513750/document>):
But that's not bulletproof; consider this code (adapted from <https://hal.archives-ouvertes.fr/hal-01513750/document>):
if [ $(date +%u) -eq 5 ]
then
alias maybe=''
else
alias maybe=:
fi
maybe for x in; do :; done
It is formally proven that Perl can't be parsed!
https://www.perlmonks.org/index.pl?node_id=663393
https://www.perlmonks.org/index.pl?node_id=663393
It can be externally parsed with ambiguities. The article is written by someone who authored such a parsing toolkit about three years later. Despite what you may have learnt, an ambiguous parse tree is still a useful thing to have, we can build tools taking it into account, also most existing tools can be modified in a straightforward fashion to make use of the extra nodes.
The real Perl parser disambiguates with heuristics and run-time hints.
There exists an unambiguous subset of Perl syntax that is expressible with a BNF grammar, and such is amenable to all parsers. http://p3rl.org/standard#DESCRIPTION
The real Perl parser disambiguates with heuristics and run-time hints.
There exists an unambiguous subset of Perl syntax that is expressible with a BNF grammar, and such is amenable to all parsers. http://p3rl.org/standard#DESCRIPTION
Yeah, I always found the linked post to not be all that serious about it anyway, just a funny, satisfying hacker thing.
It has been said that "the Perl compiler is based on yacc, lex, smoke, and mirrors."
But because Perl is parsed as it is executed, incorrect code raises syntax error only when it is reached by execution.
Sorry, but you're dead wrong. Perl is not parsed as it is executed, which can be verified easily by writing a program with a syntax error at the end, and seeing that it doesn't run code at the top. Try it with the following program.
In this case we're assigning to a symbol. And then the parsing of the final line is dependent on whether or not that symbol has a prototype. See https://perldoc.perl.org/perlsub#Prototypes for what Perl prototypes are, and to see why they would affect parsing.
Sorry, but you're dead wrong. Perl is not parsed as it is executed, which can be verified easily by writing a program with a syntax error at the end, and seeing that it doesn't run code at the top. Try it with the following program.
print "Hello, world\n";
This line raises a syntax error before the previous line tries to execute.
In this case we're assigning to a symbol. And then the parsing of the final line is dependent on whether or not that symbol has a prototype. See https://perldoc.perl.org/perlsub#Prototypes for what Perl prototypes are, and to see why they would affect parsing.
>incorrect code raises syntax error only when it is reached by execution.
That's not generally true for Perl. The BEGIN block is used to get in that state here. "Some incorrect code raises syntax error only when it is reached" is true.
It's generating this on Fridays:
That's not generally true for Perl. The BEGIN block is used to get in that state here. "Some incorrect code raises syntax error only when it is reached" is true.
It's generating this on Fridays:
&f() / 1;
f(/1;#/+);
'f' / 1;What happens if you run this code in a loop Thursday night just before Friday?
Does the parse that happens on Thursday take precedence or is it reparsed every single time through the loop?
Does the parse that happens on Thursday take precedence or is it reparsed every single time through the loop?
The BEGIN block only runs once. That is:
You could loop inside the BEGIN block and then drop out of the loop at some point. If you dropped out on friday, after the code assigning *f, it would run correctly. So:
while (1) {
BEGIN {print "hello\n"}
sleep 1;
}
You could loop inside the BEGIN block and then drop out of the loop at some point. If you dropped out on friday, after the code assigning *f, it would run correctly. So:
BEGIN {
sleep 86400;
*f = (localtime->wdayname eq 'Fri')
? sub() {}
: sub {};
}
f/1;#/+
Perl is not parsed as it is executed. It is compiled to opcodes then run. The BEGIN block, however, explicitly runs code at compile time. It is literally compiling different code on different days, then attempting to run it.
Technically not opcodes, but internal Data Structures. A serializer was written for that, to permit ".pmc files".
Oh, hey, Randal. Thanks for the correction.
Looking forward to the next time we can have steaks and Scotch.
Looking forward to the next time we can have steaks and Scotch.
Ruby has that latter quality in many scenarios. For example:
p 'Friday!' if Time.now.wday==5 || hMoral quandary of the morning: Do I point out the sign error or do I just say please don't merge this?
That looks like a syntactically correct piece of code that fails at runtime.
In similar vein: parsing C++ is literally undecidable: https://blog.reverberate.org/2013/08/parsing-c-is-literally-...
You can't even decide if a particular "*" is multiplication or a pointer dereference until you resolve templates, which is Turing-complete.
You can't even decide if a particular "*" is multiplication or a pointer dereference until you resolve templates, which is Turing-complete.
Compilers decreasingly encounter parses that depend on template instantiation, as users move to new constexpr alternatives to template metaprogramming.
So the right implementation choice, for the compiler, is to bull ahead with the common case, and throw the result away and try the other path if you get to an inconsistency. Such inconsistencies practically never happened in production code anyway, and where they did it most usually was, and now almost always is, a result of a bad edit.
So the practical expense is keeping and then GCing old state as it expires, which reduces to stack-like memory management, a solved problem.
We have not needed to go to JITting compile-time constructs, (though it could still happen to expedite constexpr evaluation). Rust might need to, soon, to accommodate parsing under influence of macros, a chore growing with time, not shrinking. (I.e., produce a new parser for each macro added, and jump into it to finish the parse.)
So the right implementation choice, for the compiler, is to bull ahead with the common case, and throw the result away and try the other path if you get to an inconsistency. Such inconsistencies practically never happened in production code anyway, and where they did it most usually was, and now almost always is, a result of a bad edit.
So the practical expense is keeping and then GCing old state as it expires, which reduces to stack-like memory management, a solved problem.
We have not needed to go to JITting compile-time constructs, (though it could still happen to expedite constexpr evaluation). Rust might need to, soon, to accommodate parsing under influence of macros, a chore growing with time, not shrinking. (I.e., produce a new parser for each macro added, and jump into it to finish the parse.)
Unless something has changed a lot, C++ templates at least only used to be Turing complete if you assume you're allowed unlimited recursive template applications, and compilers were free to restrict that (and did). Has that changed?
In theory I agree with you that this is horribly ugly - I very much prefer simple grammars (the irony being my favourite language to use is Ruby, which has an atrocious grammar). In practice these parses are rarely that hard to resolve.
In theory I agree with you that this is horribly ugly - I very much prefer simple grammars (the irony being my favourite language to use is Ruby, which has an atrocious grammar). In practice these parses are rarely that hard to resolve.
It's not the undecidability itself that is the problem though. The undecidability is just an indicator how horribly complicated C++ is to compile.
You cannot even construct the full parse tree before evaluating a mini-language that is Turing complete. Related article: why C++ compilation is slow (https://digitalmars.com/articles/b54.html)
You cannot even construct the full parse tree before evaluating a mini-language that is Turing complete. Related article: why C++ compilation is slow (https://digitalmars.com/articles/b54.html)
I have a half-finished Ruby compiler sitting around, so I'm a bit jaded when it comes to how complicated something is to compile. C++ is complex, but at least it's reasonable well specified.
Well, C++ now has constexpr functions that can run in compile time, and do basically arbitrary computation. But it also has implementation limits.
Semi-related HN classic: "Openoffice can’t print on Tuesdays" https://news.ycombinator.com/item?id=8171956
A handful of curated weird stories like this: https://500mile.email/
A handful of curated weird stories like this: https://500mile.email/
I have written code that only works in winter because of daylight saving times and some unfortunate date conversions, but having a temporary correct syntax is really a new high.
As a part of a release always got borked, I wrote a small bash script that took currently deployed files, archived them to rollback_dateandtime.tgz, then put the freshly released files in its place.
It turns out we never did a release before 10:00, because it ran fine for a few years, but the regex constructing the filename could not deal with hours consisting of 1 number.
Oh well, never write production shell scripts while your platform is burning.
The fix is literally 1 character, but I only get access when production burns. So I was not allowed to change it and the owner does not want to implement it and file all release paperwork it entails. Instead, mgmt forbid this type of release before 10:00.
It turns out we never did a release before 10:00, because it ran fine for a few years, but the regex constructing the filename could not deal with hours consisting of 1 number.
Oh well, never write production shell scripts while your platform is burning.
The fix is literally 1 character, but I only get access when production burns. So I was not allowed to change it and the owner does not want to implement it and file all release paperwork it entails. Instead, mgmt forbid this type of release before 10:00.
This is why we can't have nice things.
I have written code (at work) that crashes when the moon is in a specific phase.
I had a "switch(moon_phase)" and forgot one of the cases... And the Android app was in debug mode, so any uncaught exception brought the whole thing down.
I had a "switch(moon_phase)" and forgot one of the cases... And the Android app was in debug mode, so any uncaught exception brought the whole thing down.
Not nearly as cursed as two parent comments, but there was a widespread problem in my very popular Android app. The relative date formatting function worked incorrectly for many users, it was off by one hour. It turns out that when Russia (where most of our users were) had abolished DST, and then changed timezones a couple of times, people got really confused. Since Android's timezone data is part of the system, it was basically set in stone. Most of the users didn't choose the timezone with the correct offset, but instead set their time an hour forward so the incorrect timezone and incorrect unixtime cancel each other out for a "correct" displayed time.
I ended up getting the known correct unixtime from the server to try to guess which timezone offset the user actually meant and correcting the result of System.currentTimeMillis() and my formatting for that.
I ended up getting the known correct unixtime from the server to try to guess which timezone offset the user actually meant and correcting the result of System.currentTimeMillis() and my formatting for that.
Having the code crash every full moon would be pretty cursed tbh.
I have once heard of some software that would crash on some Wednesdays. Apparently Wednesday is the longest day name, and it was overflowing some buffer. But only if the day of the month was 10 or above, because the strings 1-9 still fit in the buffer.
> I have written code that only works in winter because of daylight saving times and some unfortunate date conversions
Not sure where you are located, but this can be particularly bad in the UK where winter time happens to coincide with UTC.
Not sure where you are located, but this can be particularly bad in the UK where winter time happens to coincide with UTC.
Yeah it’s horrible. I had a contract a number of years ago to fix a bug that they had been fighting for 5 years. When winter time kicked in all appointments on their booking system collapsed to zero minutes long.
To fix this they ran a SQL script that changed the end date on the DST switch over but that had some poor assumptions in it and made it worse.
It also had to be correct in the past and the future.
I just rewrote the whole fucking thing from scratch.
To fix this they ran a SQL script that changed the end date on the DST switch over but that had some poor assumptions in it and made it worse.
It also had to be correct in the past and the future.
I just rewrote the whole fucking thing from scratch.
Let's be pedantic about this, because this is one of the very few areas where pedantry matters: GMT ("British Winter Time") is NOT UTC, and it can differ from UTC up to 0.9 seconds. GMT is a time zone (corresponding to UT1). UTC is a time standard.
To be pedantic, this is an area where pedantry occasionally matters. For the vast majority of (casual) usage, it doesn't.
Indeed. I get invites from people from the UK who simply refer to the current local time (GMT or BST) as "GMT". It just means current London time to them.
Same happens in the US, people use EST/EDT interchangeably (and incorrectly) when they mean Eastern timezone. Or Central/Mountain/Pacific.
I appreciate your pedantry, and I wonder if you know of a widely used computer system which genuinely implements the GMT time zone as something different from UTC+0.
There may be some niche astronomical or legal(?) applications which have to keep track of the potential 0.9 seconds skew, but my impression is that any app which claims to support a "GMT" (or Europe/London) option is actually only supporting "GMT-ish".
There may be some niche astronomical or legal(?) applications which have to keep track of the potential 0.9 seconds skew, but my impression is that any app which claims to support a "GMT" (or Europe/London) option is actually only supporting "GMT-ish".
Ok, fair enough. But it's close enough that it's very easy for anything that isn't working with second-level granularity to seem like they're working only to break as soon as the time switches BST.
> GMT is a time zone (corresponding to UT1)
Are you sure? Looking into things I would have said that GMT exists as a time reference but all the time zones are based on UTC.
Are you sure? Looking into things I would have said that GMT exists as a time reference but all the time zones are based on UTC.
The first iPhone app I wrote back in college would crash if you used it in a time zone with a positive UTC offset. I can't even remember why.
I don't get it! It is clearly written in the code, that the progam should behave this way.
Is the proof, that perl is capable of this behaviour?! I don't get it - what is the point?
I read all the comments and still don't get it. What am i missing?
Is the proof, that perl is capable of this behaviour?! I don't get it - what is the point?
I read all the comments and still don't get it. What am i missing?
What makes it "special" here is the fact that it will COMPILE only on a friday.
It's not a runtime error but a compile time error. Because yes otherwise I would agree that it's doable easily in every single language.
It's not a runtime error but a compile time error. Because yes otherwise I would agree that it's doable easily in every single language.
Here's a D program that only fails to compile if the last digit of the current number of seconds is 4:
enum timestamp = __TIMESTAMP__;
void main() { pragma(msg, timestamp[$-6..$-5]); auto a = 4; static if(timestamp[$-6..$-5] == "4") { auto a = 7; } }
enum timestamp = __TIMESTAMP__;
void main() { pragma(msg, timestamp[$-6..$-5]); auto a = 4; static if(timestamp[$-6..$-5] == "4") { auto a = 7; } }
But isn’t this possible with any language that has a pre-compilation step? Perl is certainly conflating its passes (as explained by other comments above), but in rust you could add a check in build.rs or use macros in C to accomplish the same, right?
Isn't perl an interpreted language? Or I am missing a point?
What will happen when the command is `perl -c friday.pm`?
What will happen when the command is `perl -c friday.pm`?
You get the same output with "perl -c". (Actually I've just updated README to use that.)
Note that the error message is "friday.pm had compilation errors, so yes, there's a compilation phase. It's not compiled to the machine code, though.
Note that the error message is "friday.pm had compilation errors, so yes, there's a compilation phase. It's not compiled to the machine code, though.
You can write code in any language that fails at runtime depending on the day. What's notable about this is that its _syntactical correctness_ depends on the day, which is not possible to achieve in many languages.
What's being noted is the degree of flexibility that Perl has with respect to its execution environment.
Though if you include preprocessors, you expand the number of languages for which you can do something similar.
What's being noted is the degree of flexibility that Perl has with respect to its execution environment.
Though if you include preprocessors, you expand the number of languages for which you can do something similar.
The line
Perl is parsing /1;#/ is a regex based on whether f takes arguments. Otherwise it parses the slash as division and then the hash is a comment.
Another example could be:
This leads to a proof that perl is a actually impossible to parse.
https://www.perlmonks.org/?node_id=663393
Which means you can't do a lot of static tooling on perl because you just can't analyses the source accurately. (Compared to say python, which parses source before running it)
f/1;#/+
Perl is parsing /1;#/ is a regex based on whether f takes arguments. Otherwise it parses the slash as division and then the hash is a comment.
Another example could be:
foo() {
some_func / 1;#/; die "It died"
foo
}
This leads to a proof that perl is a actually impossible to parse.
https://www.perlmonks.org/?node_id=663393
Which means you can't do a lot of static tooling on perl because you just can't analyses the source accurately. (Compared to say python, which parses source before running it)
Was going to say the same thing. I thought it would be something wrong with the language. If you're going to write code that's different depending on the day of the week...meh.
they made a branch where one side is defective and the other isn't
they only follow the non-defective side one day a week
because perl doesn't forward analyze, it never sees the error on other days, and doesn't fail
the presentation is false. this code is always wrong. it's just that the bug is only visible under certain conditions.
they only follow the non-defective side one day a week
because perl doesn't forward analyze, it never sees the error on other days, and doesn't fail
the presentation is false. this code is always wrong. it's just that the bug is only visible under certain conditions.
It's a humorous way to demonstrate that you can't parse Perl code statically.
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.
Good Perl code would also look pretty boring, almost like enterprise Java.
I'd wager that all code that "just works", in any language, looks bland and predictable.
But I'd rather have that than cute and clever any day.
I'd wager that all code that "just works", in any language, looks bland and predictable.
But I'd rather have that than cute and clever any day.
Good Perl looks like a mix between structured SH and a dumbed down C with no pointers. Boring, as you say. But it works.
You say that but a lot of people just can't get over the sigils.
And a lot of people just can't get over significant whitespace, and curly braces, and lispy parantheses, and semicolons. No syntax can please everyone, especially so with people unfamiliar with the language they're looking at.
Afaik Perl is not declining in popularity, it's just not growing in popularity as fast as many other languages, so it's market share shrinks while the number of users it has grows.
True, most Gen-Z ers know nil.
First they should try Perl as if it was a tuned up AWK, and then, read the Orelly Perl books as if they were a religion.
https://docstore.mik.ua/orelly/perl4/index.htm
First they should try Perl as if it was a tuned up AWK, and then, read the Orelly Perl books as if they were a religion.
https://docstore.mik.ua/orelly/perl4/index.htm
Perl is like life - it contains both good and bad.
And good things in Perl don't get noticed because they Just Work.
And good things in Perl don't get noticed because they Just Work.
I loathe perl still (based on having to SSH (or telnet?) into people's systems and debug their perl scripts in the 90s) but, Higher Order Perl, https://hop.perl.plover.com/ is a truly excellent introduction to the power of functions that generate functions, more accessible and more immediately useful than Paul Graham's On Lisp. The lessons are immediately applicable at least to Javascript and Python. Strongly typed things like Go make it a bit more work, but still you'll understand why the work is worth doing.
Right, it’s elegant Perl that would be newsworthy, not gruesome Perl.
(Tongue-in-cheek, I’m actually rather partial to Perl.)
(Tongue-in-cheek, I’m actually rather partial to Perl.)
The other day, I wanted to check if a text file's 100,000th word was being indexed, so I generated a text file with 99,999 lines containing "foo" and one line with "bar" with this line in bash
perl -e 'print "foo\n" for 1..99999; print "bar\n";' > foobar.txt
perl -e 'print "foo\n" for 1..99999; print "bar\n";' > foobar.txt
Because prominent figures like the author of the snippet push these gotchas as virtues.
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.
As a sister language of Perl, Raku can do the same trick.
Modules are precompiled, programs are not (yet). So to make this really depend on the day of compilation we have to put it into a module (for now).
constant &s = (now.DateTime.day-of-week == 7) ?? sub () {} !! sub (|) {};
constant c = s(42);
Modules are precompiled, programs are not (yet). So to make this really depend on the day of compilation we have to put it into a module (for now).
Somewhat related:
Perl Cannot Be Parsed: A Formal Proof (2008) https://news.ycombinator.com/item?id=5770531
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.
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.
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.
> there's no such thing as dynamic parsing
As long as we're indulging in pedantry, this is incorrect presuming dynamic means what it usually means. Any regular expression constructed at runtime contradicts you.
Modifying your core parser at runtime though, who would do such a thing? Other than reader macros in Common Lisp I mean. Are we going to argue this means Common Lisp doesn't parse if we add reader macros at runtime? A peculiar argument.
Now. Should we talk about whether doing that is a good idea? A lovely and separate conversation. I agree with GP that since Perl will spit out a parse tree, it does in fact parse, and since it's not static, well, it's dynamic.
Which we can prove by, I dunno, writing some Perl which only parses on Fridays. Right?
As long as we're indulging in pedantry, this is incorrect presuming dynamic means what it usually means. Any regular expression constructed at runtime contradicts you.
Modifying your core parser at runtime though, who would do such a thing? Other than reader macros in Common Lisp I mean. Are we going to argue this means Common Lisp doesn't parse if we add reader macros at runtime? A peculiar argument.
Now. Should we talk about whether doing that is a good idea? A lovely and separate conversation. I agree with GP that since Perl will spit out a parse tree, it does in fact parse, and since it's not static, well, it's dynamic.
Which we can prove by, I dunno, writing some Perl which only parses on Fridays. Right?
> Modifying your core parser at runtime though, who would do such a thing?
Perl? Its numerous language extensions allowed it to stay competitive for such a long time. Every time someone says "language X can do Y but Perl doesn't have that syntax", a new CPAN module is born to amend the shortcoming.
Perl? Its numerous language extensions allowed it to stay competitive for such a long time. Every time someone says "language X can do Y but Perl doesn't have that syntax", a new CPAN module is born to amend the shortcoming.
> Are we going to argue this means Common Lisp doesn't parse if we add reader macros at runtime? A peculiar argument.
Peculiar how? Isn't that just common sense?
Peculiar how? Isn't that just common sense?
“Cannot be X” most often means “in the general case”. (In the context of computability.)
I 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.
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.
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!
Have you seen my "parse JSON in a single Perl Regex"? https://www.perlmonks.org/?node_id=995856
Ditto, except s/several/a couple of/
Just reading the headline gave me traumatic flashback to a customer project for a winter sports brand that broke on April 1st after not being modified for months prior to this.
You guessed it: There was a sleeper bug detonated by the date change. Pain the butt to track down in Perl code that was generating an Excel spreadsheet cell-by-cell.
You guessed it: There was a sleeper bug detonated by the date change. Pain the butt to track down in Perl code that was generating an Excel spreadsheet cell-by-cell.
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:
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
[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
Was it a German company? If so "you can only do work during working hours" would be considered a feature not a bug ;)
The thing is, you need to have a pretty corkscrew mind to think about cases like this.
What date to change to? Far into the future? Far into the past? To a weekend? To a DST change? To Friday the 13th? To a US holiday? To a Muslim, Jewish, Chinese, Soviet, Albanian holiday? To a particular weekday? To Hitler's birthday? What if it's Lenin's? To that one day my coworker was depressed because the boss denied him a raise and talked shit to him? Too many possibilities. And your timebomb might be in one of your dependencies to boot.
What date to change to? Far into the future? Far into the past? To a weekend? To a DST change? To Friday the 13th? To a US holiday? To a Muslim, Jewish, Chinese, Soviet, Albanian holiday? To a particular weekday? To Hitler's birthday? What if it's Lenin's? To that one day my coworker was depressed because the boss denied him a raise and talked shit to him? Too many possibilities. And your timebomb might be in one of your dependencies to boot.
I feel obligated to link "Falsehoods programmers believe about time" -
I think it's best to just get a trusty library instead. https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b...
I had a program once which failed every time it was 8 or 9 minutes past the hour and worked the rest of the time.
It parsed a string containing the time and sscanf treats "08" and "09" as invalid octal numbers. Argh.
It parsed a string containing the time and sscanf treats "08" and "09" as invalid octal numbers. Argh.
Been there, a TCL web script, IIRC. This led to religious processing of input with "regsub" (this predated TCL 8). Yuck.
Also once fixed an inherited awk script that malfunctioned at the end of year: a hardcoded month name array with November missing. To this day I always populate any such lookup with a loop and strftime() or appropriate.
Also once fixed an inherited awk script that malfunctioned at the end of year: a hardcoded month name array with November missing. To this day I always populate any such lookup with a loop and strftime() or appropriate.
[deleted]
It's mentioned in the source but it's based on this:
https://www.perlmonks.org/index.pl?node_id=44722
https://www.perlmonks.org/index.pl?node_id=44722
C code in similar spirit:
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.
$ gcc weird-0.c
$ ./a.out
$ gcc weird-1.c
$ ./a.out
foo(42)
$ cat weird-0.c
#include <stdio.h>
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.
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);
}
heh as soon as I saw the ternary expression I recalled the bug report I submitted some years ago:
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=130...
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=130...
Ubuntu Bug 255161: Openoffice can’t print on Tuesdays (launchpad.net)
https://news.ycombinator.com/item?id=8171956
https://news.ycombinator.com/item?id=8171956
I miss Perl and it’s community from the early-mid 2000s. Sure it was bad for those who have to maintain but trying to create the shorted and most unreadable possible was a fun pastime.
I really feel sorry for these people wasting their lives for decades engaging in mental onanism like these perl gotchas.
Randal has been doing nothing but this for at least 20 years.
Randal has been doing nothing but this for at least 20 years.
Am I literally the only person who sees the pun against “His Girl Friday?” Maybe it wasn’t intentional but that’s literally the first thing I thought of.
It wasn't intentional. Can you explain the pun?
This code is always syntactically incorrect.
It is merely that the problem branch is only occasionally followed.
It is merely that the problem branch is only occasionally followed.
So many things compile / work well on Friday, just before weekend...
Gah why did I take up programming for a living :|
What about Phase-Of-The-Moon code?
<pedantic>
The code is never syntactically correct however the syntax error is not identified by the Perl interpreter on Fridays.
</pedantic>
The code is never syntactically correct however the syntax error is not identified by the Perl interpreter on Fridays.
</pedantic>
Wow. Do I need more reasons to hate perl?
Yes, apparently.
Yes, apparently.
Someone found my telco code.
python:
import datetime
if datetime.datetime.now().weekday() == 3:
1/0Once you fix the indentation, this code is always syntatically correct; it just happens to raise an exception on Thursdays.
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.