Re: succinctness = power

[Paul Prescod <address@hidden>]

Anton van Straaten wrote:
> 
> Because lack of succinctness usually means your systems are not as
> "normalized" or well-factored as they could be, which means that they won't
> be cheaper, to develop or to maintain.  

So you're talking about other factors (extent of normalization) that are
*reflected in*, not *caused by* succinctness. It is the other factors
that are the power. Succintness is a side-effect of optimizing for them.

> ... I'm not really talking about
> token-level issues, I'm talking about capabilities a language provides for
> high-level reuse and architecture.

The paper under discussion talks about parse tree tokens:

"I think a better measure of the size of a program would be the number
of elements, where an element is anything that would be a distinct node
if you drew a tree representing the source code. The name of a variable
or function is an element; an integer or a floating-point number is an
element; a segment of literal text is an element; an element of a
pattern, or a format directive, is an element; a new block is an
element. There are borderline cases (is -5 two elements or one?) but I
think most of them are the same for every language, so they don't affect
comparisons much."

"This kind of metric would allow us to compare different languages, but
that is not its main value. The main value (at least for me) of the
succinctness test is as a guide in designing languages. The most useful
comparison between languages is between two potential variants of the
same language. What can I do in the language to make programs shorter?"

 * http://www.paulgraham.com/power.html

That way madness lies. You can *always* make any given program shorter
by adding special cases or short-cuts or simply more primitives to the
library or (even more succinct!) to the language. If you use that as
your success metric you will end up with a terrible programming
language. 'Gee, if the scheme "map" function took a vector then we could
save the conversion of these vectors to lists. If the math functions
converted strings to numbers automatically that would save the
programmer doing it. That would make programs more succinct.' There are
languages out there that have been way down that path.

>...
> 
> But I get the impression we're talking rather at cross-purposes - if a
> language is "twice as verbose", i.e. two lines for every one in another
> language, I don't have a big problem with that.  What I'm talking about are
> situations in which larger-scale opportunities for reuse and factorization
> are more difficult or impossible, resulting in programs which aren't as well
> factored as they could be in another language.

I agree that "ability to factor out common patterns" is a vital feature
of programming languages. We usually call that "extensibility" or
"expressiveness" or mabye even "power", but not succinctness. It is
*reflected in* succinctness (partially), not *caused by* succinctness.
Python is designed to be powerful in that way (though not necessarily
the MOST powerful). It is not designed to be succinct. Sometimes what is
one line in another language will be two lines in Python because the
Python version is optimizing for something other than token count or
line count. That's why I take exception to these paragraphs at the top
of the essay:

http://www.paulgraham.com/power.html : 
> Paul Prescod wrote something that stuck in my mind.
> 
> Python's goal is regularity and readability, not succinctness. 
> On the face of it, this seems a rather damning thing to 
> claim about a programming language. As far as I can tell, 
> succinctness = power. If so, then substituting, we get 
> Python's goal is regularity and readability, not power. 
> and this doesn't seem a tradeoff (if it is a tradeoff) 
> that you'd want to make. It's not far from saying that 
> Python's goal is not to be effective as a programming 
> language.

But I guess we've about exhausted this topic.

 Paul Prescod