Where were you when...

...you realized C is shit?

For me it was ten minutes ago, debugging an overflow involving a thrice-indirected pointer. Never again.

Where we you when...
...you realized you are shit?

>>2
in your anus

when i started using javascript for everything

You simply lack the brainpower for advanced abstract thinking, OP. It is you who are shit.

>>5
That would imply that I can't understand pointers or debug that program, but I did. It was just a waste of time.

when I finished reading a book on D

>>1
Halfway through the first page of SICP.

>>6
If you really understood pointers, you wouldn't have created the bug in the first place, and debugging would not have been necessary.

>>9
It's like you've never written a line C in your life.

>>6
well, now we know you're a three-star programmer

did you know that unioning an int and a float, then writing to the int and reading back as float is actually undefined behaviour? did you know that (x+A > 0) where A is a nonzero constant and x+A is unsigned will always be true (even on overflow), because overflow is undefined behaviour?

C is undefined shit.

thrice-indirected pointer
What the fuck are you doing?

Learn to abstraction for fuck's sake.

>>1
That gave you trouble? Seriously?

Here's a thought: DEFINE SOME GODDAMN TYPES for once in your life. It's okay to typedef a simple indirect pointer even if it seems redundant. Then the compiler will tell you when and where you fucked up.

>>11
Hah. I was always fond of that one.

>>12
Unsigned ints have defined overflow semantics. I wish they were user-defined but we can't have everything.

libsndfile (or was it libsamplerate?) has a compile-time test for the int/float punning behaviour. It swaps in its own if it doesn't like the result.

I'm okay with undefined behaviour. C isn't a big language and every problem has a solution. I don't even write C these days (except when I contrive a task that 'requires' it) but I miss it.

C leads to unsafe, buggy, verbose, leaky code. C is the #1 culprit of "never meeting the deadline" in software development. But it's super duper fast!

C considered harmful.

I've never needed to go beyond 5 indirections in one expression.

When I found out Kernighan and dmr were jews.

>>16
I've never had to go beyond two, and I've written virtual machines and compilers.

Two is fine if you have an array of pointers. Anything beyond that, you introduce a new type. If you don't you're just asking for shit unreadable buggy code.

I've never needed more than one level of pointing.
>>1,16 must be doing something wrong.
Also I realised it was shit when I took up a language with functions as first-class citizens and a macro system that didn't make me kick myself in the balls it was so bad,

Two levels of indirection is the rule of thumb. Any deeper is a tell-tale sign that you ought to refactor your code.

When I realized every C program has integer overflow problems.

>>12
It's well defined as object representation reinterpretation. Read your ABI and you'll be fine.

Well don't program complex abstract shit in C then

>>18
You won't encounter deep indirection in VMs and compilers.

Device driver code, however...

*(ccv->lt_fflk->su.bptr->lst_out.tx_rtn[mbrtxidx++]) = ...

(Taken from a recent project. I won't say more.)

>>1
When I began designing my own language, dissatisfied with C/C++.

>>24
And then Symta fell out and you felt bad about it.

When I read http://xahlee.info/UnixResource_dir/writ/language_to_hate.html and http://xahlee.info/comp/why_i_hate_C_lang.html.

>>26
there is one thing that always accompany these: $FREE$! (as in, free drugs!)
I love the pun on Stallman. It really exposes the nature of this subversive evil kike.

>>26
lol, Xah Lee...

>>26
Finally, about the C++ comment :) I think C++ is better than C (not in syntax, which is what you're talking about). C++ is better because it gives you more abstractions to solve problems. Also, it gives you the tools to avoid printf ("cout" class), to avoid bitmasks to represent boolean ("bool" type), avoid preprocessor tricks (templates instead of #defines), avoid cryptic error codes (exceptions). So yeah, C++ is better than C (even with a more complex syntax).

Yay?

>>26
>Java can be considered as a improvement of C
Is this guy serious?

>>4
fuck off javashit KIKE

http://c2.com/cgi/wiki?ThreeStarProgrammer

>>26
What an idiot.
Perhaps the best simple example to illustrate, is its invention of the format function printf. Completely
ad hoc,
So what?
inflexible,
Wrong.
cryptic syntax and semantics.
You never read the fucking manpage, did you?
and can't do arbitrary n-based number system
Because 99% of the time you print out a number it's going to be in decimal. The other 1% in hex or octal.
It can print decimal in several formats, but in a bunch of ad hoc fixed ways.
Same as above. No one cares about printing decimal numbers with their digits backwards or some other obscure shit.
many programers don't really understand what's n-based number system,
Nor does it matter.
And if you show them hex number system using decimal digits in a list, they would be wildly flabbergasted and goes “WHY would you ever want do that??”
Then how about you explain why, genius?
Instead of working on a better compiler, let's invent a short syntax on the spot!
How does a better compiler save keystrokes?
to this day, there are programers who don't understand the difference between a set of true/false formal parameters vs their internal representation, and insists that bitmask is the most efficient way to “encode” boolean parameters.
This sounds like a guy who was too stupid to understand bitmasks properly. Something a 9-year-old kid could probably understand with a bit of teaching.

What's with these idiots who think computers are some magic thing.

>>33
Xah Lee
You need know no more.

>>12
Both of those are obviously bad if you have even an inkling of how the language works.

The biggest problem with C is that its standard library is too small and the body of idiots using it is too large. It is therefore common to see basic functionality in a standing codebase that was implemented by idiots and has since become too entrenched to be removed without Herculean effort.

>>23
Mother of fuck I hate it when people do this, too.

Probably the function in question doesn't even need to have a pointer to ccv, in which case the indirection could have been performed somewhere farther up the call stack. In the unlikely case where you have some seriously fucked data structure which does necessitate access to the top-level, at least define a local to hold the value of tx_rtn so you don't have to deal with that awful shit more than once.

>>36
That project needed a severe redesign, but it wasn't something I was willing to do given that the rest of the code was like that too.

>>26
Not surprising, he's a Lisp/emacs fan. Those tend to be the ones with their "head so high in the clouds they can't see their feet", the same ones who keep propagating the myth that hardware keeps getting faster while coming up with more and more "elegant" abstraction crap to pile on in their code. It's amusing to see them complaining about why the software they use is so slow...

>>33
ad hoc,
So what?I agree, there's nothing wrong with that.

inflexible,
Wrong.You can't configure printf to pretty-print a structure you defined. Actually, GNU printf has this but it's slow as ruby.

cryptic syntax and semantics.
You never read the fucking manpage, did you?printf syntax is very different from the typical C syntax. Also, its behaviour depends on implicit argument conversion. It is clearly defined but way more complex than it should.

and can't do arbitrary n-based number system
Because 99% of the time you print out a number it's going to be in decimal. The other 1% in hex or octal.And why are they the only used bases? Precisely because printf cannot print in other bases. Circular argument.

many programers don't really understand what's n-based number system,
Nor does it matter.I think it's pretty unsettling that most programmers don't understand such basic mathematics.

And if you show them hex number system using decimal digits in a list, they would be wildly flabbergasted and goes “WHY would you ever want do that??”
Then how about you explain why, genius?I honestly don't see the point Xah Lee is trying to make here.

Instead of working on a better compiler, let's invent a short syntax on the spot!
How does a better compiler save keystrokes?A better compiler doesn't save keystrokes but a macro does. With both, you get optimisation regardless of whether you use the macro or not. That's why it's stupid to put it in the compiler.

to this day, there are programers who don't understand the difference between a set of true/false formal parameters vs their internal representation, and insists that bitmask is the most efficient way to “encode” boolean parameters.
This sounds like a guy who was too stupid to understand bitmasks properly. Something a 9-year-old kid could probably understand with a bit of teaching.What he is really trying to say is that he dislikes the use of bitmasks as substitute for proper keyword parameters.

>>37
Not surprising, he's a Lisp/emacs fan. Those tend to be the ones with their "head so high in the clouds they can't see their feet", the same ones who keep propagating the myth that hardware keeps getting faster while coming up with more and more "elegant" abstraction crap to pile on in their code. It's amusing to see them complaining about why the software they use is so slow...
That's wrong and you know it, Cudder. Bloat isn't the main cause of unresponsiveness. It is the general carelessness towards latency and user experience in favour of bandwidth. Video games input lag and network bufferbloat are excellent examples of this.

>>23
That's not what I was expecting, but it's still pretty bad. I typically write ``accessor'' macros for my structs, so obj->var becomes var(obj) and clusterfucks like that are as simple as uno(dos(tres(obj))).

ITT: people complaining about C when the actual problem is that they suck as programmers
/prog/ is considered harmful