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=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,MAILING_LIST_MULTI, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 8218 invoked from network); 4 Aug 2023 15:18:38 -0000 Received: from minnie.tuhs.org (2600:3c01:e000:146::1) by inbox.vuxu.org with ESMTPUTF8; 4 Aug 2023 15:18:38 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id BC30142439; Sat, 5 Aug 2023 01:18:34 +1000 (AEST) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) by minnie.tuhs.org (Postfix) with ESMTPS id 33C5F42438 for ; Sat, 5 Aug 2023 01:18:27 +1000 (AEST) Received: by mail-lj1-x22a.google.com with SMTP id 38308e7fff4ca-2b9b6e943ebso40944691fa.1 for ; Fri, 04 Aug 2023 08:18:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691162305; x=1691767105; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=nzMzRT7GObyRQRjjqUDWgNWQCaLmfeFlkrzjsmOBph8=; b=Q24cKA3i1I/WnnAWsspuSTfpOTshdzEhTobtgXDTp7vQx22hO8Azs6CFCBz2lrwvQ2 Hm6TU9sInlPj1egjPunTgz0BpOu39/l26HMWEV8zy8LsQVIcbmDnRbOu1/+olM+VOtSy 77zoPXytNEYMRcC/WfxXn9MA9Igtmtq3qj2MoxidgYNVXSCeyJqgxxbNtZYXPZoC0hoL rhKD/eiZlMGI8nY+noIWLzIVi4OqlaXYAkooDwC5gIM+/DX5ZBaBSzRbhvrvrkPeR6Vv 3DfBD6PLY1CfpHj9uegEM6Yi/96ea8pGLXcmb65qULuEbu2TdOW2hPj4IpQ9YLfDa0uU q9Og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691162305; x=1691767105; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=nzMzRT7GObyRQRjjqUDWgNWQCaLmfeFlkrzjsmOBph8=; b=S3TeVAVkaBKLk6x0KEUn2mr9BKaR/9Nu2L/7JkkfBpb/Ek/bYmVOE5uRLa2/K1BheJ J7Hf3bQsP3943O9LDpPjE/A2z0W9e1xKpzNq5xb3e6Xw/xjWaNhc9MjliYGl8AYcX7KN hLfQBZGdpkJB0/c7qg6Mka4N6ZOr3K3BrEuOh3MVOVvl7i43zBSTuHG3I2ucDY+XFMuJ aqWy4jJKzx65dPZ4QNWioccXMDn3kSC513XJRtMks8PKbHgPdIj1kORz3uKOH8Ajxlps wi0UEGtjof40qQEcBfg+J3x25ogp3a76/sltQGqtOynFGJoPGiuekFjcABEm38wDTDP6 d6zg== X-Gm-Message-State: AOJu0YzvAx5Veyex6wqr8K9TYfeXxQBDP632tgY3W7Kzzfzefg804+ve lJsLvqVyY72uq41qUZtprkNmrgDHGeI3fl5g434KGXDACwY= X-Google-Smtp-Source: AGHT+IFwkD82twHTu+dsY8opujbwD1Z32QtY/SU+JQrFEa6FtRp1wWzMNIiQ/4BlKA/r6iJoFU1AMJVIMRHyz5jJ9OQ= X-Received: by 2002:a2e:a229:0:b0:2b8:40c2:5941 with SMTP id i9-20020a2ea229000000b002b840c25941mr6109ljm.26.1691162304933; Fri, 04 Aug 2023 08:18:24 -0700 (PDT) MIME-Version: 1.0 References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> <1f043101-4dbb-34ff-b037-85e7cc707a6e@halwitz.org> <2BF7ADB4-4851-4CF5-A6AC-0F1079D4AF78@gmail.com> In-Reply-To: From: Dan Cross Date: Fri, 4 Aug 2023 11:17:48 -0400 Message-ID: To: John Cowan Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: AQZDOXXHUGCN23WAQJC2PDS2MTJV76C4 X-Message-ID-Hash: AQZDOXXHUGCN23WAQJC2PDS2MTJV76C4 X-MailFrom: crossd@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: tuhs@tuhs.org X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: python List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Thu, Aug 3, 2023 at 8:24=E2=80=AFPM John Cowan wrote: > On Thu, Aug 3, 2023 at 6:06=E2=80=AFPM Dan Cross wrote= : >> someone had needed to store a >> pair of integers, so they used a CONS cell; > > Of course, that was a bad idea. The pair of integers should have been a = struct or a class named after whatever its application-level purpose was: a= point, for example. Probably, but I didn't write the original code, or even make the change; I did submit the fix, however. :-) An issue with CLs aggregation primitives is that they can be expensive, however. QPX was weird; despite things that have been said about it publicly (http://www.paulgraham.com/carl.html) QPX was not a "typical" Lisp program: it is more like FORTRAN written in S-expressions (many thousand-line Lisp functions with jumps between various points inside of them are common; those functions like, say, setq [not setf] a boolean on line 1387, and then reference it on 3298...kind of a mess, but that's what you need to make Lisp fast). >> after a while, the pair >> needed to be expanded to a triple, so someone converted the single >> CONS cell into a (proper) list. > > In that case, a derived struct or class should have been created. The tw= o classes would use the same accessor methods, just as in C++. Of course, we all knew this. But when you've got an O(10^6) line codebase that's extremely fragile, technology and business limitations demand tradeoffs that are not always what the engineers would choose. >> this, of course, ran afoul of the type system and >> raised a condition, which resulted as an ISE in prod. The fix was >> trivial (change CDR to SECOND in the right place) but it really struck >> me that if the system were statically typed, this would have been >> trivially discovered at compile-time. > > Absolutely, and if the failure was intolerable, CL's static type declarat= ions would have caught the use of the wrong type. But you don't have to de= clare *everything*. For that matter, there is nothing in a fully staticall= y typed system that requires every variable, function, argument, etc. to be= *declared*: type inference is powerful. Not really, unless they were used consistently across the entire codebase (and sadly, they were not). >> Common Lisp does allow you to declare types in some limited regards; >> these are usually hints to the compiler for code generation. > > They may or may not be, depending on how you set the OPTIMIZE declaration= . > >> like Rob, I >> greatly prefer strong, static typing. > > Then why weren't you using mypy? Because it didn't exist at the time (the early 2010s), or if it did, it was in a very nascent state. >> Incidentally, C is weakly (you can add a pointer to an integer: the >> result is another pointer), but statically typed. > > That's not weak typing, it's operator overloading, just as when you add a= n int to a double. C will not let you, e.g., add an int to a function. I think there's a bit of a debate as to whether C is weakly or strongly typed (and certainly, these exist on a spectrum), and some good judges say it's "moderately typed". I've never heard anyone refer to implicit type conversions as "operator overloading", however. > Weak typing is quite rare in high-level languages: PL/I pointer variables= are weakly typed (that is, when you allocate an object you specify the typ= e of the object and then assign it to the pointer variable), but the rest o= f the language is strongly typed. Once `memcpy` and `void *` are in the mix, all bets are off in C. - Dan C.