8 ms·
Pascal, as defined by Wirth, is just horrible. No "fopen" to open files of a given name in the filesystem. In fact, no "open/creat", nor any other system call
by drfuchs 6y ago
Pascal, as defined by Wirth, is just horrible.
No "fopen" to open files of a given name in the filesystem.
In fact, no "open/creat", nor any other system calls at all.
No "extern", no "#include", no user-created libraries, no ability to create a .a file, or even a .o file without main().
Actually, no system libraries, either; just a few built-in functions (sin and cos, but no tan; ln but no log).
No "default" on case statements.
No "break" or "continue" statements; only "goto".
No bitwise operators for and/or/xor.
No equivalent of C's && and || operators, where the second argument is guaranteed not to be evaluated if the first one determines the result.
And, for everyone who complains about C strings, all Wirth Pascal strings are fixed-length arrays of characters. So, you can't pass the constant string 'foo' to a function that is expecting an array of 4 characters.
Finally, in TeX, Knuth says he found the fact that when you get around to defining a forward function, you must NOT repeat the parameter list (names, types) again, to be so objectionable that he chose to use global variables to communicate with forward functions instead.
All of people's fond Pascal memories are actually due to extensions in Turbo Pascal, etc.
- drfuchs 6y ago... and a few more: You can convert enum->int, but you can't go the other way. All text input files must have eoln() defined at all times, so if an when you manage to open stdin, the program must halt until the user types a line of input (and eoln() will be true iff it's empty). Then when your program reads the line and the \n, everything halts until the user types the next line of input. It's virtually impossible to make a program that interacts with the user. And if I had a nickel for every time a student got stymied by the fact that the syntax insists you must not have a semi-colon in front of an "else"....
- andi999 6y agoThanks. What also ticks me off is that he isn't eating his own food, you cannot write the writeln function is pascal (even the function doing nothing), since you would need a variadic function which accepts strings of different length, both two big no nos.
- badsectoracula 6y agoFWIW Wirth's Pascal does not have a writeln, only write and you are supposed to use a special EOL character to indicate end of line. But yes it is meant to be special (like read) and also has its own special syntax for formatting. However this isn't anything weird as the compiler was already implementing all other standard procedures and functions as part of the language itself anyway - there isn't a distinction between 'language' and 'runtime library' like you'd see in C for example.
- drfuchs 6y agoYou are incorrect. Wirth Pascal has writeln, and in fact that is the only well-defined way to output a “newline”. There is no notion of \n or \r. (Gory details: when eoln(f) is true, the file variable f^ is supposed to be the space character!)
- badsectoracula 6y agoAFAIK this is Wirth's last document/version of Pascal: http://pascal-central.com/docs/pascal1973.pdf http://pascal-central.com/docs/pascal1973.pdf It doesn't mention Writeln anywhere. In section 13 (page 39) "Input and Output" it only mentions read and write for text input/output and at the end of it mentions that the end of each line must be indicated with the EOL characer. A few pages later (page 44) there is a table of standard identifiers and there is no mention of writeln either (but there is of write).
- drfuchs 6y agoWriteln is certainly in Wirth’s “Silver Book” Pascal standard, hot off his horrible line printer in 1974: https://dl101.zlibcdn.com/dtoken/78641b52ce049f6f7825c9e8f81284b0 https://dl101.zlibcdn.com/dtoken/78641b52ce049f6f7825c9e8f81...
- badsectoracula 6y agoThis looks like the manual for the Pascal 6000 compiler they had at ETH Zurich which extended the language that Wirth described. In fact in the preface it mentions that the standard is the "The Programming Language Pascal (Revised Report)" which in footnotes mentions is the 1973 version - ie. the document i linked above. Confusingly enough though it does describe readln and writeln in an attached revised report (mentioning that the reason for their addition is that they can't rely on an EOL character being available) but this is not the text they cite as the standard Pascal nor the latest version of the report available from ETH themselves (which is basically a different scan of the same text i linked above): https://www.research-collection.ethz.ch/handle/20.500.11850/68910 https://www.research-collection.ethz.ch/handle/20.500.11850/... My guess is that they added these at some point later but didn't make a newer version of the standalone report (which is what i've seen in other places, e.g. http://pascal-central.com/standards.html http://pascal-central.com/standards.html refer as Wirth's last standard). I guess in practice it was simpler to have a single book act both as a tutorial and a reference, though i always though the 1973 report to be the last "standard" and didn't paid much attention to the other stuff released later.
- badsectoracula 6y agoYou are looking at the original Pascal from a modern perspective. At its time it was very nice which is why it exploded in popularity. When Pascal was designed there wasn't an idea of a 'file' like what you have today - files often had their own data types and were series of defined records and different systems had different ideas of their structure. AFAIK in original Pascal you were supposed to pass any files as part of the program's environments and you declared as part of the program itself (`program Foo(a,b)`) these files - it was up to the system to provide those (Turbo Pascal ignored those). The other stuff you mention about extern, include, etc follow from that. Many systems didn't think of files like Unix where they were just series of bytes. The bits about default, continue, break, etc were intentional as having a structure in the program's flow was a big thing at the time and those would be seen like hidden gotos (the addition of 'goto' was probably seen a necessary evil for its time - but even then you had to explicitly declare the targets).
- guidoism 6y agoAnd Pascal was basically just an improved ALGOL which in part was designed to come up with a common notation to communicate algorithms in journal articles. The negative issues aren’t so bad in that light.
- drfuchs 6y agoNo, I’m looking at Pascal from a 1978 perspective. If there had been a good C compiler for the PDP10, TeX would not have been written in, actually, a macro language on top of Pascal (to help work around its shortcomings both in string handling and memory management; oh and that statement labels have to be numeric).
- vidarh 6y agoFrom a 1978 perspective, Pascal was indeed already becoming dated, sure. But by then Wirth had already developed Modula, and started Modula 2. But even from a 1978 perspective, most of your criticism of Pascal is for being bad at things it was never designed to be good at, and never pretended to be good at. It was a teaching language trimmed down (in terms of concepts) from Algol W for ease of implementation over feature-completeness, not designed to be a systems language. That it became the basis for so many language implementations that opted to solve the limitations of Pascal over starting from scratch is a testament to its success.
- pjmlp 6y agoHow Pascal critics love to ignore ISO Extended Pascal introduced to fix those issues.
- sacado2 6y agoBut then ISO Pascal is not 50 years old, far from it. The Pascal from 50 years ago was not that great in practice.
- pjmlp 6y agoIt was released in 1990, a bit younger, 30 years. More than enough to be aware of its existence, specially when ISO C first release is from 1989. Also all ISO Pascal issues were fixed in ISO Modula-2, released in 1978, 42 years ago.
- sacado2 6y agoA huge, 2-decades gap. Way too late, because in the meantime, Turbo Pascal had been developed and made the language practical (and btw I'm still impressed by the quality of TP's "IDE" for the time), and in 1990 you had several competing standards that split the community, between original "academic" Pascal, Turbo Pascal, Object Pascal, ISO Pascal, and a little later Delphi. Add that to the fact Wirth himself had lost interest in the language for a long time and had developed several better ones (Modula-2 indeed, Oberon too).
- pjmlp 6y agoWell, to be fair only clueless developers were using ISO Pascal without extensions, with VMS Pascal and UCSD Pascal being two well known ones. Just like no one was using proper K&R C outside UNIX, rather dialects like Small-C and BDS C.
- AnimalMuppet 6y agoThat's because my scars of trying to use Pascal before the ISO extensions are still there.
- michaelcampbell 6y agoYou must be delightful at parties. Things improve, and it's fine to like or have fond memories of things that were part of those improvements.
- svat 6y agoAbout the choice of Pascal for TeX in 1980… was it the case that Pascal was the most widely available language at the time (at least at universities and the like where TeX would be used)? Is that why Pascal was chosen as the language for the "portable" TeX rewrite? Or was it just that Pascal was available for PDP-10 (was that a common computer?) and reasonably easy to translate from, so it was a good base? About some of the other issues (system calls, a default for "case", etc), isn't it the case that most Pascal installations did have their own extensions that resolved this (even before Turbo Pascal)? (I'm actually surprised how many distinct Pascal compilers there seem to have been, with their own extensions… it must have been a language easy to write compilers for, which must explain some of its rapid popularity.) So some of this was more a failure of standardization (Wirth just didn't think about these factors enough to put them in the original standard, or update the standard fast enough) rather than non-availability in the Pascal that anyone used at a particular place. (Of course they'd become issues for porting programs over to another system.)
- drfuchs 6y agoAt the time, Knuth was exclusively using a PDP-10, "SAIL", running the WAITS time-share operating system. If you look at early ARPAnet maps, you'll see that maybe half of the machines were DEC PDP-20's; certainly at Stanford, MIT, CMU, etc., the first machines to be connected to (what was to become) the Internet were. One main goal of the 1980's TeX rewrite was to make it as portable as possible, to support other popular architectures of the day. C wasn't available for DEC PDP mainframes; IBM 360s didn't have a C compiler at the time, either. PL/I, Algol, etc. were also not universally available. So, based on the fact that the Hedrick Pascal compiler existed for the PDPs, and a general notion that a reasonable Pascal was, or would soon, be available for VAX/VMS, IBM, and Unix (the gpc front-end for gcc), the choice was made. By the way, at the time it didn't seem like PCs and Macs would be viable platforms, being so memory-constrained (TeX wanted a whole megabyte to run in!) so that wasn't a big part of the consideration. And Unix workstations (Sun, HP, etc.) weren't yet really a thing yet. It wasn't a super-comfortable decision, but seemed like the best choice at the time. Partly because of this, TeX is written to use just a subset of the Pascal language, so as to keep things simple, and thus ultimately translatable into other languages if necessary. It turned out that DEC eventually made a very good Pascal compiler for VMS, and similarly for IBM; but GPC lagged, and the popular Unix ports of TeX are based on C translations of TeX's Pascal code. Ditto for (all? some?) of the PC and Mac versions. But, to your point, yes, all the various compilers of the time had their own work-arounds to the "default", "fopen", etc. problems. The fact that they chose different syntaxes wasn't a big issue, being easily addressable via the "WEB" macro language Knuth wrote on top of. Much more of a pain was Pascal's virtually useless string functionality and poor memory-management that required laborious work-arounds, resulting in code that is difficult to modify and debug. It's a real shame that standardization of the features needed to make Pascal a language that was really suitable for cross-platform production code didn't happen in time to make a difference. All of the code Knuth writes has been in C (via CWEB) for quite some time now. [Edit: tried to say "star"-nix, but that made everything \it, so switched to "Unix".]
- jonjacky 6y agoPascal, even Wirth's Pascal, was a huge improvement over the other languages commonly used at the time. In Pascal's heyday in the 1970s and early 1980s, most programmers came to Pascal from BASIC or old FORTRAN (FORTRAN II or IV, not 77). Compared to these, Pascal offered: long identifiers (not 1 or 2 characters like BASIC or 6 like old FORTRAN), block structure and structured programming (not line numbers and GOTOs), record data types, pointers, and memory management with new and dispose (instead of statically allocated arrays and COMMON blocks), nested structure and lexical scope (instead of everything defined at top level). All this was a revelation and made whole new programming techniques and styles available.