Too Much Verbosity = Hideous Code

Verbose Language Qomp Language 
  MODULE Example;

  IMPORT StdLog, OtherModule;

  PROCEDURE Msg(s: ARRAY OF CHAR);
  BEGIN
    StdLog.String("Showing message: "); StdLog.Ln;
    StdLog.String(s); StdLog.Ln;
    StdLog.String("Done"); StdLog.Ln;
  END Msg;

  PROCEDURE OtherProc(VAR SomeNumber: INTEGER;
                      OUT SomeString: ARRAY OF CHAR);
  BEGIN
    (* some code goes here *)
  END OtherProc;

  END Example.
  
  unit Example;

  use StdLog, OtherUnit;

  proc msg(s: astring);
  b Ln('Showing message: ');
    Ln(s);
    Ln('Done');
  e;

  proc OtherProc(v SomeNumber: int; o SomeString: astring);
  b
    // some code goes here
  e;

  e.


The hideously verbose example above is Oberon/ComponentPascal.

More verbose code that does the same job does not mean more maintainable code or less time spent fixing and concentrating on important bugs. In fact, the compiler can waste time informing the developer of issues that are so obvious they are not worth reporting.

Why not for example repeat the end of the IMPORT clause with IMPORT_END, to ensure the imports are ended? Why not repeat the parameter declarations with PARAMETER_END also? How about VAR END and CONST END as matching phrases for VAR and CONST? What about VAR BEGIN and CONST BEGIN?

Parameter Verbosity

The parameter declarations with VAR and OUT and big words and phrases such as INTEGER and ARRAY OF CHAR span far across the screen and it actually causes horrible CLUTTER. Code that was intended to be on one line (such as parameter declarations) even ends up being split into several lines by some programmers to supposedly help the readability. But is splitting up code into more lines (since it spans so far past the 80 column barrier) necessary? Languages that are not hideously verbose make parameter declarations easier to work with and less noisy. What does "noisy" mean? Well, take a math text and convert all the plus signs and minus signs to ADDITION_TO and SUBTRACT. Ask yourself whether this English ADDITION_TO and SUBTRACT helps the readability? Where does one draw the line and start attacking verbosity negatively?

An Attack

Make no mistake: Niklaus Wirth and the Algol authors are very intelligent in many respects, and their contributions to structured programming were undeniably great. However, obviously they have different aesthetic tastes than many practical programmers.

Where Niklaus, Cobol authors, SQL authors, and others are wrong: programming is not "English". It is not just some repetitive essay, repeating itself over and over again. Yet that is what we see in programming languages like Cobol, Oberon, Ada: needless, repetitive, eye straining noise. Add the CAPS LOCKS to the mixture and some programmers feel like vomiting. Feel free to stop reading if you are offended right now - the author has absolutely no soft feelings for you.

Programming should rather be a notation, as math is. Words should be used for labelling commands to do tasks.. words should not be abusively used for every thing in the language! That defeats the purpose of programming, or math.

One has to ask himself:

Serious Problems of Verbosity

SQL, COBOL, ADA, and ALGOL style languages have been touted as more readable because they are more like English or more verbose. They are indeed more verbose, but not more readable to a programmer. More readable to a beginner and a child, yes.

A mathematician could argue that "ADDITION_TO" is more readable than "+" but we don't hear these arguments from intelligent mathematicians. It seems some programmers are not experienced or awake enough to understand that notation must do the heavy work for us. There is a crowd of programmers who believe we should have heavy notation do light work or no work at all.

The key, of course, is to use words where they are really useful - as labelled commands, methods, procedure names, and function names. Words offer flexibility and extensibility. One can generate a new word out of several letters! Should fixed reserved words such as CONST, VAR, BEGIN, ANSISTRING, END, etc. benefit from this flexibility that words (combined letters) offer us? Of course they cannot - because they are fixed reserved words!

In Algol style languages with a read only param feature, often programmers skip using the feature since by value parameters skip the ugly CONST notation. It gets in the way of an interface or header and clutters up the source. Using heavy CONST and VAR words all over an interface takes away from readability, and causes repeated splattering of "CONST" all over the source. Programmers choose "by value" params often not because CONST params are not useful!

In other words, the syntax and notation of a language, if too baroque and complex, causes programmers to avoid useful features. Worse, it is not immediately apparent to the programmer that he is working around his language instead of with it. Subconscious habits build up, and the programmer works around the language skipping its useful features due to their complex hideous nature. Readability of sources improve when a programmer skips using certain useful notations. Isn't this sad?

If the Plus Sign was Unreadable

If the plus sign (+) was instead the reserved word "ADD_LEFT_AND_RIGHT_ITEMS", programmers would find a way to avoid this nonsense, such as using a function plus(item1,item2) instead. "Add left and right items" is more verbose and should be more readable to the casual person or child under the age of five passing by, should it not? This ludicrous verbose notation ends up not being useful for programmers, who are not casual persons or children.

Subconsciously Avoiding Verbosity

In the case of Delphi and Freepascal languages, Programmers will often use "string" instead of "ansistring". Yet "ansistring" is safer and less ambiguous since "string" could accidentally cause shortstrings to be used (if the ansistring compiler option is off, which has indeed caused numerous hard to find bugs). Even though people know it can cause bugs to use ambiguous "string" type, people still choose to use "string" to work around the verbosity of the language. The code becomes less reliable, more error prone, and less contractual since people choose "string". How sad.

Much sadder is the fact that programmers do not realize they are working around their language. Programmers even lie to themselves and argue with other programmers about how "their language is more like English" and how a more verbose language causes "less errors and is more readable". Hypocrites they are.

Yes, psychologically a programmer doesn't realize that often he or she skips using a useful notation such as CONST or ANSISTRING for the mere reason that CONST or ANSISTRING is too large, ugly, baroque, and less readable.

Ironically, verbose languages are supposed to be more readable (maybe to the casual user or child passing by), when in fact they seem to clutter the screen and cause programmers to find ways to defeat the verbosity (like shoving the big clunky BEGIN on the same line as THEN or END ELSE).

Math Notation And Symbols

The reason math symbols were invented was to reduce the hideous complex mess that large spoken languages like English otherwise would have polluted the mathematical algorithms with. Even though math symbols were initially harder to read for someone who didn't know how to do math, they are obviously superior. In other words: notation is superior to hideously verbose English in many practices (such as math, programming, and music).

Advantages Of Notation

Imagine as a professional musician playing an instrument, one had to read a musical composition in English instead of musical notes! Instead, musicians have successfully let the symbols and notation do the work.

How about Dijkstra's and Leibniz's recommendations of "letting the symbols do the work" and Dijktra's advisement against creating languages that have too much notation that is much like English, or too much like COBOL or BASIC? Taking it one step further, I (Lars) coined a phrase "letting the notation do the work" since it is not just about symbols. Notations are not limited to one letter characters or symbols - they are just short notes which can even be composed of a few letters (but not too many, otherwise they are no longer notes, but full phrases and words).

Unfortunately, most of Dijkstra's articles were not publicly available and only a few insiders were able to read all of his articles at the time of language invention. When some of Dijkstra's articles did get published, people misinterpreted a lot of them - such as the famous "GOTO Considered Harmful" (which Dijkstra did not title "harmful", someone else did. Dijkstra noted later that the people making religions about it misunderstood the intention of the article, which was about showing valid cases against GOTO). People, will therefore, often misinterpret the quote "let the symbols do the work" to mean that Perl and APL were being suggested (->*#%@#<-).

Letting notation do the work does not mean taking everything and turning it into symbols. Words and descriptive labels and names have their use. Words are very extensible and compositional, due to the fact that several combinations of letters make new words! Reserved syntax, however, is not about making new words - and hence there is a separation of concerns. Words should be used for descriptive commands, methods, items added to our modules, types of things. However, large words should not be used for common tasks such as "BEGIN OF THIS CODE BLOCK", "CONSTANT DECLARATION", "END OF THIS CODE BLOCK", "ADD THIS ITEM TO THAT ITEM", "VARIABLE DECLARATION", "READ ONLY PARAMETER", etc. In fact that begs question: why was VARIABLE shortened to VAR? VARIABLE is more readable than VAR. Why wasn't BEGIN shortened to "BEG" to match the three letter word END? Why was CONSTANT shortened to CONST, if the full word "CONSTANT" would obviously help readability and create more reliable programs? The answer is that continual hideous verbosity (instead of precise notation) does not lead to more readable or more reliable programs. COBOL and original BASIC even offer evidence of this.

Obviously there is hypocrisy to be noted: verbose language advocates are willing to create terse useful symbols like "VAR" and "CONST", but at the same time might violently argue against shortening REPEAT to "REP", or BEGIN to "B" or "{".

The more often we use a powerful tool (symbols are tools), such as the plus operator, the more we should consider shortening it into a notation. This is why a plus operator was chosen as "+" by mathematicians instead of ADD_LEFT_AND_RIGHT_ITEM.

Offensive

Ada and COBOL programmers would be in great heat if still reading at this point, since some might feel offended. Letting the symbols do the work isn't exactly what one wants to hear when most of the language he uses is full of large English words.

The fact that a language like Ada offers safety features, modules, and important abstractions is why Ada is relatively successful. That is not a problem. However, its extreme verbose and complex syntax and philosophy makes it much less successful than it could be. This is hard for programmers to admit who are already in love and religiously protecting their existing syntax, notation, and philosophy.

Several people could ridicule Wirth for trying to simplify Algol (he created AlgolW which was an obvious rip off of Algol) and yet his AlgolW successor called "Pascal" became popular since it was simpler and less complex than Algol 68. Cee was of course also popular because it was simpler than Algol 68, and it had practical implementations available without the serious limitations or hefty notation of Pascal and Algol.

Stealing From History

The language AlgolW, Pascal, and Cee were in fact simplifications and stolen ideas from the baroque and complex Algol68/Algol60 languages. A sensitive one may of course be offended by the word "stolen". In fact if one looks closely and does proper study, Pascal and Cee are obvious rip offs. "Struct" vs "Structured Programming" and "AlgolW" vs "Algol" gives clear evidence already. A reader not studied up on history may have never even heard of "AlgolW", the "B language", or "Notes On Structured Programming". If this is the case, the reader should read! Cee took heavily from Bee and Algol, AlgolW took heavily from Algol, Pascal took from AlgolW.

Qomp openly admits to stealing and ripping off useful ideas from modular and structured programming family languages, along with stealing ideas from the extensible programming languages (buzzword is Object Oriented). Heavens though, Mr. Wirth's CAPS LOCKS, Algol's ridiculous verbosity, C++ and Ada's ridiculous complexity, Cee's inside out syntax and declarations and ugly VOID's, and Java's hideous public static class repetition will be abandoned without any regret whatsoever. One must steal only the good ideas - and leave behind the bad ones.