Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
I have seen many people around complaining about verbosity in programming languages. I find that, within some bounds, the more verbose a programming language is, the better it is to understand. I think that verbosity also reinforces writing clearer APIs for that particular language.
The only disadvantage I can think of is that it makes you type more, but I mean, most people use IDEs which do all the work for you.
So, What are the possible downsides to a verbose programming language?
"Verbose" means "uses too many words". The question is what "too many" is.
Good code should be easy to comprehend at a glance. This is easier if most of the characters directly serve the purpose of the code.
If a language is verbose, more of your code is noise. Compare Java's "Hello World":
class HelloWorldApp {
public static void main(String[] args) {
System.out.println("Hello World!");
}
}
... with Ruby's:
print "Hello World!"
Noise wastes mental energy.
On the other hand, excessive terseness in a language also costs mental energy. Compare these two examples from Common Lisp:
(car '(1 2 3)) # 3 characters whose meaning must be memorized
# vs
(first '(1 2 3)) # 5 characters whose meaning is obvious
It affects how much code you can see and parse in a single glance
x++ rather than set(x,Integeradd(get(x),1))
ps. It's not just a matter of reading code. In the days of 40x25 screens then APL type languages, or Perl, were useful over Cobol or Fortran for the amount of code you could read/page. But now it's more about your own internal cache - if a statement has a single operator it's easier for my ageing brain to parse than one with 3 symbols and 4 function calls.
set method do here? Does it actually set something (i.e. the first x parameter) or does it return something (i.e. the assignment to x after the call)? I would say there's some odd duplication going on in the verbose example.
Mar 23, 2012 at 15:08
+ is more meaningful than plus. = is better than equals. This of course can be taken too far (and has been by several languages) but when used in moderation, is very powerful.
If the language verbosity detracts from code readability, then it is bad.
Some languages have such verbose syntax that grasping the meaning of the code takes longer (I am thinking about VB.NET versus C#):
If something Then
End If
if(something)
{}
It really boils down to what a coder is familiar and comfortable with.
If .. Then .. End If and read only what's important.
Mar 23, 2012 at 12:47
Go look at AppleScript, one of the most verbose languages I can think off that could be considered current, try to write something trival in it and come back and try and argue that verbosity is a good trait in a language.
Trying to remember all the semantics of where the keywords go and what they are is non-trivial if you don't do it every day.
Just look at all the keyword noise in this trivial example:
tell application "Finder"
if folder "Applications" of startup disk exists then
return count files in folder "Applications" of startup disk
else
return 0
end if
end tell
granted the same thing in bash with traditional Unix tools would be terse but cryptic to most OSX users, so there is a balance that must be struck.
return the 0 when you typed that? AppleScript is the only language I know that allows keyword-griefing you opponents... I mean co-workers.
I think you need to turn the question on it's head and ask: Why do some people think terse code is good?
My answer would be that there are two basic reasons:
Reasons Why Terse Can Be Better
These include being more readable, in the same way that a short sentence can be more understandable than a flowery, verbose sentence. Often programming languages that try and emulate the grammar of the English language end up being horribly long-winded, requiring huge expanses of code to perform the simplest actions. Often you'll find that the more a language emulates a written language then the harder it is to coax it into performing logically complex operations.
Reasons Why Terse Can Be Worse
Some languages (and I'm thinking of Perl) use an array of strange symbols, which seem to have been almost arbitrarily selected, as part of their syntax. To anyone not familiar with these hieroglyphs then the language becomes impenetrable. It also becomes easy to make typo mistakes that aren't easily seen. Regular expressions perhaps epitomise this kind of terseness.
Also, some people like to show-off by writing terse code because, frankly, they think it makes them look clever. You see this sometimes on StackOverflow, where people often will submit answers that are extremely compact at the expense of readability. This is a kind of "impress your peers" with how much you know philosophy, but good programmers realise that "code golf" isn't the way to create maintainable software.
terse is the antonym of verbose, terse can carry just the same negative connotation ( see Perl )
terse as an antonym of verbose (or vice versa). /ducks
Mar 24, 2012 at 3:06
@frowing, I would suggest that one way to look at the verbosity issue is to realize that programming is always some mix of two rather different styles of finding and expressing a solution.
The first and more verbose style is language-oriented (linguistic) programming. This style combines noun-like words and verb-like words within sentence-like structures, and it is intended to be read and understood in much the same fashion as a well-written paragraph. Linguistic programming is the most universal style of programming since language itself is universal. For that same reason, long-term program support always needs a powerful linguistic component, since the first thing a new programmer will look for is as conceptual understanding of what is being done. As a general rule, the farther away you move from the context in which you created a program, the more important a linguistic style of programming will be for ensuring that your assumptions and concepts will not be misunderstood by the next person trying to understand your code. Your own example of using a more linguistic style of programming to reduce ambiguity in APIs is a good example of that principle.
The second and more concise style is math-oriented (mathematical) programming. This style of reasoning also relies on language, since for example variables are analogous to nouns and operators to verbs. However, mathematical reasoning leverages the amazing and highly parallel ability of our brains to do complex spatial transformations on objects that are within our line of vision. By representing nouns and verbs as compact, distinctive symbols that can be arranged into well-structured imaginary objects -- equations -- we can then use our highly parallel visual capabilities to perform rotations, replacements, movements, inversions, and other transformations on these imaginary objects. The result is an enormous amplification of the number of cases we can handle at once, since each symbol can represent entire classes of closely related objects.
Notice that to apply visual processing effectively, you need to keep your imaginary object as similar as possible in size and features to a real object. If the needed field of vision gets too wide, or the symbols can’t be used like movable marks on an object, or if you have to “read letters” and convert them into words, the ability to perform complex transformations reliably will fall off quickly even for a very good mathematician.
That is why people immersed deeply in the mathematical style of programming can get seriously unhappy if an equation is spread out and expressed in what they would call a “verbose” linguistic style. It’s not because the equation has been changed significantly, it’s because spreading it out like that can make it nearly impossible to apply a visual style of understanding to it. Yet at the same time, a new programmer who is not at all familiar with the short symbols is likely to prefer a more verbose version that provides more linguistic information for initially understanding what the code does.
So what would I recommend?
Use both styles, but pay careful attention to why you are using each style.
For example, anything that has a chance of interfacing with the outside world should be intensively verbose at some level, even if only in the form of inline comments mixed with the code, and should also include automated checks for correct usage. Cryptic and especially incompletely defined notations have no business in such interfaces, since they are almost guaranteed to get misunderstood at some point. The 1999 loss of the Mars Climate Obiter due to a failure to recognize whether software interface units were expressed in pounds or Newtons is a particularly pointed example of the dangers of relying too casually on raw numbers at software or hardware interfaces.
Conversely, any form of programming that is deeply algorithmic and mathematical in nature is a good candidate succinct programming that supports the mathematical style of reasoning. If someone new must maintain such code, it would usually be better for them to learn the mathematical notations instead of trying to transform the code into more verbose forms. There should of course at all times be documentation easily available to explain the mathematical parts the code available to such developers, but that is a separate issue.
In between these extremes are many cases where the programmer has considerable discretion. I would suggest looking at how the code will be maintained in the long term, and trying to accommodate the needs of the people most likely to be maintaining the code in the long term.
A number of people have hinted at something that I think should probably be stated explicitly.
Verbosity tends to favor understanding at the microscopic level -- it generally leads to an individual statement being easy to read and understand. Verbosity also tends to reduce the degree of familiarity with the language necessary to understand it (to at least some degree). The most verbose languages (e.g., COBOL) can be at least somewhat readable even by complete non-programmers.
Concision tends toward the opposite: it helps understanding at the macroscopic level, especially by programmers with the most intimate familiarity with that particular language. At the same time, lack of familiarity with that specific language can prevent even rudimentary understanding, even from programmers who are otherwise quite experienced.
As such, readability varies widely depending on the target audience. On one hand, consider a large, complex project being written and maintained by people who work almost exclusively on that project, most of whom have substantial programming background and education (e.g., lots of PhDs). This will tend to favor a more concise language.
At more or less the opposite extreme, consider a project that's considerably simpler (though possibly still quite large) that's maintained primarily by people who really specialize in the business associated with the software, rather than in the software itself. This will almost certainly favor a much more verbose language.
Rather than go to a technical book, I revert to the Elements of Style* by Strunk and White. The underlying concept is "Be precise" and "Don't say more than needed." Everything else is commentary.
Applied to programming, it's about being very precise, but not having unneeded fluff. The extra fluff can be syntax, but it could also be more words than required to convey meaning. (Of course not too few to allow ambiguity either)
At the end of the day, anything which is 'different' will cause people to howl. I am comfortable with C style syntax and hence ok with other languages which share similar syntax (C++, Java, C#). So i tend to favour this particular style.
Languages tend to find a balance between descriptive enough, and not verbose.
Perl is an example of where you can write very concise code. For the uninitiated, code written by a Perl ninja is nothing short of magic.
COBOL is an example of too verbose.
I read somewhere once that a great deal of the verbose debate comes from new programmers vs old hands. The analogy used was that when we learn something new, we tell ourselves a "story" to get through it (think of when you learned algebra in HS). As we gain experience, we move beyond the need for a story explaining individual components and we comprehend a greater amount. Our code becomes denser and more terse, with comments only explaining the necessary items, instead of reiterating what the code says.
I've found this to be true between me and a coworker. She writes code with lots of comments explaining what the lines of code are, and lots of white space. If I'm reading it, I find that I can only fit a few lines of code on one screen because of this. That makes understanding each individual line far easier, but grokking the whole function becomes much harder.
I tend to write code without the extra whitespace or comments. This makes seeing the whole far easier, but you have to be able to simply "get" the individual code "words". If you tried to read this answer with each word being on it's own line, with lots of whitespace/comments/extra verbiage then it would be far easier to understand each individual word, but far harder to understand the whole.
i++; //this is adding one to var i it is redundant.
Mar 23, 2012 at 15:42
Einstein got it right: "Make things as simple as possible, but not simpler."
This applies to code as well. If you can simplify code by removing repetitive and needlessly verbose elements, that is a good thing.
Also, some case studies suggest that programmer productivity measured in lines of code is more or less a constant. So is the number of bugs per LOC. So switching to a language that allows you to do more per line of code can be considered a productivity improvement, if all other things stay equal.
That being said, there is a tendency in this industry to over engineer and complicate what should be simple things. Simple things like stuffing contact details in a relational database. I've seen some ridiculously complicated and misguided solutions (cough MDA) for that particular problem. Languages like Scala and Ruby are good examples of powerful tools that in the hands of certain individuals result in unintelligible, overly complicated, and poorly maintainable code. Just because you can use multiple levels of indirection with a few key strokes doesn't mean you have to wack every nail in sight with that particular hammer.
When used properly, you get nice clean code that is both short and easy to understand. When used poorly, you are better off confining the individual in question to using visual basic or a similarly limited language to prevent further damage.
True skill lies in making complex things in a simple way, not in making simple things in a complicated way.
Something no one else has hit is in the amount of code you can fit in one screen. It helps for several reasons:
Verbosity being a tendency to use extensive amounts of text, and Terseness the use of very little text...
Verbosity is bad because:
A certain level of verbosity is essential for clarity, however...
a minimal level of Verbosity is good because:
Some wonderful examples of overly terse commands for many people include the old BASIC standbys of val(x$), str$(x), and 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 & and * 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)
...
Foo(x)
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.
Because more code means more development times and more bugs.
If you write 100 lines of codes rather than 300 lines of codes. That means almost 1/3 development times you need and 1/3 potential bugs you may meet.
In most circumstances you need to balance efficiency and the conciseness, since write less codes means machine needs to do more things and it will decrease the efficiency.
Usually, people favor readable/verbose languages over cryptic/terse ones. However, I think most people assimilated "verbosity" with "clutter", which are not the same thing.
For instance: while(<>){print if($.==2 || $& && !$x++); $.=0 if (/^--+$/)}
is a very terse statement. It contains everything you want to know. However, because of it's terseness, it's hard to understand. On the other hand, a slightly more verbose version of the same program would be fairly straightforward to understand because it is more readable. This is of course not a property of the language per-se, but some languages tend to more verbosity while others tend to more conciseness in their way of programming.
To the other extreme of verbosity, is http://en.wikipedia.org/wiki/Literate_programming , which I consider a pretty interesting concept.
One other aspect is "unwanted verbosity", also called "clutter". Things you have to add for technical reasons, lack of syntactic sugar, bloated APIs, and so on.
I think a clear and intuitive syntax is very important. It also has to be verbose enough to facilitate an easy reading. Too short statements packed with too much logic can often lead to more time to decypher than their slightly longer counterparts. On the other hand, useless bloated code full of boilerplate lines to do something utterly simple is equally a nuisance.
Like with so many things, the answer depends on the concrete definition of "verbosity". If the definition is such that verbosity implies redundancy then I would argue it is always bad. Note that with such a definition the often cited Java hello world program would not qualify as "verbose", because there is nothing in it that is redundant.
Programmers tend to like languages with expressive power as it allows them to code up the simple things, which often have to be done frequently, in small pieces of code. Verbose languages tend to mean that many, many lines of code have to be used to do the same thing over and over again. However, there can be something of a price to be paid with expressive languages as they may not be as fast to execute as simpler high level langauages. If I can give an example in the contrast between C and C++. C++ gives more expressive power to code writers - they can encapsulate the idea of real world objects in classes. C programmers can achieve the same things but they do have the expressive power of the class construct to help them - so often they have to write longer, more complicated (to understand) code. But that code may well run faster (though this is highly dependent on compiler quality and so on) because it does not use C++'s "late binding" (ie run time refactoring) to execute the code. C just executes the compiled and linked code, C++ has to make a decision (in certain circumstances) at run time about which pieces of code to execute.
I believe that there is an answer to the question rooted in a more fundamental and theoretical issue than readibility and this answer is related to the algorithmic information theory founded by Gregory Chaitin: http://en.wikipedia.org/wiki/Algorithmic_information_theory. Stated in few words, "the information content of a string is equivalent to the length of the shortest possible self-contained representation of that string", This implies that the shortest program (namely in terms of its lexicographic length) solving a given problem closely matches the intrinsic complexity of the problem to which it gives a solution and, thus, it depends more on the problem nature and less on the representation of the problem.