C is the way

http://c.learncodethehardway.org/book/learn-c-the-hard-wayli3.html#x4-3000
I'm going to guess that you come from a language for weaklings 1. One of those "usable" languages that lets you get away with sloppy thinking and half-assed hackery like Python or Ruby. Or, maybe you use a language like Lisp that pretends the computer is some purely functional fantasy land with padded walls for little babies. Maybe you've learned Prolog and you think the entire world should just be a database that you walk around in looking for clues. Even worse, I'm betting you've been using an IDE, so your brain is riddled with memory holes and you can't even type out an entire function's name without hitting CTRL-SPACE every 3 characters you type.
Zed Shawn got it right.

C++ is good though.

Lisp
GC is shit.

>>1
Almost all Lisps are impurely functional.

I enjoy using C++, Occasionally I work with C# and it's nice to have the  IDE give me all the function names as it saves me having to look them up (ie if i'm working with some class or library I've not used before I can pick it up and run with it right away).

Codding with an IDE from time to time is like using spell checker on a phone, it only works if you know what you're looking for.

But maybe that's just me, I spend most of my time in C++.

>>4
Almost all Lisps are purely infunctional.

amirite?

>>1
Read the footnote of the page

C is the way
Trolling is shit.

Learn x The Hard Way
WTF is with this stupid fad?

The purpose of C is to act as a "herding mechanism" that keeps mediocre programmers in mediocre organizations from "doing too much damage". This is at the expense of slowing down productive programmers who know how to use more powerful and more compact techniques.

It doesn't give you the freedom and extendability Forth and Lisp does. Instead you have hard coded, "nice-looking" statements for the most common operations. You've got if, while, for, goto, and return. You must use these, and nothing else.

This makes it easier to learn for non-programmers, at the cost of the programmer's freedom and power.

>>9
More like learn it the overly verbose stupid way

>>1
>http://c.learncodethehardway.org
Very bland, beginner-level, infused with Sepples-level code.2/10
struct Person *Person_create(char *name, int age, int height, int weight)
14  {
15      struct Person *who = malloc(sizeof(struct Person));
16      assert(who != NULL);
17 
18      who->name = strdup(name);
19      who->age = age;
20      who->height = height;
21      who->weight = weight;
22 
23      return who;
24  }

>>12
It hurts to live.

>>13
Do you have phimosis?

!= NULL
I cringe every time I see this. (Or comparisons with 0.)

This shit is terrible. If you want to learn C the hard way, read C99.

They claim C is not a language for weaklings, but then one of the first things they do (4) is tell you to use Valgrind to ``report on all of the horrible mistakes you made''. Relying on Valgrind or other debugging tools is the hallmark of a weak programmer ( http://lwn.net/2000/0914/a/lt-debugger.php3 ).

Arrays and pointers are confused in (10).

(13) has a bad case of specifying things by trying to explain how a compiler works. Not only is it complete bullshit, it also raises more questions than it answers. http://existentialtype.wordpress.com/2011/04/02/functions-are-values/

(16) has the same problem as (13).

(17) introduces malloc. For some reason they use assert to handle out-of-memory condition, even though that's retarded. The return value of strdup is not checked.

(18) introduces a die function that relies on errno being zero if there was no error, which is wrong. Dumping memory to disk is terrible! rewind and fclose are not checked for errors. (18.2) is full of complete lies again. Ask Zhivago.

As an aside, http://benpfaff.org/writings/clc/malloc-sizeof.html

In (19), line 79 is unnecessary.

In (20), _object_h, _ and _ex19_h are reserved identifiers in file scope because they start with an underscore. strdup is not checked, leading to undefined behaviour when the description is printed. Curiously, it is recognized the description can be NULL in Object_destroy. This may just be ``defensive coding'', which is unnecessary because free will ignore NULL. process_input may have buffering problems, asking for input before the prompt is flushed. Assuming the second character is ENTER is sloppy. Line 163 of ex19.c is useless. I find typedefing structs distasteful.

In (21), __dbg_h__ is not a valid identifier. The return value of fclose is not checked.

In (22), the descriptions of the integer types are shit. register does not force anything.

(23),(24)-(54) are almost empty. (55) is a worthless, stupid and half-finished rant.

This may be a little too harsh since it's just a public draft.

>>12
ooc.lang.Person

>>15
Using NULL for pointers is always more readable than an implicit 0.

>>1
He's just being funny. He was a Ruby hacker for years, wrote a book on Python and got his reputation for being edgy.

>>15
That's because you're an idiot. NULL and '\0' aren't defined by default for nothing.

what >>16 said

>>18,20
0 IS the null pointer even though its bit representation is not all 0s (although it is on any sane architecture). The compiler takes care of that.

It's shorter to type and read and you would understand unless you're some Java fool.