&gt; I&#x27;ve come to the conclusion that C is best understood if you think about it in terms of the way that an assembly language programmer would think about doing things.<p>I don&#x27;t agree. That leads people to incorrect conclusions like &quot;int addition wraps around on overflow&quot; (mentioned in the article), &quot;null pointer dereferences are guaranteed to crash the program&quot;, &quot;casting from a float pointer to an int pointer and dereferencing it is OK to do low-level tricks&quot;, and so forth. C is a language that implements <i>its own</i> semantics, not the semantics of some particular machine. Confusing these two ideas has led to lots and lots of bugs, many detailed in John&#x27;s other blog posts.<p>It might be useful to teach these intuitions to beginning programmers who <i>already know</i> assembly language before learning C (though are there more than a vanishingly few number of those anymore?) But teaching assembly language as part of, or as some sort of prerequisite for, teaching C strikes me as a waste of time and likely to lead to wrong assumptions that students will eventually have to unlearn.