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

31–40 of 64 posts

Re: Why Systems Programmers Still Use C (2006)

#31

Post by javascriptlol »

smcdow wrote: post #24
javascriptlol wrote: post #17

Earlier quoted context omitted.

Why would you be moving data between cores? I'm talking about an arrangement where each core is dedicated to a single program. No sharing of memory, even via the kernel. Each hardware devices talks to a single core only. Multiplexing of hardware would be done in.. hardware. For all intents and purposes the "core" could be out on the network. All this throughput nonsense is benchmrk lies. Websites are not as a general…

How do you handle DMA and other I/O in your system?

Each hardware device is accessed by a single process at a time. Any multiplexing that needs to be fast is done in hardware. Other multiplexing can be done in user space. For example, and application can request a dedicated channel to some blocks on the hard disk (adjudicated by the OS) or just use another hard disk. Remember, we're building simple applications here so things don't need to constantly write off the the disk for various tasks. You would only be dealing with the disk if your actual data was too big to fit into memory. Cases like that need careful design, not delegation off to some other programmer who doesn't know your problem.

If you're running a server application you split it into some reasonable number of tasks and allocate cores to them as needed. Nothing else runs on the system at all. If you need more cores either upgrade your hardware or you build another identical machine and talk to it over the network. If you look at the way Moore designs, he's crafting a complete artifact to solve a specific problem, not just throwing generic parts together.

Re: Why Systems Programmers Still Use C (2006)

#32

Post by javascriptlol »

tmurray wrote: post #29
javascriptlol wrote: post #22

Earlier quoted context omitted.

You are completely misunderstanding me. I am not saying "let's all move to this new utopian system". I am suggesting that we move away from the idea of making universal systems entirely. Write software that is small enough that complete rewrites can be accomplished without trouble. The current situation is to build ourselves a problem that gets harder and harder to undo as time goes on. You can't call something that'…

It sounds like you're basically proposing Plan 9--lots of very small, single-purpose components with one standardized way of passing data between them used across the entire system. Also, you can ask a lot of people to give up binary compatibility and be okay, but asking people to give up source compatibility and change applications is a much, much harder pill to swallow. Specialized environments (like the syscall-sh…

I'm not really interested in what's "considered useful". Look at the state of web applications. Basically what we could already do in 1996 but using more resources and full of ads and other distractions. And yet to many people this step backwards represents state of the art computing. "Productivity" is highly overrated. Computers are already extremely useful without a bunch of gimmicks. Most of the Web 2.0 companies are creating the desire for their own product. Facebook has turned family photo sharing into a circus show. It doesn't serve any need other than to push for more neomaniacal computerisation. Some people will want to share family photos over the web. We can do that with very simple software. It can even be loaded on demand and sandboxed without any configuration without a hugely complex platform. _Simple_ virtual machines capable of this kind of work aren't hard to construct. But people keep chasing idiotic benchmarks instead. And if it's too slow then change the hardware to make sandboxing easier.

Re: Why Systems Programmers Still Use C (2006)

#33

Post by stonemetal »

andrewflnr wrote: post #28
javascriptlol wrote: post #18

Earlier quoted context omitted.

Thanks for the link. I will check this out later. >Can you imagine not having Unix-like systems, and not being able to use C and all the languages built around that ecosystem? Yes! Charles Moore has been essentially living this since the 1970's. No many have his level of courage though.

You mean this one? http://en.wikipedia.org/wiki/Charles_H._Moore Can you give some more detail? What does he use?

Towards the bottom of that page it mentions color forth. That is what he uses. It is a forth like language that removed punctuation and replaces it with colors.

Re: Why Systems Programmers Still Use C (2006)

#34

Post by signa11 »

why fix something that is not broken ? with systems programming you wouldn't want anyone/everyone to mess around with it anyways. i don't need bound-checked-arrays, or or garbage-collection (oh the humanity!) at random unpredictable times. c gives an unprecedented level of control over what the machine is doing, for more abstract level interface to the machine, use whatever suits your fancy...

Re: Why Systems Programmers Still Use C (2006)

#35

Post by andrewflnr »

stonemetal wrote: post #33
andrewflnr wrote: post #28

Earlier quoted context omitted.

You mean this one? http://en.wikipedia.org/wiki/Charles_H._Moore Can you give some more detail? What does he use?

Towards the bottom of that page it mentions color forth. That is what he uses. It is a forth like language that removed punctuation and replaces it with colors.

Ah, upon further reading, colorForth has its own operating system, so he probably uses that too. I had seen the forth bits, but the GP implied he was using some non-Unix OS, and I was still curious about that.

Re: Why Systems Programmers Still Use C (2006)

#36

Post by anon_d »

rntz wrote: post #19
alpad wrote: post #2

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

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…

C is far from "terribly verbose".

Re: Why Systems Programmers Still Use C (2006)

#37

Post by RodgerTheGreat »

andrewflnr wrote: post #35
stonemetal wrote: post #33

Earlier quoted context omitted.

Towards the bottom of that page it mentions color forth. That is what he uses. It is a forth like language that removed punctuation and replaces it with colors.

Ah, upon further reading, colorForth has its own operating system, so he probably uses that too. I had seen the forth bits, but the GP implied he was using some non-Unix OS, and I was still curious about that.

Forth is conventionally a compiler, REPL, editor and OS all in one package. If I recall correctly, the reference implementation of ColorForth happens to run as a Windows application, but it pretty much lives in its own memory image and could probably be made bootable.

Re: Why Systems Programmers Still Use C (2006)

#38

Post by ijt »

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 comp );

The difference in terseness and clarity is a big reason why I use Haskell when I have a choice.

Re: Why Systems Programmers Still Use C (2006)

#39

Post by ajross »

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. And there are no doubt some really good arguments why Haskell is terser and clearer than C++.

But this isn't one of them. Come on.

Re: Why Systems Programmers Still Use C (2006)

#40

Post by ajross »

quanticle wrote: post #26
alpad wrote: post #2

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

>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.

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.

Post reply on HN