4 ms·

It's interesting how this works: - enumerate everything C is doing bad. - presents fixes with a full bag of unnecessary features that no c programmer wants.

by kreco 6y ago

It's interesting how this works: - enumerate everything C is doing bad. - presents fixes with a full bag of unnecessary features that no c programmer wants. I wonder why there is no "Fixed C".

WalterBright 6y ago
The trouble is, everyone has a different view of what is unnecessary. Fortunately, you can simply not use any feature you find unnecessary. We won't harangue you about it, I promise! (Well, maybe a little bit if it's so cool we just can't resist.)
pjmlp 6y ago
That is why they are now persona non-grata on Apple, Google and Microsoft platforms. So on Apple platforms they will eventually have to deal with C++ and Swift no matter what. On Microsoft platforms, they complain about C support and get shown the door to C++. And on Google platforms, given the years of ignoring security advices, starting with Android 11, hardware memory tagging is a required feature, with the kernel randomly attaching GWP-ASan to processes, while on ChromeOS Linux gets to run on a hypervisor sandbox.
mhd 6y ago
There have been many, many "Fixed C"'s. That's the problem. This isn't a technology issue, it's a social one.
- kreco 6y ago
  I'm actually curious. until now I came across new language that sells themselves as c replacement but with a lot and lot of new features, usually "here is a new language it does a lot more than C but still compatible with it". examples in top of my head: - adding object oriented feature like built-in constructor/destructor while only default values are needed as week as a defer statement. - weird template, while I can sense that we only want a proper hygienic macro system. And "array type", pointer with length, to deal with contiguous memory. The rest is well described in the video, but those 3 points are my major issues.
  - mhh__ 6y ago
    There's no such thing as a hygienic macro system if you mean textual macros. Also array type is the single biggest thing required to fix C. How many bugs in big C projects are caused by bad indexing and overruns. On top of, "oh no free features".
    - pjmlp 6y ago
      I am hoping that at least Microsoft's Checked C doesn't die like so many other attempts.
    - WalterBright 6y ago
      Here's my proposal for fixing that in C: https://www.digitalmars.com/articles/C-biggest-mistake.html https://www.digitalmars.com/articles/C-biggest-mistake.html
ddevault 6y ago
Sorry to see this at the bottom of the thread, because you have a real point here. None of the attempts at "better C" or even "replacing C" have been serious attempts, and it's frankly getting a bit insulting. No one who still uses C wants its replacements to "catch up" on the past 20 years of new language development. We want C, but without the problems. We don't want D but less so. The response below - "you don't have to use any features if you don't want to!" - is a ridiculous cop-out and the same thing people who defend C++ are saying.
- snazz 6y ago
  While I understand the value in a small language that you can wrap your head around, I think that that is a relatively uncommon problem that real-world language developers shouldn't be catering to today (and C certainly isn't small or simple). These days, programs are simply expected to do more while not suffering from the kinds of security vulnerabilities that C code is so chock-full of. A lot of the solutions for these problems necessitate an increase in complexity. I can understand that "you don't have to use any features if you don't want to" is somewhat silly when talking about C++, since it has so many features that can bite you when you least expect it, especially when dealing with years of legacy code. D is far better designed than C++, however; it would not take you nearly as long to learn enough D to be comfortable reading others' code. All I'm trying to say is that "C, but without the problems" might actually look more like BetterC than you think it does. True zero-cost abstractions are clearly still an unsolved problem, but abstractions are a necessity. C's niche is rapidly disappearing. Also, out of curiosity, what don't you like about Zig? I saw this on your website, but I couldn't find any specific issues you'd had with it. > Wow, Zig is competitive with assembly? > Yeah, I totally had the same reaction. I’m interested to see how it measures up under more typical workloads. People keep asking me what I think about Zig in general, and I think it has potential, but I also have a lot of complaints. It’s not likely to replace C for me, but it might have a place somewhere in my stack.
- kreco 6y ago
  Thanks for your comment. It's pretty normal to face this downvotes when talking about language. And my phrasing was not the most kind of all. It's just the CS community, at some point when you are writing languages you tend to try to outsmart the language you are fixing by creating overly complex behavior. Over-engineering is every single new languages. Even Zig fails to do better than C, I think it's syntactically a disaster. Here is a few lines from the documentation: const ptr = @intToPtr(?*i32, 0x0); while (it.next()) |item| { /* ... */ } pub fn main() anyerror!void { /* ... */ } exe.addCSourceFile("test.c", [_][]const u8{"-std=c99"}); const file = std.fs.cwd().openFile("does_not_exist/foo.txt", .{}) catch |err| label: { /* ... */ }
kllrnohj 6y ago
There are already two very successful "Fixed C"'s in wide usage: C++ & Objective-C. The remaining C usage is a mix of existing domain expertise, existing large codebases impractical to migrate to anything else (eg, Linux), or a rejection of anything more than what C provides. In all of those cases anything that's not exactly C is unlikely to motivate any changes. The users that could change to a "Fixed C" already did decades ago.
jandrese 6y ago
What I wanted: The ability to query heap objects for their size. What I got: some 50,000 foot pure functional typeless language with loads of magic in the compiler that you'll never be able to reason about without having written one yourself.

by kreco 6y ago

It's interesting how this works: - enumerate everything C is doing bad. - presents fixes with a full bag of unnecessary features that no c programmer wants. I wonder why there is no "Fixed C".

WalterBright 6y ago

The trouble is, everyone has a different view of what is unnecessary. Fortunately, you can simply not use any feature you find unnecessary. We won't harangue you about it, I promise! (Well, maybe a little bit if it's so cool we just can't resist.)

pjmlp 6y ago

That is why they are now persona non-grata on Apple, Google and Microsoft platforms. So on Apple platforms they will eventually have to deal with C++ and Swift no matter what. On Microsoft platforms, they complain about C support and get shown the door to C++. And on Google platforms, given the years of ignoring security advices, starting with Android 11, hardware memory tagging is a required feature, with the kernel randomly attaching GWP-ASan to processes, while on ChromeOS Linux gets to run on a hypervisor sandbox.

mhd 6y ago

There have been many, many "Fixed C"'s. That's the problem. This isn't a technology issue, it's a social one.

kreco 6y ago
I'm actually curious. until now I came across new language that sells themselves as c replacement but with a lot and lot of new features, usually "here is a new language it does a lot more than C but still compatible with it". examples in top of my head: - adding object oriented feature like built-in constructor/destructor while only default values are needed as week as a defer statement. - weird template, while I can sense that we only want a proper hygienic macro system. And "array type", pointer with length, to deal with contiguous memory. The rest is well described in the video, but those 3 points are my major issues.
- mhh__ 6y ago
  There's no such thing as a hygienic macro system if you mean textual macros. Also array type is the single biggest thing required to fix C. How many bugs in big C projects are caused by bad indexing and overruns. On top of, "oh no free features".
  - pjmlp 6y ago
    I am hoping that at least Microsoft's Checked C doesn't die like so many other attempts.
  - WalterBright 6y ago
    Here's my proposal for fixing that in C: https://www.digitalmars.com/articles/C-biggest-mistake.html https://www.digitalmars.com/articles/C-biggest-mistake.html

ddevault 6y ago

Sorry to see this at the bottom of the thread, because you have a real point here. None of the attempts at "better C" or even "replacing C" have been serious attempts, and it's frankly getting a bit insulting. No one who still uses C wants its replacements to "catch up" on the past 20 years of new language development. We want C, but without the problems. We don't want D but less so. The response below - "you don't have to use any features if you don't want to!" - is a ridiculous cop-out and the same thing people who defend C++ are saying.

snazz 6y ago
While I understand the value in a small language that you can wrap your head around, I think that that is a relatively uncommon problem that real-world language developers shouldn't be catering to today (and C certainly isn't small or simple). These days, programs are simply expected to do more while not suffering from the kinds of security vulnerabilities that C code is so chock-full of. A lot of the solutions for these problems necessitate an increase in complexity. I can understand that "you don't have to use any features if you don't want to" is somewhat silly when talking about C++, since it has so many features that can bite you when you least expect it, especially when dealing with years of legacy code. D is far better designed than C++, however; it would not take you nearly as long to learn enough D to be comfortable reading others' code. All I'm trying to say is that "C, but without the problems" might actually look more like BetterC than you think it does. True zero-cost abstractions are clearly still an unsolved problem, but abstractions are a necessity. C's niche is rapidly disappearing. Also, out of curiosity, what don't you like about Zig? I saw this on your website, but I couldn't find any specific issues you'd had with it. > Wow, Zig is competitive with assembly? > Yeah, I totally had the same reaction. I’m interested to see how it measures up under more typical workloads. People keep asking me what I think about Zig in general, and I think it has potential, but I also have a lot of complaints. It’s not likely to replace C for me, but it might have a place somewhere in my stack.
kreco 6y ago
Thanks for your comment. It's pretty normal to face this downvotes when talking about language. And my phrasing was not the most kind of all. It's just the CS community, at some point when you are writing languages you tend to try to outsmart the language you are fixing by creating overly complex behavior. Over-engineering is every single new languages. Even Zig fails to do better than C, I think it's syntactically a disaster. Here is a few lines from the documentation: const ptr = @intToPtr(?*i32, 0x0); while (it.next()) |item| { /* ... */ } pub fn main() anyerror!void { /* ... */ } exe.addCSourceFile("test.c", [_][]const u8{"-std=c99"}); const file = std.fs.cwd().openFile("does_not_exist/foo.txt", .{}) catch |err| label: { /* ... */ }

kllrnohj 6y ago

There are already two very successful "Fixed C"'s in wide usage: C++ & Objective-C. The remaining C usage is a mix of existing domain expertise, existing large codebases impractical to migrate to anything else (eg, Linux), or a rejection of anything more than what C provides. In all of those cases anything that's not exactly C is unlikely to motivate any changes. The users that could change to a "Fixed C" already did decades ago.

jandrese 6y ago

What I wanted: The ability to query heap objects for their size. What I got: some 50,000 foot pure functional typeless language with loads of magic in the compiler that you'll never be able to reason about without having written one yourself.