Verbosity being a tendency to use extensive amounts of text, and Terseness the use of very little text...
Verbosity is bad because:
- it introduces more opportunity for typographical error
- it makes it harder to read code on screen or paper, and/or enter on punchcard
- this increases debug times
- this makes comprehension of code for upgrade/maintenance harder
- this can lead to unintended code duplication
- it increases the likelihood of syntax error somewhat
- it decreases coding flexibility, in that, most verbose languages are highly structured and don't have multiple ways to say the same thing.
- it increases coding and compilation times
- it can take more storage space.
A certain level of verbosity is essential for clarity, however...
a minimal level of Verbosity is good because:
- it is easier for humans to read and attach semantic value to than purely symbolic code
- In variable and function naming, it makes it easier to debug, port, and maintain code
- in base level language operations and keywords of complex languages, it leads to fewer incorrect operation/keyword assignments.
Some wonderful examples of overly terse commands for many people include the old BASIC standbys of
chr$(x)... return a number from its string representation, return a string for a number, and return a single character having ascii value x as a string.
Or the C/C++ pointer and by reference operators
* versus the BASIC
byref keyword. In C/C++, I can have a variable X, and a pass a pointer to that variable, but I have to remember which is the pointer and which is the "use pointer as the variable it points to"; in basic, I simply pass the reference with a byref keyword in the function call, which is more clear, but less flexible:
def fn Foo(x byref as float) foo= (x += x+1)
In this code, x's contents get modified due to the byref flag. Some flavors allow byref at call, others in definition, some in either.
The verbosity is important for casual programmers to be able to use the symbolism easier; BASIC or python are more human readable and more verbose than C/C++, and thus much more useful for casual programmers; the terseness of C/C++ makes it much better for more experienced programmers, who need to see more code and more complex code at one screenful, but have had to learn the various symbolic structure conventions. At the far end is APL, which is almost completely human unreadable.
An intimately related issue is clarity - terse code is often unclear, and excessively verbose code (as in AppleScript) can be equally unclear. Familiarity with a given language increases the clarity of terse code within that language - a raw beginner, facing C++ code is likely to be able to parse only the formulae, and even much functional BASIC or Python code is too terse for comprehension, but applescript can be puzzled out, generally, without recourse to language dictionaries. The least clear I've encountered without intentional obfuscation is Inform 7...
In the olden days
Another important consideration in the past, but one that is no longer as important for the hobby coder, is operation and storage space. (It's still vital at the high end.) Keeping in mind that many languages were interpreted, especially BASIC flavors, and many more were run-time compiled, code space was important, especially when disks only held 128KiB, and individual punchcards only 80B.
Several solutions existed - tokenization was extremely common in BASIC; the individual language keywords were reduced to a 1 or 2 byte word in either the upper 128 or the control character space. Tokenization lead also to bytecode compilation (as in Inform and the Z-Machine).
Multiple object file compilation and linking also was used to get around space limitations. A 100KiB Pascal code section might compile to only 5KiB; by linking multiple compiled files, one could build massive applications without having access to large format drives (remembering that 10MiB was astonishingly large, and buy a new car expensive).
More terse languages, however, got more code into a given chunk of both disk and ram, and thus compiled larger chunks at a time. Keeping in mind: "minicomputers" of the early 1970's might have only 64KiB of ram (the Honeywell 800 had a base install of 4 banks each of 2048 words of 8B each). APL and similar symbolic languages approached 1B per instruction plus its operands, versus the much larger 3B-10B per instruction plus operands. (It was a nightmare to type onto punchcards, especially since the symbols were essentially a font on type-ball, and many cardpunches didn't have the symbols on the keys...)
Also, keep in mind that cards could not be erased... and many programs were entered on cards. While not individually expensive, the more compressed your code could be on the card, the fewer you needed, and the larger the programs could be, or the less expensive. This is part of the reason BASIC has a concatenation of multiple instructions per line in most flavors - it was introduced to save on punch cards. (Or so says my Vax Basic programming text.) While I've not programmed for a card-reader, I've done the card punching for a Honeywell 800 in FORTRAN, BASIC, APL, and a couple other highly symbolic languages.