Shackles of Compatibility

The Shackle of Compatibility means you can never recover from mistakes in language design.

Well, I don't think so. If you do an incompatible feature you could just make it possible to enable and disable it. For example the newest rage amongst Java programmers is to declare every variable and parameter final. This is intended to catch accidental (as opposed to purposeful) variable reuse, which is a good idea.

But it is questionable whether sprinkling the source with final isn't too high a price. Ok, you can't just change the language semantics to have final be the default. But, why not make it switchable? Add something like pragma "default_final_vars";, and enjoy the best of two worlds. Old code stays as it is, new code can be not cluttered.

Similarly, any language could make the subversion or misfeatures selectable.

Of course there is a drawback as you must be aware which dialect is in use. But you need to do that anyway since many of the mainstream languages look pretty similar to each other.

Speech recognition

Giles Bowkett argues that every programmer should develop a personal style,
and Andrew Norris responds that this is not a good goal. He seems to think that this is akin to writing Fortran in any language.

I don't quite agree. Personal style should be orthogonal to the style imposed by the idioms of a language. It reminds me of speech recognition, which can have several outputs: First, the words spoken. Second, who's talking. Third, the mood of the speaker. I don't have experienced 'speaker recognition' (that isn't tied to idiom usage) in source code yet, however, and can't quite think how that would look like.

I do remember, however, reading a german book about electronics, whose tone was just slightly unusual. It turned out to be a translation from finnish.