Have you ever restricted yourself to using a subset of language features?

Question

Douglas Crockford's book JavaScript: The Good Parts is a prime example of this. He lists 'features' in JavaScript that should be avoided and provides alternatives that use the 'good parts' of the language.

A few of the bad parts are:

• eval
  slower, harder to read, dangerously insecure

• ==
  confusing and ambiguous with differently typed operands

• with
  unpredictable results

Most people program subconciously in an informal subset of the their language of choice that they are comfortable with. For example, my first reaction on being presented with a C++ vector that needs iterating over is to reach for a for-loop, rather than write a predicate and use a standard library algorithm. Possibly a failing on my part, but at least I know the algorithm is there if I really need it.

The last time I can remember conciously writing in a subset language was back in the 80s when most of my target platforms supported FORTRAN 77, but one didn't properly, so I had to write in a FORTRAN 77/FORTRAN IV hybrid. It was a pain - things have got a lot better in recent years, thanks mostly to the FOSS movement.

Yes, all the time.

Because I use Perl, and most people agree that many of our languages features are best not used unless you really need to and you know what you are doing. For example, symbolic references are supported, but you shouldn't use them. goto exists, but you shouldn't use it. You can re-use variable labels as different types, e.g. $var, @var, %var, but you shouldn't do that, either. You can not use strict to have undeclared variables become symbol table entries automatically, but you really shouldn't do that.

The main reason is that many such features have consequences both obvious and esoteric that can introduce subtle and difficult-to-debug errors into your program if used carelessly. Perl makes lots of things possible and it can be attractive to use certain unusual language features to save a few minutes of coding. There are of course times when esoteric features are handy, and it's great that they are there for you to take advantage of in Perl, as opposed to being absent entirely. But it takes experience to know when that savings is worthwhile, because the vast majority of the time you are just creating a maintenance nightmare for yourself and others down the road.

I am fond of saying TMTOWTDI, BMOTWAW; There's more than one way to do it, but most of those ways are wrong.

It's perfectly possible to create large, literate, maintainable Perl applications. And a good part of doing so is restricting yourself to a subset of language features.

One case is when you're writing a compiler of a new language in itself. You can:

• Use another language to write a simple compiler for a subset of the new language.
• Use that subset of the new language to write the compiler for the complete version of itself.