Linked by MOS6510 on Thu 10th Jan 2013 23:25 UTC
General Development "For years I've tried my damnedest to get away from C. Too simple, too many details to manage, too old and crufty, too low level. I've had intense and torrid love affairs with Java, C++, and Erlang. I've built things I'm proud of with all of them, and yet each has broken my heart. They've made promises they couldn't keep, created cultures that focus on the wrong things, and made devastating tradeoffs that eventually make you suffer painfully. And I keep crawling back to C."
Thread beginning with comment 548368
To view parent comment, click here.
To read all comments associated with this story, please click here.
moondevil
Member since:
2005-07-08

"The UNIX guys also decided to ignore the languages of their time, which provided already better type checking than C does.

And there is no way you could possibly be wrong about that!
"

Then why did they not use Algol 60 or PL/I, which were the system programming languages of the time?


"no modules

Sure it has them, though presuming you didn't know about them, you have no idea what "static" on globals and functions means.
"

It is has not.

Separate compilation is a primitive form of modules, but it is not the same.


"no way to namespace identifiers besides 70's like hacks

Namespaces are a mixed bag. Sometimes they might seem useful, but more often than not I've seen them abused and make simple problems a lot more complex. Also, they are a nightmare to debug, especially when combining code from various sources (e.g. library linking) - name mangling is a linker's nightmare. It seems that huge projects, like the Linux kernel for instance, seem to work just fine without them.
"

Sure we could also keep on using the original UNIX, why care about progress?


"null terminated strings are a open door to security exploits
the way arrays decay into pointers ditto

I think you're more complaining about a lack of automatic range checking. Sometimes it's useful, sometimes it isn't (mainly by introducing invisible glue code that can mess up some assumptions, e.g. atomicity).
"

Forget about the NULL character, boom!

Arrays should not be manipulated as pointers.

As for the usual C argument about arrays bound checking, all modern languages that compile to native code allow for selective disable of bounds checking if required.

"weak type checking

Compared to what? For my tastes the type checking in C is pretty strong.
"

Almost every other static type language out there?


"pointer aliasing forbids certain types of optimizations

"restrict" has been in C since 1999. Your complaint is 13 years out of date.
"

Except, like register, the compiler is free to ignore it and besides gcc and clang many C vendors still don't fully implement C99.

"Read MISRA C

They ask for money, no thanks. (NASA coding guidelines are an interesting read though.)
"

In our society people tend to get money for their work.

"Enable all warnings as errors

Not all warnings are errors and while it helps in development, it's very bad for e.g. libraries to ship code with -Werror enabled, since a change in compiler versions can introduce new/different checks or obsolete build options and thus make break your build.
"

You can always turn off false positives.

"Use static analyzers as part of the build process

lint has been in Unix since V7 (1979).
"

Sure, but:

- UNIX is just one OS among many
- Being available does not mean developers use it

"[Objective-C, C++] do offer more secure language constructs, but they are undermined by the C constructs they also support.

It is true that C gives you greater freedom in certain things and that includes shooting yourself in the foot. No question about it. On the other hand, certain things are much easier and better done in C (low-level data crunching routines).
"

Like in many other languages.

"Even Ritchie did recognize that C has a few issues:
http://cm.bell-labs.com/who/dmr/chist.html

And there he claims, among other things, that C type specifications are richer than Pascal's, directly contradicting your earlier statement. Be careful who you cite to support your case.
"

Sure, when compared with the original ISO Pascal. The ISO Extended Pascal as any other Pascal dialects are more expressive than C.

"If UNIX did not get copied in all universities all over the world in the early 80's, C would just be another language in history books.

Looks like somebody's got an axe to grind.
"

UNIX is a good operating system, but it is not the god of operating systems.

Reply Parent Score: 5

saso Member since:
2007-04-18

Then why did they not use Algol 60 or PL/I, which were the system programming languages of the time?

Because, if you had even read the few Wikipedia pages on C, you'd know that C derives from Algol 60. The line is roughly this: Algol -> CPL -> BCPL -> B -> C. Each of those steps had its reasons and I'm not going to list them here. Your attempt to portrait the designers of C as conceited merely shows that you carry a personal grudge that *your* language of choice didn't become ubiquitous (I presume it's Pascal, since you mentioned it so fondly - I've met a few FreePascal enthusiasts and they are argue quite similarly to you).
As for PL/I - it was first published in 1964 when the predecessors of C were already fairly underway in their own life, and it was a proprietary product of IBM (whereas C was designed at Bell Labs). Your romantic view of the wide availability of quality computer languages in the 60s is totally missing the reality of development back then.

Separate compilation is a primitive form of modules, but it is not the same.

Either they are modules (albeit in primitive form), or they aren't. You've managed to contradict yourself in a single sentence - good job. It's also sweet that you try to declare your definition of a module as authoritative. Have you ever considered that perhaps not everybody agrees with your definition?

Sure we could also keep on using the original UNIX, why care about progress?

Wow, FreePascal on Windows user, I presume. The aura of your smugness makes my screen damp. Simply because something is old doesn't mean it's bad.
Why do you think that "more features" = "progress"? Natural languages, for instance, often times simplify their grammar through more use (e.g. the regularization of the past-tense form of verbs in English).

Forget about the NULL character, boom!

NULL is actually a macro typically defined to ((void*)0), but I understand if your case-insensitive eyes don't see the difference.
Offhand remarks get offhand responses.

Arrays should not be manipulated as pointers.

Yes, your personal opinion on the matter is really insightful.

As for the usual C argument about arrays bound checking, all modern languages that compile to native code allow for selective disable of bounds checking if required.

This would be easy enough to introduce into C as well, say, by introducing an "array" keyword in variable definitions (which would turn on dynamic range checks). No need to redesign the language from the ground up. Might be nice to have, no dispute there.

Almost every other static type language out there?

This is a pretty slimy tactic to try and shift the burden of proof onto me. I'd now have to provide an extensive list to show that other static type checking languages out there have more relaxed rules, never mind even how one would qualify what "weak" and "strong" static type checking means. I don't play this way. You claimed C type checking is weak, it's yours to prove, not mine to disprove.

Except, like register, the compiler is free to ignore it and besides gcc and clang many C vendors still don't fully implement C99.

Oh my, is support really that bad?! Oh wait, you just pulled that one straight out of your behind:
https://en.wikipedia.org/wiki/C99#Implementations
Mind you, GCC still isn't fully C99 compatible: http://gcc.gnu.org/gcc-4.7/c99status.html so even your "GCC and clang" statement is false. Do you even google before you assert something?

In our society people tend to get money for their work.

That's not what I meant. I mean is that some random dude on the Internet isn't going to persuade me to spend money on a product that he insinuates will "fix" my coding practices.

You can always turn off false positives.

Obviously you've never built any bigger product somebody else coded from source, have you? I don't have the time to comb through somebody else's build tools to find which options fail and how to disable them.

UNIX is just one OS among many

Other platforms have other static analyzers. But UNIX has been the platform of birth for C, so I just wanted to show you that what you say here is not news to native C coders.

Being available does not mean developers use it

So you think forcing people is the proper approach? Have you ever considered that some people might not like that? Of course not, you are beyond error (see "arrays shouldn't be treated as pointers" comment above).

Like in many other languages.

What I was talking about is the contrast between highly abstract languages (Objective-C's OO part, Java, etc.) and lower abstraction languages (C). Of course you can write data crunching in other low-level languages (even Assembly for that matter).

Sure, when compared with the original ISO Pascal. The ISO Extended Pascal as any other Pascal dialects are more expressive than C.

Except that ISO Extended Pascal didn't exist when Kernighan and Ritchie designed C, so your citation of Ritchie to support your case misses the chronological order in which these languages appeared. According to Wikipedia, the first Pascal compiler in the US was written for the PDP-11, much later than UNIX appeared and probably even after C.

UNIX is a good operating system, but it is not the god of operating systems.

I never said so, but it's history is intertwined with C, so knowing about UNIX gives you a good idea how C developed.

Reply Parent Score: 4

moondevil Member since:
2005-07-08

"Then why did they not use Algol 60 or PL/I, which were the system programming languages of the time?

Because, if you had even read the few Wikipedia pages on C, you'd know that C derives from Algol 60. The line is roughly this: Algol -> CPL -> BCPL -> B -> C. Each of those steps had its reasons and I'm not going to list them here. Your attempt to portrait the designers of C as conceited merely shows that you carry a personal grudge that *your* language of choice didn't become ubiquitous (I presume it's Pascal, since you mentioned it so fondly - I've met a few FreePascal enthusiasts and they are argue quite similarly to you).
"

Well yes.

I never used FreePascal though.

I am old enough to have used C and Pascal when the first compilers were being made available in ZX Spectrums.

As for PL/I - it was first published in 1964 when the predecessors of C were already fairly underway in their own life, and it was a proprietary product of IBM (whereas C was designed at Bell Labs). Your romantic view of the wide availability of quality computer languages in the 60s is totally missing the reality of development back then.


I didn't say they were top quality, only better than C.

According to epoch documentation many companies did license languages on those days.

"Separate compilation is a primitive form of modules, but it is not the same.

Either they are modules (albeit in primitive form), or they aren't. You've managed to contradict yourself in a single sentence - good job. It's also sweet that you try to declare your definition of a module as authoritative. Have you ever considered that perhaps not everybody agrees with your definition?
"

I only care about the Computer Science definition and C does not offer that.

http://en.wikipedia.org/wiki/Modular_programming

"Sure we could also keep on using the original UNIX, why care about progress?

Wow, FreePascal on Windows user, I presume.
"


Never used Free Pascal.

Windows is just another operating system among many.

The aura of your smugness makes my screen damp. Simply because something is old doesn't mean it's bad.
Why do you think that "more features" = "progress"?


Usually more features tend to improve programmer's productivity.

Natural languages, for instance, often times simplify their grammar through more use (e.g. the regularization of the past-tense form of verbs in English).


Well, actually English grammar was originally simplified thanks to the Normand occupation:

http://geoffboxell.tripod.com/words.htm

"Forget about the NULL character, boom!

NULL is actually a macro typically defined to ((void*)0), but I understand if your case-insensitive eyes don't see the difference.
Offhand remarks get offhand responses.
"

I have seen enough code like str[index] = NULL to make that statement.

Not everyone writes str[index] = '\0', specially the ones that like to turn off warnings.

Too many scars of off-shoring projects.

"Arrays should not be manipulated as pointers.

Yes, your personal opinion on the matter is really insightful.
"

I imagine any security expert would agree, but I might be wrong.

"Almost every other static type language out there?

This is a pretty slimy tactic to try and shift the burden of proof onto me. I'd now have to provide an extensive list to show that other static type checking languages out there have more relaxed rules, never mind even how one would qualify what "weak" and "strong" static type checking means. I don't play this way. You claimed C type checking is weak, it's yours to prove, not mine to disprove.
"

Should I now give a CS lecture about classes of static typing?

"Except, like register, the compiler is free to ignore it and besides gcc and clang many C vendors still don't fully implement C99.

Oh my, is support really that bad?! Oh wait, you just pulled that one straight out of your behind:
https://en.wikipedia.org/wiki/C99#Implementations
"

I am well aware of that Wikipedia page.

There many more C vendors than what Wikipedia lists and many customers don't let you choose the compiler to use.

Mind you, GCC still isn't fully C99 compatible: http://gcc.gnu.org/gcc-4.7/c99status.html so even your "GCC and clang" statement is false. Do you even google before you assert something?


That assertion was because many think that gcc and clang are the only compilers that matter.

"You can always turn off false positives.

Obviously you've never built any bigger product somebody else coded from source, have you?
"

Well, have you ever done a 300+ developers multi-site project?

"UNIX is just one OS among many

Other platforms have other static analyzers. But UNIX has been the platform of birth for C, so I just wanted to show you that what you say here is not news to native C coders.
"

To expert C coders, you mean.

"Being available does not mean developers use it

So you think forcing people is the proper approach? Have you ever considered that some people might not like that? Of course not, you are beyond error (see "arrays shouldn't be treated as pointers" comment above).
"

No, I am just a meaningless person in this world.

Just stating my opinion.

"Sure, when compared with the original ISO Pascal. The ISO Extended Pascal as any other Pascal dialects are more expressive than C.

Except that ISO Extended Pascal didn't exist when Kernighan and Ritchie designed C, so your citation of Ritchie to support your case misses the chronological order in which these languages appeared. According to Wikipedia, the first Pascal compiler in the US was written for the PDP-11, much later than UNIX appeared and probably even after C.
"

Point taken.

"UNIX is a good operating system, but it is not the god of operating systems.

I never said so, but it's history is intertwined with C, so knowing about UNIX gives you a good idea how C developed.
"

Agreed.

Reply Parent Score: 2

znby Member since:
2012-02-03

"Then why did they not use Algol 60 or PL/I, which were the system programming languages of the time?

...
As for PL/I - it was first published in 1964 when the predecessors of C were already fairly underway in their own life, and it was a proprietary product of IBM (whereas C was designed at Bell Labs). Your romantic view of the wide availability of quality computer languages in the 60s is totally missing the reality of development back then.
"

Interestingly enough, Multics, whose developers included Ritchie and Thompson, was written in PL/1 and used one of the first non-IBM compilers for the language. PL/1 was by all accounts a product of 'design by committee' and compilers for it which supported the entire language were difficult to implement and required high end computers at the time.

Reply Parent Score: 1