Re: succinctness = power

[Paul Prescod <address@hidden>]

Paul Graham wrote:
> 
>...
> 
> Certainly you want to look at what can make program*s* shorter,
> not just a particular program.  Is there stuff you can do that
> makes all or most programs shorter and yet is a bad idea?

Yes, you can capture common special cases, but make the language less
reliable and harder to reason about. I've brought up the example of
making vector->list optional in Scheme. In C++ you can trigger an
arbitrary number of Turing-complete type transformations even in a
simple expression. In Perl, the string, integer and float types are
unified. Both allow you to avoid doing manual type conversions but I
think that they both hurt reliability and maintainability.

> Arguably not; presumably to do that you'd have to be capturing
> some common abstraction.

Or just making something implict that was previously explicit.

> > There are
> > languages out there that have been way down that path.
> 
> Examples of that type are exactly what I'm asking for.  So
> if you (or anyone on LL1) can think of languages that force
> programmers to be excessively terse, let's see them.  

You keep inserting the word force. Okay, if it matters, then original
APL is probably a language that forces programmers to be excessively
terse.

But the more important point is that a language can also compromise
other important principles by either *encouraging* or even *allowing*
terseness. When a C++ program crashes in code you didn't know would run,
you must think to yourself: "gee, I wonder if that code could have been
triggered by an implicit conversion." It doesn't matter whether you have
decided to avoid the feature yourself. The tens of thousands of lines of
code that you depend upon may have used the feature and you must take it
into account while debugging. Even if nobody, ever, anywhere, uses the
feature, it must be part of a complete mental model of the programming
language and that has a cost also. It isn't necessarily the case that
the code is too succinct, but rather that the price of ultimate
succinctness is language bloat and complexity.

Scheme would not be popular when compared to Common Lisp if it were not
for the fact that some people reject the idea that having more stuff
built-in is necessarily better than either being explicit or creating
appropriate abstractions yourself, when and if you need them. But either
option is less succinct than just having more stuff crammed into the
programming language (nothing is more succinct than a built-in
function!). 

>...
> Well, if the power of a language as a tool is reflected in
> something other than succinctness, tell us what.  The reason
> I wrote that essay is to propose succinctness = power as
> kind of the first step in a newton's method-like approach
> to figure out what we should be aiming for in language design.

I don't think anybody knows what we should be aiming for in language
design because there is no one thing to aim for. Different languages
have different goals and balance different factors. (and any decent
language *is* a balance) I don't think it practical to think that you
will ever be able to judge programming languages based on metrics except
for those collected in businesses, schools and your other target
markets. The relevant metrics are dollars, hours, defects, satisfaction
surveys etc. I predict that you will not be able to find
software-discoverable metrics that serve as acceptable proxies for this. 

 Paul Prescod