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.