in reply to Re: "When code reuse turns ugly"
in thread "When code reuse turns ugly"

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.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^3: "When code reuse turns ugly"
by VinsWorldcom (Prior) on Mar 30, 2016 at 19:43 UTC

    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.

[reply]
      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.

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

        And there's minicpan and pinto, probably others. I think (perhaps fancy) the habit of having local mirrors of the repository is more common among Perlers than with users of other languages

        On the other side, a search for "npm local repository" (google, ddg) shows interesting items that seem to exist longer than the few days since the incident, probably they get more traction now … :-)

        But perhaps we should replace "Yes, even you can use CPAN" with "UTSL", anyway :->

[reply]

        Good point. You always would have the last version installed locally.

[reply]

In Section Perl News