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

50 years of C, the good, the bad and the ugly [video]

streaming.media.ccc.de

Post reply on HN
Print view View original

141–150 of 257 posts

Re: 50 years of C, the good, the bad and the ugly [video]

#141

Post by jokoon »

GeorgeTirebiter wrote: post #133
jokoon wrote: post #99

I'm trying to build a language that translates directly to C. I will just implement some features of the language in C, with some headers I can already find. It feels like it's the best way I want to do this. That way, a C compiler can do a lot of work I really don't want to do, C already has backends, optimizers, etc etc. All I want is a C-like language with native strings, hash map and list, tuples python indentati…

Have you looked at Nim? https://nim-lang.org/ or Zig? https://ziglang.org/ or D? https://dlang.org/

Yes I know about all of them, they're all a bit too complex for my taste.

They're great languages, but they're not what I want.

Re: 50 years of C, the good, the bad and the ugly [video]

#142

Post by asveikau »

WastingMyTime89 wrote: post #67
sn41 wrote: post #61

Earlier quoted context omitted.

> that’s pretty much it. Only if you ignore 1. variadic arguments as in printf, 2. function pointers which are a very elementary (type-unsafe) form of closures, 3. a nice way of casting to void 4. setjmp and longjmp goodies (?) which allow you to code up co-routine libraries and exception handling mechanisms I'm sure there are more such facets I am missing. The elegance of the specification may be questionable, but t…

There is no elegance there. Casting to void is not a plus. That’s just C having no proper type system. Function pointers as an elementary form of closures, come on, what’s next? Closures are defined by capture. It’s nearly as fun as pretending C as coroutines because of setjmp . How can a statement like C being semantically poor even be seen as controversial? For god sake, we are talking about a language which semant…

> HN really is a joke sometimes.

A lot of what I'm seeing from your comments here is you can't handle people who have something positive to say about C.

They're not saying it's the one true way or something. Just that they like it in some respect.

And your attempts to dismiss that and call "HN" a joke for harboring someone who thinks this way look kind of childish to me.

Re: 50 years of C, the good, the bad and the ugly [video]

#143

Post by estebank »

fncslothouber wrote: post #126
ptx wrote: post #106

Earlier quoted context omitted.

If people rely on the LEDs working correctly or if the controller has any kind of connection to another system (which could be leveraged by an attacker to penetrate deeper into the network) it seems to me that security and memory safety would still be important.

Not everything is or needs to be connected to the Internet. There are plenty of things that are controlled by a micro controllers that do not have a network connection.

Not everything needs to be connected to the Internet, and not every micro controller is running a non-mission critical task.

A micro controller hitting a memory safety bug that causes the LEDs to present invalid output can have real world consequences. Even if the micro controller isn't directly actuating machinery, it might cause an operator to incorrectly act because they were mislead.

If the micro controller is running Christmas lights, it might be fine if it falls over, no one will die, but I would still call that a manufacturing defect.

Re: 50 years of C, the good, the bad and the ugly [video]

#144

Post by eska »

WastingMyTime89 wrote: post #98
youarethejoke wrote: post #72

Earlier quoted context omitted.

You really don't understand, but that's okay. C is a wonderful language, and that's the end of it really. You just try to think C as a language that SHOULD HAVE all the stupid bells and whistles you find convenient. Many of us more advanced coders have found that those stupid bells and whistles are, in fact, inconvenient. Casting to void is a powerful technique and the limits are literally endless. C is semantically…

The argument is not about what can and can’t be done in C. C is Turing complete and low level. You can do anything in C. The debate is not even about if it’s good idea (I don’t think it is but that’s separate). The question is about C semantics. Given the reply I get it’s pretty obvious that some here don’t understand what language semantics are. It’s about the amount of concepts you can express in the language. Hask…

You’re whitewashing history if you think Pascal was superior to C. There was no conspiracy among compiler developers as you imply.

Also you complain about semantic richness of C, but then only point to semantically rich languages you despise. A curious reader would wonder: why care about semantically rich languages then? An observant reader would wonder: so aren’t there times where semantic richness is not useful?

Re: 50 years of C, the good, the bad and the ugly [video]

#145

Post by estebank »

hgs3 wrote: post #128
Koshkin wrote: post #85

Earlier quoted context omitted.

> C is the best abstraction for many problem domains It's really not, though. What C is an abstraction of is computer architecture as it existed by the late 1960s.

> It's really not, though. What C is an abstraction of is computer architecture as it existed by the late 1960s. I don't follow. Barring micro-code, hardware is designed for executing either RISC or CISC instructions. If anything, the industry has matured and we see less esoteric ISA's today than in the 1960s.

A modern low level labguage would expose you to the concepts of cache lines and homogeneous and eterogeneous cores directly, with locality awareness to recognize false sharing. It would be something suitable to program the Cell architecture from PS2.

Re: 50 years of C, the good, the bad and the ugly [video]

#146

Post by estebank »

elcritch wrote: post #71
zozbot234 wrote: post #37

Earlier quoted context omitted.

SafeC and CheckedC do nothing for temporal safety. Zig is in the same boat. There's not really a simpler alternative to Rust with the same featureset, even its direct predecessor Cyclone was in fact quite a bit harder to use. Rust itself is also improving very quickly and becoming easier to use over time.

Unfortunately, Rust's core design philosophy is fundamentally opposed to much of the design philosophy that made C and C++ so popular and flexible. It's almost the exact opposite extreme on the pendulum, where C allowed anything while Rust limits to only what the language designers conceive as proper and not just safe. Zig can gain memory management systems like Nim's ARC which works well for system design and adds t…

What task can you do in C that you can't in Rust (or Zig, for that matter)?

Re: 50 years of C, the good, the bad and the ugly [video]

#147

Post by fncslothouber »

bonzini wrote: post #102
fncslothouber wrote: post #89

Earlier quoted context omitted.

Memory safety / security is important for a subset of all possible applications. It is not important for _all_ applications. If I use a micro controller to control a string of leds I do not care about security/memory safety. But I do care about being as close to the metal as possible, and being able to understand the compiled code.

To control a string of LEDs, something like Forth (or some other p-code virtual machine) is going to be just as good as C. PIC microcontrollers have always had BASIC as an option for example. But many microcontrollers these days will likely have a TCP/IP stack, perhaps even crypto, even if it is to control a string of LEDs via MQTT or Modbus TCP.

Forth would also be a nice choice.

Give you another example. A watch, not an apple watch, but a simple Casio watch. One that does time, alarm and a stopwatch. Not connected to anything. What is important here is the battery life, so the less code the better. C would be a fine choice here. All additional code to prevent security breaches would be a complete waste here.

Give another example. As my day-job I develop embedded software for the railways. Current system I work on operates the brakes when the train goes too fast. Not connected to the internet, and no connection would even be allowed. Written in C. One because it is simple to understand and the developer can focus on getting the functionality correct. Secondly because there is a wide choice of additional tooling and standards that is required to get the application certified.

Re: 50 years of C, the good, the bad and the ugly [video]

#148

Post by estebank »

tmtvl wrote: post #70
nousermane wrote: post #12

Earlier quoted context omitted.

> Linux kernel is written in C Not exclusively in C, not anymore: https://docs.kernel.org/rust/index.html It might take another decade for a C-free build to be possible, though.

As long as there isn't a Rust compiler written in Rust (there is a transpiler to LLVM bytecode, but that gets compiled by a C++ compiler, same for GCC-rs) I don't think a C-free (or a C++-free) build will be possible at all, so I'm guessing it'll take somewhere in the 60-100 year range.

Honest question: what would the engineering rationale be behind dropping LLVM entirely and have rustc have its own code generation backend? There are two out there that might be interesting, one uses gcc and another is called cranelift, but it isn't the default and focuses exclusively on compilation speed for debug binaries.

Re: 50 years of C, the good, the bad and the ugly [video]

#149

Post by WastingMyTime89 »

asveikau wrote: post #142
WastingMyTime89 wrote: post #67

Earlier quoted context omitted.

There is no elegance there. Casting to void is not a plus. That’s just C having no proper type system. Function pointers as an elementary form of closures, come on, what’s next? Closures are defined by capture. It’s nearly as fun as pretending C as coroutines because of setjmp . How can a statement like C being semantically poor even be seen as controversial? For god sake, we are talking about a language which semant…

> HN really is a joke sometimes. A lot of what I'm seeing from your comments here is you can't handle people who have something positive to say about C. They're not saying it's the one true way or something. Just that they like it in some respect. And your attempts to dismiss that and call "HN" a joke for harboring someone who thinks this way look kind of childish to me.

Then you are seeing what you want to see. People are straightforwardly arguing that C is semantically rich which is indeed laughable. I have addressed the point under but clearly a lot of you don’t understand what language semantics are.

Considering I was having interesting discussion about the subtleties of the Hindley-Milner type system on this same website a decade ago, yes, I do think HN is becoming a joke. The joke is on me however because apparently I keep commenting for reasons which are not always apparent to me I must confess.

Re: 50 years of C, the good, the bad and the ugly [video]

#150

Post by addaon »

KerrAvon wrote: post #76
sirsinsalot wrote: post #34

Earlier quoted context omitted.

Anyone discouraging a particular tool without actual context of the problem being solved gets zero respect from me. It's a massive red flag that they don't know enough to be useful. C is great for the things C is great for, however small that range may or may not be now and in the future. Any other stance is reductive and misleading.

Exactly what, in the year 2023 C.E., is C great for? I’ve been writing C since 1991 and I can’t think of anything where I wouldn’t start a new project in some other language. There are many interesting choices of varying maturity in the low-level systems programming space: Zig, Rust, Crystal, D, Swift (if the standard library ever gains support for system-level programming). Even the “better C” subset of C++ will all…

> Exactly what, in the year 2023 C.E., is C great for?

Implementing low-level code that is important enough to prove correct, without going through the additional effort of de novo proving your entire toolchain is correct.

Post reply on HN