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

51–60 of 536 posts

Re: The Development of the C Language (1993)

#51

Post by tialaramex »

revskill wrote: post #4
ketzu wrote: post #3

This might miss a (1993) tag. Interestingly, some might print the same title about JavaScript.

So the conclusion is, Rust will never be a success because everyone loves it ?

Sure, that's the critique implied by C++ programmers quoting Bjarne: "There are only two kinds of languages: the ones people complain about and the ones nobody uses"

Except, we do complain about Rust (e.g. I think narrowing conversions should require TryInto or a specific call, not just 'as', and I don't think String impl Add is a good idea) it's just that we think the other options are far worse.

Re: The Development of the C Language (1993)

#52

Post by falcrist »

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…

Microcontrollers exist. Their libraries are written in/for C. The programs running on them are small and need tight, efficient memory management.

I also like the minimalist nature of the language itself. I get that for desktop applications, you usually want more integration with the operating system so you can say "I want a window here and a button here" rather than having to manually build the window from scratch, but that's not something that's a concern in most embedded systems.

I'm operating in a world of voltage inputs and outputs, memory mapped devices, registers, flags, and timings... with almost nothing between me and the hardware. A simple language makes a lot of sense here.

Re: The Development of the C Language (1993)

#53

Post by revskill »

tialaramex wrote: post #51
revskill wrote: post #4

Earlier quoted context omitted.

So the conclusion is, Rust will never be a success because everyone loves it ?

Sure, that's the critique implied by C++ programmers quoting Bjarne: "There are only two kinds of languages: the ones people complain about and the ones nobody uses" Except, we do complain about Rust (e.g. I think narrowing conversions should require TryInto or a specific call, not just 'as', and I don't think String impl Add is a good idea) it's just that we think the other options are far worse.

The intention is, in 2023, the original quote should be treated responsibly.

"Programming language like C, which is quirky, flawed, and should NOT be an enormous success" instead.

Re: The Development of the C Language (1993)

#54

Post by zabzonk »

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…

> and load from address 0x12345678

and most likely seg fault, or similar

Re: The Development of the C Language (1993)

#55

Post by davidhyde »

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…

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 only reasonable option is to blindly copy and paste an example project and hack away. I’ve never been able to “start from scratch”.

An embedded Rust project is the same as a normal Rust project except that you mark it as not linking the standard library !#[no_std] and you define a main entry point and panic behaviour (there are helper crates for this).

You can still use the core and alloc crates which give you pretty much everything you need in an embedded system like strings and vectors. You also get to use modern tooling like vs code and rust-analyser instead of a different antiquated version of Eclipse for each hardware vendor.

I don’t think that Rust should only be used for big projects. You can use it for small projects and you really don’t need to get complicated with generics for application code. You need to put in the effort to get a fundamental understanding about what the borrow checker is trying to achieve and the rest may be easier than you think.

Re: The Development of the C Language (1993)

#56

Post by anovikov »

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…

Small binary and a toolchain that's small and older than most programmers using it, and known to be bug-free. Top tool if you want to write something that a real human being can "get under the hood of" and understand throughout.

As for low-level, sure that's no longer the case. It was a low-level language for K&R and their PDP-11 where they could tell precisely what will be assembler code for each line of their C code and how many CPU cycles it will take. That's no longer the case indeed.

Re: The Development of the C Language (1993)

#57

Post by lordnacho »

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 used to think "C presents the most honest representation of the low-level mechanisms of the computer", but... even this is shaky. I've been programming for almost 15 years now, and I don't think I've ever seen a computer where memory is actually a continuous array of bits sorted by memory address. The C representation of memory (and all the pointer arithmetic) is not a real representation of your hardware, and this too is an abstraction.

It's true that almost nothing works the way it's presented: the computer doesn't necessarily actually do the instructions you specify, it does its machine commands that are compiled. It also doesn't necessarily even do them in the order they are specified. The memory isn't actually a big continuous space, it's mapped as virtual memory. The actual memory isn't used in that way either, there's a hierarchy of NUMAed caches between the CPUs and the actual memory.

But it's a useful abstraction. Partly because a lot of the above things are built so that the abstraction works. But also because we want it to look that way, and it's kinda natural to let programmers imagine a virtual machine that works that way.

Re: The Development of the C Language (1993)

#58

Post by _fizz_buzz_ »

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 use C for microcontrollers. I think Rust is making some inroads, but the libraries/tooling is not there yet.

Re: The Development of the C Language (1993)

#59

Post by xscott »

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…

The original author was talking about hardware not behaving like linear memory, and other than caches and maybe some thread local tricks, I'm not sure what he meant. However, it seems pretty clear that CPUs do try really hard to make:

    mov rax, qword ptr [0x12345678]
do what you think it would/should.

And as for the C memory model, aliasing, and optimizations, I'm firmly in the camp that thinks the standards originally gave the compiler writers an inch to work on weird platforms and they've taken a mile when they work on reasonable ones. The intent of your integer to pointer cast is very clear, but it's been undefined to insanity. So now there is some variant of the following, which doesn't have UB but does the exact same thing less clearly:

    uintptr_t i = 0x12345678;
    int* p = 0;
    memcpy(&p, &i, sizeof(int*));
    int x = *p;
I'm sure some language lawyer will correct me on some obscure detail of the standard, but it could be fixed with some modification. The point to me is that using memcpy instead of pointer casts is NOT an improvement. The good compilers will generate the same code as the assembly above, so all they've done is made the C source less readable.

Re: The Development of the C Language (1993)

#60

Post by adwn »

zabzonk wrote: post #54
adwn wrote: post #37

Earlier quoted context omitted.

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

> and load from address 0x12345678 and most likely seg fault, or similar

1. If the CPU lacks an MMU and the address falls into an accessible address space, it won't segfault.

2. If the CPU has an MMU, it won't segfault if the address is mapped to an accessible region of memory.

3. This is besides the point, because the CPU will execute the instruction and attempt to load from that address. A C compiler might emit the load instruction, or it might assume that this code branch will never be executed and can therefore be replaced with code that sends an angry email to your mother.

Post reply on HN