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

101–110 of 217 posts

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

#101

Post by donkeybeer »

thayne wrote: post #67
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.

The things complained about in the article are not a minimal reflection of how computers work. Take the "wobbly types" for example. It would have been more "minimal" to have types tied directly to their sizes instead of having short, int, long, etc. There isn't any reason that compilers on the same platform have to disagree on the layout of the same basic type, but they do. The complaints about parsing header files c…

There were many different types of computers back then. Some even had 36 bit word sizes. I don't think there was any clear winner like amd64 back then that they could have prioritized. 16 and 32 bit machines existed in decent amounts and so on.

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

#102

Post by phicoh »

pjmlp wrote: post #88
AnimalMuppet wrote: post #41

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

The irony is that all wannabe C and C++ replacements are exactly the "Pascal model" brought back into the 21st century, go figure. "A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide…

The thing for me at least is that when I looked at Pascal, MODULA-2, Ada, if you had complex data structures which had to allocate and deallocate memory, then those language would not help at all. They would allow you to make pointer mistakes. Pascal and MODULA-2 were also very restrictive in various area (no generics). Ada is better in that respect, but Ada compilers were rare.

In my opinion it is only Rust that offers a language without runtime system requirement and fixes essentially all of the problems of C.

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

#103

Post by 1718627440 »

smallstepforman wrote: post #61

C’s biggest sins (also inherited by C++): - unspecified default type sizes. Should have had i8, u16, i32, u64, f32, f64 from the beginning. - aliasing pointers being restricted by default (ie an alias keyword should have been added). Performance matters. All these benchmarks which show something beating C or C++ are mostly due to dealing with aliasing pointers. C++26 still doesnt have standardised restrict keyword. T…

> - unspecified default type sizes. Should have had i8, u16, i32, u64, f32, f64 from the beginning.

I strongly disagree. The programmer should rather prescribe intent and shouldn't constantly think about what size this should exactly have. Does this variable represent the size of an object, an address, a difference or just a random positive integer? Then use size_t, uintptr_t, ptrdiff_t and unsigned int respectively. Why should I care what exact sizes these are? I hate that modern (system) languages completely throw away that concept. "I want a unsigned integer" "oh, you mean u32" "No! I really mean an unsigned integer."

Also when I do want e.g. 32 bit available, there is no reason, I need to use a suboptimal 32 bit wrapping behaviour when I don't need it. The correct type to use for computation for that would be uint32_fast_t and the implementation chooses what makes sense to use for this.

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

#104

Post by donkeybeer »

smallstepforman wrote: post #61

C’s biggest sins (also inherited by C++): - unspecified default type sizes. Should have had i8, u16, i32, u64, f32, f64 from the beginning. - aliasing pointers being restricted by default (ie an alias keyword should have been added). Performance matters. All these benchmarks which show something beating C or C++ are mostly due to dealing with aliasing pointers. C++26 still doesnt have standardised restrict keyword. T…

Which systems in the 70s or even 90s would have had good hardware support for all these lengths? I think overall perhaps its better that the thing named int works on both the arduino and my amd64 otherwise we might needlessly need to rename all types for each platform to fit the most natural type lengths there. Imagine the 32 bit to 64 bit transition under those conditions.

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

#105

Post by 1718627440 »

abcd_f wrote: post #70
smallstepforman wrote: post #61

C’s biggest sins (also inherited by C++): - unspecified default type sizes. Should have had i8, u16, i32, u64, f32, f64 from the beginning. - aliasing pointers being restricted by default (ie an alias keyword should have been added). Performance matters. All these benchmarks which show something beating C or C++ are mostly due to dealing with aliasing pointers. C++26 still doesnt have standardised restrict keyword. T…

Arrays decaying to pointers is probably the biggest non-platform specific design oversight. As you said, it's easy to see where it came from, but it should've been fixed long ago.

> 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.

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

#106

Post by 1718627440 »

krior wrote: post #72
smallstepforman wrote: post #61

C’s biggest sins (also inherited by C++): - unspecified default type sizes. Should have had i8, u16, i32, u64, f32, f64 from the beginning. - aliasing pointers being restricted by default (ie an alias keyword should have been added). Performance matters. All these benchmarks which show something beating C or C++ are mostly due to dealing with aliasing pointers. C++26 still doesnt have standardised restrict keyword. T…

Not the error "handling"? The array implementation? The weak type system? The barebones-macro-system? The nearly unuseable standard-library? The standard itself, a 750-page-tome you have to memorize, lest C is allowed to erase your hard drive? C is sin incarnated.

In my opinion error handling in C is great. It forces you to actually think about it, deal with them as close as possible and makes you write it in a forward compatible way. Much better than exceptions were you never no what one might throw in another version.

> The barebones-macro-system?

The CPP is a different language and designed that way so you can use another language that suits you better, most don't do that, because the default is fine.

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

#107

Post by okanat »

noosphr wrote: post #35
okanat wrote: post #6

Earlier quoted context omitted.

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…

I'd never thought I'd see the day that anyone praises COM.

Compared to wobbly types in C and hidden contracts due to C compiler internals, COM's IDL-based approach is much better!

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

#108

Post by danhau »

1718627440 wrote: post #103
smallstepforman wrote: post #61

C’s biggest sins (also inherited by C++): - unspecified default type sizes. Should have had i8, u16, i32, u64, f32, f64 from the beginning. - aliasing pointers being restricted by default (ie an alias keyword should have been added). Performance matters. All these benchmarks which show something beating C or C++ are mostly due to dealing with aliasing pointers. C++26 still doesnt have standardised restrict keyword. T…

> - unspecified default type sizes. Should have had i8, u16, i32, u64, f32, f64 from the beginning. I strongly disagree. The programmer should rather prescribe intent and shouldn't constantly think about what size this should exactly have. Does this variable represent the size of an object, an address, a difference or just a random positive integer? Then use size_t, uintptr_t, ptrdiff_t and unsigned int respectively.…

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.

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

#109

Post by pjmlp »

phicoh wrote: post #102
pjmlp wrote: post #88

Earlier quoted context omitted.

The irony is that all wannabe C and C++ replacements are exactly the "Pascal model" brought back into the 21st century, go figure. "A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide…

The thing for me at least is that when I looked at Pascal, MODULA-2, Ada, if you had complex data structures which had to allocate and deallocate memory, then those language would not help at all. They would allow you to make pointer mistakes. Pascal and MODULA-2 were also very restrictive in various area (no generics). Ada is better in that respect, but Ada compilers were rare. In my opinion it is only Rust that off…

First of all C did not had any generics, so same playing field.

C has a runtime, even if tiny. That is what calls into main(), handles floating point arithmetic when none is available, functions that run before and after main(), nowadays also does threading.

Heap memory handling in Pascal, Modula-2, Ada, is much safer than C, first of all no need to do math to calculate the right size, arenas are available on the standard library, dinamic allocation can also be managed by the compiler if desired (Ada), pointers are safe as they by default must be used with existing data, however if one really wants to do pointer arithmetic it is available.

The only issue that they have in regards to C, is the use-after-free, but that apparently isn't an issue for folks moving away from C into Zig, wich is basically Modula-2 with some C syntax flavour.

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

#110

Post by danhau »

donkeybeer wrote: post #104
smallstepforman wrote: post #61

C’s biggest sins (also inherited by C++): - unspecified default type sizes. Should have had i8, u16, i32, u64, f32, f64 from the beginning. - aliasing pointers being restricted by default (ie an alias keyword should have been added). Performance matters. All these benchmarks which show something beating C or C++ are mostly due to dealing with aliasing pointers. C++26 still doesnt have standardised restrict keyword. T…

Which systems in the 70s or even 90s would have had good hardware support for all these lengths? I think overall perhaps its better that the thing named int works on both the arduino and my amd64 otherwise we might needlessly need to rename all types for each platform to fit the most natural type lengths there. Imagine the 32 bit to 64 bit transition under those conditions.

All of them, through software implementation, as assembly programmers have done since forever.

You simply choose the integer type that your problem or task requires. If the hardware genuinely can‘t cope with it (performance), you reevaluate your requirements, define new constraints and choose new types. This is basic requirements engineering, which C only made more convoluted.

Post reply on HN