4 ms·

Nice project! It makes me think how awesome it would have been if the C programming language had an actual community around it with package repositories and opi

by tinco 5y ago

Nice project! It makes me think how awesome it would have been if the C programming language had an actual community around it with package repositories and opinions and just actual gradual improvement of everything. Instead of the isolated projects each with their own build systems and styles, and the IRC channels with angry people telling noobs to read K&R.

jll29 5y ago
Your comment reminded me of the early days when I learned C in the mid 1980s, and I complained about the lack of a string type (which I had been used to from Pascal, Modula-2 and even BASIC), people said one should have the freedom to implement them as 0-terminated strings or using length and a char array, or even in other ways. To me that has always been a lame excuse for a poor standard library. You can always build your own, even if the standard library has a solution that works for 99% of cases - and that makes 99% of code more readable to 100% of people. I love C (let's not get into a C++ rant here..) so this is just a comment about the culture, like the parent post. The fact that people who don't like to re-invent the wheel have not stuck with C, and maybe gone to join the Perl, Python, Java... communities made this issue worse over the years. In theory, this could still be done now (e.g. a standard build system), but I think most "systems language" innovation action now firmly happens in the Rust camp (which may be a good thing, because the world needs more safe code).
- tinco 5y ago
  To be fair, maybe it would have been a bit of a shit show if they standardised on a string format before the popularisation (or even invention) of UTF-16 (or UTF-8, whatever floats your boat).
  - vardump 5y ago
    UTF-16 makes only sense for backwards compatibility with something that was originally designed to use OCS-2. Annoyingly, it can be both big and little endian encoding. UTF-8 saves space and is just as easy (and fast!) to process as UTF-16, as both are variable length encodings. UTF-8 is always unambiguous and self-synchronizing. The byte order stays always the same. The only complication is potentially multiple ways to encode a character, but that can be solved by just declaring all but the shortest encoding illegal. Hopefully we'll only have UTF-8 in the long run, both externally and (by default) internally. C string functions are mostly compatible with UTF-8, as long as individual non-7-bit characters are not processed or the string indexed, etc.
- arthur2e5 5y ago
  I have a slight urge to blame this lack of "community" to the institutionalized nature of C's standarization in the style of "Against SQL".[1] Although in this case the barrier is not between research and implementation, but between implementation and standarization. [1]: https://scattered-thoughts.net/writing/against-sql/#innovation-at-the-implementation-level-is-gated (But hey, the defer proposal is here and might actually become a thing... right?)
Karellen 5y ago
Communities with opinions and build systems and style guides showed up, and weren't that hard to find. https://www.gnu.org/prep/standards/html_node/index.html https://www.gnu.org/prep/standards/html_node/index.html

by tinco 5y ago

jll29 5y ago

Your comment reminded me of the early days when I learned C in the mid 1980s, and I complained about the lack of a string type (which I had been used to from Pascal, Modula-2 and even BASIC), people said one should have the freedom to implement them as 0-terminated strings or using length and a char array, or even in other ways. To me that has always been a lame excuse for a poor standard library. You can always build your own, even if the standard library has a solution that works for 99% of cases - and that makes 99% of code more readable to 100% of people. I love C (let's not get into a C++ rant here..) so this is just a comment about the culture, like the parent post. The fact that people who don't like to re-invent the wheel have not stuck with C, and maybe gone to join the Perl, Python, Java... communities made this issue worse over the years. In theory, this could still be done now (e.g. a standard build system), but I think most "systems language" innovation action now firmly happens in the Rust camp (which may be a good thing, because the world needs more safe code).

tinco 5y ago
To be fair, maybe it would have been a bit of a shit show if they standardised on a string format before the popularisation (or even invention) of UTF-16 (or UTF-8, whatever floats your boat).
- vardump 5y ago
  UTF-16 makes only sense for backwards compatibility with something that was originally designed to use OCS-2. Annoyingly, it can be both big and little endian encoding. UTF-8 saves space and is just as easy (and fast!) to process as UTF-16, as both are variable length encodings. UTF-8 is always unambiguous and self-synchronizing. The byte order stays always the same. The only complication is potentially multiple ways to encode a character, but that can be solved by just declaring all but the shortest encoding illegal. Hopefully we'll only have UTF-8 in the long run, both externally and (by default) internally. C string functions are mostly compatible with UTF-8, as long as individual non-7-bit characters are not processed or the string indexed, etc.
arthur2e5 5y ago
I have a slight urge to blame this lack of "community" to the institutionalized nature of C's standarization in the style of "Against SQL".[1] Although in this case the barrier is not between research and implementation, but between implementation and standarization. [1]: https://scattered-thoughts.net/writing/against-sql/#innovation-at-the-implementation-level-is-gated (But hey, the defer proposal is here and might actually become a thing... right?)

Karellen 5y ago

Communities with opinions and build systems and style guides showed up, and weren't that hard to find. https://www.gnu.org/prep/standards/html_node/index.html https://www.gnu.org/prep/standards/html_node/index.html