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?

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

18 Answers 18


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:

print "Hello World!"

Noise wastes mental energy.

Cryptic vs Clear

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
  • 20
    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, 2012 at 13:52
  • 68
    For any program actually doing something Java frequently gets quite a lot more readable, especially with good library usage.
    – user1249
    Mar 23, 2012 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, 2012 at 14:42
  • 23
    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, 2012 at 15:00
  • 27
    +1 for the distinction between Signal vs. Noise and Cryptic vs. Clear
    – Spoike
    Mar 23, 2012 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.

  • 20
    I believe this is the ultimate reason. Readability on a limited space like a piece of paper or a monitor.
    – user1249
    Mar 23, 2012 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, 2012 at 14:45
  • 1
    @ZJR - see edit. Mar 23, 2012 at 14:48
  • 3
    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. Mar 23, 2012 at 15:08
  • 10
    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, 2012 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


It really boils down to what a coder is familiar and comfortable with.

  • 6
    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.
    – Andy Hunt
    Mar 23, 2012 at 12:47
  • 8
    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#).
    – dagnelies
    Mar 23, 2012 at 13:01
  • 10
    VB.NET is not verbose compared to some other worse offenders!
    – user7519
    Mar 23, 2012 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, 2012 at 13:52
  • 7
    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. Mar 23, 2012 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
        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.

  • 15
    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, 2012 at 14:36
  • the Applescript IDE, Script Editor, in the 90s, used to help coping with verbosity with applescript recording of actions, it wasn't horribly smart, but kinda handy while scripting Finder... around 1998 recording kinda broke up and was never fixed again. (dunno if OSX transition fixed that, IIRC, no)
    – ZJR
    Mar 23, 2012 at 14:51
  • 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, 2012 at 15:41
  • The worst thing about AppleScript is that every application you want to drive with it can have different terminology. Apple defines certain suites of commands that all programs should support, but in general, knowing how to script one application is only of limited help in scripting another.
    – kindall
    Mar 23, 2012 at 17:06
  • 3
    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, 2012 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.

  • I would not consider terse the oposite of verbose. Verbose carries a negative connotation, so would likely be better suited for an antonym carrying a positive connotation. Mar 23, 2012 at 15:21
  • 6
    terse is the antonym of verbose, terse can carry just the same negative connotation ( see Perl )
    – user7519
    Mar 23, 2012 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 Mar 24, 2012 at 3:06
  • 1
    @ScottMitchell en.wiktionary.org/wiki/terse#Antonyms
    – naught101
    Mar 24, 2012 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.


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)

  • I cite the original version since it is the most concise. :-)

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.

  • 5
    How does this answer the question?
    – ChrisF
    Mar 23, 2012 at 13:05
  • verbosity is different for everyone. That was the intent of my comment. If you are in the C/C++ camp, accepted verbosity is different compared to if you are in the perl camp.
    – Nasir
    Mar 23, 2012 at 13:19
  • code written by a perl ninja is nothing short of magic? Seriously, I think it's a nightmare.
    – Kevin
    Mar 24, 2012 at 4:30
  • i steer clear of perl :)
    – Nasir
    Mar 24, 2012 at 5:10
  • For programmers COBOL may be too verbose in comparison to other languages. However, well written COBOL can be easy for business clients to read. This allows them to verify the code does what they require by reading it.
    – BillThor
    Mar 25, 2012 at 19:33

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.

  • No-one's against comments. The problem is languages like java, applescript, or Visual Basic, which have a lot of redundant but compulsory elements.
    – Marcin
    Mar 23, 2012 at 15:40
  • 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. Mar 23, 2012 at 15:42
  • The question is about programming languages though. Mar 23, 2012 at 15:58
  • 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. Mar 23, 2012 at 16:01
  • It might be argued that a function shouldn't consist of more than a few lines anyway. If it's hard to grasp how the function works, it's probably not because of too many comments. But I agree that comments which only say what's immediately clear anyway should better be avoided. Mar 23, 2012 at 19:01

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:

  • 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.
  • really how much scrolling is done on a 1920 X 1080 screen with a reasonably readable font size? There are also these things called keyboard shortcuts for navigation either way.
    – user7519
    Mar 23, 2012 at 14:53
  • @JarrodRoberson - My screen shows approximately 30 lines. If I make the code window full screen and lower the font size to be barely readable, I get 60 lines. I've had to work on several thousand line files (not by choice, I assure you). I do use the "navigator" in my IDE, but it's still nowhere near as convenient as glancing between two sections of code that are both on the screen. Mar 23, 2012 at 15:03
  • Doesn't your IDE support split views? Mar 23, 2012 at 19:04
  • 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. Mar 23, 2012 at 19:08
  • I vaguely remember that there are actually studies demonstrating this to be true (particularly the scrolling part). Having to scroll to see a whole logical unit makes it harder to comprehend. Sounds plausible, at the very least. Mar 24, 2012 at 20:07

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)

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.

  • Verbosity in many cases increases the likelihood of typographical errors being detected at compile-time rather than simply yielding erroneous behavior.
    – supercat
    Apr 22, 2014 at 12:59

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.

  • 2
    I'd expect far more hidden bugs in 100 typical lines of Perl than in 300 lines of Ada. — As to "since write less codes means machine needs to do more things and it will decrease the efficiency", there may be such a correlation but it's not causality. It's just that the terse dynamic and/or interpreted languages like Ruby, Perl and Python tend to be slower than the more verbose static compiled languages like C or Fortran. But terse compiled Haskell, Python w/PyPy or C++ programs may be much faster than verbose e.g. interpreted Basic, Groovy, Smalltalk, or even C# code. Mar 25, 2012 at 18:21

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.

  • 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? Mar 23, 2012 at 14:27
  • 2
    I prefer verbose code written in concise languages. Mar 23, 2012 at 14:46
  • @Joshua: yeah, I noticed that it can be interpreted in very different ways, so I edited my answer. ...and what has java to do with it?
    – dagnelies
    Mar 23, 2012 at 14:59
  • 1
    A comment to state why it was downvoted may be more interesting than the downvote itself.
    – dagnelies
    Mar 23, 2012 at 15:09
  • @arnaud my bad for using wiktionary. The google search define:concise starts: "Giving a lot of information clearly" which your sample code clearly violates. Although I have to acknowledge the original implication of terse, clear and concise now travel togther. Mar 23, 2012 at 15:17

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.

  • 1
    Balanced brackets and semicolons are redundant, as to a large extent are type declarations.
    – Marcin
    Mar 23, 2012 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, 2012 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, 2012 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, 2012 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, 2012 at 14:51

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.

  • With this "late binding" you probably mean virtual function calls. But that's just one way amongs many others to achieve code reuse. Dynamic typing is another, and would probable make a better example to your point as is tends to come with a lot more overhead than C++' virtual calls. But there are also mechanisms that don't impact runtime performance at all because they can be fully resolved at compile time: in modern object-oriented languages you have templates/generics, in static functional languages parametric polymorphism. Mar 24, 2012 at 22:58
  • Late binding is what is used to make virtual function calls work, so no I didn't "mean virtual calls", I meant late binding. Virtual calls are part of the language definition, late binding is what makes that part work. And, yes, of course there are other examples in other languages, I was offering an example of the potential for trade off between expressive power and speed, not recommending one language over another. Mar 25, 2012 at 3:57

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.

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