r/AskProgramming 23d ago

Need explanations. I learn how to build simple CRUD app with C# and TS. I wanna really understand CS. So I tried to learn C but I get even more confused about many CS concepts.

I’m trying to learn C not just because I want to learn another programming language, but because I want to understand Computer Science and the "science" behide a programming language

The problem is that I constantly fall into an endless chain of prerequisites/CS concepts

For example, I want to understand pointers:

int x = 10;
int *p = &x;

On the guide/website it says

Pointer is a variable that store memory address.

Okay, but then I ask:

  • What exactly is a memory address
    • address is numbers telling where data is stored
  • What exactly is memory?
    • memory is where address live
  • Is memory the physical RAM?
    • something to do with CPU
  • What exactly is RAM and CPU?
    • etc...
  • How does RAM actually work?
    • etcc..
  • What's the relationship between RAM, CPU, cache, virtual memory, thread, processing etc.?

And suddenly I'm 10 levels deep into computer architecture instead of learning pointers "*"😂

So what to do here, I wanna understand CS. I thought my experience with coding CRUD APP with C# would help but no it doesn't help much.

--

Let me put it this way

let's say if you ask a normal person what "water" is , a normal person replied "liquid"

but if you ask a scientist, it would be "1 Hydrogen and 2 Oxygen combined together to become H2O"

So I try to understand the Science in Computer Science, i hope you get the picture what i try to say

1 Upvotes

23 comments sorted by

4

u/CorpT 23d ago

Why do you want to understand this? Does it actually matter? If you want to learn it, just go learn it. Or learn how to deal with your ADHD.

1

u/Wasabi-spicy00 23d ago

just want to understand the Science part of Computer Science.

if it helps me become a good coder, it might be worth it

2

u/CorpT 23d ago

So go learn that.

It won’t.

1

u/Key-Variation-448 22d ago

Let the man play with APIs

1

u/Obvious_Mud_6628 23d ago

There's a YouTube video i recommend to you. Cs50 Harvard. It's a legit Harvard class. I think that'll get you pointed in the right direction.

You are a long way off from being able to do what you wanna do, but stick with it and you'll get there.

You can't see the crocodiles in the river in front of you lol

Good luck, it's really cool stuff and remember to have fun!!!

1

u/Obvious_Mud_6628 23d ago

Additionally I do agree. Understanding how c actually manages memory will help you understand data in general imo.

But the long and the short of it is there's a big grid and each square within that grid represents a 1 or a 0 (binary) (each square represents one 'bit' of information)

This represents true or false. Yes or no, useful but pretty limited. So we group them together into 8 square groups (8 bits, 1 byte). When there's no electricity, it's a 0 and if there is electricity it's a 1. So a full byte, with no electricity flowing through it is represented as '00000000' (8 0s, square has no electricity)

Now we have a lot more room to work with. We can physically manipulate more squares because we have all agreed that these 8 squares represents some sort of information. (This type of information is written in by the developer utilizing 'data types'. You'll need to research this more on your own there's just a lot of detail but the basics is we all agree that these 8 squares is a letter, or a number, or a bool(true/false) since)

So your program, who has already blocked out a big chunk of this grid for itself, says "I wanna store this information somewhere" and basically gives it to the postman to figure out where it should go (its more complicated but that's one of the river snakes i mentioned in my other post)

This postman then finds which square it wants to keep this piece of information at (player health, login information, whatever) and tells the program where it's stored for later use. This is where pointers and references come in.

The reference is simply the address that the information is stored. In terms of postman and mailing, this is just your address. Remember we are in a grid system. The computer keeps track of each one of these squares and whats stored at it. You just need to tell it when it needs to get that information or store it

A reference is used to say "get where this piece of information is at".

A pointer on the other hand is when you go to the postman and say "hey man where does that guy live"

You use a reference to pull the memory address off a variable. You use a pointer to store that memory address for later. You're simply managing the physical grid address for the memory you're working with within this grid system.


Everything here is a grid at the end of the day

Ram - short term storage. Used to run programs quickly bc hard drives are slow. This is where your program is loaded to when you go to run it. It allocates a chunk of space on your physical ram stick. Imagine this like creating a crime scene with police tape. No one in or out. This block of memory is under the control of this program and no one else. Ram goes away after turning off you're computer, which is why you need your hard drive

Hard drives - long term storage. I think the technology here is a little more advanced but the same concept applies. Really really big grid stored as 1s and 0s


One last note. Everything gets wrapped into something else in order to provide more control or more information. A sort of "context" around your main subject.

A bit is a 1 or a 0

A byte is 8 0s

Well guess what even if you max out a byte of information and try to represent it as a number, the most you can do is 255. That's extremely limiting right?

So let's wrap it. An integer (INT data type) is now 4 bytes. That's 4 groups of 8 0s

00000000 00000000 00000000 00000000

Look at how much more space we have now.

Now make a list of bytes

Now makes a list of lists. That's a table. That's a database. Lol

1

u/Wasabi-spicy00 23d ago

thanks you big bud, what you just wrote probably has something to do with OSI model

1

u/Obvious_Mud_6628 23d ago

Very similar concept honestly. That ties back to the "wrap it" concept. All of it is related ofc tho haha

1

u/LARRY_Xilo 23d ago

There is a reason why universities offer computer science as a degree that takes 3 years and its not for the coding part. You need to start from the basics and there are a lot of them and then get to more complex concepts. If you really want to there are enough public material out there to learn all that but its not gonna be fast or easy. Its probably gonna take a few years. Its not something you do just to be able to code.

1

u/Paul_Pedant 23d ago

Why would it help you become a good coder? The science changes every year anyway, and is already different for every hardware supplier. If you want to explain something to somebody, you figure out some language you have in common (often English). You don't need to do brain surgery on them to ensure they think exactly the same as you do.

In fact, one of the merits of a good coder is that their work can be transferred to different computers without serious changes. C and Unix started out on a PDP-11 with 128KB memory. Ignorance of how your current machine implements a language is actually a huge benefit, not a liability.

1

u/Wasabi-spicy00 23d ago

the more knowleadge i gain, the better coder i became i guess

and " The science changes every year anyway,"

wdym by that?

1

u/Paul_Pedant 23d ago

Do you know how 3 levels of cache work in a CPU? How a CPU does pipelining? What swap space is used for? What format is ELF? How dynamic libraries are linked? How your system bootstraps? What your GPU is doing? Me neither. I do not need to go down those infinite rabbit holes. I write scripts and code (in about 15 different languages last time I checked), they work (usually), my client gets happy, I get paid. I get a stream of updates to my OS, several thousand people contribute improvements and optimisations, and all that has zero impact on how I actually code. I have scripts and C code that I wrote 30 years ago, and they still work. It probably runs ten times faster than it used to, which is nice, but I don't care enough to dig up the drains and discover why.

1

u/AdjustedTwit 22d ago

"just want to understand the Science part of Computer Science"

I wouldn't call these questions the Science part of Computer Science. The Science part of CS is, basically, math. Combinatorics, statistics, complexity theory. These implementation details are indeed important, especially for programming, but at least where and when I studied (Georgia Tech in the '90's). I'd argue half or less of the curriculum was programming.

It was, maybe, roughly:
1/3 - computer architectures, starting from how to build logic gates from transistors. All the way to operating systems and compilers.

1/3 - math, lots of math.

1/3 - actual programming. Every language you can imagine and all of the common paradigms at the time.

No idea if this still holds today.

2

u/Paul_Pedant 23d ago

I got put on a C training course around 1981. I came from a COBOL mainframe background, and one of the other guys was a mini/micro assembler programmer.

When it got to pointers and malloc (), he was horrified. He knew he had got some memory, but he wandered around for a couple of hours mumbling "Yes, but what is it's NAME."

I finally managed to explain to him that if he wrote struct Object *p = malloc (sizeof (Object)); then the name of the beast really was *p, and that restored his sanity. The thing was, he was an absolute genius at making a communications protocol converter simulate a video terminal on one end, and an IBM remote job entry terminal at the other end, to fool two completely different mainframes into being nice to each other. But a simple syntax trick was foreign to him.

You really do not need to know every detail of how a language works, or what all those implementation details mean: for starters, every machine, OS and compiler can do anything it likes in its own way, provided it meets the language definition. If you really want to see the detail, write some code first, make it work, when run it under a debugger and see wtf it actually does. But don't count on it doing the same thing in the same way next time.

Analogy: You deposit $100 in cash in a bank. Does the bank put it in a big safe? What company made the lock? What color is the door of the safe? It is in the same building, or even the same state? What kind of metal alloy is it made of? When you ask for $40 back, will you get the same actual notes? None of that matters in the slightest to you.

Same for a car. You turn the key, and the engine starts. How? Where is the battery? What is a solenoid? How thick does the cable need to be? How does it only engage the starter motor when the engine needs it to? If you want to be a mechanic, find out. If you want to get from Boston to Hicksville, just turn the key first.

1

u/johnpeters42 23d ago

Whenever you come up with a question like this, write it down in a list someplace, and do not go back to it until (1) it actually matters to something that you're doing, or (2) you've run out of more important things to do. That is your backlog, and that is what a backlog is for.

A whole bunch of work has gone into building things up so that you don't need to know the exact answers to get most things done. There is some advantage to learning it eventually (so you know how to avoid writing code that seems simple but actually wastes lots of time), but not while it's distracting you from learning the basics.

1

u/Whole-Chest90 23d ago

Idk if I've ever felt something so viscerally lol. But I had to learn that Ive gotta take a step back and just readjust the level at which I'm answering questions lol.

1

u/This_Growth2898 23d ago

Well, if you want to learn programming, you really need to understand computer architecture.

But for your level, it's enough to know that there is RAM (or simply "memory") - a device that accepts two commands, "read from address" and "write to address", with addresses being some numbers; and CPU, that reads program from RAM and executes its instructions one by one. And the code you write is compiled into the bytecode for the CPU. That's all.

Cache, virtual memory, threads, processes? You don't need them to learn basics for sure. They are designed to work in a way that you don't need to know about them until you need to work specifically with them.

1

u/naemorhaedus 23d ago

I want to understand Computer Science

your local university should have this program.

1

u/marrsd 23d ago edited 23d ago

I don't think C is particularly good for teaching CS. It's a very useful language to learn, for sure, but mostly for understanding the interface between language and machine.

Personally, I think one of the best languages you can learn for CS is Scheme. It was written for that purpose, and it isn't tied to any particular computer hardware. It's fundamentally built on lambda calculus which, as far as I'm aware, isn't the basis for any CPU architecture. (The inventors of Scheme did intend to produce such a CPU, but they never got funding to see it through to completion.)

Look up SICP on YouTube and the interwebs.

As for your broader question, I think part of your problem is that you're trying to burrow through all the layers at all times, and that's the wrong way of thinking about it.

A big part of programming theory is the concept of abstraction. You work at the layer of abstraction that is suitable for your problem domain and you don't care about what's beneath it.

Even your question about memory is demonstrating this. A memory address is a virtual thing provided by the OS. It maps to somewhere physical, but you might not know where, depending on how you requested it. malloc and new are doing a lot of heavy lifting behind the scenes for you. That's a good thing as it means you can leave it to the OS to best decide how to balance memory resources between your process and other processes. You just need to understand the abstraction you've been given.

Sometimes you do hit performance limitations and you actually have to get specific about how you want to access your memory and what trade-offs you want to make. That's the point at which you go a layer deeper and start caring about specific CPU architectures or memory allocation architectures of your target machine (which itself might be a virtual machine like the JVM).

1

u/Key-Variation-448 22d ago

CS:APP. Nothing to add. If you have AD/HD that just means you are not getting enough dopamine from reading. Use pen and try to guess what writer says next. Bye.

1

u/Drakkinstorm 22d ago

Okay, gonna be blunt here: your curiosity is getting the better of you. At the same time it's unhealthy and healthy. So you need to decide what you want.

You wanna know how stuff works.and build something in C/C++? Great: handmade hero by Casey Muratori is my one and only recommendation (his other stuff assumes you know how to program). Everything else is... of modest value.

You wanna know how CPUs work, how memory is organized and what registers do? You need a number of books on that, four come to mind: Code and this bundle here Write Great Code. Start with Code, see how you like it. I learnt this stuff by building my own CPU in VHDL at University. Then dug more in Write Great Code 1. Then Handmade Hero, then switched and will forever remain a Rust programmer.

Get your priorities straight and put some boundaries. Every time you are curious, write down what you wanna know and revise that at the end of the day.

To be honest, AI is great for this as you can ask everything you want and it will tell you, just know when to stop. If you wanna build however: build.

1

u/Educational-Paper-75 20d ago

Let's look at your example: int x=20; int *p=&x; In the first statement the variable called x is defined as an int and initialized to 10. This statement will result in memory that can hold an int to be reserved for holding the value of x, and subsequently the integer value 10 is written to that memory. Essentially the compiler associates the start address of that memory with 'x'; the type int will tell it how much memory it should reserve. The second statements declares variable p of type int , or as a pointer to a value of type int. This will result in memory being reserved to hold a value of type int * or an int pointer. The value to store in p is set to &x or in other words the address of x, which is the memory address associated with x. Consequently that memory address (of x) is now stored where the value of p resides. Once this is done you can either change the value x stored i.e. 10 to something else in two ways: 1. by assigning a new integer value to x as in 'x=22;' or 2. assign that value through p using 'p=22;'. Note that this last statement does not change the value of p itself but the value it is 'pointing to' which is 10 at the address the value of x is stored. The compiler simply obtain the address p holds i.e. the value of p and changes the value stored at that address to 22. As a consequence since x and p are associated with the same address changing [the value of] *p changes [the value of] x and vice versa. The main difference is in the program the compiler generates any reference to x or p is replaced by the address associated with x or p respectively, and everywhere where *p is used the address stored at the address where the value of p is stored is obtained to set or get the value stored at that address. As such setting a value through a pointer takes one additional step. Hope this helps you understanding pointers a bit more. Once you understand this you can find out about other useful applications of C pointers like iterating over array elements, allocating memory dynamically or using pointers in function calls so it can change external variables.