Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Systems Programmers Still Use C (2006)

bitc-lang.org

Post reply on HN
Print view View original

41–50 of 64 posts

Re: Why Systems Programmers Still Use C (2006)

#41

Post by ajross »

edwinnathaniel wrote: post #5

These days Java seems to become one of the choices to do system programming in a different area/level: HBase, Hadoop, Cassandra, GWT tools, MQ, App Servers (Jetty, Tomcat, GlassFish, etc), EhCache. Unless if people categorized the above software as non-system-programming.

It's mostly a semantics thing, but no: most "systems programmers" would not categorize those applications as "systems tasks". They're just apps. By convention, "systems programming" means dealing with the bottom of the abstraction stack. Java code can't make syscalls. Calling conventions for Java methods aren't specified at the level of CPU registers or instructions.

So writing a JVM is systems programming. Writing a Java-based data store is not, even though other stuff then sits on top of the store.

Re: Why Systems Programmers Still Use C (2006)

#42

Post by SkyMarshal »

bitc appears to be abandonned, but I cloned it from their hg repo and put it up on Github anyway. Here it is, for posterity:

https://github.com/bitc-repos/bitc

Projects like this make me wonder if they would have gotten further had they put it on a more social oss hub, be it Sourceforge in its day, or Github now.

Re: Why Systems Programmers Still Use C (2006)

#43

Post by queensnake »

CJefferson wrote: post #14
moonchrome wrote: post #4

Earlier quoted context omitted.

>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 programmi…

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…

(add -Werror - your students will never know.)

Re: Why Systems Programmers Still Use C (2006)

#44

Post by pjmlp »

CJefferson wrote: post #14
moonchrome wrote: post #4

Earlier quoted context omitted.

>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 programmi…

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…

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.

Re: Why Systems Programmers Still Use C (2006)

#45

Post by ijt »

ajross wrote: post #39
ijt wrote: post #38

I was surprised that the author thinks the syntax of Haskell is no better than that of C++. Let's look at a typical example. In Haskell, the signature for sort is sort :: Ord a => [a] -> [a] which just says that it takes a list of comparable things and returns another list of the same type. Here's the type signature for sort in C++: template void sort ( RandomAccessIterator first, RandomAccessIterator last, Compare c…

Please. The difference in terseness and clarity is made up almost entirely of the lenths of the symbol names: template void sort(I a, I b, C cmp); Now, the concepts aren't 1:1; Haskell for obvious reasons doesn't represent the idea of operating on storage directly, so you can't have an iterator and need to return a "new" list. C++ makes you write out the types you are parametrizing instead of getting it implicitly. A…

The difference is not only due to identifier length. Haskell's sort is a function in the mathematical sense. By looking at its type, I can see the input and output at a glance and understand how to use it. It's not immediately obvious from the signature of the C++ sort procedure that the "first" and "last" arguments are being used for both input and output. When you abbreviate the identifiers for STL sort it's even less obvious what's going on.

Re: Why Systems Programmers Still Use C (2006)

#46

Post by pjmlp »

smcdow wrote: post #25
edwinnathaniel wrote: post #5

These days Java seems to become one of the choices to do system programming in a different area/level: HBase, Hadoop, Cassandra, GWT tools, MQ, App Servers (Jetty, Tomcat, GlassFish, etc), EhCache. Unless if people categorized the above software as non-system-programming.

Curious as to how you would set up a DMA transaction in any of those languages? If you're doing system programming, you'll need to do DMA.

By providing an unsafe package that allows you do such things.

Have a look at:

Modula-3 + Spin

Oberon + Oberon System

Spec# + Singularity

Haskell + Home

OCaml + Mirage

Re: Why Systems Programmers Still Use C (2006)

#47

Post by lusr »

javascriptlol wrote: post #10

Also, this paper suggests that the answer to multi-tasking problems is to move the complexity out into the language. It's funny how PL researchers will always spin the situation so that it demands more PL research. If we're really moving into a many cores future as people suggest, then we should have architectures that give each application a dedicated core. No context switching. Of course, you'd need a simple system…

Jonathan Shapiro is not a traditional PL researcher. He is the architect and lead developer of EROS (www.eros-os.org) and CapROS (http://www.capros.org), and the author of a vast number of papers on secure and high-performance reliable real-time operating systems. The confinement mechanism in EROS was provably secure (i.e. provably impossible for applications to leak permissions) by Shapiro, and AFAIK is still the only meaningful and practical security mechanism demonstrated to do so, which is a pretty significant contribution in the field of computer science.

(Although having been a voyeur of his work for over a decade now, I'm sure he would be quick to point out that much of EROS was based on formalising ideas from GNOSIS and KeyKOS, and the work of Hardy, Franz, Landau et al. over 20-30 years earlier.)

BitC evolved out of a need to prove that the implementation of the confinement mechanism (prototyped in EROS) matched the model (proven in his PhD thesis), and so the CapROS system (built in BitC) was born (well that plus some architectural changes based on lessons learned from EROS). From that perspective it's much more than just another systems programming language - it has a definitive purpose to advance the state of the art in practical and theoretical computer science. (FWIW, they never did accomplish this goal [http://www.bitc-lang.org/docs/bitc/bitc-origins.html]).

Re: Why Systems Programmers Still Use C (2006)

#48

Post by cygx »

CJefferson wrote: post #14
moonchrome wrote: post #4

Earlier quoted context omitted.

>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 programmi…

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…

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

Re: Why Systems Programmers Still Use C (2006)

#49

Post by javascriptlol »

lusr wrote: post #47
javascriptlol wrote: post #10

Also, this paper suggests that the answer to multi-tasking problems is to move the complexity out into the language. It's funny how PL researchers will always spin the situation so that it demands more PL research. If we're really moving into a many cores future as people suggest, then we should have architectures that give each application a dedicated core. No context switching. Of course, you'd need a simple system…

Jonathan Shapiro is not a traditional PL researcher. He is the architect and lead developer of EROS (www.eros-os.org) and CapROS ( http://www.capros.org ), and the author of a vast number of papers on secure and high-performance reliable real-time operating systems. The confinement mechanism in EROS was provably secure (i.e. provably impossible for applications to leak permissions) by Shapiro, and AFAIK is still the…

A better idea would be to just build a small system whose security was obvious. Computer scientists are right to mimic mathematics. They're just mimicking it too directly. Mathematics is based on construction from simple axioms and cross-checking of different theories. Computer systems should be reduced to small parts with redundant checks against human error. If you prove a kernel "correct" that just means it will be that much harder to rewrite it if it turns out not to be what you wanted.
Post reply on HN