Fundamentally, the problem comes down to the other 90% of the toolstack. Even if you get people to use your language, are you really going to get them to change

Fundamentally, the problem comes down to the other 90% of the toolstack. Even if you get people to use your language, are you really going to get them to change their source code control, every person's text editor, build system, scripts that run over the code, the external localization service, the third party code escrow service, automated performance and security assessment tools, etc.? Anything that is more than a toy project has real requirements, often with tools that are outside of the control of any one vendor or even the company -- they are sometimes requirements of the industry. This code-stored-not-as-text-thing came up so often (it was a recurring Serious Question about once a year while I worked on Visual Studio) that it was simply referred to as the Emacs/grep barrier. Any tool solution that prevents the use of Emacs and grep out of box is just dead unless you have a from-scratch codebase and team. The old Smalltalk hands (some of whom worked on original Smalltalk systems) also like to relate the biggest single issue they had. At one point, they needed to reconstruct the basis library for a new implementation... but there was no code. How do you do a review of a system where the code was (in this case) completely gone, as it had long since become something interpretable as a jump point in a heap image but not as code? (Punchline: they rewrote most of it from scratch, recreating decades-old bugs)