On 2012-05-18, at 15:07, Michael G Schwern wrote:
Bagging on C is like bagging on Shakespeare. They were severely limited in hardware, didn't have a whole lot of prior art to go on and not a whole lot of people to talk to about it. Smalltalk, ML, Pascal, Prolog, Lisp and SQL all came out about the same time, and had solved most of the problems below (in pieces), so there's only so much I can forgive.
Smalltalk came out ten years later. Pascal was basically useless, so much of the language was undefined. SQL is not a procedural language, I don't know what it's doing in the list, you might as well add runoff. Lisp and Prolog are not low enough level to be used in the problem space that C addresses. Even PL/1 and most other other systems programming languages of the time required more runtime support. Compare it with languages that can be used to solve the same problems as C, like Bliss and Forth and Fortran and PL/M And most of the problems you list are complete bullshit, if you mean them as problems they should have avoided 50 years ago.
Lack of memory protection. Lack of overflow protection.
You can't write memory allocation code if you the language doesn't let you do arbitrary things with pointers.
Lack of automatic memory management.
That's not a problem, that's a requirement. C was the language that memory management code was being written in.
Fixed size strings.
Changing that requires memory management, which can't be part of the language.
Magic data in strings (null character).
The debate between null-terminated and counted strings was huge at the time, and counted strings produce their own failure modes. For example, on version of Pascal I used had a hard 255 character limit on strings.
Fixed size data structures.
See fixed size strings.
Basic string and memory functions which are unsafe at any speed. Type system tied to hardware definitions.
Far less than in other languages of the time, and C actually made an effort to force programmers not to use hardware-specific sizes. I had to port code in PL/1 and we finally threw it out, one of the big problems was fixed 35-bit integers (yes, 35-bit, on a 36-bit system).
How much hell does 64 bit computing still cause because of this?
Less than if people had standardized on PL/1.
Very static but very weak typing (makes it more a chore than a protection). No arbitrary precision math (still a modern mistake).
See fixed size strings.
Unsafe type casting.
See lack of memory protection.
No way to define new types (typedef just renames).
I've never run into a language that had that, that could be used for what C is used for.
Awful I/O design (I'd need time to make that less subjective).
C doesn't have I/O, any more than Lisp or Modula does. However, the usual C runtime library is var better than that for contemporaries like FORTRAN, Pascal, APL, and anything that made non-UNIX native system calls.
Basic language features done by a preprocessor.
Like Lisp.
Awful variable argument function interface.
There was no variable argument function interface in C, it was patched on later to allow people to write printf without assembly glue. Most languages of the time don't have one.
Strings are just arrays (and the sins you can commit with that). Arrays are just pointers (ditto).
See fixed size strings and lack of memory protection.
Generally unportable (much critical functionality is outside the language).
The only systems programming language I've used that's easier to write portable code in is Fortran. Etcetera, etcetera, etcetera. I'll give you the fall-through in case. And any other systems programming language I've used has been worse. If PL/1 had caught on, you'd have been pissed.
