> If I have to work in this language, and I'm allowed to bring in packages, I'd go look for the community's attempt at fixing the standard library ... If it's really just this, I'll probably paste a Stackoverflow answer.

Sorry, can I get this straight, we're talking about sum() now, right? I'm genuinely amazed.

> thinking through the pitfalls of the implementations of basic math operations is not a good use of time

I suppose there's a trade off, at some point it is less time to find, check, and invest in a package rather than write its contents. For lots of cases it is definitely faster to use a package. But we're talking about averaging a list of numbers here, or adding them, right? Doesn't this strike you as rather bizarre to be having this discussion over things you should be able to write trivially?

> What would you do if your language didn't have exponentiation?

It depends what I need it for and what kind of exponentiation. I'd use inline exponentiation by small positive integers. I'd be concerned if my team were writing pow(x, 2) + pow(y, 2), for example. If I needed fractional exponentiation (e.g. pow(k, 3.567)), then I know that's beyond the realm of something that could be implemented in a couple of lines. If the language didn't have it, I might write it, certainly, especially if it wasn't part of a bigger suite of functionality I need.

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.

[Edit: Parent comment has been rewritten, see second response, below].

That you think averaging a list of numbers qualifies as a 'feature' you might add to a codebase is rather the surprising thing about your response. I'm aware I'm coming over rather arsey, and that isn't intended, I'm just surprised to find someone actually defend the attitude, generally, that says a trivial calculation should be either a) provided, or you're not going to use the language, or b) put in a package to mean you don't have to spend 'the time' writing it, while at the same time saying you don't care what is in those implementations.

I mean, it doesn't matter to me, obviously. You can choose to have whatever criteria for taking a job you like, and I can have whatever criteria I like for my hires. I'm just surprised. Sorry If I've come over argumentative or grandstanding.