Lambda the Ultimate

PILOT is a language that's too simple, IMO. At the same time, it does what it was designed to do.

I don't know if a "too simple" language can exist; a language is designed for a specific task. A language may not support enough functionality to produce the results, but oftentimes I would imagine it's a result of a poor rather than one that is too simple. My support for this is that a language can be quite simple, yet the abilities it has be enough implement what is needed, e.g. Scheme.

From what I gather, Wirth praises simplicity in a programming language - i.e. the language should be simple for the given problem domain. So I'm not sure what would qualify a language as being too simple.

It will always be that way, I think.

I certainly can't agree with everything that Wirth says, but I think he's right on the money when he says that "the language designer must not ask [users] `what do you want?', but rather `how does your problem arise?'" Perl is a language which is founded on answering the first question, and that's why it's such a mess. Modern languages try to focus on answering the second question, but no language can address every such problem, because the space of them is not bounded, and I believe no finite formal system can provide general enough abstraction mechanisms for problems of arbitrary complexity. (My intuition tells me that Goedel's Incompleteness Theorem is responsible for that fact, but I can't make a formal connection.)

Anyway, I think that language design is mostly about answering that second question, and distinguishing between situations where we thought we were answering it, yet were actually answering the first one. The distinction between them is the same as the distinction between implementation (or "model") and "specification", and when you jump to the meta level of a formal system, a specification becomes merely a model of a more general class of specifications. (This is why I think there can be no finite, ideal formal system.)

Editors should be able to see the list.

The premise that a language should not be burdened by (syntactical) rules that define meaningful texts led to a language where it was difficult and almost impossible to detect a flaw in the logic of a program. It led to what I like to call a high-level Turing machine. Making mistakes is human (particularly in programming) and we need all the help possible to avoid committing them.

The Forth parser is so trivially simple that it doesn't even understand strings. There is no notion of grouping in function calls. There is no concept of compound data, just pointers to allocated blocks of memory (a sin repeated by C, although structs make it less onerous). There are no types. Thus, Forth is like an extensible assembly language. Despite what its advocates claim, adding these features to Forth is non-trivial, and most Forth programs thus contain a lot of convolutions to get around these annoyances.

The Oberon book is a ripper for Wirth simplifications. Throwing away everything that's hard to implement and not essential, and trying to keep what remainds super-lean.

Unfortunately out of print, but here's a ref: http://www.amazon.com/exec/obidos/ASIN/0201544288/qid=1006308054/sr=1-2/ref=sr_1_8_2/002-6962332-9227265

Maybe. But Wirth also goes on to cricize the other extreme, which may include languages like Scheme, which IIRC you quite like...