Well first you better manually construct that Soldering Iron. Skipping a few dependencies don't you think? Matter of fact, how'd you power that to begin with? You better go build a power source and electric grid.
True, but unfortunately, there is nothing stopping people who don't know what they're doing, from going npm install until their project directory collapses into a black hole.
In an ideal world, a library is a way to reduce complexity of big systems because you can avoid the redundancy of recreating functionality over and over and needing to know about slightly different behaviors in various modules.
In the real world, the library-ization of the ecosystem has over-solved the code re-use problem that we had decades ago, and now so much new code is written around managing and consuming modules that instead of deduplication making development simpler overall, we have an absolute net explosion in complexity. And I no longer have any idea how my computer actually works. And so many people having given up on understanding complex systems as even being a possibility let alone a goal or an expectation that nobody seems to even think it's a bad thing that it's impossible to understand a computer any more.
Good take. I just worry when inexperience meets vibecoding the result is overbloated mess.... but it "works" at first glance. Which creates even more inexperience in the end.
Why do we use dependencies? High level languages? Any tool whatsoever? Because we get to our objectives faster by doing it. That's all there is, and always has been. Get the job done sufficiently well fast enough. If your so called bloat makes the output not good enough, then it gets fixed. Just like we only optimize the inner loops where the engineering cost is lower than what we get in product improvements. That's engineering tradeoffs 101.
But what if I want my pickup truck to be able to win a Formula 1 GP? Well, then you want something different than a pickup. And you bet it's going to cost more to design, and then even more to manufacture. Pick your tradeoffs.
I maintain that there is no such thing as "vibecoding". LLMs don't "code", they "generate".
It's "vibe-generation", and the quality of the code slowly degrades over time just like a JPEG. You're just generating patches over patches, each with less context than before, and without understanding or learning.
I've had to maintain Node and Java codebases since long before vibe coding was ever a thing. Believe me, inexperienced devs (and absolute idiots) have always bloated codebases with unnecessary dependencies. It's nothing new.
I forgot to mention that it will be much worse (compared to before vibecoding) given the how many LOCs can you generate without thinking much about it.
Scaffolding has been a thing forever, I absolutely hate it and always have, but everyone has long said that everything must start with this 5000 line boilerplate mess they don't understand because it just works...
Vibe coding isn't going to make it worse, it's just this same garbage as always
In my experience, it's usually some ancient, cobbled-together application that everyone in the company uses as a "template", cloning and then deleting all the usage-specific code (if you're lucky) before starting to build their own Frankenstein monstrosity with it.
That is situation that always happened: you need to do something, you don't know how, you find a tool that does it for you and you use it. But back then, it was up to you to evaluate if that tool did what you needed. You learned its quirks and how to go around them.
Now, we're using something that automates this whole process and by result, learn nothing from it.
But they're also something you need to keep an eye on and use some critical thinking to evaluate.
I recently had to stop updating one of my dependencies, because the maintainer had changed and the first release after that change the new README was entirely AI generated and I don't trust that the new maintainer will... Well, maintain code quality in the future.
However, if we take a second and step out of software we realize the it's not a new or unique phenomenon. We could talk about how no single engineer likely knows or needs to know every aspect of how a building, or a car, or a plane, or any some such works, but we don't even need to go that far. Software Engineers needs to vaguely understand what computers are, how they work, but you absolutely don't need to be a subject matter expert on constructing and organizing motherboards and RAM units to be a successful software engineer. Those are dependencies. You need to know what RAM is. You don't need to know how it works.
An electrician doesn't need to know how a hydroelectric dam works in order to wire up a house. They don't need to be able to construct any of their tools. They just need to understand the crucial components relevant to their work. Understanding the source of electricity on their grid, what the houses power is dependent on, is not relevant.
It might start to get more relevant if you're building a small "off the grid" compound and have to rely on your own power sources. Then understanding some amount of how those sources generate power, their output levels, and their constraints will be important in building a safe, stable grid. Still, you wouldn't need to know how to construct solar cells. You wouldn't need to to understand the chemistry involved in a fueled generator. You would just need to read the manual, the documentation.
That's analogous to how software dependencies are and should be used. Don't reinvent the wheel if you find a tool that already does what you need. Read the documentation so you understand how to use it, but don't dig deeper unless you absolutely need to.
There's a million different ways to dissect this take. We can't know everything, and that's why teams exist. That's why people sell products. That's why people buy services. That's why different generations of programmers work differently. Standing on the shoulders of giants and all that.
You could save some lines as we are arguing here things based on title not the video. TL;DW is dependencies are must. Incentives to change/rebuild them is low. Understand as much as you can and encourage that understanding.
No, they're not, and anyone making that argument should take a computer science class because they know just enough to have an opinion, but not enough for that opinion to be based on reality.
So clickbaity title aside, it is true that many people will just use for example `react-query` or `Zustand` as a magic wand, that makes their render problems go away.
I just don't see the problem with that? It is a natural progression of a Junior to Mid to Senior all the way to Architect, the understanding how things work. I am all for beginners to shit their repos all over with dependencies. It will be more secure, robust and bug free.
It will be only natural as they encounter bugs, issues and gaps that they well LEARN. TBH taking that away and forcing people to learn 'the basics' upfront kind of would suck the joy out of creating for beginners. They will gain nothing from trying to understand how modern UI libraries manage tables, or how Better Auth creates session cookies, and it is not the time to absorb this knowledge.
The only problem I have with Juniors and Mids under me is they have this mentality of '3 days of trial and error will save you 10 mins of reading the docs'. If we will try to make the younglings adjust their approach is that we force them to read the damn docs, even when vibe coding.
Funnily enough more often then not when asking an LLM to do something for me it will try to write something from scratch that has a battle tested library solution.
Lost me 1 minute in. If you can't rely on abstractions, then your capabilities are very limited. Crappy dependencies with leaky abstractions have a big cost. But you don't have to know how to build a fab to write a website. Silicon provides a pretty good abstraction that rarely breaks. Regular expression libraries are another example. You don't need to know about finite state machines to use them effectively.
Agree, compounding knowledge on knowledge are the fundamental building block system to we use with all major engineering disciplines and for programming the dependencies go all the way down to bare metal. It’s unreasonable for an every day programmer to necessarily be capable of implementing a cryptography library in the same way that a cook or chef does not need to understand how to extract or transport natural gas to their cook top in order to make food.
It literally is... because we've been researching this for decades, just under the name "transactive memory". Psychologists have long known that the brain has a tendency to externalize knowledge, where instead of actually 'learning' something it instead will try to encode where to find that information as a sort of energy-saving compression technique.
Before even the most recent crop of LLM-driven cognitive offloading, the effects of this were well studied in the context of simple search engines and the effect just having a smartphone in your pocket was/is having on cognition. Every software dependency that we include in a project is an example of this same desire to replace knowledge with references to knowledge, where instead of knowing how to write a function we know what it's called and in what library it lives.
Transactive memory is important: it's how we create a division of labor and enable ourselves to specialize in deeper, more narrow fields of work. However, when we have runaway dependency hell, where even simple problems like leftpad get replaced with new external references, projects and people quickly lose the necessary context for any deeper reasoning, because everything is just pointers to knowledge graphs elsewhere and so all the interesting topological features of the cognitive map are lost.
No worries. It's here for the future time travelers to fix bunch of stuff in the past.
I've got better things to do when time-traveling into the past...
*Hello Soon-To-Be-Ex-Wife, the ramifications of your soon-to-start-affair is absolutely going to screw up your kids lives, which will see them leave you in about, oh, I dunno, 17 years.
Dependencies can drastically reduce the available pool of people who can maintain and expand code.
You don't want to be stuck with, for example, Java-code that cant be understod by a dev that knows Java.
You wind up needing to hire a part-sum of part-sum of a part-sum, of the available devs.
And as a dev its not fun to inherit a project that consists of 100000 files, of which 99900 files are dependencies that have dependencies with dependencies, and none of them have any real documentation.
And the code looks more like regexp than whatever programming language it is supposed to be.
Especially not if there is no budget for the work it takes to untangle that mess.
A warning-sign, is when the documentation for a dependency also has dependencies.
For example, if they explain functions like: "Our function foobar() is just like foobar() in the competing framework XYZ, but with these differences..."
So you have to go the the website for XYZ and learn that one too.
Indiscriminate use of dependencies certainly can cause maintenance challenges.
But the point of dependencies is to make code more maintainable by reducing the cognitive load of the project. To replace knowledge with dependencies has always been the point.
That’s why I specifically mentioned on existing knowledge you have. So you can review your dependency or rely on authority (as in sec tools). Not a jab at you, I agree, we should understand what dependency do for you before using it.
tomekrs@reddit
History of evolution of software development but by someone who doesn't know it so is shocked and against.
Your CPU is a dependency to begin with. Solder manually some MOSFETs that you made in your home laboratory if you want to be free of dependencies.
Enerbane@reddit
Well first you better manually construct that Soldering Iron. Skipping a few dependencies don't you think? Matter of fact, how'd you power that to begin with? You better go build a power source and electric grid.
oldmanhero@reddit
https://xkcd.com/378/
semmaz@reddit
Dependencies are for people that actually know what they’re doing. Offloading your existing knowledge to more robust pool that you can depend on.
usrlibshare@reddit
True, but unfortunately, there is nothing stopping people who don't know what they're doing, from going
npm installuntil their project directory collapses into a black hole.wrosecrans@reddit
In an ideal world, a library is a way to reduce complexity of big systems because you can avoid the redundancy of recreating functionality over and over and needing to know about slightly different behaviors in various modules.
In the real world, the library-ization of the ecosystem has over-solved the code re-use problem that we had decades ago, and now so much new code is written around managing and consuming modules that instead of deduplication making development simpler overall, we have an absolute net explosion in complexity. And I no longer have any idea how my computer actually works. And so many people having given up on understanding complex systems as even being a possibility let alone a goal or an expectation that nobody seems to even think it's a bad thing that it's impossible to understand a computer any more.
rybarix@reddit (OP)
Good take. I just worry when inexperience meets vibecoding the result is overbloated mess.... but it "works" at first glance. Which creates even more inexperience in the end.
hibikir_40k@reddit
"Overbloated mess?!" That's non-engineering talks.
Why do we use dependencies? High level languages? Any tool whatsoever? Because we get to our objectives faster by doing it. That's all there is, and always has been. Get the job done sufficiently well fast enough. If your so called bloat makes the output not good enough, then it gets fixed. Just like we only optimize the inner loops where the engineering cost is lower than what we get in product improvements. That's engineering tradeoffs 101.
But what if I want my pickup truck to be able to win a Formula 1 GP? Well, then you want something different than a pickup. And you bet it's going to cost more to design, and then even more to manufacture. Pick your tradeoffs.
omniuni@reddit
I maintain that there is no such thing as "vibecoding". LLMs don't "code", they "generate".
It's "vibe-generation", and the quality of the code slowly degrades over time just like a JPEG. You're just generating patches over patches, each with less context than before, and without understanding or learning.
New-Anybody-6206@reddit
this is like complaining that people eat fast food because it doesn't use their own cooking skills
kintar1900@reddit
I've had to maintain Node and Java codebases since long before vibe coding was ever a thing. Believe me, inexperienced devs (and absolute idiots) have always bloated codebases with unnecessary dependencies. It's nothing new.
rybarix@reddit (OP)
I forgot to mention that it will be much worse (compared to before vibecoding) given the how many LOCs can you generate without thinking much about it.
CpnStumpy@reddit
Scaffolding has been a thing forever, I absolutely hate it and always have, but everyone has long said that everything must start with this 5000 line boilerplate mess they don't understand because it just works...
Vibe coding isn't going to make it worse, it's just this same garbage as always
semmaz@reddit
Who do the scaffolding? Especially since it changes about half an a year
kintar1900@reddit
In my experience, it's usually some ancient, cobbled-together application that everyone in the company uses as a "template", cloning and then deleting all the usage-specific code (if you're lucky) before starting to build their own Frankenstein monstrosity with it.
semmaz@reddit
Yikes, but sadly true, trying to escape this thing now
nelmaven@reddit
That is situation that always happened: you need to do something, you don't know how, you find a tool that does it for you and you use it. But back then, it was up to you to evaluate if that tool did what you needed. You learned its quirks and how to go around them.
Now, we're using something that automates this whole process and by result, learn nothing from it.
semmaz@reddit
lol, now I can see that some condescending comments on stack can be helpful for me w dev
semmaz@reddit
More work for experienced devs!;) But yeah, I also worry that current trend would just degrade general quality of the dependencies code.
EliSka93@reddit
But they're also something you need to keep an eye on and use some critical thinking to evaluate.
I recently had to stop updating one of my dependencies, because the maintainer had changed and the first release after that change the new README was entirely AI generated and I don't trust that the new maintainer will... Well, maintain code quality in the future.
mtutty@reddit
Shallow take.
semmaz@reddit
It is, but it encourages talk about it, and it especially important right now
Enerbane@reddit
Sure. Maybe.
However, if we take a second and step out of software we realize the it's not a new or unique phenomenon. We could talk about how no single engineer likely knows or needs to know every aspect of how a building, or a car, or a plane, or any some such works, but we don't even need to go that far. Software Engineers needs to vaguely understand what computers are, how they work, but you absolutely don't need to be a subject matter expert on constructing and organizing motherboards and RAM units to be a successful software engineer. Those are dependencies. You need to know what RAM is. You don't need to know how it works.
An electrician doesn't need to know how a hydroelectric dam works in order to wire up a house. They don't need to be able to construct any of their tools. They just need to understand the crucial components relevant to their work. Understanding the source of electricity on their grid, what the houses power is dependent on, is not relevant.
It might start to get more relevant if you're building a small "off the grid" compound and have to rely on your own power sources. Then understanding some amount of how those sources generate power, their output levels, and their constraints will be important in building a safe, stable grid. Still, you wouldn't need to know how to construct solar cells. You wouldn't need to to understand the chemistry involved in a fueled generator. You would just need to read the manual, the documentation.
That's analogous to how software dependencies are and should be used. Don't reinvent the wheel if you find a tool that already does what you need. Read the documentation so you understand how to use it, but don't dig deeper unless you absolutely need to.
There's a million different ways to dissect this take. We can't know everything, and that's why teams exist. That's why people sell products. That's why people buy services. That's why different generations of programmers work differently. Standing on the shoulders of giants and all that.
rybarix@reddit (OP)
You could save some lines as we are arguing here things based on title not the video. TL;DW is dependencies are must. Incentives to change/rebuild them is low. Understand as much as you can and encourage that understanding.
CodeAndBiscuits@reddit
Didn't expect a considered, thoughtful comment on a Sunday but I'm here for it. 😎
TheRealPomax@reddit
No, they're not, and anyone making that argument should take a computer science class because they know just enough to have an opinion, but not enough for that opinion to be based on reality.
Tackgnol@reddit
So clickbaity title aside, it is true that many people will just use for example `react-query` or `Zustand` as a magic wand, that makes their render problems go away.
I just don't see the problem with that? It is a natural progression of a Junior to Mid to Senior all the way to Architect, the understanding how things work. I am all for beginners to shit their repos all over with dependencies. It will be more secure, robust and bug free.
It will be only natural as they encounter bugs, issues and gaps that they well LEARN. TBH taking that away and forcing people to learn 'the basics' upfront kind of would suck the joy out of creating for beginners. They will gain nothing from trying to understand how modern UI libraries manage tables, or how Better Auth creates session cookies, and it is not the time to absorb this knowledge.
The only problem I have with Juniors and Mids under me is they have this mentality of '3 days of trial and error will save you 10 mins of reading the docs'. If we will try to make the younglings adjust their approach is that we force them to read the damn docs, even when vibe coding.
Funnily enough more often then not when asking an LLM to do something for me it will try to write something from scratch that has a battle tested library solution.
gladfelter@reddit
Lost me 1 minute in. If you can't rely on abstractions, then your capabilities are very limited. Crappy dependencies with leaky abstractions have a big cost. But you don't have to know how to build a fab to write a website. Silicon provides a pretty good abstraction that rarely breaks. Regular expression libraries are another example. You don't need to know about finite state machines to use them effectively.
dashdanw@reddit
Agree, compounding knowledge on knowledge are the fundamental building block system to we use with all major engineering disciplines and for programming the dependencies go all the way down to bare metal. It’s unreasonable for an every day programmer to necessarily be capable of implementing a cryptography library in the same way that a cook or chef does not need to understand how to extract or transport natural gas to their cook top in order to make food.
semmaz@reddit
Agree and disagree. FSM are not be all and for all. There’s some things you can’t reliably express with it , int it?
AntiElephantMine@reddit
Totally unrelated, what keyboard is that?
rybarix@reddit (OP)
Keychron K9 Brown Switches
Reasonable_Gas8524@reddit
Do these over depent Dependcies find their way into AI models ?
jack-of-some@reddit
This video feels at least 10 years too late.
mwobey@reddit
It literally is... because we've been researching this for decades, just under the name "transactive memory". Psychologists have long known that the brain has a tendency to externalize knowledge, where instead of actually 'learning' something it instead will try to encode where to find that information as a sort of energy-saving compression technique.
Before even the most recent crop of LLM-driven cognitive offloading, the effects of this were well studied in the context of simple search engines and the effect just having a smartphone in your pocket was/is having on cognition. Every software dependency that we include in a project is an example of this same desire to replace knowledge with references to knowledge, where instead of knowing how to write a function we know what it's called and in what library it lives.
Transactive memory is important: it's how we create a division of labor and enable ourselves to specialize in deeper, more narrow fields of work. However, when we have runaway dependency hell, where even simple problems like leftpad get replaced with new external references, projects and people quickly lose the necessary context for any deeper reasoning, because everything is just pointers to knowledge graphs elsewhere and so all the interesting topological features of the cognitive map are lost.
semmaz@reddit
Kinda, but also on the surface. That no one have the will to talk about
rybarix@reddit (OP)
No worries. It's here for the future time travelers to fix bunch of stuff in the past.
lelanthran@reddit
I've got better things to do when time-traveling into the past...
*Hello Soon-To-Be-Ex-Wife, the ramifications of your soon-to-start-affair is absolutely going to screw up your kids lives, which will see them leave you in about, oh, I dunno, 17 years.
rybarix@reddit (OP)
Picking wife is def. dependency problem but yeah fix that first
MatsSvensson@reddit
Dependencies can drastically reduce the available pool of people who can maintain and expand code.
You don't want to be stuck with, for example, Java-code that cant be understod by a dev that knows Java.
You wind up needing to hire a part-sum of part-sum of a part-sum, of the available devs.
And as a dev its not fun to inherit a project that consists of 100000 files, of which 99900 files are dependencies that have dependencies with dependencies, and none of them have any real documentation.
And the code looks more like regexp than whatever programming language it is supposed to be.
Especially not if there is no budget for the work it takes to untangle that mess.
A warning-sign, is when the documentation for a dependency also has dependencies.
For example, if they explain functions like: "Our function foobar() is just like foobar() in the competing framework XYZ, but with these differences..."
So you have to go the the website for XYZ and learn that one too.
Spitfire1900@reddit
Indiscriminate use of dependencies certainly can cause maintenance challenges.
But the point of dependencies is to make code more maintainable by reducing the cognitive load of the project. To replace knowledge with dependencies has always been the point.
semmaz@reddit
That’s why I specifically mentioned on existing knowledge you have. So you can review your dependency or rely on authority (as in sec tools). Not a jab at you, I agree, we should understand what dependency do for you before using it.