🚀 go-pugleaf

: From: torek@horse.ee.lbl.gov (Chris Torek)
: Message-ID: <26993@dog.ee.lbl.gov>
:   - Given two otherwise-identical languages L1 and L2, where L1
:     requires declarations but L2 does not, L2 will always be at
:     least as powerful as L1.
: The latter does not make L2 `better' than L1, any more than the fact
: that a power saw cuts wood faster makes it `better' than a hand saw
: (it is a lot harder to cut off a finger with a hand saw).  It does
: imply that L2 may be faster to use, when one is skilled at operation
: (much as power saws are faster but more dangerous).

Much as I like the general message Chris presents (specifically, that
the more-powerful-than applies to notation/task pairs, not to
notations alone, and so on), but this analogy is just a bit off.
A hand saw is not even remotely "otherwise identical" to a power saw
(where "otherwise" is refering to something like a declaration).
A more apt analogy might be

    This does not make L2 `better' than L1, any more than the fact that
    a power saw without a blade guard can be used with less fussing and
    cussing makes it `better' than one with a blade guard (it is a lot
    harder to cut off a finger with when using a blade guard).  It does
    imply that L2 may be faster to use, when one is skilled at
    operation (much as power saws without elaborate idiot-proofing are
    faster but more dangerous).

Of course, there are still problems with *this* analogy, what with
the speed/safety tradeoff of blade guard vs declaration checking
being arguably significantly different, but then...

Also, in addition to "safety", the more powerful notation for a suite
of tasks might not be "better" because of issues of obscurity.  If
snarf-file is a primitive in L1, and implemented most briefly as
open-file, read-file, close-file in L2, and if the read-file primitive
is bound to the alt-meta-cokebottle character in L1 while being bound
to the names open, read and write in L2, it might well offset the
superior "power" of L1 for some applications.  Teco, APL and perl
spring to mind for some reason (though I suppose I'm being somewhat
unfair to them).

Just a note from your friendly neighborhood nit-picker.
--
Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw