3 ms·

My sense is that this is really a communication issue (when is it not?) On a relative scale, C is very low level compared to how we program today if you think

My sense is that this is really a communication issue (when is it not?) On a relative scale, C is very low level compared to how we program today if you think about levels of abstraction. If “low level” means “runs on the CPU almost literally as written.” then no it’s not.

fweimer 3y ago
It's more than that. C-the-language just doesn't have low-level concepts such as machine addresses, and its facilities for dealing with the types that the abstract machine ascribes to all objects are quite limited. Ada has System.Address to model machine addresses: http://ada-auth.org/standards/rm12_w_tc1/html/RM-13-7.html#p34 http://ada-auth.org/standards/rm12_w_tc1/html/RM-13-7.html#p... C++ has std::less specializations for pointer types which provide a strict total order (one aspect of machine addresses): https://en.cppreference.com/w/cpp/utility/functional/less https://en.cppreference.com/w/cpp/utility/functional/less There is also placement new and std::launder for more explicit control of typed memory: https://en.cppreference.com/w/cpp/language/new https://en.cppreference.com/w/cpp/language/new https://en.cppreference.com/w/cpp/utility/launder https://en.cppreference.com/w/cpp/utility/launder These days, even Java tries to model machine addresses: https://docs.oracle.com/en/java/javase/21/core/foreign-function-and-memory-api.html https://docs.oracle.com/en/java/javase/21/core/foreign-funct...
kortex 3y ago
Yep, this is a linguistic problem, not a technical one. "C is not a low level language" implies that the hi/lo boundary lies below C. What's below C? IR, Asm, and opcodes. IRs like LLVMIR and various bytecodes. Well, those don't map to the hardware 1:1, not even close. So IR must be HLL. Sure Asm has to be architecture specific, but even then we are getting pretty good at transpilation. And those codes get translated to opcodes anyways on most modern chips. Basically, unless you are assembling on an ancient system or embedded processor, you aren't writing in a "low level language". Very few folks nowadays do this, so the term "LLL" doesn't occupy much mindshare in semantic space. That leads folks to populate it with what they perceive as low level - the lowest language on the abstraction tree they are likely to encounter - C. This divide is only going to expand so I say we just accept the definition of low level language has shifted, and call anything where it does closely match... something else, I don't have a good term. Maybe "hardware level language".
falcrist 3y ago
> If “low level” means “runs on the CPU almost literally as written.” then no it’s not. But doesn't this still depend on what CPU you're talking about? Your C code will map much more closely to the instructions of the machine code of an 8051 or even an M4 than it will to an x86. Thus any general-purpose language is more or less "low level" depending on the CPU it's running on. This seems like a poor definition.

fweimer 3y ago

It's more than that. C-the-language just doesn't have low-level concepts such as machine addresses, and its facilities for dealing with the types that the abstract machine ascribes to all objects are quite limited. Ada has System.Address to model machine addresses: http://ada-auth.org/standards/rm12_w_tc1/html/RM-13-7.html#p34 http://ada-auth.org/standards/rm12_w_tc1/html/RM-13-7.html#p... C++ has std::less specializations for pointer types which provide a strict total order (one aspect of machine addresses): https://en.cppreference.com/w/cpp/utility/functional/less https://en.cppreference.com/w/cpp/utility/functional/less There is also placement new and std::launder for more explicit control of typed memory: https://en.cppreference.com/w/cpp/language/new https://en.cppreference.com/w/cpp/language/new https://en.cppreference.com/w/cpp/utility/launder https://en.cppreference.com/w/cpp/utility/launder These days, even Java tries to model machine addresses: https://docs.oracle.com/en/java/javase/21/core/foreign-function-and-memory-api.html https://docs.oracle.com/en/java/javase/21/core/foreign-funct...

kortex 3y ago

Yep, this is a linguistic problem, not a technical one. "C is not a low level language" implies that the hi/lo boundary lies below C. What's below C? IR, Asm, and opcodes. IRs like LLVMIR and various bytecodes. Well, those don't map to the hardware 1:1, not even close. So IR must be HLL. Sure Asm has to be architecture specific, but even then we are getting pretty good at transpilation. And those codes get translated to opcodes anyways on most modern chips. Basically, unless you are assembling on an ancient system or embedded processor, you aren't writing in a "low level language". Very few folks nowadays do this, so the term "LLL" doesn't occupy much mindshare in semantic space. That leads folks to populate it with what they perceive as low level - the lowest language on the abstraction tree they are likely to encounter - C. This divide is only going to expand so I say we just accept the definition of low level language has shifted, and call anything where it does closely match... something else, I don't have a good term. Maybe "hardware level language".

falcrist 3y ago

> If “low level” means “runs on the CPU almost literally as written.” then no it’s not. But doesn't this still depend on what CPU you're talking about? Your C code will map much more closely to the instructions of the machine code of an 8051 or even an M4 than it will to an x86. Thus any general-purpose language is more or less "low level" depending on the CPU it's running on. This seems like a poor definition.