What always strikes me (I also wrote a bf parser a while back) is the pay-off in how simple it is to implement vs how hard it is to write in it. This seems a very obvious and simple thing to notice: the less tokens/rules your language uses the easier it is to write a parser for it, but the harder it is to write a program in that language.

The implications seem more subtle and are more interesting. The very simple phenomenon implies that application development time later can be saved by compiler development time now. If so then what is the most optimal language/compiler? What is the best distribution of time? Is it perhaps so that there exists a language that is trivial to implement, yet also super powerful and expressive to program in (don't say lisp here, though it does almost satisfy the second constraint imo).

>Is it perhaps so that there exists a language that is trivial to implement, yet also super powerful and expressive to program in (don't say lisp here, though it does almost satisfy the second constraint imo).

Lisp. Satisfies both constraints.

But seriously, Forth is another interesting language that strikes a good balance between ease of implementation vs ease of use and expressive power. But even more than Lisp, it takes some serious getting used to.

The language IO has a very simple grammar[1] and ignoring libraries is a pretty productive language.

I suspect that you are on to something, but instead of the grammer being the guide instead the abstraction that the language gives you, but with a correlation between abstraction and the complexity of the grammar.

[1] http://iolanguage.org/scm/io/docs/IoGuide.html exp ::= { message | terminator } message ::= symbol [arguments] arguments ::= "(" [exp [ { "," exp } ]] ")" symbol ::= identifier | number | string terminator ::= "\n" | ";"

Interesting observation. I think, the more abstraction, the more productive you can be.

That's kind of just Greenspun's rule as applied to programming languages.

It's natural that it's simple, since (and I suspect that here I'm about to get skewered) Brainfuck is basically a straightforward implementation of a Turing machine, just as Lisps are basically straightforward implementations of the lambda calculus.

Lest you think I'm completely talking out of my ass, I defer my defense to this random wiki page:

http://esolangs.org/wiki/P%27%27

  > P′′ is a primitive programming language created by 
  > Corrado Böhm in 1964 to describe a family of Turing 
  > machines.
  > [...]
  > Brainfuck (apart from its I/O instructions) is a 
  > simple informal variation of Böhm's P′′. Böhm gives 
  > explicit P′′ programs for each of a set of basic 
  > functions sufficient to compute any partial recursive 
  > function -- and these programs are constructed entirely 
  > from six P′′ words precisely equivalent to the 
  > respective Brainfuck commands +, -, <, >, [, and ].

Agree, thats pretty much my argument for Brainfuck being a simple programming language. Thou I phrased it more as analogy then equivilance.

Brainfuck is a simple language in the same way a Turing Machine is a simple computer, conceptually simple leaving the complexity in the laborious task of writing any program

Even more beautiful is the NOR gate, for it is possible to compute any boolean function using them.

Yes, I wrote a virtual NAND gate programming tool a while back (think 2d Minecraft "redstone" style programming) and it was immensely fun to program and playing with it taught me a ton about the gap between simple logic and actual computing (which is a huge matter of scale).