Another anecdote for your hunch -- I have a friend who when he was around 13 decided (for unknown reasons) to condition himself to living in cold environment. He'd take baths in cold water, walk barefooted in his unheated room in the winter and so on. For the past 30 years he's been much more tolerant to cold than the rest of us, for example he'd just wear a sweater outside in the snow, and he seems to be in good health.

I believe we are adaptable even when we get older, though of course less so.

I think you're starting with the assumption that it is important for a religious person to know what exactly, objectively happened, rather then what the internal and psychological meaning of something in their religious text is. In my experience, those who do insist on what "really" happened according to the Bible aren't particularly spiritual -- they are just a flip coin of atheists who more than caring about the wonders of science insist on what "really" happened according to a current consensus on scientific theories.

And that's why I don't like what Tyson is doing -- I think he only helps entrench existing closed-mindedness on both sides. (Though I realize by bashing his supporters in my post above I'm not really helping matters either, FWIW.)

That is the essence of it. It doesn't matter if he's "right", what matters is the consequence of his actions, and that is turning religious people away from science further while making his "pro-science" (a ridiculous term) fans more, well, fanatical. I have an impression that his supporters care more about settling scores with religious people than about advancing science.

It's not about the intention but about the consequences. PG believes that great programming is a talent that can flourish in the right conditions that this country has. Also you're right that the companies are pushing for visas only to lower the price down. But regardless the consequence is that the good programmers can flow in greater numbers, along with mediocre and bad ones.

Without having RTA (but having read many others of his), I think essentially his argument is this: if we open the gates, one of the consequences will be is that we will have more great programmers than we would have otherwise, along with negative consequences -- a glut of mediocre programmers, lower wages, fewer jobs for domestic non-elite programmers and so on.

The question is, is having an extra few hundred or thousand super talents a year in the US worth it? PG seems to believe yes.

FWIW, I am of two minds there. Having more supertalent will likely lead to new and exciting stuff, and will likely make the lives of society overall a little worse. At least that has been the trend the last few decades ("everything is amazing and nobody's happy"). Still, is it worth it? I don't know.

Leap Motion was heavily overhyped and after $40M of investments they produced basically nothing useful. I'm very skeptical of companies that only talk about how great product they *will* have, and this hire goes squarely in that direction. Apple at least keep quit until they have something that works.

Another Leap in this category is Sinclair's QL -- though I'd take it any day over these other Leaps in their current form.

We're talking about cognitive ease (and cognitive strain) of reading code, so that is not the same: when I see
hs.add(elem) it is very obvious that the "add()" is some hs' thing. But when I see hs + elem it goes against years of practice that the operands are numbers or strings and for a tiny fraction of a second I may have to ask myself what are hs and elem again. That's cognitive strain.

IMO though operator overloading is justified with template programming since the "+" operator is guaranteed to exist so it's like a standardized function name. So I guess what I dislike is that C++ encourages things that don't have purpose other than looking nice to some people. In C at least it's accepted practice that going wild with macros is bad but with C++ there are things that are done only because they appear "elegant."

Joel Spolsky's example touches on those too: "i might be of a type that has operator= overloaded, and the types might not be compatible so an automatic type coercion function might end up being called. And the only way to find out is not only to check the type of the variables, but to find the code that implements that type, and God help you if there’s inheritance somewhere" and so on.

It's a caricature of real world's examples meant to illustrate this: when you read competently written C++ code, you don't know in your head what's going on on the machine level without going outside of the code block you're reading to check. With competently written C, you do. I don't think there is much dispute over that.

The question is, does that matter? That's (more) up for debate. My conviction is yes, it matters for system code, and no not quite, it doesn't matter as much for app code. When I look at system code, I want to know what happens at the CPU level. When I look at app code, I want to know how these abstract elements combine to make something new.

As for operator overloading, I agree there are C++ things that are more invisible. With operator overloading, I just don't like it because of precedence and all. The sole purpose of overloaded operators, I believe, is to make the code more readable, by one person's standard, but readability is in the eye of the beholder. I prefer chained function calls as I find it easier to map the code in my head to the process at runtime.

The "i = j * 5" example is meant to cover reasonable cases, not to take it to the extreme. Of course you can do all kinds of obfuscations in both C and C++. The point is that in a well-meaning, reasonably competent team, C++ coders often out of best intentions overload operators and do other things that obscure your understanding of what is actually happening. You will have to either assume/hope that the code doesn't have side effects you're not aware of, or you'll have to go and check elsewhere, which interrupts your flow of reading and understanding the code. With C, in a team of the same quality, you don't need to do that -- what you see is what you get. What I'm saying is under normal conditions, your confidence in knowing what happens is higher when looking at C than at C++ code, and the more critical the code is, the more important your level of confidence in it is.

No one says it was you who overloaded the operator. You may be looking at code someone else in your team wrote, or an ex co-worker, or an open source contributor -- and it could be even you and don't remember it. The point is, the reality is if you are given code to work with and you see i = j * 5, if it's C you know what it does; if it's C++, you don't, regardless of who wrote it.

I think the danger of that happening for low level, frequent-running, system code outweighs the flexibility that C++ gives you, and vice versa for app code.

The downside of C++, is you can't look at the code and know what happens at the machine level. Joel Spolsky describes it below: (in an article on variable naming)

"In general, I have to admit that I’m a little bit scared of language features that hide things. When you see the code

        i = j * 5;

  in C you know, at least, that j is being multiplied by five and the results stored in i.

But if you see that same snippet of code in C++, you don’t know anything. Nothing. The only way to know what’s really happening in C++ is to find out what types i and j are, something which might be declared somewhere altogether else. That’s because j might be of a type that has operator* overloaded and it does something terribly witty when you try to multiply it. And i might be of a type that has operator= overloaded, and the types might not be compatible so an automatic type coercion function might end up being called. And the only way to find out is not only to check the type of the variables, but to find the code that implements that type, and God help you if there’s inheritance somewhere, because now you have to traipse all the way up the class hierarchy all by yourself trying to find where that code really is, and if there’s polymorphism somewhere, you’re really in trouble because it’s not enough to know what type i and j are declared, you have to know what type they are right now, which might involve inspecting an arbitrary amount of code and you can never really be sure if you’ve looked everywhere thanks to the halting problem (phew!).

When you see i=j*5 in C++ you are really on your own, bubby, and that, in my mind, reduces the ability to detect possible problems just by looking at code."

My opinion is, for code that lives closer to the OS (or the OS itself), where there are fewer lines of code but which run more frequently, C is king. For code that needs to multiply/grow/combine/evolve faster and still run fast, C++ is often a better choice.

I grew up in Serbia and Spectrum meant the world to many kids in my generation, even though we had no direct connection with the UK market whatsoever -- no magazines or TV programs or anything really. So it is fair to say that Spectrum was a cross-European phenomenon. C64 was (almost) equally present, though everyone I knew who had a Commodore just played games, whereas lots of Spectrum folks dabbled in programming, at least a little.

People react to people more than people react to concepts, I don't think it's that surprising. "There's been a murder" has less of an emotional weight than "Alice murdered Bob." (And note, different emotional weight than "Bob murdered Alice." The endless nuances of being human carry far more information -- infinitely more, actually -- than what is captured by a conceptual abstraction.)

B/c those rich white frat boys want to make shit such as Groupon and Zynga. That is the real problem (for me), their outlook on life and their values result in things I don't consider useful or beautiful but just something that makes them richer and the rest of the world poorer and dumber.

I would imagine it feels like the reflex-test kick in the knee -- you feel the sensation but are surprised it is happening since you are not willing it, and you're merely observing the process.

Taking it a step further, I imagine one day when someone else can press a trigger to create a vague thought or image in your mind, you'd feel the same -- feel the mental sensation but since you'd not be willing it, you'd be just observing it. (Perhaps similar with eg. a hallucinations? Also something you did not invite in your mental space, it just occurs.)

I'm curious what happens if there are multiple validations checks and if they don't all have immediate visible consequence. E.g. if some basic function in the game such as moving to the left deteriorates in the minutes or even hours/days after the validation check has failed, or if the failed check forces glitches downstream that make the game unplayable? In other words, how do you know if you have removed the protection (esp. if the game has genuine bugs)?