
DadHacker on why C is staying - fogus
http://www.dadhacker.com/blog/?p=1161
======
TallGuyShort
I really like Linus Torvald's quote:

>> Some people seem to think that C is a real programming language, but they
are sadly mistaken. It really is about writing almost-portable assembly
language

And that's why comparing C to other, more modern languages is kind of useless
- it all comes down to what kind of programming you're doing. Even though more
expressive languages have been created and more efficient ways to create
programs are around, C is a very nice balance between high-level syntax and
low-level actions.

~~~
bprater
Agreed. When you are bit-banging and other low-level stuff, you want a
language like C.

It's such a silly argument. Good programmers pick the language that matches
the problem they are trying to solve. Anyone that considers themselves a
hacker isn't a square peg in round hole kind of person. They have several
tools in their bag and will pick out the most appropriate one for the job.

That's all the comes to mind these days when I see these arguments: people
need to open up their field of view and see what other great language exist
for their craft. Did Leonardo only use paintbrushes to write in his notebooks?

~~~
stcredzero
You can do bitwise operations in VisualWorks Smalltalk quite efficiently,
particularly for encryption applications. Of course, it helps that the
encryption library author and the VM engineer at the time collaborated
closely. (Hence, the existence of classes like ThirtyTwoBitArray.)

I seem to remember a study someone did with CISC machines like VAX. On
average, a C statement resulted in 2.5 machine language instructions.

~~~
hazzen
It isn't the ability to do efficient bit operations that is a strength of C -
it is the ability to easily and succinctly do whatever you want to the bits in
memory. Arbitrary pointer/memory operations help greatly in writing things
like memory managers, device drivers, and all of the other wonderful parts the
make up the guts of an OS.

 _edit_ : Added the text "easily and succinctly" as a qualifier on doing
things to bits in response to stcredzero's comment. It isn't that C is the
only language to allow it, it is that C allows one to do it without obscuring
your intent. C# handles this quite well with _unsafe_ blocks, Java not so
much.

~~~
stcredzero
I want to go against the misconception that high level languages mean that you
have to give up control over bits. You _can_ control particular bits that
matter, even if your language runs on a VM.

I don't see why arbitrary pointer operations are necessary anymore for memory
management and the other things. I think this is something left over from the
days when we had to squeeze every iota of performance out of machines. I
suspect that entire systems could be built with references and almost no
pointer arithmetic, and that we're simply stuck in the way we've always done
things.

So what if we give up 20 or 30% of the CPU to do this? Pretty soon, we'll be
trying to figure out how to keep 8 cores busy on a typical desktop. How about
we use some of this to allow greater abstraction in the OS kernel and device
drivers?

~~~
gloob
_I don't see why arbitrary pointer operations are necessary anymore for memory
management and the other things. I think this is something left over from the
days when we had to squeeze every iota of performance out of machines._

Squeezing out performance is pretty much the job description of system
programmers. Can you give a compelling reason to change that?

 _Pretty soon, we'll be trying to figure out how to keep 8 cores busy on a
typical desktop._

No, we won't. Software becomes twice as slow every two years. Things will stay
pretty much the same as they've always been.

~~~
stcredzero
_Squeezing out performance is pretty much the job description of system
programmers. Can you give a compelling reason to change that?_

Achieving a higher degree of abstraction, more straightforward availability of
system resources to programmers, higher levels of code reuse.

BeOS/Haiku already achieves this with C++. I think we can improve on this with
something like Go.

~~~
gloob
_Achieving a higher degree of abstraction, more straightforward availability
of system resources to programmers, higher levels of code reuse._

Present-day system programmers seem to be able to build decent enough
operating systems and the like at the level of abstraction C provides, and I
suspect that most would consider straightforward _management_ of system
resources to be higher priority than straightforward _availability_ of them.

I will concede the possibility that some unambiguously-better system could be
written in a higher-level language. However, until evidence demonstrates that
it actually can be done, that remains _just a possibility_ , and one with very
real and significant costs. Those costs are not, in the view of many system
programmers, worth it.

~~~
stcredzero
_I will concede the possibility that some unambiguously-better system could be
written in a higher-level language. However, until evidence demonstrates that
it actually can be done, that remains just a possibility_

Already happened: Symbolics Lisp Machines. (Modulo a few decades of
programming practice not available to inform the Lisp Machines.)

I suspect that Go could get us there. Interfaces would allow for a higher
degree of abstraction. The language would offer much cleaner concurrency. All
the memory management cruft would be gone. In such an environment, many things
that are now esoteric would become the realm of ordinary programming. I think
there is much to be gained.

------
smallblacksun
The post starts with "This comment deserved some expansion." What comment? I
spent 5 minutes looking around his site and still have no idea.

------
stcredzero
First, he talks about things like numerics, then points out that it just
doesn't matter for most programmers.

"C won't go away."

Of course not. [X] won't go away, where [X] is any number of languages.

~~~
wallflower
Legacy code really is aptly named. There are COBOL and assembly routines in
production that have outlived their programmers. Even if a product (for
example Oracle AS being replaced by Bea WLS) is desupported/killed, it still
lives on if it's still in use.

~~~
humbledrone
There are plenty of software jobs out there that require writing new
components in C; I'm not sure that the same is true for COBOL. Sure, there's a
ton of legacy C code, but there's also a great deal of new C code being
developed, which makes it hard for me to see C as being "dead."

~~~
stcredzero
Note that I never say C is "dead." I say that the record shows: good languages
that are actually used don't go away.

------
mmphosis
Lisp on bare metal

