C's memory model requires shared invisible invariants that can't be encoded in the type system or signatures. This makes C code incredibly fragile.
Why I Always End Up Going Back to C
41–50 of 76 posts
Re: Why I Always End Up Going Back to C
#42Returning to C after a decade away, I think the bottom line is that the reason why C has stuck around for so long is straight up path dependence. C is the foundation of Unix, and Unix-like operating systems took over the world, and C is a decent enough systems programming language that people started using it to write other OSes as well. It bothers me that there’s some kind of mysticism around C. I keep seeing weird…
C's memory model made (some) sense when computers were very slow and mostly isolated but it is a complete disaster for code connected to the internet.
Re: Why I Always End Up Going Back to C
#43Earlier quoted context omitted.
You mean, you are not worried about high complexity of codebase because you work with it every day for decades, so you know all this complexity by heart? This basically requires one to be working solo, neither receiving not sharing the source code with others, treating third-party libraries as blackboxes. I guess this can work for some people, but I don't think it would work for everyone.
> so you know all this complexity by heart? No. It's that you've built up a personal database of libraries, best-practices, idioms, et al. over decades. When you move on to a new project, this personal database comes with you. You don't need to wonder if version X of Y framework or library has suddenly changed and then spend a ton of time studying its differences. Of course, the response to this is: "You can do this…
I don't see how this can work.
You have your personal string library.. and you move to a new project, and it has it's own string library (it's pretty much given, because stdlib C library sucks). So what next? Do you rewrite the entire project into _your_ string library, and enjoy familiar environment, until the next "experienced C programmer" comes along? Or do you give up on your own string library and start learning whatever project uses?
And this applies to basically everything. The "personal database" becomes pretty useless the moment the second person with such database joins the project.
(This is a big part of Python's popularity, IMHO. Maybe "str" and "logger" are not the best string and logger classes in the world, but they are good enough and in stdlib, so you never have to learn them when you start a new project)
Re: Why I Always End Up Going Back to C
#44Earlier quoted context omitted.
Linux has libnuma ( https://man7.org/linux/man-pages/man3/numa.3.html ) while Windows has its own NUMA api ( https://learn.microsoft.com/en-us/windows/win32/procthread/n... ) For CPU/OS scheduling, use pthreads/OpenMP apis to set processor affinity for threads. For SIMD, use compiler intrinsics.
Nothing of that is written in pure C, as per ISO C standard. Rather they rely on a mix of C compiler language extensions, inline or external Assembly written helpers functions, which any language compiled language also has available, when going out of the standard goes.
I think you are being nitpicky here.
When most people say "I write in C", they don't mean abstract ISO C standard, with the possibility of CHAR_BIT=9. They mean "C for my machine" - so C with compiler extensions, assumptions about memory model, and yes, occasional inline assembly.
Re: Why I Always End Up Going Back to C
#45Earlier quoted context omitted.
Unfortunately your insightful comment is 30 years too late. You'll have to find a time-machine and go back to the 1990s and tell GNU/GTK/Gnome/etc that they are doing it wrong.
Good luck making any sort of UI without OOP-like methods. The moment you have grouped state (say "button_enabled", "button_shown", and "button_checked") and corresponding methods, you get something OOP-like. The only way to work around is immediate mode UI, but this requires fairly powerful CPU, so it's only feasible on the modern machines. Certainly not something that people would want about 30 years ago, they still…
Immediate mode UI doesn't require a powerful CPU and was invented in 2002, so about 24 years ago. I think the belief that it necessarily sacrifices performance is somewhat of a misconception.
Compare a hypothetical "Immediate Mode" counter:
void render_and_handle_button_click(struct ctx *ctx){
draw_text(ctx, "Count: %d", ctx->count);
if(draw_button(ctx, "Increment")){
ctx->count++;
}
}
void render(struct ctx *ctx){
set_textbox_text(ctx->textbox, "Count: %d", ctx->count);
}
void handle_button_click(void *ctx_in){
struct ctx *ctx = ctx_in;
ctx->count++;
render(ctx);
}
void init(struct ctx *ctx){
ctx->textbox = create_textbox(ctx);
ctx->button = create_button(ctx);
set_button_text(ctx->button, "Increment");
set_button_click_handler(ctx->button, ctx, handle_button_click);
render(ctx);
}
Re: Why I Always End Up Going Back to C
#46I don't think most of the recent essays we're seeing defending C are coming from experienced C veterans, but instead from much younger programmers who were introduced to "The C Way" of doing things by Handmade Hero.
It's surprising the number of people for whom that series appears to have completely rewritten their understanding of programming. It's almost like when someone reads Karl Marx or Richard Dawkins for the first time and finds themselves questioning everything they thought they knew about the world. It's such an outsized impact for such a seemingly straightforward tutorial series.
Re: Why I Always End Up Going Back to C
#47Earlier quoted context omitted.
> You build stuff, and there is so many manual steps "The real goal isn’t to write C once for a one-off project. It’s to write it for decades. To build up a personal ecosystem of practices, libraries, conventions, and tooling that compound over time."
You mean, you are not worried about high complexity of codebase because you work with it every day for decades, so you know all this complexity by heart? This basically requires one to be working solo, neither receiving not sharing the source code with others, treating third-party libraries as blackboxes. I guess this can work for some people, but I don't think it would work for everyone.
> neither receiving not sharing the source code with others, treating third-party libraries as blackboxes.
Tbh, this is an intriguing idea. Determine the size of a library (or module in a bigger system) by what one programmer can manage to build and maintain. Let the public interface be the defining feature of a library, not its implementation.
Re: Why I Always End Up Going Back to C
#48Earlier quoted context omitted.
> so you know all this complexity by heart? No. It's that you've built up a personal database of libraries, best-practices, idioms, et al. over decades. When you move on to a new project, this personal database comes with you. You don't need to wonder if version X of Y framework or library has suddenly changed and then spend a ton of time studying its differences. Of course, the response to this is: "You can do this…
I don't see how this can work. You have your personal string library.. and you move to a new project, and it has it's own string library (it's pretty much given, because stdlib C library sucks). So what next? Do you rewrite the entire project into _your_ string library, and enjoy familiar environment, until the next "experienced C programmer" comes along? Or do you give up on your own string library and start learnin…
It's not the "string library" that's important, but standardized interface types - so that different libraries can pass strings to each other while still being able to select the best string library that matches the project's requirements.
In C this standardized string interface type happens to the poiinter to a zero-terminated bag of bytes, not exactly perfect in hindsight, but as long as everybody agrees to that standard, the actual code working on strings can be replaced with another implementation just fine.
E.g. a minimal stdlib should mostly be concerned about standardized interface types, not about the implementation behind those types.
Re: Why I Always End Up Going Back to C
#49Earlier quoted context omitted.
> It needs to use basic data structures, so it uses GLib. It also need to support runtime-defined connection graph, so it is built on top of GObject. That's running into the age old trap of trying to shoehorn an OOP system into C, just don't do that ;) E.g. don't design your systems around the OOP paradigm in the first place.
You know what gstreamer does, right? It's a dynamic multimedia framework - you give it pipeline defined by string, like: ximagesrc display_name=:1 ! video/x-raw,framerate=20/1 ! videoscale ! videoconvert ! x264enc tune=zerolatency bitrate=500 speed-preset=superfast ! rtph264pay ! udpsink host=127.0.0.1 port=5000 and it automatically loads .so files, creates all those components and connects them to each other. Super…
> and it automatically loads .so files, creates all those components and connects them to each other. Super handy for all sorts of fun audio/video processing.
I created a quite similar OOP system for C around 1995 (as I guess did most programmers at that time who were fascinated by Objective-C), classes were implemented in DLLs and were loaded on demand, classes were objects themselves, the tree of class objects could be inspected (e.g. runtime-type-information and -reflection), and the whole system was serializable - this was for a PC game (https://en.wikipedia.org/wiki/Urban_Assault).
It looked like a neat thing at the time, but nothing a couple of structs with function pointers or a switch-case message dispatcher wouldn't be able to do just as well, definitely not something that should be the base for more than one product, and most definitely nothing that should have survived the OOP hype of the 90's ;)
Re: Why I Always End Up Going Back to C
#50I'm perfectly happy writing C With Classes. There isn't a problem in my domain that can't be solved with C, and frothing at the mouth about "safety" simply isn't relevant. I program machines and I need a language that doesn't do everything possible to hide that fact.
C is a fine language. Sure it's got sharp edges to poke your eyes our and big gears that will rip your arm off, but guess what? So does the machine. Programming a machine is an inherently unsafe activity and you have to act like a responsible adult, not some cargo culting lunatic that wants to purge the world of all code written before 2010.
I'm going back to statically allocating my 2KB of SRAM now. Humbug, etc