| ▲ | ramijames 4 days ago |
| This 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 4 days ago | parent | next [-] |
| > 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 3 days ago | parent [-] | | The 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. |
|
|
| ▲ | mattmanser 4 days ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | zelphirkalt 4 days ago | parent | next [-] | | This assumes, that the practices/methods used to create a working library are suitable for solving the problems. They might be ill-advised and include tons of workarounds for bad design decisions. Too often following the advice of never reinventing anything (and possibly doing better), is how we ended up with stacking broken stuff on top of other broken stuff, limiting us at every turn with leaking abstractions and bad designs. It is very possible to have a clean implementation with good design choices overtake an established in time, enabling more extensibility, modularity and maintainability. An example: People still way over-use regexes for all kinds of stuff. Even in code editors people for syntax recognition, where people really should know better. | |
| ▲ | gmueckl 4 days ago | parent | prev [-] | | 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. | | |
| ▲ | immibis 4 days ago | parent | next [-] | | 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? | |
| ▲ | kulahan 4 days ago | parent | prev [-] | | Why would I mature yours and deal with those issues when I can just use the already-mature one? | | |
| ▲ | gmueckl 4 days ago | parent [-] | | You 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 3 days ago | parent [-] | | We 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. | | |
| ▲ | gmueckl 3 days ago | parent [-] | | I'm not changing any story here. All this "use a library" advice to juniors isn't as universal amd fast as everybody makes it sound. I always find that it sounds too discouraging. There is no magic in these libraries and in their creation - just time and effort. And that's something that needs to be mentioned, too. You can roll your own if you're willing to justify the effort. Depending on the context, it may just not be a good use of your time. That's why it's also important to point out that no significant piece of code is mature and stable from the start, but was brought into this state iteratively using tools and processes that are available to everybody else, too. The biggest difference between existing mature code and new code under any good development process
is age. |
|
|
|
|
|
|
| ▲ | ozim 4 days ago | parent | prev | next [-] |
| I 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. |
| |
|
| ▲ | DANmode 4 days ago | parent | prev [-] |
| Holy 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. |
| |
