
Die, You Gravy Sucking Pig Dog - bdfh42
http://www.codinghorror.com/blog/archives/001211.html
======
lbrandy
> "In the C programming language, you're regularly forced to deal with the
> painful, dangerous concepts of pointers and explicit memory allocation. "

> "I'd wager the majority of programmers alive today have never once worried
> about malloc(). I call this progress..."

Anger. Must... resist... anger.

I've come to believe that Jeff Atwood is on a personal mission sent by God
himself to piss me off.

Just remember, Jeff: every time you fire up that pretty C# code of yours, and
make all your little variables through your ORM, letting the garbage collector
clean up the mess you've made and then proceed to pump out those cute little
web pages through your cute little templating language, to be sent off to some
other computer through some magic wire to some magic browser to be rendered...
that thousands and thousands of programmers (who, it should be noted, are
almost all still alive, today) worrying about "dangerous" and "painful"
concepts like pointers have slaved to make your silly little ORM, your
database, your templating language, your network stack, your web browser, your
web server, and your operating system.

As I've said before, some of us are in the trenches worrying about all the
"dangerous" stuff, like pointers. The primary difference between you and I,
though, is that I actually know you exist. I don't believe that at some point
in the mid 80's, a network stack and a file system (each created in the
"before time") really really loved each other and out popped a web server.

~~~
statictype
I know its somewhat trendy to pick on Jeff Atwood, but I don't really know
what you're getting angry about.

He never said that malloc and free are irrelevant. And manual memory
management is dangerous and painful. Anyone who's written a modicum of C would
agree with that.

That a majority of programmers today don't have to worry about it is, in fact,
progress.

~~~
DarkShikari
_Anyone who's written a modicum of C would agree with that._

I've written tens of thousands of lines of C and maintain a codebase of over
50KLOC. I also am a somewhat less active maintainer on another project with
almost 400KLOC. And I would strongly disagree with that, so you shouldn't make
wide generalizations like "anyone."

I have devoted probably less than an hour of my time _out of over a year of
development on this codebase_ to memory management. I have never understood
why people think it is so hard to call free() a couple times when your program
shuts down.

At least in my experience, if you're finding memory management to be "hard",
your program is structured in a bad way to begin with. Your program shouldn't
be covered in mallocs and frees.

~~~
statictype
>I have devoted probably less than an hour of my time out of over a year of
development on this codebase to memory management. I have never understood why
people think it is so hard to call free() a couple times
when<http://news.ycombinator.com/item?id=435267> your program shuts down.

I'm completely and utterly unable to comprehend how a code-base of the size
you mentioned could have its memory managed by a couple of free() calls when
your program shuts down. (And if you're program is shutting down, why would
you even need to call free() at all? )

Are you using some kind of garbage collector tacked on top of C?

Edit: Can you elaborate on the nature of these programs? Because if you're
building any sort of non-trivial data structures in your code at all, then you
almost certainly need allocations and deallocations

~~~
DarkShikari
We have to call free when the program shuts down because the program is
available through a library interface, and so it can be called as a linked
library in addition to being used as a standalone program. If it wasn't for
that, we wouldn't even need free.

The program is structured so that based on the parameters it is given, we know
exactly what needs to be allocated: how many video frames need to be malloced
and so forth. This is all done in the initialization functions and after the
program has started, it _never needs to grab any memory ever again_. This is
not a case of "we're allocating the max we need and distributing it later"--
it's a case of _since we know how the program works, we know what exactly what
it will need to do and how many frames it will do it to simultaneously_.

There are only four things in the entire program that are malloced:

1\. Video frame objects (big structs with tons of pointers to data that goes
along with a video frame). A new_frame function exists to malloc and return a
video frame. This makes it easy to check mallocs. We know exactly how many
frames will be needed on startup. These frames make up the vast majority of
memory usage of the program.

2\. One data struct for each thread. Each thread has its own local struct that
it passes around containing data currently being worked on.

3\. A scratch buffer, per thread. This is a small malloced buffer used for a
few calculations that require variable-size buffers, usually depending on
video frame width (i.e. something known at initialization, but not known at
compile-time).

4\. Bitstream output buffers for each thread. In the extremely rare case that
a bitstream exceeds the initial allocated value, this is realloced on demand.

Every single one of these can be free'd trivially at the end of runtime.

~~~
statictype
Interesting. Thanks for the details.

I'm guessing this is a non-interactive library\application which takes input
at start-up, does work and then exits?

(because otherwise, I assume it would be impossible to reason about how much
memory is required)

~~~
DarkShikari
The program is x264 and it can be interactive to some extent--it has a
"reconfig" function that allows you to reconfigure the parameters on the fly,
though it has some limitations as to what you can adjust and what you cannot.

One potential purpose of this is a "speed control" feature where you adjust
settings on the fly to ensure realtime operation, such as for a broadcast
encoding server (my company does this).

------
barbie17
This is perhaps one of the most astonishingly vacuous article I have ever read
in my entire life. What was is about, exactly? A funny function name? Not to
mention that 70% of it is quotes from other people. Pure link bait.

------
ejs
Funny, after I moved from programming assembly to mostly C (on
microcontrollers) I thought pointers and memory allocation were the neatest
things. I guess it all depends on your perspective, write a few thousand lines
of assembly on a chip with 256 bytes of ram and pointers seem quite magical.

I also think Jeff doesn't realize just how many people out there still write
code for small 8 and 16 bit processors, much of which is in C. Although I
would not really recommend using malloc in most of those cases the "dangerous
concepts of pointers" are still very alive and well.

------
bdfh42
With regard to:

sqlConnection.Close(); sqlConnection.Dispose(); sqlConnection = null;

The irony is that the .NET Framework and it's compilers are very good at
optimisation and will almost certainly make the object available for garbage
collection at the first opportunity - with a good chance that the second two
statements would not even make it into the assembly.

~~~
statictype
I haven't dealt with this stuff in some time, but I recall that those last two
statements are actually needed. I think it was a work-around for a bug\design-
flaw in the earlier .NET garbage collector.

That last bit on explicitly assigning to null was really weird but in some
cases, necessary.

------
DanielBMarkham
Okay! Okay!

It's killing me.

"Gravy Sucking" should be "Gravy-Sucking"

There.

I feel better now.

------
okeumeni
This programmer shows a lot of temper; I won’t hire him.

I once worked with a guy from Ukraine who use to swear in his native language
at office, trust me it’s not nice. It’s disruptive and ultimately non
productive for the programmer and others around.

------
Tichy
I like to use the template pattern for that sql connection problem.

------
lucraft
I like Gravy.

~~~
diN0bot
I like Dog.

------
simplegeek
Let's just not say if he's right or wrong. But I don't think he went to a
decent CS school, did he?

~~~
simplegeek
I mean I didn't mean any disrespect nor do I've any problems with this
success. But at times he's just plain wrong. I mean others have said enough.

