💾 Archived View for thrig.me › blog › 2024 › 03 › 15 › verbosity.gmi captured on 2024-07-09 at 01:19:02. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2024-03-21)

-=-=-=-=-=-=-

Verbosity

46. When those of the Samians who had been driven out by Polycrates reached Sparta, they were introduced before the magistrates and spoke at length, being urgent in their request. The magistrates however at the first introduction replied that they had forgotten the things which had been spoken at the beginning, and did not understand those which were spoken at the end. After this they were introduced a second time, and bringing with them a bag they said nothing else but this, namely that the bag was in want of meal; to which the others replied that they had overdone it with the bag. 38 However, they resolved to help them.

The History of Herodotus — Volume 1 by Herodotus

Herodotus may be having some fun here at the expense of the Spartans, who did get their revenge a bit later on. Laconic, or the opposite of verbose, was derived from the region formerly occupied by the Spartans (and quite a lot of slaves). Someone was asking whether there is a word for someone who uses too many words; verbozo from 'verbose' and 'bozo' was proposed. "Likes the sound of their own voice" is sometimes voiced, but that seems a tad… verbose?

Blovate took longer to recall.

All-hands meetings or sermons that go on for too long are one thing; if the story (or the speaker) is good one may not mind.

Programming languages also fall under the verbosity debate. One claim is that code is read more often than written, so should be more verbose to assist the more readers. Others dislike a verbosity that spreads everything out, and may have piles of code that almost nobody reads most of the time. There's probably a Goldilocks zone, but sizing that zone varies by programmer, the language involved, skill, memory, and doubtless other factors. Core libraries and operating systems probably need more work on them for readability and testing than things out on the frontier.

How about a simple countdown timer? Here we have various loops that start at one minus the input number and decrement a counter down to 0. The "..." bits are where code for the body of the lopp would go.

    for (size_t j = n - 1; j < SIZE_MAX; --j) {
        ...
    }

    : DOWN 1- 0 SWAP DO ... -1 +LOOP ;

    (loop for j from (1- n) downto 0 do
      ...)

    for j in range(n-1, -1, -1):
        ...

    for my $j ( reverse 0 .. $n - 1 ) {
        ....
    }

Does the loop stop before, at, or after the checkpoint? How much of this relies on the programmer knowing something, or being able to write tests for the various edge cases?

Requirements also change over time; a new system that gets popular probably needs more documentation, tests, and formalisms. On the other hand, having too much documentation may mean that the wrong procedures are followed, which can result in what might be called a whoops. There's also the problem of teaching what is necessary to subsequent generations… or what to teach; is how to pass the next test really a good education?

See Also

    Aceves, P., Evans, J.A. Human languages with greater information
    density have higher communication speed but lower conversation
    breadth. Nat Hum Behav (2024).
    https://doi.org/10.1038/s41562-024-01815-w