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

191–200 of 536 posts

Re: The Development of the C Language (1993)

#191

Post by ok123456 »

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.

gcc had emitted simd instructions since the egcs days.

Re: The Development of the C Language (1993)

#192

Post by zer8k »

coliveira wrote: post #129
qsort wrote: post #12

Earlier quoted context omitted.

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.

I have grown somewhat tired of these ChatGPT responses. It's a tool...not a panacea. C is a fantastic, albeit somewhat complicated, language. The problem is a C programmer knows the quirks and ChatGPT will dump you some code that could have undefined behavior depending on the compiler. Will ChatGPT always use restrict correctly (for example)?

Re: The Development of the C Language (1993)

#193

Post by aneeshpoth »

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 last time I wrote C was for my OS class

Re: The Development of the C Language (1993)

#194

Post by c_crank »

junon wrote: post #27
Patrickmi wrote: post #9

Earlier quoted context omitted.

When I get to achieve my target 3 times faster using Go why should I waste my time following “functional ways” just to use to write project A

Rust is not "functional ways", though, and Go is certainly not devoid of annoyances (subjectively). Really wish people would stop having language wars and realize that languages are tools for a job. C is like a flathead screwdriver, C++ is like a philips, Rust like a torx and Go like a hex. You can probably use a flatheat or even a philips for the torx or hex screws but you probably shouldn't, because they're not the…

>Rust is not "functional ways", though,

Rust carries a lot of design decisions heavily influenced from ML and OCaml. The type system and exception handling implements things that look a lot like Monads, but with a bunch of boilerplate code thrown in due to the imperative execution. That sort of syntax turned me away from the language, and probably would for a bunch of other people who don't care for that kind of language design.

I struggle to understand a use case for Hare compared to the other C-sequel type languages.

Re: The Development of the C Language (1993)

#195

Post by cdelsolar »

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…

I am working on a translation of a game engine from Go to C with another coder. One of our end goals is to make it easily available via WASM in a web browser.

As to why work in C - it’s incredibly fast, it feels very powerful as long as we manage memory correctly. We use fsanitize, which is an amazing library that can find memory leaks, buffer overruns, etc etc and run it on all unit tests. I think fsanitize is essential to have in your tool belt if you’re doing any C programming at all.

A pretty direct translation from Go to C resulted in about a 125% speed up (ie the C code was 25% faster) and this was already very optimized Go code with no allocations. From Go to WASM the results were disappointing to say the least - WASM was about 32% the speed of Go and not at all easy to multithread (and a gigantic file). From C to WASM I got a much better 79% of native speed - would have wanted a little bit more, but this is much more doable, and we haven’t begun to optimize some parts of this engine yet. And Emscripten seems to have very good pthread support, which I will try soon.

Re: The Development of the C Language (1993)

#196

Post by keepamovin »

tacker2000 wrote: post #176
keepamovin wrote: post #171

I want to read this. I'm also interested in the story of how SHA-0 was developed internally in the NSA if anyone has any idea. I'm a little surprised at folks incredulity that C is used "nowadays". To me, there will always be a place for C. If you look at: - the bulk of the internet traffic - the bulk of the base OS systems and libraries it is running on I'd say 99.9% of that is written in C. Hence my surprise. I kno…

Dont forget embedded/iot/automotive etc… The use of C will even increase as every square meter of the globe is going to be littered with small connected devices.

Exactly! Tho I don't know much about that stuff so I thought, maybe there's a possibility they all be doin trend thangs like bein Rustaceans etc or Gophers even (if that's a thang still?)

Re: The Development of the C Language (1993)

#197

Post by estebank »

ajb wrote: post #42
w4rh4wk5 wrote: post #5

I wonder how much the pile of undefined behavior contributed to C's success. I can imagine that vendors picked C over alternatives due to C giving them more freedom with their implementation.

What you are thinking about there is perhaps implementation defined behavior, which is distinct from undefined behavior ; and the sequence was the other way round - hardware with different behaviors already existed, and not specifying them in the language allowed C to succeed because it wasn't tied to a particular machine. The answer is different for different kinds of undefined behavior , but spatial memory safety v…

> Integer overerflow is still not caught by default even in rust for efficiency reasons

Honestly, I don't think that was the right default, but it is configurable at the project level for release builds. If I were deploying tools, I would certainly enable them, just like the Android team does.

Re: The Development of the C Language (1993)

#198

Post by tharne »

moffkalast wrote: post #19
qsort wrote: post #12

Earlier quoted context omitted.

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…

So we're gonna be stuck writing a precambrian prototype language till the end of time because there's so much legacy code already written in it? Never seemed to stop people moving from Pascal, or Perl or literally all other languages that are now obsolete. I really hate how for microcontrollers the only two choices are either C++ or Micropython, I mean how about some fucking middle ground instead of two polar opposit…

> At least eventually everything will be rewritten in Rust I guess.

This is the new "Year of the Linux Desktop".

Re: The Development of the C Language (1993)

#199

Post by throwaway17_17 »

marcosdumay wrote: post #181
chongli wrote: post #175

Earlier quoted context omitted.

I guess I will never understand the C and Java developers incredible fear of operator overloading. The answer is in the sentences right before the one you quoted: 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. Consider the use-cases for C: operating system kernels, hard real-time software, l…

The control flow is the same; you evaluate the parameters, and then evaluate the operator. Just like any other function call, there's nothing implicit or hidden. The only difference is that you can't create other operators with the same name for different types. And whether something is called or run inline is always decided by the compiler. Modern C doesn't promise you any relation between the way you break down you…

User defined functions require a function call pre- and post- amble to be added to the machine instructions that execute the function behavior. Typically this consists of growing the stack, adjusting required pointers at the top and then undoing that at the end. In C the operators defined by the language implementation do not involve any adjustments to the stack frame and do not invoke a ‘call’ or jump instruction in the assembly. Once operator overloading is possible this difference immediately becomes blurred.

Re: The Development of the C Language (1993)

#200

Post by zer8k »

markus_zhang wrote: post #177
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…

For me I use C because it's the de facto system programming language for botb Linux and Windows. Another reason is that C grammar is simple (but has a lot of quirks I do admit.)

Professionally I do Python. From my experience the breakages occur due to an over-reliance on libraries to do trivial tasks. Do you find a different case?
Post reply on HN