← Back to context

Comment by publicdebates

16 hours ago

> 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)#Criti...

24 comments

publicdebates

Reply
billforsternz  15 hours 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.

  • publicdebates  14 hours 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.

    • WalterBright  13 hours 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;

      5 replies →

    • pests  11 hours ago

      I'm sorry, is this an in-joke or satire or something? I can't tell really. Maybe a woosh moment, and as others have said, the GP/person you are speaking about, Walter Bright, is the creator of the D language. Maybe you didn't read your parent's post? Not saying its intentional, but it almost seems rude to keep speaking in that way about someone present in the conversation.

pjmlp  11 hours ago

The C standard committee even refused Dennis Ritchie proposal for fat pointers.

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

I doubt most C advocates ever reflect on this.

  • lelanthran  11 hours 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  8 hours 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.

      1 reply →

WalterBright  14 hours 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.

JamesTRexx  8 hours 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  23 minutes 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!).