4 ms·

I miss the simple days of just regular K&R and a decent lint. c was suppose to be a nice small simple language, but each standard adds more and more complexity

by jmclnx 4y ago

I miss the simple days of just regular K&R and a decent lint. c was suppose to be a nice small simple language, but each standard adds more and more complexity.

baq 4y ago
gcc -std=c89 still works
- ape4 4y ago
  Or you can chose to use the only the modern subset. eg only nullptr and never NULL.
  - josephg 4y ago
    Sure; but you’ll need to learn all those other features if you want to read other people’s code. I was adamantly against Javascript adding OO-style classes and public/private methods and stuff for that reason. More stuff in the language makes it strictly harder to learn. Even if I don’t want to use those language features myself, I will inevitably end up reading and debugging other people’s code which does use those features. So I still need to learn it all, even if I don’t ever see myself using that stuff.
jvanderbot 4y ago
What we need is a good old wave of deprecation. Re-simplify around a slightly more modern syntax.
pmarin 4y ago
Many people still write in a C89 dialect just fine. Most of the good stuff is written in it: sqlite, curl, STB libraries, zlib, OS kernels etc.
- jmclnx 4y ago
  Yes, that is what I stick to also, and that is better for portability.
- sylware 4y ago
  C syntax is already too rich and complex. What it needs is not more but less and some fixing: Only sized primitive types (u8/s8...u64/s64, f32/f64); typedef, enum, switch, all but one loop keyword (loop{}) should go away; No more integer promotion, only compile-time/runtime explicit casts (except for literals, and maybe void * pointers); explicit compile-time constants; no anonymous code block; etc. That said, if risc-v is successful, many components will be written directly in assembly, and trash-abl code will be written in very high-level languages with risc-v assembly written interpreters (python/perl5/lua/javascript/ruby/php/haskell/tintin/milou).
  - klodolph 4y ago
    The variable-size int, unfortunately, made a lot of sense in the early days of C. On processors like the x86 and 68000, it made sense for int to be 16-bit, so you don't pay for the bits you don't need. On newer systems, it makes sense for int to be 32-bit, so you don't pay to throw away bits.
    - sylware 4y ago
      That's why it needs fixing. We are not in the early days anymore.
      - klodolph 4y ago
        Problem is simple—there are still systems out there like that, and people are still buying them and writing C code for them. They're just in the embedded space, where day-to-day programmers don't encounter them.
        sylware 4y ago
        Then those systems are maintained, then then could correct their legacy C code to "fixed-C" (which should be not that much in-real-life anyways). It would be possible to do a quick-and-dirty work with preprocessor definitions. The real thing is when you want to write "fixed-C" with a legacy compiler: you realize than it does so much things without telling you, you would need a really accurate warning system in order to catch all those things. I was told gcc can report all integer promotions, true?
- tlamponi 4y ago
  > OS kernels Many are, but Linux moved to C11 (well gnu11 I guess) since v5.18 Summary of discussion: https://lwn.net/Articles/885941/ https://lwn.net/Articles/885941/ Actual move https://git.kernel.org/linus/e8c07082a810fbb9db303a2b66b66b8d7e588b53 https://git.kernel.org/linus/e8c07082a810fbb9db303a2b66b66b8... Being able to replace int i; for (i = 0; i < foo; i++) { ... } with for (int i = 0; i < foo; i++) { ... } makes it already worthwhile. Linus thinks so too: > I think the loop iterators are the biggest user-visible thing, but > there might be others. Also interesting: > Of course, the C standard being the bunch of incompetents they are, > they in the process apparently made left-shifts undefined (rather than > implementation-defined). Christ, they keep on making the same mistakes > over and over. What was the definition of insanity again? -- https://lwn.net/ml/linux-kernel/CAHk-=wicJ0VxEmnpb8=TJfkSDytFuf+dvQJj8kFWj0OF2FBZ9w@mail.gmail.com/ https://lwn.net/ml/linux-kernel/CAHk-=wicJ0VxEmnpb8=TJfkSDyt...
  - astrange 4y ago
    > Also interesting: The issues here are: - if it's defined, then people will rely on it, which means UBSan can't report it as an error if it sees it. - IIRC x86 defines the overflow behavior differently for scalar and vector ints, so x86 compilers that want to do autovectorization would probably leave it undefined. C's original sin here is that the numeric promotion rules are wrong ('unsigned short' should not promote to 'int'!) but as long as you can't fix that, you can't get rid of UB and still be performant.
    - uecker 4y ago
      What is wrong with promoting unsigned short to int?
mytailorisrich 4y ago
A "nice small simple" thing implies that someone has the power to say "that's it, we're freezing it the way it is". Instead, usually there is pressure to add, change, 'improve', keep up with the Joneses.
shrimp_emoji 4y ago
Not enough, if you ask me. It's treated mostly like a museum language, like classical music, with some polishing and quality of life improvements (that came 50 years too late, like checked arithmetic).
never_inline 4y ago
I used to think like this. Then I had to use `thread_local` where it was so much more convenient and portable (and likely faster) than pthread_getspecific. I think it's good quality of life features get added and standardized. Even Linux kernel uses lot of GNU extensions. Computers are there to abstract stuff for us.
userbinator 4y ago
IMHO C should remain a language that is easy to write a compiler for (and there have been many examples of individuals doing it, some of which have appeared on HN in the past), i.e. one should be able to "bootstrap" from it.
flohofwoe 4y ago
Oh come on, pure K&R-C is a pain to read and write even for old-school C enthusiasts, and C99 brought some really nice improvements (like compound literals and designated initialization) while not overloading the language with bells and whistles, it's mostly just logical extensions of existing syntax that should have worked to begin with. And C-isms like '= { 0 };' instead of '= { };' never really made a lot of sense.
VyseofArcadia 4y ago
I am starting to see value in fixing a language when you hit 1.0. No more language changes at that point. If you want to change something, it has to be in a library.
stephc_int13 4y ago
I have to disagree here. C++ is becoming more complex and bloated over time. C, on the other hand, is becoming more convenient with almost no bloat or confusing features. C is aging slowly but graciously, in my opinion.
- pajko 4y ago
  Except C23 is going to have a lot of anti-features: https://queue.acm.org/detail.cfm?id=3588242 https://queue.acm.org/detail.cfm?id=3588242
  - uecker 4y ago
    The article is a boring rant with no substance. His main issue seems to be the realloc zero change which he claims breaks idiomatic code. But this is certainly not idiomatic code as it never worked correctly in portable C code, because different implementations did different things for decades with no willingness to change.

by jmclnx 4y ago

I miss the simple days of just regular K&R and a decent lint. c was suppose to be a nice small simple language, but each standard adds more and more complexity.

baq 4y ago

gcc -std=c89 still works

ape4 4y ago
Or you can chose to use the only the modern subset. eg only nullptr and never NULL.
- josephg 4y ago
  Sure; but you’ll need to learn all those other features if you want to read other people’s code. I was adamantly against Javascript adding OO-style classes and public/private methods and stuff for that reason. More stuff in the language makes it strictly harder to learn. Even if I don’t want to use those language features myself, I will inevitably end up reading and debugging other people’s code which does use those features. So I still need to learn it all, even if I don’t ever see myself using that stuff.

jvanderbot 4y ago

What we need is a good old wave of deprecation. Re-simplify around a slightly more modern syntax.

pmarin 4y ago

Many people still write in a C89 dialect just fine. Most of the good stuff is written in it: sqlite, curl, STB libraries, zlib, OS kernels etc.

jmclnx 4y ago
Yes, that is what I stick to also, and that is better for portability.
sylware 4y ago
C syntax is already too rich and complex. What it needs is not more but less and some fixing: Only sized primitive types (u8/s8...u64/s64, f32/f64); typedef, enum, switch, all but one loop keyword (loop{}) should go away; No more integer promotion, only compile-time/runtime explicit casts (except for literals, and maybe void * pointers); explicit compile-time constants; no anonymous code block; etc. That said, if risc-v is successful, many components will be written directly in assembly, and trash-abl code will be written in very high-level languages with risc-v assembly written interpreters (python/perl5/lua/javascript/ruby/php/haskell/tintin/milou).
- klodolph 4y ago
  The variable-size int, unfortunately, made a lot of sense in the early days of C. On processors like the x86 and 68000, it made sense for int to be 16-bit, so you don't pay for the bits you don't need. On newer systems, it makes sense for int to be 32-bit, so you don't pay to throw away bits.
  - sylware 4y ago
    That's why it needs fixing. We are not in the early days anymore.
    - klodolph 4y ago
      Problem is simple—there are still systems out there like that, and people are still buying them and writing C code for them. They're just in the embedded space, where day-to-day programmers don't encounter them.
      - sylware 4y ago
        Then those systems are maintained, then then could correct their legacy C code to "fixed-C" (which should be not that much in-real-life anyways). It would be possible to do a quick-and-dirty work with preprocessor definitions. The real thing is when you want to write "fixed-C" with a legacy compiler: you realize than it does so much things without telling you, you would need a really accurate warning system in order to catch all those things. I was told gcc can report all integer promotions, true?
tlamponi 4y ago
> OS kernels Many are, but Linux moved to C11 (well gnu11 I guess) since v5.18 Summary of discussion: https://lwn.net/Articles/885941/ https://lwn.net/Articles/885941/ Actual move https://git.kernel.org/linus/e8c07082a810fbb9db303a2b66b66b8d7e588b53 https://git.kernel.org/linus/e8c07082a810fbb9db303a2b66b66b8... Being able to replace int i; for (i = 0; i < foo; i++) { ... } with for (int i = 0; i < foo; i++) { ... } makes it already worthwhile. Linus thinks so too: > I think the loop iterators are the biggest user-visible thing, but > there might be others. Also interesting: > Of course, the C standard being the bunch of incompetents they are, > they in the process apparently made left-shifts undefined (rather than > implementation-defined). Christ, they keep on making the same mistakes > over and over. What was the definition of insanity again? -- https://lwn.net/ml/linux-kernel/CAHk-=wicJ0VxEmnpb8=TJfkSDytFuf+dvQJj8kFWj0OF2FBZ9w@mail.gmail.com/ https://lwn.net/ml/linux-kernel/CAHk-=wicJ0VxEmnpb8=TJfkSDyt...
- astrange 4y ago
  > Also interesting: The issues here are: - if it's defined, then people will rely on it, which means UBSan can't report it as an error if it sees it. - IIRC x86 defines the overflow behavior differently for scalar and vector ints, so x86 compilers that want to do autovectorization would probably leave it undefined. C's original sin here is that the numeric promotion rules are wrong ('unsigned short' should not promote to 'int'!) but as long as you can't fix that, you can't get rid of UB and still be performant.
  - uecker 4y ago
    What is wrong with promoting unsigned short to int?

mytailorisrich 4y ago

A "nice small simple" thing implies that someone has the power to say "that's it, we're freezing it the way it is". Instead, usually there is pressure to add, change, 'improve', keep up with the Joneses.

shrimp_emoji 4y ago

Not enough, if you ask me. It's treated mostly like a museum language, like classical music, with some polishing and quality of life improvements (that came 50 years too late, like checked arithmetic).

never_inline 4y ago

I used to think like this. Then I had to use `thread_local` where it was so much more convenient and portable (and likely faster) than pthread_getspecific. I think it's good quality of life features get added and standardized. Even Linux kernel uses lot of GNU extensions. Computers are there to abstract stuff for us.

userbinator 4y ago

IMHO C should remain a language that is easy to write a compiler for (and there have been many examples of individuals doing it, some of which have appeared on HN in the past), i.e. one should be able to "bootstrap" from it.

flohofwoe 4y ago

Oh come on, pure K&R-C is a pain to read and write even for old-school C enthusiasts, and C99 brought some really nice improvements (like compound literals and designated initialization) while not overloading the language with bells and whistles, it's mostly just logical extensions of existing syntax that should have worked to begin with. And C-isms like '= { 0 };' instead of '= { };' never really made a lot of sense.

VyseofArcadia 4y ago

I am starting to see value in fixing a language when you hit 1.0. No more language changes at that point. If you want to change something, it has to be in a library.

stephc_int13 4y ago

I have to disagree here. C++ is becoming more complex and bloated over time. C, on the other hand, is becoming more convenient with almost no bloat or confusing features. C is aging slowly but graciously, in my opinion.

pajko 4y ago
Except C23 is going to have a lot of anti-features: https://queue.acm.org/detail.cfm?id=3588242 https://queue.acm.org/detail.cfm?id=3588242
- uecker 4y ago
  The article is a boring rant with no substance. His main issue seems to be the realloc zero change which he claims breaks idiomatic code. But this is certainly not idiomatic code as it never worked correctly in portable C code, because different implementations did different things for decades with no willingness to change.