141–150 of 233 posts
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.
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.
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.)
Earlier quoted context omitted.
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 #if (some C preprocessor expression that's true on Fridays printf("Hello world!); #else printf; #fi (although it's been long enough since I've written C that I don't know if (a) there exists a C-preprocessor instruction as per the above, (2) if the…
Earlier quoted context omitted.
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!
Earlier quoted context omitted.
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.
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.
python: import datetime if datetime.datetime.now().weekday() == 3: 1/0
This leverages Perl's BEGIN block which runs before the main part of the code. I suppose the same fun could be had in other languages: if day_of_week is "Friday" eval(piece_of_incorrect_code) else do_sane_operation