
Real men program in C - Anon84
http://www.embedded.com/design/218600142?cid=RSSfeed_embedded_news
======
ubernostrum
There are two extreme approaches to " _Real_ programmers do X".

One approach is rooted in electrical engineering, and declares that _real_
programmers are the ones who get as close as possible to the hardware.

The other approach is rooted in mathematics, and declares that _real_
programmers are the ones who get as close as possible to formal models of
computation.

Both are narrow-minded and flat-out wrong. _Real_ programmers understand that
context is king, and that everything they will do is a trade-off decided by
some factor of the project they're working on.

~~~
cperciva
I'm a mathematician, yet I'm still part of the do-most-things-in-C camp. I
don't think this contradicts your point, though -- I find that C provides a
far more well-defined model of computation than scripting languages like perl.

I use C more because I want to know what my code is going to do than because I
want to know how it is going to do it.

~~~
redcap
As a query, have you looked into lisp at all? I've seen (through HN) examples
of stuff like derivatives expressed quite elegantly using Lisp.

Using C for maths programming sounds fun and all, but I'm sure there's got to
be a better way of doing things.

~~~
cperciva
I've tried lisp; but for one-time hacks where I'm not aiming for performance
or robustness I usually go to the extreme and use Maple.

------
jacquesm
The reason why C is so big in the embedded/realtime world is because there are
no 'layers' underneath you that can screw up the timing. Deterministic
behaviour is one of the key goals in that sphere. (and it should be in every
other but that's not economically feasible it seems).

On the web, where programmer time is expensive and most software is throw-away
(sorry, but that's the way I see it even if that is not a popular attitude
here) the equation is completely different and skewed towards scripting
languages, with 'java' (basically a safer version of C++) taking up a good
portion of the compiled segment.

Hardly anybody directly programs their web aware stuff in C.

Most entry level jobs are with companies that do web development, there you
learn how to do scripting and quick and dirty development, usually with lots
of loose ends in the final product.

When you program in C such undisciplined coding would be punished with lots of
segmentation faults and data corruption issues, and before long you'd be a
more seasoned - and more careful - programmer.

Even seasoned and careful programmers mess up though, witness the endless
stream of buffer overflow exploits.

Another great thing about C is that it is not such a moving target, once
you've learned it you're 'current' for the next decade or two or so.

The proliferation of languages and environments is quite bewildering at times.
This years hottest technology is next years garbage. In the C world things
move at a more relaxed pace and the technology you're interfacing with is
generally speaking more mature, it doesn't feel so much like a work in
progress.

~~~
cperciva
_Hardly anybody directly programs their web aware stuff in C._

I do. :-)

 _Even seasoned and careful programmers mess up though, witness the endless
stream of buffer overflow exploits._

I'd dispute that. There were lots of buffer overflow vulnerabilities five
years ago; but I can't remember seeing any buffer overflows in the past few
years which weren't either (a) written by novices, or (b) in code which was
written 5+ years ago but sufficiently obscure that nobody looked at it until
recently.

I'd say that, especially given the proliferation of automated analysis tools,
buffer overflows are pretty much a solved problem where seasoned and careful
programmers are concerned.

~~~
jacquesm
Interesting! What is it that you do in C that talks to the web ?

I'm serving up a very large amount of jpegs as image streams to a piece of
javascript and found that the only way to get enough performance was to code a
multi-threaded special purpose webserver (I call it yawwws, yet another www
server) in C. That's been going for a decade or so now, possibly if I had to
do it today I'd use some other technology.

~~~
cperciva
_What is it that you do in C that talks to the web ?_

I've written lots of client side code (a command-line pipelined HTTP client;
library code for callback-driven HTTP for the benefit of web services). On the
server side, the tarsnap website is a combination of static HTML and CGI
programs written in C.

------
kls
One point that the article fails to highlight is, while there is a great
demand for embedded programmer, that demand is concentrated in a smaller set
of companies than say web development or enterprise systems. That coupled with
a lot of the hardware companies moving more and more of their operations to
China and Eastern Europe, does not paint a rose picture for heading into the
embedded space. Unless you plan to design and market your own products. The
mobility of an embedded development career is not as good as a web or
enterprise developer and the returns (pay, benefits, security) on some
occasions tend to be less than that of other development opportunities.

------
wglb
Somehow Smalltalk did not make his list. Nor forth.

It would be a more interesting debate if there were some hard evidence of the
relative efficiency, measured in total development/maintenance/opportunity
cost comparing C with other useful languages/environments.

The discussion seems to be limited to "C is the only choice because it is
close to the metal" and "so what".

------
faal
I think the principal problem is: who the hell wants to work with embedded
systems? I'm a CS graduate student and I don't see any reason why you would
want to go in to that field. As far as I'm concerned, let the Chinese do it.

~~~
__david__
I love working with embedded systems. The nice thing is that it's usually
embedded for some reason--it's talking directly to some hardware and that
makes it interesting--motors, switches, leds, accelerometers, DACs ADCs, etc.
Quite often those are hooked up to physical things so the program you end up
with is controlling or is controlled by cool tangible things.

Then add to the mix that since embedded things are custom you generally get to
drill all the way down to the processor itself to make it boot up correctly.
When you are done you've generally got an app layer and hardware layer and a
processor interface layer and it's all code you wrote yourself (since
everything can be completely customized it's really hard to write reusable
generic code _and_ have it small and fast).

There's something really satisfying about standing back and realizing that
nearly every piece of code running on the processor is yours.

~~~
joe_bleau
Damn straight.

If the project is small enough, you might even design the hardware and write
all the code. Nowhere to hide and all the bugs (and glory) are yours.

------
noamsml
Ugh, not the "real men" argument again.

Real _programmers_ use the tool that is best to the job, rather than using one
that appeals to their bravado.

------
steveh7
"Quiche-like phrase"? I couldn't read any further.

