Some things just were not possible in the good old days because the programming languages we old-timers grew up with did not support them. This lack led us to learn some things that are turning out to be bad habits. These bad habits are even repeated in more modern language designs.

Non-chainable relational operators ^

Not simple:

    if ( a == b && b == c ) ...   // C

Simple:

    if a == b == c: ...           # Python

What makes it simple is that it matches a familiar mathematical notation and everyday speech. Old-timers had to learn a new notation when they learned C, and they may have forgotten that there was previous art. C++ could overload its operators to achieve this effect, but will it? (or can it? operator overloading is not simple!)

Symbolic constants for array lengths ^

In C:

    int a[10];
    ...
    for ( i = 0 ; i < 10 ; i++ ) ...

is not simple because the array length (10) has to be maintained in two places. So the habit became: "#define a symbolic constant"...

    #define LENGTH_OF_A 10
    int a[LENGTH_OF_A]
    ...
    for ( i = 0 ; i < LENGTH_OF_A ; i++ ) ...

But this is not simple for a number of reasons because there are two programming languages involved here: the C language and the C preprocessor language. (By the way, it was only in 2007 that the C++ standards committee decided that the C++ preprocessor would have the same semantics as the C preprocessor. The GNU GCC C preprocessor will probably continue to go its own way.)

• You have to know the correlation between array names and symbolic length constants. This correlation cannot be checked by the compiler or most lint programs. Yes, you can define simple naming conventions and bloat your line length while you are at it.
• C preprocessor variables are not available at runtime, nor to simple debuggers.

    for ( i = 0 ; i < sizeof a / sizeof a[0] ; i++ ) ...

But that is long-winded and often rewritten (using a #define macro!) as:

    #define len(arr) (sizeof arr / sizeof arr[0])
    ...
    for ( i = 0 ; i < len(a) ; i++ ) ...

This looks exactly like Python's

    ... len(a) ...

which manages to avoid preprocessing to get this result.

But it is neither syntactically or conceptually as simple as Ruby's

    ... a.length ...