Personally, I think that there are several benefits of concise code -- as contrasted with either obfuscated code or "long-hand" code.

They are same benefits that a VHLL has over a HLL. Doing the same thing, with fewer lines -- within sensible constraints of clarity -- mean that:

• there are less lines to have (or aquire) bugs.

  Provided combined line represents a single logical step of the algorithm, then making it 'indivisible' can be highly beneficial. It means that extra lines cannot be easily inserted at inappropriate places between two parts of that logical step by accident. This avoids one of the classic sources of errors induced during maintenance.

  Of course, it can mean that it becomes necessary to later break the line up when requirements change. But this isn't necesarially a bad thng as the very fact that it muct be broken up, forces the programmer to attempt to understand why it was combined in the first place.

• it is easier to get an overview of the structure of each logical piece of code, if each subroutine, method or logically self-contained block within the algorithm, is viewable within your editor on a single screen.

  Personally, this is of great importance to me as a programmer. I am always uncomfortable with monolithic lumps of code that wander off the bottom of my screen leaving me in a position of having to scroll up and down to view the complete algorithm.

  It's one reason that almost the first thing I do when I encounter code that has large volumes of embedded comments is to remove them. If the comments are (IMO) accurate and valuable to understanding the code, I may chose to move them into a single block preceding the block(s) of code to which they relate. But generally, I find that I don't trust them enough to rely upon them, prefering to derive my understanding from the code itself rather than the comments, which are often out of date, inaccurate or couched in terms that made sense to the programmer who wrote them, when he already had a good understanding of the code, but not to me coming along afterwards trying to aquire that understanding.

  There are occasional exceptions:)

• Often the process of combination also has the side-effect of reducing the opcode count, and the need for temporary variables, which can lead to improvements in either or both; performnce and reduced memory allocation. If this is achieved without recourse to obfuscation, or a reduction in clarity, then it certainly doesn't harm.

  I get kind of crinkly when I see the phrase "premature optimisation". Especially if code is destined to be re-used, writing it to be as memory and cycles efficient as is commensurate with clarity is (IMO) worthy of making the effort.

  The authors of modules have no way of knowing the runtime demands of the applications that will use their code, so their optimisation efforts are either 'always premature' or 'always beneficial'.

  The idea that modules should be written without regard to the runtime costs and optimisation left to the modules users as and when their applications run up againsts limits, severly restricts and negates the purpose of modularisation.

  We all benefit from the efforts that perls maintainers put into optimisations, though we may occasionally be bitten by them when thing are taken a step to far. I for one wouldn't want to loose the benefits of their many successful optimisations in order to avoid the occasional bug that results from them.