Yarn

Recent twts in reply to #vh5pwrq

@markwylde 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.

⤋ Read More

@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

⤋ Read More

@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 😂

⤋ Read More

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)

⤋ Read More

@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.

⤋ Read More

@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.

⤋ Read More

@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 🤣)

⤋ Read More

@prologic@twtxt.net

“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.

⤋ Read More

@prologic

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.

⤋ Read More

@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.

⤋ Read More

@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.

⤋ Read More

Participate

Login or Register to join in on this yarn.