The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: tfb@tfeb.org (Tim Bradshaw)
Subject: [TUHS] Happy birthday, Niklaus Wirth!
Date: Fri, 16 Feb 2018 21:02:46 +0000	[thread overview]
Message-ID: <EEA2F509-4071-43BC-8A44-4565D8FEE92E@tfeb.org> (raw)
In-Reply-To: <20180216134243.62D8C18C098@mercury.lcs.mit.edu>

On 16 Feb 2018, at 13:42, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
> 
> This isn't really about Unix, but I hate to see inaccuracies go into
> archives...

I think it's also important to say that claims like 'lisp is slow' are essentially meaningless.

It is reasonable to say that 'this program is slow', where 'this program' refers to some definite bit of code, implicitly qualified by the machine it is running on, when the statement was made &c &c.  That's clearly a thing you can go out and test.

It's often safe to say that particular implementations of programming languages are slow, which means that many or most programs run using the specified implementation of the programming language are slower than they might be either using some other implementation of the same language, or written in some other programming language and run using an implementation of that. In particular I can say 'CPython is slow' for instance: this statement might be wrong, but it does at least have some content.

For programming languages which only *have* one implementation or have a single dominant implementation, you can get lazy and say, for instance 'Python is slow'.  What this really means is 'CPython is slow' (ie it's the same as the previous statement).  It's also dangerous because it tacitly assumes that there is only one implementation of Python, which is not  true (or at least has not been true in the past).  But you can usually get away with this.

For programming languages which have many implementations, and still more for *families* of related programming languages, each member of which may have many implementations, the statement loses all meaning.  What does the statement 'Lisp is slow' *mean*?  The only meaning it could really have is something like 'all implementations of Lisp that there have been are slow and all implementations *there ever will be* will also be slow'.  The only way this could possibly make sense is if the person making the statement understood that some feature or features of any Lisp-family language was so hard to implement that it was really clear that no fast implementation could ever exist.  I claim (without evidence) that Lisp-family languages, considered as a whole, do not contain such toxic features.  So the statement simply does not have any meaning.

I think that people making such statements, assuming they are not making them merely as insults (which very often, historically, they are, although I assume not here), make them because they are confused.  What they really mean, at best, is that certain implementations of Lisp-family languages of which they have (often apocryphal) experience have been rather slow.  In fact what they usually mean is even weaker than that: some particular programs (which someone told them about) run in some particular implementations were slow.  But somehow this becomes generalised to 'Lisp is slow': I think it would be interesting to understand how this generalisation happens, although its probably even more off-topic here than messages about Lisp are.

To bring it slightly back on-topic, I think these statements are very like statements along the lines of 'Unix is insecure', which I think we could all agree is meaningless: a particular implementation of Unix might be insecure, but I think the claim that Unix is *inherently* insecure simply has no content.

Finally I'll just add this quote about Stalin, a Scheme compiler by Siskind: "Stalin is the highest performing Scheme compiler and one of the highest performing compilers for any language".

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180216/c3d07321/attachment-0001.html>


  reply	other threads:[~2018-02-16 21:02 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-16 13:42 Noel Chiappa
2018-02-16 21:02 ` Tim Bradshaw [this message]
  -- strict thread matches above, loose matches on Subject: below --
2018-02-18 20:50 Norman Wilson
2018-02-19  0:28 ` Dave Horsfall
     [not found] <mailman.22.1518790085.20342.tuhs@minnie.tuhs.org>
2018-02-16 17:40 ` Paul McJones
2018-02-16 19:24   ` Bakul Shah
     [not found] <mailman.1.1518746401.1018.tuhs@minnie.tuhs.org>
2018-02-16  2:40 ` Paul McJones
2018-02-16  2:19 Noel Chiappa
2018-02-16  2:48 ` Larry McVoy
2018-02-16  4:19   ` Steve Nickolas
2018-02-16 11:27   ` Tim Bradshaw
2018-02-16 15:45     ` Nemo
2018-02-14 21:06 Dave Horsfall
2018-02-14 21:12 ` Clem Cole
2018-02-14 22:15   ` George Michaelson
2018-02-14 23:37   ` Dave Horsfall
2018-02-14 21:24 ` Toby Thain
2018-02-16  0:01   ` Dave Horsfall
2018-02-16  0:51     ` Dan Cross
2018-02-16  1:06       ` Clem cole
2018-02-16  3:10         ` Toby Thain
2018-02-16 13:36           ` Clem Cole
2018-02-16  1:18       ` Larry McVoy
2018-02-16  1:55         ` George Michaelson
2018-02-16  1:56         ` Lawrence Stewart
2018-02-16  2:38           ` Dan Cross
2018-02-16  2:41             ` Larry McVoy
2018-02-16  2:51               ` Dan Cross
2018-02-16  2:56                 ` George Michaelson
2018-02-16 10:26               ` Tim Bradshaw
2018-02-16  1:25       ` Ian Zimmerman
2018-04-24  0:59         ` Ian Zimmerman
2018-04-24  3:26           ` Dave Horsfall
2018-04-24  4:31           ` Dan Stromberg
2018-04-24 13:42             ` Clem Cole
2018-02-16  2:09       ` Bakul Shah
2018-02-16  2:31         ` Toby Thain
2018-02-16 10:01         ` Tim Bradshaw
2018-02-16 12:10           ` Bakul Shah
2018-02-16 12:37             ` tfb
2018-02-16 13:34               ` Bakul Shah
2018-02-16 14:07                 ` Bakul Shah
2018-02-16 20:13                 ` tfb
2018-02-16  3:17       ` Dan Stromberg
2018-02-14 23:19 ` Greg 'groggy' Lehey
2018-02-14 23:31   ` Dave Horsfall
2018-02-15 17:32     ` Steffen Nurpmeso
2018-02-15 19:18       ` Ian Zimmerman
2018-02-15 20:56         ` Steffen Nurpmeso
2018-02-15 21:31         ` Jeremy C. Reed
2018-02-15  2:30 ` Nemo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=EEA2F509-4071-43BC-8A44-4565D8FEE92E@tfeb.org \
    --to=tfb@tfeb.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).