Re: RE: succinctness = power

[Paul Graham <address@hidden>]

--Anton van Straaten wrote:
> 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.
> 
> I think what is wanted with programming languages and programs intended for
> human consumption is something along the lines of "the greatest
> meaning-based compression" (or "greatest semantic compression", to be more
> succinct).  If greatest possible compression were the goal, then all that
> would be needed to write succinct programs would be to run the final program
> through
> a compression program like gzip.
> 
> Compression programs work by looking for repeated patterns in the data being
> compressed, and optimizing the expression of those repetitions.  But most
> compression programs look for arbitrary identical patterns, and don't care
> about possible meanings of the data being compressed.  Writing succinct (or
> concise) human-readable code involves identifying repeated patterns that
> have closely related meanings, and optimizing those.
> 
> This kind of "manual semantic compression" results in better code, or even
> best code.  That's because repetition is almost always bad, in almost every
> possible respect (one common exception: execution speed).  A semantically
> compressed program should, almost by definition, be more comprehensible to a
> human than the alternatives.  Semantic compression of programs tends to
> result naturally in layered and modular programs, since if one is paying
> attention to meaning when performing compression, common functionality is
> factored out, and higher-level behaviors are built on top of lower-level
> behaviours.
> 
> So I would need to be convinced that there's any technical case at all, as
> some have suggested, for not performing maximal semantic compression on
> programs.  In that case, Fredrik's definition of succinctness as "greatest
> possible compression" works just fine, as long as it's understood to be
> semantic compression.

I agree with you, and in fact regularly go through my code
looking for patterns I can eliminate by writing macros. The
aim is not simply to make the code shorter, but to make myself
understand better what the program is doing.  (Which is why
I distrust arguments about language design that treat
readability and succinctness as if they were opposites.)

I suspect the more a languge lets you do this, the better.
At least, it would seem to be a better plan than the 
opposite approach of enshrining "design patterns".

Often you don't even realize you're doing the same thing
in several places till you see the code you've written.
A famous example of this is Steele & Sussman's discovery,
during the writing of Scheme, that Actors and closures
were the same thing.  They had not realized this till they
saw the code they'd written.  

In the best case, the pattern you discover is a new kind 
of abstraction, you write a generalized version, and this
then becomes a new tool in your toolbox, and changes the
way you conceive of programs from then on.  At its best,
programming is the discovery of new ideas, not just the
implementation of a spec.  It helps to have a language
that is like molding clay rather than carving stone.

It would be interesting to run a kind of symbol-level gzip
on source code and see what it turned up.  

> 
> Of course, there's a pragmatic/business case for not performing maximum
> semantic compression, which is simply that many programmers and designers
> are either not capable of doing it, or else they work in environments in
> which the benefits of approaching development in this way are not understood
> or sufficiently valued.  Also, in some cases with sufficiently small,
> one-off programs, high levels of semantic compression may not be directly
> justifiable.
> 
> Anton
>