Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C’s Biggest Mistake (2009)

digitalmars.com

Post reply on HN
Print view View original

371–380 of 382 posts

Re: C’s Biggest Mistake (2009)

#371

Post by moon4u »

dpc_pw wrote: post #220

I love how so many people here argue with the Walter Bright about technical aspects of C. I have been a member of many programming languages communities, and every language has its own culture. C was always a language for the arrogant. "The real programmers" that can handle their memory, not afraid to work with pointers and that can get their code right. I've been there, done that for many years, and became more humb…

> Oh, how they dare argue with WALTER BRIGHT. The hubris!

With all due respect, but if someone says something invalid, the fact that they have authority on a subject does not mean that we should agree.

As far as I understand the article (And I'm not the great Walter Bright, so I may be wrong) - the author states that "void foo(char a[..])" is better syntax than "void foo(size_t s, char a[])" but does not provide any arguments for it. Furthermore, the author initially fails to mention that there has been an attempt to fix the array-to-pointer-decay issue, when discussing "C's Biggest Mistake".

So, yeah, the author may be right that this has been C's biggest mistake. I don't know whether that is true or not, I do not have his experience. It is certainly true that this mistake would be high on rankings of all mistakes that C did. Still, the initial "sleight of hand" move followed by unsubstantiated argument leads to a post with the quality similar to that of a twitter post. Maybe even worse, since, you know, it's posted on a place other than twitter, so we are actually talking about it as if it was something serious.

Re: C’s Biggest Mistake (2009)

#372

Post by IshKebab »

saagarjha wrote: post #272
IshKebab wrote: post #259

Earlier quoted context omitted.

Oh... can you show me those 100+ other languages that have opt-out memory safety, explicit lifetime annotation, a borrow checker and no runtime?

That’s an extremely specific reading of the claim “fix C” that excludes almost everything but Rust.

I never said those are the only ways to fix C. Try reading the argument again:

> What Rust hast brought to the tables was nearly the same what was brought by 100+ other programming languages in attempts to "fix C."

> Oh... can you show me those 100+ other languages that have opt-out memory safety, explicit lifetime annotation, a borrow checker and no runtime?

Maybe I can make it even clearer:

> What Rust has brought to the tables was nearly the same as 100+ other languages

> Oh... can you show me those 100+ other languages that have (some unique Rust features)

Re: C’s Biggest Mistake (2009)

#373

Post by baylessj »

the_hoser wrote: post #235
raverbashing wrote: post #225

Earlier quoted context omitted.

By number of new projects using it (without counting legacy code) Nobody would do a project in C today with Go/Rust/C++ etc unless it's for a very specific situation

Careful with generalizations like that. You're forgetting the most important reason anyone uses a language: It's the one they know. A C programmer isn't automatically going to switch to Rust for new projects that they would use C for, unless their goal is to use Rust.

C is also used a lot in embedded environments where the hardware won't support languages with a larger footprint. Quite common in my line of work.

Re: C’s Biggest Mistake (2009)

#374

Post by enriquto »

WalterBright wrote: post #346
saagarjha wrote: post #276

Earlier quoted context omitted.

> You cannot even use a global variable safely! Sorry? I’m unsure what you mean here, because there are plenty of ways to use globals in ways I would call “safe”: no undefined behavior, correct output, …

In one C file you can declare a global: int x; and in another: int* x; and you'll be mixing pointers and ints and it won't be detected.

I was not talking about this, but about aliasing a variable on the same translation unit.

    int x = 7;
    void f() { /* do things using x */ }
    void insidious_function(int *p) { *p = 3; }
now, inside f you cannot be sure that x equals 7, even if you never write into it. You may call some functions, that in turn call the insidious function that receives the address of x as a parameter. There's no way to be sure that the value of x is not changed, just by looking at your code.

Re: C’s Biggest Mistake (2009)

#375

Post by asveikau »

WalterBright wrote: post #345
asveikau wrote: post #93

Earlier quoted context omitted.

Maybe people are voting this down because they think it's directed at Walter Bright in particular, but I think there is actually some truth in the harsh comment. Nothing about Walter Bright in this statement, but some of the harshest criticisms from others I have seen of C are not from expert practitioners in C. People who are experts and also critics seem to have a more practical, realistic, nuanced critique, that u…

I also have extensive (20 years) experience with the solution I proposed.

Yes I know, and for clarity I appreciate your work and insight, and frequently enjoy your comments here.

My point was that people were mistaking the comment for an attack on you, which I don't think was necessarily intended or needs to be without it being a valid point about a different set of critics.

Re: C’s Biggest Mistake (2009)

#376

Post by jstimpfle »

hvdijk wrote: post #356
jstimpfle wrote: post #308

Earlier quoted context omitted.

To me, the question is what is actually "the type system" and what is "the allocation system" or whatever else aspect of implementing a compiler. So determining the type of "&a" is not an issue, it's just one case in determining the type of a C expression (look up the object "a", is it an array? The type of the expression is a pointer to the array element type). This is not a special case, at least not more special t…

Are you aware that given int a[3];, (&a+1) and (a+3) denote the same address? If you are, how can that possibly work if as you suggest, &a and a are indistinguishable to the compiler, that they are both seen as a pointer to int?

That came quite honestly as a huge surprise to me. I've never seen this before. Thanks for the heads up!

Re: C’s Biggest Mistake (2009)

#377

Post by account42 »

knaq wrote: post #278
saagarjha wrote: post #273

Earlier quoted context omitted.

This would require storing type information in a symbol, would it not? Either via mangling or some other method.

Yes. I proposed a method without mangling, but I suppose there isn't any reason why C couldn't use mangled names. It also isn't a requirement that C++ use mangled names. Other ways of carrying the type information are possible. I like the idea of a reference to DWARF debug info, which C++ is already using to support stack unwinding for exceptions.

> It also isn't a requirement that C++ use mangled names.

Overloading requires the type information to be part of the symbol "name" (ie, whatever is used for symbol lookup and linking) wether that is a mangled string or more complex data structure.

Re: C’s Biggest Mistake (2009)

#378

Post by account42 »

mhh__ wrote: post #40
rightbyte wrote: post #24

Earlier quoted context omitted.

The proposal is just syntactic sugar for an size argument. It doean't add or solve anything really.

It allows automatic bounds checking i.e. I don't need to point out how many bugs that could fix. If you're worried about performance test it and turn it off.

I'm curious what you'd want the automatica bounds checking to do?

Just terminating the program won't be much better than OOB memory access in many cases.

Continuing but discarding OOB writes/use a dummy for OOB reads could lead to much worse behavior.

An exception (or setting errno since this is C) would need that exception to be handled somewhere in a sensible way in which case you could just as easily add manual bounds checking.

Re: C’s Biggest Mistake (2009)

#379

Post by account42 »

ImprobableTruth wrote: post #116
rumanator wrote: post #79

Earlier quoted context omitted.

> I don't see a future where C survives Meanwhile C is running strong since the 70s. > the lack of package manager What do you call linux distro's package managers then? I mean, in distributions like Debian you can even download a package's source code with apt-get.

>What do you call linux distro's package managers then? If you want to count them as package managers, they're by far the worst ones of all the well known languages (with some notable exceptions e.g. guix's and nixos's). They're not portable between distributions or even different versions of the same distribution (!), since it's non-trivial to install older versions of libraries (or, hell, different versions of the…

> If you want to count them as package managers, they're by far the worst ones of all the well known languages (with some notable exceptions e.g. guix's and nixos's).

The have the only feature I care about: cross-language dependency management.

Unless you are suggesting to reimplement everything in each language and then make users install ten different XML parser, SSL implementations, etc. just because not-implemented-in-my-favorite-language syndrome.

Re: C’s Biggest Mistake (2009)

#380

Post by account42 »

leetcrew wrote: post #48
SamReidHughes wrote: post #5

The biggest mistake to me feels like implicit integer conversions. That's where C feels like it's really out to get you.

on a somewhat related note, I've always wished for something like `explicit` that prevents assigning different typedefs for the same underlying type to each other. like suppose I have two types, WorldVec (vector in worldspace) and ViewVec (vector in view/sceenspace). under the hood they are both typedefs for float[3], so I can freely assign them back and forth. but any vector operation that mixes the types would almo…

You can do that in C++ by wrapping he type in a new class although it requires some boilerplate depending on which operators you want to support. [0]

You don't have to use all features of C++ - if you prefer a more C like style you can have that.

[0] https://www.boost.org/doc/libs/1_48_0/boost/strong_typedef.h...

Post reply on HN