[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: succinctness = power
I disagree that succinctness or terseness is a good property of a
language. When I read an expression or statement, I don't want to have
to puzzle it out. I want the meaning to be obvious. Verbiage decreases
comprehension, but so can terseness.
Also, repetition can increase a program's robustness. We humans like to
approach problems in different ways, and if all those ways lead to the
same answer, then I at least, have a greater confidence in the solution.
The requirement that one must declare the type of a variable before any
use is an example of a beneficial repetition.
I'm willing to let a compiler squeeze the repetition out of my programs.
Vladimir G. Ivanovic http://leonora.org/~vladimir
2770 Cowper St. email@example.com
Palo Alto, CA 94306-2447 +1 650 678 8014
"AvS" == Anton van Straaten <firstname.lastname@example.org> writes:
AvS> Jeffrey Palm wrote:
>> Given this definition, no... but this definition is inaccurate,
>> because 'succinct' doesn't imply the *greatest* compression;
>> So, I'd say languages *should* aim for a succinctness that
>> reduces the size (and consequently the complexity) of
>> programs without hindering their expressiveness.
AvS> I think what is wanted with programming languages and programs
AvS> intended for human consumption is something along the lines of
AvS> "the greatest meaning-based compression" (or "greatest semantic
AvS> compression", to be more succinct). If greatest possible
AvS> compression were the goal, then all that would be needed to write
AvS> succinct programs would be to run the final program through a
AvS> compression program like gzip.
AvS> Compression programs work by looking for repeated patterns in the
AvS> data being compressed, and optimizing the expression of those
AvS> repetitions. But most compression programs look for arbitrary
AvS> identical patterns, and don't care about possible meanings of the
AvS> data being compressed. Writing succinct (or concise)
AvS> human-readable code involves identifying repeated patterns that
AvS> have closely related meanings, and optimizing those.
AvS> This kind of "manual semantic compression" results in better
AvS> code, or even best code. That's because repetition is almost
AvS> always bad, in almost every possible respect (one common
AvS> exception: execution speed). A semantically compressed program
AvS> should, almost by definition, be more comprehensible to a human
AvS> than the alternatives. Semantic compression of programs tends to
AvS> result naturally in layered and modular programs, since if one is
AvS> paying attention to meaning when performing compression, common
AvS> functionality is factored out, and higher-level behaviors are
AvS> built on top of lower-level behaviours.
AvS> So I would need to be convinced that there's any technical case
AvS> at all, as some have suggested, for not performing maximal
AvS> semantic compression on programs. In that case, Fredrik's
AvS> definition of succinctness as "greatest possible compression"
AvS> works just fine, as long as it's understood to be semantic
AvS> Of course, there's a pragmatic/business case for not performing
AvS> maximum semantic compression, which is simply that many
AvS> programmers and designers are either not capable of doing it, or
AvS> else they work in environments in which the benefits of
AvS> approaching development in this way are not understood or
AvS> sufficiently valued. Also, in some cases with sufficiently small,
AvS> one-off programs, high levels of semantic compression may not be
AvS> directly justifiable.