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

91–100 of 257 posts

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

#91

Post by mustache_kimono »

c7DJTLrn wrote: post #62
mustache_kimono wrote: post #58

Earlier quoted context omitted.

> AFAIK Torvalds has also stipulated that any Rust code needs to be mirrored in C. Do you have a cite for this? I hadn't heard this at all.

Apologies, I can't find a source. I probably read it on LWN somewhere. Linus wouldn't dip both feet into the water at the same time. I'm confident he's said that the kernel needs to be buildable without Rust if need be.

> I'm confident he's said that the kernel needs to be buildable without Rust if need be.

FWIW that's not the same thing? That's simply CONFIG_RUST=n, not "You have to write this driver twice in two different languages".

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

#92

Post by camel-cdr »

Koshkin wrote: post #84
siftrics wrote: post #54

Earlier quoted context omitted.

This shouldn't be downvoted. C++ is a superset of C; it must be capable of being at least as "brutal and honest" and "abstract and deceiving" as C. I would argue that C++ can be dramatically more deceiving than C --- see inheritance and operator overloading, just to name two.

Operator overloading is the one thing that makes C++ strictly better than any language that does not allow it.

How so? To me, operator overloading seems like a non feature, that at best create more ambiguity.

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

#93

Post by KerrAvon »

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

Classic K&R C? Where you declared the function arguments Pascal style out of line and had to rely on separate “lint” programs to check for typesafety in function calls?

Surely you mean C89, where functions have some type safety but C’s variable declaration syntax remains a horrible inelegant kludge?

Have you written much code in Swift?

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

#94

Post by Kototama »

JonChesterfield wrote: post #35

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

Saying C is fine, does not make it fine though. The facts speak for themselves: even the best programmers in this world which are extremely conscious about security have vulnerabilities in the software they wrote because of C. There were two remotes vulnerabilities in OpenBSD since it's creation, more recently there was a vulnerability in the ping utility of FreeBSD, etc.

C without undefined behaviors is not C anymore by the way. It would be something else.

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

#95

Post by matheusmoreira »

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.

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

#96

Post by sn41 »

enedil wrote: post #90
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…

Closure is not an anonymous function. It "encloses" variables that were in scope at the point of closure creation. Therefore function pointers cannot serve that purpose as is.

I agree, I should have used anonymous function specifically instead of a closure (for example, Ruby/Smalltalk closures are blocks, not functions.) Thanks for the correction.

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

#97

Post by warmwaffles »

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 simplicity is a blessing and curse. I enjoy writing C and sticking to a hard discipline of writing unit tests for all functions where possible. Abusing `assert/1` in debug mode. But concurrency is a hard thing to build. Identifying critical sections, making sure they have mutex locks where necessary. I want to love Rust but it's hard for me to get used to the syntax. I've started using it and failed multiple times because it's terse. Inevitably I will try again and hope it pans out.

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

#98

Post by WastingMyTime89 »

youarethejoke wrote: post #72
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…

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. Haskell - a language I personally despise - is semantically very rich. So is modern C++ for what it’s worth. C simply isn’t.

It’s even deceiving sometimes because it has the apparence of having some semantic elements (arrays for exemple) which are not there in reality and are really only syntactic sugar on top of other semantic constructions(pointers).

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

#99

Post by jokoon »

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 indentation, vector math, and nothing else, and make it as simple as possible.

I'm a bit tired of new language trying to do new things, I just want something less verbose than C, but not as powerful as C++, with the feeling of python.

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

#100

Post by Conscat »

camel-cdr wrote: post #92
Koshkin wrote: post #84

Earlier quoted context omitted.

Operator overloading is the one thing that makes C++ strictly better than any language that does not allow it.

How so? To me, operator overloading seems like a non feature, that at best create more ambiguity.

Without it, you cannot express arithmetic wrappers or simd wrappers. So far, no language with any users has managed to provide adequate arithmetic and simd types built in, despite several attempts like Odin and CosmiC/HolyC. I'm not sure it's even possible to design such types that satisfy everyone, and they must be extensible somehow because satisfying anyone is a moving target.

Note how terrible doing any amount of math is in C.

Post reply on HN