Live data from Hacker News

The Development of the C Language (1993)

bell-labs.com

251–260 of 536 posts

Re: The Development of the C Language (1993)

#251
post #6

People who still write C, honest question: Why? C is full of quirks. From cryptic "undefined behaviors" to a type system that isn't really a type system (more like "size hints for the compiler"), the language doesn't feel easy to use/debug. Add to this CPP macros, a universally recognized bad idea, a clunky import system, and lack of a single reference implementation of the compiler/libC, and you have a language that…

> I used to think "C presents the most honest representation of the low-level mechanisms of the computer", but... even this is shaky. I've been programming for almost 15 years now, and I don't think I've ever seen a computer where memory is actually a continuous array of bits sorted by memory address. The C representation of memory (and all the pointer arithmetic) is not a real representation of your hardware, and th…

>>I don't think I've ever seen a computer where memory is actually a continuous array of bits sorted by memory address.

I may be being pedantic or outright wrong (since it's been a while since I used C), but I don't think C can address memory by individual bit.

You have to read one or more bytes from memory, twiddle the bits in them, using C's bitwise operators (like !, &, | and tilde), and then write the changed bytes back to memory at the same addresses you read them from. At least for the earlier C versions I used, this was the case, IIRC.

And to read and write those bytes, you do it via scalar variables like ints or longs, or via structs or arrays, or via pointers. Or using library functions like memset().

Re: The Development of the C Language (1993)

#252
post #119

"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…

they should simply use c++, like k&r did to compile their example code in their 2nd ed - see preface to book if you don't believe. i will never understand why C programmers get so upset about C++. of course, the latest revisions of C introduce some new features not in C++, but nothing really major. if you want good type checking, compile your C code with C++, and fix all the type errors you will get.

> they should simply use c++, like k&r did to compile their example code in their 2nd ed - see preface to book if you don't believe.

So what? And GCC allegedly has been C++ for many years. Please take a look at the repo and tell me why this means anything (besides language wars being a waste of time).

My personal experience with C++ is that I seem to always end up peeling off my nice abstractions again later. Most of what it offers hasn't stuck for me, at least for systems programming. There's a lot of bad C code I've had to work on over the years, but overzealously architected C++ codebases take the crown for inflicting the most pain for sure. One recent experience was when I replaced 4 files and 200 lines of C++ classes with 4 lines of straight C code. Not even a function was necessary. And that was one of the less bad experiences because it was actually possible to fix.

In my most recent attempt to be open-minded about it I've ended up keeping a few short methods, which can be nice for code brevity at the call site, and there is less of a tax about having to come up with naming schemes. But I have otherwise found classes (and in particular methods) to be painful for two reasons: All the procedures operating on the class have to be declared in the class (or as static methods in a friend class, but then they have to be declared there). This includes private methods and is just one more level of annoyance for a small (and debatable) syntactic convenience. It's pretty f***ing bad to have to turn implementation details to the outside (it extends transitively to implementation types used in your private methods etc.), and that is a big reason why C++ projects have infamously longer compile times compared to C projects.

Another problem with methods is that it seems you can't define them as having "static" linkage, at least not with MSVC. I suppose this can increase link times and prevent the compiler from making some optimizations.

One other thing I did was trying to buy more in to RAII, for example doing ref-counting in an automated way. It's another area where I feel I've lost a lot of control over what happens (it's hard to get it right), and my codebase is slowly deteriorating.

Another big problem that I personally see is implicit "this". C++ would already be a much better language without this. It's a bad tradeoff IMO (and Python was right to make it explicit), I can't see a benefit of not typing "this->". It is misleading while reading, and frequently having to change method parameter names just to be able to access both is a real annoyance. (From which code style rules like "m_" prefix arise, which typically don't get followed 100% -- so you'll see locals with m_ and members without it -- and which add two more characters, making the implicit this even more useless).

After a few months I am back to writing simple structs with none of this counter-productive (at least for small teams) access protection, and simple plain functions.

That's only scratching the surface of C++ (it's only about "C with classes" so far). I do know "modern C++" to a degree, and when digging deeper into the trends from the last 1-2 decades it gets much worse. I've been following what the C++ committee is up to these days and it seems they are stubbornly penny-wise but pound-foolish. One recent example -- they have now improved the type inference of "this" !!with an added new syntax!! [0] so you can have "easier" CRTP patterns. Does anyone but the most extreme freaks still understand what actually happens there or is the C++ audience mostly an army of copy&paste coders?

As a proficient C programmer, it's so much easier to be annoyed about most of C++'s features, because they break so quickly when put under stress, and just being a bit more explicit with C-style code seems to often lead to more maintainable code and actually not that much more code, sometimes even less (not having to deal with all the crazy abstractions).

That all said, throwing in the occasional templated function or class for good measure can be incredibly powerful, much better than dozens or hundreds of lines of C macro generator hacks. It can be useful also when working with IDEs. But it's a slippery slope and mastering it is hard.

[0] https://www.sandordargo.com/blog/2022/02/16/deducing-this-cp... . There is also a youtube video somewhere.

Re: The Development of the C Language (1993)

#253
post #207

My career is in full stack web development but I program in C in my master's degree coursework and as a hobby. Every time I have to peel back a decade's worth of CSS to move a button on a webapp I daydream of moving to a career in C. Is the grass actually greener on the other side?

Im currently working on a large scale commercial app in C. You have to be very careful with memory and safety, but overall it's so much better than writing apps in JavaScript, Java, or any other language I can think of.

Re: The Development of the C Language (1993)

#254

Earlier quoted context omitted.

they should simply use c++, like k&r did to compile their example code in their 2nd ed - see preface to book if you don't believe. i will never understand why C programmers get so upset about C++. of course, the latest revisions of C introduce some new features not in C++, but nothing really major. if you want good type checking, compile your C code with C++, and fix all the type errors you will get.

> they should simply use c++, like k&r did to compile their example code in their 2nd ed - see preface to book if you don't believe. So what? And GCC allegedly has been C++ for many years. Please take a look at the repo and tell me why this means anything (besides language wars being a waste of time). My personal experience with C++ is that I seem to always end up peeling off my nice abstractions again later. Most of…

my point was that k&r used c++ for it superior type checking (and because the C++ compiler could actually compile C89 code, which no commercial compuilers at the time could) - obviously in a book about C they did not use C++ features. so i am not sure what you are going on about here.

i learned assembler and fortran, then abandoned them for C, and then abondoned C for C++. i did all that progression because it self-evidentially made me more productive.

Re: The Development of the C Language (1993)

#255

Earlier quoted context omitted.

> they should simply use c++, like k&r did to compile their example code in their 2nd ed - see preface to book if you don't believe. So what? And GCC allegedly has been C++ for many years. Please take a look at the repo and tell me why this means anything (besides language wars being a waste of time). My personal experience with C++ is that I seem to always end up peeling off my nice abstractions again later. Most of…

my point was that k&r used c++ for it superior type checking (and because the C++ compiler could actually compile C89 code, which no commercial compuilers at the time could) - obviously in a book about C they did not use C++ features. so i am not sure what you are going on about here. i learned assembler and fortran, then abandoned them for C, and then abondoned C for C++. i did all that progression because it self-e…

Couldn't care less about the type checking differences (apart from using abstract classes with virtual methods, but that's not C syntax), they're quite small and the C++ way is in fact an annoyance e.g. when interfacing with straightforward void pointer APIs. That reminds me of enum class, another feature that brings something nice to the table (properly scoped enum names for better IDE completion) but is almost made unusable by the fact that they can't be easily used with bitwise operators.

The thing about C++ is that many of its features start with a good intention, but most of them are so specific that they have to go down one almost arbitrary route (non-orthogonal decisions, like enum class introducing at least 3 changes at once) and pessimize the other use cases. Good luck refactoring your codebase when you realize you have to change your approach and it's no longer supported by any kind of specialized syntax. That's a problem that C mostly doesn't have -- most of its features are needed when programming a computer, and they're minimal and orthogonal, with few ways to paint yourself in a corner.

Re: The Development of the C Language (1993)

#256
post #23

Earlier quoted context omitted.

Not the commenter you're replying to, but I suspect what they mean is that the C memory model is byte-addressable not bit-addressable. You can't point/refer to a specific bit in memory, instead you have to first read the byte and then select an individual bit using bitwise operations, much like most modern processors.

That has nothing to do with the C memory model, but how the CPU is structured. No modern CPU has an interface for bit-address accessing as far as I am aware... C makes no assumptions about the size of a byte

If I remember correctly, it assumes the size of a char is greater than or equal to seven bits, and a char is defined to be the smallest addressable unit.

C does not support bit-addressing.

Re: The Development of the C Language (1993)

#257
post #207

My career is in full stack web development but I program in C in my master's degree coursework and as a hobby. Every time I have to peel back a decade's worth of CSS to move a button on a webapp I daydream of moving to a career in C. Is the grass actually greener on the other side?

Depends on how much you would appreciate to do GUIs in C, Win32, Motif, X Athena Widget, GadTools, GEM, Gtk 4,...

You would appreciate that webapp buttom.

Re: The Development of the C Language (1993)

#258
post #70

Earlier quoted context omitted.

> C is full of quirks. From cryptic "undefined behaviors" to a type system that isn't really a type system (more like "size hints for the compiler"), the language doesn't feel easy to use/debug. I guess because I just don't agree with this viewpoint at all. I've been writing C on and off for over 20 years now and I simply haven't encountered the amount of distress and pain that I see others deal with, especially when…

Adding that anything I wrote in C++/MFC at that time is now obsolete. Everything I wrote in C/Win32 is as much fresh as it had been 30 years back.

While I undertstand the sentiment, MFC is still being maintained, and is in fact still the only C++ GUI framework worth using, being shipped in Visual Studio latest (2022).

Re: The Development of the C Language (1993)

#259
post #12
post #6

People who still write C, honest question: Why? C is full of quirks. From cryptic "undefined behaviors" to a type system that isn't really a type system (more like "size hints for the compiler"), the language doesn't feel easy to use/debug. Add to this CPP macros, a universally recognized bad idea, a clunky import system, and lack of a single reference implementation of the compiler/libC, and you have a language that…

Because everything speaks C. If you write a library in C, it can be easily exposed to a variety of high-level languages and platforms. You might argue this is more a property of the C ABI than of C itself, but unless the project is large enough that it's worth doing it in C++ or Rust instead, it's still a very reasonable choice. Also not everything is web. Sure, if you're writing API endpoints in C you're just shooti…

Mainframe and micros computers don't speak C, unless we constrain ourselves to their UNIX environment.

ChromeOS doesn't speak C, unless you mean shipping WASM libraries. (Not every Chromebook supports exposing the Linux environment).

iOS and Android, kind of speak C, but not if you care to actually ship an app.

Re: The Development of the C Language (1993)

#260

Earlier quoted context omitted.

I use C for microcontrollers. I think Rust is making some inroads, but the libraries/tooling is not there yet.

neither does the IDE tools I feel, it's going to take a while, and Rust has been here for 17 years.

IDE tools like what? LSPs for Rust are on par / better than that of C/C++, partially because of language being stricter, no #include nonsense etc. Unlike C/C++, sane build system and dependency management system that are universally agreed upon actually exist. What exactly is "going take a while"?
Post reply on HN