6 ms·

Because if you don't know C, you don't know what's actually happening when you write software. Because if you don't know C, you've only seen the map, not the t

by quesera 14y ago

Because if you don't know C, you don't know what's actually happening when you write software. Because if you don't know C, you've only seen the map, not the territory. Because if you don't know C, you're looking at the finger, not the moon. Because if you don't know C, everything you think about computers is a leaky abstraction. The counterpoint is that flawed models are often good enough. Newton's theory of gravitation comes to mind. But if you like knowing what's going on, either for personal satisfaction, or because what you're working on is not fully encapsulated by a different language (inevitably, originally, written in C), then C is both interesting and useful.

zxcdw 14y ago
Comments like these seem to have the underlying idea that C somehow explains how things work. It doesn't. It doesn't explain at all. It's only an abstraction among the others - granted, it's a lower level abstraction. To understand how a computer works when it executes a program, accesses some data, writes to a disk, spawns a process and forks it, then kills the child after a certain interrupt can pretty much only be learned by learning assembly and some hardware and OS-related literature. Of course, for most programmers(let alone people in general) this is nearly useless information today. It's obsolete. And that's good. But what C teaches you about how "things are under the hood", is just a leaky abstraction. C doesn't care about such low-level things because they are implementation details. Standard C could be ran by pen and paper just as well as on a computer. It's a "black box". Takes input and produces output according to the standard. Frankly, the only "low-level" thing C has over e.g. Java is that most domains in which C is used are working close to the hardware and it runs on "the real hard machine". With C, in it's modern domains, you are exposed to these "low-level" details, not because of C, but because of the domain. With many other languages the user doesn't have to deal with such problems because of the problem domain is different.
- 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.
- quesera 14y ago
  > To understand how a computer works when it executes a program, accesses some data, writes to a disk, spawns a process and forks it, then kills the child after a certain interrupt can pretty much only be learned by learning assembly and some hardware and OS-related literature. Well yes, but you're talking about library code there. Your code, which links in libraries, will never fully describe those libraries. But that library code was very likely written in C...so...
- dpeck 14y ago
  "Of course, for most programmers(let alone people in general) this is nearly useless information today. It's obsolete. And that's good." I'm not sure how you can say that knowledge of assembly/hardware is obsolete. Perhaps unneeded for tasks that most programmers have in our hip new ad-driven world, but someone still has to understand and write the code that runs the code that eventually puts the cat-based meme on your screen. Engineers seldom use calculus, but they used derived functions every day. The same applies to programming, everyone who programs should be exposed to the low level innards enough to at least take the magic away and have a basic concept of what a computer actually does. You'll be better for it.
- amcintyre 14y ago
  Of course, for most programmers(let alone people in general) this is nearly useless information today. It's obsolete. And that's good. Damn right it's good--for me--that most programmers think low-level programming/machine knowledge is obsolete. I'm pretty certain it means I'll never want for a (good) job as long as I can still think and move enough to edit code.
- haberman 14y ago
  > To understand how a computer works when it executes a program, accesses some data, writes to a disk, spawns a process and forks it, then kills the child after a certain interrupt can pretty much only be learned by learning assembly and some hardware and OS-related literature. That's funny, because 97% of the Linux kernel (the code that implements the things you mentioned) is written in C. I think you're getting confused by the fact that C has a standard library, so it's true that you don't have to write process spawning yourself. But the standard library is written mostly in C and calls into an OS that is written mostly in C. So C's computational model can indeed explain how low-level things work. The C standard even defines a "freestanding implementation," which is a C platform that has no access to an OS. So C-the-language can work without any OS at all, and without any runtime/interpreter that is filling the role of a traditional OS. Very few languages can say that, and indeed it's the reason why it makes sense to develop an OS in the language. To write an OS in a language that requires an OS begs the question.
  - philh 14y ago
    I personally learned a lot more about how computers work from assembly than from C. One example: C programmers talk about "the stack", but it's an implementation detail, you can learn C without knowing what the stack really is. Assembly will teach you. As for process spawning, I/O, etc.: it might be that C is just as good as assembly for those, but I would be surprised if either was sufficient. Presumably that's where "hardware and OS-related literature" comes in.
- agumonkey 14y ago
  I've seen a fair share of lispers and clojurians blogging about compiled assembly, cpu cycles and cache usage of their ludicrously high-level macro-expanded DSLs. As people said already, C semantics is closer to the metal but that's about it, it's just one small language (not insulting) It's not reality, even assembly isn't. In any language, doing full stack design will get you close to reality.
- aiscott 14y ago
  I agree, C doesn't itself explain "how things work." But I think the process of learning C can (but won't always) lead to a pretty good understanding of how things work. I'm admittedly not a very good programmer, but I love the ideas of programming, and it's probably my second best creative outlet. I just struggle with some of the higher level concepts... it seems the more abstraction that goes on, the harder I find it to understand. Closures, for example. Sometimes I think I understand them, and sometimes I don't. I work in hardware design, and perhaps it is only because it is what is familiar to me, but it seems to be a very concrete way of thinking. Certainly not just because it's physical, but that probably helps too. As far as programming, I think C and Assembly have to be my two favorite programming languages. By that I mean real C, not c++ or objective-c or whatever. And a "purer" form of assembly on simpler CPU designs. Assembly is great because the operations are so simple. Move, Load, Store, Add, etc... My problem solving has always been to take the problem and break it down into smaller problems, and Assembly seems to be an extreme view of that. Assembly is naturally close to the hardware. (Although how close varies with CPU design and can be argued in light of micro-ops, caching, out of order execution, etc...) Vanilla C translates so directly to Assembly, that if you know Assembly, it's easy to envision what Assembly could be generated by the code you are writing in C. If you have an understanding of the hardware involved, there just isn't very much mystery to C. As such, it can provide a springboard to understanding higher levels of abstraction.
RodgerTheGreat 14y ago
C is a leaky abstraction based on a simplified model of how computers and their memory worked in the 1970s. C code is transformed in complex and heavily context-dependent ways by all but the most primitive compilers before it hits metal, despite the popular opinion that "the language is close to the machine". If you like C, use it. If you want to know what's going on, learn assembly.
- quesera 14y ago
  You're conflating the language with its modern compilers on modern processor architectures, but I agree. My statements above were the iconoclastic and anachronistic version of reality, purposely so. If you know C, it is possible to comprehend a direct mapping of your "high level" code to a set of processor instructions. This is complicated by modern huge glib-style libraries and modern compiler optimizations, but it remains possible. That, combined with the fact that C is foundational in almost all current production languages, and remains highly useful among them, are why I think anyone who takes programming seriously should know C. Someone else compared C to Latin. Obviously C is more useful on its own than Latin, but the comparison is valid for the foundational aspect. Understanding threads and locking in C gets you a long way toward understanding those concepts in most popular languages. I'd make the same arguments for understanding Unix, by the way...and also that you can't really understand Unix without understanding C. And the converse.
  - dllthomas 14y ago
    > This is complicated by modern huge glib-style libraries and modern compiler optimizations, but it remains possible. I disagree. It's complicated by those things, but more importantly it's complicated by modern processor architectures, which do not execute one instruction after another anymore like C would have you believe - they just mostly pretend to. Which isn't to say this is any less true of the other high-level languages we have at hand, and I still think knowing C is valuable (although I'm wavering more on that then I was 5 years ago), I just think your characterization is incorrect.
    - deleted 14y ago
frou_dh 14y ago
Why can't this characterisation of "close-to-the-metal enlightenment" come from any language that surfaces your OS's SysCalls, along with an understanding of what compilers and assembly are? It's possible to understand the entirety of practical computation from top to bottom without C needing to be in your toolbox. Correct me if I'm wrong.
- quesera 14y ago
  Nope, you're right. But your "any language" almost certainly passes those syscall bindings through C to get there. Some languages are higher fidelity than others. However, C requires you to know more about how the compiler is going to turn your character string, say, or your looping construct, into assembly code. Some languages don't even have structs or pointers, or explicit memory allocation! You're laughing (I hope), but these are real things in memory, with only a thin layer of magic (layout, pointer math) in C...whereas they do exist in other languages, but are hidden -- usually pretty well, but rarely completely to the point where you are better off not knowing about them.
  - gaius 14y ago
    Not really. Using a for loop in C requires no more understanding than using a for loop in Python. As for character strings, what you need to know in C is the "gotchas" related to running off the end, in most cases the machine would be just as happy with a Pascal-style string[1] And for pointers, I'll leave you with http://en.wikipedia.org/wiki/Tony_Hoare#Quotations http://en.wikipedia.org/wiki/Tony_Hoare#Quotations [1] Tho' processors since the Z80 have instructions to help you deal with null-terminated strings...
  - frou_dh 14y ago
    I think Go, for example, performs syscalls directly. > However, C requires you to know more about how the compiler is going to turn your ... into assembly code. But does it really require (with emphasis)? The nature of some debugging and optimisation might push you towards that, but it's still a choice. I feel your point comes down to the use of C as a "vehicle" to learn low-level concepts. Which is fine, but someone can also just learn them directly (upfront or retroactively) and use whatever progression of languages they want.
gaius 14y ago
I could make exactly the same assertions about assembly language (I learnt 6502 when I was a kid, and dabble in 6502 and 68k these days for fun, keep meaning to learn ARM). Being able to reason at that level, and read generated ASM (x86 ugh) is an invaluable skill which I use daily, and it's a level below C. But, lines of assembly language professionally written: 0.
pjmlp 14y ago
There were computers before C existed, and there will be computers after C is long gone. If you really want to know how current computers work at low level, then Assembly is the only way. Everything else are higher level abstractions.
- bertomartin 14y ago
  But, you could probably use C as a stepping stone to Assembly...or just dip in whenever you need clarification on something.
drhowarddrfine 14y ago
If you know C, there's nothing you can't do.
to3m 14y ago
Hum. Unless what you're working with is translated into C, which is pretty rare these days, learning C won't tell you much that's of any use. The relationship between knowing C and writing good Python, say, is approximately 0. (The value may even be negative.) Same even goes for something like C# and Java. And in any event, the major influence on how efficiently code runs is the underlying CPU, not C. C is the same, no matter which CPU it's going to be compiled for; the resulting code, which is what actually gets run, will vary. `p[i]', where `int p[100]' is a global, is going to turn into something quite different when built for MIPS from what it would for x86. So what good is learning C? Well, if somebody will give you a job with it, and that job is well paid, then maybe it would be worth learning seriously... not sure how common this is these days, though.
- dllthomas 14y ago
  > So what good is learning C? Well, if somebody will give you a job with it, and that job is well paid, then maybe it would be worth learning seriously... not sure how common this is these days, though. Or if you want to hack at and/or understand parts of Linux or any of countless utilities.

by quesera 14y ago

zxcdw 14y ago

Comments like these seem to have the underlying idea that C somehow explains how things work. It doesn't. It doesn't explain at all. It's only an abstraction among the others - granted, it's a lower level abstraction. To understand how a computer works when it executes a program, accesses some data, writes to a disk, spawns a process and forks it, then kills the child after a certain interrupt can pretty much only be learned by learning assembly and some hardware and OS-related literature. Of course, for most programmers(let alone people in general) this is nearly useless information today. It's obsolete. And that's good. But what C teaches you about how "things are under the hood", is just a leaky abstraction. C doesn't care about such low-level things because they are implementation details. Standard C could be ran by pen and paper just as well as on a computer. It's a "black box". Takes input and produces output according to the standard. Frankly, the only "low-level" thing C has over e.g. Java is that most domains in which C is used are working close to the hardware and it runs on "the real hard machine". With C, in it's modern domains, you are exposed to these "low-level" details, not because of C, but because of the domain. With many other languages the user doesn't have to deal with such problems because of the problem domain is different.

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.
quesera 14y ago
> To understand how a computer works when it executes a program, accesses some data, writes to a disk, spawns a process and forks it, then kills the child after a certain interrupt can pretty much only be learned by learning assembly and some hardware and OS-related literature. Well yes, but you're talking about library code there. Your code, which links in libraries, will never fully describe those libraries. But that library code was very likely written in C...so...
dpeck 14y ago
"Of course, for most programmers(let alone people in general) this is nearly useless information today. It's obsolete. And that's good." I'm not sure how you can say that knowledge of assembly/hardware is obsolete. Perhaps unneeded for tasks that most programmers have in our hip new ad-driven world, but someone still has to understand and write the code that runs the code that eventually puts the cat-based meme on your screen. Engineers seldom use calculus, but they used derived functions every day. The same applies to programming, everyone who programs should be exposed to the low level innards enough to at least take the magic away and have a basic concept of what a computer actually does. You'll be better for it.
amcintyre 14y ago
Of course, for most programmers(let alone people in general) this is nearly useless information today. It's obsolete. And that's good. Damn right it's good--for me--that most programmers think low-level programming/machine knowledge is obsolete. I'm pretty certain it means I'll never want for a (good) job as long as I can still think and move enough to edit code.
haberman 14y ago
> To understand how a computer works when it executes a program, accesses some data, writes to a disk, spawns a process and forks it, then kills the child after a certain interrupt can pretty much only be learned by learning assembly and some hardware and OS-related literature. That's funny, because 97% of the Linux kernel (the code that implements the things you mentioned) is written in C. I think you're getting confused by the fact that C has a standard library, so it's true that you don't have to write process spawning yourself. But the standard library is written mostly in C and calls into an OS that is written mostly in C. So C's computational model can indeed explain how low-level things work. The C standard even defines a "freestanding implementation," which is a C platform that has no access to an OS. So C-the-language can work without any OS at all, and without any runtime/interpreter that is filling the role of a traditional OS. Very few languages can say that, and indeed it's the reason why it makes sense to develop an OS in the language. To write an OS in a language that requires an OS begs the question.
- philh 14y ago
  I personally learned a lot more about how computers work from assembly than from C. One example: C programmers talk about "the stack", but it's an implementation detail, you can learn C without knowing what the stack really is. Assembly will teach you. As for process spawning, I/O, etc.: it might be that C is just as good as assembly for those, but I would be surprised if either was sufficient. Presumably that's where "hardware and OS-related literature" comes in.
agumonkey 14y ago
I've seen a fair share of lispers and clojurians blogging about compiled assembly, cpu cycles and cache usage of their ludicrously high-level macro-expanded DSLs. As people said already, C semantics is closer to the metal but that's about it, it's just one small language (not insulting) It's not reality, even assembly isn't. In any language, doing full stack design will get you close to reality.
aiscott 14y ago
I agree, C doesn't itself explain "how things work." But I think the process of learning C can (but won't always) lead to a pretty good understanding of how things work. I'm admittedly not a very good programmer, but I love the ideas of programming, and it's probably my second best creative outlet. I just struggle with some of the higher level concepts... it seems the more abstraction that goes on, the harder I find it to understand. Closures, for example. Sometimes I think I understand them, and sometimes I don't. I work in hardware design, and perhaps it is only because it is what is familiar to me, but it seems to be a very concrete way of thinking. Certainly not just because it's physical, but that probably helps too. As far as programming, I think C and Assembly have to be my two favorite programming languages. By that I mean real C, not c++ or objective-c or whatever. And a "purer" form of assembly on simpler CPU designs. Assembly is great because the operations are so simple. Move, Load, Store, Add, etc... My problem solving has always been to take the problem and break it down into smaller problems, and Assembly seems to be an extreme view of that. Assembly is naturally close to the hardware. (Although how close varies with CPU design and can be argued in light of micro-ops, caching, out of order execution, etc...) Vanilla C translates so directly to Assembly, that if you know Assembly, it's easy to envision what Assembly could be generated by the code you are writing in C. If you have an understanding of the hardware involved, there just isn't very much mystery to C. As such, it can provide a springboard to understanding higher levels of abstraction.

RodgerTheGreat 14y ago

C is a leaky abstraction based on a simplified model of how computers and their memory worked in the 1970s. C code is transformed in complex and heavily context-dependent ways by all but the most primitive compilers before it hits metal, despite the popular opinion that "the language is close to the machine". If you like C, use it. If you want to know what's going on, learn assembly.

quesera 14y ago
You're conflating the language with its modern compilers on modern processor architectures, but I agree. My statements above were the iconoclastic and anachronistic version of reality, purposely so. If you know C, it is possible to comprehend a direct mapping of your "high level" code to a set of processor instructions. This is complicated by modern huge glib-style libraries and modern compiler optimizations, but it remains possible. That, combined with the fact that C is foundational in almost all current production languages, and remains highly useful among them, are why I think anyone who takes programming seriously should know C. Someone else compared C to Latin. Obviously C is more useful on its own than Latin, but the comparison is valid for the foundational aspect. Understanding threads and locking in C gets you a long way toward understanding those concepts in most popular languages. I'd make the same arguments for understanding Unix, by the way...and also that you can't really understand Unix without understanding C. And the converse.
- dllthomas 14y ago
  > This is complicated by modern huge glib-style libraries and modern compiler optimizations, but it remains possible. I disagree. It's complicated by those things, but more importantly it's complicated by modern processor architectures, which do not execute one instruction after another anymore like C would have you believe - they just mostly pretend to. Which isn't to say this is any less true of the other high-level languages we have at hand, and I still think knowing C is valuable (although I'm wavering more on that then I was 5 years ago), I just think your characterization is incorrect.
  - deleted 14y ago

frou_dh 14y ago

Why can't this characterisation of "close-to-the-metal enlightenment" come from any language that surfaces your OS's SysCalls, along with an understanding of what compilers and assembly are? It's possible to understand the entirety of practical computation from top to bottom without C needing to be in your toolbox. Correct me if I'm wrong.

quesera 14y ago
Nope, you're right. But your "any language" almost certainly passes those syscall bindings through C to get there. Some languages are higher fidelity than others. However, C requires you to know more about how the compiler is going to turn your character string, say, or your looping construct, into assembly code. Some languages don't even have structs or pointers, or explicit memory allocation! You're laughing (I hope), but these are real things in memory, with only a thin layer of magic (layout, pointer math) in C...whereas they do exist in other languages, but are hidden -- usually pretty well, but rarely completely to the point where you are better off not knowing about them.
- gaius 14y ago
  Not really. Using a for loop in C requires no more understanding than using a for loop in Python. As for character strings, what you need to know in C is the "gotchas" related to running off the end, in most cases the machine would be just as happy with a Pascal-style string[1] And for pointers, I'll leave you with http://en.wikipedia.org/wiki/Tony_Hoare#Quotations http://en.wikipedia.org/wiki/Tony_Hoare#Quotations [1] Tho' processors since the Z80 have instructions to help you deal with null-terminated strings...
- frou_dh 14y ago
  I think Go, for example, performs syscalls directly. > However, C requires you to know more about how the compiler is going to turn your ... into assembly code. But does it really require (with emphasis)? The nature of some debugging and optimisation might push you towards that, but it's still a choice. I feel your point comes down to the use of C as a "vehicle" to learn low-level concepts. Which is fine, but someone can also just learn them directly (upfront or retroactively) and use whatever progression of languages they want.

gaius 14y ago

I could make exactly the same assertions about assembly language (I learnt 6502 when I was a kid, and dabble in 6502 and 68k these days for fun, keep meaning to learn ARM). Being able to reason at that level, and read generated ASM (x86 ugh) is an invaluable skill which I use daily, and it's a level below C. But, lines of assembly language professionally written: 0.

pjmlp 14y ago

There were computers before C existed, and there will be computers after C is long gone. If you really want to know how current computers work at low level, then Assembly is the only way. Everything else are higher level abstractions.

bertomartin 14y ago
But, you could probably use C as a stepping stone to Assembly...or just dip in whenever you need clarification on something.

drhowarddrfine 14y ago

If you know C, there's nothing you can't do.

to3m 14y ago

Hum. Unless what you're working with is translated into C, which is pretty rare these days, learning C won't tell you much that's of any use. The relationship between knowing C and writing good Python, say, is approximately 0. (The value may even be negative.) Same even goes for something like C# and Java. And in any event, the major influence on how efficiently code runs is the underlying CPU, not C. C is the same, no matter which CPU it's going to be compiled for; the resulting code, which is what actually gets run, will vary. `p[i]', where `int p[100]' is a global, is going to turn into something quite different when built for MIPS from what it would for x86. So what good is learning C? Well, if somebody will give you a job with it, and that job is well paid, then maybe it would be worth learning seriously... not sure how common this is these days, though.

dllthomas 14y ago
> So what good is learning C? Well, if somebody will give you a job with it, and that job is well paid, then maybe it would be worth learning seriously... not sure how common this is these days, though. Or if you want to hack at and/or understand parts of Linux or any of countless utilities.