KemyLand wrote:
This a grade of magnitude harder to parse than its English equivalent.
I see you spanish sample as absolutely acceptable way of translation the idea to another language.
After you read the rules the simplicity of parsing will be obvious.
Code:
Alrighty then. Here's how I manage to do so much with so little.
(1) I really only understand five kinds of sentences:
(a) type definitions, which always start with A, AN, or SOME;
(b) global variable definitions, which always start with THE;
(c) routine headers, which always start with TO;
(d) conditional statements, which always start with IF; and
(e) imperative statements, which start with anything else.
(2) I treat as a name anything after A, AN, ANOTHER, SOME, or THE, up to:
(a) any simple verb, like IS, ARE, CAN, or DO, or
(b) any conjunction, like AND or OR, or
(c) any preposition, like OVER, UNDER, AROUND, or THRU, or
(d) any literal, like 123 or "Hello, World!", or
(e) any punctuation mark.
(3) I consider almost all other words to be just words, except for:
(a) infix operators: PLUS, MINUS, TIMES, DIVIDED BY and THEN;
(b) special definition words: CALLED and EQUAL; and
(c) reserved imperatives: LOOP, BREAK, EXIT, REPEAT, and SAY.
Kevin wrote:
embryo wrote:
Also I see here an example of an almost ideal self-documenting code. Really useful feature.
Only if you think that this is ideal documentation:
Code:
xyz++; /* Increase the value of xyz by one */
Usually the job of documentation is to explain higher level concepts, not to describe the code line by line and expression by expression.
The lack of high level structuring power was mentioned in my previous post. But the lack of low level understanding among non programmers seems wasn't noticed by many programmers. So there are a lot of losses in translation.