(untitled)

Why do people hate C? I've never seen a good programmer who disliked it. are people just to used to being spoon fed by cpp?

>spoon fed by cpp I've always thought that cpp was a lot harder to get good at then c, and I don't think that opinion is particularly controversial. Frankly I use c because it can do a lot of the same stuff as cpp but its easier to write. As for why people hate it... idk I haven't met that many people that hate it. Some think its too archaic to be useful for anything that isn't super low level (which I disagree with) but the only people I've seen actually soykaf on C are either hard core CS theory nerds, rust zealots, or haven't ever really used it and just assume its hard because it doesn't have vectors. Also, we already have a C thread with the exact same OP image.

>>19901 basically this through and through. c is my favorite language, it's simple and easy to write. i've never met anyone irl who hates c, but i have met people who don't get how it's simple. i think more than anything c is misunderstood, and the reasons for that reach farther than what i really wana post right now.

>>19899 C makes integer division and integer overflow undefined behavior despite hardware often supporting cheap ways to check for these. There used to be computers that had an interrupt on integer overflow. On modern x86-64, DIV *still* throws an interrupt if the divisor register is zero. IIRC, in the latest C standard integer overflow is no longer undefined, it silently overflows. C exposes the stack and heap to abuse. A bad C program can easily smash the stack or break the heap. Integer overflow contributes to these problems. That's why there's calloc(nmemb, size)[code] instead of [code]calloc(nmemb * size) . It is a pain to do anything in C. In response, nobody checks if their arithmetic could overflow. String code is particularly frustrating. There's strcat and strcpy . The stricter strncat and strncpy are touted as an improvement, but are still awful. The code went from arbitrary memory overwrite to silent data truncation. GNU utilities avoid all four of these functions. >Avoid arbitrary limits on the length or number of any data structure, including file names, lines, files, and symbols, by allocating all data structures dynamically. In most Unix utilities, “long lines are silently truncated”. This is not acceptable in a GNU utility. https://www.gnu.org/prep/standards/standards.html#Semantics I loved the last time I got to program in C. I just wrote a bunch of data structures that should have already been implemented and should support more than one element type. I had fun, but it was a massive waste of time.

>>19911 Many people who write C have to write their own data structures. pretty much none exist by default. i too had lots of fun even writing a simple binary tree in C, but it is hardly practical in today's world. but it's fun in way.

>>19899 The reasons I can imagine: They are lazy. Tooling like compilers, build systems, testing, package managers used to suck and still mostly does. It's easy to write dangerously but very difficult and tedious to write well. There is little or no consistent guidance on how to write good C. For every "write C this way" there are 100 people saying that's the wrong way but not providing guidance as to the "right" way. C lacked decent standards and behaviour for a long time. People were taught C a decade or more ago during the "bad old days" in college by uninspiring teachers who would make anyone hate anything. Most of all though, many developers these days are simply not fascinated with low-level systems behaviour like what's in what registers when or on the stack or when a program can reuse memory or needs to reallocate it. You need to have a passion for hardware and assembly (and disassembly) to want to write good C. I don't know Cpp but I work with C every day and love it. I try not to be a language snob. I have also written useful stuff in bash, PHP, JavaScript, Python, Lua, and Rust. Some of those things have seen commercial use. Rust is shaping up to be "the next C" which Cpp tried to be but never really achieved and which Go didn't really aim for but people think it did.

>>19914 >Rust is shaping up to be "the next C" which Cpp tried to be but never really achieved and which Go didn't really aim for but people think it did. I think it's more that many people regard Go as being safer for certain types of projects that were traditionally written in C (such as server daemons, particularly multithreaded ones) rather than Go being a replacement for C itself.

>>19899 >are people just to used to being spoon fed by cpp? Being spoonfed is great. Manually coding in data structures is un-great. In fact, it is bad, wouldn't recommend.

>>19929 There's this extremly pervasive meme that you need to do everything the hard way in order to understand something, which simply isn't the case most of the time, especially not in programming.

>>19919 Yeah that seems about right. I'm not sure I agree with rust being the next C either. Seems to me like rust makes a better replacement for projects that are usually written in C++ rather than C. Web browsers, complicated application software, etc. Its not really "the next C++" because they're nothing alike but people seem to be moving away from object oriented programming and rust offers a pretty compelling paradigm to use instead. As an aside, rust has been an incredibly difficult language for me to learn. I can usually pick up the basics of a new language within a few hours/days and the rest is just practice and familiarity so that I don't have to reference the documentation all the time. I've spent hours playing around with rust and reading tutorials and books but it has yet to click for me. Not the fault of the language but maybe kind of explains why it hasn't been replacing C++ more quickly.

>>19899 People who lack experience in the language to understand how trivially easy it is.

>>19899 C has very limited functionality, often touted as a benefit but can be a negative for rapid development When you want to be able to predict assembly instructions, memory locations, or talk with hardware, choose C. If you care about performance, C++. All else, pick from java, python, JS, C#. Use it for the rest of your life. Swear it's the best language for doing X, even though you never tried the other languages. And that's it

I could've started this thread myself. I understand (anyone does) that a language has a domain at which it excels, and many languages are better for other things. I also realize that choice of language is out of personal preference or practical use. Yet seldom do I see a language where people would just poke in and give a list of arguments (always the same handful thereof, by the way) as to why it is bad, and repeating them every chance they get. Sure, the arguments are somewhat valid. Yet it seems like people are campaigning against C. I don't like js, but I don't go around the internet bitterly complaining about it. And many other arguments are just misconceptions from ANSI C. Either way, all I care is C is fun to use, and I use it when I want to use something fun. Sometimes I use perl, sometimes scheme. Granted, I do it for fun. Perhaps these people are SRS programmers who have to use C because their boss told them to. Honestly my use of C is often for a very simple reason: it's simple to use. Call me a fool. I know the language and the environment is readily available without much fuss. I can use it even in plan9 (so far my favorite environment by far), I don't need to set up a specific environment, deal with library bindings (everything is made for C first, everything else usually on top), and I'm not bound to spend time reading a book on one of a bunch of languages that all look somewhat similar, have some somewhat minor differences, and which will probably not outlive C. It's just easier for me to start wroting C on the spot whenever I'm faced with an interesting problem. In the end, if I ever get to have a programming job, I should be able to learn the language with relative ease, meanwhile, just let me code. Comfort zone? Perhaps. I am also interested in haskell, coq, prolog, APL, maybe in my own time and for fun, not because of some gospel that the enlightened have had the benevolence to shine down on me.

>>19901 Honestly the exact opposite imo, C++ seems like an easier C in my eyes.

>>20068 C++ has significantly more complexity (and a worse standard library) than C. C++ is an ugly toolbox of tools that were created in the 90s mixed with newer shinier tools that do the same exact thing. It requires the user to know what to use and what not to use. > I understand (anyone does) that a language has a domain at which it excels And if you don't know it has interoperability with basically everything. Java? JNI. Go? cgo. Python? Cpython. The list goes on. It's also unrivaled in embedded applications. > C because their boss told them to. This type of thinking shows a lack of experience.

>>20095 >And if you don't know it has interoperability with basically everything. People tout this as a strength of C's, even though it's not really a property of the language itself. C interop is common because C's a very well established language, making it useful to interface with the existing libraries written in it.

>>20098 >People tout this as a strength of C's, even though it's not really a property of the language itself. C interop is common because C's a very well established language, making it useful to interface with the existing libraries written in it. I mean, if you benefit from it only when using C, I would say it is a strength of C, a language is not only it's design, but all the context that comes with it.

>>20068 C++ does more things for you, sure, which makes it seem easier in the beginning. However those features come at the cost of complexity: C++ is an enormous language, especially if you're using a more modern revision. Basically C++ is fairly easy to learn but incredibly difficult to master. C has a more linear difficulty curve: moderately difficult to learn, and moderately difficult to master. I think one thing that makes both languages challenging is that there isnt one single "idiomatic" way to write them, unlike rust or python or even java. This is more of an issue in C++ than C because its such a huge language. Seriously, if you compare C++ code that makes heavy use of templates and pure functions with the mire traditional object oriented style they don't even look like the same language.

>>20119 Well put. My day job is office work at a millwork/carpentry business, so I mentally think of languages as workshop layouts. To me, C is like a master carpenter's small workshop - a small but carefully-chosen selection of high-quality hand tools. In the hands of someone patient and intelligent (even if inexperienced) those tools can help make high-quality work.

https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f027338b0fab0f5078971fbe enjoy the read!

>>20119 This is a perfect description of C vs C++. Also the fact that there is no "idiomatic" C or C++ (at least that I know of) causes a higher barrier of entry of writing good C (or C++ code). Once you learn a way of doing it tho, it's really hard to move to another way. I argue with a principal engineer (I'm a senior) all of the time about how our coding styles differ and we both hate to use each other's styles. Although I'm more of a hard line "C++ should never be used" type of guy. I have yet to see an argument for C++, and yes I learned it as "C with classes" and "design patterns" which were not good ways to learn a language which is (probably) fine. Simplicity (that being C) is always my preferred style. The only major issue with C is IMO data structures, which are easy enough to create on your own, but writing the 100th linked list abstraction because you want to create a map gets kinda old after a while (although I think GNU C has its own list implementation, I've never looked into using it).

>>20151 >I have yet to see an argument for C++ I never write c++ but my brother does so professionally and from talking to him it seems like c++ is a lot better when you don't try to do the object oriented thing too slavishly. I guess one thing it has over C is easy polymorphism, but something it has over even more modern languages is a fuarrrking million different ways to achieve that polymorphism, so you really can pick the best option for your use case (inheritence/overrides, templates, lambdas, C-like function pointers and vtables,...). Obviously knowing which way is best requires a ton of experience but that goes back to the thing I was saying earlier about learning curves.

>>20141 Thanks for this.

>>19899 >Why do people hate C? I hate C because it's a language poor even when it was created. The Lisp, Smalltalk, Forth, APL, and other languages all existed before it. Compiling C is akin to compiling Brainfuck, as both are languages which only provide very low-level descriptions of the programs, require large compilers which recognize patterns to get basic information. I could write an entire book about why C is a bad language, but I'll link to this one instead; as an addition, I was halfway finished writing this post the first time, when my OpenBSD machine crashed and lost all of it, but the C programmer behind it sure did save time taking shortcuts: http://web.mit.edu/%7Esimsong/www/ugh.pdf I'll compare C to Ada to explain some of its shortcomings: Ada is a language designed to be statically-analyzed and compiled to efficient code, and uses very strong typing to achieve this. Ada requires explicit conversions, whereas C is littered with implicit recursion rules, which makes detecting mistakes infeasible. The C language makes bizarre demands, such as requiring variables to have addresses, which makes it much harder to remove them, whereas Ada allows this demand, but doesn't make it the default. Ada is a language designed to run programs to get correct results, so it has checks which ensure proper operation, when they can't be compiled away, but they can be specifically requested or removed despite this; C has no checks and the programmers continually make the same mistakes. Ada was designed to minimize surprises, but C compilers are prevented from giving good diagnostics due to the many ignored warnings they generate. An Ada compiler won't just remove code, but a C compiler can and will, silently. Ada is a language with English keywords, for comprehensibility; C is a language with an ugly and nonsensical syntax, which makes it harder to read and easier to make mistakes. Ada has a rationale, and C has very little, if any. Ada uses -- for comments to the end of line, whereas C uses /**/, which conflicts with division by a dereference and extends until the closing comment. People have issues understanding pointers, because of C's nonsense. Ada minimizes the need for access types (pointers) through various mechanisms, and subprograms describe how they use parameters, allowing the compiler to decide passing by value or by reference; C requires pointers in many cases, and requires the programmer to decide the passing mechanism. I don't want to retype my entire comment but, again, there's enough for an entire book. The language is littered with decisions where it seems to have taken precisely the worst choice, like associating pointer declarations with only a single variable declaration, rather than all of them, or using global state in errno instead of out parameters for failure. I've never seen another language which allows the disgusting combination of control structures C does, as with Pigeon's Device; it's clear there's no real design here, and it just so happened to compile: http://pigeonsnest.co.uk/stuff/pigeons-device.html Also read this, which compares Ada to C in the context of infamous C programming errors: https://annexi-strayline.com/blog >I've never seen a good programmer who disliked it. This is another reason to dislike C. People hate this attitude that real programmers use C, so anyone who doesn't like it isn't a real programmer. I want to write programs which handle all failure cases, but I've been told by proud C programmers this is undesirable. The C language encourages writing programs that break under certain conditions, which is unacceptable. People don't go around telling others Java is how the machine actually works, despite having hardware implementations in Jazelle, and yet there are plenty of C programmers who genuinely believe all of the nonsense with C is somehow inherent to programming, when it's not. UNIX does its best to force programmers to at least bind with C, and then people take that as a reason C really is necessary. If I want to discuss real low-level programming, I often find C programmers who are actually uninterested in the topic, but want to pretend C is relevant. The language isn't simple, and ignoring the standards the compilers follow isn't a real solution. Read that first linked book to learn that much of what's said about C and UNIX are lies. UNIX wasn't the first operating system written in a high-level language. C wasn't the first optimized high-level language. Most of what UNIX claims were actually done properly in Multics, written in PL/I. In the book Coders at Work, the now late Fran Allen at one point during her interview explains how C actively destroyed optimization research; the Bell Labs people just told the programmers to do their own optimizations. Systems better in every way existed, but now we're stuck with C garbage like UNIX that loses my work and barely works at all. A computer is a machine to automate work, and amplify human thought; a real programmer understand this, and wants to write the smallest program which achieves its task. A high-level language, like APL, which does more with less is good, but C programmers regularly advocate the opposite. There can be pride in writing tight machine code, which I enjoy doing, but what point is there in writing tight C, since it's just going to be given to a millions-of-lines compiler like GCC or Clang? It's easier to write correct machine code even, since C leaves most any program riddled with subtle flaws; isn't every program in K&R C actually broken in some way? There's no virtue in using this language, but people act as if there is. There's so much more I could point out here, but I must stop myself.

>>20183 What's up with the image and why does it have nonsense code?

>>20186 That's Pigeon's Device: http://pigeonsnest.co.uk/stuff/pigeons-device.html

>>20183 I'm sorry I'm not reading that wall of text but please don't post garbage code like pic related. At least use clang-format like a normal person.

>>20192 I mean, as a fellow C fan I am disappointed in this dumb responses to one of the more cogent criticisms of C in the thread. That said, >>20183 there are some points in here that I don't fully agree with, beginning with > requiring variables to have addresses I mean, I don't know if that's in the standard, but I'm pretty sure compilers don't put variables in the stack unless they have to (i.e. you use the address in the code/there's nowhere else to put it. > it has checks which ensure proper operation Sure, C doesn't, but that doesn't mean it's bad. It just means that the programmer has to put in more work to write correct code. The only issue I have with C's popularity is that it gets used on soykaf where safe languages like Ada would be better suited. > C compilers can and will, silently Yes, and that's annoying as fuarrrk. It is a very risky practice that has been know to generate bugs. Other people have seen this problem and try to fix it, like plan 9's compiler, but that didn't catch up. > with an ugly and nonsensical syntax I actually like it, it's really simple. The only time I get confused is when function pointers are involved, but otherwise is really simple to parse, imo. Maybe is just the practice. > conflicts with division by a dereference It kinda does but not really, you should be writing binary operators with spaces on each side. A shame that's not enforced. > issues understanding pointers, because of C's nonsense. I really disagree on this one. I don't know if I'm missing anything, but C's pointers function in the same way pointers work in the ISA level. I don't see an issue on that at all. > requires the programmer to decide the passing mechanism. Why is this bad??? > so anyone who doesn't like it isn't a real programmer. Yeah that is like kicking dead whales down the beach, I totally agree with you here. Elitism is a pervasive issue in CS in general, and when programmers (often young programmers) try their hand and mildly succeed at doing something perceived as hard (like writing in C), they get cocky. > UNIX wasn't the first operating system written in a high-level language. People say that? > In the book Coders at Work, the now late Fran Allen at one point during her interview explains how C actively destroyed optimization research; the Bell Labs people just told the programmers to do their own optimizations. I didn't know that, that genuinely is like kicking dead whales down the beach. > Systems better in every way existed I hope that, by now, you trust that I'm acting in good faith, so I'm gonna ask, what systems? Why didn't they succeed? About your final remarks, I'm just gonna say that I'd like to learn APL just to see what the fuzz is about. Haven't had the time tho.

>>20183 Ain't no body ever saw a C comment block and thought it was division of a pointer

>>20207 You can't even divide pointers. What kind of brain damaged person is doing the reading?!

I personally hate C and C++, because of their syntax inconsistency and overcomplication. Good example if this are pointers in D: D int[] a; // dynamic array of ints int[4][3] b; // array of 3 arrays of 4 ints each int[][5] c; // array of 5 dynamic arrays of ints. int*[]*[3] d; // array of 3 pointers to dynamic arrays of pointers to ints int[]* e; // pointer to dynamic array of ints In D pointer syntax is clean and is read linearly. Clean, beautiful simple. Meanwhile in C: C int(*(*ptr)[3])(); // It is array of function pointer which points to “array of function“ Is this some kind of April Fool's joke, overengineering or pure malice? Why make this so hard on purpose? Yet some C and C++ programmers will tell me I'm stupid, not the syntax.

I dislike C because it encourages a very bad attitude towards both language design and programming as a whole. C expects you to play by its rules, rather than the other way around. The syntax is poorly defined and inconsistent, you need to spend a lot of time with dumbass minutia that other languages would take care of for you, the type system is a flaming pile of garbage, and it loves doing random soykaf behind your back. What annoys me the most about C though is the community surrounding it. Everyone who writes C seems to think that anyone who can't deal with C simply isn't a good enough programmer to handle it. It's like saying you're bad with tools if you use a hammer instead of stones you find on the ground. Maybe the latter does take more skill, but that's not the point. If you want a job done well, you should use tools that naturally lend themselves to good results, and C is a tool that produces horrible results unless you go out of your way to make it behave.

>>20214 Another example is D's template metaprogramming being so much easier to use and read than C++'s, and it's more powerful too, I think.

>>20186 >>20192 I posted that code, because it's valid C, and a great example of what a bad language it is. That someone who supposedly understands a language wouldn't also recognize valid code in it is a good reason to believe the language isn't actually known. People claim C is a simple language, but examples such as this reveal it's actually disgustingly complicated. I'm aware of no other language where people have fun writing obfuscated programs that others can't understand, no matter how they try. >>20207 Why should that confusion be necessary at all? Plenty of languages don't have such needless confusions. >>20214 >Is this some kind of April Fool's joke, overengineering or pure malice? It's pure stupidity. >Why make this so hard on purpose? It wasn't done on purpose, just by people who had no place designing anything. >Yet some C and C++ programmers will tell me I'm stupid, not the syntax. Misery loves company. Someone bitten by mistakes which never should've occured will want others to be bitten in-turn. >>20203 >I mean, I don't know if that's in the standard, but I'm pretty sure compilers don't put variables in the stack unless they have to (i.e. you use the address in the code/there's nowhere else to put it. I'm not going to double-check the standard, but I believe it's required. Now, a compiler may still remove the need for addresses, if variables can be proven to not need them, but this is a bad default, because it places undue burden on the compiler for little gain. Ada uses the opposite default and also removes much of the need for variables which are aliased, so the compiler can more easily produce more efficient programs. >Sure, C doesn't, but that doesn't mean it's bad. It just means that the programmer has to put in more work to write correct code. History has shown again and again that the programmer will probably make a single mistake, which is all it takes, and it will probably be one of the same mistakes C programmers have been making for decades, to add insult to injury. It's acceptable to program without validity checks in some languages, like machine code, but people aren't advocating for writing plenty of things at that level, either, and people are usually more careful with machine code. >The only issue I have with C's popularity is that it gets used on soykaf where safe languages like Ada would be better suited. Where is C suited, precisely? To make it harder, is there a single valid use of C which isn't forced by UNIX? What passes for embedded doesn't really count, to me, since the machine code or Forth are more suited there. Where it really matters, Ada gets used. The Lockheed Martin F-35 uses C++ instead, and has been over budget and behind schedule for decades. Where's one place C should be used? >Yes, and that's annoying as fuarrrk. It is a very risky practice that has been know to generate bugs. Other people have seen this problem and try to fix it, like plan 9's compiler, but that didn't catch up. How many people use that in practice? Every time people boast about C's speed, it's really that of GCC and Clang. Would C be a fast language without these gargantuan compilers? I don't think it would, especially since a language like Ada can still take advantage of them. >I actually like it, it's really simple. My Pigeon's Device example shows otherwise. Forth has a simple syntax. C syntax only seems simple at a glance. >The only time I get confused is when function pointers are involved, but otherwise is really simple to parse, imo. Maybe is just the practice. Why should it be necessary to learn a confusing syntax for anything, when there are plenty of examples of how much simpler it could be; what does that complexity give anyone? Here's an analogy: A barrel of wine with a thimble of toxic sewage in it becomes a barrel of toxic sewage. >It kinda does but not really, you should be writing binary operators with spaces on each side. A shame that's not enforced. That's not the only shame. >I really disagree on this one. I don't know if I'm missing anything, but C's pointers function in the same way pointers work in the ISA level. I don't see an issue on that at all. Not all machines have instruction sets suited to C. Now, C also contributed to the death of specialized machines. A language like Ada has a real notion of types, arrays, and other things at a high-level. If a machine has a high-level notion of arrays, Ada can use them without issue; C can't. Machines with type-checking and other things in hardware had to treat all C data as arrays of characters, completely negating what the hardware was capable of. >Why is this bad??? It's bad because the compiler can make a better decision, and even change it during runtime. It's another way the supposed optimized nature of C works against it. >People say that? Yes, it's one of the many common lies people spread. >I hope that, by now, you trust that I'm acting in good faith, so I'm gonna ask, what systems? Why didn't they succeed? Xerox had Smalltalk machines, Genera and others had Lisp machines, and the Burroughs 5000 was known for its stability, for three examples. These machines didn't require the safety mechanisms of modern operating systems, because they guaranteed them in the hardware or the compiler. Imagine a machine which couldn't have buffer overflows, because every access was checked in hardware; it wasn't necessarily slow, either, because it could be done in parallel with other calculations. These machines didn't succeed for market reasons. Besides, consider how much money is made by writing C and C++ programs which break. Programs that don't just blow up would put a lot of people out of work, wouldn't they? Look at the Lockheed Martin F-35; it gets to have a lot of money thrown at it, because it doesn't work, because it uses C++. If it worked, there wouldn't be nearly so much money thrown around. >About your final remarks, I'm just gonna say that I'd like to learn APL just to see what the fuzz is about. Haven't had the time tho. There's a thread here; it's a fun language: >>9

>>20224 >C expects you to play by its rules, rather than the other way around. That's another major issue. When Unicode was becoming popular, C programs had to be changed, because C has no real notion of a character. What happened? Ken Thompson and Rob Pike convinced the entire world to bend over backwards so poor little C wouldn't be inconvenienced by a real-world problem. They popularized an awful character encoding specifically to work around deficiencies in C, and it's disgusting that they got away with it, and even receive praise for this.

>>19899 >I've never seen a good programmer who disliked it. cringe and b8. the world doesn't revolve around your real man's language. yes, there are people who hate it simply because they are dumb, but that doesn't change the fact that it's a bad language. get over yourself >>20214 The syntax is soykaf, regardless of the reasoning for it. There's literally no point. That's basically all of C culture. "it's da user's fault". Meanwhile every piece of C I've ever looked at is so broken you can segfault it just by reading any 20 lines of random code in it. People think they are just magically a good programmer if they read K&R (not remotely nearly enough to properly write C) and start soykafting out code.

>>20227 >I posted that code, because it's valid C, and a great example of what a bad language it is. That someone who supposedly understands a language wouldn't also recognize valid code in it is a good reason to believe the language isn't actually known. People claim C is a simple language, but examples such as this reveal it's actually disgustingly complicated. >I'm aware of no other language where people have fun writing obfuscated programs that others can't understand, no matter how they try. >the code doesn't fail to compile, C actually lets you call one case from inside another case NICE Thanks for telling me about that. I've just tested it out and it also works in C++.

>>20246 template<typename T> nextEven (T n) { switch(n % 2) { case 0: n++; case 1: n++; break; } return n; } Butiful I tell you.

>>20247 >nonsense code lol, just do n%2?n+2:n+1

>>20249 flip the branches around

>>20227 >People claim C is a simple language, but examples such as this reveal it's actually disgustingly complicated. C is simple in the same way that chess is simple. Few rules, unfathomable emergent complexity.

>>20249 Uncute. Don't make me actually find an exemple where that's actually the most efficient option. n + (2 - (n % 2)) btw.

>>20261 >unnecessary parens disgusting. You know, I think there might be something to what that lainon said about C programmers having fun by deliberately stripping down their code to the point of obfuscation.

>>20263 Unnecessary parenthesis improve readability at next to no cost sometimes, fuarrrking fight me. Technically needs no parenthesis at all, but n + (2 - n % 2) looks pretty alright to me. About the obfuscation thing: stripped down code is sexy, but it needs to be logically stripped off, it can't just be a superficial writing thing.

>>20264 I just put them in when the order of ops actually matters. You can do the sum in whatever order you want but the mod comes first so I'd probably write it n + 2 - (n % 2)

>>20265 >the mod comes first Yesh, that's why you don't need any parenthesis.

>>20266 We were talking about when to include unnecessary parens to help readability.

>>20247 >>20249 >>20261 >>20265 >n % 2 I think you mean: n & 1 Actually works correctly for negative odd integers, unlike n % 2 (^:

I dislike C because I disagee with its approach to syntax. There's way too many symbols, things are extremely context sensitive, and there's a ton of special syntax for things that don't need or even really benefit from it. The underlying functionality of C is super simple and makes a lot of sense, but that syntax intoduces way more headache than its worth.

>>20446 Oh nou,we have a LISPer over here

>>20448 I don't need C to be lisp, I just need it to make sense. C has no rules, and the only reason it gets away with it is by being small enough that nobody notices.

I think that in 30-50 years' time, most current programming languages will be forgotten (replaced by new ones), and the main survivors from today will be the current two surviving lisp dialects*, forth, APL and C, and some dialect of ML**. Of course I cannot predict the future, this is a very pretentious thing to say of me. What I actually mean is that given the current panorama of PL, the long-term relevance of languages seems to be just that. In that list, C is likely to remain "king" because it is still the most convenient of them all. Even if it's inferior to all the others listed in many ways, it is still the most likely candidate for oh so many uses and also as a reference. Consider how many copies of C are out there trying to be the "next iteration" of the language, often improving on one or two things, yet C has stood the test of time (and so many diverging iterations of course divide the codebase), and of course, these iterations target different goals, building on C with specific features, that is: they go from the general to the particular. The contestant that is most likely to replace C descendants (or Algol descendants) in production is probably a ML dialect since it has the cleanest syntax, the most intuitive (IMO), more formal and with the cutting edge in PL research. It's kinda like a sane man's lisp. I suspect lisp because despite all the preaching and the grandiose claims of it's fans, there is but very little successful software made with lisp, almost seems people don't actually want to use it. Of course there are working lisp systems running (and possibly servicing thousands of customers), but it doesn't seem anywhere near having the codebase of popular languages, and I am still waiting for a lisp OS half as popular as TempleOS, despite the wet dreams of it's proponents. Still, it has some of the best literature and it's a great language to learn the Master's secrets of the craft. Forth is commonly invoked as a replacement for C but as far as I know, stack-based programming is far slower than register machines. This is all, of course, my very own opinion. * Of the two lisp dialects, CL has some of the juiciest features but it has ossified and is likely not resilient to change. In accomodating the new paradigms to come, it is likely to break up in sub-dialects as already happened, they all being implementations that, just as the current ones, are written once and stay unmantained thereafter. The standard is stagnant, the use of the language has waned ever since making a revision unlikely. Scheme will also diverge into sub-dialects but it is far simpler to implement than CL, and it is often revised and modularly extended. ** ML dialect will probably be a new one, rather than Haskell. Or OCaML, otherwise. Haskell seems too complex to implement so something simpler may arise (perhaps something like typescript will be the norm) All that said, remember that the more users some software/language has, the soykaftier it becomes. Can't nave your cake and eat it, too.

>multics It wasn't even finished. >>20450 Of course people don't want to use lisp. People nag on c++ for having too much stuff, but with lisp there is potential for infinite variations of syntaxis. Of course when you doing project alone or in tightknit group this is good, but when working on a large scale project you can just get lost in a maze that somebody else wrote.

>>20459 >Honeywell continued system development until 1985. About 80 multimillion-dollar sites were installed, at universities, industry, and government sites. The French university system had several installations in the early 1980s. >In 1985, Multics was issued certification as a B2 level secure operating system using the Trusted Computer System Evaluation Criteria from the National Computer Security Center (NCSC) a division of the NSA, the first operating system evaluated to this level. >The last known Multics installation running natively on Honeywell hardware was shut down on October 30, 2000, at the Canadian Department of National Defence in Halifax, Nova Scotia, Canada.[13] Source: Wikipedia Surely you don't think an unfinished system would be used by multimillion dollar workstations. Why do you make up false information?

>>20183 Nice post. Thank you. Just one thing. >I want to write programs which handle all failure cases, but I've been told by proud C programmers this is undesirable. The C language encourages writing programs that break under certain conditions, which is unacceptable You are probably talking about bounds checks when accessing arrays. It again depends on the domain whether this is desireable or not. For normal user software it is absolutely no problem at all to use a language, that has automatic checks for such things, because the slow down will be unrecognizable to the user. But think of software for simulations, which needs to be extremely fast and accesses arrays millions of times per second. This software is carefully examined and tested to ensure that no such errors happen. And there is no point in checking array bounds when you know for sure, that every access is valid. >>20212 >You can't even divide pointers. He's talking about dereferences. Like here: #include <stdio.h> int main() { int a = 34; int *b = &a; int c = 68/*b; printf("%i\n", c); } This doesn't work because the "/*" is interpreted as a beginning of a comment.

>>20563 >You are probably talking about bounds checks when accessing arrays. I'm talking about everything. I want to write programs which always work correctly. SPARK Ada can completely elide all run time checking, because it can prove it's unnecessary, but normal Ada is still good for this. However, such checking constitutes insurance against hardware failure, or even a flaw in the prover or other infrastructure, so it's still a good idea to keep it. There's no good reason to disable validity checking, unless it's required for performance reasons, which is unlikely. >But think of software for simulations, which needs to be extremely fast and accesses arrays millions of times per second. That software is typically written in Fortran, which has facilities for ensuring array bounds are respected, such as being a known size at compilation. A language which merely has array looping or maps doesn't need bounds checking for those accesses, because it can guarantee, by definition, every access is valid. The overwhelming majority of C programmers aren't writing simulations, no different than how most Lisp programmers aren't writing an AI. Again, I so often see C programmers talk about the minor costs of array bounds checking, completely ignoring chasing null bytes for string lengths. There has been hardware which, due to using a high-level language for all software, could run all programs in a single address space. Consider the massive cost of constant context-switching imposed by the UNIX kernels, which better systems can completely elide. Better systems aren't competing on UNIX's terms, but showing how completely different and better systems can exist which UNIX programmers would think are completely unworkable.

>>20141 >using git commits as blog redpilled okay, readed it, basically C bad because locale is like kicking dead whales down the beach? What to do instead? C rocks because the syntax is not esoteric dogshit (also perl's syntax rocks for the same reason) C++ syntax is dogshit, and has the same C problems. Rust syntax is not dogshit, its horseshit, why {} to print soykaf? it's fuarrrking terrible python? Slow as soykaf Javascript? >javascript ruby? wasn't it dead? perl? rocks, but more dead than ruby php? do people still care about it? Zig? Tries to be a C repleacement. claims to be faster than C (good luck) because it always compiles with -O3

>>20662 yeah i like C for basically the reasons you stated >Zig I really like zig, and i wish it the best but i feel like its biggest benefit, that it doesn't fuarrrk around with the "C way of doing things" too much, is also its biggest weakness, because you don't actually gain that much by using it over C. hopefully it'll be able to find its niche. at least rust has a fairly compelling use-case proposition. seems like it'd be a good choice for huge projects involving many developers of varying skill levels. "go implement this trait on this object" seems like an easier project to hand to an intern than "create a class that encapsulates this behavior". besides the apple association, is there actually anything deeply wrong with objective C? i've only used it a couple times and kind of liked it. i feel like it has kind of the same problem as zig, but it benefits from being basically C with a better preprocessor/macro system rather than a totally different language.

>>20563 Those cases need very complex changes in the code to works, like what I did.

>>20675 What, if for some braindead reason, the code styleguide tells you to not leave spaces around operators? You're screwed. Also: at least put a space on both sides of the operator.

>>20677 I just did with one space because it is the minimal change which make this code to work, if you cant use space you still having "()".

I suppose you will create another restriction where its not allowed the use of "(" and ")", therefore I give you plus one.

>>20680 Using array indexing as pointer dereference is a bad idea in any scenario, even if your styleguide tells you to not leave spaces around operators and to only use parentheses when necessary. But wait, there's more! You can replace 68/b[0] with either of these: 68/0[b] 68/~~*b 68/+*b 68/-+-*b Maybe there's more but I don't have any at the back of my mind.

>>20682 >68/0[b] the fact that the subscript operator is commutative is one of my favorite things about C lmao

>>19899 >Why do people hate C? I don't hate the language itself. I just hate how it's used so carelessly, especially in a network context. I come from a network admin background, not a professional programming background (though I do it as a hobby and for some custom utilities at work). A lot of the hostility to C in my field is due to the ridiculously huge number of security issues in the past few decades that have happened because someone wrote a daemon in C or C++ and made mistakes that lead to security-nightmare buffer overflows.

>>20693 You probably think that webdevelopers which uses Java, PHP, etc must die hahaha.

>>20693 >You probably think that webdevelopers which uses Java, PHP, etc must die hahaha. No, I don't. Java has protections that stop most buffer overflows. It's extremely difficult to do it by accident. And anyone thinking of writing a standalone daemon in PHP is in need of a straightjacket and a padded room. I don't really care what language is used for web purposes (either frontend or backend), so long as either the backend is written in a safer language, or in the case of interpreted languages, the interpreter itself. I think C/C++ are fine, so long as they're not being exposed to a network. GUIs, HPC, drivers, sure. Daemons? Hell no.

>>20183 I wouldn't even compare Forth, APL and C. As for Smalltalk it came around the same. I'll add ALGOL and PL/I in the "better than C before C" club. What they all lacked was efficiency and portability. Thus they weren't suitable for the operating system that Bell Labs was developing.

>>20695 What about all the bugs not related to buffer overflow?

Are people who hate C the same people who can't drive without an automatic transmission?

>>20707 People who avoid C are people who are tired of a manual transmission that instantly shreds itself to pieces unless they handle the clutch with millisecond and millimetre precision every single time they shift gears.

>>20709 That's a bad allegory. Manual transmissions are basically impossible to shred. Automatic transmissions need frequent maintenance (oil changes. Oil flush)

>>20675 >>20678 >>20680 This often happens when someone points out a glaring flaw with C. No one cares that this particular trap is easy enough to not fall into, so long as the programmer is aware of it of course, because it shouldn't exist. There's no advantage to comment syntax trivially clashing with other syntax. To those who take offence at someone using C without being aware of its flaws, look at this post and the responses it received for an example of how most C programmers don't actually know C: >>20183 >>20696 I forgot to mention ALGOL; I knew I was forgetting one. >What they all lacked was efficiency and portability. Now, PL/I was efficient enough for Multics, and C isn't actually portable. One reason C would appear more efficient than other languages is because it doesn't do the checks they do, and has hidden flaws because of this. >>20707 Is programming about having the machine automate tasks or is it about feeling like a wizard and shunning those who don't know what the magic symbols mean? Most C programmers would admit that programming in an assembler is a waste of time, and it would be a better use of effort to instead improve the compilers for languages such as C. Conveniently, this thinking breaks down once anything about C is mentioned. Wouldn't it be nice, if I could write a program in a very high-level language, like APL or Prolog, and it would be as efficient as the machine could make it; time would be better spent improving these languages than improving C, if the goal is to efficiently and easily automate tasks. If the goal is to look cool while also shunning those not in the cult, and to get paid more to fix broken programs, then C is better, sure.

>>20717 Stop the bullshit, you cant do simple bound checking? you need the language generate slowcode for every fuarrrkinf access because you are piece of soykaf which dont know how to code?(Argue in good faith and avoid using personal attacks.)

Does anyone know if there's a better C alternative than Zig? I'm looking for something that is both simple and not mired in 50 years of stagnation. Zig looks good but I would prefer something more mature.

>>20718 Don't get too upset now, that would be embarrassing. Firstly, if a language does bounds checking on every access in principle, it can remove any which can be proven to be unnecessary. In a language like C, there's likely to be more unnecessary bounds checking, since the programmer will be defensive, even if it's never actually needed in the final program. Secondly, a language doing bounds checking will, outside of implementation errors, never lack a necessary bounds check, whereas C makes it exceedingly likely the programmer may forget at least one, which is probably all that's necessary. In a language like SPARK Ada, the tools prove no exceptions can occur, meaning all bounds checking is unnecessary. However, in critical infrastructure (not too much C there, thankfully) it can be good to keep it anyway, because it serves as protection against hardware failure.

>>20720 You could try BetterC: https://dlang.org/blog/2017/08/23/d-as-a-better-c/ https://dlang.org/blog/2018/02/07/vanquish-forever-these-bugs-that-blasted-your-kingdom/

>>20450 I found this post to be a good read but can I just say that I think your writing was a bit odd? >I suspect lisp This threw me off the first time I read it because, relative to the context of everything else you were saying, this seemed like you were saying "I suspect lisp [will be successful] because..." When considering the way you used the word "suspect", I believe the correct phrasing would have been "I think lisp is suspect because..." as that's how I commonly see the word "suspect" used, when it's used in the way you're using it in that sentence.

>>19899 I love and hate C. C++ has a ton of useful nice functions (sorting of vectors, string manipulation, and so on) but it comes with such a ton of garbage on top of it. C is beautiful in it's simplicity, as I can express everything I want fairly easily in C. However, reimplementing the 1000th sorting function, the 1000th linked list and the 1000th dynamically growing array gets so fuarrrking annoying. Also C++ classes can be nice. When I program something like an projectile in a game, it is so much faster to write specific_object->compute_velocity() than object_compute_velocity(specific_object). I would love a mixture of C with minimal C++ functionality in it. But without the BLOAT.

This book is pretty good for people wanting to get better at C

>>21181 >get better at C It's introductory, there's not much you can gain from reading it if you already know some C. I read it and it's great, but as I said, there's not much to gain.

>>21181 >>21198 Hey, lains, I think this is a thread for hating C and you're looking for >>>/λ/19673

>>21199 Aight, thanks. Have a good one <3

I don't dislike C, it's a fine language. My beef is with the people who use it and the general philosophy it represents. A good number of the people who use C nowadays are suckless types who think that "worse is better" is the be-all end-all of software design, when in reality it's probably the worst possible way to design a program. There's inevitably a point where solving a problem 90% of the way doesn't cut it anymore, and it's usually sooner rather than later. So what ends up happening is that people make ad-hoc additions to the 90% solution, and what you end up with is an error-prone kludgy mess that could've been avoided by making something robust enough to solve 100% of the problem day one. C++, modern UNIX, and web browsers are all testaments to that fact.

>>23519 >modern UNIX There is no such body as "modern UNIX". UNIX branched so heavily we have many OSes descending from it each with different philosophy of design.

>>21199 >There is a thread for hating C Hey, that's pretty cool, can we too have a thread for hating lisp, haskell, ada ...?

>>23563 Sure, just create a thread for the language you hate. But do better than the OP of this thread, who assumes the people that hate C are not 'good programmers'.

>>23527 The vast majority of popular UNIX systems share the same problems because they run the same software. Everything that runs X or wayland is broken by default.

>>23527 That's an interesting perspective. I just finished reading this: https://mbalmer.medium.com/when-seekdir-wont-seek-to-the-right-position-a9e2b1986203 The seekdir implementation under every BSD and Mac OS X has been broken for twenty-five years, because the idiots just copy and reuse code they've never bothered to understand.

>Hey, that's pretty cool, can we too have a thread for hating lisp, haskell, ada ...? Go for it. You'll find almost nothing to complain about.

>>19899 Personally I don't really hate C, but I'm very tired of it. It never changes and adds simple but useful abstractions that are applicable universally and it never adds useful things to the standard library that should've been there a decade ago (asprintf, strdup...). On the desktop the ecosystem is barren. You've got a couple of "big" frameworks like Glib and some huge libraries for specialized tasks (openssl, curl, etc), but nothing in-between for simple utility functions. For those you're expected to write them on your own for every single project or copy some random's pastebin. I'm talking about the simple things everyone needs like mkdir-p, rm-rf and data structures such as lists and hash tables. They don't belong in stdlib, but it'd be nice to have a second-class stdlib to avoid duplicate work. On embedded this is less of a problem, as you generally *need* less, but the lack of simple abstractions that are otherwise universally present is felt here anyway. Namespaces are a big one for me, as large names get ever so closer to the 80 char boundary, but also things like specifying the size of a flexible array in a structure when allocating statically. Hell, binary literals are _still_ a GCC extension. C moves so slowly that it becomes impossible to add nice and useful features that would improve the lives of everyone while still being in line with C's core principles, because apparently change is against said principles. I don't think it'd be very controversial to say that having a committee killed any chance for this to improve. And yet, C is the only thing I consistently keep having to come back to, no matter how hard I try to avoid it. Maybe I really should pick up C++ some day.

>>23643 >On the desktop the ecosystem is barren. You've got a couple of "big" frameworks like Glib and some huge libraries for specialized tasks (openssl, curl, etc), but nothing in-between for simple utility functions. This resonates with me. I've been building a toy example to use 'poll', but the majority of the effort is going to code to add and remove 'struct pollfd' from a static array. I didn't want to couple the code for bounds checking with the network code, so instead I have a max size collection type that can fail in two ways: no room to add an element and cannot remove an element because it doesn't exist. There's no exceptions, so these functions need return codes which have to be checked by the caller. It would be far easier to just do array bounds checking in the main loop, but then it can't be tested separately. In C, it takes forever to do anything. At least it's fun to write code slower than you can think. It feels very productive.

C is alright for some specific tasks and I love the freedom it gives me as a developer. However, I dislike the general culture around it which view it as the greatest language of all time and dislike anything remotely high-level. This whole "real developers" business they deal with is toxic and doesn't help anyone. Also, I find it's very hard to make something that's very stable in C. There's always some shaky foundation for my project or it's full of hard to find bugs. It's a feeling I never get in Common Lisp or Haskell, but is all too common in C.

>I've never seen a good programmer who disliked it. Define good? There's got to be at least one high-ranking professional out there who hates it. I've liked C for a very long time. However it's hard to deny some of the systems put made it very easy to shoot yourself in the foot (e.g. a default allocator, no stdlib way to pass your own). I know generics is a hot topic with C, and while I don't like the way most languages handle generics, having to implement an in-home vector for whatever object you're implementing (or maybe worse, using macro magic to fake generics) is a pain. That's not going to stop me from programming in C. But it's not faultless, and I understand why some people hate it.

>>23563 >>There is a thread for hating C >Hey, that's pretty cool, can we too have a thread for hating lisp, haskell, ada ...? I'd like one for Dart. The gentle learning curve and intuitiveness of C++, the elegance and power of Javascript, and the tooling simplicity of C#.

GNU C >>>> C++ > Standard C C with GCC extensions is really great. Without those extensions, though, C++ provides some features which are really useful and necessary, like RAII... So I think people hating on C are probably hating on standard C, not C with extensions. The same goes for other ecosystem features of C - on its own C seems bad, but there's so much tooling and support out there for C that it's a really powerful programming system.

>>26529 What good GCC extensions are you talking about?