5 ms·

"After this experience, it was hard to understand that the software engineering community did not recognize the benefits of adopting a high-level, type-safe lan

"After this experience, it was hard to understand that the software engineering community did not recognize the benefits of adopting a high-level, type-safe language instead of C." -- N. Wirth I suspect that the good programmers did notice the benefits of a strict statically typed language, however the cost was probably deemed to be too high at the time. Because C was a "mid-level language" and stayed close to the metal it could efficiently use the limited resources of pre-LSI (let alone VLSI) computers; effectively C allowed you to break the rules if you wanted or needed to. These days obviously the performance difference is generally less than a few percent and hence can be largely ignored.

narag 15y ago
I've read quite a bit of Pascal's history. There are three main explanations: * Lack of a complete standard. The language was initially used in academy, so when it was adopted by industry, numerous mutually incompatible extensions were developed. The standard C library today may seem basic, but it was nice in comparison. * Virtual machines. Now they're the cool thing. Then they were a shortcut to have a quick and dirty implementation for new hardware, instead of writting a compiler. Bad performance was associated with the language, not the implementation. * Some implementations were of the "bondage and discipline" kind. TurboPascal compiler in the eighties solved all three problems, adding an IDE and a $50 tag for good measure. But it was too late. Although very popular in Europe and for little shops in general, the big software firms in the USA had adopted C already.
- xradionut 15y ago
  One wonders where we would be if Pascal or one of it's offspring like Oberon had actually caught on and challenged C. It would be nice to have a alternative system programming language. C sometimes feels like a local maximum instead of a global one. From the PDF: "The clean solution given in Oberon [6] is the concept of type extension, in object-oriented languages called inheritance. Now it became possible to declare a pointer as referencing a given type, and it would be able to point to any type which was an extension of the given type. This made it possible to construct inhomogeneous data structures, and to use them with the security of a reliable type checking system. An implementation must check at run-time, if and only if it is not possible to check at compile-time,. Programs expressed in languages of the 1960s were full of loopholes. They made these programs utterly error-prone. But there was no alternative. The fact that a language like Oberon lets you program entire systems from scratch without use of loopholes (except in the storage manager and device drivers) marks the most significant progress in language design over 40 years."
  - cpeterso 15y ago
    Pascal was the primary high-level language used for development in the Apple Lisa, and in the early years of the Mac. Microsoft assumed Pascal would become the dominant application programming language, so the early Windows ABI used the Pascal calling conventions. That's why we're stuck with Windows' PASCAL/WINAPI/stdcall and cdecl ABI mess today.
    - narag 15y ago
      IIRC the first (unusable) Windows version was written in Pascal. I remember reading somewhere that Pascal calling convention was more efficient. Return from a function and cleaning the parameters from the stack could be done with a single RET N instruction, while C calls needed both a RET and a separate stack realignment, because C allows variable number of params. I don't know if it's still the case with recent processors.
      - caf 15y ago
        C requires that variable-argument-list fuctions be called with a correct prototype in scope, so it is perfectly feasible to use a "callee-cleans-up" ("Pascal") calling convention for regular C functions and a "caller cleans up" ("cdecl") convention for varargs functions. The point is moot though, because just because an operation can be represented using a single assembler mnemonic doesn't mean that it's any faster than an alternative that uses several. A case in point is the "REP MOVS" style string functions, that until very recently were actually slower than opencoding the equivalents, since they trapped to microcode.
  - pjmlp 15y ago
    <quote> One wonders where we would be if Pascal or one of it's offspring like Oberon had actually caught on and challenged C. It would be nice to have a alternative system programming language. C sometimes feels like a local maximum instead of a global one. </quote> I think we would be using safer systems where buffer overruns and pointer exploits would be almost non existent. The hegemony of C has cost the industry millions of euros/dollars in software correctness.
kabdib 15y ago
Pascal's I/O was broken. Strings were broken. Every Pascal I ever worked with (with the exception of the Pascal I used in school) had extensions to make it work in the Real World. Unextended Pascal was a toy. Apple was a Pascal shop in the 80s, but they extended it to the point that I just translated (in my head) the C code that I wanted to write into the variant of Pascal they'd implemented. Pascal had a couple of nice things that C didn't (nested procedures, for one), but they weren't used all that much by us. Strings were still a pain. Str255 stunk, and everyone knew it, but nobody had anything that was dramatically better.
- pmiller2 15y ago
  I disagree. Unextended Pascal is not a toy: it's a tool to teach computer science and structured programming. In a classroom environment in the 1970's, it's not relevant that strings have to have a defined, fixed length. I'm not 100% sure what you mean by I/O being broken, but I'd wager that's not a big deal in a classroom environment, either. In any case, evaluating unextended Pascal as anything other than a teaching tool is like complaining that a hacksaw isn't very good for screwing in screws. Talk about "wrong tool for the job!" :-)
  - Avshalom 15y ago
    The quote -from Wirth himself- was not about classroom environments, it was about software engineer(s|ing).
    - pmiller2 15y ago
      True. But, "high-level, type-safe language" need not refer to unextended Pascal, and I see no evidence that it was intended to. He could have meant Algol W. Depending on when it was written, he could have meant Modula 2, Modula 3, or Oberon.
      - kabdib 15y ago
        Serious question: Why is it that we generally see only toy systems being done in these languages. I don't mean to offend. If I'm unaware of major pieces of software done in Modula-N or Oberon, then feel free to correct me. I only know of some teaching-level and research OS work, and some GUI work, but little in the way of commercial stuff.

narag 15y ago

I've read quite a bit of Pascal's history. There are three main explanations: * Lack of a complete standard. The language was initially used in academy, so when it was adopted by industry, numerous mutually incompatible extensions were developed. The standard C library today may seem basic, but it was nice in comparison. * Virtual machines. Now they're the cool thing. Then they were a shortcut to have a quick and dirty implementation for new hardware, instead of writting a compiler. Bad performance was associated with the language, not the implementation. * Some implementations were of the "bondage and discipline" kind. TurboPascal compiler in the eighties solved all three problems, adding an IDE and a $50 tag for good measure. But it was too late. Although very popular in Europe and for little shops in general, the big software firms in the USA had adopted C already.

xradionut 15y ago
One wonders where we would be if Pascal or one of it's offspring like Oberon had actually caught on and challenged C. It would be nice to have a alternative system programming language. C sometimes feels like a local maximum instead of a global one. From the PDF: "The clean solution given in Oberon [6] is the concept of type extension, in object-oriented languages called inheritance. Now it became possible to declare a pointer as referencing a given type, and it would be able to point to any type which was an extension of the given type. This made it possible to construct inhomogeneous data structures, and to use them with the security of a reliable type checking system. An implementation must check at run-time, if and only if it is not possible to check at compile-time,. Programs expressed in languages of the 1960s were full of loopholes. They made these programs utterly error-prone. But there was no alternative. The fact that a language like Oberon lets you program entire systems from scratch without use of loopholes (except in the storage manager and device drivers) marks the most significant progress in language design over 40 years."
- cpeterso 15y ago
  Pascal was the primary high-level language used for development in the Apple Lisa, and in the early years of the Mac. Microsoft assumed Pascal would become the dominant application programming language, so the early Windows ABI used the Pascal calling conventions. That's why we're stuck with Windows' PASCAL/WINAPI/stdcall and cdecl ABI mess today.
  - narag 15y ago
    IIRC the first (unusable) Windows version was written in Pascal. I remember reading somewhere that Pascal calling convention was more efficient. Return from a function and cleaning the parameters from the stack could be done with a single RET N instruction, while C calls needed both a RET and a separate stack realignment, because C allows variable number of params. I don't know if it's still the case with recent processors.
    - caf 15y ago
      C requires that variable-argument-list fuctions be called with a correct prototype in scope, so it is perfectly feasible to use a "callee-cleans-up" ("Pascal") calling convention for regular C functions and a "caller cleans up" ("cdecl") convention for varargs functions. The point is moot though, because just because an operation can be represented using a single assembler mnemonic doesn't mean that it's any faster than an alternative that uses several. A case in point is the "REP MOVS" style string functions, that until very recently were actually slower than opencoding the equivalents, since they trapped to microcode.
- pjmlp 15y ago
  <quote> One wonders where we would be if Pascal or one of it's offspring like Oberon had actually caught on and challenged C. It would be nice to have a alternative system programming language. C sometimes feels like a local maximum instead of a global one. </quote> I think we would be using safer systems where buffer overruns and pointer exploits would be almost non existent. The hegemony of C has cost the industry millions of euros/dollars in software correctness.

kabdib 15y ago

Pascal's I/O was broken. Strings were broken. Every Pascal I ever worked with (with the exception of the Pascal I used in school) had extensions to make it work in the Real World. Unextended Pascal was a toy. Apple was a Pascal shop in the 80s, but they extended it to the point that I just translated (in my head) the C code that I wanted to write into the variant of Pascal they'd implemented. Pascal had a couple of nice things that C didn't (nested procedures, for one), but they weren't used all that much by us. Strings were still a pain. Str255 stunk, and everyone knew it, but nobody had anything that was dramatically better.

pmiller2 15y ago
I disagree. Unextended Pascal is not a toy: it's a tool to teach computer science and structured programming. In a classroom environment in the 1970's, it's not relevant that strings have to have a defined, fixed length. I'm not 100% sure what you mean by I/O being broken, but I'd wager that's not a big deal in a classroom environment, either. In any case, evaluating unextended Pascal as anything other than a teaching tool is like complaining that a hacksaw isn't very good for screwing in screws. Talk about "wrong tool for the job!" :-)
- Avshalom 15y ago
  The quote -from Wirth himself- was not about classroom environments, it was about software engineer(s|ing).
  - pmiller2 15y ago
    True. But, "high-level, type-safe language" need not refer to unextended Pascal, and I see no evidence that it was intended to. He could have meant Algol W. Depending on when it was written, he could have meant Modula 2, Modula 3, or Oberon.
    - kabdib 15y ago
      Serious question: Why is it that we generally see only toy systems being done in these languages. I don't mean to offend. If I'm unaware of major pieces of software done in Modula-N or Oberon, then feel free to correct me. I only know of some teaching-level and research OS work, and some GUI work, but little in the way of commercial stuff.