Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Never write your own date parsing library

zachleat.com

Post reply on HN
Print view View original

151–160 of 333 posts

Re: Never write your own date parsing library

#151

Post by leakycap »

ok_dad wrote: post #129
leakycap wrote: post #103

Earlier quoted context omitted.

I 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…

People 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.

I 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?

Re: Never write your own date parsing library

#152

Post by stouset »

avanwyk wrote: post #139
quelsolaar wrote: post #100

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,…

I 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.

Nobody 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.

Re: Never write your own date parsing library

#153

Post by [deleted] »

9dev wrote: post #53
jedberg wrote: post #28

Things you should never do: Make your own load balancer software Make firewall software Make a date parsing library Attempt to verify an email with a regular expression.

> Attempt to verify an email with a regular expression. .+@.+ That one always seemed sufficient for me, every issue after that is the users problem

[deleted]

Re: Never write your own date parsing library

#154

Post by immibis »

gmueckl wrote: post #125
mattmanser wrote: post #118

Earlier quoted context omitted.

It'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.

In 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.

Yeah, 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?

Re: Never write your own date parsing library

#155

Post by immibis »

stouset wrote: post #152
avanwyk wrote: post #139

Earlier quoted context omitted.

I 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.

Nobody 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 somet…

An 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.

Re: Never write your own date parsing library

#157

Post by djfivyvusn »

quelsolaar wrote: post #100

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,…

Yea, date time parsing is probably fine so is rolling your own auth, unicode, font rendering, compilers.

Datetime libs themselves? No thanks.

Re: Never write your own date parsing library

#158

Post by jkingsman »

jgauth wrote: post #123
jerf wrote: post #58

Earlier quoted context omitted.

Consider it a translation convention. There's a time and a place for "cycles" or "rels" or whatever, but it gets into "Calling a Rabbit a 'Smeerp'" [1] territory pretty quickly. The payoff isn't really all that great. Stargate SG-1 is one of my favorite instances of this. The first couple of episodes address the fact that the Earth characters do not speak the same languages as everyone else in the galaxy. Then, havin…

"The Hunt for Red October" had an interesting way of handling this with the Russian speakers. The movie starts with them speaking Russian with English subtitles, does a slow zoom into the Russian-speaker's lips, and switches to English mid-sentence.

With some elegance, too; iirc they pivot languages on the word "Golgotha" as he reads from the bible, the Latin word for a location near Jerusalem, but having a non-English/non-Russian word be when they switch made it a lot less jarring. Plus, having it be during a read-out-loud-from-book portion allowed for more measured cadence that smoothed the switch but probably would have felt jarring if the audience were parsing multi-character dialogue when it happened.
Post reply on HN