Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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 that do all that work for you.

so, What are possible downsides to a verbose programming language?

share|improve this question

We're looking for long answers that provide some explanation and context. Don't just give a one-line answer; explain why your answer is right, ideally with citations. Answers that don't include explanations may be removed.

closed as not constructive by Jarrod Roberson, gnat, Walter, Jonas, Mark Trapp Mar 26 '12 at 5:40

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

16  
Have you been coding in APL recently? –  SK-logic Mar 23 '12 at 14:42
5  
Check out Languages, Verbosity, and Java by Dhanji R. Prasanna –  Jeremy Heiler Mar 23 '12 at 14:57
45  
"A developer only has a certain number of keystrokes in them before they die" –  CamelBlues Mar 23 '12 at 16:38
7  
Perhaps you should ask the "many people complaining" what their reasons are. –  Eric Lippert Mar 23 '12 at 19:46
20  
@EricLippert, I believe P.SE is a perfect place to query a large number of "complaining" developers. –  Kevin McCormick Mar 23 '12 at 21:44

18 Answers 18

up vote 128 down vote accepted

The goal is quick comprehension

"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.

Signal vs Noise

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:

puts 'Hello World!'

Noise wastes mental energy.

Cryptic vs Clear

On the other hand, excessive terseness in your code can be cryptic.

t = st * tr
# vs
total = subtotal * tax_rate

Cryptic code also wastes mental energy.

share|improve this answer
16  
I would say that the latter is about readability at the micro level (where we usually prefer more verbose notation) where as the former is about readability at the macro level (where we usually prefer more brevity) –  jk. Mar 23 '12 at 13:52
54  
For any program actually doing something Java frequently gets quite a lot more readable, especially with good library usage. –  user1249 Mar 23 '12 at 14:38
9  
actually a better example of macro scale verbosity might be patterns that work around a missing language feature –  jk. Mar 23 '12 at 14:42
11  
I would say that example with Java is not the best one, too. Such things as the need to define a class and a method matter in code golf, but hardly in real applications. It not like Java requires a lot of code to output a few words, these few lines are required to create a program, and that's different. –  Malcolm Mar 23 '12 at 15:00
19  
+1 for the distinction between Signal vs. Noise and Cryptic vs. Clear –  Spoike Mar 23 '12 at 15:48

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.

share|improve this answer
14  
I believe this is the ultimate reason. Readability on a limited space like a piece of paper or a monitor. –  user1249 Mar 23 '12 at 14:37
1  
+1, and completely agree, and I code on a 13" laptop, but then again this site has 3 monitors as their logo... must be somewhat related :) –  ZJR Mar 23 '12 at 14:45
1  
@ZJR - see edit. –  Martin Beckett Mar 23 '12 at 14:48
2  
So what does the 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. –  Jesse C. Slicer Mar 23 '12 at 15:08
7  
One thing that's missing here is the usefulness of ideographs - that symbols can be more meaningful than words. E.g. + 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. –  mcmcc Mar 23 '12 at 18:56

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.

share|improve this answer
4  
I work in C# mostly, but when I do read VB I find I read it as if it were C#. I ignore all of the If .. Then .. End If and read only what's important. –  AndyBursh Mar 23 '12 at 12:47
6  
same as Andy. I find both equally readable. I would even tend to say that i prefer a little VB's variant (despite I'm more used to c#). –  arnaud Mar 23 '12 at 13:01
7  
VB.NET is not verbose compared to some other worse offenders! –  Jarrod Roberson Mar 23 '12 at 13:02
3  
@AndyBursh - Exactly my point. When reading VB.NET you do some mental translation above and beyond understanding the code. –  Oded Mar 23 '12 at 13:52
5  
Oded, End-If is a much easier-to-understand construct for the end of a if-statement than brackets when the brackets are nestled inside of another if-statement, inside a loop, inside another loop, inside a function that is inside a class. All of the aforementioned blocks use the same brackets, meaning that trying to figure out which one a particular end-bracket matches less intuitive. –  Andrew Neely Mar 23 '12 at 16:04

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.

share|improve this answer
9  
Didn't you want to return the 0 when you typed that? AppleScript is the only language I know that allows keyword-griefing you opponents... I mean co-workers. –  ccoakley Mar 23 '12 at 14:36
3  
The OSX answer to AppleScript's cumbersomeness is Automator. Let's replace easy-to-type text with a giant library of draggable, verbosely-described, and poorly-explained functionality blocks! –  fluffy Mar 23 '12 at 15:41
1  
Applescript is cumbersome to write, but easy to human comprehend... within the bounds of programmers putting the applescript hooks in with intelligible syntax into the driven application. –  aramis Sep 11 '12 at 22:40

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.

share|improve this answer
3  
terse is the antonym of verbose, terse can carry just the same negative connotation ( see Perl ) –  Jarrod Roberson Mar 23 '12 at 18:29
1  
@JarrodRoberson: I hate to be pedantic on a Friday night of all things, but I looked on a few online thesaurus's and none of them have terse as an antonym of verbose (or vice versa). /ducks –  Scott Mitchell Mar 24 '12 at 3:06
1  
@ScottMitchell en.wiktionary.org/wiki/terse#Antonyms –  naught101 Mar 24 '12 at 12:12

@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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
5  
How does this answer the question? –  ChrisF Mar 23 '12 at 13:05

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.

share|improve this answer
2  
@Marcin I'm not against comments either, but when they are like this: i++; //this is adding one to var i it is redundant. –  Spencer Rathbun Mar 23 '12 at 15:42
2  
@BrendanLong Hmm, mayhap I wasn't clear. I was equating unnecessary comments with verbose programming languages. Lots of words to say the same thing, only a verbose programming language requires them at all times. –  Spencer Rathbun Mar 23 '12 at 16:01

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)

  • I cite the original version since it is the most concise. :-)
share|improve this answer

Something no one else has hit is in the amount of code you can fit in one screen. It helps for several reasons:

  • Less scrolling back and forth when you're working on (or reading) multiple functions in one file.
  • Less horizontal scrolling (stop reading, click and drag scroll bar, stop reading, click and drag scrollbar...).
  • Faster scanning, since there's less useless syntax getting in the way of finding what you want.
share|improve this answer
2  
You're both missing the point -- whether my IDE can make scroll less bad, it will never be as good as not having to scroll (or use hotkeys, or splitscreen) at all. It's like saying "On screen keyboards are just fine, haven't you ever heard of clicking on things?"; Obviously I have, but it doesn't beat having a real keyboard. –  Brendan Long Mar 23 '12 at 19:08

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.

share|improve this answer

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.

share|improve this answer
4  
You may want to double check the [meaning of concise] (en.wiktionary.org/wiki/concise), as it is nearly an antonym of cryptic. Do you perhaps code in Java? –  Joshua Drake Mar 23 '12 at 14:27
2  
I prefer verbose code written in concise languages. –  Brendan Long Mar 23 '12 at 14:46
1  
A comment to state why it was downvoted may be more interesting than the downvote itself. –  arnaud Mar 23 '12 at 15:09

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.

share|improve this answer
1  
Balanced brackets and semicolons are redundant, as to a large extent are type declarations. –  Marcin Mar 23 '12 at 15:38
1  
@Marcin: Yeah, but they make writing a parser/analyzer for the language easier. I'm fairly convinced that such syntax exists for the benefit of the language implementer, not the programmer using the language. –  ccoakley Mar 23 '12 at 16:24
1  
@Marcin - depends entirely on the language whether type declarations are or are not needed. Certain type systems are simply not decidable, hence .... regarding brackets and semicolons, well, you'd rather want a language with an unambiguous grammar and a short lookahead - or else compiling even small programs could take hours and at the end you got to choose which interpretation of your program you prefer. –  Ingo Mar 23 '12 at 19:00
1  
@ingo I am not aware of any language in which all variables or functions must have a type declaration because of the complexity of the type system. In fact, I would say that languages with more powerful type systems are more likely to allow such declarations to be omitted. –  Marcin Mar 24 '12 at 8:08
1  
@Marcin, no reason to get angry. You said I would say that languages with more powerful type systems are more likely to allow such declarations to be omitted and I gave you an example, where a more powerful type system requires more type annotations. If you feel that doesn't contradict your stetement, then well, so be it. –  Ingo Mar 24 '12 at 14:51

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.

share|improve this answer

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.

share|improve this answer

Verbosity being a tendency to use extensive amounts of text, and Terseness the use of very little text...

Verbosity is bad because:

  1. it introduces more opportunity for typographical error
  2. it makes it harder to read code on screen or paper, and/or enter on punchcard
    1. this increases debug times
    2. this makes comprehension of code for upgrade/maintenance harder
    3. this can lead to unintended code duplication
  3. it increases the likelihood of syntax error somewhat
  4. it decreases coding flexibility, in that, most verbose languages are highly structured and don't have multiple ways to say the same thing.
  5. it increases coding and compilation times
  6. it can take more storage space.

A certain level of verbosity is essential for clarity, however...

a minimal level of Verbosity is good because:

  1. it is easier for humans to read and attach semantic value to than purely symbolic code
  2. In variable and function naming, it makes it easier to debug, port, and maintain code
  3. 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 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.

share|improve this answer

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.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.