> Sprinkling printf statements is an efficient debugging technique.

Debatable.

> Functional programming doesn't have state, so you don't need locks, so you can get better concurrency.

This is not true.

Many algorithms are intrinsically imperative (e.g., quicksort). You can represent it using some monads in Haskell to hide this, but in the end your code is still imperative; and if you want to parallelize it, you still have to think about synchronization.

> , though he did not join until June 2016

So his effective salary is double that.

I think people are supposed to report their salary with the stock price at grant, not after appreciation (at least on levels.fyi). But yea it's a lot more because google stock is half their comp and it keeps doubling every 3-4 years.

I’m from Levels.fyi. We actually request users to report compensation with appreciation. This is because the appreciation can actually be used to negotiate compensation elsewhere and provides a more accurate picture.

It's related to intelligence in the sense that being able to predict well requires intelligence and helps compression. If you have an intelligent model that predicts new words with high confidence, then you can use fewer bits to encode them. If I were to be even more handwavy, I would say having the ability to summarize effectively is a sign of intelligence.

The counterpart of "Contracts" in C++ is "Traits" not "generics".

maybe use fences?

This is probably not useful for production, but volatile is a great way to see what kind of code compiler generates in a realistic setting. For example, if you want to see how compiler optimizes a code snippet and the code depends on a constant that you don't want to get constant folded away.

Program verification. E.g. when you want to prove that certain condition/path (e.g. asserts) is unreachable.

This seems odd. I've known no one who learns programming by reading books. Reading books help, but most people get proficient by working on projects.

Hmm, you're right, I agree, but you need to understand a language before working on a project (OK, maybe that's my style, maybe others interlace working + reading).

But the original poster claimed info was just so hard to get and I said it wasn't.

Horses for courses, ok. In reality it's books + SO + lots of online info + your local expert (there's usually one at least, though expertise is relative) + transferable skills from other languages.

All I'm saying is you need that info, and it's there, one way or another. There's so much info now out there compared to when I started programming. It's there, use it.

> I've known no one who learns programming by reading books.

Similarly, taking a dance class won't make you a dancer, but it helps.

I did, years ago before I had a computer and when I got an opportunity I would type programs at school/terminals/store computers. I think being forced to visualize the code before can help because when you sit down it's just typing.

This is unlikely to happen because of the performance penalty it would incur (e.g. defining outcome of all out-of-bound memory accesses).

I would expect that it would still be faster and use less memory than most of the other popular languages today (e.g., C#, Python, or JavaScript).

It would be just another option to choose from. Solving some of those undefined behaviors may even provide other benefits (e.g., better compiler error messages, optimizations, or portability).