Garth Gilmour
2 min readDec 17, 2021

--

I used to think the same way, but the folks I know who (unlike me) understand performance turned me round. As I once saw it put on Twitter “C gives you an understanding of hardware, as it was in the 1970's”. Any modern description of how hardware works would have to include the different levels of caching, pre-fetching, branch prediction and pipelining, parallel execution etc… You get none of that from C.

On top of that you would want to layer an understanding of the performance penalties of locking, and why coding with immutable data can give superior performance. Then on top of that you would want to discuss the merits of garbage collection verses reference counting. Finally you would need to get into the dynamic code optimisations performed by the JVM and CLR and how to stay out of their way.

Ultimately most of the lessons a student would be taught on a traditional C programming course are outdated, incorrect and counterproductive. If you teach students that what lives in a pointer is a memory address then you are doing them a disservice. Even the idea that array elements are contiguous in memory is problematic, if you are trying to train folks to write high performance code.

A modern programming course should teach coding as it is today and avoid outdated wisdom, such as that synchronised and virtual methods always run slower, manually caching objects is a good idea, one long method runs faster than lots of short ones, doing many jobs at once is faster than doing them individually etc… All of that is before you get to the many quirks of the C language that only exist for historical reasons and will get in a learners way. This is why the industry gave up on C for C++, and then gave up on C++ for Go and now Rust. If the choice was mine it would definitely be Rust.

--

--

Garth Gilmour
Garth Gilmour

Written by Garth Gilmour

Helping devs develop software. Coding for 30 years, teaching for 20. Technical Learning Consultant at Liberty Mutual. Also martial arts, politics & philosophy.

Responses (1)