Re: Initial Draft Finding on Principle of Least Power

[I agree with Harry in his other response that the debate about functional
languages is a minor point, hence sending cc to www-archive instead of www-tab
(for now... if anything interesting emerges, we could post a pointer).]

noah_mendelsohn@us.ibm.com wrote:
> Graham Klyne writes:
> 
> 
>>I'm biased in this respect, but I rather liked the reference to
>>Haskell.  In particular, I thought the text was clear enough 
>>(to me) that Haskell was no less powerful, but also carried the
>>suggestion that somehow pure functional expressions are more 
>>amenable to the proffered advantages of less power.
> 
> 
> Thanks.  That's certainly what I intended when I added it.  I think that 
> functional languages are a very interesting point on the 
> power/complexity/analyseability scale, as they have all the expressive 
> power of Turing completeness, but can be reasoned about in ways that are 
> difficult with procedural languages.

Indeed, it was the "can be reasoned about" aspect to which I was alluding.

Though, on reflection, I wonder if this is entirely true?  Early work on
denotational programming language semantics would map procedural constructs to
lambda calculus (that's about where I first got interested in functional
programming).  And in Haskell, most (if not all) of the procedural techniques of
imperative languages can be emulated using monads (notably: I/O and state).  So,
in the ultimate, which is more analyzable?

I also note that Bill de hOra raised JSON (a subset of Javascript data literals,
used for communicating data in some Ajax frameworks).  This had me thinking that
maybe the practical advantage is the availability of a useful language subset
that is amenable to analysis?  So Haskell without higher order functions might
be one such option, and could probably be useful for sharing information in the
sense of PLP.  The JSON subset of Javascript would, I think, be interesting to
compare for expressivity and analyzability.

[What follows is somewhat rambling... as I write I'm not sure where it's leading]

Through the years, I've used a number of programming languages and packages for
different tasks having varying degrees of expressivity.  I think there may be a
"power" axis that is orthogonal to the analyzability or complexity axis:
specificity vs generality.  There have been many languages/packages that are
very good in a particular domain, but less useful when moving to new domains
(e.g. Awk, SQL, HTML), and other languages that are quite generic in their
applicability (C, Perl, XML).  So we may have a language that is powerful in the
sense that it deals with a specific set of advanced concepts yet remains quite
analyzable (I once worked a little with a language like this called, I think,
APT which was used to describe geometric constructs for numerically controlled
machining), or others (like LISP S-expressions or RDF that are generic and
simple but require a lot of effort to convey useful ideas).

Does all of this have anything to offer the principle of least power?  I think
the proffered benefit of least power is analyzability, or ease of processing.
When common operations can be expressed in a common fashion, there's a big win
there.  "Complex" languages tend to offer many ways to say the same thing;
"simple" languages less so (and where there are different ways, they are
amenable to analysis to demonstrate equivalence).

Thinking of TimBL's PLP piece (which you're tasked with re-working), I've always
felt it to be a bit "motherhood and apple pie";  i.e. I've always instinctively
felt it's right, but never really understood how to apply it.  If the principle
is to be valuable to publish as part of AWWW, I think it has to help us in some
way:  to provide guidance in making or assessing design decisions.  Thus far, I
think we have something like:  in the context of a given application, if a
simple declarative data format will suffice, don't use a (Turing complete)
programming language;  use a format that offers a minimum of ways (preferably 1)
to construct a given value (?);  use a format that doesn't allow one to
construct invalid or un-interpretable values;  use a format that is easy to
write and parse; ...

I've no idea if anything here is remotely helpful.  Please feel free to ignore.

#g

-- 
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

Received on Friday, 23 December 2005 12:53:30 UTC