Live data from Hacker News

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

streaming.media.ccc.de

191–200 of 257 posts

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

#191

Earlier quoted context omitted.

No, I'd count Zig as having more of an "open ended" type system / philosophy. Though, it looks like Zig doesn't do function overloading either [1]. That's a disappointment. So you end up with `array_count`, `map_count`, etc instead of just `count`. In my way of thinking that's more work reduces readability. It's one of the paint points of C vs C++ to need `array_list_count` and `hash_map_add` instead of just saying `…

One of the main drawbacks of function overloading is that it can make code harder to read and understand. When the same function name is used for multiple different purposes, it is confusing for developers who are reading the code. This makes it more difficult to maintain and modify the code in the future, as developers spend extra time trying to understand the various function definitions and how they are being used…

> it is confusing for developers who are reading the code. … as developers spend extra time trying to understand the various function definitions and how they are being used.

This is a similar argument to Hungarian encoding, IMHO. A decent LSP makes it trivial to see which function is being called. The other issue you mention is a problem with the debugger/compiler, not function overloading.

> Even finding what file the function is in can be a non-trivial task.

Not really, control-click and you’re at the function def.

> it can be difficult to determine which function is causing the issue. This can make it more time-consuming to fix the bug and can lead to frustration for the developer.

Not any harder than “method” overloads, which it sounds like Zig does have.

Personally I find the opposite. Having 20 names for functions that all equate to `len` requires more mental overhead.

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

#192
post #2

His final conclusion is that C has to go, just like COBOL, Fortran, and PL/I. I wonder how long it will take before C will be gone totally when you realize how much COBOL and Fortran are still around. Not so long ago, I came along a module for Python 'SciPy.interpolate' that happens to be programmed in Fortran.

In a way, it's already happening. Many big tech companies are now defaulting to other languages than C and are actively discouraging the use of C or C++ for new code. They still have a big vested interest in maintaining existing code of course. That's not going to disappear overnight obviously.

Do you have examples? Is it all going towards Rust or are there other big tech-backed contenders?

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

#193
post #41

A different take on the matter: I write code mainly artistically, and I found that C is one of the best languages available to code as a form of art. It allows to be both brutal and honest, or abstract and deceiving. Not many languages are so semantically powerful.

What are your goto sources of knowledge for C? I’m learning it to write embedded stuff and so far it’s mainly the k&r book, one from no starch press, and a udemy course. Thanks!

I think you’ll like Fluent C: Principles, Practices, and Patterns by Christopher Preschern (O’Reilly, 2022).

The books you have are excellent ways to learn the language, and this one complements them in that it lists common practices around, for example, error handling, and other common topics. It shows different approaches and mentions practices from real-world open-source C projects that follow them.

It seems like a good book to continue exploring C after learning the language.

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

#194
post #174

Earlier quoted context omitted.

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.

Those are fair points, but they're probably too specific to the architecture to incorporate in C's general execution model. They're better exposed through platform specific programming interfaces like OpenMP or CUDA. Even a domain specific language, like GLSL, may be more appropriate.

I think that the general point being made here is that C’s general execution model, as you call it, really is just a PDP-like computer because that is what they had when making C.

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

#195

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.

C++ is not a superset of C, there are plenty of legal C constructs that will trigger errors when compiled with a C++ compiler.

But most of them are new constructs, not found in the venerable C90.

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

#196

Earlier quoted context omitted.

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…

Also without operator overloading, it wouldn't be possible to implement lazy evaluation, which along with the use of expression templates happens to be one of the most crucial aspects that any linear algebra library will want to take advantage of in order to generate the most optimal code.

Operator overloading is syntax; lazy evaluation is semantics.

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

#197

Earlier quoted context omitted.

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

I think it's a nice representation, allowing easy recursion.

   const char *my_strchr(const char *str, int ch)
   {
     if (*str == 0)
       return NULL;
     if (*str == ch)
       return str;
     return my_strchr(str + 1);
   }
It's a good format for storage and communication.

Name any other string data structure and I will cite you all the disadvantages compared to the C string.

- If the format contains pointers, you have to marshal it to a flat representation to communicate or store it. The C string is already marshaled.

- If the format contains size fields, their own size matters: are they 16, 32, 64. What byte order? Again, needs marshaling. You might think not if going between two processes on the same machine. But, oops, one is 32 bit the other 64 ...

I shudder to think of what FFIs would look like, if C strings were something else. It's the one easy thing in foreign interfacing.

C programs themselves sometimes come up with alternative string representations, for good reasons; but those representations don't interoperate with anything outside of those programs, or groups of closely related programs.

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

#198

Earlier quoted context omitted.

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

If that static analyzer was itself written in C, you have one program's worth of C experience, which is very little.

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

#199

Earlier quoted context omitted.

What are your goto sources of knowledge for C? I’m learning it to write embedded stuff and so far it’s mainly the k&r book, one from no starch press, and a udemy course. Thanks!

I think you’ll like Fluent C: Principles, Practices, and Patterns by Christopher Preschern (O’Reilly, 2022). The books you have are excellent ways to learn the language, and this one complements them in that it lists common practices around, for example, error handling, and other common topics. It shows different approaches and mentions practices from real-world open-source C projects that follow them. It seems like…

Thank you!

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

#200

Earlier quoted context omitted.

What are your goto sources of knowledge for C? I’m learning it to write embedded stuff and so far it’s mainly the k&r book, one from no starch press, and a udemy course. Thanks!

Not the GP, but cppreference.com [1] is the best reference I've found for C (and C++) in 20+ years, short of just reading the standards themselves. [1] https://en.cppreference.com/w/c

Thank you!
Post reply on HN