7 ms·

Of course C doesn't "explain" how things work. C is a language, it doesn't explain anything. However, when you write and read real-life C code, you have a chanc

by eliben 14y ago

Of course C doesn't "explain" how things work. C is a language, it doesn't explain anything. However, when you write and read real-life C code, you have a chance to learn how software works under the hood much better than with higher-level languages. The low-level rigid type system makes you see how data structures are really laid out. Pointers and direct memory addressing makes you realize how memory is really managed, the real meaning of passing things by value and by reference, and many more things.

RodgerTheGreat 14y ago
What if I want to know how registers are used and allocated in a program? Most C compilers ignore "register" annotations, and with good reason- they hamstring the compiler's ability to optimize, which is usually a completely opaque process from the programmer's point of view in the first place. Why have a type system that includes implicit coercions between types, sometimes with different internal representations? (Just imagine an int promoting to a float.) Doesn't that obscure the "real meaning" of the program, or is it merely a detail you find uninteresting? C is not the only language that makes these low-level concepts accessible, and C does not represent the "floor" with respect to making the behavior of hardware explicit. If what you're actually getting at is that C is the most popular language today that exposes all of those things, it sounds less convincing- Systems languages cannot advance if we take C's position as given.
- swordswinger12 14y ago
  Having really bizarre type conversions can allow for brilliant code in some cases - the Quake fast inverse sqrt function contains a float->int coercion, iirc.
- quesera 14y ago
  You're right, C is the most popular language with the least amount of magic between you and assembly. It's a useful balance of abstractions on top of assembly without a total loss of the processor model. This isn't less convincing to me, I would never argue that someone learn C instead of all other languages. But I do believe that knowing C makes you a better programmer in all (current popular production) languages. Re: your point about systems programming not advancing...I didn't mean to imply that C was "perfect" (in the Latin sense, meaning "done, finished"), just that it's the best we have for many things. I do really like Go, and wish I could use it more, for non-personal projects.
mccoyst 14y ago
"low-level rigid type system" You've never written C.
- eliben 14y ago
  Hmm... right, it was something with a C in it, but not sure what! Come on! Don't you have a constructive comment?
stonemetal 14y ago
However, when you write and read real-life C code, you have a chance to learn how software works under the hood much better than with higher-level languages. getchar(); //C STDIN.getc //Ruby getChar //Haskell System.in.read(); //java How do any of those show me how software works under the hood? In none of them do I have any clue how a character makes it from my terminal to my program. int* a; Teaches me nothing about caches, memory latency, NUMA etc. Hell, dereferences are even guarantied to read the same physical location in memory(just the same logical location.) struct stuff{ int a; int b; }; Doesn't teach me anything about memory layout. C assumes you are running on some hardware from the 70s, it doesn't know about virtual memory, address spaces, memory pages, NUMA, ram with multiple channels, the no execute bit, GPGPU programming. The only thing C has going for it is simplicity.
- kabdib 14y ago
  > The only thing C has going for it is simplicity. But it's an interesting /kind/ of simplicity. FORTRAN is simple, for instance. Yet we don't use it much any more. C is simple enough to not make you go bananas trying to learn the language [C++], but rich enough that you don't go bananas solving large, interesting problems [assembly]. It pretty much nailed the uncanny valley of just complex enough. It's a bit creaky. It desperately needs namespaces. I'm on the fence about memory models (this is a platform thing, in my mind), and definitely Do Not Want threads jammed into the language. I would love a decent macro language, but that's probably a decade-long debate (if what happened in the Scheme community is any indication). I would love a compilation system that didn't suck [yes, macros and a Go-like build system probably don't mix well]. I've been writing C for over 30 years. I plan to keep writing it for another 20. The unscientific, neat thing about C is that it's /fun/. I know this doesn't go over well with standards types and cow-orkers who feel the urge to override operator = and take dependencies on Koenig lookup all the time, but C has a charm that other, similar languages have been unable to capture.
  - gaius 14y ago
    FORTRAN is simple, for instance. Yet we don't use it much any more. Computing is like an iceberg, with the web being the bit above the surface. rich enough that you don't go bananas solving large, interesting problems [assembly] Two words: macro assembler. It may surprise you to know that not that long ago, sophisticated GUI apps were written in assembly language (in fact the IDE I use on my ST, Devpac, was written in assembly, and it's everything you would expect of a modern IDE - editor, compiler, debugger, etc - running under GEM). Many games were written in pure ASM.

by eliben 14y ago

RodgerTheGreat 14y ago

What if I want to know how registers are used and allocated in a program? Most C compilers ignore "register" annotations, and with good reason- they hamstring the compiler's ability to optimize, which is usually a completely opaque process from the programmer's point of view in the first place. Why have a type system that includes implicit coercions between types, sometimes with different internal representations? (Just imagine an int promoting to a float.) Doesn't that obscure the "real meaning" of the program, or is it merely a detail you find uninteresting? C is not the only language that makes these low-level concepts accessible, and C does not represent the "floor" with respect to making the behavior of hardware explicit. If what you're actually getting at is that C is the most popular language today that exposes all of those things, it sounds less convincing- Systems languages cannot advance if we take C's position as given.

swordswinger12 14y ago
Having really bizarre type conversions can allow for brilliant code in some cases - the Quake fast inverse sqrt function contains a float->int coercion, iirc.
quesera 14y ago
You're right, C is the most popular language with the least amount of magic between you and assembly. It's a useful balance of abstractions on top of assembly without a total loss of the processor model. This isn't less convincing to me, I would never argue that someone learn C instead of all other languages. But I do believe that knowing C makes you a better programmer in all (current popular production) languages. Re: your point about systems programming not advancing...I didn't mean to imply that C was "perfect" (in the Latin sense, meaning "done, finished"), just that it's the best we have for many things. I do really like Go, and wish I could use it more, for non-personal projects.

mccoyst 14y ago

"low-level rigid type system" You've never written C.

eliben 14y ago
Hmm... right, it was something with a C in it, but not sure what! Come on! Don't you have a constructive comment?

stonemetal 14y ago

However, when you write and read real-life C code, you have a chance to learn how software works under the hood much better than with higher-level languages. getchar(); //C STDIN.getc //Ruby getChar //Haskell System.in.read(); //java How do any of those show me how software works under the hood? In none of them do I have any clue how a character makes it from my terminal to my program. int* a; Teaches me nothing about caches, memory latency, NUMA etc. Hell, dereferences are even guarantied to read the same physical location in memory(just the same logical location.) struct stuff{ int a; int b; }; Doesn't teach me anything about memory layout. C assumes you are running on some hardware from the 70s, it doesn't know about virtual memory, address spaces, memory pages, NUMA, ram with multiple channels, the no execute bit, GPGPU programming. The only thing C has going for it is simplicity.

kabdib 14y ago
> The only thing C has going for it is simplicity. But it's an interesting /kind/ of simplicity. FORTRAN is simple, for instance. Yet we don't use it much any more. C is simple enough to not make you go bananas trying to learn the language [C++], but rich enough that you don't go bananas solving large, interesting problems [assembly]. It pretty much nailed the uncanny valley of just complex enough. It's a bit creaky. It desperately needs namespaces. I'm on the fence about memory models (this is a platform thing, in my mind), and definitely Do Not Want threads jammed into the language. I would love a decent macro language, but that's probably a decade-long debate (if what happened in the Scheme community is any indication). I would love a compilation system that didn't suck [yes, macros and a Go-like build system probably don't mix well]. I've been writing C for over 30 years. I plan to keep writing it for another 20. The unscientific, neat thing about C is that it's /fun/. I know this doesn't go over well with standards types and cow-orkers who feel the urge to override operator = and take dependencies on Koenig lookup all the time, but C has a charm that other, similar languages have been unable to capture.
- gaius 14y ago
  FORTRAN is simple, for instance. Yet we don't use it much any more. Computing is like an iceberg, with the web being the bit above the surface. rich enough that you don't go bananas solving large, interesting problems [assembly] Two words: macro assembler. It may surprise you to know that not that long ago, sophisticated GUI apps were written in assembly language (in fact the IDE I use on my ST, Devpac, was written in assembly, and it's everything you would expect of a modern IDE - editor, compiler, debugger, etc - running under GEM). Many games were written in pure ASM.