Re: succinctness = power

["Vladimir G. Ivanovic" <address@hidden>]

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

--------
Vladimir G. Ivanovic                        http://leonora.org/~vladimir
2770 Cowper St.                                         vladimir@acm.org
Palo Alto, CA 94306-2447                                 +1 650 678 8014

"AvS" == Anton van Straaten <anton@appsolutions.com> writes:

  AvS> Jeffrey Palm wrote:
  >> Given this definition, no... but this definition is inaccurate,
  >> because 'succinct' doesn't imply the *greatest* compression;
  AvS> ...
  >> 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> compression.

  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.

  AvS> Anton