Jon Bentley has been around computers for years, spending most of his time with AT&T Bell Labs (the birth place of Unix and C). In an article in “Unix Review”, Jon mentions some guidelines on building languages. I thought these guidelines also apply to writing other programs, so I thought I would pass them along. The items below are taken from the article. My comments are in []’s.
[ Jon discussed his ideas with a few major points listed below.]A Zoo of Examples. Start with the zoo to define your problem, use it for testing throughout development, and put the best examples into the documentation.
- If you are doing a graphing program, start of with a number of example graphs that you want to be able to create using your program. Use them to help you decide what type of features you want your program to support.
A Working Description. Create a one- or two-page outline of your Language to ensure a cohesive design.
[ Clearly defining your problem at the start will have headaches in the design and coding process.]The User’s Manual. Document your language or GUI’s goals and architecture from the user’s perspective.
- To create a program that is designed for the user, write your documentation first, describing how you want the program to run, and then write your code based on this. It’s too easy to take short cuts in programming, because it’s easy to implement and not easy to use.
Language Design Principles.
- Design Goals. Before you design a carefully study the problem you are trying to solve. An old rule of thumb states that the first 10% of programming effort provides 90% of the functionality; can you make do with a small implementation that cheaply provides the fir 90%, or do you have to use more powerfull tools to get to 99.9%.
- Simplicity. Keep you language as simple as possible. A smaller system is easier for its implementers to design, build, document, and maintain and is easier for its users to learn and use.
- Yardsticks of Design. Here are some desirable properties of interfaces:
- Orthogonality: keep unrelated features unrelated.
- Generality: use an operation for many purposes.
- Parsimony: delete unneeded operations.
- Completeness: make the system implement all operations of interest.
- Similarity: make the interface as suggestive as possible.
- Extensibility: make sure the system can grow.
- Openness: let the user “escape” to use related tools.
- The Design Process. Like other great software, languages are grown, not built. Start with a solid, simple design expressed in a succinct notation. Before implementing the language, test your design by performing a wide variety of operations. After the system is up and running, interate designs to add features as dictated by your customer’s needs.