I'd consider it a serious code smell for my codebase to be carrying around my personal attempt (or my team's attempt) at at half of the Python standard library. When it looks like we're heading in that direction, let's just use Python!
Sure, if it's really just arithmetic on lists, I won't be happy about it, but I'll write it. I've yet to meet a standard library which is wonderfully complete except for that one thing. If the abstractions of the environment I'm working in are that poor, there's going to be a thousand other little "trivial" things that I'm now responsible for maintaining, and some of them will turn out to be less trivial than imagined.
For example, it is "trivial" to write linked lists in C, but tracking down the one-character typo that causes them to nondeterministically explode is IMO a distraction from the project, not a valid part of it.
And what about the next project in that language? Wouldn't it be nice to factor out all that stuff and bring it with me? Well, now I am using a community standard library, but it's the community of "just me." Why not take one with some internet recommendations and an active Github?
My employer fortunately runs its own package mirrors, though, so we don't run the risk of packages just disappearing on someone else's whim.
I suppose our difference in values is that I consider each line of in-house code as much of a liability as you consider each line of other people's code.
My reaction to the article is very simple:
>What concerns me here is that so many packages took on a dependency for a simple left padding string function, rather than taking 2 minutes to write such a basic function themselves.
"So many people" writing a basic function themselves is an exactly wrong outcome IMO.
Sure, if it's really just arithmetic on lists, I won't be happy about it, but I'll write it. I've yet to meet a standard library which is wonderfully complete except for that one thing. If the abstractions of the environment I'm working in are that poor, there's going to be a thousand other little "trivial" things that I'm now responsible for maintaining, and some of them will turn out to be less trivial than imagined.
For example, it is "trivial" to write linked lists in C, but tracking down the one-character typo that causes them to nondeterministically explode is IMO a distraction from the project, not a valid part of it.
And what about the next project in that language? Wouldn't it be nice to factor out all that stuff and bring it with me? Well, now I am using a community standard library, but it's the community of "just me." Why not take one with some internet recommendations and an active Github?
My employer fortunately runs its own package mirrors, though, so we don't run the risk of packages just disappearing on someone else's whim.
I suppose our difference in values is that I consider each line of in-house code as much of a liability as you consider each line of other people's code.
My reaction to the article is very simple:
>What concerns me here is that so many packages took on a dependency for a simple left padding string function, rather than taking 2 minutes to write such a basic function themselves.
"So many people" writing a basic function themselves is an exactly wrong outcome IMO.