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

The Development of the C Language (1993)

bell-labs.com

Post reply on HN
Print view View original

121–130 of 536 posts

Re: The Development of the C Language (1993)

#121

Post by coliveira »

kaba0 wrote: post #114
pkkm wrote: post #93

Earlier quoted context omitted.

> due to its low level of expressivity, you often have to introduce less efficient solutions simply because language deficiencies. Things like small string optimizations in C++ are simply not possible in C. You don't have to use an inefficient solution. You can always roll your own optimized solution or use a library. I agree that C++ has some nice string optimizations built into the standard library, but it's not ob…

> You don't have to use an inefficient solution. You can always roll your own optimized solution or use a library That’s not true. You for example can’t write a generic, efficient vector implementation in C - the language itself can’t do that. You either have to copy paste the same code for different sizes, or make use of some monstrous hack of a macro. Instead projects use hacks like conventionally placing the next/…

> hacks like conventionally placing the next/prev pointer in structs

This is not a hack, it is the way it should be in C.

Re: The Development of the C Language (1993)

#122

Post by binjooou »

kaba0 wrote: post #114
pkkm wrote: post #93

Earlier quoted context omitted.

> due to its low level of expressivity, you often have to introduce less efficient solutions simply because language deficiencies. Things like small string optimizations in C++ are simply not possible in C. You don't have to use an inefficient solution. You can always roll your own optimized solution or use a library. I agree that C++ has some nice string optimizations built into the standard library, but it's not ob…

> You don't have to use an inefficient solution. You can always roll your own optimized solution or use a library That’s not true. You for example can’t write a generic, efficient vector implementation in C - the language itself can’t do that. You either have to copy paste the same code for different sizes, or make use of some monstrous hack of a macro. Instead projects use hacks like conventionally placing the next/…

Generic things are rarely efficient, the most optimal code tends to be specialized and tailored to specific hardware and/or the kind of data its operating on.

std::vector (which is a really inefficient way of doing dynamic arrays btw) can be cleanly implemented with macros (see stb stretchy buf) or by splitting the element data from the housekeeping data:

  int append(void *arr, size_t elemsize, size_t *capacity, size_t *size, const void *items_to_add, size_t num_items_to_add);

Re: The Development of the C Language (1993)

#123

Post by 9659 »

flohofwoe wrote: post #109
moffkalast wrote: post #105

Earlier quoted context omitted.

Yeah if you want to kill yourself from frustrations, maybe. I'm not writing microcontroller code for the fucking space shuttle, and I would suspect most people aren't. C did a ton of things right, but it also did a ton of things wrong. Learning from that and moving on would be the sensible thing to do after 50 years.

Tell me an alternative which ticks all the checkboxes and I'll switch immediately. C++ isn't it because the committee has completely lost focus since ca C++11, Rust isn't it because they completely forgot about ergonomics, simplicity and elegance on their quest to fix memory safety (and both C++ and Rust suffer from "design by committee"). Zig looks perfect so far, but it's too early to switch over yet. Any other pro…

Ada. 83 or 95

Re: The Development of the C Language (1993)

#124

Post by xyzzy_plugh »

kaba0 wrote: post #107
enriquto wrote: post #75

Earlier quoted context omitted.

> People who still write C, honest question: Why? Because loops are fast. I do scientific computing, where many people use python nowadays, and a few years ago it was matlab/octave. These languages feel "cramped" because they artificially force you to program in a certain way in order to avoid loops. While such a "vectorial" notation is often useful, many algorithms are better expressed using a loop notation, and C d…

C has no in-built way to deal with SIMD, which is essential for high-performance computing over loads of data. On that count alone it is already out of the game.

What are you talking about? "in-built"? Have you ever written SIMD assembly before? It's comically easy to integrate SIMD optimizations into a C program.

Re: The Development of the C Language (1993)

#125

Post by kevin_thibedeau »

mytailorisrich wrote: post #15
babarock wrote: post #6

People who still write C, honest question: Why? C is full of quirks. From cryptic "undefined behaviors" to a type system that isn't really a type system (more like "size hints for the compiler"), the language doesn't feel easy to use/debug. Add to this CPP macros, a universally recognized bad idea, a clunky import system, and lack of a single reference implementation of the compiler/libC, and you have a language that…

> The C representation of memory (and all the pointer arithmetic) is not a real representation of your hardware, and this too is an abstraction. By and large memory is a contiguous array and the C representation closely matches what is actually happening, so I am curious about which platforms you have worked on.

Tagged memory architectures don't match the C model of linear memory. They're essentially obsolete now but C is still designed to accommodate them.

A lot of the UB the people grouse about can generally be ignored because 99% of the platforms out there have the same behavior in areas where the standard is extra permissive for obsolete exotic hardware. Tagged memmory is dead, 1's complement is dead, big-endian is mostly dead. All the UB associated with them is not that relevant most of the time. The downside is that people write code that takes a lot of liberties assuming behavior that the standard doesn't guarantee. A common one is unaligned access because x86 has always been permissive about it and it took until C11 to have power tools needed to manage it in the language.

Re: The Development of the C Language (1993)

#126

Post by coliveira »

kaba0 wrote: post #80
pkkm wrote: post #68

Earlier quoted context omitted.

1. It gives me a lot of control over how the program works, which lets me create programs that work faster and use less memory than would be possible in most other languages. 2. Relatedly, it's more explicit than almost any other language. If a line of code doesn't look like a function call, it's not calling anything. There is no hidden control flow. These statements are not true in languages which support operator o…

> It gives me a lot of control over how the program works, which lets me create programs that work faster and use less memory than would be possible in most other languages. While it is true to a degree, I would also add that due to its low level of expressivity, you often have to introduce less efficient solutions simply because language deficiencies. Things like small string optimizations in C++ are simply not poss…

People who know how to use C rarely if ever have problems with undefined behavior. I particularly have written a huge amount of C code and my bugs have never been related to undefined behavior. This is an idea that has been spread to make people even more afraid of using C/C++. While there is a possibility of finding these problems, in practice it is almost a non-issue.

Re: The Development of the C Language (1993)

#127

Post by Keyframe »

babarock wrote: post #6

People who still write C, honest question: Why? C is full of quirks. From cryptic "undefined behaviors" to a type system that isn't really a type system (more like "size hints for the compiler"), the language doesn't feel easy to use/debug. Add to this CPP macros, a universally recognized bad idea, a clunky import system, and lack of a single reference implementation of the compiler/libC, and you have a language that…

IT's an old war-time friend that when battle is up we both know how to shoot and be effective at it - both towards enemies as well as our feet.

Re: The Development of the C Language (1993)

#128

Post by kaba0 »

xyzzy_plugh wrote: post #124
kaba0 wrote: post #107

Earlier quoted context omitted.

C has no in-built way to deal with SIMD, which is essential for high-performance computing over loads of data. On that count alone it is already out of the game.

What are you talking about? "in-built"? Have you ever written SIMD assembly before? It's comically easy to integrate SIMD optimizations into a C program.

Through in-built assembly, or some compiler-specific annotation. None of them is vanilla C, which was my point.

Re: The Development of the C Language (1993)

#129

Post by coliveira »

qsort wrote: post #12
babarock wrote: post #6

People who still write C, honest question: Why? C is full of quirks. From cryptic "undefined behaviors" to a type system that isn't really a type system (more like "size hints for the compiler"), the language doesn't feel easy to use/debug. Add to this CPP macros, a universally recognized bad idea, a clunky import system, and lack of a single reference implementation of the compiler/libC, and you have a language that…

Because everything speaks C. If you write a library in C, it can be easily exposed to a variety of high-level languages and platforms. You might argue this is more a property of the C ABI than of C itself, but unless the project is large enough that it's worth doing it in C++ or Rust instead, it's still a very reasonable choice. Also not everything is web. Sure, if you're writing API endpoints in C you're just shooti…

I believe that with the arrival of ChatGPT and similar tools, writing code in C will become as easy as in any other language. The AI tools know how to generate good C code, and C is fast by itself. I believe we'll see a lot more code written in C now that we have new tools to analyze C code.

Re: The Development of the C Language (1993)

#130

Post by zabzonk »

pjmlp wrote: post #119

"Although the first edition of K&R described most of the rules that brought C's type structure to its present form, many programs written in the older, more relaxed style persisted, and so did compilers that tolerated it. To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for…

they should simply use c++, like k&r did to compile their example code in their 2nd ed - see preface to book if you don't believe.

i will never understand why C programmers get so upset about C++. of course, the latest revisions of C introduce some new features not in C++, but nothing really major. if you want good type checking, compile your C code with C++, and fix all the type errors you will get.

Post reply on HN