Yes I did, I just find the wording ambiguous enough to mislead newcomers, especially at the very start. The article is good at making parallels with the software world and explaining how to map previous knowledge, but does not make it clear at the beginning that this is not software. Even at the end, things are muddy, with things like:
Hardware - write concurrent code, write serial code where needed.
For you an I who get the difference, we can read between the lines and get it, but a complete newcomer might just as well end up thinking: "okay I get it, this is very low level software code which is executing concurrently by default", when really, it is "this is very high level hardware which is described here, and physics makes it 'happen everywhere' at once, but I can understand what happens through a mind trick".
Mind you, I like your article, but I just feel it may make some hardware beginners get some fundamental basics wrong.
As an anecdote, I personally noticed the critical importance of this distinction first hand, as in a software program, we went through a hardware course on this very subject and the teacher incessantly restated this fact, with due reason since later down the road each one of us understood that basically every single mistake one made was due to one trying to shoehorn software concepts into hardware, or expecting software behaviour from hardware.
Mind you, I like your article, but I just feel it may make some hardware beginners get some fundamental basics wrong.
As an anecdote, I personally noticed the critical importance of this distinction first hand, as in a software program, we went through a hardware course on this very subject and the teacher incessantly restated this fact, with due reason since later down the road each one of us understood that basically every single mistake one made was due to one trying to shoehorn software concepts into hardware, or expecting software behaviour from hardware.