rkts
That would be an audacious claim, considering the book is rather old and only 200 pages. I recommend it because it is a model of concise and accessible prose, good for laymen (like me) who want to get the basic facts with minimal fluff. As far as I know, none of its main points has been invalidated by intervening research. But I can see why its blunt statements of fact might be unpalatable to some.
If you want to learn more about the subject, I suggest this book, which concisely disposes of these and other popular anti-IQ arguments:
http://www.amazon.com/Question-Intelligence-IQ-Debate-Americ...
Predictable objections:
1. I had some great teachers at RRU: I did too. But they are the exception rather than the rule.
2. You'll make more money with a degree from RRU: The statistics don't support this. Harvard students end up with the same average income as students who get admitted to Harvard but then go to a less prestigious school.
3. You'll meet more smart people at RRU: Yes, but you can find smart people anywhere, and a few years of college classes is as good a filter as any admissions department, at least in technical majors. The kind of people you meet in a topology course is about the same no matter what school you're at.
I think the most important thing is to find a place where you'll fit in and be happy for 4-5 years. Visit a few places, and go with your gut.
See also: http://www.paulgraham.com/colleges.html
If you try to bring personal intuition into mathematics, you'll just repeatedly shoot yourself in the foot
I disagree. Intuition should always be foremost in mathematical understanding. You may have gotten a different impression from your math classes, and that IMO is a consequence of bad teaching.
I had a similar problem with accepting that 1/inf = 0
As you should; the statement is false. The limit of 1/x as x->infinity is zero, but there is no x at which the quotient "reaches" zero. In non-standard analysis, if x is positive infinite, then 1/x is positive infinitesimal, meaning it is infinitely close to, but still greater than zero.
Personally I get the best results from the MLton SML compiler. OCaml is also pretty fast and more practical. YMMV.
The African American adolescents had a lower birth weight, a lower verbal IQ, and a higher number of sexual partners than did White adolescents. For each characteristic, the mixed race mean fell between the means of the two parental populations.
I have never understood what this means. "Within-group" variation can be quantified as standard deviation (among other metrics). How do you measure "between-group" variation? Sample the group means and find the standard deviation? But that's obviously meaningless.
template<typename T>
void zap (T (*f)(T x), T &x) { x = f(x); }
Example: int square (int x) { return x*x; }
int foo[5] = {1,2,3,4,5};
zap<int>(square, foo[3]); // foo is now {1,2,3,16,5}
Admittely, the <int> is a little ugly, but that can probably be fixed with Hindley-Milner (or just plain dynamic typing).But that's exactly what IQ tests measure, at least in the context of academic and job performance. IQ tests are used because they are the most economical predictor of achievement in certain areas.
Stanovich seems to be saying that he can predict some kind of achievement (or "well-being," whatever that is) by examining people's susceptibility to certain mental quirks like the sunk cost fallacy. Ok, it's a fine hypothesis, but where's the data?
He says that IQ and rationality are "very imperfectly" correlated. What is the number, exactly?
You seem pretty determined to persuade us that IQ is unimportant. I don't claim to be an expert on the subject, but HN readers should know there's more to the debate:
http://news.ycombinator.com/item?id=536558
http://news.ycombinator.com/item?id=565842
http://news.ycombinator.com/item?id=588797
http://news.ycombinator.com/item?id=518828
http://news.ycombinator.com/item?id=559054
http://news.ycombinator.com/item?id=514086
http://news.ycombinator.com/item?id=480331
http://news.ycombinator.com/item?id=497733
http://news.ycombinator.com/item?id=483771
http://news.ycombinator.com/item?id=514856
This is just from a quick Google search. I'm sure there are more.
If that's true, there ought to be some culture that doesn't have this problem. Can you name one?
Everyone has two brains, a "people" brain and a "stuff" brain. Most people use them roughly equally, but some use one more than the other.
When we were kids, my sister and I used to argue because she thought that her stuffed animals had feelings, and that birds had conversations about specific things. She was always attributing human emotions to things that didn't have them. Even now, she does it with her cat: if the cat trips and falls and walks away with its head down, my sister will say, "Aww, she's embarrassed!" -- even though cats don't understand embarrassment and the cat is probably just tired.
Unsurprisingly, my sister is religious and I'm not. Religion is what happens when people misapply their people brain to thinking about stuff. They get a vague sense that the world is alive, and then explain it in whatever concrete terms their culture provides (God, in our case).
Nerdiness is what happens when people misapply their stuff brain to thinking about people. Nerds misinterpret other people because they fail to attribute emotions to them. However, unlike religious people, nerds usually realize at some point that they have a problem and can try to change. Except in extreme cases, religious people suffer no consequences for being wrong, so they have no reason to change.
Since women tend to be more interested in people and men more interested in stuff, this also explains why women are more often religious, and men are more often nerds.
I intended my example to represent cases where you want real mutation, in the sense of modifying a data structure in place. Your code using the State monad, if I understand it correctly, just abstracts functional updates in a way that looks like mutation.
Anyway, my intent in my original comment was simply to explain the practical consequences of pure functional programming. That, for instance, if you have a pure function that you want to randomize, this change must be reflected in all the code that depends on it. My intuition is that this is a bad thing, but I don't have enough experience to say for sure. However, it is apparent to me that purity
1. adds a lot of complexity to the language, and
2. has no clear practical benefits,
which is why I say it's a waste of time.
getLine :: IO String
getLine takes nothing as its input--not the state of the world, or whatever, but nothing--and produces a string that's inside an IO monad. To all appearances, it's an impure function. But because the String is inside a box (so to speak) you can't peek at it--instead, you can only give it to another function, provided that function also returns a box you can't peek into.In effect, this creates two classes of functions. Some, like getLine, can have side effects, generate random values, look into other boxes, whatever. These are technically "pure" in a mathematical sense since their outputs are always inside identical boxes, but in practice they behave just like impure functions, and you reason about them the same way. The rest have more restricted capabilities, and because their values aren't inside boxes, the compiler can verify that they return distinct values in a pure manner.
So, for an extreme example, consider this function:
foo (x) { x++; return x; }
In Haskell foo would return "IO Int," which means the "Int" may be produced impurely. Actually, the integer is produced in a pure manner, so it would be fine for foo to return a plain Int. But the way Haskell determines purity is too crude to figure that out: all it knows is that foo depends on a mutation, which may make the output impure. Impurity is contagious, so foo "catches" it from ++ and thus has to put its output in a box.Hence, the typical description of pure functional programming as "functions only transform inputs to outputs" is only true in the most trivial mathematical sense, and has no practical import. Pure functional programming really means writing a crude proof that a certain subset of your program is pure, and the compiler checking the proof for you.
(Disclaimer: I understand that this is a very vague high-level description of monads, that monads can work in other ways and do many other things, and that purely functional languages can handle state/side effects/etc. in other ways. It's a complex issue and I'm just trying to convey the way that it usually works in practice.)
I never said that they do.
"Functional programming" can mean one of three things.
1. Higher-order programming: the use of higher-order functions to make code more general/compact. Since you know Ruby, you're already doing some higher-order programming, but you may not understand it well enough to take full advantage of it. The best way to learn higher-order programming is to read SICP.
2. The use of immutable (aka persistent, nondestructive) data structures, i.e. data structures that can be updated without mutation. For example, linked lists allow you to prepend an element without changing the original list. This makes code cleaner in some cases and has advantages for concurrency. For specifics, look up Clojure.
3. Functional purity, aka referential transparency: the property that, for any input x, a function must always produce the same output x'. That is, all functions must be functions in the mathematical sense of the word. In practice, this doesn't really mean eliminating impure functions, but rather partitioning your program into "provably pure functions" and "possibly impure functions," using a clever hack (monads) to ensure that the output of possibly-impure functions is invisible to the provably-pure ones.
So, supposing you had a pure function whose behavior you wanted to randomize, you couldn't just throw in a call to the random() function, but would also have to convert it and all the functions that depend on it into impure (monadic) functions, replacing all function calls with the bind operator (>>=). It's quite complicated and I have never found a reason to believe it's a good idea, other than some theoretical stuff about "safety" and compiler optimizations that make your program 2% faster. I suggest not wasting your time on it.
I listened to this speech a couple hundred times before it dawned on me: I was having those blasphemous thoughts because my Sunday school teacher was, in fact, full of baloney, and that speech was his way of preempting my critical thinking.
If you know an idea is false, you don't have to work to suppress it. Your brain is good at doing that for you. I think as a rule, if someone tells you to suppress an idea, you should do the opposite and follow it further. Even if it shocks you.
How?