3 ms·

> C is not really representative of underlying hardware anymore While I understand where this is coming from, can you suggest any language that is closer to th

by jjav 5y ago

> C is not really representative of underlying hardware anymore While I understand where this is coming from, can you suggest any language that is closer to the mental model of how the underlying hardware works than C (other than assembly)?

kaba0 5y ago
Well, hard to define closer as a simple dimension — but in certain things perhaps Rust — eg. SIMD is notoriously bad in C. Also, multithreading — which is not exactly a new thing either and don’t forget about pointer aliasing — though that latter is more of an optimization possibility. Fortran may also be considered as another candidate for having SoA over AoS which can potentially be more cache-friendly. But my point was more like, there is no reasonable difference between eg. C and another language that compiles down to machine code — the old saying that a seasoned C programmer can reasonably guess the created machine code of a program is no longer true with today’s heavily optimizing compilers and the amount of magic happening is almost comparable to eg. Haskell.
- jjav 5y ago
  What about multithreading? Someone exposed to developing a multithreaded app in C using pthreads will have a much better understanding about threads. I have worked with too many younger developers who are confused about kernel threads, cooperative multitasking, green threads, 1:1, 1:M due to only having experienced higher level languages. You couldn't ever have this type of confusion after working in C with threads. Memory handling of course is the other big area. So many developers grown only on higher level languages have varying level of confusion about memory allocation, passing buffers around by copying vs. pointers, modifying memory vs. copy on write vs. reallocating everything. You couldn't possibly come out confused by any of this after a solid stint in C. And just like threads, it's very valuable understanding even if later you mostly program in higher level languages. So yes, while it certainly true that in the 80s you could squint at C code and see the generated assembly code, and that's no longer necessarily true today, it is still true that having a solid foundation in C will help tremendously in understanding what's going in the CPU and memory in ways that probably no other language (that I'm aware of) will help you learn. I do need to spend a solid season in Rust sometime to have a deeper opinion about it!

by jjav 5y ago

kaba0 5y ago

Well, hard to define closer as a simple dimension — but in certain things perhaps Rust — eg. SIMD is notoriously bad in C. Also, multithreading — which is not exactly a new thing either and don’t forget about pointer aliasing — though that latter is more of an optimization possibility. Fortran may also be considered as another candidate for having SoA over AoS which can potentially be more cache-friendly. But my point was more like, there is no reasonable difference between eg. C and another language that compiles down to machine code — the old saying that a seasoned C programmer can reasonably guess the created machine code of a program is no longer true with today’s heavily optimizing compilers and the amount of magic happening is almost comparable to eg. Haskell.

jjav 5y ago
What about multithreading? Someone exposed to developing a multithreaded app in C using pthreads will have a much better understanding about threads. I have worked with too many younger developers who are confused about kernel threads, cooperative multitasking, green threads, 1:1, 1:M due to only having experienced higher level languages. You couldn't ever have this type of confusion after working in C with threads. Memory handling of course is the other big area. So many developers grown only on higher level languages have varying level of confusion about memory allocation, passing buffers around by copying vs. pointers, modifying memory vs. copy on write vs. reallocating everything. You couldn't possibly come out confused by any of this after a solid stint in C. And just like threads, it's very valuable understanding even if later you mostly program in higher level languages. So yes, while it certainly true that in the 80s you could squint at C code and see the generated assembly code, and that's no longer necessarily true today, it is still true that having a solid foundation in C will help tremendously in understanding what's going in the CPU and memory in ways that probably no other language (that I'm aware of) will help you learn. I do need to spend a solid season in Rust sometime to have a deeper opinion about it!