<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:"times new roman",serif;font-size:large"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 20, 2024 at 4:11 PM John Levine <<a href="mailto:johnl@taugh.com">johnl@taugh.com</a>> wrote:<br></div><div dir="ltr" class="gmail_attr"><div class="gmail_default" style="font-family:"times new roman",serif;font-size:large"></div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It appears that Clem Cole <<a href="mailto:clemc@ccc.com" target="_blank">clemc@ccc.com</a>> said:<br>
>“The PL/C compiler had the unusual capability of never failing to compile<br>
>> any program, through the use of extensive automatic correction of many<br>
>> syntax errors and by converting any remaining syntax errors to output<br>
>> statements.”<br>PL/C was a long time ago in the early 1970s. People used it on batch<br>
systems whre you handed in your cards at the window, waited a while,<br>
and later got your printout back. Or at advanced places, you could<br>
run the cards through the reader yourself, then wait until the batch<br>
ran.</blockquote><div><br></div><div class="gmail_default" style="font-family:"times new roman",serif;font-size:large">PL/C was a 3rd-generation autocorrection programming language. CORC was the 1962 version and CUPL was the 1966 version (same date as DWIM), neither of them based on PL/I. There is an implementation of both at <<a href="http://www.catb.org/~esr/cupl/">http://www.catb.org/~esr/cupl/</a>>.</div><div class="gmail_default" style="font-family:"times new roman",serif;font-size:large"><br></div><div class="gmail_default" style="font-family:"times new roman",serif;font-size:large">The Wikipedia DWIM article also points to Magit, the Emacs git client.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
In that environment, the benefit from possibly guessing an error<br>
correction right meant fewer trips to the card reader. In my youth I<br>
did a fair amount of programming that way in WATFOR/WATFIV and Algol W<br>
where we really tried to get the programs right since we wanted to<br>
finish up and go home.<br>
<br>
When I was using interactive systems where you could fix one bug and<br>
try again, over and over, it seemed like cheating.<br>
<br>
R's,<br>
John<br>
</blockquote></div></div>