4 ms·

Interesting article, but he misses the right answer: if it isn't broken, don't fix it. C may not be the easiest language to learn, but you wouldn't want newbie

by alpad 15y ago

Interesting article, but he misses the right answer: if it isn't broken, don't fix it. C may not be the easiest language to learn, but you wouldn't want newbies messing with systems programming anyway. Higher level languages give you a more abstract view, but when you are doing systems programming that's not what you want, you need to be in full control. Only C gives you precise control of what the machine is doing all the time. You don't want a garbage collector to kick in unexpectedly, you don't want data structures to be allocated in mysterious ways.

willvarfar 15y ago
On the other hand, again and again bugs that come from the ability in C to alias have been exploited. His answer was of course EROS. Microsoft explored Singularity. Some of his colleagues went and wrote Go as a systems language (if not a kernel-side language).
moonchrome 15y ago
>You don't want a garbage collector to kick in unexpectedly, you don't want data structures to be allocated in mysterious ways. All of that (and everything else C is attributed with) can be accomplished without using an arcane preprocessor/include system and you can have niceties such as a saner type system, generics/macros, namespaces, etc. C is a language stuck with the design decisions that reflected the programming environments in the 60's and 70's but make absolutely no sense in modern context and now we are just stuck with it because of inertia.
- chipsy 15y ago
  I would agree and would elaborate that the major weaknesses of C are a combination of build system issues and an overly weak type system. It wasn't realistic to have the whole compile process done in memory in the early 70's, and OS virtual memory wasn't realistic either; but we've long surpassed those concerns, and that means that all the thinking about the program namespace, modules, linking, pre-processing, etc. is worth re-evaluating. As well, we can do better static checking now, without including any notion of GC; in an imperative execution model, leakage of memory, handles, processes etc. remains orthogonal to type safety. C has heavily bottlenecked program control logic from the beginning - a callstack, looping constructs, etc. - and allowing some equivalents to exist in its data structures would make user code tremendously more reliable. These changes, often paired with some more attention to concurrency, show up in all the newer system language designs - D, Go, Rust, Clay, BitC, etc.
- CJefferson 15y ago
  Anyone who tries building a better C (for example Go) seems to end up going "too far", and as well as fixing the things you mention, ends up adding garbage collection, and various other things which are not suitable for very low level systems programming. I teach C, and I would love a "cleaner C" mode, which just got rid of lots of the bizareeness of C, several of which you mention. The fact that many compilers will warn with '-Wall' about code which is clearly incorrect, but due to the rules of C they cannot simply reject, is irritating.
  - queensnake 15y ago
    (add -Werror - your students will never know.)
  - pjmlp 15y ago
    Fact is there are many examples of operating systems implemented with GC enabled systems languages. Spin, Oberon, Singularity, Home are just a few of them. The main problem is that for a systems programing language to be used a such, there much exist a successful operating system that uses it as its main language. In Windows 8, the main systems language is C++/CX (C++ with reference counting extensions), so the time will come.
  - cygx 15y ago
    The fact that many compilers will warn with '-Wall' about code which is clearly incorrect, but due to the rules of C they cannot simply reject, is irritating. The rules of C are actually stricter than many reople realize (add -std=c99 -pedantic-errors to gcc and you can get an idea about that -- this, however, still won't catch semantic errors like aliasing violations). Personally, I'm using clang with -Weverything and remove warnings as necessary. On gcc, there are a lot of useful warnings which are not included in -Wall. My current warning levels look like this: -std=c99 -pedantic -Werror -Wall -Wextra \ -Wmissing-prototypes -Wmissing-declarations -Wshadow -Wpointer-arith \ -Wcast-align -Wwrite-strings -Wredundant-decls -Wcast-qual \ -Wnested-externs -Winline -Wno-long-long -Wconversion -Wstrict-prototypes
javascriptlol 15y ago
"Only C"? What about Forth?
rntz 15y ago
You misunderstand his argument. He's not arguing that we should replace C with "higher-level languages" that don't give you precise control of the hardware; in fact, he bemoans the fact that the PL community at large seems interested only in such high-level languages. Nor is he complaining that C is hard to learn (I'm not sure where you got that impression). In fact, the paper mostly takes for granted that C needs to be replaced, and discusses the challenges in doing so, which may be why you assumed that BitC is (was, really) just another typical research-community high level programming language project. The fact is, C is broken, and we all suffer every day because of it. From a security perspective, C is a nightmare. It is not just an unsafe language (in the PL sense of having undefined behavior), but a rampantly unsafe language. Null pointers (which C.A.R. Hoare famously called his "billion-dollar mistake"), buffer overruns, unrestricted pointer arithmetic, arbitrary casting, manual memory management; all of these are the cause of innumerable bugs in real code, often critical security vulnerabilities. C is also not the nicest of languages to code in. It is terribly verbose. There is no good way of writing generic code in it. The preprocessor is a gigantic ugly hack. Writing portable C is a pain in the ass, and building it portably is doubly so. The worst part is, we know reasonable ways to solve most of these problems. In many cases we have known them for decades. Unfortunately, how to best integrate these solutions into a language and still keep it useful for systems programming was (and is) an open problem. I can't speak for Shapiro, but as I see it this is what BitC was aimed at doing.
- anon_d 15y ago
  C is far from "terribly verbose".
quanticle 15y ago
>Only C gives you precise control of what the machine is doing all the time. Maybe in 1979, it did. Modern C compilers alter and modify code quite radically, to the point where it's quite difficult these days to go back from optimized assembly back to the original C code. These days, C gives you a good illusion of control, but all too often, C programmers mistake illusion for reality.
- ajross 15y ago
  No, C gives you control. I have a syscall (bind(), say) that takes or returns a polymorphic array via a pointer. How many "system" languages represent something like a C pointer cast or union type with clear storage semantics? Or I want to write a code generator for my fancy new language interpreter and need to call mmap() to get an executable range. How many "system" languages let me call into that memory with native syntax? What you're describing is the difficulty in understanding what the guarantees of control are that you get form your compiler (and yes, that's a much more involved issue than simply reading a language spec). Yeah, C is hard. But the fact that you don't understand how the optimizer works (or how to read the generated assembly) isn't the work of an "illusion", it's just your own inexperience.

by alpad 15y ago

willvarfar 15y ago

On the other hand, again and again bugs that come from the ability in C to alias have been exploited. His answer was of course EROS. Microsoft explored Singularity. Some of his colleagues went and wrote Go as a systems language (if not a kernel-side language).

moonchrome 15y ago

>You don't want a garbage collector to kick in unexpectedly, you don't want data structures to be allocated in mysterious ways. All of that (and everything else C is attributed with) can be accomplished without using an arcane preprocessor/include system and you can have niceties such as a saner type system, generics/macros, namespaces, etc. C is a language stuck with the design decisions that reflected the programming environments in the 60's and 70's but make absolutely no sense in modern context and now we are just stuck with it because of inertia.

chipsy 15y ago
I would agree and would elaborate that the major weaknesses of C are a combination of build system issues and an overly weak type system. It wasn't realistic to have the whole compile process done in memory in the early 70's, and OS virtual memory wasn't realistic either; but we've long surpassed those concerns, and that means that all the thinking about the program namespace, modules, linking, pre-processing, etc. is worth re-evaluating. As well, we can do better static checking now, without including any notion of GC; in an imperative execution model, leakage of memory, handles, processes etc. remains orthogonal to type safety. C has heavily bottlenecked program control logic from the beginning - a callstack, looping constructs, etc. - and allowing some equivalents to exist in its data structures would make user code tremendously more reliable. These changes, often paired with some more attention to concurrency, show up in all the newer system language designs - D, Go, Rust, Clay, BitC, etc.
CJefferson 15y ago
Anyone who tries building a better C (for example Go) seems to end up going "too far", and as well as fixing the things you mention, ends up adding garbage collection, and various other things which are not suitable for very low level systems programming. I teach C, and I would love a "cleaner C" mode, which just got rid of lots of the bizareeness of C, several of which you mention. The fact that many compilers will warn with '-Wall' about code which is clearly incorrect, but due to the rules of C they cannot simply reject, is irritating.
- queensnake 15y ago
  (add -Werror - your students will never know.)
- pjmlp 15y ago
  Fact is there are many examples of operating systems implemented with GC enabled systems languages. Spin, Oberon, Singularity, Home are just a few of them. The main problem is that for a systems programing language to be used a such, there much exist a successful operating system that uses it as its main language. In Windows 8, the main systems language is C++/CX (C++ with reference counting extensions), so the time will come.
- cygx 15y ago
  The fact that many compilers will warn with '-Wall' about code which is clearly incorrect, but due to the rules of C they cannot simply reject, is irritating. The rules of C are actually stricter than many reople realize (add -std=c99 -pedantic-errors to gcc and you can get an idea about that -- this, however, still won't catch semantic errors like aliasing violations). Personally, I'm using clang with -Weverything and remove warnings as necessary. On gcc, there are a lot of useful warnings which are not included in -Wall. My current warning levels look like this: -std=c99 -pedantic -Werror -Wall -Wextra \ -Wmissing-prototypes -Wmissing-declarations -Wshadow -Wpointer-arith \ -Wcast-align -Wwrite-strings -Wredundant-decls -Wcast-qual \ -Wnested-externs -Winline -Wno-long-long -Wconversion -Wstrict-prototypes

javascriptlol 15y ago

"Only C"? What about Forth?

rntz 15y ago

You misunderstand his argument. He's not arguing that we should replace C with "higher-level languages" that don't give you precise control of the hardware; in fact, he bemoans the fact that the PL community at large seems interested only in such high-level languages. Nor is he complaining that C is hard to learn (I'm not sure where you got that impression). In fact, the paper mostly takes for granted that C needs to be replaced, and discusses the challenges in doing so, which may be why you assumed that BitC is (was, really) just another typical research-community high level programming language project. The fact is, C is broken, and we all suffer every day because of it. From a security perspective, C is a nightmare. It is not just an unsafe language (in the PL sense of having undefined behavior), but a rampantly unsafe language. Null pointers (which C.A.R. Hoare famously called his "billion-dollar mistake"), buffer overruns, unrestricted pointer arithmetic, arbitrary casting, manual memory management; all of these are the cause of innumerable bugs in real code, often critical security vulnerabilities. C is also not the nicest of languages to code in. It is terribly verbose. There is no good way of writing generic code in it. The preprocessor is a gigantic ugly hack. Writing portable C is a pain in the ass, and building it portably is doubly so. The worst part is, we know reasonable ways to solve most of these problems. In many cases we have known them for decades. Unfortunately, how to best integrate these solutions into a language and still keep it useful for systems programming was (and is) an open problem. I can't speak for Shapiro, but as I see it this is what BitC was aimed at doing.

anon_d 15y ago
C is far from "terribly verbose".

quanticle 15y ago

>Only C gives you precise control of what the machine is doing all the time. Maybe in 1979, it did. Modern C compilers alter and modify code quite radically, to the point where it's quite difficult these days to go back from optimized assembly back to the original C code. These days, C gives you a good illusion of control, but all too often, C programmers mistake illusion for reality.

ajross 15y ago
No, C gives you control. I have a syscall (bind(), say) that takes or returns a polymorphic array via a pointer. How many "system" languages represent something like a C pointer cast or union type with clear storage semantics? Or I want to write a code generator for my fancy new language interpreter and need to call mmap() to get an executable range. How many "system" languages let me call into that memory with native syntax? What you're describing is the difficulty in understanding what the guarantees of control are that you get form your compiler (and yes, that's a much more involved issue than simply reading a language spec). Yeah, C is hard. But the fact that you don't understand how the optimizer works (or how to read the generated assembly) isn't the work of an "illusion", it's just your own inexperience.