@markwylde@twtxt.net No, it doesn’t have to be this way, but it is (almost) always this way. When a programming language makes it too easy to manage dependencies, you inevitably get microdependencies. It doesn’t help that many people learn JavaScript or Python as their first language.

I don’t think it’s the tools fault per se 🤗 It’s a educational problem I think. Not everything has to be a library / dependency:

Copying and Pasting code is “okay” 👌

@prologic@twtxt.net 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@twtxt.net 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@twtxt.net 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.

@mckinley@twtxt.net 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@twtxt.net 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 🤣)

@mckinley@twtxt.net 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@twtxt.net 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.