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

101–110 of 536 posts

Re: The Development of the C Language (1993)

#101

Post by Joker_vD »

TheOtherHobbes wrote: post #63
lordnacho wrote: post #57

Earlier quoted context omitted.

> I used to think "C presents the most honest representation of the low-level mechanisms of the computer", but... even this is shaky. I've been programming for almost 15 years now, and I don't think I've ever seen a computer where memory is actually a continuous array of bits sorted by memory address. The C representation of memory (and all the pointer arithmetic) is not a real representation of your hardware, and th…

Why do programmers in 2023 need to imagine a virtual machine (basically a PDP-11 from 1970-something) at all? You only need that abstraction if you're doing low level bit/byte bashing and I/O, or there's some chance you may run out of memory and need to handle that manually. That applies to a tiny slice of all possible applications. There are far more useful modern abstractions that don't need to make those assumptio…

> basically a PDP-11 from 1970-something

That PDP-11 from the seventies had ADC/SBC (addition/subtraction with carry) in its instruction set, the result of MUL was twice the size of the inputs (i.e., multiplying two ints produced a long), and DIV produced both the quoitient and the remainder. None of that is visible from C and yet people keep clamoring that "C is close to the metal". Bah, humbug: while " * p++" and " * --p" idioms translate directly into an addressing mode particular for PDP-11 — most other architectures don't have autoincrement/decrements — there is no specific support for " * ++p " or " * p--" in the machine itself.

Re: The Development of the C Language (1993)

#102

Post by moffkalast »

hnlmorg wrote: post #33
moffkalast wrote: post #19

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

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

Yeah to my great annoyance I did have to grep for an ipv4 address with a perl regex the other day. But for any actual scripting it's basically dead.

Re: The Development of the C Language (1993)

#103

Post by pkkm »

sgt wrote: post #97
pkkm wrote: post #68

Earlier quoted context omitted.

1. It gives me a lot of control over how the program works, which lets me create programs that work faster and use less memory than would be possible in most other languages. 2. Relatedly, it's more explicit than almost any other language. If a line of code doesn't look like a function call, it's not calling anything. There is no hidden control flow. These statements are not true in languages which support operator o…

With C23 there's the #embed feature. Might be super useful for embedded software. How are the toolkits e.g. for ESP32 and TI in terms of C23 compatibility?

> How are the toolkits e.g. for ESP32 and TI in terms of C23 compatibility?

C23 hasn't been released yet so it's hard to talk about compatibility. It's probably going to take a few years before it's widely supported.

Re: The Development of the C Language (1993)

#104

Post by flohofwoe »

moffkalast wrote: post #100
pkkm wrote: post #79

Earlier quoted context omitted.

> I really hate how for microcontrollers the only two choices are either C++ or Micropython Why wouldn't you just use C for programming a microcontroller? Sure, it's not a great language for web backends, but microcontrollers are where it shines. You're probably not deploying 100,000 lines to a microcontroller for a personal project, so the lack of certain abstractions isn't going to be that painful. On the other han…

Why wouldn't you use assembly for programming a microcontroller? Sure, it's not a great language for web backends but microcontrollers are where it shines. /s Because as the OP states, it's an objectively (pun intended) terribly abstracted language. There is nothing 100% predictable about C except that you'll eventually get screwed because you didn't account for some random obscure thing that should never have even b…

Enable max warning level, use a static analyzer, and ASAN, UBSAN and TSAN (in order of importance), and most problems you listed just disappear. Most importantly though: don't use MSVC if you have the choice.

Re: The Development of the C Language (1993)

#105

Post by moffkalast »

flohofwoe wrote: post #104
moffkalast wrote: post #100

Earlier quoted context omitted.

Why wouldn't you use assembly for programming a microcontroller? Sure, it's not a great language for web backends but microcontrollers are where it shines. /s Because as the OP states, it's an objectively (pun intended) terribly abstracted language. There is nothing 100% predictable about C except that you'll eventually get screwed because you didn't account for some random obscure thing that should never have even b…

Enable max warning level, use a static analyzer, and ASAN, UBSAN and TSAN (in order of importance), and most problems you listed just disappear. Most importantly though: don't use MSVC if you have the choice.

Yeah if you want to kill yourself from frustrations, maybe. I'm not writing microcontroller code for the fucking space shuttle, and I would suspect most people aren't.

C did a ton of things right, but it also did a ton of things wrong. Learning from that and moving on would be the sensible thing to do after 50 years.

Re: The Development of the C Language (1993)

#106

Post by tester756 »

zabzonk wrote: post #91
tester756 wrote: post #84

Earlier quoted context omitted.

Is this important? I treat compiler as *full* toolchain I run compilation and expect sane error messages - saying that "oh, it's because of linker yada yada" doesn't solve my problems nor is valid excuse Other language (compilers) do better.

> I treat compiler as full toolchain well, you may do that, but it doesn't make it so. the linker has much less information to go on than the compiler - basically (depending on how you compiled) machine code. actually, the GNU linker does quite a good job, given what it has to work with. > Other language (compilers) do better. a language is not a compiler

>well, you may do that, but it doesn't make it so. the linker has much less information to go on than the compiler - basically (depending on how you compiled) machine code. actually, the GNU linker does quite a good job, given what it has to work with.

but it was their decision to split the tools like that, wasn't it?

nothing technically prevents you to model it in such a way that you can have access to the data you need, right?

You probably don't even need to have linker at all.

>> Other language (compilers) do better.

>a language is not a compiler

I wrote compiler in parenthesis.

Also, since "language" has two definitions

1. syntax

2. whole ecosystem

Then it is valid either way

Re: The Development of the C Language (1993)

#107

Post by kaba0 »

enriquto wrote: post #75
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…

> People who still write C, honest question: Why? Because loops are fast. I do scientific computing, where many people use python nowadays, and a few years ago it was matlab/octave. These languages feel "cramped" because they artificially force you to program in a certain way in order to avoid loops. While such a "vectorial" notation is often useful, many algorithms are better expressed using a loop notation, and C d…

C has no in-built way to deal with SIMD, which is essential for high-performance computing over loads of data. On that count alone it is already out of the game.

Re: The Development of the C Language (1993)

#108

Post by TheLoafOfBread »

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 FreeRTOS is written in C.

Re: The Development of the C Language (1993)

#109

Post by flohofwoe »

moffkalast wrote: post #105
flohofwoe wrote: post #104

Earlier quoted context omitted.

Enable max warning level, use a static analyzer, and ASAN, UBSAN and TSAN (in order of importance), and most problems you listed just disappear. Most importantly though: don't use MSVC if you have the choice.

Yeah if you want to kill yourself from frustrations, maybe. I'm not writing microcontroller code for the fucking space shuttle, and I would suspect most people aren't. C did a ton of things right, but it also did a ton of things wrong. Learning from that and moving on would be the sensible thing to do after 50 years.

Tell me an alternative which ticks all the checkboxes and I'll switch immediately. C++ isn't it because the committee has completely lost focus since ca C++11, Rust isn't it because they completely forgot about ergonomics, simplicity and elegance on their quest to fix memory safety (and both C++ and Rust suffer from "design by committee").

Zig looks perfect so far, but it's too early to switch over yet.

Any other promising candidates?

Re: The Development of the C Language (1993)

#110

Post by zabzonk »

tester756 wrote: post #106
zabzonk wrote: post #91

Earlier quoted context omitted.

> I treat compiler as full toolchain well, you may do that, but it doesn't make it so. the linker has much less information to go on than the compiler - basically (depending on how you compiled) machine code. actually, the GNU linker does quite a good job, given what it has to work with. > Other language (compilers) do better. a language is not a compiler

>well, you may do that, but it doesn't make it so. the linker has much less information to go on than the compiler - basically (depending on how you compiled) machine code. actually, the GNU linker does quite a good job, given what it has to work with. but it was their decision to split the tools like that, wasn't it? nothing technically prevents you to model it in such a way that you can have access to the data you…

all compiled language systems must support a separate link stage, if they are to be of any practical use
Post reply on HN