Live data from Hacker News

The Development of the C Language (1993)

bell-labs.com

11–20 of 536 posts

Re: The Development of the C Language (1993)

#11
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…

> I don't think I've ever seen a computer where memory is actually a continuous array of bits sorted by memory address

well, that is not the C memory model. C does not allow you to access bits in memory directly. maybe you meant bytes? or words? if so, many cpus have exactly that architecture.

Re: The Development of the C Language (1993)

#12
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 shooting yourself in the foot, just use Python or Ruby or Go and call it a day. For things like embedded it's often your only reasonable choice.

Re: The Development of the C Language (1993)

#13
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…

It‘s the only language supported by basically all platforms, microcontrollers, GPUs, web-browsers. Although that is also almost true for C++ nowadays. I‘m also curious which memory model would be superior in your opinion?

Re: The Development of the C Language (1993)

#14
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…

I like making things (air quality monitors, web nfc login, automated garden, power monitor and etc) with microcontrollers like the Raspberry Pi Pico, the only real choices are C/C++ or some flavor of Python. I really do not like Python, it rubs me the wrong way for some reason and also I can find libraries for all the components/sensors in C/C++.

It's not so bad. Manipulating strings is a pain in the ass so everything becomes a char and managing types is so annoying, especially dealing functions that could easily take an int or float, you either have to make a template or different versions of the function for each type. This makes me appreciate dynamically typed languages a lot. Those two issues are the only problems I seem to have, everything else has been easy and breezy

Besides those two things it's pretty nice. My code is a bit verbose because I'm not that great at it but I'm sure I could reduce the lines of code in my projects (the biggest one has 4000+ lines of code, but it does a lot) by using structs and more loops, but that's mostly a skill/experience issue.

Re: The Development of the C Language (1993)

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

Re: The Development of the C Language (1993)

#16
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…

Existing C examples from semiconductor vendors do not allow other languages. Ok, C++ is also used, but that’s it. So it’s no brainer taking available drivers and building logic around them. That’s current state in embedded development. Client does not pay for use of modern languages.

Re: The Development of the C Language (1993)

#17
post #11
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…

> I don't think I've ever seen a computer where memory is actually a continuous array of bits sorted by memory address well, that is not the C memory model. C does not allow you to access bits in memory directly. maybe you meant bytes? or words? if so, many cpus have exactly that architecture.

> C does not allow you to access bits in memory directly.

of course it does what are you talking about?

Re: The Development of the C Language (1993)

#18
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…

Extremely minimal runtime, portability, and very low overhead when compared to other languages. I have a tiny statistics daemon that scrapes /proc and sends out multicast packets, and it builds and runs on everything from ARMv5 to Xeons, barely showing up on any kind of resource meter and with an absurdly small binary size.

I considered rewriting it in Go a couple of times but just didn’t see the point.

Re: The Development of the C Language (1993)

#19
post #12
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…

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 opposites? At least eventually everything will be rewritten in Rust I guess.

Re: The Development of the C Language (1993)

#20
post #11

Earlier quoted context omitted.

> I don't think I've ever seen a computer where memory is actually a continuous array of bits sorted by memory address well, that is not the C memory model. C does not allow you to access bits in memory directly. maybe you meant bytes? or words? if so, many cpus have exactly that architecture.

> C does not allow you to access bits in memory directly. of course it does what are you talking about?

bits are not addressable in C and are thus not directly accessible.
Post reply on HN