Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]

humprog.org

Post reply on HN
Print view View original

101–110 of 118 posts

Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]

#101

Post by scotty79 »

the_why_of_y wrote: post #62
mpweiher wrote: post #35

Earlier quoted context omitted.

Undefined behaviour being weird and having bizarre implications is not a feature of C. It is a feature introduced by compiler writers who prize esoteric optimisations more than simplicity. And it is not forbidden by the standard, though discouraged.

Following your argument: Use-after-free or double-free is undefined behavior. Therefore a C implementation that provides malloc(3) should provide an implementation of free(3) that is a no-op and provide a garbage collector that actually frees the memory.

> Use-after-free or double-free is undefined behavior.

It's an error even if it's undetectable by the compiler. I understand that nomenclature from few decades ago makes a distinction but nowadays we just call such thing an error.

Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]

#102

Post by Gordonjcp »

tialaramex wrote: post #95
Gordonjcp wrote: post #87

Earlier quoted context omitted.

> So it may be that your "clever" C algorithm which in your head translates into just six CPU operations, unfortunately on a real modern CPU is six hefty macro-ops that will take dozens of cycles to execute and repeatedly go to sleep waiting for main memory, whereas the algorithm in a modern language that looked ludicrous to your C programmer eyes compiles to sixteen tiny ops the CPU can consume two at a time with no…

I can give you a smaller example if that helps. Rust's u8::is_ascii_hexdigit is a predicate which decides whether the 8-bit unsigned integer is the ASCII code for a hexadecimal digit, that is 0 through 9, A through F or a through f. Inside the implementation is exactly what a modern programmer would expect, a pattern match, it'll do a whole bunch of arithmetic operations on the 8-bit unsigned integer and get a true o…

I can't say I've ever seen a lookup table method for that, going right back to implementing that kind of function on 8-bit CPUs.

Are you sure you're not just used to shitty code?

Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]

#103

Post by bluecalm »

tialaramex wrote: post #81
AshamedCaptain wrote: post #76

Earlier quoted context omitted.

> Which is easily shown to be false given that hardware designers have had bend backwards and into contorted shapes to emulate the hardware environment that C was originally created to work against. It may be a valid point, but value-less, since this basically implies that most hardware you are going to be able to buy today (ARM, x86, whatever) is going to be a fast PDP-11 (or at least it's going to present itself as…

Not quite. The modern hardware isn't actually a fast PDP-11 it's just capable of emulating one more efficiently than you would if people didn't insist on writing C. So it may be that your "clever" C algorithm which in your head translates into just six CPU operations, unfortunately on a real modern CPU is six hefty macro-ops that will take dozens of cycles to execute and repeatedly go to sleep waiting for main memory…

It might be but it isn't. The promise of clever modern language beating C in performance is almost as old as C and we are yet to see one.

Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]

#104

Post by waiseristy »

sacnoradhq wrote: post #70
waiseristy wrote: post #20

The primary benefit to C is that it is simple. And that is IMO the reason why it has such sticking power. The entire language & toolchain is understandable at a fairly core level without too much effort. Please don’t start a C flame war either HN. I know I’m nerd sniping you all on this one

I don't know what you mean by "simple". Little kids don't learn C, they learn Python. C has near universal portability. It's everywhere. That's the most important property.

> The entire language & toolchain is understandable at a fairly core level without too much effort.

That’s what I mean by simple. And that’s the reason why it also has universal portability. Cause it’s simple

Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]

#105

Post by torstenvl »

spacechild1 wrote: post #19
torstenvl wrote: post #5

Earlier quoted context omitted.

Your comment seems to assume C++ is a better, safer language than C. I know a number of people who would sharply question that assumption. I for one really hate destructors. They mean you can never tell what `delete` does. I remember a nasty double-free bug I had because of that.

First off, new/delete are only used for objects that are allocated on the heap. Even then, modern C++ has RAII wrappers such as std::unique-ptr. You should only need new/delete in rare cases.

By default, unique_ptr calls delete.

It therefore still calls the destructor.

So this has literally no bearing on the problem. It doesn't help at all.

Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]

#106

Post by tialaramex »

Gordonjcp wrote: post #102
tialaramex wrote: post #95

Earlier quoted context omitted.

I can give you a smaller example if that helps. Rust's u8::is_ascii_hexdigit is a predicate which decides whether the 8-bit unsigned integer is the ASCII code for a hexadecimal digit, that is 0 through 9, A through F or a through f. Inside the implementation is exactly what a modern programmer would expect, a pattern match, it'll do a whole bunch of arithmetic operations on the 8-bit unsigned integer and get a true o…

I can't say I've ever seen a lookup table method for that, going right back to implementing that kind of function on 8-bit CPUs. Are you sure you're not just used to shitty code?

GNU libc is an example of a relatively well known isxdigit() which uses a LUT even today.

Its excuse is that this simplifies locale handling, you know for if your locale has hexadecimal digits in a different place from everybody else, presumably because you're from some alternate universe where Z is a hex digit.

Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]

#107

Post by Ygg2 »

jstimpfle wrote: post #92
smitty1e wrote: post #77

Earlier quoted context omitted.

Everything us easy when you know how to do it. But that learning curve...

Nobody said it's easy. Programming is hard. The statement is that the language is _simple_.

Nobody mentioned programming. And hard/easy is a relative term. My easy != your easy.

Sharpened rock is a simple tool. Versatile too, but try using it to make a sculpture and it's going to be hard, very hard. Especially if you never used it extensively.

C is a simple language. No doubt about it. But doing multi-threading and memory safety in C is like trying to build a 100m tall structure using nothing but a sharpened rock. Possible but, why would you.

Java is a complex language. Lots of complexity. Classes, annotations, async, System.out and so on. But multi-threaded and memory safe (memory leaks allowed ofc) programs is as simple as just not using Java's array of unsafe tooling.

Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]

#108

Post by litoE »

tialaramex wrote: post #106
Gordonjcp wrote: post #102

Earlier quoted context omitted.

I can't say I've ever seen a lookup table method for that, going right back to implementing that kind of function on 8-bit CPUs. Are you sure you're not just used to shitty code?

GNU libc is an example of a relatively well known isxdigit() which uses a LUT even today. Its excuse is that this simplifies locale handling, you know for if your locale has hexadecimal digits in a different place from everybody else, presumably because you're from some alternate universe where Z is a hex digit.

But isn't that just a bad implementation in libc, rather than a problem with C itself? It should be trivial to rewrite isxdigit() copying rust's algorithm in C.

Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]

#109

Post by torstenvl »

tialaramex wrote: post #106
Gordonjcp wrote: post #102

Earlier quoted context omitted.

I can't say I've ever seen a lookup table method for that, going right back to implementing that kind of function on 8-bit CPUs. Are you sure you're not just used to shitty code?

GNU libc is an example of a relatively well known isxdigit() which uses a LUT even today. Its excuse is that this simplifies locale handling, you know for if your locale has hexadecimal digits in a different place from everybody else, presumably because you're from some alternate universe where Z is a hex digit.

This is a problem with glibc (it's also a violation of the C standard, since isxdigit is explicitly not affected by the current locale).

Other C libraries don't have this problem.

http://git.musl-libc.org/cgit/musl/plain/src/ctype/isxdigit....

Re: Some Were Meant for C – The Endurance of an Unmanageable Language (2017) [pdf]

#110

Post by [deleted] »

tialaramex wrote: post #106
Gordonjcp wrote: post #102

Earlier quoted context omitted.

I can't say I've ever seen a lookup table method for that, going right back to implementing that kind of function on 8-bit CPUs. Are you sure you're not just used to shitty code?

GNU libc is an example of a relatively well known isxdigit() which uses a LUT even today. Its excuse is that this simplifies locale handling, you know for if your locale has hexadecimal digits in a different place from everybody else, presumably because you're from some alternate universe where Z is a hex digit.

[deleted]
Post reply on HN