Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Development of the C Language (1993)

bell-labs.com

Post reply on HN
Print view View original

41–50 of 536 posts

Re: The Development of the C Language (1993)

#41

Post by cyber_kinetist »

qsort wrote: post #12
babarock wrote: post #6

People 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…

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…

And since C has become more than just a language and actually a protocol (See https://faultlore.com/blah/c-isnt-a-language/), you sometimes would need to know the inner workings of C even when you write in other programming languages (C++, Rust, Swift, Zig, even Python, etc...)

Re: The Development of the C Language (1993)

#42

Post by ajb »

w4rh4wk5 wrote: post #5

I wonder how much the pile of undefined behavior contributed to C's success. I can imagine that vendors picked C over alternatives due to C giving them more freedom with their implementation.

What you are thinking about there is perhaps implementation defined behavior, which is distinct from undefined behavior; and the sequence was the other way round - hardware with different behaviors already existed, and not specifying them in the language allowed C to succeed because it wasn't tied to a particular machine.

The answer is different for different kinds of undefined behavior, but spatial memory safety violations are basically always possible in a language you can write an OS in, since you need to convert from hardware buffers to higher level types. temporal memory safety wasn't possible to enforce at the time on a low level language, it's taken decades for it to be implemented in a mainstream non-garbage-collected language. Integer overerflow is still not caught by default even in rust for efficiency reasons (it would take all the processor vendors to implement an efficient way of catching it)

Re: The Development of the C Language (1993)

#43

Post by SkiFire13 »

mytailorisrich wrote: post #15
babarock wrote: post #6

People 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.

Most modern hardware make use of registers and multiple layers of caches and you need ton of UB to justify the compiler making use of them.

Re: The Development of the C Language (1993)

#44

Post by Philip-J-Fry »

rcarmo wrote: post #34
Philip-J-Fry wrote: post #26

Earlier quoted context omitted.

>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.

What do you mean no where near as complete feature wise? Go or specifically the TinyGo implementation?

Seems to do exactly what 99% of people need.

Re: The Development of the C Language (1993)

#45

Post by stowaway1256 »

moffkalast wrote: post #19
qsort wrote: post #12

Earlier 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…

Isn't Lua middle-ground enough? Alternatively you can write it in V and transpile to C.

Re: The Development of the C Language (1993)

#47

Post by messe »

jacquesm wrote: post #24
zabzonk wrote: post #20

Earlier quoted context omitted.

bits are not addressable in C and are thus not directly accessible.

They are also not normally directly addressable by the CPU, you'll have to do some combining and splitting with separate instructions. Some CPUs are better at this than others.

I wouldn’t quite count it as bit-addressing, but x86, for example, can load bits directly into the carry flag using the BT instruction which can take a register or memory address as it’s first argument, with the bit being given as the second.

Re: The Development of the C Language (1993)

#48

Post by stowaway1256 »

Philip-J-Fry wrote: post #44
rcarmo wrote: post #34

Earlier quoted context omitted.

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.

What do you mean no where near as complete feature wise? Go or specifically the TinyGo implementation? Seems to do exactly what 99% of people need.

Feature parity is fine but support is not quite there. Doesn't support WiFi on NodeMCU boards last I checked.

Re: The Development of the C Language (1993)

#49

Post by EternalCarnage »

babarock wrote: post #6

People 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…

History.

You do what your operating system vendor does.

Not few operating systems have a C interface. The implementation of binaries (see also application binary interfaces) depends on the operating system.

Shared libraries (e.g., DLL) are binaries, too.

C compiler developers have the ability to generate consistent[1] binary outputs.

In simpler terms, vendors of these compilers can reach a consensus on how to convert C code into binary files, known as Application Binary Interfaces (ABI).

It is not uncommon[2] to have a foreign function interface in C.

1. http://yosefk.com/c++fqa/defective.html

2. https://learn.microsoft.com/en-us/cpp/dotnet/calling-native-...

Re: The Development of the C Language (1993)

#50

Post by rcarmo »

Philip-J-Fry wrote: post #44
rcarmo wrote: post #34

Earlier quoted context omitted.

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.

What do you mean no where near as complete feature wise? Go or specifically the TinyGo implementation? Seems to do exactly what 99% of people need.

"Seems" is an outside perspective. There are loads of hardware features that it just doesn't support on various boards, and lots of extra hardware (like sensors) that it has no libraries for. It's not just the MCU/CPU that matters here.
Post reply on HN