No matter how restrictive a language is, some programmers will still find ways to screw things up. Imagine the following piece of code:

var price = this.ApplyVAT(basePrice);
if (this.acceptsRebate)
{
    return new RebateCalculator(RebateType.Default).Transform(price);
}

return price;

Let’s screw it:

// Rebats calculator became variable cal.
var cal = new RebateCalculator(RebateType.Default);

// stylecop complain if i dont put comment here and leave line empty. don't know why??
//
// don't know price now so later maybe!!!
Price pp = null;

// Func is transforms price to price!
Func<Price, Price> tar = cal.Do;
var g = Tax(bPR);

// changed by MAG 02/08/2013
// if arebt2 is true, the condition should match.....
if (arebt2)
{
    // assign g to g2
    var g2 = g;

    // don't remember what tar mean but its very important!!! don't remove!!!
    pp = tar(g);
}
else
{
    // it's the same!
    pp = g;
}

// i can return now because i know price!!!
return pp;

The code still complies to the same IL, and doesn’t violate any StyleCop or Code analysis rules (while StyleCop is damn strict forcing you to write code in a very precise way). But it’s now a piece of crap, completely impossible to work with. How would you possibly design a language which tells that those comments are useless and annoying, that my naming conventions is among the poorest and that intermediary variables add more harm than good?

Using Unicode in names is a good example. In the code above, I haven’t even used Unicode in the names of variables. [A-Za-z0-9_] is enough to give meaningless names. On the other hand, Unicode may be very helpful in improving code. This piece of code:

const numeric Pi = 3.1415926535897932384626433832795;
numeric firstAlpha = deltaY / deltaX + Pi;
numeric secondAlpha = this.Compute(firstAlpha);
Assert.Equals(math.Infinity, secondAlpha);

is readable enough, but allowing Unicode in names can empower the programmer to write this instead (the problem being that you won’t be able to type variable names on a non-Greek keyword):

const numeric π = 3.1415926535897932384626433832795;
numeric α₁ = Δy / Δx + π;
numeric α₂ = this.Compute(α₁);
Assert.Equals(math.∞, α₂);

Some developers will consider that the second variant pushes naming too far, but it may be an excellent readability boost for some projects (such as a project written by a team of scientists).

Talking about naming conventions, I haven’t seen a single rule which actually prevents giving bad names to variables. An example such as the code above can be prevented by a rule similar to:

The names of private variables should contain at least four characters. The names of public variables should contain at least six characters.

But this won’t prevent renaming pp into ppppppp just to get rid of the warning. An additional rule:

The names can’t contain a character consecutively repeated more than two times. For example, feed is a valid name, while feeed is not.

may also be circumvented by renaming the variable to ppabcde.

The actual goal

What’s more important is that a well designed programming language should help avoiding errors. For example:

if (this.isEnabled)
    this.PlayVideo();
    this.PlaySubtitles();

is a sign that something went wrong. When I see that in a C# code, I blame:

• The programmer, because it’s so simple to always insert curly brackets, instead of taking a risk of losing thousands of dollars because of a stupid bug, hard to detect during code reviews and hard to find later,

• The programmer, again, because he should have used proper tools (StyleCop in this case),

• The language, because such syntax could have been forbidden,

• The IDE, because it didn’t reacted to the fact that the programmer screwed up indentation.

Conclusion

• Be restrictive when it helps avoiding bugs and when the syntax flexibility is not particularly useful.

• Don’t be restrictive just to help beginners: they’ll find ways to make their code unreadable anyway.

• Add syntactic sugar when it helps readability most of the time, without being misused most of the time.

Example of Python

If you know Python, this is a good example of useful strictness. Persons who just started learning it are usually negatively surprised by its strictness:

What? I can’t indent the code like I want? This is annoying!

or:

There are no switch statements in Python? Are you serious?! Are you telling that I have to use if-elif-else every time I need a switch?

A few years later, the person would confirm that:

• Having meaningful indentation is an excellent idea, because it prevents subtle errors (like the one with the if above) and reduces the effort of writing code (instead of putting semicolons and indenting code, you deal only with indentation).

• They don’t need a switch, because they replace conditional by polymorphism anyway and when they actually need a mechanism similar to a switch, a dictionary is a perfect choice.

Don’t go out of your way to prevent bad code. You’ll never cover any sizable subset of all the ways to write bad code and every additional rule costs something (time, money, mental capacity, opportunity, complexity, etc.). One can write FORTRAN in any language, don’t try to fight it.

Instead, ask positive questions: How much do I, and the user, gain by restricting the language this? Does it make the parser simpler and faster? Does it really simplify the language? Does it make it easier to write good code (as opposed to harder to write bad code)? Does it have synergies with other features that add entirely new benefits? Weigh those benefits against the aforementioned costs.

The primary goals in a language should be:

1. Allow a programmer to actually express what he wants. For example, rather than having a small number of integer types, allow a programmer to specify which characteristics are important, including representable range, wrapping behavior, overflow trapping, endianness, etc. Don’t force programmers to specify properties which aren’t of interest, but allow specification of whatever combination of properties is important. For floating-point types, allow code some control over precision/speed trade-offs. Allow types to propagate into expressions, so that e.g. long1 = int1 + int2; will perform the arithmetic as long.(*)

2. Require “yes that’s what I mean” markers in places where there’s more than one thing a programmer might plausibly have intended, but not in cases where there the straightforward meaning is the only one that makes sense. An initialization like double someDouble = 0.1f; might match programmer intention, but is more likely a mistake; it would be appropriate to require something like double someDouble = FloatToDouble(0.1f;. On the other hand, float someFloat = 0.1; would only have one plausible meaning, and should thus store the fraction 1/10 into someFloat as accurately as possible.

3. Allow programmers to specify places when implicit conversions should be applied more strictly than usual, and places where they should be applied more loosely. For example, if a language supports auto-boxing, allow a means by which a method parameter can say that it should not accept an implicitly-auto-boxed object.

4. When deciding what kinds of implicit constructs should or should not be legal, think about the effects of changes to parts of the code. For example, if code is required to say someField = (float)Math.Sqrt(something) rather than simply someField = Math.Sqrt(something) when someField is a float, how will that affect the effort required to make someFloat be a double if float precision is found to be inadequate?

(*) The normal argument I’ve read against allowing types to propagate into expressions is that it leads to ambiguous situations involving operator overloads. To that I would suggest allowing methods to either specify which overloads to favor in cases of ambiguity, or require that the invoking code make clear what it wants. Further, given an integer expression like (a*b+c)/d, I would suggest that requiring an indication of how the dividend should be computed would make programmer intentions clearer than would applying a default behavior.

It depends entirely on the philosophy of the language.

C allows you to deliberately shoot yourself in the foot, in order to obtain the best possible performance. C++ allows you to blow your leg off. Java is a bondage and discipline language, preferring ceremony and safety over performance. Haskell’s type system emphasizes mathematical proof of consistency.

I don’t think you can make a language “idiot proof”. At most, you can make it “mistake proof” for those that have good intentions.

So I wouldn’t invest computertime and developer (compile time) or user (runtime) frustration in checking every little detail. Of course, errors will be made, and of course bugs will be shipped, but is it worth restricting everything and everyone in the hope that you can prevent (for the full 100%) fools from being fools, or humans from making mistakes?