15 ms·
The Problem with C (2020)
- theherk 5y agoOh boy. Can't wait to see how this comment section materializes.
- __vim__ 5y agoLet me grab a seat
- 0x008 5y agoOf course it will be a circle jerk about how C is generally better because it is more simple. Then a bunch of people mentioning we should abandon C++ in favor of rust.
- 0xFFFE 5y agoC is generally better because it doesn't treat you with kid gloves, if you don't know what you are doing you will get fucked in the ass. That said, any competent engineer would know what tool to use to solve a given problem. You don't use a sledge hammer to fix a watch.
- 0x008 5y agoI agree, the tools should make it very clear what implications using a certain feature has (e.g. unsafe in rust).
- pjmlp 5y agoC did it already in 1979, yet people keep ignoring it. > Although the first edition of K&R described most of the rules that brought C's type structure to its present form, many programs written in the older, more relaxed style persisted, and so did compilers that tolerated it. To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions. https://www.bell-labs.com/usr/dmr/www/chist.html https://www.bell-labs.com/usr/dmr/www/chist.html
- tialaramex 5y agoWe've been here before with other aspects of human behaviour. If you really don't want people to do it, make it impossible and then they can't. You can't write an integer overflow in WUFFS because that doesn't compile. You can't use your Google.com WebAuthn credentials to sign into fakegoogle.example, even if you really, really want to, even if you're 100% sure this is a good idea, it can't be done. Any time you stop short of this, you mustn't really want people to stop doing it and so they won't. The next strongest defence, still not used often enough, is to make it very annoying to do things that are a bad idea. Default deny for example, the compiler obliges you to go in and explicitly allow the obviously bad thing you've done each and every single time you do it. A DLR train can be driven in fully manual mode instead of being automated, but it goes annoyingly slowly if you do that. Linting is far below the visibility of even compiler warnings, most of your target audience will never see the message. It's not even "Do not look into laser with remaining eye" but more like a "Caution: Eye hazard" warning written inside the never-opened instruction manual.
- pjmlp 5y agoButchers are also free not to wear metal glovers, if they lose part of the hand because they don't know what they are doing, tought luck. Any competent butcher will never cut themselves.
- habibur 5y agoIn case you are wondering what's this article is about, a more expressive title would be : "C++'s problem with C".
- hn_go_brrrrr 5y agoCorentin is on the C++ standards committee, so no surprise there.
- kstenerud 5y agoC is the glue interface that connects all the different languages together. I wouldn't want to see anything new added to the language that complicates this lingua franca. I liked C in the 80s, 90s and 2000s. It was a neat and simple language, but that changed as compilers got more aggressive with their optimizations and exposed just how complicated and unintuitive the spec actually is (and the impossibility of avoiding UB). C was a good learning experience for language committees (as was C++), but it's time to cut our losses and move on. I also liked C++ in the 90s, but soon grew to despise it. When they tried to revamp it and make it safer to use, I was hopeful, but that's now gone. It's too complicated, the error messaging sucks, and there are too many different ways to do the same thing (with ever changing best practices). In a way, CMake and C++ are two peas in a pod. This is why I now pin my hopes on rust and zig. I want to write low level code, but not in C or C++. I want a build system that's not Makefiles, CMake, or (shudder) gradle.
- kajaktum 5y agoWhat makes you think Rust and Zig will not suffer the same issue given enough time?
- kstenerud 5y agoThere's absolutely no guarantee that these problems will be avoided in rust and zig; we only have the benefit of hindsight to avoid the problems we have now, and a recorded history of the kinds of things that tend to go wrong in committees (factions, infighting, BigCo interference, intrigue, egos, bike shedding, etc).
- jackosdev 5y agoThe Zig creator is very conscious of this, talks a lot about rejecting many proposals and ideas to keep the language simple, not being an ass-hole about it, just to avoid what happened to C++.
- Someone 5y agoAnd then the question is whether it will grow fast enough, or get overshadowed by a language that’s a bit more like a weed, growing fast in whatever direction it can, and whether it will then die because of lack of sunlight. It’s tricky to balance features, backward compatibility and ‘cleanliness’ in a (language, standard library)
- Hublium 5y ago> [C++] also had type inference very early on, but the developers of the mid-80s were not quite ready for that and Bjarne Stroustrup was pressured into removing auto, until it was added back to C++11. Does anybody have background information on this claim? Was there actually a working compiler with it back then or was it just some proposal paper at the time?
- slaymaker1907 5y agoI found a post claiming it was used in B and C to specify a data type stored on the stack. https://stackoverflow.com/a/8272497/7608007 https://stackoverflow.com/a/8272497/7608007
- pjmlp 5y agoC23 is considering following C++ footsteps and repurpose auto as well.
- colonwqbang 5y agoI hope they don't, at the very least we can afford to choose a new keyword. Even if auto was infrequently used, it's no good to silently change the meaning of existing valid programs.
- foldr 5y agoWould it change the meaning of existing valid programs? C's "type inference" algorithm is to assume that everything is an int by default. So auto x = 7; is equivalent to auto int x = 7; which is equivalent to int x = 7; (since "auto" is the default storage class). If the C standard folks do things right, then the only change will be to allow some previously invalid code like the following: auto str = "foo"; Such code will compile on a C compiler (hopefully with a warning!) but won't have a defined behavior. I guess a more problematic case would be auto x = 9999999999999L; Where the value will be truncated in C but will be inferred as a long in C++ (assuming typical sizes for int and long int). Again, though, I am not sure if truncation of signed constants has a defined behavior in the standard.
- slaymaker1907 5y agoI write a lot of code in a C++ codebase and I'd say C++ is horrific. Not just because of its roots in C, no I think it is actually a worse language than C. Notable detriments in the language include references, classes, a lot of template stuff (some of it is ok, but it makes separate compilation almost impossible).
- google234123 5y agoYour examples for why C++ is bad are references, classes, and templates? So I guess you like Fortran77?
- loup-vaillant 5y agoReferences are kind of redundant when you already have pointers, and they make the performance characteristic of the code you read less clear (am I passing down a pointer, or am I copying the whole thing?). C structs can already do most of what C++ classes can do. Including inheritance and virtual methods, when you really really need them. As for encapsulation, pointer to implementation provide a more stable, harder to cheat interface than private members. A must for stable ABIs. C does lack generics, and I do often miss them, but templates really aren't a good solution. I don't know what a good solution looks like, I haven't looked at Zig or Rust yet. Another thing I miss in C is a namespace system, especially when you ship libraries: makes every name longer, and you still have annoying name clashes from time to time.
- bitwize 5y ago> References are kind of redundant when you already have pointers, No. They're not. References must point to valid objects (i.e., cannot be nullptr and cannot be random addresses in memory), and you cannot do arithmetic on them. They are much safer to use than pointers, so actually, references make pointers redundant. > C structs can already do most of what C++ classes can do. Including inheritance and virtual methods, when you really really need them. Only much more cumbersomely.
- 5y ago
- unwind 5y agoAs a long-time C aficionado, part-time wanna-be language-lawyer, and just general supporter and fan, the fact that there is no C conference was interesting. I guess I knew that, because if there was such a conference I would have known, at least I would like to think that. On the other hand I've never been to a programming language conference (probably self-fulfilling by being primarily a C programmer at heart) so it's not "a thing" for me. Anyway, some things I think would make for interesting content at such a conference, should one decide to exist: Modern C. It would be useful with practical down-to-earth comparison between C the way (I feel) many think it "should" be written, i.e. C89-style with lots of worry that the compiler may be broken, and something more modern/sensible. Standard directions. Some kind of survey-style talk trying to both summarize known interests covered by the committe now, and also perhaps polling the audience for input about where C needs to go. Compiler architect's thoughts. Get the major compiler writers in a panel, have them talk about how various language (mis)features affect their ability to write good compilers, and what changes would help with that, if any. Code sight-seeing. Just having a few knowledgable folks navigate some well-known codebases on a projector with commentary/analysis would be very interesting I think, both to see how others have solved things, and perhaps spot problems/possible improvements. Must be done respectfully of course. Now I almost feel as if I miss that conference. :/ More ideas, anyone? (Edited for typos and grammar)
- bb88 5y ago> As a long-time C aficionado, part-time wanna-be language-lawyer, and just general supporter and fan, the fact that there is no C conference was interesting. There doesn't need to be a conference for everything under the sun. I don't see a screwdriver conference popping up around me anytime soon.
- bluetomcat 5y agoC++ is a semantically overloaded language. It is very far from "C with classes" at this point. In C, every construct has a direct mental mapping to its rough representation as machine code, and its corresponding side effects. C++ adds a "meta stage" after which the machine code might be the same, but it takes a lot of time for the programmer to figure out what is really happening.
- smackeyacky 5y agoIn classic "get off my lawn" style I thought C++ divergence from C when they abandoned cfront was where it all went wrong. At least with cfront you had some idea of what was getting generated. My favourite C++ compiler was Symantec 7 on windows. It was a great, affordable tool for making MFC applications and had a neat GUI builder too. I still have the CD of it but it refuses to install on windows 11 sadly. Nowadays I just use C or C#, C++ just seems like a hard to use version of C# and I have little use for the extra performance it might have.
- nnoitra 5y agoI dislike C++ for the same reason I dislike all languages that try to be everything. You can use the language for years and there are still parts of it that you don't understand properly. C on the other hand has such a minimal and clear syntax that you can learn it pretty fast and feel confident about the language.
- vkazanov 5y agoWell, one of the problems of C is that it's not as simple as it wants you to think it is. :-)
- Koshkin 5y agoRight. You just move complexity into the codebase.
- vkazanov 5y agoWhile true, most C coders are fine the idea of only introducing complexity upon demand. No, what I mean is these subtle things that are impossible to get right: stupid integer promotion rules, needlessly complex declarations, messy stdlib functions, undefined behaviour as a feature, etc.
- zelphirkalt 5y agoAnd then there are languages, which are fractions of the amount of syntax you have in C, much more consistent throughout, which can actually claim to minimalistic.
- usrbinbash 5y agoSo what is the <title> then again exactly? Because my takeaway from the article is this: C++ piled loads and loads and them some loads of stuff onto a slim, easy, comprehensible language, is now a gigantic pile of complexity. that has precious little to do with its roots any more...and every attempt to solve its problems includes piling on more complexity. So, how is that a problem of C? C is not responsible for C++, simple as that.
- username91 5y agoThe title doesn't seem to correspond to the article at all; basically it's clickbait.
- srvmshr 5y agoC++ is an overloaded language whose complexity seems to be growing with each revision. Heck, I remember Bjarne Stroustrup even semi-lamenting it in one of the interviews. I don't understand why this is a C problem, whose syntax and definitions have been relatively stable for the last 3 decades. Author has gripes with C++ 'universality' IMHO but just piling it on C.
- usrbinbash 5y ago> I don't understand why this is a C problem Because it isn't a C problem. C has been basically stable for decades. C++ is free to overload itself by piling ever more stuff onto itself, but any problems this language has, are not problems of C, or problems C needs to fix.
- pjmlp 5y agoISO C11, ISO C17, ISO C23, GCC C, clang C, xlc, aC, TICC, MSVC C, ...
- srvmshr 5y ago> ISO C11, ISO C17, ISO C23, > GCC C, clang C, xlc, aC, TICC, MSVC C Absolutely. Some are feature fixes, malloc changes etc. How many of them are breaking changes or deprecations?
- pjmlp 5y agoC11 made a couple of breaking changes, any compiler is no longer required to support the optional annexes. Your beautiful VLAs will stop working, unless one only uses GCC or clang forks.
- deleted 5y ago[deleted]
- mr90210 5y agoC is just perfect as it is.
- Koshkin 5y agoBut K&R C was (aesthetically) more perfect. ANSI could not live with that, apparently.
- bear8642 5y agoYou mean no function prototypes or just the idea that declarations defaulted to int? Only used ANSI so wondering what excellence of K&R C mean
- Koshkin 5y agoBoth. Note that a huge amount of groundbreaking code had been written in K&R C before someone decided that it was "not good enough."
- deleted 5y ago[deleted]
- scoutt 5y ago> > There Are No C Conferences. Maybe that’s why the C++ committee is now over 10 times the size of the C committee. I have this controversial thought: C people understood one thing before everyone else (including the creators of C++, Rust, and any other language), and is this: “Perfection is Achieved Not When There Is Nothing More to Add, But When There Is Nothing Left to Take Away” -- Antoine de Saint-Exupery. Super-bloated languages that keep adding features every month/year are far from perfection. Now bring it on! Note: I love both C and C++. I prefer C because it's simpler (I write firmware for a living). Sometimes I use C++ with simple classes and I might throw in a template or two if I am in a good day. Of course my classes are for my use only: don't try to copy/move them!! I won't chase every little nitpick of deleting and overriding every operator/constructor!! And the further I might go is implementing a Singleton.
- pjmlp 5y agoI guess you haven't kept up to date with ISO C work.
- scoutt 5y agoMay be, but... https://en.wikipedia.org/wiki/C17_(C_standard_revision) https://en.wikipedia.org/wiki/C17_(C_standard_revision) "C17 addressed defects in C11 without introducing new language features" means a lot. https://en.wikipedia.org/wiki/C2x https://en.wikipedia.org/wiki/C2x Has a few additions compared to C++20 (https://en.wikipedia.org/wiki/C%2B%2B20 https://en.wikipedia.org/wiki/C%2B%2B20)
- pjmlp 5y agoHave fun reading these ones instead of relying on Wikipedia, https://news.ycombinator.com/item?id=30160590 https://news.ycombinator.com/item?id=30160590 Also you forgot the endless amount of compiler specific language extensions.
- scoutt 5y agoLet's see what (and how it) lands in C2x. Of course, as any other language, C might be taken over in the future by a new generation and be bloated, too. But so far, it is contained. In any case, nobody can deny the amount of bloat in C++ has no parallel. > Naturally at this point one could ask why not just use C++ instead I might do, in a limited and simpler form, as I said before. Of course I am not developing something like SKIA; just firmware in a limited and constrained environment (not even using std).
- ssfak 5y agoMore adequate title would be "C++ problems with C"..
- cortexio 5y agoFor me, C is perfect and just works and C++ doesnt. That being said, both their std libs are a big mess. It's absolutely horrible. The problem is the macro preprocessor. It's a horrible feature that should not have existed.
- gk1256 5y agoC is not perfect. It's closer to assembly, but you can't do anything useful without reinventing most things that is already done in C++. C++ STD lib is not a big mess. At least, I am using it for decades. I don't know if you really used it because those who are against STD doesn't understand the point of abstractions and it's utility. They always tend to cite why would I use vector when I can create a "simple" linked list myself with pointers.
- notacoward 5y agoAs far as I can tell, the definition of C++ is mostly driven by compiler folks (and wannabes), motivated to add features for their own career benefit and generally doing so in the way that's most convenient for them (e.g. std::move as a pseudo-function instead of as real syntax that the already-insane parser would have to handle). Since only the in-group's interests are considered, the much more numerous regular C++ users are ill served. For all its faults, there's much less churn in the definition of C and what change does occur seems to be driven by clearly demonstrated needs out in the real world. C might seem stagnant, outdated, incomplete, or unsafe - all fair criticisms - but at least a competent C programmer's hard-won knowledge of how to overcome these deficiencies doesn't get turned on its head every few years as a new language version comes out. Even decades-old C (at least since the K&R vs. ANSI function-declaration change) is still readable and scarcely less idiomatic than something written last week. So, referring to the OP's title, which language has the bigger problem?
- gk1256 5y agoI don't think they are wannabes. Getting a feature accepted to C++ is hard. That's why most people push their features into Boost (well, MVP style). The C++ committee has respected people with years of experience.
- flohofwoe 5y agoAs a (now, primarily) C developer who still uses plenty of C++ in mixed-language projects when needed: C++ should only provide as much C compatibility as is needed for consuming headers with C-API declarations, and nothing more. Microsoft's 2012 advice [1] to compile C code with a C++ compiler was misguided (at the time this was just an excuse to not support the latest C standards in MSVC). Writing C code in the so-called "common C/C++ subset" is a massive PITA for a C coder, because this common subset is a nonstandard dialect of C which will forever be stuck in the mid-90s. [1] https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/ https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-an...
- throwaway984393 5y agoMost programming languages are really good. People who talk ill of them just don't know them well, and also probably never lived while there were no high-level languages. And honestly, people are creatures of trends; we don't use the most popular languages because they're flawless. The only major problem with C is its community never took off with a popular library packager and linter. Every other language that seems so cool today would be just as painful as C if they didn't have so many contributed modules and tweaks. Port those to C and people would fall in love with it all over again.
- BirAdam 5y agoThe C package manager was and still is (largely) any UNIX/Linux distribution and the source packages for them. That’s how common C is. Linters are up to the user. There are many, but older UNIX systems that I’ve used generally included a `lint` command. If you really wanted to, you could consider UNIX/Linux operating systems the “IDE” and package manager for C.
- jon_north 5y agoIf I'm writing C++, I am doing it because I need nanosecond latency (and the delicious language libraries). If I only need microsecond latency, I would use Golang. If millisecond is fine, it'd be Python in a hot minute. If I only need (as is 99% of the time the case) a smidge of code to run nanosecond-fast, I'd write a C extension and call it from a higher-level language that does the orchestration code. The C extension would by definition be simple code, so there is no real problem with C as such - it's ideally suited for that role. Only in the rare case that a large program needs to be nanosecond-fast would I even consider C++ (and I'd push really hard to learn if that really needed to be true!), and then I'd write code like it was 2003 - smart pointers and POD classes, but that's it. The new libraries are wonderful for saving code and getting good fast implementation of algos!
- deltaonefour 5y ago>Only in the rare case that a large program needs to be nanosecond-fast would I even consider C++ (and I'd push really hard to learn if that really needed to be true!) This is mostly true for web development where bottlenecks just exist in IO and beyond. For gaming this is not the case. The entire industry needs nanosecond latency so engines must be written in languages that are nanosecond-fast.
- jon_north 5y agoYes, that's true. I've actually been part of 3 published games, all in C++ -- all written with the ethos I mention above (POD classes and basically write like it's the year 2003). Bitcoin is the same way, written in C++ -- unfortunately that codebase went hogwild with new features just to do it. Codebases like zcash are absolutely nightmarish for no reason at all (given what they are doing is so trivial)
- gk1256 5y agoC is a terrible language. You have to reinvent everything on it. The simplicity is just a lie. C++ on the otherhand is way simple to use and really straightforward. I like Zig too.
- BirAdam 5y agoBy “reinvent everything,” I believe you mean to say that you have to make your own linked-lists to have adjustable strings, and you have to create structs with function pointers to have objects… The simplicity is either in the language and tooling around the language, or it is in the code you read and write in that language. C chose to be simple in the language itself and not in the code. The single greatest praise that I will give to C is that the entirety of the language can be held in the mind of the programmer using it, with zero need for reference. This is impossible in most other languages.
- gk1256 5y ago> By “reinvent everything,” I believe you mean to say that you have to make your own linked-lists to have adjustable strings, and you have to create structs with function pointers to have objects… Spot on. > C chose to be simple in the language itself and not in the code. But it market itself being simple so people even newcomers think that C is simple in every regard. Only few people rarely acknowledge this fact. > The single greatest praise that I will give to C is that the entirety of the language can be held in the mind of the programmer using it, with zero need for reference. This is impossible in most other languages. In other languages, which parts you are unable to held in your mind? The only instance where I need references in C++ is STD library features. But if we measure, it take less time than if we were to reinvent it on C.
- notacoward 5y agoWhat I think a lot of detractors miss is that this reinvention need not be done by every single C programmer. In any significantly large and/or old C codebase, there will be local data structures, functions, macros, and idioms to solve the kinds of problems specific to that domain in a way suitable for that domain. For example, in my own domain of servers for distributed filesystems and similar things, the codebases I worked on had sophisticated ways of dealing with memory lifetimes across "discontinuous" control flows because of queuing, RPC, and so on. Those ways worked. I saw similar things in kernels, databases, etc. When I started working on a C++ codebase for yet another distributed storage system, every programmer seemed to be fighting to make C++/STL do the right thing in a memory-lifetime milieu that the language and library designers had apparently never contemplated. Worse, each programmer seemed to be solving those problems in different ways, leading to a proliferation of approaches which sometimes weren't even compatible with each other. That code had far more copies and memory leaks than the C code I'd worked on previously, despite the previous code having been worked on mostly by programmers with a significantly lower skill/experience level. Ironically, there was more wheel-reinvention in the C++ code than in C. I'm not saying C is the right choice for every project. C++ isn't either. C++ might be a pretty good language for doing the sorts of mid-level things that the people on the C++ language committee like to do (surprise surprise) but there are many broad domains at both higher and lower semantic levels for which it can be a poor fit. For a lot of low-level stuff a language that lets people define their own domain-specific abstractions will beat an "every bell and whistle and all wrong for what we're doing" language every time.
- sylware 5y agoI stick to lean and simple C89 with benign bits of c99/c11. With nice tables of functions and clever recursive pre-processor naming, you can scale that easily to large modular applications and keep everything very clean. The absolute and unquestionable truth: a c++ compiler is abysmally more complex and hard to write than a C (89 with benign bits of c99/c11) compiler, and this is mecanically true due to the syntax complexity difference. There are many shmol and cute alternatives C compilers out there (and there are working better each day which goes by, and some are doing more than enough optimizations), and I would like to use them, that which is not possible with c++, due to its complexity hence shuting the door hard on any reasonable efforts of writing a "working" alternative. That said, personnaly, I have high hopes (maybe too high) if RISC-V is successful: I see everything assembly (not even C anymore) with high level script languages of the like of python/javascript/lua/etc. I am writting more and more assembly these days (mostly x86_64 though, desktop RISC-V are only starting to ramp up in performance), and the main pitfall seems to be the abuse of the macro language of the assembler, which could be averted if explicitely aware of this bias.
- throwaway17_17 5y agoCan you expand a little on the pitfalls you see concerning the 'abuse of the macro language'? I have an undeniable pipe dream that my hobby language can be essentially a well-defined and explicit thin cover for assembly language primitives. I think your thoughts about the downsides of 'higher-level' idioms/practices when using assemblers would be very on point for me to consider.
- sylware 5y agoI use FASM, and FASM has probably one of the most powerfull macro languages out there. FASM actually implements _only_ this macro language and _not_ the x86_64 assembler itself. The x86_64 assembler is actually written using this macro language, like the support of ELF, COFF, etc, binary formats. Some ppl have implemented an ARM assembler with this macro language (and I am thinkink about RISC-V). Its author likes to refer to this macro language as an "assembler writting toolkit" which looks to me more than fair. As a practical example, this macro language has full support of modular and hierarchical namespaces. I found myself lost into dividing my code paths in basillions of namespaces and that way too much. Excessively, I also started to write my "own" language using this macro language: I was not writting assembly anymore, only macros and some with hardly any assembly in them. This is actually a bias that happens with any computer language: the tendency of devs to "maximize" the usage of some syntax, which kind of increase exponentially with this very syntax complexity, to reach a point where a Rube Goldberg machine looks efficient and sane (yes, this is severe irony).
- schwanky 5y ago
- JonChesterfield 5y agoThe problem with C is undefined behaviour. Not mentioned in this post. Specifically the somewhat recent idea that code which does something naughty is best deleted. This makes updating a compiler a hazardous activity for approximately all 'C' code. Also makes refactors somewhat risky when they send code down different paths in the compiler. I wonder if this judgement and execution result from collaboration with C++.