[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: succinctness = power

Paul Graham wrote:
> This topic of succinctness is something we (and language
> designers generally) have tiptoed around.  I think it is
> an important one.  The more I think about it, succinctness
> seems to be what languages are *for*.  If so, to say that
> the aim of a language is not to be succinct seems almost
> to say that its aim is not to be a good programming
> language.

Not unsurprisingly, I disagree.

"It seems to me that succinctness is what programming
languages are for. Computers would be just as happy to be
told what to do directly in machine language. I think that the
main reason we take the trouble to develop high-level
languages is to get leverage, so that we can say (and more
importantly, think) in 10 lines of a high-level language what
would require 1000 lines of machine language. In other
words, the main point of high-level languages to make
source code smaller."

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

Consider programming in either the lambda calculus or one of the Turing
complete languages explicitly intended to make programming hard. Neither
is a walk in the park but typically I would choose the lambda calculus,
despite the fact that it is incredibly verbose. The reason is:
programming the lambda calculus is not unlike the algebraic
manipulations I practiced for so many years in school. It fits my brain.
Turing machines are (in my opinion) extremely painful to program because
the mental model of thinking of everything as a state machine is
completely foreign.

Think back to the first two real programming languages. FORTRAN -
FORmula TRANslater. Think in formulae, not in bits! LISP: Think in
lists, not in bits!

"""McCarthy compared (formal) logical and natural languages in this
proposal for his personal research program. His conclusion was: " It
therefore seems to be desirable to attempt to construct an artificial
language which a computer can be programmed to use on problems and
self-reference. It should correspond to English in the sense that short
English statements about the given subject matter should have short
correspondents in the language and so should short arguments or
conjectural arguments." His goal: " I hope to try to formulate language
having these properties and in addition to contain the notions of
physical object, event, etc., with the hope that using this language it
will be possible to program a machine to learn to play games well and do
other tasks." (25)"""

So you want a programming language that maps as closely as possible on
the *way you think about the problem*. You want to model the problem
domain, not tell the computer in mind numbing detail how to compute
something. Let's call this property expressiveness. Succinctness flows
from expressiveness, not vice versa. Also, neither succinctness nor
expressiveness can be treated as absolute drivers for language design.
Otherwise you are forced to add primitives for every domain and
programming model. There is a tradeoff between expressiveness and
language size (similar to size of alphabet versus length of words).

If succincness=power, COBOL would be not just be a dying programming
language but a failed *idea*. The very idea of trying to make a
programming language "like English" would be ridiculous. Clearly at
least some language designers disagree that succinctness is an
overriding goal. COBOL was supposed to bring programs to the
programmer's mental model rather than vice versa. (I don't think it
succeeded, but I'm glad someone made the attempt)

For many programmers, Python demonstrably succeeds at fitting their
mental models:

 * http://www.melbpc.org.au/pcupdate/2108/2108article9.htm

Of course, it depends on their mental models and their problem domains!

 Paul Prescod