Re: "When code reuse turns ugly"

[Your Mother]

The great thing about predicting doom is that if you just keep doing it long enough you are guaranteed to be right.

Is a week of broken builds and surprise scrambling all over the world less than or greater than the uncountable commits, arguments, and shipped bugs of splitting out an ostensibly simple little block of code to 50,000 projects and 39,273 developers who couldn't get it right the first few passes? Legitimately curious but it's rhetorical since there is no way to measure it. I wish there were. The cold water of individual prerogative v corporate assumption in open source was worth something in the whole show, at least to me.

Turning things we like into virtue and things we dislike into sin should be a bit of a red flag on an opinion piece.

[BrowserUk]

The great thing about predicting doom

I'm not sure that I ever "predicted doom" so much as railed against the logic of substituting a dependency for a 1 or a few lines of code you write and maintain yourself.

Would you call this "predicting doom"? Or this? Or this?

Is a week of broken builds and surprise scrambling all over the world less than or greater than the uncountable commits, arguments, and shipped bugs of splitting out an ostensibly simple little block of code to 50,000 projects and 39,273 developers who couldn't get it right the first few passes? Legitimately curious but it's rhetorical since there is no way to measure it. I wish there were.

The other paragraph in the article that stood out for me was: "Is it possible that we've become too lazy? Rather than write one-line functions, folks are pulling in outside code, and thus overly relying on dependencies. Here's some widely used open-source NPM modules that caught our eye:"

I see people pulling in whole (large and complex) packages in order to use 1 or 2 lines. Eg, Sub::Exporter

Turning things we like into virtue and things we dislike into sin should be a bit of a red flag on an opinion piece.

I think the keyword is balance. Not writing your own DBI from scratch is obvious; Math::Round to get round() less so.

[VinsWorldcom]

I'm totally on board with the "we've become too lazy" point. Partly because I don't know Perl modules well enough, and partly because of that exact issue - I don't want additional dependencies beyond CORE in my modules unless I absolutely can't help it - I find myself reinventing some "simple" wheels to make it easier for others (like me) who object to never-ending chains of recursive dependencies when installing what *should* be a simple module.

I hadn't thought of the consequences of someone removing an open source Perl module on which one of mine depends, but I *guess* it *could* happen - luckily I've been under-reliant on external module use within mine.

[BrowserUk]

I hadn't thought of the consequences of someone removing an open source Perl module on which one of mine depends, but I *guess* it *could* happen

That'd never been of concern to me either. For one thing, perl isn't (as) vulnerable to that because perl modules get installed locally rather than downloaded from their source, on demand, each time they are used as so much JS stuff is.