TutorialDee and such relational languages are nice - but their syntax can be reduced.

QompLanguage style '''b''' and '''e''' and other innovations to make the language concise, short, and easy to use will be helpful.

One idea of TutorialDee was to reduce verbosity of SQL such as getting rid of SELECT and such. If SQL was more precise, and didn't require so much dynamic string generation in our languages - it would be much easier to access and use. This is in fact one of the main benefits of a relational language designed such as TutorialDee - it is more precise and cutting than SQL. Why not take it further and make it even more cutting, clean, and precise than it already is? It can be reduced further.

As I have time, I will play with a cu t down, readable, precise version of TutorialDee.

----
Proscriptions, Prescriptions, Recommendations 
* CAPS LOCK will not be used excessively 
* RELATION shall be reduced to '''rel'''
* VAR reserved word shall be reduced to '''v''' reserved letter
* INTEGER shall be reduced to '''int'''
* BEGIN shall be reduced to '''b'''
* END shall be reduceed to '''e'''
* ...

''Please allow longer words if one desires. In other words, if "v" is short for "var", then allow "var" also. Further, why use "b" and "e" when curly braces are well-established for such use? I'm not sure one-letter key-words are a good thing to use often.''

Curly braces are already used elsewhere in TutorialDee, see below example. As for one letter key words not being a '''good thing to use often''', this is obviously an opinion of yours. 

Duplication (allowing more than one way of doing it) should be carefully considered, but also thought as evil at times, since doing things more than one way offers little benefit and places more bugs into the compiler,  more room for error, more variations of code (instead of consistent code). This is one of my biggest gripes with Ruby - having too many ways to do the same thing.  

One should use a teaching language (TutorialDee) - and then move to the sister non-learning language (more notative, less verbose, less like Pascal) after learning. Curly braces could be used too - using B and E keeps the sister language near identical and easy to migrate too though. This is the approach Qomp takes to delphi and fpc. If one knows TutorialDee,  he should immediately know the sister language just by using syntax highlighting and seeing exact similarities.
----
Examples 

 '''v''' myThings '''real rel''' {
  name '''char''',
  x '''int''',
  y '''int''',
  z '''int'''
 } '''key''' {name}

----
Quotes and reasons why I prefer more precise, concise, brief languages:

*''"We have to let the symbols do the work, for that is the only known technique that scales up"'' --Dijkstra 

*''"Elsewhere I have warned against the ...tendency to design programming languages so that they are easily readable for a semi-professional, semi-interested reader. (Symptoms of this tendency are languages the vocabulary of which includes a wild variety of English words to be used in a nearly normal sense...)"'' --Dijkstra

*''..."It looks so attractive: Everybody can understand it immediately.' But giving a plausible semantic interpretation to a text which one assumes to be correct and meaningful, is one thing; writing down such a text[.....]expressing exactly what one wishes to say, may be quite a different matter! On comparable grounds, John McCarthy calls 'COBOL .. a step up a blind alley on account of its orientation towards English which is not well suited to the formal description of procedures'."'' --Dijkstra 

* As I said before - we got rid of SELECT from SQL (which is annoying) so we shall take it further when we can and reduce other areas of the language.
----
Designing a "D" language along these lines sounds like a great idea.  However, by definition, it will not be TutorialDee.  TutorialDee has a well-defined syntax.  If you change that syntax, you create a different language.  

Remember that TutorialDee is primarily intended to be a teaching and illustration language.  Its verbosity is intended to make the syntax intuitive even to those with minimal programming experience.  "b", "e" and "int" may require explanation, depending on the audience.  "BEGIN", "END" and "INTEGER"[1] should require less, if any, explanation.  But, if you perceive a developer demand for a QompLanguage that is a TutorialDee-inspired "D", then please develop it.

--

[1] - In TutorialDee, keywords in caps is a coding convention; it is not a requirement of the TutorialDee specification or any implementation of which I'm aware.