6 ms·
When ever i see "never implement your own...", i know i want to implement it myself. People say that about hard things, and I only want to do hard things. Nobod
by quelsolaar 1y ago
When ever i see "never implement your own...", i know i want to implement it myself. People say that about hard things, and I only want to do hard things. Nobody wants people who can do easy things, people want people who can do hard things. The only way to learn how to do hard things, is to do hard things, so do the hardest things.
So go ahead, write your own date library, your own Unicode font rendering, compiler, OS, game engine or what ever else people tell you to never do because its hard.
- fsckboy 1y agoyou want to do something people really think is hard? use C. it's not safe. all the people who say C is not safe have downvoted me for quoting them
- quelsolaar 1y agoI exclusively write in C89. I'm a member of the ISO C standard board.
- boothby 1y agoThe confluence of tinker-for-tinkerings'-sake "hackers" and get-rich-quick "hackers" on this site certainly leads to a lot of fun miscommunication.
- glibby 1y agoBy 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.
- 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).
- leakycap 1y agoI get wanting to do hard things, but do you write in binary? Do you crank your own electricity? My most valuable resource is time. Sure, I could learn more low-level aspects of my craft ... and sometimes I find it useful to do so. When I focus on doing the hardest, already solved things by re-implementing them my own way, what value am I adding? I've never met a client who cared about a library or how I did something in code - until it broke. Then, they didn't care who wrote it, they just cared it started working again.
- ok_dad 1y agoPeople have built tables but I still build tables myself. Not as many people will use them as people who use IKEA tables, but that’s okay, I’m still going to build them.
- leakycap 1y agoI don't think tables are the hard thing. If you wanted to grow your wood, plane and dry it yourself, etc... then you'd be "hard way" building a table. I assume you use tools?
- ok_dad 1y agoI mean, a table is as hard as you make it. I work with rough construction lumber, and make nice finished goods, my point was that people still do stuff that isn’t worth their time financially.
- leakycap 1y ago> I mean, a table is as hard as you make it. We aren't talking about the same thing: I stated "I don't think tables are the hard thing." Note the word "the" in front of "hard thing" -- I'm referencing the article we're discussing, which mentions "the hard thing"
- fc417fc802 1y ago
- bobsmooth 1y agoSolve new hard things instead of solved hard things.
- dafelst 1y agoOr you know, just do what you want
- GoblinSlayer 1y agoMost solutions are garbage though, because they evolved accidentally.
- qwertox 1y agoThis past 22nd of July was the shortest recorded day [0]. How would your library handle this? [0] https://www.space.com/astronomy/earth/earth-will-spin-faster-on-july-22-to-create-2nd-shortest-day-in-history https://www.space.com/astronomy/earth/earth-will-spin-faster...
- VohuMana 1y agoI think in the case of the article the date library isn't necessarily hard but tedious. They mention most date libraries suffer from supporting too many standards or allow ambiguity. I agree with you though, do the hard things even if it doesn't work 100% right you will have learned a lot. In university I had to implement all of the standard template library data structures and their features, it wasn't as robust as the actual STL but the knowledge of how those work under the covers still comes up in my day to day job.
- david-gpu 1y agoSoftware companies make money by providing value to their customers via the software they provide. How does reimplementing a hard but already well-solved problem align with their goals? How does that compare with solving a hard problem for which there are no good solutions yet?
- avanwyk 1y agoI can't believe this is such a controversial take. Solving hard things by yourself is growth. I 100% agree, rather solve a hard solved problem yourself than learning yet another JS framework or launching yet another revenue losing SaaS ("successful" because of VC). Or whatever. Push hard boundaries.
- brianpan 1y agoIt's controversial because 1) good on someone for wanting to do something difficult and 2) I cannot think of a worse thing to try to implement. Maybe trying to parse the world's postal and street addresses is a close second? Just, why.
- stouset 1y agoNobody is really saying not to build these things. They’re saying the problem is exceedingly annoying to solve—and often not in a technically interesting way but in a way that is just massively tedious—and a better alternative almost certainly already exists. If you want to build it to scratch an itch, go ahead. If you want to build it for fun, go ahead. If you want to build it because an existing solution gets something wrong and you can do better, go ahead (but know that it is a way bigger undertaking than you might assume at first glance). The real advice is “don’t casually build your own X”, but that’s less punchy.
- immibis 1y agoAn exemplary one is "don't build your own timezone database" It's not interesting, it's not fun, it's just a process of getting complaints it's wrong in edge cases and then fixing them, over and over until no one can find another broken edge case. You can start by writing down England is +0, Germany is +2, etc... someone's going to mention DST and you'll put in a field for switching on the Nth Sunday of month X... later you'll run into a country that uses a different rule and you'll add a bunch of spaghetti code or write a Turing-complete DSL, etc... One day someone tells you about a village where they count 17 hour days on seashells and then you'll give up. And if your DB doesn't produce identical results to the Olson DB in all cases then you created an incompatibility anyway. Might as well just use the Olson DB.
- dracodoc 1y agoIt's not because it's "hard". It's all about the nuisance created by human behavior. Calendar, DST, timezone, all the problems you never imagined can happen and can only be met in real life scenarios, and you will meet same problem again, struggle then found out the same problem have been solved long time ago by mature library, and the solution doesn't require any smart or advanced technique, just another corner case.
- geocar 1y agoI disagree hard. Firstly because I have a great imagination, but secondly because I am old and have a lot of real life scenarios to think about. State-of-the-art here has changed a few times in my professional career: Once upon a time most time/date libraries used a single integral type and try to make it do double-duty by being both interval and absolute (whatever that means) time by taking the interval from an epoch. Relatively recently however, that's started to change, and that change has been made possible by people using languages with better type systems reinventing the date/time approach. This has led to fewer bugs, and more predictability with regards to calendar operations in different programs. But bugs still happen, so this approach is still unsatisfying. One thing I keep having to worry about is distance; I record RTT as part of my events, since when I am looking for contemporaneous events, the speed-of-light actually tends to be a real factor for me. So I don't think this is solved simply because my problems aren't solved by existing libraries, and I keep getting into arguments with people who think GMT=TAI or something dumb like that. It's not "all about" anything: Nobody knows shit about what's happening in the next room over, and if there are 12 different date/time libraries now, I guarantee there'll be a 13th that solves problems in all of them, and is still incomplete.
- rkagerer 1y agoDon't forget to roll your own crypto libraries.
- djfivyvusn 1y agoYea, date time parsing is probably fine so is rolling your own auth, unicode, font rendering, compilers. Datetime libs themselves? No thanks.
- richardw 1y agoNever write your own multi-planetary date/time library in brainfuck.
- whoamii 1y ago… but if you plan to sell it, don’t build your own billing system!
- geocar 1y agoYes. Do it. The only way you understand X is by making your own X and trying to support it for a few decades, and our industry needs more people who understand X; fewer who just ask chatgpt/stackoverflow/google for "the answer".
- ozim 1y agoMissing context is - there is always something else you work on like the guy was making Eleventy so it was waste of his time. If you work for a company and build todo app most likely it will not be beneficial for you to implement in-house library because there will be stuff that will bring much more value. Like you don't have now 2 years to cover for all hard stuff because you have to make synchronization of tasks between devices and your boss most likely won't appreciate that. "Never roll your own cryptography" is always used in context of building another application it is never "don't become a cryptography specialist".
- chii 1y ago> The only way to learn how to do hard things, is to do hard things, so do the hardest things. and i don't want to pay my employees to learn, i want to pay them to produce output i can sell. Doing hard things are good, if this hard thing has never been done before - like going to the moon. Doing hard things which has been done, but just not by you, is not good unless it's for "entertainment" and personal development purposes - which is fine and i encourage people to do it, on their own dime. Like climbing Mount Everest, or going to the south pole. But if you are doing a project for someone else, you don't get to piggy back your personal wants and desires unrelated to the project on to it.
- schindlabua 1y agoExcept making employers do only easy things will make them stagnate. People who do nothing but simple CRUD apps over and over won't even be particularly good at making CRUD apps... whereas the guy who builds an Unicode font renderer in his free time always seems to write better code for some reason. Getting better at your job is not just a "personal want" but very much something that the employer appreciates aswell. Of course reinventing the wheel isn't good in corporate because the reinvented wheel is buggier than the ready made npm package but employers should go out of their way to find hard problems to solve that they can pass to their employees. It's called a growth opportunity.
- pjmlp 1y agoUnless you work for enterprise consulting where employers appreciate replaceable cogs that they randomly drop into any project, and nicely out project budget regardless of delivery quality.
- keybored 1y agoYou can’t convince an employer with that attitude. They’re gonna keep exploiting their employees and “encourage” them to do their “personal development” in their free time.
- ahf8Aithaex7Nai 1y ago> and i don't want to pay my employees to learn, i want to pay them to produce output i can sell. This can be a bad local optimum. It probably depends on what exactly your business does, but it can make sense to pay an employee to acquire knowledge and skills that are needed in the business. You can't buy this off the shelf in all circumstances. Of course, it also has to make economic sense and be viable for the company. Unfortunately, I often see employees doing things quite badly that they don't really understand because they are not given the opportunity to learn properly. I can't imagine that this burns less money in the medium and long term than giving paid employees adequate space to learn.
- psychoslave 1y agoThere are different kind of hardship though. There things which was a result will make your mind click to an other way to comprehend a problem space and how to navigate through it. And there are things which are hard due to pure accumulation of concurrent conventions, because of reasons like coordinating the whole humanity toward harmony with full happy peaceful agreement of everyone is tricky. Handling date is rather the latter. If you dig in the lucky direction, you might also fall into cosmological consideration which is a rabbit hole of its own, but basically that's it: calendars are a mess.
- motorest 1y ago> People say that about hard things, and I only want to do hard things. That's perfectly fine. Your time, your hobbies. > Nobody wants people who can do easy things, people want people who can do hard things. No, not really. People want people who do easy things, because they are clever enough to avoid needlessly wasting their time having to do hard things when they could have easily avoided it. It's your blend of foolish mindset that brought us so many accidental complexity and overdue projects. There's a saying: working smart instead of working hard. > So go ahead, write your own date library, your own Unicode font rendering, compiler, OS, game engine or what ever else people tell you to never do because its hard. You can cut it out, this isn't LinkedIn.
- d_tr 1y agoIn a scenario where a programmer has to do this for work and might naively think that date handling is simple, the title is invaluable advice. It is one of those things that can cause real trouble. OTOH writing, e.g., your own renderer could cause some funny display at worst and maybe some unnecessary effort.
- cookiengineer 1y agoI feel obligated to comment on this. Due to my work I rely on web scraped data for cybersecurity incidents. For Amazon Linux, they are disclosed with the fvcked up US datetime format (Pacific Time) and not in ISO8601 formatted strings which could imply Juliet/Local time. In 2007 there was a new law that changed when Pacific Time enters/leaves Daylight Saving Time. Instead of making this fixed by a specific Day of a specific Month in numbered form like say "YYYY-03-01 to YYYY-10-01", they literally wrote the law quoting "first Sunday of April" to "last Sunday in October". Before 2007 it was "Second Sunday in March" to "first Sunday in November". I'm not making this shit up, go ahead and read the law, come back and realize it's even more complex for other timezones, because some nations seem to make fun of this by going to +14:00 hours and -11:30 hours depending on the president's mood on Christmas or something. In order to find out the Day of a specific calendar date, there's this cool article about Determination of the day of the week [1] which is quite insane on its own already. There is no failsafe algorithm to do that, each method of determining the day of the week has its own tradeoffs (and computational complexity that is implied). Then you need to get all Sundays of a month, count the right one depending on the year, map back the date to ISO8601 and then you know whether or not this was daylight saving time they're talking about. Also make sure you use the correct local time to shift the time, because that changed too in the law (from 02:00LST to 03:00LDT and 02:00 LDT to 01:00LST before, to 02:00LST to 03:00LDT and 02:00LDT to 01:00LST after the changes). Took me over 4 fvcking weeks to implement this in Go (due to lack of parsers), and I hate Amazon for this to this date. PS: Write your own Datetime parser, this will help you realize how psychotic the human species is when it comes to "standards". After all this I'm in huge favor of the Moon Phase based International Fixed Calendar [2] [1] https://en.wikipedia.org/wiki/Determination_of_the_day_of_the_week https://en.wikipedia.org/wiki/Determination_of_the_day_of_th... [2] https://en.wikipedia.org/wiki/International_Fixed_Calendar https://en.wikipedia.org/wiki/International_Fixed_Calendar
- GoblinSlayer 1y agoReporting of cybersecurity incidents are easily late by a month or more, time zones are well below the rounding error. You will be more accurate to display it as YYYY±6month.
- kyawzazaw 1y agoCorporations and government certainly want people who can execute things that are easy, but reliably and consistently
- gjm11 1y agoI find this a perplexing comment in view of the fact that almost all of the linked article is in fact about how the author wrote his own date parsing library; the "never do it" bit is just a couple of lines at the start and so far as I can tell is mostly there for fun. (In particular, at no point does the article actually argue for not writing your own date parsing library. It just says, in essence, "Never do it. I did it. Here's what I did and why.")
- kurikuri 1y ago> When ever i see "never implement your own...", i know i want to implement it myself. Doing stuff for learning is useful, and the intent behind this general phrase is to not ‘implement your own’ something which is both hard and critical in a production environment. I work in cryptography (for security purposes) and have implemented quite a few things myself to learn, but I still use stable, field tested, and scrutinized crypto for any actual use. > People say that about hard things, and I only want to do hard things. Nobody wants people who can do easy things, people want people who can do hard things. Only wanting to do hard things limits yourself quite a bit: what about things which seem easy but could be improved? I worked in a non-tech related medical manufacturing job for a bit and took time to learn the process and tools. Afterward, I implemented a few tools (using what my coworkers (who have no programming or IT experience) have available to them: Excel and the VBA on the lab computers) to help them prep inventory lists which they have been doing by hand. Doing it by hand took them 3 hours as a group (and the first shift had to do this every morning), which my tool did in 5 seconds with a single button click. They still use it to this day, about a decade later. This wasn’t something ‘hard:’ I glued a few files together, grouped a list by a filter, sorted the groups by a column, and made a printout which was easy to read and mark on as they went about their day. However, my coworkers didn’t even know this was possible until someone came in with a different skill set, learned what they did (by doing the job well for months) and then made a solution. You must be careful with doing only ‘hard’ things. It requires other people to identify what is hard! In addition: crackpots do only hard things and believe they find better solutions than what exists so far (without consulting or learning about what has been done). Interesting people learn about things as they are (with the humility of knowing that they are not experts in most things) and tries to improve them using the knowledge they already have. Don’t waste your time rolling your own crypto when you could do the _actual_ hard thing and identify unaddressed space to make careful and considered improvements.
- mikepurvis 1y agoSome things are good hard, the kind of hard that's driven by an interesting domain, going deep with well-architected tools or systems, learning lots of cool stuff. I expect datetime-adjacent code is basically the opposite of all of this. All the hard parts are driven by fiddly adherence to real-world geography, politics, physics/astronomy, etc. There's no underlying consistency from which a sane model can be extracted, it's just special cases and arbitrary parameters all the way down. I'm up for a challenge of course, but all else being equal, I'm happy to leave work that is the "bad hard" to others.
- bapak 1y agoCorrect. It's not hard, just stupidly time consuming to the point of being unable to ever produce anything that works 70% of the time. I hate anyone who will attempt to craft their own 10-lines line parser and then ignore that it fails 4 times a day. Just use the damn library. Thank you. Write it for fun, but don't ship it. You're wasting everyone's time with your craft.
- yes_man 1y agoReminds me of this passage from Postgres documentation: ”As an example, 2014-06-04 12:00 America/New_York represents noon local time in New York, which for this particular date was Eastern Daylight Time (UTC-4). So 2014-06-04 12:00 EDT specifies that same time instant. But 2014-06-04 12:00 EST specifies noon Eastern Standard Time (UTC-5), regardless of whether daylight savings was nominally in effect on that date. … To complicate matters, some jurisdictions have used the same timezone abbreviation to mean different UTC offsets at different times; for example, in Moscow MSK has meant UTC+3 in some years and UTC+4 in others.” Parsing datetimes indeed sounds like a challenge in collecting, knowing and maintaining all these warped out standards and compromises. ”Bad hard” is a great description
- popoflojo 1y agoLeap seconds are when it really gets fun.
- 1y ago
- nicoburns 1y ago> So go ahead, write your own date library, your own Unicode font rendering, compiler, OS, game engine or what ever else people tell you to never do because its hard. You can absolutely do these things. What you need to be aware of is that in most cases maintaining these things to a production quality level is full-time job for a talented engineer. So you shouldn't attempt these IF: - You have a higher-level aim you are also trying to achieve - You need a production quality implementation If one of those isn't the case then knock yourself out.
- DonHopkins 1y agoIt's so tempting to tell you "never implement your own html parser using regular expressions" just to make you do it. I triple dog dare you! https://www.youtube.com/watch?v=mc6pk2FRhbA https://www.youtube.com/watch?v=mc6pk2FRhbA
- drewcoo 1y agoThere's hard and then there's "there are so many unexpected edge cases you'll surely be cut if you touch that code," which not fun-hard. This is the latter.
- junon 1y agoWriting an OS. I've learned more about computers, hardware, CPU design, compilers, etc. that have translated into literally every other facet of my IT world than I could have done without this project. Definitely agree.
- ainiriand 1y agoYeah but never ever roll your own encryption, or do it but never trust it.
- rgavuliak 1y ago> Nobody wants people who can do easy things, people want people who can do hard things. No, people want people that can provide value regardless of the difficulty. What you're describing is how we end up with not invented here syndrome.