[deleted]
The Development of the C Language (1993)
31–40 of 536 posts
Re: The Development of the C Language (1993)
#32This might miss a (1993) tag. Interestingly, some might print the same title about JavaScript.
Added
Re: The Development of the C Language (1993)
#33Earlier quoted context omitted.
Because everything speaks C. If you write a library in C, it can be easily exposed to a variety of high-level languages and platforms. You might argue this is more a property of the C ABI than of C itself, but unless the project is large enough that it's worth doing it in C++ or Rust instead, it's still a very reasonable choice. Also not everything is web. Sure, if you're writing API endpoints in C you're just shooti…
So we're gonna be stuck writing a precambrian prototype language till the end of time because there's so much legacy code already written in it? Never seemed to stop people moving from Pascal, or Perl or literally all other languages that are now obsolete. I really hate how for microcontrollers the only two choices are either C++ or Micropython, I mean how about some fucking middle ground instead of two polar opposit…
> Never seemed to stop people moving from Pascal, or Perl or literally all other languages that are now obsolete.
Operating systems written in Pascal are now obsolete. OSs in C are not.
Perl is much easier to replace because fewer things were dependent on it however even here Perl 5.x still pops up all over the place.
Re: The Development of the C Language (1993)
#34Earlier quoted context omitted.
So we're gonna be stuck writing a precambrian prototype language till the end of time because there's so much legacy code already written in it? Never seemed to stop people moving from Pascal, or Perl or literally all other languages that are now obsolete. I really hate how for microcontrollers the only two choices are either C++ or Micropython, I mean how about some fucking middle ground instead of two polar opposit…
>I really hate how for microcontrollers the only two choices are either C++ or Micropython There's TinyGo as well. https://tinygo.org/ I'd say that's the middle ground for me.
It is nice, but nowhere near as complete feature-wise than C/C++. The fact that it exists does not mean you can use it to achieve the same thing.
Re: The Development of the C Language (1993)
#35People who still write C, honest question: Why? C is full of quirks. From cryptic "undefined behaviors" to a type system that isn't really a type system (more like "size hints for the compiler"), the language doesn't feel easy to use/debug. Add to this CPP macros, a universally recognized bad idea, a clunky import system, and lack of a single reference implementation of the compiler/libC, and you have a language that…
It's kind of like English. English is in some sense a simple language (grammar), a poor mixture of other languages and its orthography is not good (not an elegant language), but everyone speaks it.
Re: The Development of the C Language (1993)
#36People who still write C, honest question: Why? C is full of quirks. From cryptic "undefined behaviors" to a type system that isn't really a type system (more like "size hints for the compiler"), the language doesn't feel easy to use/debug. Add to this CPP macros, a universally recognized bad idea, a clunky import system, and lack of a single reference implementation of the compiler/libC, and you have a language that…
> Add to this CPP macros, a universally recognized bad idea
I don't think is not a bad idea. You can't solve language incompatibilities in the language it self. Textual macro languages solves this nicely.
CPP is what makes C and C++ work for projects aimed at multiple platforms or compiler vendors.
Re: The Development of the C Language (1993)
#37People who still write C, honest question: Why? C is full of quirks. From cryptic "undefined behaviors" to a type system that isn't really a type system (more like "size hints for the compiler"), the language doesn't feel easy to use/debug. Add to this CPP macros, a universally recognized bad idea, a clunky import system, and lack of a single reference implementation of the compiler/libC, and you have a language that…
> The C representation of memory (and all the pointer arithmetic) is not a real representation of your hardware, and this too is an abstraction. By and large memory is a contiguous array and the C representation closely matches what is actually happening, so I am curious about which platforms you have worked on.
> the C representation closely matches what is actually happening
It really doesn't, though. Although your CPU might present system RAM as one contiguous array of bytes to your program, the C compiler follows different rules – see strict aliasing and other pointer dereference rules. For example, the following is Undefined Behavior and your C compiler may or may not generate the assembly you expect:
int x = *(int *)0x1234568;
Re: The Development of the C Language (1993)
#38People who still write C, honest question: Why? C is full of quirks. From cryptic "undefined behaviors" to a type system that isn't really a type system (more like "size hints for the compiler"), the language doesn't feel easy to use/debug. Add to this CPP macros, a universally recognized bad idea, a clunky import system, and lack of a single reference implementation of the compiler/libC, and you have a language that…
> cryptic "undefined behaviors"
It's not really that cryptic (aside from like strict aliasing, but -fno-strict-aliasing). There's some UB that might be considered unnecessary/too strict, but it still makes sense in its own right, and, if understood, is quite powerful, and leads to a bunch of neat optimizations.
> the language doesn't feel easy to use/debug
If debugging at the assembly level, stepping by instructions, it's actually quite nice (despite what everyone says about it not mapping well to hardware, in my experience there's still a pretty clear & immediately obvious correspondence between each C thing and assembly subsection, and vice versa)
> CPP macros, a universally recognized bad idea
I don't know, they're quite neat for things I have to do. Sure, a turing-complete compile-time language would be nice (I'm not saying that sarcastically, I even use a DSL for writing SIMD that is exactly that!), but it'd add a ton of complexity to mapping C source to assembly.
> Also, documentation is all over the place. If a function isn't described in `man`, I have no idea where else to actually look for it.
Use of the standard library grows less and less significant as the size of the C project grows. Besides that, cppreference.com has pretty much everything.
And yeah, as others have said, a linear sequence of bytes is still a thing every CPU presents. Yes, there's cache & whatnot, but there's like precisely no way to usefully map that to any user-controllable/visible thing, because it's pretty much not user-controllable and intended to be invisible (and varies across all hardware).
Re: The Development of the C Language (1993)
#39People who still write C, honest question: Why? C is full of quirks. From cryptic "undefined behaviors" to a type system that isn't really a type system (more like "size hints for the compiler"), the language doesn't feel easy to use/debug. Add to this CPP macros, a universally recognized bad idea, a clunky import system, and lack of a single reference implementation of the compiler/libC, and you have a language that…
Honestly because I don't want to learn another language.
And because most of the world uses C for low level stuff. You can say that Esperanto is a much better international language than English but what good does it do if nobody speaks it?
Re: The Development of the C Language (1993)
#40People who still write C, honest question: Why? C is full of quirks. From cryptic "undefined behaviors" to a type system that isn't really a type system (more like "size hints for the compiler"), the language doesn't feel easy to use/debug. Add to this CPP macros, a universally recognized bad idea, a clunky import system, and lack of a single reference implementation of the compiler/libC, and you have a language that…
I don't write C as much as i used to but i still write a lot of it, including new code. The reasons are: 1. C is relatively simple. Sure, not as simple as it could be (e.g. compared to something like Oberon-07) but in the grand scheme of language things, it is far on the simpler side of the spectrum. I can write a C parser relatively easy if i want to for example (and at some point years ago i did that to transpile a…
About 4., there is already a preprocessor loop proposal for clang[0] and I think I have also seen it some obscure Qualcomm bluetooth chip compiler.
[0]: https://discourse.llvm.org/t/rfc-new-preprocessor-macro-dire...