5 ms·

> The problem is, until now there has not been a very good systems programming language that allowed you to stay lean on memory without introducing any performa

> The problem is, until now there has not been a very good systems programming language that allowed you to stay lean on memory without introducing any performance overhead. Rust is certainly a contender, thankfully. We've only had Pascal and Modula-2 for what, 40-45 years? >perfectly good reason C is still prevalent to this day ... it's not that and it's not good. It's just that security implications were largely ignored, people were lazy and innovation and making sound decisions (rather than popular ones) has never been strong in the OSS/Linux community (apart from the kernel itself).

akira2501 12y ago
http://www.lysator.liu.se/c/bwk-on-pascal.html http://www.lysator.liu.se/c/bwk-on-pascal.html It's a hobby horse by this point, but it makes it clear that the Pascal of 30 years ago is not the Pascal of today. The same can be said of C. These languages have evolved to be where they are today, mostly because hardware has evolved to be where it is today. Castigating past decisions as laziness really seems to be ignorant of this process, what it involved, and why it was necessary to make the decisions that we have up until now. Engineering, on the whole, is the art of compromise.
- pjmlp 12y ago
  > April 2, 1981 USCD Pascal was created in 1978, Mesa in the mid-70s and Algol in 1968. Most of the complaints don't apply to them.
  - cbd1984 12y ago
    > UCSD Pascal bwk's point, then as now, was that once you deviated from Standard Pascal, you had to either bet on a specific horse in the non-standard Pascal race, or develop your own Pascal-like language with its own inherent defects, similar to but different from the defects of Standard Pascal and other Pascal-like languages. Your code would likely never interoperate with anyone else's Pascal variant. C, which had one de facto standard implementation and less genetic drift (because the standards, first K&R and then ANSI and ISO, were never as terrible as Standard Pascal's definition), didn't suffer from this nearly as much. Mesa didn't, either, but only because it was fairly obscure, and there sure were a lot of Foogols running around for a while, of which Pascal and its semi-clones formed only one family.
    - pjmlp 12y ago
      Nothing of this was relevant in 1981. The first K&R was published in 1978, ANSI/ISO C in 1989. In 1981 C only mattered if you had access to a UNIX system, there were hardly any K&R compliant compilers. Anyone using C outside a UNIX system was also betting on a specific horse. Which is one of reasons why ANSI C has so much undefined and unspecified behaviours defined, as the committee didn't want to rule out any implementation.
- lazyjones 12y ago
  > These languages have evolved to be where they are today, mostly because hardware has evolved to be where it is today.* No. Pascal and Modula-2 were perfectly usable, safe systems programming capable languages 20 years ago. Pascal was widely used in commercial product development (DOS/Windows), Modula-2 was scarce, but taught at universities with high quality development environments available for many platforms and the Oberon OS was based on the language Oberon, which was heavily influenced by/derived from Modula-2. Everything necessary to produce safe, maintainable, fast software was available back then, but lazy/uneducated/stubborn people used C instead and wrote crappy software we still have to use today. It's a shame really.
  - alayne 12y ago
    I'm sure Pascal was really the silver bullet and its failure had nothing to do with Pascal derivatives being academic, non-portable, not very expressive, and having numerous other issues. I think your ad hominem comments about people who implemented in C are in poor taste and not based in reality.
    - 4ad 12y ago
      I don't understand why we talk about Pascal at all, since Pascal is just as memory-unsafe as C.
      - ajuc 12y ago
        in one important practical aspect it isn't - strings are length+content in pascal, not null-delimited as in c. It's very important difference.
        4ad 12y ago
        You read into buffers, not strings. You can easily have buffers overflows. Pascal arrays are bounds checked, but not when it matters: http://wiki.lazarus.freepascal.org/Secure_programming#Buffer_Overflow http://wiki.lazarus.freepascal.org/Secure_programming#Buffer....
- zanny 12y ago
  Reading through some gstreamer code this weekend, I contend that "C of 30 years ago is not the C of today". It is still all the most horribly insecure and obtuse passing of raw pointer manipulation and bitwise logic ever. The preprocessor is still hell on software. Every variable is named something like gst_hello_world_parser_box because when you write complex software in it you always get huge name conflicts. It still thinks the best way to manage memory is to not manage it at all. People complained for so long about having to put your deletes in destructors in C++, too bad you have no such thing in C at all - you don't have classes, after all. Guess it has to go in the procedural function logic. Like 30 years ago.

akira2501 12y ago

http://www.lysator.liu.se/c/bwk-on-pascal.html http://www.lysator.liu.se/c/bwk-on-pascal.html It's a hobby horse by this point, but it makes it clear that the Pascal of 30 years ago is not the Pascal of today. The same can be said of C. These languages have evolved to be where they are today, mostly because hardware has evolved to be where it is today. Castigating past decisions as laziness really seems to be ignorant of this process, what it involved, and why it was necessary to make the decisions that we have up until now. Engineering, on the whole, is the art of compromise.

pjmlp 12y ago
> April 2, 1981 USCD Pascal was created in 1978, Mesa in the mid-70s and Algol in 1968. Most of the complaints don't apply to them.
- cbd1984 12y ago
  > UCSD Pascal bwk's point, then as now, was that once you deviated from Standard Pascal, you had to either bet on a specific horse in the non-standard Pascal race, or develop your own Pascal-like language with its own inherent defects, similar to but different from the defects of Standard Pascal and other Pascal-like languages. Your code would likely never interoperate with anyone else's Pascal variant. C, which had one de facto standard implementation and less genetic drift (because the standards, first K&R and then ANSI and ISO, were never as terrible as Standard Pascal's definition), didn't suffer from this nearly as much. Mesa didn't, either, but only because it was fairly obscure, and there sure were a lot of Foogols running around for a while, of which Pascal and its semi-clones formed only one family.
  - pjmlp 12y ago
    Nothing of this was relevant in 1981. The first K&R was published in 1978, ANSI/ISO C in 1989. In 1981 C only mattered if you had access to a UNIX system, there were hardly any K&R compliant compilers. Anyone using C outside a UNIX system was also betting on a specific horse. Which is one of reasons why ANSI C has so much undefined and unspecified behaviours defined, as the committee didn't want to rule out any implementation.
lazyjones 12y ago
> These languages have evolved to be where they are today, mostly because hardware has evolved to be where it is today.* No. Pascal and Modula-2 were perfectly usable, safe systems programming capable languages 20 years ago. Pascal was widely used in commercial product development (DOS/Windows), Modula-2 was scarce, but taught at universities with high quality development environments available for many platforms and the Oberon OS was based on the language Oberon, which was heavily influenced by/derived from Modula-2. Everything necessary to produce safe, maintainable, fast software was available back then, but lazy/uneducated/stubborn people used C instead and wrote crappy software we still have to use today. It's a shame really.
- alayne 12y ago
  I'm sure Pascal was really the silver bullet and its failure had nothing to do with Pascal derivatives being academic, non-portable, not very expressive, and having numerous other issues. I think your ad hominem comments about people who implemented in C are in poor taste and not based in reality.
  - 4ad 12y ago
    I don't understand why we talk about Pascal at all, since Pascal is just as memory-unsafe as C.
    - ajuc 12y ago
      in one important practical aspect it isn't - strings are length+content in pascal, not null-delimited as in c. It's very important difference.
      - 4ad 12y ago
        You read into buffers, not strings. You can easily have buffers overflows. Pascal arrays are bounds checked, but not when it matters: http://wiki.lazarus.freepascal.org/Secure_programming#Buffer_Overflow http://wiki.lazarus.freepascal.org/Secure_programming#Buffer....
zanny 12y ago
Reading through some gstreamer code this weekend, I contend that "C of 30 years ago is not the C of today". It is still all the most horribly insecure and obtuse passing of raw pointer manipulation and bitwise logic ever. The preprocessor is still hell on software. Every variable is named something like gst_hello_world_parser_box because when you write complex software in it you always get huge name conflicts. It still thinks the best way to manage memory is to not manage it at all. People complained for so long about having to put your deletes in destructors in C++, too bad you have no such thing in C at all - you don't have classes, after all. Guess it has to go in the procedural function logic. Like 30 years ago.