07 Dec, 2011, Tyche wrote in the 21st comment:
Votes: 0
Rarva.Riendf said:
…most of the OS are themselves in C for a reason, it is the humaly readable langage that is closer to it.


There are two reasons that C is often used today to write an OS.
1) It's popular and has a large programmer base.
2) Competition has created compilers that produce very well optimized code.

The language isn't in any way, shape, or form "closer to how a computer works" than Pascal, COBOL, Fortran, BASIC, C++, LISP, PL/I, PL/M, Modula-2, Oberon, Forth, Smalltalk or the whole host of other high level languages that have been used to write operating systems.
07 Dec, 2011, Rarva.Riendf wrote in the 22nd comment:
Votes: 0
Quote
Again, as an example, if you are trying to write high-performance software that works with large amounts of data, not understanding the caching and paging models of the OS can kill you even if you think you're "right at machine level" with C – you really are not, and that's not really in question. There are things happening that you simply aren't controlling.

I dont know why you raise the OS in this when I am talking about how the computer works. Yes the OS makes a lot of stuff you sometimes wish it did not, but an OS is not a computer, it is another program. And since you are talking about that, it is definitely more difficult to change the behaviour of a program to use cpu cache in a higher langage than C. (not impossible, just more hidden since it is not a natural thing for those langage to get closer to the hardware implemetnation)


For Tyche:when you type malloc , it means you reserved some memory, somewhere on your physical hardware. And you have the adress right away, and it is easy to write in it as the langage itself does not a lot more than that.
String manipulation in a higher level langage like JAVA C# or RUBY shows how much you are disconnected of the hardware compared to C. You dont care about putting a 10char len String in your variable then a 50char then 30.
Anyway thats my pov, confirmed by experience in 10 years of works in IT: most people who went straight to JAVA or C# understand shit why their code is bloated and leaking memory…
07 Dec, 2011, quixadhal wrote in the 23rd comment:
Votes: 0
Rarva.Riendf said:
For Tyche:when you type malloc , it means you reserved some memory, somewhere on your physical hardware. And you have the adress right away, and it is easy to write in it as the langage itself does not a lot more than that.


Well, not really.

What you have is a virtual address that points to the segment of memory the OS has allocated to you as "your address space". It might be in RAM, it might be on a disk file via swap, it might even be on another machine via memory mapped I/O. From the point of view of your C code, you don't know.

Now, if you are writing your own kernel, then yes… you can perhaps say that (*53280) = 15; will indeed place that bit pattern into that memory address. However, for that to be true, you not only need to be in a kernel module, but that module needs to put the CPU into REAL mode, since otherwise the MMU may still remap your address space.

Keywords like "register" are only hints to the compiler to maybe put this in a CPU register if one is available. The only thing C really does that higher-level langauges like Ruby/Perl/etc don't do, is expose pointers to arbitrary memory addresses. How that is useful to someone coding a MUD is not clear to me.
07 Dec, 2011, David Haley wrote in the 24th comment:
Votes: 0
Quote
I dont know why you raise the OS in this when I am talking about how the computer works. Yes the OS makes a lot of stuff you sometimes wish it did not, but an OS is not a computer, it is another program.

But the OS is the fundamental layer for accessing "the computer". And if you're talking about "the computer" but not the OS, and you don't want to talk about the actual hardware, it's unclear what you are talking about.

Quote
For Tyche:when you type malloc , it means you reserved some memory, somewhere on your physical hardware

No… I'm beginning to understand why you think that C is so close to "the computer" – it's because you don't know what C is doing!

malloc doesn't reserve memory on the physical hardware at all. malloc is a library that wraps around the operating system (yes… the OS) calls to get virtual memory. It might, or might not, allocate memory on disk, in RAM, or wherever the OS feels like putting it.

Furthermore, the address that you have is not at all a physical memory address. It's a virtual memory address. Oh, yes, virtual memory is managed by the OS.

Quote
Anyway thats my pov, confirmed by experience in 10 years of works in IT: most people who went straight to JAVA or C# understand shit why their code is bloated and leaking memory…

And this is an entirely different statement from "C is closer to the computer". You could make the case that it's because C forces you to think about things that Java/C# don't.

(BTW, Java and Ruby are not acronyms.)
07 Dec, 2011, Runter wrote in the 25th comment:
Votes: 0
Mmm, yeah. I think making the case that C gives you any type of insight to hardware mechanics is going to be a tough one. It's much more reasonable to say that C gives you more access to low level concepts which may put your Computer-Math skills to work. Like shuffling and dealing with actual bytes and bits, often. But it's really not indicative of dealing with hardware or even OS level code. As Tyche pointed out, the portability itself is proof of how vastly different operating systems and hardware can all use C.
07 Dec, 2011, Tyche wrote in the 26th comment:
Votes: 0
Rarva.Riendf said:
I dont know why you raise the OS in this when I am talking about how the computer works.


Because it is the role of the operating system to establish the processor mode and handle the exceptions thrown by the memory management unit. So is learning C really helpful at all in understanding how a computer works? No.

Rarva.Riendf said:
It is definitely more difficult to change the behaviour of a program to use cpu cache in a higher langage than C.


How code is generated and whether it is optimized for cache access or not is implementation dependent in C. It is under the control of the compiler authors who produce the machine code your compiler generates. This is the same for C as it is for Fortran, COBOL, Pascal, LISP, and pretty much any compiled language.
Writing cache optimal code requires intimate familiarity with the processor and compiler. So is learning C really helpful at all in understanding how that part of a computer works? No.

Rarva.Riendf said:
For Tyche:when you type malloc , it means you reserved some memory, somewhere on your physical hardware.


It's a request to the operating system which could be anywhere (see above).

Rarva.Riendf said:
String manipulation in a higher level langage like JAVA C# or RUBY shows how much you are disconnected of the hardware compared to C.


String manipulation in C is a pretty good illustration of how disconnected C is from most processors.
07 Dec, 2011, David Haley wrote in the 27th comment:
Votes: 0
Hell must be freezing over if Tyche and I are agreeing… :smile:
07 Dec, 2011, Chris Bailey wrote in the 28th comment:
Votes: 0
S-oo-ooo cc-c-ool-dd in here.
07 Dec, 2011, Rarva.Riendf wrote in the 29th comment:
Votes: 0
Runter said:
As Tyche pointed out, the portability itself is proof of how vastly different operating systems and hardware can all use C.

Funny cause it is the best argument I could use as well, it shows how computer are all the same. Rest is about performance tuning because they are not made the same but the logic behind it is. All comes down to what I meant by how a computer works I guess. For me it works the same would he have 8 processors and 10 gig of ram and a ssd on linux, or a 68k with little ram where you can literally follow the flow of electricity between it and the memory to know where your value will be stored. And I feel C is better suited to force some of its logic on you, than any other langage. You all disagree, maybe I am wrong then, but my experience at work/school really led me to think that.
So there is no point in this converstation becaus eI am agreeing on what you are saying, just not on the final conclusion.
07 Dec, 2011, David Haley wrote in the 30th comment:
Votes: 0
Quote
All comes down to what I meant by how a computer works I guess. For me it works the same would he have 8 processors and 10 gig of ram and a ssd on linux, or a 68k with little ram where you can literally follow the flow of electricity between it and the memory to know where your value will be stored.

But this entire process is invisible with C. The OS takes care of it.
If something works the same in your language, no matter what the underlying hardware/OS/etc. is, then it seems rather clear that you are, in fact, not very close to those details because they are invisible to you. How, then, are you closer to understanding how they work?

I dunno where the communication impedance is here, if it is perhaps a language issue, but something is obviously not being communicated correctly.

I believe that what you are trying to say is that C forces you to think about details like your memory usage, memory layout, and so forth, whereas other languages hide that from you to a great extent. That's fair. But so far, it simply is not clear at all what is meant by seeing "how the computer works" given that you have explicitly thrown out the hardware, the OS, other libraries, etc. – nor how C helps you get there.
07 Dec, 2011, Rarva.Riendf wrote in the 31st comment:
Votes: 0
David Haley said:
That's fair. But so far, it simply is not clear at all what is meant by seeing "how the computer works" given that you have explicitly thrown out the hardware, the OS, other libraries, etc. – nor how C helps you get there.

It helps because all the tools you have and that most of the lower stuff is still written in C so you can escape userland a lot easier than you would with any other langage.
07 Dec, 2011, Kardon wrote in the 32nd comment:
Votes: 0
QBeAjISBb..."> QBeAjISBb..." type="application/x-shockwave-flash" width="425" height="350">
07 Dec, 2011, David Haley wrote in the 33rd comment:
Votes: 0
Rarva.Riendf said:
David Haley said:
That's fair. But so far, it simply is not clear at all what is meant by seeing "how the computer works" given that you have explicitly thrown out the hardware, the OS, other libraries, etc. – nor how C helps you get there.

It helps because all the tools you have and that most of the lower stuff is still written in C so you can escape userland a lot easier than you would with any other langage.

Not sure what you mean here. I have helloworld.c – what do I do to escape userland, and go see the source of those other tools and lower stuff?
07 Dec, 2011, Rarva.Riendf wrote in the 34th comment:
Votes: 0
David Haley said:
Rarva.Riendf said:
David Haley said:
That's fair. But so far, it simply is not clear at all what is meant by seeing "how the computer works" given that you have explicitly thrown out the hardware, the OS, other libraries, etc. – nor how C helps you get there.

It helps because all the tools you have and that most of the lower stuff is still written in C so you can escape userland a lot easier than you would with any other langage.

Not sure what you mean here. I have helloworld.c – what do I do to escape userland, and go see the source of those other tools and lower stuff?

With a simple Linux or bsd you compiled and run in debug mode nothing is hidden, and the fact that everything is in C means you will use the exact same tools, gdb valgrind your prefered editor to see how your program works, and how it interacts with everything else.
07 Dec, 2011, Runter wrote in the 35th comment:
Votes: 0
There's tools for every mainstream programming language to give you the same debugging capabilities… and many of them are higher level than C. I don't see what your point is here.
07 Dec, 2011, David Haley wrote in the 36th comment:
Votes: 0
Rarva said:
With a simple Linux or bsd you compiled and run in debug mode nothing is hidden

But we've already discussed very many things that are hidden. Plus, what Runter said – debuggers aren't exactly exclusive to the C world.
07 Dec, 2011, Vigud wrote in the 37th comment:
Votes: 0
What can Ruby teach you about endianness?
Sizes of pointer objects?
07 Dec, 2011, Rarva.Riendf wrote in the 38th comment:
Votes: 0
David Haley said:
Rarva said:
With a simple Linux or bsd you compiled and run in debug mode nothing is hidden

But we've already discussed very many things that are hidden.

I do not see what is hidden when you follow your code right through OS api/library whatever step by step.
07 Dec, 2011, David Haley wrote in the 39th comment:
Votes: 0
Vigud said:
What can Ruby teach you about endianness?

Endianness matters in any application sending raw binary to other applications over, say, a network.

Vigud said:
Sizes of pointer objects?

Pointers are a C abstraction, not a fundamental computer construct.

Rarva said:
I do not see what is hidden when you follow your code right through OS api/library whatever step by step.

Well, often, you don't have that source. And even if you did, you could inspect that source no matter what language you're starting from.

You might as well say that if you follow everything everywhere, you'll be able to understand everything. This seems tautological. :smile:
07 Dec, 2011, Rarva.Riendf wrote in the 40th comment:
Votes: 0
Quote
Well, often, you don't have that source. And even if you did, you could inspect that source no matter what language you're starting from.

Often you can have the source. And yeah I can look at a book in japanese when all I know is French and a little English. Sure gonna help….

I mean they have tool like this in C:
http://www.lemoda.net/c/cdecl/index.cgi?...

Never ever had even the idea of a need for one in any other higher level langage…
20.0/78