C’s Biggest Mistake (2009) • Hacker News Board

Re: C’s Biggest Mistake (2009)

#101

Post by shakow » Sat, Sep 12, 2020, 11:55 PM UTC

rumanator wrote: post #75

WalterBright wrote: post #59

Earlier quoted context omitted.

I suspect C has been steadily losing ground since I made it.

C has been "losing ground" not because of random per peeves of those who never wrote a line of code in C but because since C's last standard update there have been other programming languages that offer developers something of value so that the trade-off between using C or any alternative starts to make technical sense. It also helps that C's standardization proceeds in ways that feel somewhat between sabotage and ut…

> Meanwhile, C is still the absolute best binary interop language devised by mankind.

You're mistaking the “C” ABI with the C language. The so-called C ABI should actually be called the UNIX-derived ABI, as (i) C doesn't define an ABI and (ii) C can perfectly produce binaries using another ABI (such as e.g. the “Pascal” one, common on the DOS platform).

Re: C’s Biggest Mistake (2009)

#102

Post by mark-r » Sat, Sep 12, 2020, 11:57 PM UTC

pjmlp wrote: post #27

baby wrote: post #17

Earlier quoted context omitted.

I don't see a future where C survives, not only because of memory corruption bugs (although that's a pretty big one), but also for usability: the lack of package manager, common build system, good documentation, good standard library, etc. are just too much to compete with any modern system language.

Unfortunely until we get rid of UNIX/POSIX clones, C will be kept around. So not in my lifetime.

Or at least not in Torvalds' lifetime. His views on replacements for C are legendary. It would be interesting to see his comments on this proposal.

Re: C’s Biggest Mistake (2009)

#103

Post by johnisgood » Sat, Sep 12, 2020, 11:58 PM UTC

blogant wrote: post #34

baby wrote: post #17

Earlier quoted context omitted.

I don't see a future where C survives, not only because of memory corruption bugs (although that's a pretty big one), but also for usability: the lack of package manager, common build system, good documentation, good standard library, etc. are just too much to compete with any modern system language.

> lack of package manager, common build system, good documentation. This is where C is superior to virtually every other language. It has K&R to start with [1], a wealth of examples to progress from there, man pages, autotools, cmake, static and shared libraries. > good standard library. It should have hash tables at least, but it isn't bad. [1] Which is still the best language book ever written (yes, it has some ant…

> It should have hash tables at least

https://man.openbsd.org/ohash_init.3

Re: C’s Biggest Mistake (2009)

#104

Post by makecheck » Sun, Sep 13, 2020, 12:00 AM UTC

Unfortunately working with dynamically-allocated buffers is still a thing; adding array syntax just favors one form of size specification without solving the other case.

Although C is usable on many types of hardware, interesting things could be done, e.g. on desktop OSes if certain hardware-specific extensions were made.

One of the things I wish we could do with our now-absurdly-large pointers (64-bit) is to reserve a handful of bits for other information such as the size. Sure it means we can’t store anything at location 2^64-1 but it wasn’t that long ago we only had 32-bit pointers and the 33rd bit is twice as many addresses all by itself so I think we can lose a few.

For example, if all allocations were rounded up to buckets of a certain size, the precise byte count would not need to be encoded in the pointer (just the number of buckets, requiring fewer bits). There could be a couple bits to give pointers a type for other interesting scenarios, e.g. perhaps a pointer identified as an “immediate value” that isn’t actually allocated at all, and it is “dereferenced” by treating its “address” as the “stored” value. There could even be a couple of bits to track use of common allocators (it would be so nice to simply know that a pointer was allocated by "malloc" vs. "new" for example).

In high-level languages, then, the syntax change would be not to identify arrays specifically but pointers with encodings that are “complete” (e.g. "char const complete*" or something), covering both stack arrays and dynamic buffers.

Re: C’s Biggest Mistake (2009)

#105

Post by WalterBright » Sun, Sep 13, 2020, 12:03 AM UTC

makecheck wrote: post #104

Unfortunately working with dynamically-allocated buffers is still a thing; adding array syntax just favors one form of size specification without solving the other case. Although C is usable on many types of hardware, interesting things could be done, e.g. on desktop OSes if certain hardware-specific extensions were made. One of the things I wish we could do with our now-absurdly-large pointers (64-bit) is to reserve…

> Unfortunately working with dynamically-allocated buffers is still a thing; adding array syntax just favors one form of size specification without solving the other case.

All that is needed is a mechanism for forming a fat pointer from a pointer and a length. In D this looks like:

    int* p = cast(int*)malloc(length * sizeof(int));
    if (!p) fatalError();
    int[] a = p[0 .. length];
    ...
    int x = a[length + 1]; // runtime error: buffer overflow

In C, this could be done via a macro with no additional core language changes.

Re: C’s Biggest Mistake (2009)

#106

Post by josephg » Sun, Sep 13, 2020, 12:03 AM UTC

blogant wrote: post #34

baby wrote: post #17

Earlier quoted context omitted.

I don't see a future where C survives, not only because of memory corruption bugs (although that's a pretty big one), but also for usability: the lack of package manager, common build system, good documentation, good standard library, etc. are just too much to compete with any modern system language.

> lack of package manager, common build system, good documentation. This is where C is superior to virtually every other language. It has K&R to start with [1], a wealth of examples to progress from there, man pages, autotools, cmake, static and shared libraries. > good standard library. It should have hash tables at least, but it isn't bad. [1] Which is still the best language book ever written (yes, it has some ant…

Huh? In what way is C’s books, documentation or build system superior to that found in other languages? Most languages have plenty of good books written about them. And plenty of code examples online. I can’t speak for other languages but I find MDN (Javascript) and the rust docs consistently better than C’s man pages. Ruby’s documentation is great too.

As for build systems, autotools is a hilarious clown car of a disaster. You write a script (automake) to generate a huge, slow script (configure) to generate a makefile to finally invoke gcc? It is shockingly convoluted. It seems more like a code generation art project than something people should use. CMake papers over it about as well as it can, but I think cmake is (maybe by necessity) more complex than some other entire programming languages. In comparison, in rust “cargo build” will build my project correctly on any platform, any time, with usually no effort on my part beyond writing the names and versions of my dependencies in a file.

And as for package management, C is stuck in the 80s. It limps by, but it doesn’t have a package manager as we know them today. There’s no cargo, gems, npm, etc equivalent. Apt is no solution if you want your software to work on multiple distros (which all have their own ideas about versioning). Let alone writing software that builds on windows, Mac and Linux.

So no, C is not superior to other modern languages in its docs, build system or package manager. It is vastly inferior. I still love it. But we’ve gotten much, much better at making tooling in the last few decades. And sadly that innovation hasn’t been ported back to C.

Re: C’s Biggest Mistake (2009)

#107

Post by Cyph0n » Sun, Sep 13, 2020, 12:04 AM UTC

quelsolaar wrote: post #57

franciscop wrote: post #52

This was probably the most confusing thing about C when I first started learning programming back in the day. When you call a function you pass the value, except in arrays where it gets converted as a pointer. It was explained back then to me that the reason is because copying the whole array was not efficient so it was better to pass the reference.

I think a better way to think about is to say that when you type: int a[10]; you allocate 10 integers and "a" is the pointer to the first one of them. Arrays are just memory, just like what you get wen calling malloc, and memory is accessed using pointers in C.

Minor nitpick: there is no allocation going on here - you’re simply reserving a fixed-size buffer on the stack (assuming the array is local to a function).

Re: C’s Biggest Mistake (2009)

#108

Post by ksherlock » Sun, Sep 13, 2020, 12:05 AM UTC

Koshkin wrote: post #66

WalterBright wrote: post #30

Earlier quoted context omitted.

In my experience with language design, a little bit of syntactic sugar can have transformative results. C's function prototypes, syntactic sugar added circa 1990, were transformative for C programming.

I wonder if a better idea (in principle) would be to have some kind of hardware implementation, sort of like a finer-grained memory segmentation.

x86 has a BOUND instruction which generates an exception if an index is out of bounds. It didn't make it into x64.

Re: C’s Biggest Mistake (2009)

#109

Post by SV_BubbleTime » Sun, Sep 13, 2020, 12:06 AM UTC

torstenvl wrote: post #99

SV_BubbleTime wrote: post #92

Earlier quoted context omitted.

Agreed. The proposal is also wasteful. >extern void foo(size_t dim, char *a); And the like assumes that I have the space to waste a native type on every array. So if I’m using a 10 length array, I need to provision a native 32 or 64 bit value for “10”. In embedded system this wouldn’t happen. At least not mine, I’m running up on limits all over the place even being careful with bitfields and appropriately sized types…

So... don't use array syntax in the function prototype and definition? The proposal doesn't PROHIBIT passing a pointer, it would just offer an option to pass a fat array.

I think you mean fat pointer. And yea, that’s nice for people that don’t care their 4bit array has 64bits of native type reserved... I think other people would care.

So, I go back to the idea that it seems unlikely this would ever be an official C change.

Re: C’s Biggest Mistake (2009)

#110

Post by WalterBright » Sun, Sep 13, 2020, 12:08 AM UTC

pritovido wrote: post #94

I actually believe the way C works is great, as simple as it could be and it gives you power to do exactly what you want, they way you want it. I would certainly hate(and would continue using them btw) that they remove normal pointers from C. It would be like removing s expressions from lisp. I believe that the solution to this "mistake" is just not using c directly, using other languages to write C code for you, or…

The proposal does not suggest removing normal pointers from C. D has these dynamic arrays, and normal pointers too. Although one sees pointers used less and less in D code.