From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: from minnie.tuhs.org (minnie.tuhs.org [50.116.15.146]) by inbox.vuxu.org (Postfix) with ESMTP id 080AC28A60 for ; Wed, 3 Apr 2024 18:19:24 +0200 (CEST) Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 25C8E42695; Thu, 4 Apr 2024 02:19:21 +1000 (AEST) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) by minnie.tuhs.org (Postfix) with ESMTPS id B2A2A42453 for ; Thu, 4 Apr 2024 02:19:10 +1000 (AEST) Received: by mail-pl1-x631.google.com with SMTP id d9443c01a7336-1e034607879so52726415ad.0 for ; Wed, 03 Apr 2024 09:19:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712161150; x=1712765950; darn=tuhs.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=upcs2J3WyaE0RwfT2k91Z3Hr1f/4hQixbkNZvipsS30=; b=e+TvPXTeUNm7CMeU0qfprTQrpMiC2U0i5ZF69gijEZxTKr6+ss+AYte1fGQWZqrpBe MDfYBJAYaM0kgLi2vjNw9VgJw5dYE0w/pGmViEBqNPRhqAuroRjVImWYakRBmEX6jjDw 0mczf1k6f/LfsCQdTsue/O3ABCZ27wTIFPwMlDvDIZpWiESzxcr4zJDMDPiFFWkSpPX2 zxPQs15xb6SOo41DTwspwnDnwSUzB0xz2hoP/MiU8lJftu2hEih7UWtkQKq2aJjyfNrj m93k9i7gt+en6vsl1iBSsvr0wLORgcqgbldM95ROsOeVkJnev0lTJO2LqXPr2tqTg6LN PanQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712161150; x=1712765950; h=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=upcs2J3WyaE0RwfT2k91Z3Hr1f/4hQixbkNZvipsS30=; b=YZnoho/kcYtUqNAqpuHDE/eJRaHEoWHI/9npUg45BAN1L8CIOZ47DrZ4Ia68y5HRZf dPSm4zVkh4rRo7OB4X5LS6RfeHcakVjIoV9w1iZDr2Bu7gAx2owW2z/qRxgKutjm9gnV WLZVvYyo6Bn/ORxh3s2esHVHP2XyswHvQ3+0sRb2BGI76Z7g6VPD/RLtjskHx2srEuLe mAuvlqpaw6mGnHWXZbjgwCXCgDzCU0B+8xAa0LSn7jWKC4EHygjXG+eSReO2UgcA2zDv kG/1y0RrzcCo51TfgDV7CZIYINzXr3n5IYuCopftQ0EM5Jidhmq0PwYDj//Gy584ecLJ Nj2w== X-Gm-Message-State: AOJu0YyJnXB/hqv3DKMKmQdSfUM7Exvj5dQ1Ktct/4ARNfprub3PQ/fu poSf5G49rhCBbc0a50ZVi8cjN2vwGRuQkSL9BDZWKeS9uCZ4oPRmrHLUqbax6IdVdVOn6x6xis2 EOe8Ik9UhRhdSmmddOy1x2bo96SZ/I5hL X-Google-Smtp-Source: AGHT+IGeU5ELoVKI2157snRq2O6k4tBxiF2UYrgnFUH2LUq8dvu6yF6ZHqMpNqdwlkLvOPEHdTLyPAZlyYM157hUCZ0= X-Received: by 2002:a17:903:292:b0:1e2:6240:72e7 with SMTP id j18-20020a170903029200b001e2624072e7mr7274027plr.53.1712161149722; Wed, 03 Apr 2024 09:19:09 -0700 (PDT) MIME-Version: 1.0 References: <1d3f129c-eafe-4fb2-9ea2-d949f3813c88@technologists.com> In-Reply-To: <1d3f129c-eafe-4fb2-9ea2-d949f3813c88@technologists.com> From: Paul Winalski Date: Wed, 3 Apr 2024 12:18:58 -0400 Message-ID: To: coff@tuhs.org Content-Type: multipart/alternative; boundary="00000000000020a99c0615339548" Message-ID-Hash: VTOYQPIBDZLNIJHPYPNI6ZBIKZX3NLPW X-Message-ID-Hash: VTOYQPIBDZLNIJHPYPNI6ZBIKZX3NLPW X-MailFrom: paul.winalski@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 X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [COFF] Re: Of PL/I List-Id: Computer Old Farts Forum Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --00000000000020a99c0615339548 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Apr 2, 2024 at 1:01=E2=80=AFPM Charles H Sauer (he/him) < sauer@technologists.com> wrote: > > Being judicious in using just the good parts, PL/I seemed just fine. > Essentially all of my work at Yorktown was in PL/I. > > Every programming language I've encountered has had its share of what I call toxic language features--things that impair reliability and maintainability. Good production programming shops ban the use of these features in their code. In the case of PL/I, IMO the most toxic feature is the DEFAULT statement. This is Fortran's IMPLICIT on steroids. The end result of using the DEFAULT statement is that, when you see a variable declaration, you need to review all of the applicable DEFAULT statements to figure out what the variable's attributes are. PL/I was designed to be a successor language to both COBOL and Fortran. One of the ugly features of Fortran is a fussy set of rules on statement ordering, particularly on declaration-type statements. PL/I relaxed those rules. Declarations can appear anywhere in the program and apply throughout the block they appear in. I know of folks who composed programs at the keypunch who used to write down variable declarations on a piece of paper as they came up with them, then when they reached the END statement of the scope block, punched out all the cards for the DECLARE statements. This practice was annoying in that, while reading the code you'd encounter variables that hadn't been declared yet and you'd have to rummage through the code to find the declarations. In the PL/I shops I worked at it was required that all declarations be at the beginning of the scope block. PL/I also has very weak data typing--you can convert almost any data type into almost any other data type. The language has a large and baroque set of conversion rules, and these don't always produce intuitive results, particularly when doing fixed decimal division. It can also mask typos, leading to hard-to-find bugs. I once mistyped: IF A ^=3D B [I'm using ^ here for the angle-bracket EBCDIC NOT sign character] as: IF A =3D^ B where A and B were both declared as character strings. So I wrote "if A equals NOT B". The compiler happily generated code to treat B as a character string of 0s and 1s, convert that to a bit string, apply the NOT operation, then similarly convert A to a bit string and do the comparison. This of course caused unexpected program behavior. It might have taken me a long time to find it except that there was a warning diagnostic message from the compiler: "data conversion will be done by subroutine call". This almost always means you've unintentionally mixed data types. -Paul W. --00000000000020a99c0615339548 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Apr 2, 2024 at 1:01=E2=80=AFPM Ch= arles H Sauer (he/him) <sauer= @technologists.com> wrote:

Being judicious in using just the good parts, PL/I seemed just fine.
Essentially all of my work at Yorktown was in PL/I.

Every programming language I've encountered has h= ad its share of what I call toxic language features--things that impair rel= iability and maintainability.=C2=A0 Good production programming shops ban t= he use of these features in their code.

In the cas= e of PL/I, IMO the most toxic feature is the DEFAULT statement.=C2=A0 This = is Fortran's IMPLICIT on steroids.=C2=A0 The end result of using the DE= FAULT statement is that, when you see a variable declaration, you need to r= eview all of the applicable DEFAULT statements to figure out what the varia= ble's attributes are.

PL/I was designed to be = a successor language to both COBOL and Fortran.=C2=A0 One of the ugly featu= res of Fortran is a fussy set of rules on statement ordering, particularly = on declaration-type statements.=C2=A0 PL/I relaxed those rules.=C2=A0 Decla= rations can appear anywhere in the program and apply throughout the block t= hey appear in.=C2=A0 I know of folks who composed programs at the keypunch = who used to write down variable declarations on a piece of paper as they ca= me up with them, then when they reached the END statement of the scope bloc= k, punched out all the cards for the DECLARE statements.=C2=A0 This practic= e was annoying in that, while reading the code you'd encounter variable= s that hadn't been declared yet and you'd have to rummage through t= he code to find the declarations.=C2=A0 In the PL/I shops I worked at it wa= s required that all declarations be at the beginning of the scope block.

PL/I also has very weak data typing--you can convert= almost any data type into almost any other data type.=C2=A0 The language h= as a large and baroque set of conversion rules, and these don't always = produce intuitive results, particularly when doing fixed decimal division.= =C2=A0 It can also mask typos, leading to hard-to-find bugs.=C2=A0 I once m= istyped:

IF A ^=3D B=C2=A0 [I'm using ^ here f= or the angle-bracket EBCDIC NOT sign character]

as= :

IF A =3D^=C2=A0 B

where= A and B were both declared as character strings.=C2=A0 So I wrote "if= A equals NOT B".=C2=A0 The compiler happily generated code to treat B= as a character string of 0s and 1s, convert that to a bit string, apply th= e NOT operation, then similarly convert A to a bit string and do the compar= ison.=C2=A0 This of course caused unexpected program behavior.=C2=A0 It mig= ht have taken me a long time to find it except that there was a warning dia= gnostic message from the compiler:=C2=A0 "data conversion will be done= by subroutine call".=C2=A0 This almost always means you've uninte= ntionally mixed data types.

-Paul W.
--00000000000020a99c0615339548--