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 4612 invoked from network); 3 Aug 2023 22:06:34 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 3 Aug 2023 22:06:34 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 225DC416BD; Fri, 4 Aug 2023 08:06:31 +1000 (AEST) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) by minnie.tuhs.org (Postfix) with ESMTPS id 16392416BC for ; Fri, 4 Aug 2023 08:06:25 +1000 (AEST) Received: by mail-lj1-x22d.google.com with SMTP id 38308e7fff4ca-2b9c55e0fbeso22143731fa.2 for ; Thu, 03 Aug 2023 15:06:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691100383; x=1691705183; 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=A+R/YcBSjjf1yWEJ8odfCMoc3xzIkTqFUXastXC79i0=; b=ix4ekr6p9xU4Nu+RgNnxGemKXS6ilqIQJXsHVWqp/9rjO5NKsdh28KrGHwdE6KSKpy sRP3C5YZHEclnKbBJYynxWIkqF32qt/L83yVNRtE2YkHqItmkc49RC9kc8jWLG/HKTPR QohMBormsPQPezRYMkocvvCBrdnkgxsPyjZg6fyKS2E0OtjsQdg2lUPxxKQh9B5P2FMy 4zINUvKhFZRNw7GbB9t5yIAP6hYgDhbx11qGSgzhvaaw1aMI9xXsbQjFnyIenC+Jpnfo m0pBX0+RVwPuGmcDe7ezeEzuXh3L05PtqqbnpM2g2mh41ZRnxQb7PjVYVihdvY7vKrqr qJuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691100383; x=1691705183; 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=A+R/YcBSjjf1yWEJ8odfCMoc3xzIkTqFUXastXC79i0=; b=JYrPMZ+7TnFCzDfGTBtDuZUeC93fZInxPo/hhgBCq6urq3tFJfHTgfWdl/BT68BCSL nYD5e4QklWDtjXM99F87wsJgS7fLGBmEe1L/AK8u+kRbmsrWRkLjDirUGl5f+UilfQ9z bQLHfAfnpYK/rp+vvrUA/Xb/bVpKKONxKiLzWwtqE5ypvRfTftvo3vpDXZXHNQ0JfKOg l0LncY95h/riaNEyVGDMMJiUluUQmmOi5k7e/eyNOjM5pdRf9dqXzvuUSi3lGuV3EOi4 dd7IqYtLM8MJS7yhbAVVRvcXpIP2dKdLPcqpx6zBGsPo2rlTrPyi3D0D076sWuCHVeeA k+Vg== X-Gm-Message-State: AOJu0YzsDr4oobZl3hdig/qKQkahivMTdAZABy61TdEKgr9UBamrHoUW 7E/mTGBjDH4TTVb+eKjzwVTAq3hJxlU0W5EygEwS9rZi X-Google-Smtp-Source: AGHT+IFBS2kBuorLL5eRpmpCsRTUoY0YA6oQH71T93ETqNXrXplxMrA0alv3jE6FMlfR78CYvj9L1owBd2jf6gpCukQ= X-Received: by 2002:a05:651c:218:b0:2b6:df5d:8e05 with SMTP id y24-20020a05651c021800b002b6df5d8e05mr51731ljn.33.1691100382994; Thu, 03 Aug 2023 15:06:22 -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: <2BF7ADB4-4851-4CF5-A6AC-0F1079D4AF78@gmail.com> From: Dan Cross Date: Thu, 3 Aug 2023 18:05:46 -0400 Message-ID: To: "will.senn@gmail.com" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: ESRQRYNQLN3EFN4S34Z5BNOENLB62G4L X-Message-ID-Hash: ESRQRYNQLN3EFN4S34Z5BNOENLB62G4L 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 11:21=E2=80=AFAM will.senn@gmail.com wrote: > Nice. I've never appreciated type checking at 'compile' time, but I under= stand why others might (ocd). C was my first exposure to blending types, th= en Perl was fuzzier, then Python was even better at pretending types didn't= matter. Now, with Lisp, I am freed from type concerns... until I'm not. Th= ankfully, it's my choice. Types in programming languages vary across two axes: strong versus weak, and static versus dynamic. Common Lisp is strongly typed: for example, you cannot add an integer to a list, or `cons` something onto a vector (Common Lisp vectors are not lists). Indeed, exactly the former caused a production outage in a large Lisp system I worked on for about a year: someone had needed to store a pair of integers, so they used a CONS cell; after a while, the pair needed to be expanded to a triple, so someone converted the single CONS cell into a (proper) list. Consequently, the function for accessing the second value went from being CDR to CADR (or `SECOND`), but the programmer missed one place: the value of `(cdr foo)`, now a list, was passed to some function that expected a fixnum and tried to add something to it: 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. On the other axis, Lisps are usually dynamically typed, which in this context, means that the type of a value associated with a symbol may change over time and one matters when the value is actually used. Common Lisp does allow you to declare types in some limited regards; these are usually hints to the compiler for code generation. Conversely, in statically typed languages, the type of every value is known at all times (particularly at compile time). Incidentally, this episode --- along with something similar in a Python program --- really soured me on dynamically-typed languages. The python failure was particularly maddening: it was heavily unit tested (100% coverage) but as soon as we put it out, we immediately got an error report: a type error with processing the arguments to `main` (Google had some non-standard internal libraries for that that were challenging to test). This was highly frustrating: like Rob, I greatly prefer strong, static typing. Incidentally, C is weakly (you can add a pointer to an integer: the result is another pointer), but statically typed. - Dan C. > On August 3, 2023 9:56:22 AM CDT, Dan Halbert wrote= : >> >> Python has optional type annotations. There are batch tools (e.g., MyPy)= to do type analysis and IDE's also provide help. Example: >> >> def greeting(name: str) -> str: >> return 'Hello ' + name >> >> I found Python to be an enormous improvement over Perl for writing the k= inds of things I used to write in Perl, with the Perl book at my side. I cu= rrently make my living working on Python for microcontrollers. Neverthless,= I am fond of type checking too, and if I were writing a large Python syste= m, I would use type annotations. >> >> I have used BCPL too, in the 70's, and we achieved some measure of type = safety by careful naming. >> >> Dan H. >> >> On 8/3/23 10:19, Bakul Shah wrote: >> >> I have not heard such horror stories about Common Lisp (or may be I have= forgotten them!). My impression is that python doesn't quite have the kind= of {meta,}programming tools Common Lisp has. CL has been used for large cr= itical programs. Perhaps Von Rossum had more experience with statically typ= ed languages than Lisp (because -- pure speculation here -- if he had used = CL enough, he would never have designed python :-) >> >> On Aug 3, 2023, at 1:32 AM, Rob Pike wrote: >> >> I once inherited maintenance of a critical piece of infrastructure writt= en in exquisitely well written, tested, and documented Python. I mean it, i= t was really really good. >> >> It crashed about once a week and I had to fix it over and over because i= n those exponentially vast combinations of paths through the code would ari= se yet another way to turn a string into a list, or something analogous. It= was hell. >> >> Critical code needs static typing. >> >> -rob >> >> >> On Thu, Aug 3, 2023 at 1:56=E2=80=AFPM Bakul Shah = wrote: >>> >>> python can certainly implement tail call optimization (TCO). Pretty muc= h any language can implement TCO but for some reason people think such prog= rams are harder to debug (and yet they don't similarly complain about loops= !). The beauty of Scheme was that it *mandated* tail recursion. >>> >>> > On Aug 2, 2023, at 8:24 PM, George Michaelson wrot= e: >>> > >>> > Tail recursion not lazy eval. >>> > >>> > I wish words meant what I meant "inside" when I think them, not >>> > "outside" what they mean when I write them. >>> >> >> > -- Sent from /e/OS Mail.