Live data from Hacker News

C isn't a programming language anymore (2022)

faultlore.com

191–200 of 217 posts

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

#191
Rust is a good way to get bad C programmers to stop using C

But Rust evangelists cannot stop people from using any particular language

Assembly is the only language that matters. It's the only language the computer "understands"

Everything other language is just an abstraction over it

When it comes to abstractions not everyone has the same preferences

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

#192

Earlier quoted context omitted.

Arduino has 16-bit int, so the timer app will work up to 32.767 or 65.535 seconds, that is less than two minutes.

When you choose unsigned int for that type, you compare against UINT_MAX and return an EOVERFLOW, ENOMEM, EOUT_OF_RANGE or whatever you like when someone sets a timer greater than that. Or you choose another type, i.e. unsigned long which is guaranteed to take values to at least 4294967295. I happen to program for the Arduino platform recently and milliseconds in the Arduino API are typed unsigned long. If your decis…

Right, so you can't just use int.

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

#193

Earlier quoted context omitted.

So you've backtracked from most variables, to number of elements. For number of elements there's size_t. So again, when are "natural types" the right answer?

When the C was invented? I feel it'd have been much more burdensome and inhibited the authors of various compilers if they had to write software or otherwise emulation of all these lenghths on the archs of the time. Still today I'd say, you cited size_t, I think that's the most important type, otherwise we shouldn't make most uses of integers as named fixed lengths unless we are specifically performing some mathemati…

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 your values always fit in 16 bits, it works, but what's special about 16? A value that goes from 0 to 100 only needs 7 bits, so int is not efficient there either, you should have asked for 7 bits which would round up to 8 on most platforms. Arduino is an 8–bit platform that requires several instructions to add 16 bits to 16 bits — int isn't the most efficient type.

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

#194

Earlier quoted context omitted.

When the C was invented? I feel it'd have been much more burdensome and inhibited the authors of various compilers if they had to write software or otherwise emulation of all these lenghths on the archs of the time. Still today I'd say, you cited size_t, I think that's the most important type, otherwise we shouldn't make most uses of integers as named fixed lengths unless we are specifically performing some mathemati…

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.

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

#195

Earlier quoted context omitted.

Repeating a previous comment of mine ( https://news.ycombinator.com/item?id=32784959 ) about an article in Byte Magazine (August 1983) on the C programming language: From page 52: > Operating systems have to deal with some very unusual objects and events: interrupts; memory maps; apparent locations in memory that really represent devices, hardware traps and faults; and I/O controllers. It is unlikely that even a low-…

I've started describing what C does is breaking the third wall. Which in theater sis when the actors acknowledge they're in a play. C totally accepts breaking the third wall. And Pascal doesn't. Problem with C currently is the language is controlled by people that think programming languages should be like Pascal.

That would be the fourth wall

     ________
    |        |
    | actors |
    |        |
     audience

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

#196
post #87

Earlier quoted context omitted.

It is often said that C became popular just because Unix was popular, due to being free -- it just "rode its coattails" as you put it. As if you could separate Unix from C. Without C there wouldn't have been any Unix to become popular, there wouldn't have been any coattails to ride. C gave Unix some advantages that other operating systems of the 1970s and 80s didn't have: Unix was ported to many different computers s…

> Unix wasn't the first operating system to be written in a high-level language. The Burroughs OS was written in Algol, Multics was written in PL/I, and much of VMS was written in BLISS. None of those languages became popular. Of course, they weren't available as free beer with source tapes. > Apple replaced the original Macintosh OS with a system based on a Unix. Only because they decided to buy NeXT instead of Be.…

It also helped that Unix managed to run on machines that were boat anchors and doorstops compared to what you'd need for Multics.

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

#197

Earlier quoted context omitted.

So you've backtracked from most variables, to number of elements. For number of elements there's size_t. So again, when are "natural types" the right answer?

Tbh I am finding it a bit hard to think of a use of integers that either isn't a length or a mathematical operation, so I gotta say it does narrow things down.

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

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

#198

I remember reading some crank on slashdot decades ago seriously claiming that Windows was not an operating system. This type of argument hasn’t gotten any more intelligent since.

Following up, I see that's not really what the author was trying to say: it's that for a growing number of purposes, like gluing together two languages that aren't C, that the C ABI is still dominating things where the C language shouldn't even be involved.

Write clickbait, get kneejerk. I guess some other things are at least as old as C.

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

#199

Earlier quoted context omitted.

I've started describing what C does is breaking the third wall. Which in theater sis when the actors acknowledge they're in a play. C totally accepts breaking the third wall. And Pascal doesn't. Problem with C currently is the language is controlled by people that think programming languages should be like Pascal.

That would be the fourth wall ________ | | | actors | | | audience

It would. It's still an interesting description of the difference between C and Pascal, though.

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

#200

Earlier quoted context omitted.

Tbh I am finding it a bit hard to think of a use of integers that either isn't a length or a mathematical operation, so I gotta say it does narrow things down.

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.
Post reply on HN