Limiting and reducing language complexity

Programming languages have an unfortunate tendency to become increasingly complex as the communities associated with them grow. A language may initially be "simple", but as its user-base grows and users experiment with other tools and acquire new ideas pressure is placed on the language's developers to implement new features. Therefore, a language may begin to suffer from featuritis—the disease of having too many features, or being overly complex.

As Bruce MacLennan writes in his book Principles of Programming Languages (3rd. ed., published by Oxford University Press), "Featuritis arises from the fact that it is inherently easier to defend adding a feature to a language than to oppose it. This is because the benefits of adding a feature often outweigh the consequent increase in complexity, and because the benefits are specific and clear, whereas the costs are often general and hidden."

I believe MacLennan has a point. Often, adding just a small feature to a programming language will improve it in some small way, perhaps even make it more useful. However, one new feature leads to another, and after hundreds of small features—all useful in themselves—have been implemented, a language begins to suffer from bloat and inconsistency, both of which lead to new users of the language quickly becoming confused.

Every language has a distinctive character, and this is something to be proud of, not to shy away from. Designers and authors need to appreciate the "personality" of various programming languages, encourage diversity, and remember that there will be some features outside the scope of any given programming language which should be left for other languages to implement.

How is it possible to decide which features are within the scope of a programming language and which are not? I believe that the answer lies in having an individual leading the development of a language. I do not like the term "benevolent dictator", but that probably best describes the kind of role that I refer to. If the development of a language is led by an individual person, as opposed to a committee, it logically follows that the language will reflect some aspects of that person's personality. If that individual identifies with the philosophy of the language, there is an increased chance that they will know whether or not adding a feature is "good" for that language. If they feel uncomfortable with making a change, it probably is in the project's best interests not to implement it. And, as "Syzygy" recently commented, "If one can feel the author's 'signature' in the interpreter, the programmer can follow along the lines of the author's thought, and will more readily understand what is feasible, and how an end can be achieved."

An individual will have their own sense of what is "right" or "wrong" for a language, and, provided that they do not continually have to justify their feelings about particular issues, they can guide a language's development, maintaining simplicity while increasing usefulness. Committees find this far more difficult to
accomplish, since each person on the committee is obliged to explain their opinions to other members, and often it is very difficult to pinpoint exactly why one feels uncomfortable with a particular feature or change. I do not believe it is crucial that only one individual develops a language; this would be impractical in many ways. But I do believe that an individual, ultimately, should have the final say on what goes into and what stays out of a programming language.

Of course, the community can always fork a language and create a new project, particularly if they are greatly displeased with the attitude of, or some of the decisions made by, the development leader. Ideally, this will never happen: it is emotionally taxing and costly in terms of resources. But the option is always there for those who need it, and the right to fork is fundamental to the concept of free software.

Programming languages like Yabasic with small yet active communities usually do not suffer from featuritis. At any rate, I do not think that Yabasic is negatively impacted by feature creep, although I am undoubtedly biased. But as our community grows and the language is developed further, it is important that we move quickly to counteract any symptoms of featuritis if and when they do appear. I will be releasing a beta version of Yabasic 3 soon, within a week or two from now at most; and I look forward to hearing your feedback, bug reports, and—of course—feature requests. I would love to hear your thoughts on keeping Yabasic both simple and useful.