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

C isn't a programming language anymore (2022)

faultlore.com

Post reply on HN
Print view View original

201–210 of 217 posts

Re: C isn't a programming language anymore (2022)

#201

Post by xigoi »

okanat wrote: post #6
nacozarina wrote: post #3

None of the alternatives have stability. What was exemplary & idiomatic rust pre-pandemic would be churlish & rejected now and the toolchain use would be different anyway. Carpenters, plumbers, masons & electricians work on houses 3-300 yrs old, navigate the range of legacy styles & tech they encounter, and predictably get good outcomes. Only C has, yet, given use that level of serviceability. C99, baby, why pay more…

The replacement has already happened. It is HTTP and JSON for 99% of the software developed today. The reason C stayed has multiple reasons but most obvious ones are for me are: - People just stopped caring about operating systems research and systems programming after ~2005. Actual engineering implementations of the concepts largely stopped after the second half of 90s. Most developers moved on to making websites or…

> C hit a perfect balance of being a small enough language to grok, being indepedent of the system manufacturers, reflecting the computer architecture of 80s, actually small in syntax

C is a complex language with complex syntax. The C specification is, like, 800 pages. And good luck implementing a C parser as easily as you could a Scheme parser.

Re: C isn't a programming language anymore (2022)

#202

Post by rramadass »

haberman wrote: post #74
drnick1 wrote: post #31

Earlier quoted context omitted.

Yes and no. Clearly what you said is true, but the more profound reason is that C just minimally reflects how computers work. The rest is just convention.

More concretely, I think the magic lies in these two properties: 1. Conservation of mass: the amount of C code you put in will be pretty close to the amount of machine code you get out. Aside from the preprocessor, which is very obviously expanding macros, there are almost no features of C that will take a small amount of code and expand it to a large amount of output. This makes some things annoyingly verbose to cod…

Nicely put!

Haven't seen C's allure quite explained that way.

Re: C isn't a programming language anymore (2022)

#203

Post by direwolf20 »

donkeybeer wrote: post #194
direwolf20 wrote: post #193

Earlier quoted context omitted.

So you write a timer app that counts in milliseconds in an int variable, and it works on your machine where that's 32 bits. I compile it for Arduino, and I can't set a timer for longer than 32 seconds in the future. Isn't that a problem? You shouldn't have used int — you should have declared a maximum time value (99:59:59) and how many bits are needed to store that value. In what situation is plain int sufficient? If…

A ms beat in arduino sounds a bit demanding, idk how much a software based 32 bit would eat into the beats budget but I did say if we know the bounds of the problem explicitly that's a valid case for known fixed bit lengths.

The Arduino framework has a millisecond timer always running unless you turn it off.

Re: C isn't a programming language anymore (2022)

#204

Post by direwolf20 »

donkeybeer wrote: post #200
chuckadams wrote: post #197

Earlier quoted context omitted.

Bit fields? (Assuming one's not using a struct)

Good point. Yes if we need more than 8 flags we might need to consider one of the fixed length types.

Why 8? Some computers have smaller types. C has smaller types, as bitfields, but they're second–class. Why not just always specify the bits you need?

If you think 16 is probably enough and don't want to calculate, then specify 16.

Re: C isn't a programming language anymore (2022)

#205

Post by rramadass »

ghosty141 wrote: post #118
1718627440 wrote: post #100

Earlier quoted context omitted.

C is super close to the hardware in that it works exactly like the abstract C machine, which is kind of a generalization of the common subset of a lot of machines, invented to make it portable, i.e. viable to be implemented straightforwardly on various architectures. For example pointer provenance makes it work on machines with segmented storage, these can occur anywhere, so there is no guarantee that addresses beyon…

The C abstract machine is exactly the important part. There is a difference between saying C is close to "the hardware" and C is close to the C abstract machine. The latter like you described has a few concepts that allow for abstraction and thus portability but obviously they lead to situations where the "maps to the hardware" doesn't seem to hold true. My gripe is only with people acting like the C abstract machine…

> The C abstract machine is exactly the important part. ... My gripe is only with people acting like the C abstract machine doesn't exist and C is just syntax sugar for a bit of assembly. It's a bit more involved than that.

Most people have no understanding of an abstract machine though the very idea of a high-level programming language is based on it.

The C Language Standard itself specifies "Program Execution" only on a "Abstract Machine". Mapping that abstract machine to an ISA/Memory on real hardware is the task of the C compiler. It can do this in any manner as long as the observable behaviour of the program is "as-if" it ran on the abstract machine.

Relevant quote:

A conforming implementation executing a well-formed program shall produce the same observable behavior as one of the possible executions of the corresponding instance of the abstract machine with the same program and the same input.

Further Resources;

Wikipedia Abstract machine - https://en.wikipedia.org/wiki/Abstract_machine

Abstract machines for programming language implementation (pdf) - https://www.rw.cdl.uni-saarland.de/people/diehl/private/pubs...

The Abstract Machine: A Pattern for Designing Abstract Machines (pdf) - https://www.plopcon.org/pastplops/plop99/proceedings/garcia/...

Re: C isn't a programming language anymore (2022)

#206

Post by rramadass »

pjmlp wrote: post #85
Nevermark wrote: post #75

Earlier quoted context omitted.

> the concepts of pointers, variable sizes and memory layout of structs all represent the machine at some level. Exactly. Everything in assembly is still one-to-one in terms of functional/stateful behavior to actual execution. Runtime hardware optimization (pinhole instruction decomposition and reordering, speculative branching, automated caching, etc.) give a performance boost but do not change the model. Doing so w…

Lets play a game of what ISO C can do, and no other systems programming language has similar feature available? If language extensions to ISO C are allowed, then same goes for my selection on competing systems languages.

You keep making these sorts of comments on various threads which tells me that perhaps you are not clear on the idea of an "Abstract machine" which underpins all high-level languages.

See my comment here for some references - https://news.ycombinator.com/item?id=46930253

The gap between the "C Abstract Machine" and the actual Hardware underneath is smaller than most other high-level languages. This comment by user haberman puts it very nicely - https://news.ycombinator.com/item?id=46910015

Re: C isn't a programming language anymore (2022)

#207

Post by rramadass »

uecker wrote: post #69
munificent wrote: post #25

Earlier quoted context omitted.

Care to share the answer with the rest of the class?

I am not sure what Filip's view on this is. But like to point out the article from Stephen Kell linked below which explains why C is an incredibly useful tool for systems programming and what distinguishes it from all other languages. https://dl.acm.org/doi/abs/10.1145/3133850.3133867

That is a nice article!

Thanks for the pointer.

Re: C isn't a programming language anymore (2022)

#208

Post by abcd_f »

pjmlp wrote: post #145
1718627440 wrote: post #105

Earlier quoted context omitted.

> but it should've been fixed long ago. Is 27 years for you not long ago enough? That's more than a generation away and closer to the invention of the language than today.

Worse than that, lets remember that WG14 rejected Dennis Ritchie proposal for fat pointers, and the C authors decided it was more fun to keep their own way with other programming languages than try to improve C from WG14. https://www.nokia.com/bell-labs/about/dennis-m-ritchie/varar...

I read through the RFC and I think it's fair it was rejected, because this was ultimately a half-measure, with severe usability restrictions.

Fat pointers are clearly a way to deal with arrays (and also get "slices" and non-zero terminated strings for free!), but it's just not possible to retrofit them into the language without breaking existing code.

Re: C isn't a programming language anymore (2022)

#209

Post by SkiFire13 »

kevin_thibedeau wrote: post #154
danhau wrote: post #108

Earlier quoted context omitted.

How will you know if your integer type is adequate for the problem at hand, if you don‘t know its size? Choosing the right type is a function of signedness, upper/lower bound (number of things), and sometimes alignment. These are fundamental properties of the problem domain. Guesstimating is simply not doing the required work.

C specifies minimum sizes. That's all you need 99% of the time. I'm always annoyed by the people who assume int is 32-bits. You can't assume that in portable code. Use long or ensure the code works with 16-bit ints. That is how the type system was meant to be used. int was supposed to reflect the natural word size of the machine so you could work with the optimum integral type across mismatched platforms. 64-bit plat…

This doesn't really agree with this OP statement:

> The programmer should rather prescribe intent and shouldn't constantly think about what size this should exactly have.

You still have to constantly think about size! Except now you have to think about _minimum_ size, and possibly use a too big data type because the correctly sized one for your platform had a guaranteed minimum size that's too small for what you want to do.

Re: C isn't a programming language anymore (2022)

#210

Post by SkiFire13 »

drnick1 wrote: post #29
mjg59 wrote: post #19

I really don't understand why people keep misunderstanding this post so badly. It's not a complaint about C as a programming language. It's a complaint that, due to so much infrastructure being implemented in C, anyone who wants to interact with that infrastructure is forced to deal with some of the constraints of C. C has moved beyond merely being a programming language and become the most common interface for in-pr…

I don't see that as a problem. C has been the bedrock of computing since the 1970s because it is the most minimal way of speaking to the hardware in a mostly portable way. Anything can be done in C, from writing hardware drivers, to GUI applications and scientific computing. In fact I deplore the day people stopped using C for desktop applications and moved to bloated, sluggish Web frameworks to program desktop apps.…

You're still thinking of C as a programming language but the blogpost is not about this, it's about using C to describe interfaces between other languages.

> because it is the most minimal way of speaking to the hardware in a mostly portable way.

C is not really the most minimal way to do so, and a lot of C is not portable anyway unless you want to become mad. It's just the most minimal and portable thing that we settled on. It's "good enough" but it still has a ton of resolvable problems.

Post reply on HN