4 ms·
I'll add "reduce code size and complexity" to the list of benefits. A python library to calculate a simhash, or track changes on a django model, or auto generat
by JackC 2y ago
I'll add "reduce code size and complexity" to the list of benefits. A python library to calculate a simhash, or track changes on a django model, or auto generate test fixtures, will often be 90% configuration cruft for other usecases, and 10% the code your app actually cares about. Reading the library and extracting and finetuning the core logic makes you responsible for the bugs in the 10%, but no longer affected by bugs in the 90%.
- dkarl 2y agoHard agree. A library should not inflict complex use cases' complexity on simple use cases, but sometimes they do, either because they're poorly designed or because they're overkill for your use case. But often I see pain and complexity excused with "this is the library that everybody else uses." Sometimes a simple bespoke solution minimizes costs compared to the complexity of using a massive hairball with a ton of power that you don't need. One big caveat to this: there's a tendency to underestimate the cost and complexity of a solution that you, personally, developed. If new developers coming onto the project disagree, they're probably right.
- jofer 2y agoThe big caveat is a big one. Choose your battles wisely! There are plenty of things that look simpler than an established library at first glance (I/O of specialized formats comes to mind quickly). However, a lot of the complexity of that established library can wind up being edge cases that you actually _do_ care about, you just don't realize it yet. It's easy to wind up blind to maintenance burden of "just a quick add to the in-house version" repeated over and over again until you wind up with something that has all of the complexities of the widely used library you were trying to avoid. With that said, I still agree that it's good to write things from scratch and avoid complex dependencies where possible! I just think choosing the right cases to do so can be a bit of an art. It's a good one to hone.
- JackFr 2y ago> I/O of specialized formats comes to mind quickly The classic "I'll write my own csv parser - how hard can it be?"
- LPisGood 2y agoWhat are some footguns? It does seem easy
- rho4 2y agomultiline values, comma vs semicolon, value delimiter escaping
- mikepurvis 2y agoIt's easy if the fields are all numbers and you have a good handle on whether any of them will be negative, in scientific notation, etc. Once strings are in play, it quickly gets very hairy though, with quoting and escaping that's all over the place. Badly formed, damaged, or truncated files are another caution area— are you allowed to bail, or required to? Is it up to your parser to flag when something looks hinky so a human can check it out? Or to make a judgment call about how hinky is hinky enough that the whole process needs to abort?
- mjw1007 2y agoBeyond the basic implementation of quoting and escaping, those are things you also have to worry about if you use someone else's csv parser. And if you implement your own, you get to choose the answers you want.
- naitgacem 2y agoEven with numbers, some locales use a comma `,` as the decimal seperator, and some use the dot `.` so that can cause headaches out of the box.
- lelanthran 2y agoWhat do you mean "allowed to bail"? Regardless of the format if you're parsing something and encounter an error there are very few circumstances where the correct action is to return mangled dat.
- geysersam 2y agoAt my current workplace the word "bespoke" is used to mean anything that is "business logic" and everyone are very much discouraged from working on such things. On the other hand we've got a fantastic set of home made tooling and libraries, all impressive software engineering, almost as good as the of the shelf alternatives.