I didn’t have to program this, thankfully. The code was used as an example of recursion but the explanation was lacking so I ended up writing out each frame by end until I understood it. Took a few pages and a couple of hours.
I am grateful that I learned what I did going through it but I’d rather not do it again.
My favourite take on DI is this set of articles from like 12 years ago, written by a guy who has written the first DI framework for Unity, on which are the currently popular ones, such as Zenject, based on.
The first two articles are pretty basic, explaining his reasoning and why it’s such a cool concept and way forward.
Followed by more articles about why he thinks it was a mistake, and he no longer recommends or uses DI in Unity in favor of manual dependency injection. And I kind of agree - his main reasoning is that it’s really easy for unnecessary dependencies to sneak up into your code-base, since it’s really easy to just write another [Inject] without a second thought and be done with it.
However, with manual dependency injection through constructor parameters, you will take a step back when you’re adding 11th parameter to the constructor, and will take a moment to think whether there’s really no other better way. Of course, this should not be an relevant issue with experienced programmers, but it’s not as inherently obvious you’re doing something potentially wrong, when you just add another [Inject], when compared to adding another constructor parameter.
Exactly. Dependency injection is good; if you need a framework to do it, you’re probably doing it wrong; if your framework is too magical, you’re probably not even doing it at all anymore.
If you like this then I’d recommend reading more papers published at sigbovik. Favorites include “do programming socks make you better at programing?”, “making hard drives by increasingly stupid and unworkable means” and “a formal mathematical proof that I am transgender”
A good Adblock is a digital equivalent of an armored car. You can go everywhere, comfortably. Visit the most terrible sites or places. All this time protected from the bullets of capitalism.
This is why we do nightly automatic backups on all sites. Whatever happens we can just restore to the previous night and you never lose more than a day of work. Backup plans and redundancy is a waste of money to management, accounting, and customers until they need it.
and with systems like Borgbackup, storing months worth of daily backups doesn’t take up an excessive amount of disk space, especially if the files rarely change.
I used to feel this way. Over the course of building out 2 calendar systems in my career (so far) and having to learn the intricacies of date and time-related data types and how they interact with time zones, I don’t have much disdain for time zones. I’d suggest for anyone who feels the same way as this meme read So You Want To Abolish Time Zones.
Also, programmers tend to get frustrated with time zones when they run into bugs around time zone conversion. This is almost always due to the code being written in a way that disregards the existence of times zones until it’s needed and then tacks on the time zone handling as an afterthought.
If any code that deals with time takes the full complexities of time zones into account from the get-go (which isn’t that hard to do), then it’s pretty straightforward to manage.
Time zones are part of it, but also daylight savings is a real pain in the ass. And like you said it gets particularly complicated when you’re dealing with a system that deals with these things as an afterthought, which seems to be a lot of older libraries for time. For instance, the Java date utils are a nightmare and are now considered semi deprecated replaced by a new java.time api. That is, of course, no help for the ridiculous amount of things that depend on these stupid date utils and no one wants to spend the dev hours to refactor.
This did little to convince me that timezones are an unnecessary construct. Pretty much every point made was done from the perspective of someone who had already decided their opinion rather than objectively weighing the pros and cons.
Yeah, the article is written like it’s parodying those who want to abolish timezones, but I’d be interested in specifically what you found unconvincing? I read the main point as being that time zones are an arbitrary social convention but that that arbitrary social conventions are pretty useful for humans.
Like one thing that the article does is repeatedly asking the question “but what time is it in Melbourne?” which I guess sounds pretty silly if you think timezones are unnecessary, since the question would be meaningless if timezones were abolished, and people in different parts of the world would already have centered their day around their respective parts of the clock and you would just look up what the times for everything are in another place. But I think the author was kind of already discarding that idea, because it’s just equivalent to timezones - you have a lookup table for each part of the world to find out what people do at a certain time, except instead of being a single offset you have like a list of times like “school openings”, “typical work hours”, “typical waking hours” (?) etc. This system is basically timezones but harder to use for humans. So the author asking “but what time is it in Melbourne?” is in the context of this table not actually existing, because if it did, then you haven’t actually abolished time zones.
Yeah but also if we’re being honest, from a programmer perspective the timezone has no bearing on what you do, and is hence not a problem at all.
After all, much like you translate the language of your UI when displaying in X, you also add Y hours to all times shown in X. Done. You wouldn’t even need to persist the zoned time data anywhere, given their static nature you could decide the final timestamp shown at display time, purely on a client, visual, level.
OTOH, daylight saving time turns itself - and timezones - into an utter mess and whoever invented them hopefully is proud of the raw amount of grief and harm they caused the world. It causes all kinds of issues with persistence, conversion and temporal shifts in displayed time due to the ephemeral nature of the +X minutes added. Or not. That’s the worst part.
So timezones: Fine, it’s just bling bling on display anyways.
DST: Burn it at the stake.
Yeah, I’m in agreement that DST is kinda pointless and could probably be abolished, but the thread is about abolishing timezones in general (or so I thought).
Abolishing DST doesn’t eliminate all the weird issues with “ephemeral” offsets though. Suppose the user wants to set a reminder for a recurring event at 3pm, and then moves to another country. Do you keep reminding them at 3pm in the new time zone or the old time zone? Maybe the reminder was “walk the dog” and the user meant for it to be at 3pm local time, or maybe it was “attend international meeting” and the user meant it to be at 3pm in the original timezone. (This admittedly only happens to calendar apps so isn’t something that most applications have to deal with, unlike displaying timestamps in general.)
But other than that, I’m of the opinion that as programmers we’re supposed to model the problem space as best we can and write software that fits the problem, rather than change the problem to fit our existing solution. After all, software is written to be used by humans, not the other way round (at least not yet). So if DST is something those wacky humans want and use, then a correct program is one which handles them correctly, and a programmers job is to deal with the complexity.
I disagree about the table - if you’re interacting regularly across timezones you tend to convert everything to your local time anyway - India’s on lunch at 9am, US is starting at 14:00, because that’s how it fits into your day.
I mean you’re not wrong but I’d argue you can get more interesting cve’s using a higher more performant language such as c++. Where there are are ways to include CVE 's from C and introduce new ones to each level of your program using inheritance.
Here is the thing. Everybody, including attackers, is too overwhelmed with the boring variety of CVEs and unable to even think about the more interesting kind.
As soon as we make people stop generating those boring ones by the millions, our days will be way more interesting while we find and fix more complex CVEs. But anyway, those will also be way more common on C and C++ code than most other languages (maybe with an exception for JS).
EDIT: Oh, nevermind. I’ve forgotten that it’s using CVSS, which has a tendency to really overestimate the risk, so almost everyting is CCVE according to them :D
programmer_humor
Top
This magazine is from a federated server and may be incomplete. Browse more on the original instance.