4 ms·

> 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 t

> 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?

fiedzia 8y ago
> Studying past highly-successful systems and understanding why they made the choices they did is not just useful but essential. Studying currently used and developed systems for people who will be designing future ones and enter job market in near future is more essential. Databases designed today are mainly distributed and knowledge of design choices made by Postgres doesn't help there, same as design choices made by whatever existed before Postgresql. > Most of what you would learn from implementing a map or regex parser is way above the hardware Ok, I agree with that. Although I am testing now hash implementation written using SIMD instructions. My main point here was however that while you see map and regex parser as some building block that people should know how to build, I am saying that the building blocks today are things built on top of them. This moves whole thing one layer above, and makes the question of "how does map work internally" into the same territory as "how is nand gate built internally" for C developers: totally irrelevant. Programming courses were focused on teaching how to write hashmaps and sorting algorighms for decades, but here is the news: we already have them, start teaching how to use them to build higher-level things. > Go ahead, try to name a language that better represents hardware. Assembler. LLVM IR. C or C++ with custom extensions. Whole families of languages for graphic cards. > representing the hardware is not the point anyway Oh, that's what I think too. That's why I see C as obsolete: if you don't need it to represent hardware (which it doesn't) and rely on compiler doing optimisations for you, you can as well use more convenient language (like Rust. Or Java), which will provide the same end result with a lot of added value. Like actually making use of the hardware easier for example. > Apparently some people think that anything below the web browser is hardware. The implementation details of anything below the web browser is indeed mainly dictated by hardware. How the web browsers are designed too: all changed significantly to utilize parallelism and accelerated graphics because that's how hardware works today. > you'd know that making something teaches lessons in ways that abstract thought can not. Definitely. But it helps a lot if that "something" will be relevant to your future work. C largely isn't, outside of relatively shrinking domains. > You wouldn't. The implementors would. Yes. But implementors would not look into "how to write C code", but into "how specific hardware works" to make things efficient. People who write compilers today look into either hardware specs, or models exposed by code generators. That's another niche where C is not the king anymore. > Your attitude is effectively "it's magic" even if you don't use the word. True. I consider certain amount of layers below what I work on as "magic" in the sense that it makes no sense to me to know how it works in details, only to have some mental model. It is useful for me to know that CPU has registers and cores, it is not useful to know how to produce it. I also know that whatever people work on today, will be covered by more layers tomorrow. Of course someone will need to know to build a CPU or how to write a regex parser, but we come to time when we spend 99% of time just using them and the need to building or redesigning one appears maybe once a decade. A lot of things the people teach when they teach C is very useful for people who will be using C professionally, and largely useless for 99% of those who will use something else because the world moved on higher or lower for the things that C was used before.

fiedzia 8y ago

> Studying past highly-successful systems and understanding why they made the choices they did is not just useful but essential. Studying currently used and developed systems for people who will be designing future ones and enter job market in near future is more essential. Databases designed today are mainly distributed and knowledge of design choices made by Postgres doesn't help there, same as design choices made by whatever existed before Postgresql. > Most of what you would learn from implementing a map or regex parser is way above the hardware Ok, I agree with that. Although I am testing now hash implementation written using SIMD instructions. My main point here was however that while you see map and regex parser as some building block that people should know how to build, I am saying that the building blocks today are things built on top of them. This moves whole thing one layer above, and makes the question of "how does map work internally" into the same territory as "how is nand gate built internally" for C developers: totally irrelevant. Programming courses were focused on teaching how to write hashmaps and sorting algorighms for decades, but here is the news: we already have them, start teaching how to use them to build higher-level things. > Go ahead, try to name a language that better represents hardware. Assembler. LLVM IR. C or C++ with custom extensions. Whole families of languages for graphic cards. > representing the hardware is not the point anyway Oh, that's what I think too. That's why I see C as obsolete: if you don't need it to represent hardware (which it doesn't) and rely on compiler doing optimisations for you, you can as well use more convenient language (like Rust. Or Java), which will provide the same end result with a lot of added value. Like actually making use of the hardware easier for example. > Apparently some people think that anything below the web browser is hardware. The implementation details of anything below the web browser is indeed mainly dictated by hardware. How the web browsers are designed too: all changed significantly to utilize parallelism and accelerated graphics because that's how hardware works today. > you'd know that making something teaches lessons in ways that abstract thought can not. Definitely. But it helps a lot if that "something" will be relevant to your future work. C largely isn't, outside of relatively shrinking domains. > You wouldn't. The implementors would. Yes. But implementors would not look into "how to write C code", but into "how specific hardware works" to make things efficient. People who write compilers today look into either hardware specs, or models exposed by code generators. That's another niche where C is not the king anymore. > Your attitude is effectively "it's magic" even if you don't use the word. True. I consider certain amount of layers below what I work on as "magic" in the sense that it makes no sense to me to know how it works in details, only to have some mental model. It is useful for me to know that CPU has registers and cores, it is not useful to know how to produce it. I also know that whatever people work on today, will be covered by more layers tomorrow. Of course someone will need to know to build a CPU or how to write a regex parser, but we come to time when we spend 99% of time just using them and the need to building or redesigning one appears maybe once a decade. A lot of things the people teach when they teach C is very useful for people who will be using C professionally, and largely useless for 99% of those who will use something else because the world moved on higher or lower for the things that C was used before.