3 ms·

> the fatal error was not combining the array dimension with the array pointer; all it needs is a little new syntax a[...]; this won’t fix any existing code. Ov

> the fatal error was not combining the array dimension with the array pointer; all it needs is a little new syntax a[...]; this won’t fix any existing code. Over time, the syntax a[] can be deprecated by convention and by compilers. You're thinking in decades. C standard committee is slower than that. This could have worked in practice, but probably never will happen in practice. Maybe people should start considering a language like D[1] as an alternative, which seems to have the spirit of both C and Go, but with much more pragmatism than either. [1] https://en.wikipedia.org/wiki/D_(programming_language)#Critique https://en.wikipedia.org/wiki/D_(programming_language)#Criti...

billforsternz 9mo ago
There is some irony in someone replying to the author of the D language suggesting that maybe the D language is the real solution he's looking for.
- I_am_uncreative 9mo ago
  A tale as old as time.
- publicdebates 9mo ago
  It might be the language he is looking for, but it might not, and more likely than not is not. D is one of those odd languages which most likely ought to have gotten a lot more popular than it did, but for one reason or another, never quite caught on. Perhaps one reason is because it lacks a sense of eccentricity and novelty that other languages in its weight class have. Or perhaps it's just too unfamiliar in all the wrong ways. Whatever the case may be, popularity is in fact one of the most useful metrics when ruling out a potential language for a new project. And if D does not meet GP's requirements in terms of longevity or commercial support, I would certainly not suggest GP adopt it too eagerly, simply because it happens to check off most or all their technological requirements.
  - RickHull 9mo ago
    I think that D meets Walter Bright's requirements.
    - BeetleB 9mo ago
      I would hope so. He invented the damn language.
      - WalterBright 9mo ago
        There's always room for improvement!
  - WalterBright 9mo ago
    D is an elegant re-imagine of C and C++. For a trivial example, typedef struct S { int a; } S; becomes simply: struct S { int a; } and unlike C: extern int foo(); int bar() { return foo(); } int foo() { return 6; } you have: int bar() { return foo(); } int foo() { return 6; } For more complex things: #include <foo.h> becomes: import foo;
    - hardlianotion 9mo ago
      Everything except the import looks like standard c++ since at least 98.
      - WalterBright 9mo ago
        C++ does not allow forward references outside of structs. The point-of-instantiation and point-of-declaration rules for templates produces all kinds of subtle problems. D does not have that issue. Yes, you absolutely can get the job done with C and C++. But neither is an elegant language, and that puts a cognitive drag on writing and understanding code.
    - publicdebates 9mo ago
      Smoe of these are definitely nice-to-haves*, but when you're evaluating a C++ alternative, there are higher priority features to research first. How are the build times? What does its package system(s) look like, and how populated are they? What are all its memory management options? How does it do error handling and what does that look like in real world code? Does it have any memory safety features, and what are their devtime/comptime/runtime costs? Does it let me participate in compile time optimizations or computations? Don't get me wrong, we're on the same page about wanting to find a language that fills the C++ niche, even if it will never be as ideal as C++ in some areas (since C++ is significantly worse in other areas, so it's a fair trade off). But just like dating, I'm imagining the fights I'll have with the compiler 3 months into a full time project, not the benefits I'll get in the first 3 days. * (a) I've been using structs without typedef without issue lately, which has its own benefits such as clarifying whether the type is simple or aggregate in param lists, while auto removes the noise in function bodies. (b) Not needing forward declarations is convenient, but afaik it can't not increase compile times at least somewhat. (c) I like the consistency here, but that's merely a principle; I don't see any practical benefit.
- WalterBright 9mo ago
  > maybe the D language is the real solution he's looking for Yes, I realized that after not finding any 'droids.
WalterBright 9mo ago
The C committee is not afraid to add new syntax. And this is an easy addition. Not only does it deliver a massive safety improvement, it dramatically speeds up strlen, strcmp, strcpy, strcat, etc. And you can pick out a substring without needing to allocate/copy. It's easy money.
pjmlp 9mo ago
The C standard committee even refused Dennis Ritchie proposal for fat pointers. https://www.nokia.com/bell-labs/about/dennis-m-ritchie/vararray.html https://www.nokia.com/bell-labs/about/dennis-m-ritchie/varar... Meanwhile after UNIX was done at AT&T, the C language authors hardly cared for the C standard committee in regards to the C compiler supported features used in Plan 9 and Inferno, being only "mostly" compatible, followed up having a authoring role in Alef, Limbo and Go. > The language accepted by the compilers is the core ANSI C language with some modest extensions, a greatly simplified preprocessor, a smaller library that includes system calls and related facilities, and a completely different structure for include files. https://doc.cat-v.org/plan_9/4th_edition/papers/comp https://doc.cat-v.org/plan_9/4th_edition/papers/comp I doubt most C advocates ever reflect on this.
- lelanthran 9mo ago
  > Meanwhile after UNIX was done at AT&T, the C language authors hardly cared for the C standard committee in regards to the C compiler supported features used in Plan 9 and Inferno, being only "mostly" compatible, followed up having a authoring role in Alef, Limbo and Go. > I doubt most C advocates ever reflect on this. What would be the conclusion of this reflection? Assuming you have reflected on this, what was your conclusion?
  - pjmlp 9mo ago
    That the language authors concluded C was done, there was no point collaborating with WG14, and there were better tools to do their operating systems research on.
    - AlexeyBrin 9mo ago
      > there were better tools to do their operating systems research on. I think that's the key, Ritchie, Thompson, Pike were interested in OS research while people that love C today just want a simple and powerful language with manual memory management. It is not the first time in history when the creation has a separate life from the creator's wishes.
JamesTRexx 9mo ago
As I see it, the problem with languages trying to replace C is that they not only try to fix fundamental flaws, but feel compelled to add unneeded features and break C's simplicity.
- WalterBright 9mo ago
  C is a simple language, but that simplicity leads to non-portable code and lots of klunky, ugly things like using the preprocessor as a substitute for conditional compilation, imports, lambdas, metaprogramming, etc. You don't have to use unneeded features that are in D. The core language is as simple as C, to the point where it is easy to translate C to D (in fact, the compiler will do it for you!).
  - JamesTRexx 9mo ago
    "lots of klunky, ugly things" I wonder how much of that is caused by too complex thinking. It seems that simplicity is very difficult for most people. "You don't have to use unneeded features" True, but that doesn't work in practice, for example the intentions to use only limited C++ features in new projects, that end up bogged down with the other features anyway because of "new toy to play with" effect. What isn't there can't be used and keeps the language lean and clean (and not mean ;-) ).
    - WalterBright 9mo ago
      I agree that often programmers are tempted to use features "just because they are there". We've introduced the notion of "editions" in D lately, and its purpose is to remove features that have not proved their value over time.
- 1718627440 9mo ago
  Also they leave a important point of C behind: backward-compatibility.
  - WalterBright 9mo ago

billforsternz 9mo ago

There is some irony in someone replying to the author of the D language suggesting that maybe the D language is the real solution he's looking for.

I_am_uncreative 9mo ago
A tale as old as time.
publicdebates 9mo ago
It might be the language he is looking for, but it might not, and more likely than not is not. D is one of those odd languages which most likely ought to have gotten a lot more popular than it did, but for one reason or another, never quite caught on. Perhaps one reason is because it lacks a sense of eccentricity and novelty that other languages in its weight class have. Or perhaps it's just too unfamiliar in all the wrong ways. Whatever the case may be, popularity is in fact one of the most useful metrics when ruling out a potential language for a new project. And if D does not meet GP's requirements in terms of longevity or commercial support, I would certainly not suggest GP adopt it too eagerly, simply because it happens to check off most or all their technological requirements.
- RickHull 9mo ago
  I think that D meets Walter Bright's requirements.
  - BeetleB 9mo ago
    I would hope so. He invented the damn language.
    - WalterBright 9mo ago
      There's always room for improvement!
- WalterBright 9mo ago
  D is an elegant re-imagine of C and C++. For a trivial example, typedef struct S { int a; } S; becomes simply: struct S { int a; } and unlike C: extern int foo(); int bar() { return foo(); } int foo() { return 6; } you have: int bar() { return foo(); } int foo() { return 6; } For more complex things: #include <foo.h> becomes: import foo;
  - hardlianotion 9mo ago
    Everything except the import looks like standard c++ since at least 98.
    - WalterBright 9mo ago
      C++ does not allow forward references outside of structs. The point-of-instantiation and point-of-declaration rules for templates produces all kinds of subtle problems. D does not have that issue. Yes, you absolutely can get the job done with C and C++. But neither is an elegant language, and that puts a cognitive drag on writing and understanding code.
  - publicdebates 9mo ago
    Smoe of these are definitely nice-to-haves*, but when you're evaluating a C++ alternative, there are higher priority features to research first. How are the build times? What does its package system(s) look like, and how populated are they? What are all its memory management options? How does it do error handling and what does that look like in real world code? Does it have any memory safety features, and what are their devtime/comptime/runtime costs? Does it let me participate in compile time optimizations or computations? Don't get me wrong, we're on the same page about wanting to find a language that fills the C++ niche, even if it will never be as ideal as C++ in some areas (since C++ is significantly worse in other areas, so it's a fair trade off). But just like dating, I'm imagining the fights I'll have with the compiler 3 months into a full time project, not the benefits I'll get in the first 3 days. * (a) I've been using structs without typedef without issue lately, which has its own benefits such as clarifying whether the type is simple or aggregate in param lists, while auto removes the noise in function bodies. (b) Not needing forward declarations is convenient, but afaik it can't not increase compile times at least somewhat. (c) I like the consistency here, but that's merely a principle; I don't see any practical benefit.
WalterBright 9mo ago
> maybe the D language is the real solution he's looking for Yes, I realized that after not finding any 'droids.

WalterBright 9mo ago

The C committee is not afraid to add new syntax. And this is an easy addition. Not only does it deliver a massive safety improvement, it dramatically speeds up strlen, strcmp, strcpy, strcat, etc. And you can pick out a substring without needing to allocate/copy. It's easy money.

pjmlp 9mo ago

The C standard committee even refused Dennis Ritchie proposal for fat pointers. https://www.nokia.com/bell-labs/about/dennis-m-ritchie/vararray.html https://www.nokia.com/bell-labs/about/dennis-m-ritchie/varar... Meanwhile after UNIX was done at AT&T, the C language authors hardly cared for the C standard committee in regards to the C compiler supported features used in Plan 9 and Inferno, being only "mostly" compatible, followed up having a authoring role in Alef, Limbo and Go. > The language accepted by the compilers is the core ANSI C language with some modest extensions, a greatly simplified preprocessor, a smaller library that includes system calls and related facilities, and a completely different structure for include files. https://doc.cat-v.org/plan_9/4th_edition/papers/comp https://doc.cat-v.org/plan_9/4th_edition/papers/comp I doubt most C advocates ever reflect on this.

lelanthran 9mo ago
> Meanwhile after UNIX was done at AT&T, the C language authors hardly cared for the C standard committee in regards to the C compiler supported features used in Plan 9 and Inferno, being only "mostly" compatible, followed up having a authoring role in Alef, Limbo and Go. > I doubt most C advocates ever reflect on this. What would be the conclusion of this reflection? Assuming you have reflected on this, what was your conclusion?
- pjmlp 9mo ago
  That the language authors concluded C was done, there was no point collaborating with WG14, and there were better tools to do their operating systems research on.
  - AlexeyBrin 9mo ago
    > there were better tools to do their operating systems research on. I think that's the key, Ritchie, Thompson, Pike were interested in OS research while people that love C today just want a simple and powerful language with manual memory management. It is not the first time in history when the creation has a separate life from the creator's wishes.

JamesTRexx 9mo ago

As I see it, the problem with languages trying to replace C is that they not only try to fix fundamental flaws, but feel compelled to add unneeded features and break C's simplicity.

WalterBright 9mo ago
C is a simple language, but that simplicity leads to non-portable code and lots of klunky, ugly things like using the preprocessor as a substitute for conditional compilation, imports, lambdas, metaprogramming, etc. You don't have to use unneeded features that are in D. The core language is as simple as C, to the point where it is easy to translate C to D (in fact, the compiler will do it for you!).
- JamesTRexx 9mo ago
  "lots of klunky, ugly things" I wonder how much of that is caused by too complex thinking. It seems that simplicity is very difficult for most people. "You don't have to use unneeded features" True, but that doesn't work in practice, for example the intentions to use only limited C++ features in new projects, that end up bogged down with the other features anyway because of "new toy to play with" effect. What isn't there can't be used and keeps the language lean and clean (and not mean ;-) ).
  - WalterBright 9mo ago
    I agree that often programmers are tempted to use features "just because they are there". We've introduced the notion of "editions" in D lately, and its purpose is to remove features that have not proved their value over time.
1718627440 9mo ago
Also they leave a important point of C behind: backward-compatibility.
- WalterBright 9mo ago