Talk:PL/C

Cascading diagnostics

I had to laugh at "PL/C was widely used in college-level programming courses because of its avoidance of a known problem named "Cascading Diagnostics", wherein one error is "fixed" by the compiler, resulting in a secondary, tertiary and additional series of error messages.", as cascading diagnostics is actually something PL/C was notorious for. A single typo could easily cause hundreds of lines of error messages (PL/C tending to be verbose in it's errors) since it would try to correct the error and keep running, and it's correction invariably caused several new errors in the succeeding lines. I strongly suspect the author of that line has never actually experienced PL/C.

In that era compilers which hit an error and stopped were actually much better teaching tools, since it was clear where the error actually was. However in a batch enviroment having to resubmit the program for every individual error wasn't really practical, so students had to work thru outputs with multiple errors, and try to correct them all at once. A compliler like PL/C, which generated many bogus errors, made that much harder. — Preceding unsigned comment added by 2601:589:300:CA70:0:0:0:E35C (talk) 13:28, 13 July 2022 (UTC)

I don't think the PL/C diagnostics were as bad as being made out here, but I agree that the statement in the original article was overly broad and unsupported, and I have recast it in the reworking of the article that I did. Wasted Time R (talk) 15:23, 29 October 2022 (UTC)

Did you know nomination

The following is an archived discussion of the DYK nomination of the article below. Please do not modify this page. Subsequent comments should be made on the appropriate discussion page (such as this nomination's talk page, the article's talk page or Wikipedia talk:Did you know), unless there is consensus to re-open the discussion at this page. No further edits should be made to this page.

The result was: promoted by Theleekycauldron (talk) 07:02, 11 October 2022 (UTC)

(

• Comment or view
• Article history

)

• ... that PL/C was created at Cornell University as a student-oriented dialect of IBM's PL/I programming language, and that as many as 250 other universities used it? Source: fns 6 and 11 in article
  • ALT1: ... that Cornell University's student-oriented PL/C programming language dialect was made available to other universities but required a "research grant" payment in exchange? Source: fn 4 in article
  • Reviewed: Template:Did you know nominations/Henry Stock
  • Comment:

5x expanded by Wasted Time R (talk) and DavidGries (talk). Nominated by Wasted Time R (talk) at 10:40, 22 September 2022 (UTC).

• New enough and large enough expansion of a long-running stub. QPQ present. Earwig turns up no issues. Hook facts check out for ALT0 and ALT1. Sammi Brie (she/her • t • c) 17:52, 3 October 2022 (UTC)
  • Advice for contributors @Wasted Time R and DavidGries: I don't think the words "Imagine waiting five hours to discover only that a semicolon was missing." are quite the right tone, but that idea should be incorporated with the previous sentence.
• @Wasted Time R: As I'm sure Sammi Brie knows, technical abbreviations tend to decrease interest in a hook – can the jargon be condensed? theleekycauldron (talk • contribs) (she/her) 17:36, 6 October 2022 (UTC)
  • @Theleekycauldron: In ALT0, you could replace "... of IBM's PL/I programming language ..." with "... of an IBM programming language ...". Other than that, I'm not sure what jargon can be eliminated. "PL/C" is the name of the article, and while general readers may not realize that programming languages can have dialects, the analogy with human language dialects should be understandable. I think general readers are also familiar with research grants. Wasted Time R (talk) 01:03, 7 October 2022 (UTC)
    • @Wasted Time R: perhaps a piped link?
    • ALT1a: ... that Cornell University's student-oriented programming language dialect was made available to other universities but required a "research grant" payment in exchange?
    • I know it's silly, but it does actually have quite the effect :) theleekycauldron (talk • contribs) (she/her) 06:37, 7 October 2022 (UTC)
      • Ah, I see what you mean. Yes, a piped link is okay with me, as is ALT1a. Wasted Time R (talk) 10:22, 7 October 2022 (UTC)
        • I thought a slash would help, but yes, my call sign hooks have suffered so much I've stopped making them. I should have caught this. Sammi Brie (she/her • t • c) 05:43, 8 October 2022 (UTC)

Terak

[ copied here from User talk:Wasted Time R ]

Your mention of the Terak is interesting, since it is a PDP-11 box rather that IBM mainframe. The abstract of the Stillman article seems to imply that Cornell was running Pascal on them, rather than PL/C. The Daily Sun reference explicitly says PL/C, but only says they’re working on it. Since PL/C was written in IBM assembler, this would be interesting. Do you have any inside knowledge or are you only going by the references? I’m still looking for a copy of the darned thing, so this would be big news. Peter Flass (talk) 19:02, 26 October 2022 (UTC)

No, I don't have inside knowledge about the PL/CS variant or the Terak, and yes, I have also wondered about the extent to which PL/CS ran on the Terak. The end of the Stillman paper says "For this purpose, we have purchased Terak microcomputers, which are based on Digital Equipment Corporation's LSI-11 processor. In place of UCSD Pascal, our first semester course will be using PL/CS, a system developed at Cornell University which is much simpler to operate than the UCSD system." (I believe you can see the whole paper even if you aren't an ACM member, as they have opened up access to articles of this vintage.) The Teitelbaum CACM paper says "The design and implementation of the Program Synthesizer began in May 1978, and demonstrable prototype versions were operational under UNIX as well as on Terak (LSI-11) microcomputers by December 1978 [24, 25]. ... The first language implemented for the Synthesizer was PL/CS, an instructional dialect of PL/I [5, 23]. PL/CS had previously been defined to serve as a vehicle for research on batch-oriented, error-correcting compilers [6] as well as for program verification [4]." However, the Rudan history of computing at Cornell article says that "With regard to individual microcomputers for teaching, introductory computer programming, the [University Computing Board] was very interested in the innovative and interesting development of the Cornell Program Synthesizer by Tim Teitelbaum, professor in Computer Science. Using an LSI-11 chip, Teitelbaum developed this self-contained system for writing structured programs from a video display tube using a subset of the PL/CS processor running in a “syntax-directed synthesizer.” As it turned out, the Terak company was building microcomputers that contained the LSI-11 chip, and so several of these computers were purchased for use as development and test machines as a joint OCS and Computer Science project. ... Because the Synthesizer could compose only PL/C programs, OCS built the necessary software and hardware connections so that the Synthesizer could send completed programs to the IT batch processor on the 370/168 for execution and printing of results." So what to make of all that? The arrangement that Rudan describes certainly doesn't sound like the 'simpler to operate' system that Stillman describes. The people who implemented PL/C were experienced compiler developers who had previously had a heritage (CORC and CUPL) of developing compilers for non-IBM systems, so maybe they did built part of PL/CS for the LSI-11? I'm not sure. Wasted Time R (talk) 10:43, 27 October 2022 (UTC)

I think this discussion should be moved to the talk page for PL/C, I should never have started it here. I want to take some time to review the sources in more detail, and maybe some other research, they're certainly confusing, but your edit is faithful to the sources. The CPS contains an interpreter for PL/C. Peter Flass (talk) 16:41, 27 October 2022 (UTC)

I looked again at the Conway-Constable TR on PL/CS and page 19 indicates it was a replacement of the regular PL/C front end that generated the same intermediate language. So that would suggest that PL/CS was also implemented in 370 assembly. But presumably PL/CS was a small enough subset (compared to PL/C) that the Cornell Program Synthesizer people could implement their own interpreter for it on the LSI-11. So maybe the Synthesizer environment is what Stillman's university was going to use and that's why he saw it as simple. However maybe if someone wanted a printout of the program and its output, that was what the connection to the 370 was for that the Rudan history describes. But it would be good to find something more definitive on this. Wasted Time R (talk) 15:23, 29 October 2022 (UTC)

I used the Cornell Program Synthesizer on a Terak 8510a at Cornell in Fall 1978. This was in a room in Upson Hall where the terminals for the PDP-11/60 were. The main feature of the Program Synthesizer was the syntax-directed editor for PL/CS. Instead of typing free-form text as we do today in programming editors, you selected templates for PL/CS statements. Each template populated the editor with the source for a given type of statement (such as IF) and left blanks for you to fill in, for instance, the condition to be tested. I got the impression that at least at that time, the subset of PL/C implemented by the Program Synthesizer was so limited as to be rather uninteresting. By contrast, the full PL/C (which I used on Cornell’s IBM 370/168 via the snappy batch Instant Turnaround system) was pretty decent. I’m pretty sure that the Program Synthesizer did not require access to the IBM mainframe for what it did. Part of the reason I think that is that later at another university, I had access to a different Terak 8510a (which cost $12,000!) and briefly used the Program Synthesizer on it (using a floppy that I believe I had gotten from Tim Teitelbaum). As I recall (some 40+ years later), the Program Synthesizer worked on that Terak, even though it definitely didn’t have a connection to an IBM mainframe. I eventually acquired that Terak for myself when it became obsolete, and later - if memory serves - donated it to The Terak Museum. I transcribed part of a tutorial for the Terak version of the Cornell Program Synthesizer here: http://60bits.net/msu/mycomp/terak/terframe.htm Riordanmr (talk) 01:38, 13 February 2024 (UTC)

Source code

[ copied here from User talk:Wasted Time R ]

Sadly, Cornell seems to have been better at developing things than saving copies of them. Peter Flass (talk) 16:41, 27 October 2022 (UTC)

I suspect that a lot of source code from that era is lost. It would have had to have made transitions from punched cards for the 370 through a half dozen other computer systems and media formats to be in some GitHub site today. Wasted Time R (talk) 15:23, 29 October 2022 (UTC)