Criticize C.

Please, I'd like to hear what /prog/ thinks is silly about C.

It's curly

It pales in comparison to BCPL.

No modules/namespaces, crippled macro system, crappy type system (even if it were untyped it would have been better, because it would have allowed for things like standard containers as part of the standard library).

Its fukking useless when we already have k and s for those phonemes. C just klutters shit up with a superfluous grapheme.

C is just a solid tool.

>>4
Will you please develop your comment about the type system a bit further?

>>7
Either include genericity or don't even bother adding a type system.

C has something called a 'necessary problem'. Actually, it has many of them. These necessary problems will appear once you want to conceive of a language that is just a layer above assembly, which can be implemented for any architecture and other implementation-specific details. These problems can disappear with the use of abstraction which would make C no longer be C, but a different language. What can be done instead, is introduction of vague specification and semantics, flexible enough to be implementable by all.

If you're an intelligent person who wants to program, you will use a different tool than C if you can. That is, if you're writing something that requires C, then you obviously have to use C. But if what you're writing can be implemented in another language which does not have the aforementioned necessary problems, it'd be illogical to do otherwise.

Those who bash C are either too dumb to realize its importance or too smart (= busy) to realize its design goal.

(　≖‿≖)　　D
( ≖‿≖ ) 　　I
(≖‿≖　)　　C
(‿≖   ) 　　K
(≖　　　) 　　
(　 　　 ) 　　T
(　 　　 ) 　　O
(　　　≖) 　　W
( 　≖‿) 　　E
(　≖‿≖)　　R

>>7
Programming languages either need strict type checking (like Haskell) that catch errors before run-time, or they need no types (like Python) so you don't have to deal the type-related crap when it won't help you anyway.

>>9
Forth is (well, it was until 83) more vaguely specified, and has better abstraction capabilities. C's importance is merely circunstantial.

>>7
And when I say untyped, I mean like in Assembly.

>>11
Python
no types
Oh really?

C is the Language of the Real Programmer. No matter if those half programmers don't even know how to write directly good applications. If you waste your time with a debugger you actually missed the point.

Obviously you can be far more quick in your development process by using higher lever languages such as Python... or you may get more abstraction just adding a "++" to your "C", but this doesn't bring down the importance of being a good C programmer.

When you know C good enough, you automatically can understand what should and what shouldn't be done in high level languages.

>>12
Importance is always circumstantial.

>>16
Yes, but, as I said, C's is merely circumstantial.

no types (like Python)
http://dis.4chan.org/read/prog/1245822149/10

>>12
IHBT.

>>9
I disagree to some things you said. For example, there is no point in using loose guarantees regarding the sizes of integer types instead of defining their exact sizes/ranges.

I wish I had a guarantee about the exact size of an int whenever I use one, instead of just knowing that it is ``required to be at least 16 bits long''.

And what if the int in question is actually 64 bits wide? I may either write non-portable code that relies on this, or portable code that ignores it and wastes lots of memory.

If you adhere to a strict interpretation of the C standard, the high-order bits of any integer type that is assigned a size larger than that which the standard requires are mostly unusable (unless you use lots of undesirable #ifs and #defines). There is no guarantee that this high-order portion even exists, and thus there's no way of knowing the point up to which I may use that int.

Sorry, I had to get this off my chest. Also, cocks.

>>20
What about <inttypes.h>

>>21
s/$/\?/

>>21
You mean <stdint.h>. But my point was not about how to get those well-defined types in C, but why loose definitions leave room for ambiguity and inefficiency.

but i like C :(

>>19
Yes, by Dennis Ritchie.

>>20

For example, there is no point in using loose guarantees regarding the sizes of integer types instead of defining their exact sizes/ranges.

There is, portability. Considering C is the layer on top of assembly which is supposed to be portable, this is within the goals and scope of C.

I wish I had a guarantee about the exact size of an int whenever I use one, instead of just knowing that it is ``required to be at least 16 bits long''.

What would you do then?

And what if the int in question is actually 64 bits wide? I may either write non-portable code that relies on this, or portable code that ignores it and wastes lots of memory.

In what way do you consider memory to be wasted? When it can't be done in standard C, then you can only write a wrapper for all the available solutions in all other languages, but not C. This will make your solution - and thus code - as portable as the algorithm and language selected for the task.

If you adhere to a strict interpretation of the C standard, the high-order bits of any integer type that is assigned a size larger than that which the standard requires are mostly unusable (unless you use lots of undesirable #ifs and #defines)

That is wrong. A strict interprentation of the standard would tell you that you don't know which bits are value bits and which are padding (or other types of bits, such as as a sign bit), in other words the C programmer representation agnostic of his integers -- lest he touches the wrong bit. (the standard does specify twos complement for some integers, and representation of floats if a cetrain macro is defined, et&) Also, (int)LONG_INT is imp-specific behavior, while int i = LONG_INT; is undefined behavior. If you were talking about signed integer assignment, you're plain wrong, because the standard says it's undefined.On the other hand, unsigned integers have defined behavior on such cases, so you can't possibly refer to them.

It is simply the case that I know more than you on programming and that you should simply learn more instead of wasting your (and our) time here.

>>20
With LONG_INT I meant LONG_MAX (though LONG_MIN is incidentally also acceptable as a replacement).

>>26
loose guarantees
You're mom's a loose guarantee

>>26
IHBT. Or perhaps you just didn't read what I wrote. But thanks for reinforcing my argument by saying that ``the C programmer is agnostic of the representation of his integers'' and that the standard is indeed limiting and awkward.

Also, I would shove my fixed-size int up your EXPERT PROGRAMMER ass, even if the standard says that this leads to undefined behavior. Additionally, I'd be able to know in beforehand the greatest value it may hold and thus be able to use it efficiently.

The rest of your post is nonsense.

perhaps you just didn't read what I wrote.
I quoted selectively and responded to each quotation within context. You, except ignoring completely my questions, responded in a manner which shows you do not want to simplify things in a discussion, but rather, complicate them further., and now you must excuse me because there's nothing more to be told unless you find yourself able to reply seriously to >>26

>>26
Also, notice that I wrote ``the high-order bits of any integer type that is assigned [by the compiler] a size larger than that which the standard requires are mostly unusable''.

This has nothing to do with the bullshit you wrote about assigning a LONG_MAX to an int. I was talking about what sizes are assigned to integer types by the compiler, and not about the semantics of the C operation known as ``assignment''.

>>30
That's fine to me, Your Highness the Expert Programmer. Thou shalt not waste thy time and supposedly endless expertise any longer here.

C isn't a just layer above assembly. HLA is.
C has enough abstract concepts/libs(and countless ways to abstractize to any level of operation from disk utlitities to XML parsers) to conceal the hardware interface thats its productivity is like 10x assembler with almost the speed of asm(with full optimizations of course). Thats why Lunix is written is C.



___________________________________________
http://xs135.xs.to/xs135/09042/av922.jpg
orbis terrarum delenda est

C isn't a just layer above assembly.
It is.

C has enough abstract concepts/libs
Which abstract concepts does C have? Abstract libraries? Do you understand what it means for a language to be a layer above assembly? If you did, you wouldn't be talking about abstract libraries; you can write libraries you'd call 'abstract' in assembly.

to conceal the hardware interface thats its productivity is like 10x assembler with almost the speed of asm
The compilation end result of a C compiler of today is nowhere near optimal. As for C's productivity, where did you hear this magic number 10x? Or do you just pull crap out of your ass? Shit-smudging board-lurking pathetic funky junky penisdenis faggotree motherfucker, damned is the stupidity in every of your posts.

"Which abstract concepts does C have" Keywords which translates to multiple&variable instructions in asm.
"Abstract libraries" heard of headers and libraries?
"Do you understand what it means for a language to be a layer above assembly" HLA and Linoleum.
"you can write libraries you'd call 'abstract' in assembly."  They are shortcuts for loading multiple instructions.
"The compilation end result of a C compiler of today is nowhere near optimal" GCC -O3
"magic number 10x" You have to writes every instruction by hand. C obviously translates to >10 instructions per word.



_____________________________________
http://xs135.xs.to/xs135/09042/av922.jpg
orbis terrarum delenda est

>>34
If you're on /prog/ and you still get trolled by FV, you're doing it wrong.

In this day an age how do ppl  still see his posts

>>37 They have eyes, those 'ppl'

____________________________________________
http://xs135.xs.to/xs135/09042/av922.jpg
orbis terrarum delenda est

>>34
Shit-smudging board-lurking pathetic funky junky penisdenis faggotree motherfucker, damned is the stupidity in every of your posts.

Or, in other words, FrozenVoid.
Get the fuck out of there, you namefag bastard!

// ==UserScript==
// @name           fix prog
// @description    fixes all of FrozenVoid!FrOzEn2BUo's posts on /prog/
// @namespace      http://dis.4chan.org/prog/
// @include        http://dis.4chan.org/*;
// @version        1.2
// ==/UserScript==

(function(){
 var posts = [];
 var myclass = new RegExp('\\bpost\\b');
 var divs = document.getElementsByTagName('div')
 for(var i = 0; i < divs.length; ++i){
  var classes = divs[i].className;
  if(myclass.test(classes)) posts.push(divs[i]);
 }
 for(var i = 0; i < posts.length; ++i){
  var postername = posts[i].getElementsByTagName('span')[3];
  var postertrip = posts[i].getElementsByTagName('span')[4];
  //if(/^!FrOzEn2BUo/.test(postertrip.innerHTML))
  if(/^FrozenVoid$/.test(postername.innerHTML))
   posts[i].parentNode.removeChild(posts[i]);
 }
})();