copsarebastards

I'd agree with you in some languages, but in C this would be prohibitively difficult. In general, good fluent design uses immutable objects, which makes it basically just a syntactic sugar for functional programming. While fluent syntax is nice, the functional semantics are the real value, and are much easier to do in C (although, as soon as you add in memory management, functional programming often becomes prohibitively difficult too).

That’s the danger of Occam’s razor and of simple answers. “Simplicity” is often a hiding place for our biases. We reach the conclusion we want to reach and then call it simple. --Plaza Garabaldi

I'm not saying you're wrong, I'm saying that I don't actually agree with you that brains being hardwired with information is that hard to explain.

That's actually a very good example, but I'd argue that this is actually a violation of the standard: memset is defined as setting the value in memory. Most optimizations on undefined behavior don't really fall into this category.

I guess you could group this kind of thing into the category of "dead code elimination" which is useful, but results in parts of the code written not producing the specified executable. I have to think on this example more.

Good luck with that. I suspect the only good C is not C.

There's a flipside to this: middle-aged-to-old people aren't choosing to participate in the silicon valley startup culture. As superuser2 noted, a 22-year-old can subsist on ramen while living in a car, while a 45-year-old can't ask his wife and children to do that. But it runs deeper than that: just because a 22-year-old can subsist on ramen while living in a car doesn't mean it's a rational choice.

Most startups these days are producing glorified ad servers that don't actually solve any problems or provide any value. The tech bubble is such that anyone with a young face, a Macbook Pro, and a dumb idea can get funded, but that won't last. As such, working 60 hour weeks for stock that will be worthless in a decade is a bad idea for anyone, regardless of age. Software devs in their 40s have the self-respect and experience that they won't take that kind of deal.

There are some startups which have reasonable business models, but I suspect that time will show that part of those reasonable business models is recognizing the value of experience. In the long run 45-year-old programmer with 25 years of experience working 40 hours a week is easily worth two 22-year-old programmers with 2 years of experience working 60 hours a week. There are certainly young prodigies and ideas which hit the zeitgeist so well that the execution of the idea barely matters, but these are outliers, not the norm.

I'm not missing that; you're making an assumption.

>> Computers don't have spirits

> But standards committee do.

Agreed. Which is why you should choose a language which was standardized by a standards committee whose goals better align with your goals.

> I doubt rust could be ported to a 8bit PIC microcontroller, or to a 6502 keeping reasonable performance characteristics or letting the programmer take advantage of the platform quirks.

I don't think that's true; I think that the current state of Rust tools is such that this is true now, but it's nothing inherent to the design of the language, and I think you'll be able to do quite a bit with Rust in the situations you describe when the tools around Rust are more mature. I can't really speak to this more because I'm not sure why you think this can't be done.

> More specifically, they're competing to produce the fastest code for software that follows the C specification to the letter. That's not necessarily the same as producing the fastest code that actually achieves the intended goal.

That's true, but "producing the fasted code that actually achieves the intended goal" is not a problem which can be solved by a compiler--the compiler can't read your mind.

Attempting to represent a reasonable approximation of reading your mind is the responsibility of the specification. You can definitely do better than C, but I doubt you could have done better 4 decades ago when C was designed.

> What GCC is doing subverts the purpose of writing in C, which is to get close to the machine and instruct its processor to do certain things.

That's not the purpose of writing in C. It's a goal you might be able to achieve with C, but I'm not sure why that's your goal, and it's certainly not the goal of everyone who writes C. I think more people who write C do so with the coal of producing programs that run fast or with a minimal memory fingerprint.

> This is a case of following the letter of the law (in this case the C standard) while disregarding its spirit: all the undefined behaviour was so that C compilers could accomodate for odd architectures while remaining close to the metal, not so that compiler programmers could go out of their way to turn their compiler into a mine field.

Computers don't have spirits; they work as you tell them to work, to the letter, and if you're remaining close to the metal, your language will indicate that fact. Optimizing undefined behaviors doesn't make C a minefield; low-level programming for different architectures just is inherently a minefield. C was a minefield before these optimizations were added.

Rust is extremely impressive because they've found so many ways to do high-level programming while maintaining low-level performance. But they can only do that because they have the benefit of the 4 decades of programming language research that have occurred since the basics of C were designed.

Yeah, I'd go so far as to argue that if you need security, you probably shouldn't be writing C.

I don't think people's inability to distinguish between paying for software and paying for programming makes the statement "Software should be free" a bad statement.

I understand the problem, I'm saying that it's not GCC's problem. If you don't want undefined behavior, don't put undefined behavior in your code. The code you wrote isn't clear or reasonable, because it relies undefined behavior. It's a valid criticism that this code does appear to be straightforward when it isn't, but that's not a criticism of GCC, it's a criticism of ANSI C. If you don't like it, use a better language. C was designed 4 decades ago; and they can't possibly have forseen every problem that we've discovered in that time.

Writing code that depends on the value of unread memory is bad for security.

I think a better design would be to separate mutators from pure functions. If a procedure mutates state, it should have a void return type, and if a procedure returns a value it should be a pure function that doesn't mutate state.

This is, of course, a rule of thumb, not a hard law. Some exceptions:

1. I think it's okay (and in fact, idiomatic in C) to mutate state and return some sort of information about what occurred (i.e. a success flag, a number of characters written, etc.).

2. Isolated mutations such as logging sometimes make sense in an otherwise pure function.