8 ms·

One of C's design principles is to be fast at the cost of safety, just like an F1 formula car. It will let you make fast mistakes. You drove a Corolla in colle

One of C's design principles is to be fast at the cost of safety, just like an F1 formula car. It will let you make fast mistakes. You drove a Corolla in college, then got a job and drove a cool BMW for several years and now you think you're hot shit, so you hope in an F1 car and not only does it take forever to learn how to drive it, it has to be driven on a special track and the gearbox is different, what a nuisance! "If only we could add 4 doors, automatic transmission, snow tires, and a trunk to put our stuff in, people won't keep getting into accidents with this car", you say. Right, but then it becomes a BMW. If you want real speed, you need to first go slow and master the car because otherwise you'll crash and burn. C is messy because real world hardware is very messy. You can't push bytes through the hardware at its speed limit without getting your hands dirty, and we all come out into the real world wearing "class Dog extends Animal" white gloves. To use C effectively, you should not be coding in C in your mind. You should be thinking in assembly, but your fingers should be typing C code. It's not safe, but if you want to reach 230MPH and accelerate at 60MPH in 2.6 seconds, you better know exactly what you're doing when you hop behind the wheel of that car. It's not for the weak.

continuational 5y ago
I like that analogy. You're saying that C should only be used in competitions, and not be allowed in the real world, right?
- creativemonkeys 5y ago
  I don't see a problem with using C in the real world, but if you're going to attempt to race on the highway and you don't know how to steer clear of potholes, don't go blaming the car when the wheels fly off. The car requires you to know how to drive at high speeds and a lot of people don't know how to, so instead of being honest with themselves, they look around and conclude that it must be the car's fault, because this many people couldn't possibly be that bad at racing. It's possible to become a better driver to handle the F1 car, just like it's possible to arrive at the same destination driving a Corolla, just 2 minutes later. If you want the speed though, you have to put in the effort.
samatman 5y ago
I upvoted this because hey, no lies detected. The problem is that this particular design principle of C is ready for a comfortable retirement in a beach community. The machismo is probably why you're getting dragged a bit, but the bottom line is that being intimate with the hardware is orthogonal to pointlessly segfaulting. C does both, Zig is aiming for one of these things and I'll let you guess which.
- creativemonkeys 5y ago
  A segfault lets the user know that the developer made a mistake, and where in the code it happened. Blaming C for segfaults is blaming the tool. C is a small language with a spec designed to adapt to new hardware while remaining fast. The spec is ambiguous in precisely the places where resolving the ambiguity would mean either limiting its portability or its speed. This increases the learning curve significantly and also requires diligence on behalf of the developer, so it's high effort to write. It's a perfectionist's language, because, if you can steer clear of the known pitfalls, you get a working piece of software that's maximally portable and fast, and fast is still what we want our tools to be. There is a place for Zig, and Nim and Rust in this world, but there is no world in which these tools make the same trade-offs as C and end up with a faster and more portable (across hardware) language. They can sacrifice speed to make it more difficult for the developer to make mistakes. They can sacrifice portability to make assumptions that resolve undefined behavior, which would also decrease the burden on the developer, but they will never get all three - correctness, portability and speed, so in that sense, they will never replace C, they can only hope to starve C of developers.
  - throwaway17_17 5y ago
    I think your breakdown of a language is a neat idea, the decomposing of implementations by there ‘scores’ in the three areas of correctness, portability, and speed. I think I’d like to replace speed with a performance score encompassing both speed and memory footprint though. I also agree that achieving high ‘scores’ in all three areas is a relative impossibility. For me, the best language is going to be the one that has a maximum in the performance area and is provably (at least to some reasonable measure) correct. I think portability between execution environments can be a loss for the types of things I enjoy programming.
comex 5y ago
There is nothing about the design of strtol that makes it particularly fast. If anything, the extra checks and accesses to errno (which on modern systems is generally an implicit function call) that are required to use strtol correctly represent unnecessary overhead, though only a trivial amount of it. But mostly it’s just an awkward API design.
ogogmad 5y ago
I think the brittleness of C's string handling functions is not a necessary consequence of anything you said. It's just sloppiness and inertia.
shadowofneptune 5y ago
You're right, we need to draw a distinction between the Real Programmers and the Quiche Eaters. A mere Java or Python user just isn't good enough, they can't write portable assembly like a Real Programmer can.
- creativemonkeys 5y ago
  Absolutely not. Once a user reads "Head First Java" or customizes Django sites, they get their standard issue keyboard and they're ready to start writing interrupt handlers in C. If the code crashes, it must be the language.
pyjarrett 5y ago
> C is messy because real world hardware is very messy Ada was designed for embedded systems specifically and has guards over many of the pitfalls in C. Still, it provides easy access to in-depth low-level control when you need it (assembly, intrinsics, binding variables to specific memory locations, importing C, creating your own custom allocators). The difference is that you write intent, and then paint additional control on top of that. This makes Ada also suitable for higher level applications.
adwn 5y ago
There's nothing fast about zero-terminated strings. In fact, many operations on them are much slower than sane alternatives, because they first have to scan the entire string to compute its length. You can't even create a temporary substring without either modifying or copying part of the original string. How lame is that? Zero-terminated strings are almost never the best solution, so why are they the language-supported default? > You should be thinking in assembly, [...] Well, then you shouldn't by typing in C, because Undefined Behavior coupled with modern C compilers will make sure that what you get is not what you thought. *cough* signed integer overflow * cough* > You can't push bytes through the hardware at its speed limit without getting your hands dirty Rust proves you wrong (maybe some other languages, too, but I don't know them as well)
- creativemonkeys 5y ago
  What you're missing is the difference between known issues and unknown issues. You're looking at a language that's been heavily used for 60 years and accumulated a long list of known issues and things not to do, that powers pretty much everything in computers, and you're comparing that with the new kid on the block with a vocal fanbase. You could invest your time into learning that finite list, or you could invest your time into learning a new language with a long list of _unknown_ issues yet to be discovered - but out of sight, out of mind, right? As far as runtime speed goes, assuming equal instructions being generated, if Rust spends even one CPU cycle checking array lengths, its generated code will be slower than C's, by definition. You can justify the trade-off ("it checks array lengths for me because I am human and I forget sometimes") or relax the restrictions ("it's not humanly noticeable"), but you can't claim it runs faster or even just as fast, because it's not. The only thing Rust proved to me is that there was a whole generation of developers who did't mind writing unreadable Perl code who had kids that are equally unaware of how unreadable Rust code is and it'll take a few decades for them to see that, assuming that Rust stays relevant for another decade.
  - adwn 5y ago
    > You could invest your time into learning that finite list, or you could invest your time into learning a new language with a long list of _unknown_ issues yet to be discovered That's a bad argument, because it could be used against any change or improvement. By that logic, humans should have never even come down from the trees. > if Rust spends even one CPU cycle checking array lengths That's the thing: Almost all checks and guarantees which make Rust safer than C are done at compile time and have no negative effect on the generated code.
School-Cotton 5y ago
This would be more justifiable if C had support for vector instructions, which are crucial for high-performance code on modern CPUs.
V_Terranova_Jr 5y ago
The F1 analogy is easy to use against this line of argumentation. Today's F1 cars are way faster than their predecessors. They are also safer, more automated, and in large part faster because they are easier to drive. The racing is more boring, and cars are uglier, but those are different topics. The idea that you can't maintain the runtime performance of C while innately supporting automated reasoning about invariants/safety just doesn't hold up. The idea is to move the whole Pareto front outward - that's what advancements in theory and technology do.
- creativemonkeys 5y ago
  They came, they saw, and they went away, and C is still the smallest, fastest and most portable language. I think the only way to dethrone C is to change the equation of what's expensive to do in hardware - accessing memory, and that's not a problem us software guys are going to solve.
TheFrigginDoC 5y ago
C was not designed to be fast. It was designed to be a bit simpler and a whole lot more portable then assembly code. The speed is a biproduct of how it does not try to do anything other then basically mapping perfectly to the hardware.

continuational 5y ago

I like that analogy. You're saying that C should only be used in competitions, and not be allowed in the real world, right?

creativemonkeys 5y ago
I don't see a problem with using C in the real world, but if you're going to attempt to race on the highway and you don't know how to steer clear of potholes, don't go blaming the car when the wheels fly off. The car requires you to know how to drive at high speeds and a lot of people don't know how to, so instead of being honest with themselves, they look around and conclude that it must be the car's fault, because this many people couldn't possibly be that bad at racing. It's possible to become a better driver to handle the F1 car, just like it's possible to arrive at the same destination driving a Corolla, just 2 minutes later. If you want the speed though, you have to put in the effort.

samatman 5y ago

I upvoted this because hey, no lies detected. The problem is that this particular design principle of C is ready for a comfortable retirement in a beach community. The machismo is probably why you're getting dragged a bit, but the bottom line is that being intimate with the hardware is orthogonal to pointlessly segfaulting. C does both, Zig is aiming for one of these things and I'll let you guess which.

creativemonkeys 5y ago
A segfault lets the user know that the developer made a mistake, and where in the code it happened. Blaming C for segfaults is blaming the tool. C is a small language with a spec designed to adapt to new hardware while remaining fast. The spec is ambiguous in precisely the places where resolving the ambiguity would mean either limiting its portability or its speed. This increases the learning curve significantly and also requires diligence on behalf of the developer, so it's high effort to write. It's a perfectionist's language, because, if you can steer clear of the known pitfalls, you get a working piece of software that's maximally portable and fast, and fast is still what we want our tools to be. There is a place for Zig, and Nim and Rust in this world, but there is no world in which these tools make the same trade-offs as C and end up with a faster and more portable (across hardware) language. They can sacrifice speed to make it more difficult for the developer to make mistakes. They can sacrifice portability to make assumptions that resolve undefined behavior, which would also decrease the burden on the developer, but they will never get all three - correctness, portability and speed, so in that sense, they will never replace C, they can only hope to starve C of developers.
- throwaway17_17 5y ago
  I think your breakdown of a language is a neat idea, the decomposing of implementations by there ‘scores’ in the three areas of correctness, portability, and speed. I think I’d like to replace speed with a performance score encompassing both speed and memory footprint though. I also agree that achieving high ‘scores’ in all three areas is a relative impossibility. For me, the best language is going to be the one that has a maximum in the performance area and is provably (at least to some reasonable measure) correct. I think portability between execution environments can be a loss for the types of things I enjoy programming.

comex 5y ago

There is nothing about the design of strtol that makes it particularly fast. If anything, the extra checks and accesses to errno (which on modern systems is generally an implicit function call) that are required to use strtol correctly represent unnecessary overhead, though only a trivial amount of it. But mostly it’s just an awkward API design.

ogogmad 5y ago

I think the brittleness of C's string handling functions is not a necessary consequence of anything you said. It's just sloppiness and inertia.

shadowofneptune 5y ago

You're right, we need to draw a distinction between the Real Programmers and the Quiche Eaters. A mere Java or Python user just isn't good enough, they can't write portable assembly like a Real Programmer can.

creativemonkeys 5y ago
Absolutely not. Once a user reads "Head First Java" or customizes Django sites, they get their standard issue keyboard and they're ready to start writing interrupt handlers in C. If the code crashes, it must be the language.

pyjarrett 5y ago

> C is messy because real world hardware is very messy Ada was designed for embedded systems specifically and has guards over many of the pitfalls in C. Still, it provides easy access to in-depth low-level control when you need it (assembly, intrinsics, binding variables to specific memory locations, importing C, creating your own custom allocators). The difference is that you write intent, and then paint additional control on top of that. This makes Ada also suitable for higher level applications.

adwn 5y ago

There's nothing fast about zero-terminated strings. In fact, many operations on them are much slower than sane alternatives, because they first have to scan the entire string to compute its length. You can't even create a temporary substring without either modifying or copying part of the original string. How lame is that? Zero-terminated strings are almost never the best solution, so why are they the language-supported default? > You should be thinking in assembly, [...] Well, then you shouldn't by typing in C, because Undefined Behavior coupled with modern C compilers will make sure that what you get is not what you thought. *cough* signed integer overflow * cough* > You can't push bytes through the hardware at its speed limit without getting your hands dirty Rust proves you wrong (maybe some other languages, too, but I don't know them as well)

creativemonkeys 5y ago
What you're missing is the difference between known issues and unknown issues. You're looking at a language that's been heavily used for 60 years and accumulated a long list of known issues and things not to do, that powers pretty much everything in computers, and you're comparing that with the new kid on the block with a vocal fanbase. You could invest your time into learning that finite list, or you could invest your time into learning a new language with a long list of _unknown_ issues yet to be discovered - but out of sight, out of mind, right? As far as runtime speed goes, assuming equal instructions being generated, if Rust spends even one CPU cycle checking array lengths, its generated code will be slower than C's, by definition. You can justify the trade-off ("it checks array lengths for me because I am human and I forget sometimes") or relax the restrictions ("it's not humanly noticeable"), but you can't claim it runs faster or even just as fast, because it's not. The only thing Rust proved to me is that there was a whole generation of developers who did't mind writing unreadable Perl code who had kids that are equally unaware of how unreadable Rust code is and it'll take a few decades for them to see that, assuming that Rust stays relevant for another decade.
- adwn 5y ago
  > You could invest your time into learning that finite list, or you could invest your time into learning a new language with a long list of _unknown_ issues yet to be discovered That's a bad argument, because it could be used against any change or improvement. By that logic, humans should have never even come down from the trees. > if Rust spends even one CPU cycle checking array lengths That's the thing: Almost all checks and guarantees which make Rust safer than C are done at compile time and have no negative effect on the generated code.

School-Cotton 5y ago

This would be more justifiable if C had support for vector instructions, which are crucial for high-performance code on modern CPUs.

V_Terranova_Jr 5y ago

The F1 analogy is easy to use against this line of argumentation. Today's F1 cars are way faster than their predecessors. They are also safer, more automated, and in large part faster because they are easier to drive. The racing is more boring, and cars are uglier, but those are different topics. The idea that you can't maintain the runtime performance of C while innately supporting automated reasoning about invariants/safety just doesn't hold up. The idea is to move the whole Pareto front outward - that's what advancements in theory and technology do.

creativemonkeys 5y ago
They came, they saw, and they went away, and C is still the smallest, fastest and most portable language. I think the only way to dethrone C is to change the equation of what's expensive to do in hardware - accessing memory, and that's not a problem us software guys are going to solve.

TheFrigginDoC 5y ago

C was not designed to be fast. It was designed to be a bit simpler and a whole lot more portable then assembly code. The speed is a biproduct of how it does not try to do anything other then basically mapping perfectly to the hardware.