[TUHS] Re: What would early alternatives to C have been?

On Sun, Mar 9, 2025 at 9:18 AM G. Branden Robinson < g.branden.robinson(a)gmail.com&gt; wrote: Branden — respectfully, if you download the standard https://archive.org/details/iso-iec-7185-1990-Pascal or look at versions that have been converted to HTML such as https://wiki.freepascal.org/Standard_Pascal, that statement is a tad hollow. Sadly, that is the issue with Pascal. The fundamental flaws of the core Pascal language remained as described in Brian’s paper as: 1. Since the size of an array is part of its type, it is not possible to write general-purpose routines, that is, to deal with arrays of different sizes. In particular, string handling is very difficult. 2. The lack of static variables, initialization, and a way to communicate non-hierarchically combine to destroy the ‘‘locality’’ of a program — variables require much more scope than they ought to. 3. The language's one-pass nature forces procedures and functions to be presented in an unnatural order; the enforced separation of various declarations scatters program components that logically belong together. 4. The lack of separate compilation impedes the development of large programs and makes using external libraries impossible. 5. The order of logical expression evaluation cannot be controlled, which leads to convoluted code and extraneous variables. 6. The case statement is emasculated because there is no default clause. 7. The standard I/O is defective. There is no sensible provision for dealing with files or program arguments as part of the standard language and no extension mechanism. 8. The language lacks most of the tools needed for assembling large programs, most notably file inclusion. 9. There is no escape. You >>are<< correct that many (not all) of the defects Brian and Dave ran into when updating/rewriting the Software Tools book from FORTRAN (Ratfor) to Pascal >>could<< have been fixed. The core issue with Pascal is that if an implementation did add an extension,* every implementation did it differently.* Now, the truth is that having different implementations from different vendors was not unusual. The whole reason ASA developed FORTRAN-66, which begat the many versions that followed [I believe FORTRAN-2018 is the last verified version, but I'm told by Dr. FORTRAN [Steve Lionel] that they are preparing an updated draft. BASIC had it in spades. In fact, at one of the early 'Hatfield/McCoy" parties between my friends at HP and Tektronix, we count 14 different flavors of "HP BASIC" and 6 different flavors of "Tek Pascal." History. Wirth was teaching at Stanford when Algol-X was proposed. In the late 1960s, the International Federation for Information Processing (IFIP) held the International responsibility for the definition of the programming language ALGOL 60, chartered IFIP Working Group 2.1 to develop a replacement for the language which had been identified, notably the lack of a standardized string subsystem. This effort was dubbed ALGOL X. You can use an internet search to find several of them, but one of the proposals was submitted by Niklaus Wirth and Tony Hoare. When their proposal was not accepted, the language ALGOL 68 would be developed under these auspices. The committee decided that the Wirth/Hoare proposal was an insufficient advance over ALGOL 60, and the proposal was published as a contribution to the development of ALGOL in CACM after making slight modifications to the language. Wirth eventually decided to develop his proposal and created an implementation targeting the IBM System/360 at Stanford University. He called the new language Algol-W [used in many universities, and I used it at CMU, and I have friends that used it at Cornell and Princeton]. At the time, Wirth's original target was a tool to teach his students at Stanford. It was not a "production quality" compiler in the sense of IBM's FORTRAN-H, which was considered the "best" production compiler at the time. Also, remember the whole assembler/compiled code was hardly a settled debate. Wulf's findings showed BLISS was as good as the best PDP-10/PDP-11 programmers, which was still a few years in the future. As I've said elsewhere, it took enough students trained in the ideas from the Green Book a few years to get into the world to start to develop the optimizers we now expect as the norm. Again, it was not considered an issue for what they were trying to solve. Read the IFPS meeting notes. Turbo Pascal was a flavor of Pascal that came much later. At the time, UCB Pascal and UCSD Pascal were the two popular implementations for students, and commercial folks used Whitesmiths and, later, OMSI. The first three were the compilers Brian and PJ used (I believe all were running a V7 Unix, but I'm not positive about the target OS). FWIW: today's popular Pascal is Free Pascal (freepascal.org) and it accepts all of the syntax of Turbo, Object Pascal, and Delphi as input. But it was too late. No, it was not agreed upon. Everyone developing a Pascal implementation was pushing their flavor (sound familiar). Turbo "won" when they targeted DOS, which, at the time, was being ignored by the traditional "professional" programmers (DOS was too much of a "toy" to be serious. - Minicomputers were the bread and butter). When PharLap created an OS extension that allowed for a real 32-bit C for the 386, UNIX and C had already taken the mantel, and Pascal was losing favor in the DOS world. Look at OMSI, which primarily targeted the PDP-11. It has many of these extensions [it basically started as one of the Tek Pascal's, BTW. Jon and I worked with some folks who developed it.] Please be careful here. The point is that in 1980, Pascal and C, as described by Brain, C did not have the issues I listed above, but the popular Pascal implementations being used in the wild did. I don't since I lived it. Need to work with Noel to update that page -- that name was because it came with the original ditroff - which used libS.a to replace Lesk's portable I/O library. It was less an issue of new compiler language features and more the requirement for a new I/O library. Remember, C and BLISS, as examples are defined without an I/O library in their origin stories. They both use the local OS's IO interface. C does not formally get an I/O library until Typesetter C and White Book. Simply, until C moved to the Honeywell and 360 nd people started to "port" code, that Lesk started to codify an IO library that could be used regardless of the local OS. Look at the documentation in V6. You'll see some interesting like fd = -1 and other artifacts that Mike had in so that earlier code would recompile and relink. With typesetter C, Dennis forced a small rewrite of your code to use libS.a. As I said, I lived this whole war. Crumudgingly yours, Clem ᐧ