[mistrial9]

surprising -- I picked up the same, also read it cover to cover, and wondered over and over what kind of thinking leads to the small assembly'ish idioms and quirky character IO definitions. "Structured Programming" was obvious to me, and using that design to build non-trivial programs was very compelling, but the constant emphasis on small, tricky ways to move around a character seemed driven by some intense factory of machine parts thinking, not clean abstractions or consistant naming or human-readable coding. I immediately wanted to try this "big phone network" core OS language on my portable home computer with apparently one-one hundred thousandth of the capacity. Other home computer companies were publishing C compilers rapidly with lots of feature tradeoffs, so there was no question that C was the thing to use for me. Not good design at all though -- machine requirement driven totally.

[voakbasda]

I recently worked to update a Linux-based system that was originally built by a team that had previously implemented the same product on a microcontroller-based system. The Linux drivers are obviously direct ports of the old subsystems, without any apparent effort to understand or leverage existing kernel drivers or subsystems that could have simplified (or outright replaced) their custom functionality. It is unholy.

Now, this might sound absurd by the standards of today (because it is), but this was the transition that every programmer had to make back when high level languages were introduced. It takes time to adapt to a paradigm shift, so it hardly seems surprising when vestiges of the “old ways” can be seen peeking through the curtains of the new abstraction.