5 ms·
By all means, write it. Just don't use it. These warnings are almost always in the context of code you're going to release, not exercises in learning on your ow
by glibby 1y ago
By all means, write it. Just don't use it. These warnings are almost always in the context of code you're going to release, not exercises in learning on your own.
- ramijames 1y agoThis is such nonsense. All the stuff that we use, someone wrote. If nobody makes them, then how is that going to work? The messaging here is that you should be careful about using what you build on your own because it: - hasn't been battle tested - likely has bugs - isn't mature The only way that it will be all of those things is if someone invests time and energy in them. From an ecosystem perspective this is absolutely the right thing. You want duplicate projects. You want choice. You want critical knowledge to be spread around.
- Swizec 1y ago> If nobody makes them, then how is that going to work? I see it as “Dont write your own X, unless you want to maintain X. Here be dragons, this problem is deeper than it appears, the first 80% will be easy, the next 15% will annoy you, and the last 5% will consume your life for weeks, months, or even years. Or you could use a library”
- ahartmetz 1y agoThe latter, if you want to get it completely right. I occasionally read the commits in the Qt framework, and from that, I can tell you that date-time stuff is complicated, and not in an instructive way, but in a super tedious way.
- DANmode 1y agoHoly shit. The point is, before you release your new thing, make sure it addresses all of the pain points the previous solutions have already slogged through, or that if it doesn't, people are still aware of when they can arise, and why your thing has chosen not to mitigate them yet, or ever, if it's an opinionated piece of tech.
- commandlinefan 1y agoNah, finding that stuff is what users are for.
- mattmanser 1y agoIt's about exposure. The things that people write that everyone uses have had HUGE exposure. They've been exposed to all the edge cases, they've been tested millions, if not billions of times. All the bugs ironed out. The people who've worked on them are now the greatest domain experts on that little corner of comp-sci. Yours won't unless it hits prime time. So yours will be weak, brittle and dangerous.
- gmueckl 1y agoIn order to have these mature libraries, someone hat to start building them. They all had to to be incomplete, immature and horribly buggy early in their lifetime, too.
- immibis 1y agoYeah, so do you want to go through that process of shipping broken crap and fixing user complaints one at a time until it happens to work for everyone, which is a mandatory process for all new libraries in one of these areas to go through, or would you rather stand on the shoulders of someone who's already done it?
- kulahan 1y agoWhy would I mature yours and deal with those issues when I can just use the already-mature one?
- gmueckl 1y agoYou assume that you always have a mature option available. That's (a) definitely not a totally generalizable assumption and (b) my point is that mature options only exist because the people that developed them just did it when confronted with the task.
- kulahan 1y agoWe are specifically talking about something that does have a mature option available. That’s why it’s stupid to try and implement your own version of something complex. If you change the story such that the product is actually needed and universally immature, of course building it is a valid argument. Regarding b: Right, and the point of this article is that for those types of things, go for the already-mature thing. You’re arguing a point nobody is making.
- ozim 1y agoI think there is missing point in this discussion. Most of the time you build something else. Like if you build a todo app and have to deal with scheduling you don’t spend time making date library because it’s not your goal. But people would do that. Heck most developers instead of starting blog on a blog platform start writing code for their own blogging engine.
- mikestaas 1y agosee https://rakhim.org/honestly-undefined/19/ https://rakhim.org/honestly-undefined/19/
- flir 1y agoIn the case of date libraries, I think if I ported the tests from a few well-known libraries to my own, I'd have reasonable confidence in my own. Having said that, I don't think date libraries are hard, I think they're messy. Mostly because humans keep introducing convenience fudges - adding a second here, taking eleven days off there, that kind of thing.
- benlivengood 1y agoI would not be surprised if the state of unit tests on good date parsing libraries are not sufficient to design a new one from scratch. See the number of unit tests in the Linux kernel, for example.
- flir 1y agoYou might be right, I haven't checked. It just seems on the face of it such an easy thing to test. Scalars go in, scalars come out. (This could just be me doing the Dunning-Kruger thing). You could run a fuzzer against two libraries at the same time to find discrepancies....... hmm. That might actually be a good exercise.
- deleted 1y ago[deleted]
- shakna 1y agoMost well-known date library systems have failed in places. Quite a few, still do. So whilst you might get some known regression to test against, nothing can give you a foolproof guide. You can have reasonable confidence that here there be dragons, but not so much that your assumptions about something will hold.
- tbrownaw 1y ago> Having said that, I don't think date libraries are hard, I think they're messy. Messy is just a particular kind of tedious which is the most common form of hard. It's not like typical things that need doing tend to include solving lots of unsolved problems.
- deleted 1y ago[deleted]
- bdangubic 1y agoI write my own, but in production I always use libraries written by some dude from Omaha :)
- dylan604 1y agoAnd that dude is no longer actively maintaining it and you just discovered an issue with it.
- bigstrat2003 1y agoI think that advice makes sense in the context of cryptography, where the consequences for getting it wrong can be quite serious indeed. I don't think it holds true for something as unimportant as a date parsing library.
- poink 1y agoCorrect date handling (including parsing) can be monumentally important. Imagine an app that reminds people when to take their medications, for example
- what 1y agoYou typically take medication at a set time every day. You don’t need to parse dates for that.
- poink 1y ago1) Dates are often stored as strings, so parsing them correctly is a necessary component of storing them. Also, those dates need not be simple app state. They could come from an API provided by your doctor/pharmacy 2) Many people (especially the elderly) take enough medications on different schedules that managing them all would be a significant cognitive load for anyone It’s just an illustrative example, though. My point is getting dates right (including parsing their string representations) often matters quite a bit. If you disagree, let’s argue about that rather than quibble about the minutiae of the example
- deleted 1y ago[deleted]
- computerthings 1y ago[dead]
- leptons 1y agoA lot of cryptography relies on dates, time, etc.
- kuon 1y agoHard disagree here. Use it. Of course, if you running code that drive a pacemaker or a train maybe be careful, but in general, do things. We don't want a world where only three old bearded guys can write a compiler or a physic engine. Do the same errors again and you'll learn, eventually you'll do better than those who were here before you.
- Hnrobert42 1y ago>Maybe be careful Really?
- patrick0d 1y agoWell don't do it and instead of using an off the shelf library that is known to work while the rest of the development team isn't reinventing the wheel. Doing it for fun and education is fine of course.
- sabas123 1y ago> We don't want a world where only three old bearded guys can write a compiler or a physic engine. Don't write your own OS does not mean do not contribute to something like the linux kernel.
- Zambyte 1y agoIt's interesting that people are disagreeing with you in a way that they're making it sound like they're elaborating on your point. To the people reading this, please don't just disagree with an "obvious counterexample". Explain why!
- breatheoften 1y agoWhat IS the right way to model dates in a pacemaker ...? I hope the answer is "just don't do it" -- but I don't know what reasons there might be for a pacemaker to need to depend on calendar dates in order to best do its job ...
- fc417fc802 1y agoWell naturally it will need to connect to your phone via Bluetooth for the app to proxy update downloads and historic location data uploads. But in order to do anything on the network securely you need an accurate clock and the ability to parse datetimes because the PKI implementation depends on that. Then the app pings you to remind you that your premium subscription will be expiring soon after which your heart rate will be limited to 100 bpm or less.
- cmdlyne2 1y ago> By all means, write it. Just don't use it. I'd say write it, probably don't use it, and don't share it unless it's substantially better than the alternative. This way, you'll learn about it, but you'll more likely stay with something standard that everyone else is using, and you don't share yet another library that wastes others' time and your own (having to read about it, evaluate it, use it, and the migrate off of it when it's abandoned).