Programming a Problem-Oriented Language by Charles Moore

• Mistakes that are obvious in retrospect, but difficult to recognize in context.
• A problem-oriented language is a language tailored to a particular application. To avoid that uniquely clumsy term, I'll usually substitute application language as synonyms. Very often such a language isn't recognized for what it is.
• So to offer guidance when the trade-offs become obscure, I am going to define the Basic Principle: Keep It Simple.
• The Basic Principle has a corollary: Do Not Speculate!
• Do not put code in your programs that might be used. Do not leave hooks on which you can hang extensions. The things you might want to do are infinite; that means that each one has 0 probability of realization.
• The Basic Principle has another corollary: Do It Yourself!
• By permitting the program to dynamically modify its control language, we mark a qualitative change in capability.
• It's much easier to elaborate upon a program than it is to strip it to basics.
• Lacking input simply means that the program knows what to do without being told. That built into the code is all the information needed to run.
• Current languages put more constraints on this last coding process than they should.
• Now let's look at the major failing of higher-level languages. In attempting to ac hive machine-Independence and to be applicable to a wide range of applications, they only give you access to a fraction of the capabilities of your computer.
• Declare all variables. Everyone likes to know what parameters you are using.
• Define everything you can before you reference it.
• Indent! Paper is 2-dimensional. Use it!
• Use short words. You don't want to type long words, and I don't want to read them.
• Abbreviate in some consistent fashion and stick to your own rules.
• Programs are self-documenting, even assembler programs, with a modicum of help from mnemonics.
• What comments should say is what the program is doing.
• There are two words I need to establish precise definitions for: A subroutine is a set of instructions that return from whence they came. A routine is a set of instructions that return to some standard place.
• Subroutines suffer from nesting. If you call a subroutine from within a subroutine you must somehow save the original return address.
• If you jump somewhere, not intending to come back, you can save trouble, time and space. But only if you really never come back.
• It is extremely important for routines to be able to communicate efficiently.
• Finally, it is important to use registers efficiently. Assign registers for specific purposes and use them consistently. Re-assign registries if you must to avoid conflicts. Do not move data from one register to another; see that it is where it belongs in the first place.
• A program without input is a program with a single task. A program with input may have many tasks, which it will perform as directed by its input.
• I only caution you not to get lost in the details; the structure, the concept of the program are what is important.
• Each word performs its specific, limited function; independently of any other word. Yet the combination of words achieves something useful.
• A variable gives a name to a location and not to a value.
• No matter what problem arises, we needn't worry about what to do. Pass the buck; ask the user.
• One of your major tasks will be to decide what kinds of numbers you need for your application, how you will format them, and how you will convert them.
• A push-down stack operates in a last-in first-out fashion. It is composed of an array and a pointer.
• It is important not to attempt to combine the return stack and the parameter stack. They are not synchronized.
• It is important to acknowledge the function and existence of a dictionary, to concentrate it in a single place and to standardize the format of entries.
• A common characteristic of bad programs is that the equivalent of a dictionary is scattered all over the program at great cost in space, time and apparent complexity.
• One basic principle applies to dictionary search: it must be backwards--from latest to oldest entries. This permits the same word to be re-defined, and the latest meaning to be obtained.
• Applications tend to be complicated before they become interesting.
• If you minimize writes you can save a lot of disk accesses.
• If you are going to scan data sequentially, you can save many accesses by reading consecutive blocks at the same time.
• By now I'm sure you're aware that the heart of your program is a control loop. It not only con trolls the operation, but also the philosophy and organization of the program. Let me review its operation: it reads a word, finds it in the dictionary, and executes its code; failing that it converts it to a binary number and places it onto the stack; failing that it types an error message.
• For practical purposes, all programs are prepared by previously existing programs.