3 ms·

I'm sure there are lots and lots of options in the design space here that would have been viable, but for better or worse this is the one we got. I dunno why Pa

I'm sure there are lots and lots of options in the design space here that would have been viable, but for better or worse this is the one we got. I dunno why Pascal didn't happen (but large portions of developers scoffing at the language shouldn't be discounted: this is as much a social consenus building exercise as a purely technical one), but for the "simpler C" versus Rust question it seems to me that there's some kind of local optimum around C, in the sense that the people interested in safety wanted more than is possible with small changes to C and the people who wanted to keep C weren't sufficiently motivated to actually make the changes (Regehr touches on this in the first part of the article, getting any kind of consensus on what Friendly C should actually be turned out to be very hard).

actionfromafar 3y ago
Just adding checked arrays would make a big difference I feel. Maybe it's not too late to change culturally, I think both GCC and LLVM has compile options for that. I also think if Pascal existed with a C syntax front-end, 0-index arrays and ditching the Pascal libraries and going for libc by default, I would probably have switched.
- dannymi 3y ago
  >0-index arrays On each pascal array you specify both bounds. So nothing stops you from doing `array[0..4] of Integer` or whatever.
- arnsholt 3y ago
  I mean, in some sense it's never too late to change? But I do think that as technical people our profession has a strong tendency to underestimate (and undervalue!) the social component of this kind of change. If you have agreement on a path forward, getting it done is mostly a question of elbow grease. The hard part most of the time is getting an agreement on which path to choose out of many mutually exclusive options. And the Linux Rust effort is a good example of this: I think getting agreement that this is good and desireable is at least as hard as the technical work of writing the code. As the LWN article notes, there's been lots of change in this over just the last few years but there's still quite strong resistance it seems.
- ljosifov 3y ago
  This one thing https://digitalmars.com/articles/C-biggest-mistake.html https://digitalmars.com/articles/C-biggest-mistake.html would have helped a lot. Imo given 1) GCC and LLVM have had extensions like that for a long time now, 2) most arrive at that/similar destination at some point (b/c it's so useful), and 3) afaik standardization was supposed to standardize current best/popular practice that is widespread but non-standard (and not invent new untried untested stuff), I think that C standardization committee dropped the ball (and kept dropping it for a very long time) as far as C arrays (and matrices and ndarrays etc) go.
- pjmlp 3y ago
  That would be Zig in a way, Modula-2 (1978) for C folks.
- hnfong 3y ago
  > going for libc by default I understand this isn't relevant to the original discussion since the kernel doesn't use libc, but in userland, the flawed design of libc is as much a liability as the language itself IMHO. For example, maybe you know when to use strcpy(), strncpy(), strlcpy(), memcpy(), but TBH I don't remember the appropriate contexts to use them and I don't write enough C code to warrant actively keep all the nuances in my head.

actionfromafar 3y ago

Just adding checked arrays would make a big difference I feel. Maybe it's not too late to change culturally, I think both GCC and LLVM has compile options for that. I also think if Pascal existed with a C syntax front-end, 0-index arrays and ditching the Pascal libraries and going for libc by default, I would probably have switched.

dannymi 3y ago
>0-index arrays On each pascal array you specify both bounds. So nothing stops you from doing `array[0..4] of Integer` or whatever.
arnsholt 3y ago
I mean, in some sense it's never too late to change? But I do think that as technical people our profession has a strong tendency to underestimate (and undervalue!) the social component of this kind of change. If you have agreement on a path forward, getting it done is mostly a question of elbow grease. The hard part most of the time is getting an agreement on which path to choose out of many mutually exclusive options. And the Linux Rust effort is a good example of this: I think getting agreement that this is good and desireable is at least as hard as the technical work of writing the code. As the LWN article notes, there's been lots of change in this over just the last few years but there's still quite strong resistance it seems.
ljosifov 3y ago
This one thing https://digitalmars.com/articles/C-biggest-mistake.html https://digitalmars.com/articles/C-biggest-mistake.html would have helped a lot. Imo given 1) GCC and LLVM have had extensions like that for a long time now, 2) most arrive at that/similar destination at some point (b/c it's so useful), and 3) afaik standardization was supposed to standardize current best/popular practice that is widespread but non-standard (and not invent new untried untested stuff), I think that C standardization committee dropped the ball (and kept dropping it for a very long time) as far as C arrays (and matrices and ndarrays etc) go.
pjmlp 3y ago
That would be Zig in a way, Modula-2 (1978) for C folks.
hnfong 3y ago
> going for libc by default I understand this isn't relevant to the original discussion since the kernel doesn't use libc, but in userland, the flawed design of libc is as much a liability as the language itself IMHO. For example, maybe you know when to use strcpy(), strncpy(), strlcpy(), memcpy(), but TBH I don't remember the appropriate contexts to use them and I don't write enough C code to warrant actively keep all the nuances in my head.