5 ms·

Ugh, this is close to being a troll post. Yes C has its weaknesses and domains appropriate to it's use. But sentences like "Lacking a strong and expressive typ

Ugh, this is close to being a troll post. Yes C has its weaknesses and domains appropriate to it's use. But sentences like "Lacking a strong and expressive type system, C not only permits but encourages its programmers to sacrifice correctness, safety, robustness, testability, and maintainability in favor of some highly underdeveloped and ill-measured ideas about “performance”. Much of the infrastructure of the Internet is built out of this garbage." and especially words like "garbage" only exposes the author as someone who doesn't know what he is writing about. (ok i could have used the shorter word "fool" here, but ..). The "infrastructure of the internet" (including the underlying operating systems) is one of the domains in which C shines. There is good reason that even today, large chunks of "infrastructure" code is written in C/C++. "anybody who considers C for high-level application development at this point in history, is in a grievous state of sin" With "high level" being conveniently undefined and without any examples, that statement means next to nothing. What a terrible, ill thought out article.

jacquesm 17y ago
C is advanced assembler. It is an absolutely great language for system level stuff, especially because everything is explicit, no relying on side effects or stuff hidden from view. The thread of execution is extremely easy to follow. The only thing I would change if we could revisit the past is that I would add a string primitive to the language with a half decent set of string operators. That would have made my life a lot easier at some point in the past. The funny thing is that most languages that people use that criticize 'C' are usually at the core levels written in C. There is probably a good case to be made for the claim that Unix would not exist if it weren't for the C language.
- evgen 17y ago
  > The funny thing is that most languages that people use that criticize 'C' are usually at the core levels written in C. The difference is that the people using these higher level languages only depend on a single set of maintainers who need to get the primitives right once instead of every random coder needing to manage buffers, garbage collecting unused memory, threading, and a host of other landmines on each and every project.
  - jacquesm 17y ago
    I think those 'random coders' would grow up quite rapidly if they had to learn how to program for real. It's the high level language cruft that is a prime source of all the endless layering of glue on top of other glue that we're stuck with. Less scripting, more binaries. I cringe every time I install some minor system level package and I have to include perl, awk, php and python or some other combination of stuff.
    - cturner 17y ago
      Funnily enough the proliferation of those scripting languages has made it easier to get a picture of what's going on if you do get rooted by the consequences of running a flakey C app. In the old days the md5 binary would be broken and you were pretty much screwed if the other guy was good. But these days you can hammer out manual md5 algorithms and do other stuff using perl, python, and anything else at your disposal - things that are deployed by default on contemporary unix distributions. Better still, if you've got a book on unix systems calls you can absolutely fly through troubleshooting techniques that weren't practical before. (Sure the bad guys could just delete your VMs, but then that is a clear sign that the system has had it - and that signal is useful in and of itself - one of the difficult things in a situation like that is making a call on how far gone your system is so you can set short-term priorities in the lead up to rebuilding everything)
    - evgen 17y ago
      Good thing those coders wading around what you seem to consider the shallow end of the coding pool are not writing things like our nameservers, web servers, operating systems, or anything else important. Oh, that's right, they are. And they keep fucking up. Repeatedly. When this keeps happening over and over again it is time to consider the possibility that the problem isn't the craftsman but the tool. The advantage of using lots and lots of glue languages is that it forces the important bits to be loosely coupled, adds flexibility to the development and deployment process, and leads to systems that are easier to comprehend and reason about. The only things that should be opaque binaries are system libraries and VMs/runtimes. Everything else should be "glue".
- kingkongrevenge 17y ago
  > The funny thing is that most languages that people use that criticize 'C' are usually at the core levels written in C. The JVM and MS CLR are largely in C++.
- jonshea 17y ago
  You and I must use different definitions for “side effects or stuff hidden from view” if you think those are things you avoid by programming in C.
  - jacquesm 17y ago
    The only really 'hard' thing I ever did in C was write an OS with interrupt handlers that passed control to user space. Debugging that took me more time than I care to remember, I hung that box so often that I hooked the reset switch up to a foot pedal :) Other than that C has been pretty good to me in terms of showing where the bugs are. Post mortem debugging would usually give you the location of your crash and that plus a little bit of deduction will tell you what you're doing wrong. Memory overwrites (and stack overwrites) are things that belong to a certain phase of coding where you are still learning the ropes and you have not yet mastered the idiomatic solutions that people will use to avoid such problems. Setjmp and longjmp are also an excellent source of hard to find bugs, as well as multi-threading (the multi-threading problems are not unique to C, some languages are simply better at doing that sort of thing, occam for instance). I've heard C compared to a race car, it's great as long as you stay between the lines, take a turn too fast and you're heading straight for trouble. Experience (as in bumping your head a couple of times) will make sure that you know how far you can push it. C is like any other powertool (think chainsaw or plasmacutter), you can easily get hurt but once you've mastered the tool it is quite amazing what you can do with it. I got in to C after a long period of writing almost nothing but assembly language (x86, 68K and a bunch of 8 bitters) and I remember thinking of C as a very 'high level language'. My perspective has changed a bit since then...
- MaysonL 17y ago
  The funny thing is that most languages that people use that criticize 'C' are usually at the core levels written in C. There is probably a good case to be made for the claim that Unix would not exist if it weren't for the C language. Check out Oberon (both the language(s) and the operating system(s)) for a look at an alternate universe in which C doesn't exist and Unix never happened. And people are happy. And anything that can be done in C can be done. Although some mistakes are significantly more difficult to commit.
kingkongrevenge 17y ago
What's your issue with the quote? C does not have a proper type system. C code is inevitably loaded with unsafe cast operations. > C/C++ He was talking about C, not C++. C++ has a good type system and also makes it easy to avoid bounds checking problems.
jonshea 17y ago
Michael taught both the SICP and the Software Design and Implementation classes at an ivy league school for several years. I’m fairly certain that he knows what he’s talking about. I’ll admit that the post was a little ranty. It was quickly reworked from an internal email conversation, and it’s not intended to be a taken as if it came from a conference proceeding. With that in mind, do you deny that C/C++ “sacrifice correctness, safety, robustness, testability, and maintainability in favor of… ‘performance’”?
- deleted 17y ago
  [deleted]
jerf 17y ago
Indeed, large swathes of the Internet are written in C. Large swathes of the internet have also had buffer overflow after buffer overflow after buffer overflow after buffer overflow after buffer overflow after buffer overflow after buffer overflow after buffer overflow after buffer overflow after buffer overflow after buffer overflow after buffer overflow after buffer overflow... for decades. At some point you have to stop blaming "lazy" programmers and start pointing fingers at the language that let the same bug through thousands upon thousands of times; a bug whose term almost has no meaning in other languages. How do you "buffer overflow" Java or O'Caml? (It isn't quite impossible, necessarily, but it's multiple orders of magnitude less likely.) A safe variant of C wouldn't have been that hard to create, but the culture wouldn't permit it. So... I also point fingers at the culture that has valued performance over correctness... not just highly, not just valued performance highly along with correctness, but has valued performance over correctness. Anyway, the whole "the internet is written in C" is a very weak argument in C's favor; it certainly fit a culture and can't be argued to be totally impractical, but a lot of the sharp edges aren't actually necessary, even with performance as a primary goal, and those sharp edges have claimed far too many victims. I totally respect the original authors, but it should have been incrementally improved into something much safer, instead of freezing in its 1970s level of development.
- ncarlson 17y ago
  > A safe variant of C wouldn't have been that hard to create, but the culture wouldn't permit it. C is a non-language. It's a tool used to give developers complete control of the hardware. It's just one step up from Assembler (to make the developers job a little bit easier). Adding type checking, buffer overflow mitigation, or any other extraneous domain-specific feature is completely outside scope of the language. If you need those features, write a language, dialect, or compiler extension which supports them.
  - jacquesm 17y ago
    My preference would have been a switch which would enable things like boundschecks on arrays.
  - 17y ago
agazso 17y ago
The SSL bug in this case happened because the programmers had wrong assumption about the network input (namely it doesn't contain the zero byte value). This type of wrong assumption can be made in any language. And this bug doesn't make buffer overflows or any other exploitable activities possible, so they are not dangerous in a way that 'usual' C code can be dangerous. Still it is a serious threat regarding the widespread usage of that particular library.

jacquesm 17y ago

C is advanced assembler. It is an absolutely great language for system level stuff, especially because everything is explicit, no relying on side effects or stuff hidden from view. The thread of execution is extremely easy to follow. The only thing I would change if we could revisit the past is that I would add a string primitive to the language with a half decent set of string operators. That would have made my life a lot easier at some point in the past. The funny thing is that most languages that people use that criticize 'C' are usually at the core levels written in C. There is probably a good case to be made for the claim that Unix would not exist if it weren't for the C language.

evgen 17y ago
> The funny thing is that most languages that people use that criticize 'C' are usually at the core levels written in C. The difference is that the people using these higher level languages only depend on a single set of maintainers who need to get the primitives right once instead of every random coder needing to manage buffers, garbage collecting unused memory, threading, and a host of other landmines on each and every project.
- jacquesm 17y ago
  I think those 'random coders' would grow up quite rapidly if they had to learn how to program for real. It's the high level language cruft that is a prime source of all the endless layering of glue on top of other glue that we're stuck with. Less scripting, more binaries. I cringe every time I install some minor system level package and I have to include perl, awk, php and python or some other combination of stuff.
  - cturner 17y ago
    Funnily enough the proliferation of those scripting languages has made it easier to get a picture of what's going on if you do get rooted by the consequences of running a flakey C app. In the old days the md5 binary would be broken and you were pretty much screwed if the other guy was good. But these days you can hammer out manual md5 algorithms and do other stuff using perl, python, and anything else at your disposal - things that are deployed by default on contemporary unix distributions. Better still, if you've got a book on unix systems calls you can absolutely fly through troubleshooting techniques that weren't practical before. (Sure the bad guys could just delete your VMs, but then that is a clear sign that the system has had it - and that signal is useful in and of itself - one of the difficult things in a situation like that is making a call on how far gone your system is so you can set short-term priorities in the lead up to rebuilding everything)
  - evgen 17y ago
    Good thing those coders wading around what you seem to consider the shallow end of the coding pool are not writing things like our nameservers, web servers, operating systems, or anything else important. Oh, that's right, they are. And they keep fucking up. Repeatedly. When this keeps happening over and over again it is time to consider the possibility that the problem isn't the craftsman but the tool. The advantage of using lots and lots of glue languages is that it forces the important bits to be loosely coupled, adds flexibility to the development and deployment process, and leads to systems that are easier to comprehend and reason about. The only things that should be opaque binaries are system libraries and VMs/runtimes. Everything else should be "glue".
kingkongrevenge 17y ago
> The funny thing is that most languages that people use that criticize 'C' are usually at the core levels written in C. The JVM and MS CLR are largely in C++.
jonshea 17y ago
You and I must use different definitions for “side effects or stuff hidden from view” if you think those are things you avoid by programming in C.
- jacquesm 17y ago
  The only really 'hard' thing I ever did in C was write an OS with interrupt handlers that passed control to user space. Debugging that took me more time than I care to remember, I hung that box so often that I hooked the reset switch up to a foot pedal :) Other than that C has been pretty good to me in terms of showing where the bugs are. Post mortem debugging would usually give you the location of your crash and that plus a little bit of deduction will tell you what you're doing wrong. Memory overwrites (and stack overwrites) are things that belong to a certain phase of coding where you are still learning the ropes and you have not yet mastered the idiomatic solutions that people will use to avoid such problems. Setjmp and longjmp are also an excellent source of hard to find bugs, as well as multi-threading (the multi-threading problems are not unique to C, some languages are simply better at doing that sort of thing, occam for instance). I've heard C compared to a race car, it's great as long as you stay between the lines, take a turn too fast and you're heading straight for trouble. Experience (as in bumping your head a couple of times) will make sure that you know how far you can push it. C is like any other powertool (think chainsaw or plasmacutter), you can easily get hurt but once you've mastered the tool it is quite amazing what you can do with it. I got in to C after a long period of writing almost nothing but assembly language (x86, 68K and a bunch of 8 bitters) and I remember thinking of C as a very 'high level language'. My perspective has changed a bit since then...
MaysonL 17y ago
The funny thing is that most languages that people use that criticize 'C' are usually at the core levels written in C. There is probably a good case to be made for the claim that Unix would not exist if it weren't for the C language. Check out Oberon (both the language(s) and the operating system(s)) for a look at an alternate universe in which C doesn't exist and Unix never happened. And people are happy. And anything that can be done in C can be done. Although some mistakes are significantly more difficult to commit.

kingkongrevenge 17y ago

What's your issue with the quote? C does not have a proper type system. C code is inevitably loaded with unsafe cast operations. > C/C++ He was talking about C, not C++. C++ has a good type system and also makes it easy to avoid bounds checking problems.

jonshea 17y ago

Michael taught both the SICP and the Software Design and Implementation classes at an ivy league school for several years. I’m fairly certain that he knows what he’s talking about. I’ll admit that the post was a little ranty. It was quickly reworked from an internal email conversation, and it’s not intended to be a taken as if it came from a conference proceeding. With that in mind, do you deny that C/C++ “sacrifice correctness, safety, robustness, testability, and maintainability in favor of… ‘performance’”?

deleted 17y ago
[deleted]

jerf 17y ago

Indeed, large swathes of the Internet are written in C. Large swathes of the internet have also had buffer overflow after buffer overflow after buffer overflow after buffer overflow after buffer overflow after buffer overflow after buffer overflow after buffer overflow after buffer overflow after buffer overflow after buffer overflow after buffer overflow after buffer overflow... for decades. At some point you have to stop blaming "lazy" programmers and start pointing fingers at the language that let the same bug through thousands upon thousands of times; a bug whose term almost has no meaning in other languages. How do you "buffer overflow" Java or O'Caml? (It isn't quite impossible, necessarily, but it's multiple orders of magnitude less likely.) A safe variant of C wouldn't have been that hard to create, but the culture wouldn't permit it. So... I also point fingers at the culture that has valued performance over correctness... not just highly, not just valued performance highly along with correctness, but has valued performance over correctness. Anyway, the whole "the internet is written in C" is a very weak argument in C's favor; it certainly fit a culture and can't be argued to be totally impractical, but a lot of the sharp edges aren't actually necessary, even with performance as a primary goal, and those sharp edges have claimed far too many victims. I totally respect the original authors, but it should have been incrementally improved into something much safer, instead of freezing in its 1970s level of development.

ncarlson 17y ago
> A safe variant of C wouldn't have been that hard to create, but the culture wouldn't permit it. C is a non-language. It's a tool used to give developers complete control of the hardware. It's just one step up from Assembler (to make the developers job a little bit easier). Adding type checking, buffer overflow mitigation, or any other extraneous domain-specific feature is completely outside scope of the language. If you need those features, write a language, dialect, or compiler extension which supports them.
- jacquesm 17y ago
  My preference would have been a switch which would enable things like boundschecks on arrays.
- 17y ago

agazso 17y ago

The SSL bug in this case happened because the programmers had wrong assumption about the network input (namely it doesn't contain the zero byte value). This type of wrong assumption can be made in any language. And this bug doesn't make buffer overflows or any other exploitable activities possible, so they are not dangerous in a way that 'usual' C code can be dangerous. Still it is a serious threat regarding the widespread usage of that particular library.