4 ms·

If I could change C, I would look closely at Go. To be more precise, I would - Quit separating definition and implementation (.h & .c vs. the singular .go) -

by EFruit 11y ago

If I could change C, I would look closely at Go. To be more precise, I would - Quit separating definition and implementation (.h & .c vs. the singular .go) - Implement multiple returns - Replace #include with something a bit closer to Go's import (Package name and in-body identifier are decoupled) - Methods on any user-defined type - Finally, something namespace-like because library_thing_return_t *library_thing_doing_something_else(libraty_thing_param_t *in) seems unsustainable to me.

coliveira 11y ago
People who want to program in Go are writing code in Go. People who want to program in C++ are writing code in C++. The C standard should improve the language we have, not try to emulate some other existing language.
- EFruit 11y ago
  Note that I didn't say I want to use Go, nor are all my points taken from Go (namely the namespace feature). I did not mention automatic memory management, I did not say the standard library needs to handle XML, and I still did not advocate that the syntax be so strict.
cyphar 11y ago
.h and .c separation is important for shared libraries (you know, that thing that you can't really do in Go). I would like it if headers had some stronger requirements (since you can put any code in a header, which is quite bad).
- pcwalton 11y ago
  > .h and .c separation is important for shared libraries (you know, that thing that you can't really do in Go). Why are header files necessary for dynamic linking? To name one of dozens of examples, Java has dynamic linking and has no header files.
- xenadu02 11y ago
  > .h and .c separation is important for shared libraries No it isn't. That's a completely orthogonal issue. The compiler is perfectly capable of generating the equivalent of a public header if the implementation has a way to specify visibility.
  - nly 11y ago
    It's a bit more than that. You'd have to compile a lot of fluff in to the ELF. We'd be talking something closer to Windows COM, which allows extracting IDL from a type library.
hvs 11y ago
saying a 40 year-old language that is one of the most widely used "seems unsustainable to me" seems weird.
adrusi 11y ago
I won't comment much on most of those points (they're not my style), but as for the last point you made about long identifiers and namespacing, I used to agree that that was a problem, but now I've changed my position. If you choose a long prefix to disambiguate your library functions, then it gets annoying, but you don't have to use long prefixes. "sdl" and "ao" and "X" and "gtk" are great examples of short vendor prefixes for identifiers. In Go, since you brought it up, you have to reference identifiers from foreign packages with a prefix anyway. Go does let you change the prefix if it would otherwise conflict with your code, but because of syntactical concerns, it's more likely to conflict in the first place. Which brings me to the interesting thing about C's lack of namespacing: it means that global identifiers look the same everywhere. This enables you to safely use grep and sed on global identifiers. It's not 100% foolproof because you can shadow a global with a local, and the identifier could appear in a string or comment, but if you're disciplined with the naming conventions of your globals, it should be very unlikely that a local accidentally shadows a global, and if a global identifier's name appears in a string, or especially in a comment, it's probably actually refering to that identifier. This means that a language design decision turns simple refactoring features from a somewhat complex tool that needs compiler integration into "just use sed".

by EFruit 11y ago

coliveira 11y ago

People who want to program in Go are writing code in Go. People who want to program in C++ are writing code in C++. The C standard should improve the language we have, not try to emulate some other existing language.

EFruit 11y ago
Note that I didn't say I want to use Go, nor are all my points taken from Go (namely the namespace feature). I did not mention automatic memory management, I did not say the standard library needs to handle XML, and I still did not advocate that the syntax be so strict.

cyphar 11y ago

.h and .c separation is important for shared libraries (you know, that thing that you can't really do in Go). I would like it if headers had some stronger requirements (since you can put any code in a header, which is quite bad).

pcwalton 11y ago
> .h and .c separation is important for shared libraries (you know, that thing that you can't really do in Go). Why are header files necessary for dynamic linking? To name one of dozens of examples, Java has dynamic linking and has no header files.
xenadu02 11y ago
> .h and .c separation is important for shared libraries No it isn't. That's a completely orthogonal issue. The compiler is perfectly capable of generating the equivalent of a public header if the implementation has a way to specify visibility.
- nly 11y ago
  It's a bit more than that. You'd have to compile a lot of fluff in to the ELF. We'd be talking something closer to Windows COM, which allows extracting IDL from a type library.

hvs 11y ago

saying a 40 year-old language that is one of the most widely used "seems unsustainable to me" seems weird.

adrusi 11y ago

I won't comment much on most of those points (they're not my style), but as for the last point you made about long identifiers and namespacing, I used to agree that that was a problem, but now I've changed my position. If you choose a long prefix to disambiguate your library functions, then it gets annoying, but you don't have to use long prefixes. "sdl" and "ao" and "X" and "gtk" are great examples of short vendor prefixes for identifiers. In Go, since you brought it up, you have to reference identifiers from foreign packages with a prefix anyway. Go does let you change the prefix if it would otherwise conflict with your code, but because of syntactical concerns, it's more likely to conflict in the first place. Which brings me to the interesting thing about C's lack of namespacing: it means that global identifiers look the same everywhere. This enables you to safely use grep and sed on global identifiers. It's not 100% foolproof because you can shadow a global with a local, and the identifier could appear in a string or comment, but if you're disciplined with the naming conventions of your globals, it should be very unlikely that a local accidentally shadows a global, and if a global identifier's name appears in a string, or especially in a comment, it's probably actually refering to that identifier. This means that a language design decision turns simple refactoring features from a somewhat complex tool that needs compiler integration into "just use sed".