6 ms·

It's hard to get my head around what it would be like seeing C-like patterns for the first time if I was someone that already had a background in COBOL and Pasc

by sbf501 4y ago

It's hard to get my head around what it would be like seeing C-like patterns for the first time if I was someone that already had a background in COBOL and Pascal. At my university, CS101 was taught with both COBOL and Pascal, but I had already had some C and 6502 assembly in the mid-80's. COBOL seemed like assembly with words instead of opcodes and cryptic operands. Pascal seemed like a more user-friendly C. I can see why C is preferable to COBOL as the world moved to more commodified OSes and something better than assembly was needed for drivers & kernels, but it would be interesting to know what Pascal "idiosyncrasies" turned people to "portable" C. Any old timers here care to weigh in?

PaulHoule 4y ago
C had pointer arithmetic which let you do systems work that you could not do in PASCAL, by the later 1980s Turbo Pascal had extensions to fill the gap and I liked it better but school had me using Unix workstations that didn’t have Turbo Pascsl so I switched to C.
- sbf501 4y ago
  Ah. That's a good point. No pun intended. I forgot how powerful being able to address raw memory is with a non-asm language.
- pjmlp 4y ago
  Plenty of Pascal versions had such extensions, not only TP.
  - WalterBright 4y ago
    In the early 80s, they didn't. Pascal was more or less unusable on the PC. Pascal remained unusable until it got a boatload of extensions. The trouble was, every Pascal added different extensions, making Pascal unportable.
    - pjmlp 4y ago
      Just like most C dialects outside UNIX, but for C it counts as features.
      - WalterBright 4y ago
        There were portability issues with C compilers, for example, value preserving vs sign preserving integer promotion rules. But Pascal was unusable without extensions. I mean that. I wrote programs in Pascal. For example, Wirth's Pascal had no provision for programs that had more than one source file.
        pjmlp 4y ago
        I wouldn't consider RatC or Small-C that usable without the pile of Assembly code they needed to be usable beyond bare bones control flow statements. Like I say, two weights two measures.
        Gibbon1 4y ago
        Nothing was non-trivially usable on an IBM PC without a pile of assembly code. Integrating C with assembly was easy. Pascal originally didn't support that at all. And academics were utterly horrified by things like Turbo Pascal.
        pjmlp 4y ago
        The usual argument, C extensions for inline Assembly and dialects outside UNIX, no problem, it was great. The fact that Pascal extensions existed, and Modula-2 as evolution from Pascal was a standard since 1978, doesn't count.
        WalterBright 4y ago
        Even the bad early C compilers were far more usable than Pascal. I know this, because where I worked at Data I/O we tried a whole bunch of them - Pascal, Fortran, and C.
deleted 4y ago
[deleted]
Jtsummers 4y ago
Here is Kernighan's take on Pascal from 1981: https://www.cs.virginia.edu/~evans/cs655/readings/bwk-on-pascal.html https://www.cs.virginia.edu/~evans/cs655/readings/bwk-on-pas... It seems pretty representative of other complaints about Pascal (versus C, in particular, but not always) I've seen from that same time.
- pjmlp 4y ago
  Cleverly ignoring that Modula-2, released in 1978, sorts out those issues.
  - ncmncm 4y ago
    Modula-2 had already lost that race. It was another extended, incompatible Pascal among myriad others mostly still called Pascal. Scud-pascal, Apollo Pascal, Clascal, Turbo Pascal, what-have-you.
    - pjmlp 4y ago
      You mean like the myriad of C dialects like K&R C, Small-C, RatC, DBS C, what-havw-you.
      - ncmncm 4y ago
        Different compilers, same language.
        pjmlp 4y ago
        Thanks for providing how little you know what they were capable of, versus proper C on UNIX.
        ncmncm 4y ago
        Code for any that lacked features would still build on a more complete implementation. This is fundamentally different from the Pascal case where extansions absolutely necessary for the compiler to be useful at all differed radically from one to another.
AnimalMuppet 4y ago
See "Why Pascal Is Not My Favorite Programming Language" (https://www.cs.virginia.edu/~evans/cs655/readings/bwk-on-pascal.html https://www.cs.virginia.edu/~evans/cs655/readings/bwk-on-pas...). It's written by Brian Kernighan, but it's not a hit piece. It's also not a comparison to C. Kernighan (and P. J. Plaugher) had written a book called "Software Tools". It was supposed to give several reasonably-lengthy examples of software that did actual useful functions. It was written in RATFOR, which is a pre-processor for FORTRAN. Some time later, they re-wrote the book to use Pascal, calling it (predictably enough) "Software Tools In Pascal". After writing it, Kernighan wrote this paper, basically because he was thinking "That should have been way easier than writing the same stuff in RATFOR. Why was that so hard?" I used Pascal for two years professionally, and many of the issues in the paper I ran into. Pascal was just clumsy to use. It was a good teaching language, but not good for professional programmers in many cases. (C, on the other hand, was written by people trying to write an operating system, and turned out to be a decent language for writing operating systems in.) Note well: All of this is true of the original Pascal. Things like Turbo Pascal improved it and made it actually a usable language. But even that wasn't portable - there wasn't a Turbo Pascal for anything other than the IBM PC, so far as I recall. And every other "improved" version was different from Turbo Pascal, so there was no portability between extensions either.
- pjmlp 4y ago
  Let's just ignore the C dialects outside UNIX like Small-C and RatC, or that we had to wait until 1990 for proper standard, and not even K&R C was a given outside UNIX.
  - kloch 4y ago
    The delay in publishing a "proper" standard was due to the incredible success/usefulness of the defacto K&R standard. But as you point out that was hard to find outside of Unix. I suspect this was mostly due to the effort required to implement the full standard library and/or resource limitations on many systems. For example, there was a Small-C compiler available for the Atari 800 in 1982: http://www.atarimania.com/utility-atari-400-800-xl-xe-c-65_19204.html http://www.atarimania.com/utility-atari-400-800-xl-xe-c-65_1... "... based on the Small C compiler published in Dr. Dobb's Journal" If you look in the beginning of the manual it has a list of what is and is not supported. They claim it is sufficient to compile C/65 itself but there are lots of things we take for granted missing.
WalterBright 4y ago
I was experienced with PDP-11 assembler when I was given a copy of K+R. Since many of C's semantics are based on the peculiarities of the -11 instructions, I understood it immediately. It was a breath of fresh air compared to Fortran or Pascal. I never wrote another line in either of those languages after reading K+R. Some things that come from the -11: 1. post increment and decrement 2. integer promotion rules 3. floating point promotion rules 3. `register` storage class
- 10000truths 4y ago
  4. Null-terminated strings, the scourge of all C programmers to come.
  - davidgay 4y ago
    The common alternative was single-byte-length strings. Null-terminated strings was much nicer.
- shadowofneptune 4y ago
  Dennis Richie reports that the increment operators actually came from B on the PDP-7. It didn't have auto-increment addressing modes, but it did have memory locations which increment when read. "This feature probably suggested such operators to Thompson; the generalization to make them both prefix and postfix was his own. Indeed, the auto-increment cells were not used directly in implementation of the operators, and a stronger motivation for the innovation was probably his observation that the translation of ++x was smaller than that of x=x+1." https://www.bell-labs.com/usr/dmr/www/chist.html https://www.bell-labs.com/usr/dmr/www/chist.html
  - ncmncm 4y ago
    Right, there was no room in memory for the compiler to implement peephole optimization. Or any other.
superjan 4y ago
If you know assembly, Pascal took away a lot and gave little in return, and it was verbose. I worked on a 80x25 monitor so the verbosity was annoying. Only functions could return values, but they were not guaranteed to be pure. No early returns. I also remember there were library functions with variable # of elements, but you could not write them (variable arg functions) yourself. Really hated that. Not all of these were fair criticisms, but they were enough to switch for me.

by sbf501 4y ago

PaulHoule 4y ago

C had pointer arithmetic which let you do systems work that you could not do in PASCAL, by the later 1980s Turbo Pascal had extensions to fill the gap and I liked it better but school had me using Unix workstations that didn’t have Turbo Pascsl so I switched to C.

sbf501 4y ago
Ah. That's a good point. No pun intended. I forgot how powerful being able to address raw memory is with a non-asm language.
pjmlp 4y ago
Plenty of Pascal versions had such extensions, not only TP.
- WalterBright 4y ago
  In the early 80s, they didn't. Pascal was more or less unusable on the PC. Pascal remained unusable until it got a boatload of extensions. The trouble was, every Pascal added different extensions, making Pascal unportable.
  - pjmlp 4y ago
    Just like most C dialects outside UNIX, but for C it counts as features.
    - WalterBright 4y ago
      There were portability issues with C compilers, for example, value preserving vs sign preserving integer promotion rules. But Pascal was unusable without extensions. I mean that. I wrote programs in Pascal. For example, Wirth's Pascal had no provision for programs that had more than one source file.
      - pjmlp 4y ago
        I wouldn't consider RatC or Small-C that usable without the pile of Assembly code they needed to be usable beyond bare bones control flow statements. Like I say, two weights two measures.
        Gibbon1 4y ago
        Nothing was non-trivially usable on an IBM PC without a pile of assembly code. Integrating C with assembly was easy. Pascal originally didn't support that at all. And academics were utterly horrified by things like Turbo Pascal.
        pjmlp 4y ago
        The usual argument, C extensions for inline Assembly and dialects outside UNIX, no problem, it was great. The fact that Pascal extensions existed, and Modula-2 as evolution from Pascal was a standard since 1978, doesn't count.
        WalterBright 4y ago
        Even the bad early C compilers were far more usable than Pascal. I know this, because where I worked at Data I/O we tried a whole bunch of them - Pascal, Fortran, and C.

deleted 4y ago

[deleted]

Jtsummers 4y ago

Here is Kernighan's take on Pascal from 1981: https://www.cs.virginia.edu/~evans/cs655/readings/bwk-on-pascal.html https://www.cs.virginia.edu/~evans/cs655/readings/bwk-on-pas... It seems pretty representative of other complaints about Pascal (versus C, in particular, but not always) I've seen from that same time.

pjmlp 4y ago
Cleverly ignoring that Modula-2, released in 1978, sorts out those issues.
- ncmncm 4y ago
  Modula-2 had already lost that race. It was another extended, incompatible Pascal among myriad others mostly still called Pascal. Scud-pascal, Apollo Pascal, Clascal, Turbo Pascal, what-have-you.
  - pjmlp 4y ago
    You mean like the myriad of C dialects like K&R C, Small-C, RatC, DBS C, what-havw-you.
    - ncmncm 4y ago
      Different compilers, same language.
      - pjmlp 4y ago
        Thanks for providing how little you know what they were capable of, versus proper C on UNIX.
        ncmncm 4y ago
        Code for any that lacked features would still build on a more complete implementation. This is fundamentally different from the Pascal case where extansions absolutely necessary for the compiler to be useful at all differed radically from one to another.

AnimalMuppet 4y ago

See "Why Pascal Is Not My Favorite Programming Language" (https://www.cs.virginia.edu/~evans/cs655/readings/bwk-on-pascal.html https://www.cs.virginia.edu/~evans/cs655/readings/bwk-on-pas...). It's written by Brian Kernighan, but it's not a hit piece. It's also not a comparison to C. Kernighan (and P. J. Plaugher) had written a book called "Software Tools". It was supposed to give several reasonably-lengthy examples of software that did actual useful functions. It was written in RATFOR, which is a pre-processor for FORTRAN. Some time later, they re-wrote the book to use Pascal, calling it (predictably enough) "Software Tools In Pascal". After writing it, Kernighan wrote this paper, basically because he was thinking "That should have been way easier than writing the same stuff in RATFOR. Why was that so hard?" I used Pascal for two years professionally, and many of the issues in the paper I ran into. Pascal was just clumsy to use. It was a good teaching language, but not good for professional programmers in many cases. (C, on the other hand, was written by people trying to write an operating system, and turned out to be a decent language for writing operating systems in.) Note well: All of this is true of the original Pascal. Things like Turbo Pascal improved it and made it actually a usable language. But even that wasn't portable - there wasn't a Turbo Pascal for anything other than the IBM PC, so far as I recall. And every other "improved" version was different from Turbo Pascal, so there was no portability between extensions either.

pjmlp 4y ago
Let's just ignore the C dialects outside UNIX like Small-C and RatC, or that we had to wait until 1990 for proper standard, and not even K&R C was a given outside UNIX.
- kloch 4y ago
  The delay in publishing a "proper" standard was due to the incredible success/usefulness of the defacto K&R standard. But as you point out that was hard to find outside of Unix. I suspect this was mostly due to the effort required to implement the full standard library and/or resource limitations on many systems. For example, there was a Small-C compiler available for the Atari 800 in 1982: http://www.atarimania.com/utility-atari-400-800-xl-xe-c-65_19204.html http://www.atarimania.com/utility-atari-400-800-xl-xe-c-65_1... "... based on the Small C compiler published in Dr. Dobb's Journal" If you look in the beginning of the manual it has a list of what is and is not supported. They claim it is sufficient to compile C/65 itself but there are lots of things we take for granted missing.

WalterBright 4y ago

I was experienced with PDP-11 assembler when I was given a copy of K+R. Since many of C's semantics are based on the peculiarities of the -11 instructions, I understood it immediately. It was a breath of fresh air compared to Fortran or Pascal. I never wrote another line in either of those languages after reading K+R. Some things that come from the -11: 1. post increment and decrement 2. integer promotion rules 3. floating point promotion rules 3. `register` storage class

10000truths 4y ago
4. Null-terminated strings, the scourge of all C programmers to come.
- davidgay 4y ago
  The common alternative was single-byte-length strings. Null-terminated strings was much nicer.
shadowofneptune 4y ago
Dennis Richie reports that the increment operators actually came from B on the PDP-7. It didn't have auto-increment addressing modes, but it did have memory locations which increment when read. "This feature probably suggested such operators to Thompson; the generalization to make them both prefix and postfix was his own. Indeed, the auto-increment cells were not used directly in implementation of the operators, and a stronger motivation for the innovation was probably his observation that the translation of ++x was smaller than that of x=x+1." https://www.bell-labs.com/usr/dmr/www/chist.html https://www.bell-labs.com/usr/dmr/www/chist.html
- ncmncm 4y ago
  Right, there was no room in memory for the compiler to implement peephole optimization. Or any other.

superjan 4y ago

If you know assembly, Pascal took away a lot and gave little in return, and it was verbose. I worked on a 80x25 monitor so the verbosity was annoying. Only functions could return values, but they were not guaranteed to be pure. No early returns. I also remember there were library functions with variable # of elements, but you could not write them (variable arg functions) yourself. Really hated that. Not all of these were fair criticisms, but they were enough to switch for me.