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

91–100 of 536 posts

Re: The Development of the C Language (1993)

#91

Post by zabzonk »

tester756 wrote: post #84
zabzonk wrote: post #81

Earlier quoted context omitted.

that's the linker, not the c compiler

Is this important? I treat compiler as *full* toolchain I run compilation and expect sane error messages - saying that "oh, it's because of linker yada yada" doesn't solve my problems nor is valid excuse Other language (compilers) do better.

> I treat compiler as full toolchain

well, you may do that, but it doesn't make it so. the linker has much less information to go on than the compiler - basically (depending on how you compiled) machine code. actually, the GNU linker does quite a good job, given what it has to work with.

> Other language (compilers) do better.

a language is not a compiler

Re: The Development of the C Language (1993)

#92

Post by kps »

zabzonk wrote: post #2

i had read this before, and it has been posted here multiple times, but somehow i had missed: > Thus the core C language escaped nearly unscathed from the standardization process, and the Standard emerged more as a better, careful codification than a new invention. which made me grin.

In 1993 the unintended consequences of X3J11 “undefined behavior” had not yet emerged, nor had the reality that future Standard committees would double down rather than fix it.

If anyone had realized what UB would turn out to mean, it would not have been invented that way. Dennis Ritchie's 1988 comments on the `noalias` proposal match exactly: “the committee is planting timebombs that are sure to explode in people's faces”; “a license for the compiler to undertake aggressive optimizations that are completely legal by the committee's rules, but make hash of apparently safe programs”, and consequently: “[It] must go. This is non-negotiable. [...] The concept is wrong from start to finish. It negates every brave promise X3J11 ever made about codifying existing practices, preserving the existing body of code, and keeping (dare I say it?) ‘the spirit of C.’”

Re: The Development of the C Language (1993)

#93

Post by pkkm »

kaba0 wrote: post #80
pkkm wrote: post #68

Earlier quoted context omitted.

1. It gives me a lot of control over how the program works, which lets me create programs that work faster and use less memory than would be possible in most other languages. 2. 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. These statements are not true in languages which support operator o…

> It gives me a lot of control over how the program works, which lets me create programs that work faster and use less memory than would be possible in most other languages. While it is true to a degree, I would also add that due to its low level of expressivity, you often have to introduce less efficient solutions simply because language deficiencies. Things like small string optimizations in C++ are simply not poss…

> due to its low level of expressivity, you often have to introduce less efficient solutions simply because language deficiencies. Things like small string optimizations in C++ are simply not possible in C.

You don't have to use an inefficient solution. You can always roll your own optimized solution or use a library. I agree that C++ has some nice string optimizations built into the standard library, but it's not obvious to me that they're always better than the simplicity and predictability of a simple chunk of memory.

Besides, you generally don't write C code in the same way you write C++ but with more primitive tools. You often allocate a buffer once and operate on it; you don't emulate passing strings by value from function to function, doing lots of allocations and deallocations in the process.

> Well, will it really compile to what you meant? If you have UB, it might still compile but the semantics of your program could change entirely depending on which compiler and which version you use.

I'm not sure what point you're making here. If you have bugs in your program then it may work incorrectly, yes, but that's true no matter the language.

Re: The Development of the C Language (1993)

#94

Post by shrubble »

davidhyde wrote: post #55
moffkalast wrote: post #19

Earlier quoted context omitted.

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…

Embedded Rust has been a viable option for at least 4 years now and especially so for the past 2 years. I really dislike having to learn the quirks of building, configuring and navigating typical embedded c based projects. They always seem to have an excessive amount of tiny files (in various languages) all over the place with obscure heuristics only the original authors know about. IMO, to build anything new your on…

While it seems Rust supports ARM devices like M0, M4 and of course more powerful chips like those capable of running Linux, there are huge swathes of chips that it doesn't support like 8051, PIC etc.

Re: The Development of the C Language (1993)

#95

Post by camel-cdr »

badsectoracula wrote: post #29
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 don't write C as much as i used to but i still write a lot of it, including new code. The reasons are: 1. C is relatively simple. Sure, not as simple as it could be (e.g. compared to something like Oberon-07) but in the grand scheme of language things, it is far on the simpler side of the spectrum. I can write a C parser relatively easy if i want to for example (and at some point years ago i did that to transpile a…

> let me store some state or have a loop

This is arguably already possible, and was possible even before c99 added variadic macros. Although the code is a bit cumbersome to write.

Re: The Development of the C Language (1993)

#96

Post by flohofwoe »

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…

Quite simply there haven't been any candidates so far which both got the "essence" of C and had the momentum to actually replace C. Zig looks like the most promising so far, if they don't fuck up on their way to 1.0

(disclaimer: I switched back from C++ to C as my language of choice for writing libraries ca 2017, but also continue to write C++ (if necessary to talk to C++ libs) and a lot of Python and Typescript for simple cmdline tools and web stuff, also ObjC on Mac of course for talking to system frameworks, in recent years dabbled with Rust, Odin and Nim, in the long distant past also with C#, Java, Lisp and some Forth, and eventually hope to transition over to Zig for the stuff I currently use C for (maybe in 3..5 years?)

TL;DR: use the language that suits a problem best, and C is a very good tool to have in any language toolbox, because it can usually provide a solution where other languages have to give up or just become to much of a hassle (for various reasons)

Re: The Development of the C Language (1993)

#97

Post by sgt »

pkkm wrote: post #68
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…

1. It gives me a lot of control over how the program works, which lets me create programs that work faster and use less memory than would be possible in most other languages. 2. 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. These statements are not true in languages which support operator o…

With C23 there's the #embed feature. Might be super useful for embedded software. How are the toolkits e.g. for ESP32 and TI in terms of C23 compatibility?

Re: The Development of the C Language (1993)

#98

Post by jjgreen »

tester756 wrote: post #86
jjgreen wrote: post #74

Earlier quoted context omitted.

Uh? gcc (11) produces, eg /usr/bin/ld: main.o: in function `main': /cptutils/src/xycpt/main.c:148: undefined reference to `xycpt' You get the file, the line, the name of the missing symbol ...

Everything looks fine if you use hello world examples Yet when reality kicks in, then you can spend 15mins trying to figure what the hells is going on

Not a hello world example, I renamed a function in a program which is part of a 13K LoC project to get that error message.

Re: The Development of the C Language (1993)

#99

Post by bigbacaloa »

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…

To add to this, with a flathead screwdriver you can open a beer bottle, kill someone, make holes in a wall, nada all sorts of other useful things.

Re: The Development of the C Language (1993)

#100

Post by moffkalast »

pkkm wrote: post #79
moffkalast wrote: post #19

Earlier quoted context omitted.

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…

> I really hate how for microcontrollers the only two choices are either C++ or Micropython Why wouldn't you just use C for programming a microcontroller? Sure, it's not a great language for web backends, but microcontrollers are where it shines. You're probably not deploying 100,000 lines to a microcontroller for a personal project, so the lack of certain abstractions isn't going to be that painful. On the other han…

Why wouldn't you use assembly for programming a microcontroller? Sure, it's not a great language for web backends but microcontrollers are where it shines. /s

Because as the OP states, it's an objectively (pun intended) terribly abstracted language. There is nothing 100% predictable about C except that you'll eventually get screwed because you didn't account for some random obscure thing that should never have even been possible to do. Any language that allows using static variables can have predictable memory consumption. There is nothing inherent to it that makes it better than a language that works at the same level but built to modern standards, except the piles upon piles of legacy code you can use.

Post reply on HN