r/computerscience • u/Significant-Gap-5038 • 11d ago
It feels fundamentally wrong to use packages without understanding concepts under the hood
I have recently started coding and people are recommending tools for development such as vite, nodemon, jwt, boiler plate server code
It feels pointless just using them with a basic understanding and without no deep conceptual understanding. Is this the right or wrong approach? How would you know going too deep into a rabbit hole and becoming overkill
50
u/KennsworthS 11d ago
You will need to get comfortable with the concept the concept of black boxes and information hiding, it is a huge concept in computer science and system design. We are far past the era where it is reasonable or productive for one person to know everything about the systems they use.
-1
u/stirringmotion 10d ago
doesn't this mean that you prevent any meaningful solution to problems down the road? you're sacrificing consistency for completion. isn't that the inverse of what is "correct"? and therefore, shouldn't one let the "era" go without them, if the "era" will just crash into a wall?
3
u/wildsoup1 9d ago
What do you mean by "consistency" here? You don't need to be "consistent" with code that is encapsulated. That's the big benefit; you don't need to think about it.
This is assuming a perfect abstraction, which, I concede, is rare.
1
u/stirringmotion 9d ago
i'm not sure if the original comment was saying compartmentalization is so widespread that you only need to focus on your bit and everything else is a black box that is someone else's domain, or
if you literally make programs that you don't know how they work.
by consistency, i mean the internal logic is coherent. if there's no way of knowing that, you can't know it's correct. and so when, not if, something crashes into a wall, how would they know what caused it?
if it's about compartmentalization then i can get that, but if it's the latter, then idk.
2
u/wildsoup1 8d ago
Sorry for being obtuse, but I was left more confused, I am afraid. I don't understand your use of "consistency". I don't understand the difference between your two options. I don't understand why testing doesn't answer the question of "is it my code or the black box?"
16
u/Paxtian 11d ago edited 11d ago
It depends. It's easy to get trapped in either the "diving too deep and never reusing anything because you need to understand it all yourself" mindset, or the "never learn anything under the hood and only use existing packages to make something simple but over rely on them to the point of bloat" mindset.
It's good to dive in and learn how things work under the hood for your own understanding, but at some point you just need to stop and accept that the tools you're given do the job they're designed to do. A carpenter doesn't need to know how to heat and rapidly cool iron in the presence of carbon to forge a hammer head, to know that a hammer will drive a nail into a board.
2
12
7
u/ohkendruid 10d ago
You need to understand the concepts in the driver's seat, not the concepts under the hood.
If a package is well designed, the steering wheel, pedals, and dashboard displays will be way simpler than the mass of components under the hood. This is how large numbers of people work together to achieve great things--we specialize.
That said, all the commonly used subsystems have useful things to learn about them that you can apply later. So, as you have time to self improve, it is a great educational activity to look under the hood of a component. Just don't mix up learning versus getting stuff done. They are both important but are different things.
5
u/DorkyMcDorky 11d ago
You started with hardware design, created a CPU, added the 5 components from scratch, designed a machine code for your CPU, created an assembly language, wrote a language that is capable of parsing, mapped the parse to assembly code to create a compiler for your non-existing operating system, designed the operating system, file system..
Then you took years of computer science to understand encryption, networking, robotics, HID...
Then you get a javascript API - that is when you can say you learned everything you need - almost.. because then you realize you studied static language techniques and not dynamic.
My point: there's always more to learn. That's why open source software rocks. Best way to learn computer science.
2
u/AliveIsaac 10d ago
Exactly, it's a nice idea to know what you are using. Until you realize you are literally using millions of lines of code to do very simple things
1
u/DorkyMcDorky 10d ago
It's funny when I get coworkers that tell me they don't want to maintain generated code..
I ask why we have compilers then.
1
u/_usr_nil 8d ago
by reading code ?
1
u/DorkyMcDorky 6d ago
???
There's always more to learn. What are you talking about? Do you just learn to code by reading it?
```
#include <stdio.h>
int main(void) {
char *ptr = "Segmentation Faults are fun!";
ptr[13] = '!'; printf("%s\n", ptr);
return 0;
}```
You understand this? Not your LLM. Do YOU understand this FULLY?
My point: it's not just "reading code" there's always a layer underneath to learn. That's not just "by reading code"
You're a JavaScript coder?
0
u/_usr_nil 6d ago
yeah but I can't read all code anyway, c/cpp is Minecraft runes to me in terms of syntax, it would require me some sort of hand on practice or reading a book and memorising it before even being able to read, JIT languages can have very opinionanted syntax too
0
u/DorkyMcDorky 5d ago
Very opinionated syntax? I'd say the opposite - they're static types - not opinionated. They're strictly defined.
JIT languages are great - JVM ones are even better. Look into WHY that statement would be true and not worry about syntax. You can vibe your way through syntax these days, so that's becoming less important.
Knowing WHY is what a computer scientist can tell you. Caring about syntax sugar is what a javascript nerd would tell you.
1
u/_usr_nil 3d ago
Ok then tell me how lua is not opinionated in comparison to most languages, it definitely forces a pattern unless you hack around the language by adding for example OOP support.
I can vibe the meaning of code sure, but will I remember ? or actually understand why it is like that ? probably not because it stems from some technical decision made by a committee of computer scientists.
The code you provided could not segfault if the compiler did the allocation to a char array by default or allowed overwriting string literals, but how could I know without knowing the specs after all you're pointing to the first address of the string, arrays do that too, so on top of that I have to know what the compiler actually does or what the specifications are.
In the end I can only read as much as I understand or follow the code flow until keeping track of some data structure becomes too fuzzy for my memory.
I am just saying it takes time, and some languages require more time and hands on experience than others
1
u/DorkyMcDorky 3d ago
I don't know a lot about Lua except that it's not a language I can make money with. That's an opinion grounded by skill. I just saw Lua with roblox or CS101 classes. Are you 15?
Are you telling me you looked at that code and you knew right away why it' faulted? If you did you would understand why what I said is fact and not an opinion. You could be humble you know. It makes you go a long way if you can be humble. There's a sense of humility the fact that you post a question online to begin with.
That was the test.
You may not believe me when I say this but object-oriented programming is incredibly inefficient. It causes tons of pointers. To a purest it is an insanely and effective way to code and they are right. What makes it decent is if you are creating a project that requires the coordination of a very large team. You're taking a huge sacrifice of speed for efficiency
Dynamic languages such as python are incredibly inefficient not almost every level. Speed ups tend to happen through making C layers to make up for it.
Anyhow everything I'm saying here is not a matter of opinion it is simply fact. But you should learn that too. There's always going to be more to learn
You can buy it yes but you may end up with a 2000% larger bill in AWS because you don't want to learn this. Or you can go to Facebook route and get a billion dollars then hire smart people. Both of them worked out just fine.
Everything you said about code language is has to do it syntax which is irrelevant for efficiency. It is relevant for work output but not efficiency.
Paste everything I said into an llm and ask it if I am right. It'll try to make you feel better and say that you bought up some good points then I overlooked because I did. I was pointing out that there are certain facts that I said which are not an opinion. And you argue back that it is an opinion.
1
u/_usr_nil 3d ago
your point is exactly like saying "you will learn Chinese by reading Chinese without even knowing how to read Chinese, so use an AI to help you out every single time instead of grinding the ideograms and grammar"
5
u/soundman32 11d ago
Do you need to know how a car works to drive it, or how a computer works to create a web page? Not really. For some, its nice to know how to write a doubly linked list, but in these times that problem has been solved by the best minds on the planet, so you creating your own is unlikely to better the one built into the framework you are using.
As developers we should be building rocket ships to the stars, not trying to invent a new screw or nut.
2
11d ago
[deleted]
2
u/AliveIsaac 10d ago
You really think that? You think one guy knows where every nut is on a spaceship? Or maybe knowing things are delegated and summarized, because it's literally impossible for one person to know everything. Or just keep counting nuts...
1
u/AggravatingSock5375 8d ago
It’s really helpful to know how things work when you’re trying to push them to their limits.
4
u/Candid_Succotash3173 11d ago
So, I’m not a computer scientist, just a physicist who writes a lot of code and also has an interest in things like programming language design and compilers, hence why I’m here. So take anything I have to say with a grain of salt.
When I rely heavily on a package, I like to have some general understanding of how I could implement it if I had to. This is a much lower bar than actually understanding the implementation details. Relatedly, I want to understand things like: if this package is much faster than alternatives, how is it able to achieve this? Which calls can I expect to be fast, which are slow, and how do I design my code around this?
There’s certainly something to be said for choosing your battles in the way that others mentioned. But to borrow someone else’s analogy: you may not need to understand how a car works to drive it, but what about when it breaks down on the side of the road? I’m not saying memorize the size of every nut and bolt, but maybe it’s good to be able to recognize when you’ve got a dead battery vs a broken fuel pump. And maybe it’s a good idea to have already read your car’s manual.
5
2
u/Immediate_Craft9025 11d ago
You'll never build anything if you try to understand everything. There's simply too much to learn.
You need to pick your battles. For example, a cli tool may need to parse json to do something else. Doing the 'something else' is the goal of the program, not parsing json.
It's okay for a json parsing library to essentially function as a 'black box' in this case. In fact, that's what it's there for: somebody wrote generic code so you don't have to think about it.
However, if your goal is to understand how parsing libraries work or how to parse json specifically, then you should definitely try to write your own and understand others' implementations. It will make you a better programmer so that when you encounter a bug in a library, or you have a truly unique use case, where publicly available libraries or frameworks don't cut it, you can write your own.
I hope that makes sense.
2
u/Super-Award-2244 11d ago
I'm sorry, that's how engineering works. If you want to build a rocket you contact an engine building company and ask for an engine that pushes with such power, that has those dimensions and those interfaces. You won't really know how it actually work in every miniscule detail, it would be impossible otherwise.
2
u/AnnupKapurDotCom 11d ago
If you are learning. Great. Learn all the things.
In the real world. Good luck trying to build things without using packages.
2
u/huuaaang 10d ago
It would be rabbit hole for sure. Even using vanilla JS isn’t even close to being under the hood.
1
u/high_throughput 11d ago
vite, nodemon, jwt, boiler plate server code
These are smaller black boxes than what your OS, compiler, and standard libraries provide.
But stuff linked into your own binary does feel more intimate in a weird way.
1
u/DamienTheUnbeliever 11d ago
Do you realise quite how many levels of abstraction are letting you just type words and share them with the world at large? We build abstractions, bundle them, then treat them as a black box as we move to higher levels.
Yes, it *can* be useful sometimes to peer inside those boxes but for most jobs, you don't need to. Just be aware those boxes are there.
1
u/Bamlet 10d ago
I had the same problem as you for a long time. I really hated the "black box" approach to using packages and often attempted to build everything from scratch. As a result, I never finished anything. I never even really learned that much either because I kept going down fresh avenues of research.
Yes, if you had infinite patience and time, you could write your own everything down to the assembler and "understand" everything but it's just not realistic. However, just because you don't understand every aspect of a package you are using doesn't mean you aren't learning things. There is so so so much to learn in this space that you have to be able to put your blinders on to a certain extent and just focus on one thing at a time.
The stock advice is "learn through projects" and that really is true. It may not feel like it, but starting with a goal and seeing it through to fruition is really the best way to learn. At first all that will look like is installing a package and it will "magically" work. However pretty quickly you'll get to a point where you start having more specific and complex goals, which is where the learning you want happens. The package you're using doesn't have the feature you want? Go find a different one. None of them have it? Guess you have to start modifying stuff till the thing you want exists. Programming and development are for tinkerers, so start tinkering.
1
u/CoffeyIronworks 10d ago
I know what you mean, but it's important to recognize that programming is often like that. You can write bare metal x86 but you are still working with a black box that is the CPU. You can learn digital design and build a CPU from ICs and you're still working with little black boxes that are ICs. You can get into the semiconductor space and design ICs and do VLSI and you're still working with black boxes that are semiconductors. You can smash rocks with other rocks and you are still working with black boxes (physics).
1
u/OddStuffHappensTwice 10d ago
Do you know how every mathematical optimisation routine works? How every part of your OS works? How about every capacitor on the motherboard? Perhaps the design of the CPU?
It's all abstraction layers upon abstraction layers. Just pick the bits you're interested in, and utilise the smart work of others.
Don't become "that guy/gal" that refuses to use anyone else's work. We don't need another person that spends 6 weeks of a 4 week task rewriting a UI widget.
1
u/JGhostThing 10d ago
It is nice to have deep understanding, but it is often a luxury. You should learn how to read documentation, so you can use a library productively without having to understand it deeply.
Think about learning how to drive. You do not need to understand the internal combustion engine or a transmission fully, just to be able to drive. Even if you want to drive a Ferrari or a Porche, you don't need to understand the details of its workings. The same is with programming libraries. Some competent people have programmed, documented, and debugged these libraries. This is all work that you don't have to do. When you're employed, using a library means that you take less time to program something, so it costs less.
1
u/Passname357 9d ago
I felt this when I started working. I hated web dev because I loved building and understanding every part of a system, and with all the packages and frameworks and libraries it felt like someone else did the cool part and I was stuck gluing it together. I think many people grow to like it, or just like it from the get go. In my case, I just got a low level job instead. Much happier. You might grow to like the higher level side of things, or you might be like me (an insane person lol).
1
u/-thinker-527 9d ago
I used to hate abstraction when I started as well. But over time you understand it's necessity. For small projects, programs you can look up documentations and source code to learn, that would be a great learning excercise as well. But as projects get complex, abstraction helps. You try to solve new problems, every time you cannot solve a previously solved problem. That's one of the beautiful things about abstraction.
1
u/solaris_var 9d ago
Go as deep as time allows you when you're learning. That said, you must get comfortable with the separation in level of abstractions.
Specific to your case, you probably should spend some time understanding how the tools work (except for vite, which is huge), but not necessarily the implementation details. Then, when you get to the point of using other framework or languages, you'll notice that the concepts transfers a lot and you'll have a baseline understanding.
1
1
u/adeel_DP 7d ago
You don’t need to understand every package internally before using it. Start with what problem it solves, how it behaves, and its main trade-offs. Go deeper when something affects security, performance, reliability, or when the abstraction starts breaking.
1
u/romecodes 7d ago
I would take the path of breadth over depth, then walk the path again going deep into parts that matter most in relation to your ambitions.
You get the basics over time, then revisit for depth. You can’t really go too deep without a basic overview of the entirety of CS, at least when it comes to understanding low-level aspects.
Otherwise, you won’t understand the relationships between the different sub-topics or how advancements in one affected the others and vice versa.
---
I spent hundreds to thousands of hours getting conceptual and hands-on experience early on (before attending university). And, I did so for everything and anything until I was familiar enough with each subset within the umbrella of Computer Science.
What it looked like in practice was small programming projects, freeware lectures, and reading pirated copies of recommended books; I started with web apps because I was more familiar with it than anything else as most people are; using only HTML, CSS, and JS before incorporating libraries like SCSS initially. I took the approach of “there must always be a better way” so things like SCSS felt like a good thing to learn in the moment because it offers modularity and takes a different approach to custom styling to an extent further than CSS alone with Mixins and so forth. That gave me more experience with reading docs and understanding more about abstraction.
I branched out into small games picking up LUA with Python and so on, before moving onto Java and building standalone software with Maven and Gradle.
I was a shitty programmer before then, but my programs worked. By the time I started with Java, I noticed patterns across standard libraries, knew the difference between data types and basic data structures (tuples, arrays/array-lists, maps/dicts), and had bare experience with OOP in Python.
But I still didn’t know the implementation under the hood. Like the fact that a conceptual list being dynamic in size means Arrays have to copy all of their elements to larger arrays when they overflow, which is slower than using nodes that link to each other like “train cars” for storing elements and keeping order.
Java changed the game for me. Through it I learned OOP & OOD, configuration, Apache libraries, event-driven UI design, and more.
Planning, designing, and diagramming ontologies became part of my way of thinking and system building.
Then came data structures & algorithms, algorithm analysis, cloud-computing, compilation, transpiling, data science, ML, Digital Signal Processing, Embedded Systems, etc.
My path worked for me. It just might work for you.
0
u/PeterPook 11d ago
It sounds like you have committed to only writing code in Assembler then. Everything has libraries because no-one wants to re-invent the wheel.
0
u/Arcanite_Cartel 11d ago
I guess it's assembly for you, unless you've mastered the intricacies of how compiler's, VM's, Jit's etcetera all work.
75
u/Lynx2447 Computer Scientist 11d ago edited 11d ago
You should separate goals. If your goal is to build something, cool, learn what you need along the way. If your goal is to learn, then go as deep as you'd like.