7 ms·

> precursor to studying kernels or databases or compilers While widely used kernels are still written in C, new ones are often not, and vast majority of new da

> precursor to studying kernels or databases or compilers While widely used kernels are still written in C, new ones are often not, and vast majority of new databases isn't either. Its java (Hadoop, Solr), Go (InfluxDB), Rust (Tikv) among others. That's if you want to be prepared for today. If you look into few years ahead, its also TLA+, Idris or Coq. Same for compilers, its increasingly rare to see anyone choosing C for that domain, especially as a language for teaching them. > Should schools be teaching C at all? I'd change this question to "should schools have any say in deciding what to teach?". Wouldn't be better to offer a list of options and let students do the market research and decide on their own? > It can be very informative to implement some of the features found in other languages in C That's not how programming works today. You are given those as language primitives and don't think about it same way you don't think how the hardware implements "if" in C. You may be curious and find some use for this knowledge if you have it, but its not very useful when you want to "teach C" (and its also very ephemeral).

notacoward 8y ago
I'm pretty sure the Linux kernel, BSD kernels, MySQL, Postgres, gcc, etc. will all be with us for quite a while. A few years ahead things won't be written in TLA+ or Coq because they're not even programming languages. Lamport is very explicit that TLAx is a specification language, and the central component of Coq (Galina) is too, so the name-dropping doesn't really make your case more convincing. C should definitely not be the only or even primary language people learn, but it's pretty critical to understanding how things work today and will continue to work for at least the next decade. > Wouldn't be better to offer a list of options I do believe I already said something like that. Yep, just checked. I did. The point is that, even if it's only an option, the question of how to teach it is still important. > That's not how programming works today. In your opposite-of-humble opinion, which is wrong. In fact, implementing things that are already pretty well known is exactly how programming is taught. Everywhere. In all languages. Students learn about pitfalls, and tradeoffs, and why "this" is easy/common but "that" is hard/rare. If you want to teach C, you have to teach C as it is used and why. A language is far more than just syntax you can learn from a book. Any student who has actually implemented a "basic language feature" in C is better equipped to understand how that implementation of that feature in a particular other language represents only one set of decisions within that space, and that others are possible. I'd say that's pretty important knowledge. Programmers who just settle for "it's magic" and "that's how it is" are never going to be very good programmers.
- fiedzia 8y ago
  > I'm pretty sure the Linux kernel, BSD kernels, MySQL, Postgres, gcc, etc. will all be with us for quite a while. Yes, they will exist and be used somewhere, but when people design a new database or compiler today, C is not the language of choice anymore, so teaching it for that reason is not useful. Many of the things I am using for storing data today have no line of C in them, same for a lot of research papers in that subject. > implementing things that are already pretty well known is exactly how programming is taught. I agree with that, just discussing what those things should be. Implementing low-level language features has more to do with hardware architecture than any code above it, and C is not good for representing (modern) hardware. The way it is done today is that you come up with some mental model, and instruct compiler to generate native code for that, and none of those need to involve C. LLVM IR or some equivalent is more likely to be used if you need some "C-like language". > Any student who has actually implemented a "basic language feature" in C is better equipped to understand how that implementation of that feature in a particular other language represents only one set of decisions within that space You don't need C for explaining that, just show two sets of decisions without any code. > Programmers who just settle for "it's magic" and "that's how it is" are never going to be very good programmers. It's not magic, but how exactly one feature or another was implemented changed many times for languages I am using because hardware changed, or more research was done, and besides gaining some performance I wouldn't notice any difference. Knowing how to use those features is important, practical and useful for many years, implementation details are irrelevant and may become outdated tomorrow (and they literaly did in many cases). C is still used, but nowhere as popular or relevant as it once was. It is not "the language of databases and compilers". If you want to teach it, focus on domains where it likely will be relevant, not the ones where it was relevant 20 years ago.
  - notacoward 8y ago
    > when people design a new database or compiler today, so teaching it for that reason is not useful Those who do not learn the lessons of the past are doomed to repeat it. Studying past and present highly-successful systems and understanding why they made the choices they did is not just useful but essential. > Implementing low-level language features has more to do with hardware architecture than any code above it, Untrue for the examples I gave. Most of what you would learn from implementing a map or regex parser is way above the hardware - sorting/searching, state machines, optimizing for different input sizes or patterns, managing mutability and concurrency. Implementing a simple object system is even less hardware-oriented. > C is not good for representing (modern) hardware. Perhaps not, but very few languages are better for that. Of the programming (and non-programming) languages you've mentioned so far, only Rust might be a tiny bit better in that particular regard. Go ahead, try to name a language that better represents hardware. Or don't, since representing the hardware is not the point anyway (see previous paragraph). Apparently some people think that anything below the web browser is hardware. > You don't need C for explaining that, just show two sets of decisions without any code. And here I think I see the crux of the problem. Have you ever programmed? If you have, or even if you've been engaged in some other kind of creative effort, you'd know that making something teaches lessons in ways that abstract thought can not. It's true that you don't particularly need C for that, but if you're teaching a class on C for other reasons it's kind of the obvious choice. "Without any code" is an absurd statement. > besides gaining some performance I wouldn't notice any difference. You wouldn't. The implementors would. The people who read the implementors' papers and use them as the basis for the next next system would. Even you, as a user, could benefit from understanding whether particular input or concurrency patterns represent best or worst cases for the algorithms that were used. You can't optimize your own code without that knowledge, and you can't have that knowledge without ever having worked on anything similar or even thought about it at any but the most superficial level. Your attitude is effectively "it's magic" even if you don't use the word. I think the most important point here is that people who haven't even educated themselves shouldn't be commenting on how to educate others. Would you like to Dunning-Krueger us some more?

notacoward 8y ago

I'm pretty sure the Linux kernel, BSD kernels, MySQL, Postgres, gcc, etc. will all be with us for quite a while. A few years ahead things won't be written in TLA+ or Coq because they're not even programming languages. Lamport is very explicit that TLAx is a specification language, and the central component of Coq (Galina) is too, so the name-dropping doesn't really make your case more convincing. C should definitely not be the only or even primary language people learn, but it's pretty critical to understanding how things work today and will continue to work for at least the next decade. > Wouldn't be better to offer a list of options I do believe I already said something like that. Yep, just checked. I did. The point is that, even if it's only an option, the question of how to teach it is still important. > That's not how programming works today. In your opposite-of-humble opinion, which is wrong. In fact, implementing things that are already pretty well known is exactly how programming is taught. Everywhere. In all languages. Students learn about pitfalls, and tradeoffs, and why "this" is easy/common but "that" is hard/rare. If you want to teach C, you have to teach C as it is used and why. A language is far more than just syntax you can learn from a book. Any student who has actually implemented a "basic language feature" in C is better equipped to understand how that implementation of that feature in a particular other language represents only one set of decisions within that space, and that others are possible. I'd say that's pretty important knowledge. Programmers who just settle for "it's magic" and "that's how it is" are never going to be very good programmers.

fiedzia 8y ago
> I'm pretty sure the Linux kernel, BSD kernels, MySQL, Postgres, gcc, etc. will all be with us for quite a while. Yes, they will exist and be used somewhere, but when people design a new database or compiler today, C is not the language of choice anymore, so teaching it for that reason is not useful. Many of the things I am using for storing data today have no line of C in them, same for a lot of research papers in that subject. > implementing things that are already pretty well known is exactly how programming is taught. I agree with that, just discussing what those things should be. Implementing low-level language features has more to do with hardware architecture than any code above it, and C is not good for representing (modern) hardware. The way it is done today is that you come up with some mental model, and instruct compiler to generate native code for that, and none of those need to involve C. LLVM IR or some equivalent is more likely to be used if you need some "C-like language". > Any student who has actually implemented a "basic language feature" in C is better equipped to understand how that implementation of that feature in a particular other language represents only one set of decisions within that space You don't need C for explaining that, just show two sets of decisions without any code. > Programmers who just settle for "it's magic" and "that's how it is" are never going to be very good programmers. It's not magic, but how exactly one feature or another was implemented changed many times for languages I am using because hardware changed, or more research was done, and besides gaining some performance I wouldn't notice any difference. Knowing how to use those features is important, practical and useful for many years, implementation details are irrelevant and may become outdated tomorrow (and they literaly did in many cases). C is still used, but nowhere as popular or relevant as it once was. It is not "the language of databases and compilers". If you want to teach it, focus on domains where it likely will be relevant, not the ones where it was relevant 20 years ago.
- notacoward 8y ago
  > when people design a new database or compiler today, so teaching it for that reason is not useful Those who do not learn the lessons of the past are doomed to repeat it. Studying past and present highly-successful systems and understanding why they made the choices they did is not just useful but essential. > Implementing low-level language features has more to do with hardware architecture than any code above it, Untrue for the examples I gave. Most of what you would learn from implementing a map or regex parser is way above the hardware - sorting/searching, state machines, optimizing for different input sizes or patterns, managing mutability and concurrency. Implementing a simple object system is even less hardware-oriented. > C is not good for representing (modern) hardware. Perhaps not, but very few languages are better for that. Of the programming (and non-programming) languages you've mentioned so far, only Rust might be a tiny bit better in that particular regard. Go ahead, try to name a language that better represents hardware. Or don't, since representing the hardware is not the point anyway (see previous paragraph). Apparently some people think that anything below the web browser is hardware. > You don't need C for explaining that, just show two sets of decisions without any code. And here I think I see the crux of the problem. Have you ever programmed? If you have, or even if you've been engaged in some other kind of creative effort, you'd know that making something teaches lessons in ways that abstract thought can not. It's true that you don't particularly need C for that, but if you're teaching a class on C for other reasons it's kind of the obvious choice. "Without any code" is an absurd statement. > besides gaining some performance I wouldn't notice any difference. You wouldn't. The implementors would. The people who read the implementors' papers and use them as the basis for the next next system would. Even you, as a user, could benefit from understanding whether particular input or concurrency patterns represent best or worst cases for the algorithms that were used. You can't optimize your own code without that knowledge, and you can't have that knowledge without ever having worked on anything similar or even thought about it at any but the most superficial level. Your attitude is effectively "it's magic" even if you don't use the word. I think the most important point here is that people who haven't even educated themselves shouldn't be commenting on how to educate others. Would you like to Dunning-Krueger us some more?