>>1
Whoever wrote that response is a fucking idiot and needs to do something that requires a little less mental power. Like working a cash register at Target.
>>4
Actually he's right for the most part. Sure a lot of that response consists of "doing <x> in C++ will actually result in more productive...", however he has his points.
And you're just butthurt that someone just named your 'hero' an idiot.
Name:
Anonymous2011-07-30 7:13
Opposition to any programming paradigms and concepts related to those paradigms which are not possible or very awkward to use in C. These include things like object-oriented design, abstraction, etc.
Bullshit. Structures cover most of what a programmer needs from OOP and C does of course support abstraction.
for(i = 0; i < strlen(line); i++)
{
...
doSomethingWith(line);
...
}
Nobody sane actually does that.
As for the quality of the code, in order to see what kind of code C leads to it's simply enough to take almost any open source C program out there and examine how it has been done. Just as an example let's take the mplayer software, which is the most popular media player in Linux. Let's examine, for example, its libavcodec/h264.c file:
This one single file has a whopping 8306 lines of code. As an example of a function, the fill_caches() function in this file is a whopping 462 lines long, and looks like this. (The few comments in that code are worth reading.) As an example of another function, the decode_mb_cavlc() function, which is 492 lines long and looks like this.
Video decoding code is always ugly, no matter the language. This is FUD.
His claim that using the STL causes "inefficient abstracted programming models" is simply not true. Using STL right causes the program to be more efficient, a lot safer and much easier to understand and maintain.
The STL is terrible as it encourages the programmer not to care about which data structure is adequate for what ey's doing.
In the vast majority of cases when a C-hacker hears the term "object-oriented" or "class", what he actually hears is "virtual functions", and his prejudiced brain immediately makes the connection "virtual functions → slow → bad", and they immediately become completely deaf to anything else. They seem to think that using classes means that you absolutely must use inheritance (not true), you must use virtual functions (not true) and that virtual functions are extremely slow (not true).
Firstly, virtual functions are very slow. If your entire programs rely on them, the performance degradation isn't negligible. Secondly, what's the point of using classes over structs if you don't use inheritance?
What SEPPLESers don't understand, is that the choice of C over SEPPLES isn't primarily a question of language, but of mentality. It is the faith in non-bloated software, the hope to disprove Wirth's law, the conviction that laziness isn't an excuse for unreasoned use of abstractions.
>>12 Firstly, virtual functions are very slow.
Welcome to 1990, where computers ran with 40MHz at most. Of course virtual functions are slow (compared to regular functions, you'll add one or two more pointers and a cache fault or two). But we've moved on, and arrived in 2011 now.
>>12
O(1) strlen is not bloat, using sizeof(size_t) space for every vector and string to store the length is not bloat, optional bound-checking is not bloat, having a well engineered standard library that helps the programmer instead of randomly fail is not bloat, having a module/package system instead is not bloat, a decent macro preprocessor is not bloat, having twelve different procedures to do the same thing because the standard didn't, doesn't and will never get them right the first, second, third, fourth, ..., time is bloat, having a shitty header files ``system'' to manage imports that only get copied inside the current file is bloat, having a context-sensitive grammar is bloat.
Most apply to C++ as well.
>>13,14
It's more an issue of needless indirection. C++ is as fast as C if you don't abuse its features. If you used the equivalent of a virtual function in C when it was needed, and not when it isn't, unlike C++ which tends to encourage its use everywhere.
[...] unlike C++ which tends to encourage its use everywhere.
Last time I checked, most books (i.e. all I have) on C++ explicitly mention that methods should only be declared virtual if the situation/architecture/God demands it.
>>25 >>26
The English word for what you're trying to say is ``better''. Be careful not to confuse it with ``worse''!
Name:
Anonymous2011-07-30 19:39
One could ironically say that knowing well C doesn't seem to help you write logical sentences in English.
...er.
Name:
FrozenVoid2011-10-26 13:23
If safety and re-usability was really the points >>1, Java would be written in Ada or some strict pascal dialect.
But no, Java is written in a mix of C++ and asm, like most of these "innovative" "safe" "purely functional" languages.
Jesus, what a stupid article. The worst part is he's completely poisoned the well; any attempts at a retort will just result in, `Lol! Seems you have C-hacker syndrome bro!'
Oh well. At least this will tarnish the author's reputation, whoever he is.
Name:
Anonymous2011-10-26 14:43
>>29
Have you ever listen to James Gosling speak about why Java was designed the way it was? Based on your moronic response, I'm willing to say no. I would give you a link to the interview, but given your limited mentality, I don't think you would actually make it beyond the second paragraph.
JESUS FUCKING CHRIST WHY DID YOU BUMP THIS
I'M RAGING SO HARD AT JUHA NIEMINEN RIGHT NOW
HOW CAN C++ FAGGOTS BE SO RETARDED
On a more serious note, picking at h264.c is quite funny. The only h.264 decoder I know written in C++ is Microsoft's, and it's about twice as slow as libavcodec's.
That whole rant is almost as retarded as that shit Stroustrup wrote where it compared a C++ program against a C one that called realloc() in the inner loop.
Why do I even care, there's a reason all these libraries (and the kernel) are written in C, if they want to make a point they should try rewriting them in C++ and see what comes up. It'd be funny to watch to say the least.
Name:
Anonymous2011-10-26 15:59
ALL HAIL JAVA
GC is shit.
Name:
Anonymous2011-10-26 16:00
ONE WORD
NOT EVEN C IS AS FAST AS C
THREAD OVER
Name:
Anonymous2011-10-26 19:00
....
After reading the original post... I noticed 3 things.
1) The writer of the original article is some butthurt C++ fag.
2) The writer of the original article is some butthurt C++ fag that knows that linus knows his shit, and couldn't even bother posting his name, fake or otherwise to man up to his claims.
3) The vast majority of his complaints stem from actually having to know your shit in C... instead of using some library someone wrote in C++. I'm sorry, at the point you get butthurt because someone wants you to know your shit instead of copy-n-pasta... the fuck are you doing?
I have to disagree with everything in the original article. My work went from hiring C++ programmers to hiring C programmers and our productivity increased 100%. It took us a bit to deal with not having a library already made for everything you want, but the boon was getting into making your own libraries for the things you need. And becoming a better programmer.
Name:
Anonymous2011-10-26 20:50
I am programming language agnostic. I do my work in terms of the bigger picture, not based on trifling matters. ( ≖‿≖)
>>2
>I'm not saying that many such data containers made in C++ aren't a mess
and in the end it contradicts with itself
C++ is a mess, if you disagree you are a fag.
Name:
Anonymous2011-10-27 0:24
>>41
The term is blub programmer. Blub is a language that falls right in the middle of the abstractness continuum. It is not the most powerful language, but it is more powerful than Cobol or machine language.
As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.
I don't think in terms of languages, I think in terms of solving problems. If I assign a language for a project, it'll be the language that I can use to solve the problem as quickly as possible while giving acceptable performance when using the software.
>>44
Lisp is the bottom of the power continuum. When the Lisp programmer looks up, all he sees is merely weird languages with "syntax".
Name:
FrozenVoid2011-10-27 1:40
Lisp can be implemented in a couple of javascript functions, and it would be faster since arrays > lists and modern JIT compilers blow Lisp code out of water. In fact i can see some of my scripts approaching 40% speed of equivalent and optimized C code, that without(!) using Int32Array and typed variables(recent extension).
Name:
Anonymous2011-10-27 2:56
>>46
JS + JIT is not going to be faster than SBCL + type hints. (I think JIT and type hints are equivalent "advantages" here) And the guys writing Lisp compilers have it figured out, thank you very much.
But to convince your C++ poisoned mind that it's not as simple as "LOL linked lists R stoopid freshman crap not actually useful" :
let's say you implement Lisp lists as backward vectors, where the car is the last element, and the cdr is an identical array with size set to - 1 of the parent size, and cons just pushes, occasionally growing the vector by reallocating the whole thing at a new memory position. (you make it backward because idiomatic Lisp builds lisps by pushing to the front, but vectors are better at pushing to the back)
There's already a nasty performance problem here: you have to reallocate the whole array every time you cons onto something that's already the cdr of something else. For instance:
(define ngland '(n g l a n d))
(define england (cons 'e ngland))
(define angland (cons 'a ngland)) ;have to reallocate ngland because it's already got an e at the end of the array.
This isn't just some dumb example: in functional code, you pretty constantly re-use parts of data structures to build new ones, and you need to know that it's not having side effects. So the vector solution doesn't really reduce allocations, because allocations are necessary for the style. Instead, it just delays them and makes them bigger (as well as less obvious.)
Another thing this approach ruins is pointer-equality of cells. Most lisps require that lists be comparable by pointer to see if they are identical lists. If they can get reallocated, this gets complicated.
And unless you implement your arrays as not really arrays at all, like Clojure does, they kind of fall on their face at functional-style code performance-wise (as I showed above.) You need to be able to recombinate (take apart and put back together in crazy ways) them while minimizing memory allocation. That's tough with arrays. Linked lists are built for it.
Another performance issue is that cells all being the same size (typically just two pointers) is a convenient invariant to optimize around. For example, it becomes easy to write a memory manager that doesn't deallocate and rather just pushes things on a "free list." Doing so with arrays is... clumsy.
In conclusion, you have stateful brain damage. [code]
>>47
conses are not well-adapted to today's architectures. fuck your shitty lithpu
Name:
Anonymous2011-10-27 3:38
>>48 today's architectures
you mean unmanageable, needlessly stateful, unparallelizable pieces of shit? Or are you claiming that Clojure vectors and maps are a better alternative. I don't totally disagree there.
>>49
I'm all for having various containers like list/vector/dict (with possibility of giving usage/type hints). Building everything out of cons cells sounds naive and much too simplistic to be well-adapted to reality. My mantra is to give the computer just barely enough to optimize things on its own. I can't imagine the kind of optimizer that will turn an assoc list into an optimized vroom-vroom hash table, or a mere list into a vector.
As for the Clojure thing, uh, please tell me, exactly how do you figure that having immutable vectors and maps by default is a good idea?
>>49
State is inherent in the universe. Not everything is parallelizable. There's a reason all the other "interesting" architectures developed back in the early days have died out.
Name:
Anonymous2011-10-27 5:48
This one single file has a whopping 8306 lines of code. As an example of a function, the fill_caches() function in this file is a whopping 462 lines long, and looks like this. (The few comments in that code are worth reading.) As an example of another function, the decode_mb_cavlc() function, which is 492 lines long and looks like this.
I have no idea what the fuck he's trying to say here. I don't understand exactly what those functions are doing, but I can at least vaguely guess what they're for. I don't know the H.264 standard and probably neither does whoever wrote that. But someone who did would most likely understand them very well.
>>50 exactly how do you figure that having immutable vectors and maps by default is a good idea?
It makes it so you can write more things as pure functions more easily. Pure functions have so many beneficial properties that I'm not going to list them. Half of them are design benefits, the other half are performance benefits.
And Clojures maps and vectors aren't just immutable -- they're optimized for immutability.
>>60
You know, a function may do unpure things inside and still be a pure function. Forcing base containers to be immutable doesn't help that, and instead forces the programmer's hand. If you want to avoid mutating containers at all costs, then just don't do it.
>>66
temperature is vibrating independent molecules
vibrating molecules actually according to modern quantum theory aren't really the same molecule at every point in time.
>>69
Okay fucktard, let's have it. I say that as long as the container behaves nicely under higher-order functions and iterators are powerful enough and certainly not retarded, they're "functional" enough.
Name:
Anonymous2011-10-28 0:26
>>70
it's not functional if I have to think about the time dimension in cases where the time dimension doesn't matter.