Hacker News Reader

Comment by wolfspaw | Hacker News Reader

C evolves, even if slowly.

I think some devs are fed up of Complexity and excessive abstractions.

C has very few language features, it's a very simple language -- while all modern languages have new (complex and taxing) features.

It's kinda like a Minimalist movement, can we do the same Modern Mumbo Jumbo but in a simple, minimalistic C way?

GC and RAII? Nah, just use Arenas/Pools. Or don't use heap at all.

C is an unsafe language but modern tools get better and better every year, with GCC doing really cool static analysis and finding buffer overflows at compile time.

Also, C runs anywhere and everywhere.

View on HN

Anyone who thinks C is simple is just aiming the gun at their foot. If you want simple, you want something like Scheme.

See e.g. wonderfully named "A Simple, Possibly Correct LR Parser for C11" [0], specifically the opening discussion of the ambiguities in the C grammar. Never mind the semantics, which are quite divorced from the underlying hardware! I mean, PDP-11 had a carry flag, a double-wide multiplication instruction, a combined divide-with-remainder instruction (just as x86 does) yet those are unexposed in C.

[0] https://hal.science/hal-01633123/document

I think parent means simple as in the language has very few facilities and the ones it gives you are very barebones (hence simple). C is simple in the sense that a screwdriver is simple compared to a power tool.

It doesn't mean that it is simple to use correctly. An expert might be able to accurately judge the torque achieved by hand, but a beginner can easily under- or over-torque things. Etc...

Yes, but maybe I want to shoot myself in the foot or am willing to take the risk, it's my computer and nobody can tell me what to do with it. That's why I like C. I've been writing Python for almost two decades now, all the new languages are trying even more to tell me how to do things or that I'm doing them wrong, screw that, I don't want to be coddled or patronised by the language I'm using, I'm writing C.

Frankly this is why I have trouble taking all this C advocacy seriously. Do managers really want their engineers using C? I understand how it can be pleasurable in the way that listening to vinyl is pleasureable. But my undersanding is that it takes years and years of experience to not make catastrophic errors in C. And that's a lot of risk.

> Nah, just use Arenas/Pools. Or don't use heap at all.

This will solve more than 90% of problems. I'll also add that replace C pointers with a "Fat Pointer" or Go-like slice struct and avoid the C stdlib. Then you'll have fixed 99% of issues.

Custom allocators are pretty useful, yes. And slices, although it would be nice to have an easy syntax for using them.

Still have null pointers though. So an optional type would be useful too. Billion dollar mistake and all. Oh, and you have to check errno, might want a better way to handle errors so that you have to check them, or at least acknowledge that they exist. Probably need a linter to make those stick, you really do want violating a nullability constraint to fail at compile time.

And yeah, you have to avoid libc now, but it has so much useful stuff! So we'd want a library that offers all that useful stuff, but uses our fancy custom allocators, and optionals, and error checks, and slices.

While we're dreaming, wouldn't namespaces be nice? Like you have a function do_bar on a struct Foo type, so there's this foo_do_bar function (almost like a method), it'd be nice to be able to just say foo.do_bar, y'know?

Of course, at that point, you've almost got a whole different language! But it can compile and link with C, so yeah, best of both worlds.

What if I told you...

Err.. Why does one need to even use a different language to implement Arenas and Slices? Yes having syntax level support for them would indeed be nice (something like new languages like Odin and Zig are trying) but you can start using them today and make programming in C an order of magnitude better.

Reply on news.ycombinator.com