

In Defense of C - gtani
http://girtby.net/archives/2008/8/23/in-defence-of-c

======
gamble
"There are no minimum requirements."

Anyone sitting down to write an article on what a programmer needs to know
should take that sentence as their mantra.

C is definitely one of, if not the most important languages a well-rounded
programmer should know. But realistically, there are millions of programmers
who get along perfectly well without knowing it. In unusual cases like those
described in this article, they'll get around their ignorance of C by leaning
on a forum, guru, or a third-party library. In fact, the number of programmers
who do know C is (vastly) smaller the number who don't.

Lest anyone think I'm celebrating ignorance, that's not the point. I come at
programming from an engineering perspective, and C rates highly in my
pantheon. The point is that for any requirement someone can come up with for a
'good' programmer, a pretty good chunk of the community has gotten along just
fine without knowing it.

Ultimately this debate is less a question of what someone _needs_ to know, and
more about how circumscribed a professional life they're comfortable with.

------
d0mine
In short:

 _all the major operating systems, all the high-level language runtimes, all
the databases, and all major productivity applications are written in C_

 _Live in high-level language land for your entire career?_

 _but sooner or later a crack is going to open up and the abstraction is going
to leak._

 _And on that day, boy will you wish you knew C._

</quote>

------
cbetz
Wait, why does C need defending?

~~~
etal
Apparently because Jeff Atwood complains about it occasionally. Also, because
it's the only popular language that doesn't consider "magic" a good thing.

~~~
stcredzero
You've never been in a self congratulatory C shop where "macro wizardry" is
considered a good thing. (Wasn't there some early widget toolkit for X windows
that tried to implement Objects using C macros?)

On the other end of the spectrum, I have also worked on a large client-server
app at a company whose workforce was taken from the local community college
with courses in programming taught in C. Every time these programmers wanted a
new collection, they _rewrote_ Linked List. No exaggeration. There were many
hundreds of independent implementation of Linked List. I was looking over a
shoulder of a programmer, who was showing me that this was what I should do,
and watched her showing me how to _reimplement linked list_. One client even
got fed up and tried to introduce a library called "Super Link." Programmers
in this shop ignored it and went on reimplementing Linked List. Management at
the company determined that "Super Link" would just be particular to that
client. (No one understood passing function pointers.)

These programmers thought the C compiler was some kind of "magic." Every time
I tried to talk about the call stack, they would give me blank stares.

~~~
etal
Pretty good. C is unmagical, but that doesn't keep developers from adding
their own special magic...

Reading Guy Steele's late-1990s defenses of Java, and observing how C and C++
actually are used in industry -- yeah, I actually am happy that Sun managed to
bring Joe Application Programmer about halfway to Lisp. In general, magic
features like built-in garbage collection and all the basic collections in the
standard library are a Good Thing. The main problem I see is that C is
designed for systems programming, where everything really should be explicit,
while most of the code that actually gets written belongs at a much higher
abstraction level. Still, even in higher-level languages there are edge cases
that make much more sense if you understand how the situation looks from the
level of C -- for example, performance profiles.

(At the self-deprecating C shop where I worked last, I was the one deleting
macros, wrapping lower-level code with Swig, and pushing Python and shell
scripts for new code. We used glib, too -- which removes 10% of the pain while
demonstrating ever more clearly that C should not be the primary language for
big userland applications.)

------
Zak
My Common Lisp environment is not built on top of C. Knowing C will not help
me track down bugs in it, and shelling out to a C program will rarely produce
more than a marginal speed increase.

That's not to say knowing C isn't a good idea, in part for the other reasons
the author listed and in part because C and Lisp are near, if not at the ends
of the high/low level language spectrum. Understanding the machine provides
valuable insight for programmers, even if they never actually use C in real
programs.

~~~
mechanical_fish
_My Common Lisp environment is not built on top of C._

What _is_ it built on top of? Your environment is not based on Unix, Mac OS,
or Windows? I thought Lisp Machines were part of history.

~~~
silentbicycle
Lisp, probably.

You write a fairly straightforward* Lisp interpreter in some existing language
(often C, though ML seems like a good fit as well), use that to execute a Lisp
compiler _written in Lisp_ on itself, and presto, you have Lisp all the way
down to the machine code. The non-Lisp scaffolding is only a temporary support
for the initial construction. It may be built _with_ C, but then the C
vanishes. It isn't _on top of_ it in any sense.

See also: <http://en.wikipedia.org/wiki/Self-hosting> \-- Compilers for
Haskell, Smalltalk, Factor, C, etc. have been done this way, too. There's
nothing specific to Lisp about the process. Consider: What are C compilers
written in?

* I.E., don't bother optimizing it much if it's only run to build the compiler. Making it simple for easy porting is more important than speed.

~~~
Zak
His point is that I'm most likely running Lisp on top of some operating system
that's written in C rather than using a Lisp-based OS that runs directly on
the hardware. Movitz is a project to enable running Lisp on x86 PCs so that a
Lisp-based OS can be developed, but I'm not using it.

mechanical_fish is correct that I'm running CL on Linux, which is written in
C. If I have a problem that requires me to gain some deeper understanding of
Linux than I can get from the documentation, I will have to read C.

All of that said, I think this isn't an especially compelling argument for
learning C. The understanding it brings of how computers work is more valuable
for most programmers, I think.

------
AndyKelley
I'm not sure what this means, but picking up C was like nothing to me. I grew
up on Visual Basic 6 and Perl, and finally I hit puberty and decided to learn
C. But it was like nothing. I found the the syntax familiar, the language
powerful, and even having more features than Visual Basic. The modularity
makes so much sense, allocating and deallocating memory has a strange
familiarity, and when you get nice data structures and pointers, the
algorithms than unveil themselves are simply beautiful. Operating System API
as simple C function calls feels wonderful.

The only thing that tripped me up for a while was pointer syntax, but that
wasn't a problem after I realized that * simply means "dereference". Segfaults
suck, but then again you can just printf() something right before and after a
suspicious block to see where the problem lies.

Finally, what I'm getting at here, is that I'm not sure if I can say I "know
C" or not. I've written several apps, including a RPG/style game engine and a
chess AI. But essentially, there was _no_ learning curve. It just makes it
really hard to judge my skill level.

Also, I would like to note that C is a great programming language. Did I
mention I like C?

I apologize for that incoherent post. But hey, logic is for programming.

------
nostrademons
Counterpoint: <http://bramcohen.livejournal.com/4563.html>

~~~
pmorici
No it isn't. If anything it is a complementary point. The article advocating C
says you should know about it should you ever need to use it. Cohen's article
says nothing to refute that and in fact acknowledges there are instances when
C is a good idea.

~~~
watmough
"These are decisions for which there's no rational justification whatsoever.
For example, writing a non-speed-critical program (which is most of them) in C
or C++. A few years ago you could justify that because the other languages
didn't have such extensive libraries, but today it's ludicrous."

I think this is the text that was intended to be cited.

Thanks to the GP for posting that article, it's well worth reading for any and
all of Bram Cohen's insights.

~~~
silentbicycle
I think you're fiercely agreeing: Having a very sharp scalpel is great _when
you need it_ , just know that it's almost never the best tool to start with.

------
Allocator2008
main(int argc*, char argv[]) { printf ("true that\n"); }

~~~
qwph
I think you meant:

    
    
      #include <stdlib.h>
      #include <stdio.h>
    
      int main()
      {
          printf("true that\n");
          return EXIT_SUCCESS;
      }

