Earlier quoted context omitted.
I believe the main culprit is that the compiler guys want to optimize away Cpp templates, where programmer intent is not as explicit as in C.
C has enough UB of its own, no need to bring C++ into the picture.
50 years of C, the good, the bad and the ugly [video]
161–170 of 257 posts
Re: 50 years of C, the good, the bad and the ugly [video]
#162He says something like >"if you want to write new program in C now think long and hard and pick something else" I would not use plain C to write enterprise backend servers. I happily use modern C++ for that. For some very low power microcontrollers however I absolutely would. Amount of high quality free tooling and libraries beats everything else. From a practical point of view: I've written enough firmware for very…
I tend to think unless perform/$ is really important one should use a managed language for that, that isn't Javascript.
But yeah, not really sure what some other language would buy me in the small embedded space that earns me my beer money. I recently had an issue where the corporate spyware was convinced make/gcc were up to no good resulting in minute and a half compile times instead of the usual 10 seconds. I spent a bunch of time with IT getting that fixed. Well that's the build time I'd get with Rust. So Rust is a big nope. C++ is not that slow but still slow. And C++ without malloc is well who are we trying to kid here.
Re: 50 years of C, the good, the bad and the ugly [video]
#163Earlier quoted context omitted.
C++ for starters, would already be an improvment, provided string, array and vector classes with bounds checking, get used instead of raw C pointers. Alongside RAII for resource management.
For most embedded stuff those are just extra hassle and not worth it. C and its raw pointers and are really all you need most of the time. The need to have some discipline and expertise to produce solid code with confidence is not a bad thing in the embedded domain. If the code truly is critical you need to dive deep into verification techniques anyway.
Re: 50 years of C, the good, the bad and the ugly [video]
#164Earlier quoted context omitted.
C would be a better language if it really lived up to its old ideal of being a "portable assembly language". That stopped being true as compilers started optimizing undefined behavior (e.g. signed overflow). Instead of a "+" in the source code yielding an honest-to-goodness hardware add instruction, it could be "optimized"--i.e. constant folded, CSE'd, strength-reduced, value-range-analyzed, among others--by an optim…
> if it really lived up to its old ideal of being a "portable assembly language". What "old ideal" ? Where do you believe this "ideal" was expressed? Should I expect to find it in the First Edition K&R perhaps? Or in the documentation for the original C compiler? In the ANSI standard ? C was never this mythical "portable assembly language" that's just something people say about it, mostly to ridicule it, you are enga…
"The language is also widely used as an intermediate representation (essentially, as a portable assembly language) for a wide variety of compilers, both for direct descendents like C++, and independent languages like Modula 3 [Nelson 91] and Eiffel [Meyer 88]. "
Re: 50 years of C, the good, the bad and the ugly [video]
#165I bought a C compiler at my job in 1984 because I thought it was the future, then spent nearly a decade writing MacOS apps in C. I even added object extensions to it (for our use) in 1989 because C++ was not an option yet. I worked with Objective-C in the late 90s and again in the 2010s, which is basically C with funky object stuff. I don't miss it at all. C is very low level and so easy to write bad code in if you d…
Re: 50 years of C, the good, the bad and the ugly [video]
#166Earlier quoted context omitted.
I like C89 for its simplicity too but after using the Jai beta for over a year I have a hard time seeing myself ever going back.
I'll probably give Jai a go when it is released, but I am a bit afraid the idiosyncrasies are already creeping up.
Re: 50 years of C, the good, the bad and the ugly [video]
#167Earlier quoted context omitted.
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 j…
There are plenty of interesting C works out there, as well as data structures or algorithms that C can express elegantly. Small example, linked lists. I don't think non-C linked list code tends to be as straightforward as I've seen in C. Or the character-at-a-time style of string processing. It's kind of unique to C. You can say there is stuff about that you don't like. That's fine. Linked lists suck with modern CPU…
To be fair, the most straightforward definition of the linked list is generic, and C completely lacks such facility.
> fascist-
Sounds familiar.
Re: 50 years of C, the good, the bad and the ugly [video]
#168Earlier quoted context omitted.
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…
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.
Thankfully returns in digital stores, warranties in consulting projects, lawsuits in business losses and cybersecurity bills are slowly changing that.
Re: 50 years of C, the good, the bad and the ugly [video]
#169I maintain that C is fine and optimising compilers converting 'bad' C into dangerously broken binaries is not fine. We don't need to replace C to make it safe, we need to take the edge off undefined behaviour justified compiler rewrites.
I believe the main culprit is that the compiler guys want to optimize away Cpp templates, where programmer intent is not as explicit as in C.
Re: 50 years of C, the good, the bad and the ugly [video]
#170It is not hard to say what is unique about C: it and Forth are the only high level languages with seamless access to memory. If other languages offer it at all, like PEEK and POKE and Basic, it is far more awkward and interrupts your flow. That might be a good thing - the ESPOL compiler mentioned in the talk would print a big fat warning "YOU MUST KNOW WHAT YOU ARE DOING!" after any line in your code doing C-like tricks.