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

131–140 of 536 posts

Re: The Development of the C Language (1993)

#131

Post by msla »

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 there's no easier way to access various libraries.

Yes, that library does things with pointers the new language can't prove are safe. It's been used for longer than you've been alive and it isn't changing. If a new language can't express what it's doing, well, the library isn't going to move, the language is. Therefore, I either have odd shims and contortions or I have C.

I await a Buzz Language to eventually have "inline C" the way C has inline assembly.

Re: The Development of the C Language (1993)

#132

Post by versteegen »

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…

You didn't say what the checkboxes are, but... perhaps the 'BetterC' subset of D? https://dlang.org/spec/betterc.html#retained

Or D itself if you don't need a language as minimal as C. D is basically C++ redesigned and now that GCC includes D support by default I wonder whether it'll gain popularity.

Re: The Development of the C Language (1993)

#133

Post by mytailorisrich »

SkiFire13 wrote: post #43
mytailorisrich wrote: post #15

Earlier quoted context omitted.

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

Most modern hardware make use of registers and multiple layers of caches and you need ton of UB to justify the compiler making use of them.

Registers are orthogonal with memory layout. Cache does not change the general model.

Re: The Development of the C Language (1993)

#134

Post by flohofwoe »

9659 wrote: post #123
flohofwoe wrote: post #109

Earlier quoted context omitted.

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

Interesting choice, but Ada is probably even less popular than Zig.

Even just requiring users to integrate my hypophetical Ada library source distribution into their project's build system files would most likely drown me in support tickets ;)

Re: The Development of the C Language (1993)

#135

Post by zabzonk »

tester756 wrote: post #116
zabzonk wrote: post #110

Earlier quoted context omitted.

all compiled language systems must support a separate link stage, if they are to be of any practical use

But all of them must have low quality error messages too?

as i said, the linker only has so much information - whatever is supplied by the (possibly various) compilers and/or assemblers. which is minimal. so a linker cannot produce very accurate error messages. i'm afraid you are going to have to live with this, and understand it.

Re: The Development of the C Language (1993)

#136

Post by cvnamx »

adwn wrote: post #37
mytailorisrich wrote: post #15

Earlier quoted context omitted.

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

> the C representation closely matches what is actually happening It really doesn't, though. Although your CPU might present system RAM as one contiguous array of bytes to your program, the C compiler follows different rules – see strict aliasing and other pointer dereference rules. For example, the following is Undefined Behavior and your C compiler may or may not generate the assembly you expect: int x = *(int *)0x…

If you want to load from address 0x1234568, assign it to a char pointer first. Then the cast is legal and defined.

Your point that C is stricter than asm of course still stands.

Re: The Development of the C Language (1993)

#137

Post by [deleted] »

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…

[deleted]

Re: The Development of the C Language (1993)

#138

Post by Hirrolot »

dzaima wrote: post #38
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…

> cryptic "undefined behaviors" It's not really that cryptic (aside from like strict aliasing, but -fno-strict-aliasing). There's some UB that might be considered unnecessary/too strict, but it still makes sense in its own right, and, if understood, is quite powerful, and leads to a bunch of neat optimizations. > the language doesn't feel easy to use/debug If debugging at the assembly level, stepping by instructions,…

> Sure, a turing-complete compile-time language would be nice

I wrote Metalang99 [1] as a compile-time language that is able to perform loops, recursion, etc. It's not Turing-complete though, as the C preprocessor is not Turing-complete.

[1] https://github.com/Hirrolot/metalang99

Re: The Development of the C Language (1993)

#139

Post by enriquto »

moffkalast wrote: post #102
hnlmorg wrote: post #33

Earlier quoted context omitted.

> Never seemed to stop people moving from Pascal, or Perl or literally all other languages that are now obsolete. Operating systems written in Pascal are now obsolete. OSs in C are not. Perl is much easier to replace because fewer things were dependent on it however even here Perl 5.x still pops up all over the place.

Yeah to my great annoyance I did have to grep for an ipv4 address with a perl regex the other day. But for any actual scripting it's basically dead.

> for any actual scripting it's basically dead.

Run "file /usr/bin/* | grep -i perl | wc -l" on your computer. You will be surprised.

EDIT: if you want a histogram for all the types of programs in your system, run this

    file -bL /usr/bin/* | cut -d' ' -f1-3 | sort | uniq -c | sort

Re: The Development of the C Language (1993)

#140

Post by pjmlp »

zabzonk wrote: post #130
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.

Petzold did the same on his highly acclaimed book for Windows 3.x book, also with a note on the preface regarding type safety.

Likewise, Microsoft introduced windowsx.h header file, to improve type safety while using C for Windows 3.x applications.

Post reply on HN