@prologic hmm… I have mixed feelings… Like reinventing the wheel to learn vs using an already round one…
It’s a hard conversation, and as with education it depends on your context and ideology but you can and should ‘force’ it in your organization
@eaplmx My point though was around copy/paste being okay as a tool 👌 😂
We teach the concept of reusability far too much and over ehpazise it to the point where many junior developers believe and have an alergic reaction to copying and pasting code 😂
another concept that we teach overemphasize is that globals are bad! 🤣 in fact, computers know nothing else, but global memory anyway 🤦♂️ (with the exception of protected rings, and protected segments of memory)
@prologic All I know is, this problem is much less prevalent in languages without official package managers, like C or Lua.
@prologic I see the opposite here, copying and pasting lazily instead of creating reusable code.
I mean, having a dependency to know if a number is odd or even is excessive https://www.npmjs.com/package/is-odd-or-even
But at the same time if your language or runtime gives you these quick snippets is usually better that your own code, due to those “things you didn’t know you don’t know”. That’s why I have mixed feelings on copying and paste vs using a dependency vs reimplementing it yourself.
@eaplmx There can’t be a concrete rule for this sort of thing. I’m generally in favor of reinventing the wheel to certain extent, but using a library can be very useful if you want to focus on the end result.
When your 5 dependencies each have 5 dependencies of their own, then you have a problem.
@mckinley Is right here, as much as I’m strongly opinionated on the subject, there is no “hard” and “fast” (right or wrong) rule here. There are only “rules of thumb”, “guidelines” and “experience”.
And as @mckinley nicely points out, the real problem is likely the exponential effect of dependencies. Fortunately or unfortunately (depending on how you look at it) libraries can also have dependencies (and good language really will support this), but the thing we often refer to as “dependency hell” comes from this “exponential dependency tree” that we inevitably see in ecosystems like NodeJS / NPM (are there other examples? I feel like I pick on NodeJS / NPM too much 🤣)
“dependency hell” comes from this “exponential dependency tree” that we inevitably see in ecosystems like NodeJS / NPM
Yes, and these “ecosystems” try to put a band-aid on it by allowing packages to specify which version of a package they need. All that means is you get 7 different versions of the same package bloating up your node_modules folder and 6 critical vulnerabilities from one package.
Then, it’s impossible to keep track of all 1200 of your dependencies and sub-dependencies, so you get a robot to do it for you: Dependabot. What happens when Dependabot dies? Absolute chaos.
NodeJS library authors could just write better libraries and avoid breaking changes every update, and NodeJS software developers in general could fix their programs when they break, but they don’t. It’s on the “ecosystem” to solve for this, and it inevitably does a terrible job.
are there other examples?
Python, Ruby, Perl, Rust. Sometimes even Go. There’s a little bit of this in every language with an official package manager. I’d say Python and NodeJS are the worst offenders, though.
I feel like I pick on NodeJS / NPM too much
I don’t think we pick on NodeJS/NPM enough.
@mckinley Thankfully less so in Go, because of the culture around the language, but I used to feel this way about Python too once upon a time, I feel like languages and ecosystems get “populated” with ideas from every other language/ecosystem over time and eventually reach a state of “chaos”? 🤔 As an example, Go now supports generics as of Go 1.19, something I’m not really all that thrilled with really as it adds unnecessary complexity to the language IMO that isn’t really needed.
@eaplmx my view on this is that I tend to recreate the wheel everytime for a simple reason: it get better everytime I make it.
When copying something, which is ok for me too, you’re relying on the thought you had at the time, while currently they could be different and you could get around a problem quite differently.
For me reusability is about internal code, not with libraries.
If I need to share code with my project using a library then that library is made with my own hands and code.