Re: succinctness = power

["Steven H. Rogers, Ph.D." <address@hidden>]

Paul Graham wrote:
> ...
> 
> The question at hand is, can a *language* be too succinct?
> I.e. can you design a language that forces users to 
> express their programs in an excessively dense style,
> rather than (like any language) merely allowing them to?
> 
In an earlier post you suggested that Python's goal is to be "not 
powerful", because it values clarity and readability over maximal 
succinctness.  Every design makes engineering trade-offs, and while 
Python does sacrifice succinctness for clarity and ease of 
understanding, I don't think implies that power or succinctnees are not 
valued.  A better summary of the Python design goal might be "maximize 
clarity and readability while providing a useful level of power for most 
users".  Python has become popular with both novices and experts.  A 
language aimed at experts might be somewhat more succinct.

Much of Python's popularity results from many programmer's discovering 
that it "fit's their brains".  It's like a well balanced firearm that 
almost hits where you look without effort.  I'm working on a project 
where we selected Python for end user scripting with the intent of 
programming the core system in C/C++.  Upon exposure to Python, the core 
programming team found that it "fit their brains" so well that they 
wanted to do everything except low level machine access in Python.  I 
think that the reduced amount of code that Python requires compared to C 
was a factor, though not a decisive one.

Part of the attraction of the APL family of languages is the extremely 
succinct solutions they make possible for problems amenable to array 
oriented approaches.  It really does give one a sense of power to do 
something with a line of code that might take a page with a more verbose 
language.  On the other hand, it might take as long to understand one 
line of APL as it does to understand the page long alternative, 
especially for a novice APLer.  The traditional APL symbol set helps in 
reading this dense code (for many at least, including myself).  The 
abandonment of these symbols in favor of one or two character ASCII 
names by the J and K dialects helped portability, but looks like line 
noise.  This seems to put off many programmers as badly as Lisp's prefix 
notation and parentheses.  APL/J/K may be too succinct.  It is much like 
mathematical notation and mathematical discourses typically surround 
expressions with explanatory text.  If you want a language to tell it's 
own story, a little less terseness is probably optimal.

Steve
-- 
"A language that doesn't affect the way you think about programming is 
not worth knowing." - Alan Perlis