5 ms·

> Studying past highly-successful systems and understanding why they made the choices they did is not just useful but essential. Studying currently used and de

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

notacoward 8y ago
> Databases designed today are mainly distributed and knowledge of design choices made by Postgres doesn't help there I've been working on distributed systems for 25+ years, and I still believe that understanding what happens within each node is important. You might be surprised how many of the real world's distributed databases are basically sharding over local databases written in C, and even the newer ones borrow many of the concepts. Would you rather study a mature query planner or an immature one? Both, really, but seeing how the mature one has developed over time is probably more instructive. And then there are kernels, filesystems, compilers, and other things you conveniently dropped from the comparison. > Assembler. LLVM IR. C or C++ with custom extensions. Whole families of languages for graphic cards. LLVM IR doesn't count, because there's no software to study that's written directly in it. The same is true of assembler. As for "X with custom extensions" you can't learn those without learning X itself so you haven't really made an argument against learning X. Also, very little software is written using those extensions so, again, there's no pedagogical value. > you can as well use more convenient language Missing the point again. The OP wasn't about what language to use for new development. It was about learning what is needed to study existing systems. > A lot of things the people teach when they teach C is ... largely useless for 99% Or maybe some of that 99% just don't know what they don't know, and that's the essence of Dunning-Krueger. People develop expertise in their own tiny sub-domain, then use simplified models for the rest ... but those other sub-domains aren't actually any simpler. Abstractions leak. While there is certainly a danger in drilling too deep or getting too wrapped up in details that end up not being relevant (or permanent), any programmer who treats "those other layers" as magic is going to be handicapped relative to a programmer who knows something about them. For example, knowledge I gained about cache-coherency algorithms very early in my career has come back to me again and again in contexts that were surprising to my colleagues who were never exposed to that stuff. They just thought it was magic, but it turned out to be magic that could be re-applied at a different layer for big wins.
- fiedzia 8y ago
  > You might be surprised how many of the real world's distributed databases are basically sharding over local databases written in C I probably would be, most of the ones I hear about or use aren't. When it comes to data storage, I work mainly with solr. Not only it doesn't have a line of C, if you were to study its domain there is no C equivalent. development and research is available in Java or Python, and nearest native competitors ... are also not written in C. > Would you rather study a mature query planner or an immature one? If I were a student, I'd rather study one that will give some idea of what people will design when I will enter job market, using tools they will use. > seeing how the mature one has developed over time is probably more instructive maybe, but is also less relevant for the needs of current database market and subject of research. > It was about learning what is needed to study existing systems. Existing systems are written in variety of languages and C, while still significant, does not constitute majority. Recently created systems are mostly written in something else. > Or maybe some of that 99% just don't know what they don't know, and that's the essence of Dunning-Krueger. Or maybe those who teach C stay in their bubble and missed the fact that other things not only exist, but also took over market and mind share. > any programmer who treats "those other layers" as magic is going to be handicapped relative to a programmer who knows something about them Only if those things have any relevance to their job. If you go 2 or 3 layers below, any relevance is lost and we keep adding those layers. > For example, knowledge I gained about cache-coherency algorithms very early in my career has come back to me again and again in contexts that were surprising to my colleagues who were never exposed to that stuff. They just thought it was magic, but it turned out to be magic that could be re-applied at a different layer for big wins. So you provided some cache-coherency implementation and now they can use it without knowing how it is implemented, right? And spent their time on improving their product having the cache coherency as given? As it was magic?

notacoward 8y ago

> Databases designed today are mainly distributed and knowledge of design choices made by Postgres doesn't help there I've been working on distributed systems for 25+ years, and I still believe that understanding what happens within each node is important. You might be surprised how many of the real world's distributed databases are basically sharding over local databases written in C, and even the newer ones borrow many of the concepts. Would you rather study a mature query planner or an immature one? Both, really, but seeing how the mature one has developed over time is probably more instructive. And then there are kernels, filesystems, compilers, and other things you conveniently dropped from the comparison. > Assembler. LLVM IR. C or C++ with custom extensions. Whole families of languages for graphic cards. LLVM IR doesn't count, because there's no software to study that's written directly in it. The same is true of assembler. As for "X with custom extensions" you can't learn those without learning X itself so you haven't really made an argument against learning X. Also, very little software is written using those extensions so, again, there's no pedagogical value. > you can as well use more convenient language Missing the point again. The OP wasn't about what language to use for new development. It was about learning what is needed to study existing systems. > A lot of things the people teach when they teach C is ... largely useless for 99% Or maybe some of that 99% just don't know what they don't know, and that's the essence of Dunning-Krueger. People develop expertise in their own tiny sub-domain, then use simplified models for the rest ... but those other sub-domains aren't actually any simpler. Abstractions leak. While there is certainly a danger in drilling too deep or getting too wrapped up in details that end up not being relevant (or permanent), any programmer who treats "those other layers" as magic is going to be handicapped relative to a programmer who knows something about them. For example, knowledge I gained about cache-coherency algorithms very early in my career has come back to me again and again in contexts that were surprising to my colleagues who were never exposed to that stuff. They just thought it was magic, but it turned out to be magic that could be re-applied at a different layer for big wins.

fiedzia 8y ago
> You might be surprised how many of the real world's distributed databases are basically sharding over local databases written in C I probably would be, most of the ones I hear about or use aren't. When it comes to data storage, I work mainly with solr. Not only it doesn't have a line of C, if you were to study its domain there is no C equivalent. development and research is available in Java or Python, and nearest native competitors ... are also not written in C. > Would you rather study a mature query planner or an immature one? If I were a student, I'd rather study one that will give some idea of what people will design when I will enter job market, using tools they will use. > seeing how the mature one has developed over time is probably more instructive maybe, but is also less relevant for the needs of current database market and subject of research. > It was about learning what is needed to study existing systems. Existing systems are written in variety of languages and C, while still significant, does not constitute majority. Recently created systems are mostly written in something else. > Or maybe some of that 99% just don't know what they don't know, and that's the essence of Dunning-Krueger. Or maybe those who teach C stay in their bubble and missed the fact that other things not only exist, but also took over market and mind share. > any programmer who treats "those other layers" as magic is going to be handicapped relative to a programmer who knows something about them Only if those things have any relevance to their job. If you go 2 or 3 layers below, any relevance is lost and we keep adding those layers. > For example, knowledge I gained about cache-coherency algorithms very early in my career has come back to me again and again in contexts that were surprising to my colleagues who were never exposed to that stuff. They just thought it was magic, but it turned out to be magic that could be re-applied at a different layer for big wins. So you provided some cache-coherency implementation and now they can use it without knowing how it is implemented, right? And spent their time on improving their product having the cache coherency as given? As it was magic?