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

181–190 of 257 posts

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

#181

Post by pyth0 »

Koshkin wrote: post #80
coldcode wrote: post #63

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

Only a mother could love Swift's syntax. The classic K&R C, on the other hand, was the very definition of simplicity and elegance. (Objective-C is a whole another topic, of course.)

I really don't understand this take at all. Swift has fairly standard syntax as far as modern languages go.

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

#182

Post by tialaramex »

pjmlp wrote: post #164
tialaramex wrote: post #127

Earlier quoted context omitted.

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

From Dennis himself, "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]. " -- https://www.bell-labs.com/usr/dmr/www/chist.html

That same document claims, "C's approach to strings works well" which, I mean I admire Dennis Ritchie but he's just wrong.

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

#183

Post by JonChesterfield »

matheusmoreira wrote: post #95
stephc_int13 wrote: post #64

The more I learn about new and less new languages (Zig, Jai, C#) the more I like C and its true simplicity. The language has a few irritating historical artefacts and the stdlib API is completely outdated and full of bad design, but there it is still versatile enough for my needs.

> the stdlib API is completely outdated and full of bad design It is also completely unnecessary on Linux. I switched to freestanding C and discovered it was a much better language. Made programming fun again. All I needed was one system call function and some entry point code. It's gotten to the point that it bothers me that gcc could potentially generate calls to mem* functions even in freestanding mode.

llvm does that too. It's really tempting to assume there's a libc available for the target architecture. On the list of things to clean up that hasn't hit top of stack for anyone.

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

#184

Post by rightbyte »

JonChesterfield wrote: post #169
rightbyte wrote: post #40

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.

I attribute it to benchmarks. Spec and the like. Where you can indeed make the benchmarks faster by leaning into UB. No signed overflow? Branch gone from that loop. Prove these two things can't alias because the pointer provenance model says they don't and you can rearrange the loads and stores. The collateral damage from that line of work is high though.

Ye you might be correct. I think they are overreaching a bit in the eagerness to optimize.

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

#185

Post by tmtvl »

estebank wrote: post #148
tmtvl wrote: post #70

Earlier quoted context omitted.

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.

Well people keep telling me that C/C++ code should be replaced by Rust for ~safety~ reasons, and LLVM is a C++ project, so...

Let's say it would avoid all the memory bugs in LLVM, that would doubtlessly make it worth throwing away the LLVM implementation (avoid sunk cost fallacy).

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

#186

Post by WastingMyTime89 »

asveikau wrote: post #153
WastingMyTime89 wrote: post #149

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

I am extremely familiar with C. I used to work on a static analyser for it. The issue is that there is very little to like in how C is designed from a PL point of view.

You are confusing what the language can do and what is semantic is.

C strings are just a contiguous allocation of byte and a bunch of functions which interprets it as ascii characters and stop on a specific value. That’s literally the worst representation of a string you can have.

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

#187

Post by FpUser »

Gibbon1 wrote: post #162
FpUser wrote: post #55

He 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 would not use plain C to write enterprise backend servers. I happily use modern C++ for that. 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 u…

>"I tend to think unless perform/$ is really important one should use a managed language for that, that isn't Javascript."

For my particular project managed language would simply not work. Way too slow. Besides the code base is relatively small and higher level language would not offer any compelling benefits.

>"minute and a half compile times"

Just checked. My particular project compiles under 1 second using Atmel Studio 7.

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

#188

Post by tialaramex »

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.

If anything, it's more likely that the desirable choice is to shift LLVM to Rust.

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

#189

Post by sylware »

tristanbvk wrote: post #24
sylware wrote: post #14

Earlier quoted context omitted.

C syntax is already way too rich and complex, not to mention the bazillions of gcc extensions required to compile the linux kernel. Namely, if it has to be "replaced", that would be with something with a much simpler syntax, which will require a bit more of finger power. We don't want to find ourself locked-in by very few compiler vendors (open source or not), that only because it is not reasonable to code a real-lif…

These are good ideas. The simplicity here is what I am going for.

On the long run, it all depends on syntax stability which is tightly coupled with its complexity.

The "benchmark" to run to evaluate syntax complexity toxicity, for a compiled language, is how long an alternative compiler written by a small teams of averagely skilled devs, or even one individual averagely skilled dev, can stay a "real life" "working" alternative.

Mid-term/long-term planned obsolescence of computer language syntax is really...

Oh, and in my previous post: for compile time constants we can use static consts, my bad.

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

#190

Post by Hemospectrum »

KnowOneYouNo wrote: post #114
kovac wrote: post #30

Earlier quoted context omitted.

Can C really completely go away as long as there's embedded programming? Are there any other alternatives for that domain?

Ada is a much better and modern alternative for embedded, real-time and/or systems programming. Its mature, (although still evolving) and very scalable from very, very small to very, very large systems. It also supports interoperability with C and C++. It is a primary language in GCC. See https://ada-lang.io/ and https://learn.adacore.com/ Unfortunately Ada is held back by a genuine lack of awareness and some old mis…

As strange as it might sound, the success of Rust seems to have reopened some doors for Ada. People in both communities are aware of this and already collaborating on various projects to mutual benefit.
Post reply on HN