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_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 2784 invoked from network); 5 Aug 2023 04:45:20 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 5 Aug 2023 04:45:20 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 637D8426E4; Sat, 5 Aug 2023 14:45:15 +1000 (AEST) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) by minnie.tuhs.org (Postfix) with ESMTPS id 5BC51426E3 for ; Sat, 5 Aug 2023 14:45:07 +1000 (AEST) Received: by mail-qk1-x733.google.com with SMTP id af79cd13be357-7672303c831so215288285a.2 for ; Fri, 04 Aug 2023 21:45:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iitbombay-org.20221208.gappssmtp.com; s=20221208; t=1691210706; x=1691815506; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=noKtTDat1nzCgsB0PtH6W8MTrQY8lUG6KPvgP3rEclY=; b=hUS/4aRLFUYenMeYoJF6GiImzY36DWi+Jz1HSKAMB2zir2aMpME1hQKZN+9sofTeHs em6eoSpj0ke3owOhXmIsUa3Fu8yMALdRD6ddduuuRPTbpi1wopGjUCoU/UXPqU+snrXk KIcdiQdCGGDMQhE9LxDvUytdu8By3ZMlsYc3FSy86hSOToO6HRIqFieCKM/2wI3Nv1W1 +0FpwJZuhdUZrXnpMzRU87QclqTD8nwCw0VvhY5/w2Blsf0FRrv/8Y75EQmELBUTGuWZ fwrNUuYHRtCJzER9C6nI+O42byC64ePr/g5KpPrSVSIRlXFmR7JjmsZBRrLoqXbumBdH rOiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691210706; x=1691815506; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=noKtTDat1nzCgsB0PtH6W8MTrQY8lUG6KPvgP3rEclY=; b=hlhnZCyAL6YxWRiqw6XYGPkCqg9IaVgtXV/j8vS0ZhHHRFBdmGpiT7KjrKpPd8Wwrg FTn282iMh3k/MYBGORS2j28QL9Etc4tjsIlLjjzBvQgE5r2eXId1TE1s4sKjO+uoOjQ+ 9SBCd4WHVPUgf9BCU+4lxUYZLaA3y/vTEmTTfd8NxAjTv/jr0CHrxtY1gdCvOhm9BwdE +fG2DOFB4nmpxJLilwb609NlOoBPU0rp9pBpzPoAFOQkMv12+H2CFCcDqxz4DJIDI7dh 5hWx9F8Jdc3xVGIgrhPKO2zfzRjoMtd8jmNKDPryq3qThHc4sPYn9c/ToP2T5QRTzOrv 12jQ== X-Gm-Message-State: AOJu0Yya0IjfYxfislfgv2DfIsyjygtzpOM+TbtebKNpVhx8HXdzs8lQ 3BQ1K99ouRldc75fABmIhO/nXup31JEfl1wy5Kg= X-Google-Smtp-Source: AGHT+IHex6sanlvHUwNaPoTYBr7k5oZ6bPtyLyZTkcG7EYjB5rQXXQLFA7JlbTGdVbRJ+p1Asfrjnw== X-Received: by 2002:a05:620a:228b:b0:76c:c9ea:95c9 with SMTP id o11-20020a05620a228b00b0076cc9ea95c9mr3236699qkh.22.1691210706183; Fri, 04 Aug 2023 21:45:06 -0700 (PDT) Received: from smtpclient.apple (107-215-223-229.lightspeed.sntcca.sbcglobal.net. [107.215.223.229]) by smtp.gmail.com with ESMTPSA id ja4-20020a170902efc400b001b8013ed362sm2556356plb.96.2023.08.04.21.45.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2023 21:45:05 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\)) From: Bakul Shah In-Reply-To: Date: Fri, 4 Aug 2023 21:44:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: 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> To: Dan Cross X-Mailer: Apple Mail (2.3731.600.7) Message-ID-Hash: FESZY7OKN3UAVDRTGWXC4XOLRJBNLVNR X-Message-ID-Hash: FESZY7OKN3UAVDRTGWXC4XOLRJBNLVNR X-MailFrom: bakul@iitbombay.org 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: Sorry for beating a dead horse but... What I was getting at when I invoked lisp is because I was thinking of the ability to debug live processes as opposed analyzing dead programs (core dumps). With lisps you can not only access a lot of the dynamic state of the program at the language level but (in theory) you may also be able to fix the problem and let the process continue. Especially when a program crashes rather infrequently, having access to only a core dump & stack trace can be quite frustrating. Why do we continue to live in a virtual "batch processing" world when it comes to dealing with such problems? [I once spent a month analyzing a problem a customer reported. I had guessed what the problem might be but = couldn't reproduce it. In their live setup, it took 15 minutes to catch the bug with a logic analyzer!] The other thing both you and Rob pointed out is that even "well-tested" programs can crash. While you can use more type annotations even in dynamic languages to catch type errors, types are not sufficiently expressive so you always have that potential problem (and we can't=20 *prove* large programs to be bug free). It is of course better to do all the testing you can but that typically occurs in "lab conditions", not in the real world. That is why many large services can run a small subset of servers with newer version of s/w as a "canary" to catch errors early (but that is usually a binary decision -- if the canary dies, you don't do the software update). With a dynamic language you can add situation specific tests on the fly if the program misbehaves. Live debugging should be even easier now -- with the right setup one should be attach a bot to do some initial checking etc. Instead we have apps that use 100s of MB to GBs of space but die silently. Guess we all suffer from Stockholm Syndrome! > On Aug 3, 2023, at 3:05 PM, Dan Cross wrote: >=20 > 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 = understand why others might (ocd). C was my first exposure to blending = types, then 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. Thankfully, it's my choice. >=20 > 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). >=20 > 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. >=20 > 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). >=20 > 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. >=20 > Incidentally, C is weakly (you can add a pointer to an integer: the > result is another pointer), but statically typed. >=20 > - Dan C. >=20 >> On August 3, 2023 9:56:22 AM CDT, Dan Halbert = wrote: >>>=20 >>> Python has optional type annotations. There are batch tools (e.g., = MyPy) to do type analysis and IDE's also provide help. Example: >>>=20 >>> def greeting(name: str) -> str: >>> return 'Hello ' + name >>>=20 >>> I found Python to be an enormous improvement over Perl for writing = the kinds of things I used to write in Perl, with the Perl book at my = side. I currently make my living working on Python for microcontrollers. = Neverthless, I am fond of type checking too, and if I were writing a = large Python system, I would use type annotations. >>>=20 >>> I have used BCPL too, in the 70's, and we achieved some measure of = type safety by careful naming. >>>=20 >>> Dan H. >>>=20 >>> On 8/3/23 10:19, Bakul Shah wrote: >>>=20 >>> 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 critical programs. Perhaps Von Rossum had more experience with = statically typed languages than Lisp (because -- pure speculation here = -- if he had used CL enough, he would never have designed python :-) >>>=20 >>> On Aug 3, 2023, at 1:32 AM, Rob Pike wrote: >>>=20 >>> I once inherited maintenance of a critical piece of infrastructure = written in exquisitely well written, tested, and documented Python. I = mean it, it was really really good. >>>=20 >>> It crashed about once a week and I had to fix it over and over = because in those exponentially vast combinations of paths through the = code would arise yet another way to turn a string into a list, or = something analogous. It was hell. >>>=20 >>> Critical code needs static typing. >>>=20 >>> -rob >>>=20 >>>=20 >>> On Thu, Aug 3, 2023 at 1:56=E2=80=AFPM Bakul Shah = wrote: >>>>=20 >>>> python can certainly implement tail call optimization (TCO). Pretty = much any language can implement TCO but for some reason people think = such programs are harder to debug (and yet they don't similarly complain = about loops!). The beauty of Scheme was that it *mandated* tail = recursion. >>>>=20 >>>>> On Aug 2, 2023, at 8:24 PM, George Michaelson = wrote: >>>>>=20 >>>>> Tail recursion not lazy eval. >>>>>=20 >>>>> I wish words meant what I meant "inside" when I think them, not >>>>> "outside" what they mean when I write them. >>>>=20 >>>=20 >>>=20 >> -- Sent from /e/OS Mail.