Well, Peter Van Roy's CTM is not an impenetrable and jargon filled, it's actually easier to read than SICP, I think all programmers should read it at least once (I don't know peter van roy personally, I'm not shilling for him or anything).
Your point about c and c++ kind of illustrates my point, I think there are very few people who should ever be programming at such a low level, if more programmers were to thoroughly familiarize themselves with the 'abstractions' that have been discovered, that mistake wouldn't be made.
Certainly, one can be excused for programming in C in 1995. You realize that there weren't many alternatives back then, right?
Substitute "Factory Patterns" if it helps you understand what I'm talking about. Or CTM or SICP.
I'm all about working at a nice high level of abstraction. I'm just not particularly bothered to know the technical term for whatever abstraction I happen to be using at the moment or its storied history.
I see something like "Figure 2, Taxonomy of Programming Paradigms", and I can't for the life of me understand the mind of somebody who'd consider that chart essential learning for a programmer.
Knowing the proper technical terms for abstractions you use is helpful when collaborating with others
This cannot be emphasized enough.
"Certainly, one can be excused for programming in C in 1995. You realize that there weren't many alternatives back then, right?"
I didn't mean to imply you directly, the question is why did the company you were applying to and the industry in general not 'see the light'. lisp,python,tcl,prolog,sql existed before 1995.
Personally, I disagree with the pattern languages of object oriented design, they aren't necessary if you know the full range of abstractions of which CTM and SICP describe (functional, relational, logical, constraint etc). The proliferation of these difficult to use OO patterns is another symptom of programmers not knowing enough computer science.