From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 20717 invoked from network); 2 Jan 2022 04:02:40 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 2 Jan 2022 04:02:40 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 890949D069; Sun, 2 Jan 2022 14:02:34 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id EDD3D9CF06; Sun, 2 Jan 2022 14:02:21 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 0DE519CF06; Sun, 2 Jan 2022 14:02:20 +1000 (AEST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by minnie.tuhs.org (Postfix) with ESMTPS id D42BD9CE58 for ; Sun, 2 Jan 2022 14:02:18 +1000 (AEST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id CE36D18C08E; Sat, 1 Jan 2022 23:02:17 -0500 (EST) To: tuhs@minnie.tuhs.org Message-Id: <20220102040217.CE36D18C08E@mercury.lcs.mit.edu> Date: Sat, 1 Jan 2022 23:02:17 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Subject: Re: [TUHS] roff(7) [ and other related stuff ] X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: jnc@mercury.lcs.mit.edu Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" > From: John Cowan > Why use C syntax? What was wrong with Fortran, Lisp, or Cobol syntax, > extended to do what you wanted? Why do all hammers look basically the same? Because there's an 'ideal hammer', and over time hammer design has asymtoted toward that 'ideal hammer' design. One can't just keep improving the design indefinitely - diminishing returns set in. So I suspect there is, to some degree, a Platonic 'ideal syntax' for a 'classic block-structured' programming language, and to me, C came pretty close to it. I except LISP from that assessment, because LISP is built around a fundamentally different model of how computations/algorithms are organized, and C and LISP aren't directly comparable. But that realization points to a deeper bug with the 'Platonic ideal language' concept above, which is that languages are fundamentally, albeit at a very deep conceptual level, tied to the basic concept of the computing hardware they are to run on. C/COBOL/FORTRAN/etc are all for von Neumann-like (in a broad sense) computing engines - a single thread of computation, which happens sequentially. But we've pushed that paradigm about as far as it can go, we're into diminishing returns territory on that one. The future, starting with the hardware, will be very different - and will need quite different languages. (Go, from what little I know of it, is a baby step in this direction - it is intended to make it easy to use multiple simultaneous loci of execution, making use of the mutiple cores that are common now.) I suspect we'll be shifting to radically different paradigms, 50 years from now - massively parallel computing meshes (think Connection Machines on steroids - or the human brain), and those will use fundamentally different computing paradigms, and programming languages for them, which in turn will need very different syntax. Noel