> I firmly agree, but the idea that programming languages ought to be
> designed to try to prevent bad programs from being written turns up
> generation after generation. It is one of the arguments I frequently
> hear against Scheme and Lisp macros, i.e. that one can use macros create
> a sublanguage which nobody else can read. (That this argument still
> shows up long after the practice of creating ‘DSLs’ in other languages
> took off, often using little more than syntactic sugar for lambdas,
> shows how vacuous it is.) Indeed, if we subscribed to this idea, we
> would probably never even have had syntax-rules, much less call/cc.

> Pascal is the traditional embodiment of a programming language designed
> to try to prevent the writing of ‘bad’ code. Others in this category
> include Python, where this sentiment has become embedded in the
> community (many Python programmers objected to the introduction of the
> ‘:=’ assignment expression on these grounds). Perhaps one can argue that
> the Python idea that ‘There should be one — and preferably only one —
> obvious way to do it’ is in essence the same argument as ‘There should
> not be a way to write bad code’.

IMHO, productive ways to look at it:

1) Is a feature almost impossible to learn to use correctly, such that
excellent programmers commonly make serious mistakes? E.g. C pointers,
operator precedence.

2) Is a feature rarely used in good taste and often used in bad taste?
Contenders: multiple inheritance, operator overloading, syntactic sugar.

3) Is a feature generally considered to lead to unmaintainable code?
Experienced maintainers dread to inherit a codebase using the feature.