The Awesome Power of Context
When you look at the role of context in all linguistic endeavors, you will find that there is no more powerful force. If you don't believe me try speaking to an infant. No matter what you say to the infant they won't understand a word of it. They may recognize your voice, from sounds they heard in the womb, but that is only because they have a context for recognition. Take that same babe 30 years later and drop them in a random country, and odds are they'd have not better time understanding anything said to them by the locals. Ifthey are clever or lucky they may survive long enough to develop sufficient context and learn the local language. But even then, they will have a confused and muddled grasp of many concepts thatdo not cleanly map to their mother tongue.
The same is true for programmers and their computers. Take a Java programmer and ask them to hack on a C program, and you will end up with a program that crashes regularly, runs out of memory, and is structured poorly by the norms of the C community. It is not the Java programmer's fault, they simply lack sufficient context to understand the nuances of the language. Peculiar idiomatic expressions, like macro expansions, can produce truly spectacular misunderstandings.
Assembler programmers tend to think the same of C programmers. Why does a C programmer never use a BCD to represent arbitrary precision numbers? Why Do you need 20 million pointer types, they're just addresses in a register? Sign? What sign? Less than, greater than, above, below, it all depends on the context. To the assembler programmer the machine is the context.
Having built production systems in 16 different languages in the past decade, I can say this for the vast majority of programmers who define themselves by the language they use, they really like mental bondage. Now imposing constraints on though to encourage creativity in other areas. I for example always impose an upper size limit on the number of lines I write. But not experiencing alternative ways of thinking about a problem in the first place is more limiting.
After working on high level OO popular languages, I always end up revisiting bare metal forth. I have one directory on my laptop with 30 variations of forth implemented for 6 different architectures. I have 2 custom design forth chips, and Ethernet drivers for them. I have firths that run on hlool VMs. And every time I revisit these I have new ideas for those other contexts.