Erdos Pal
http://en.wikipedia.org/wiki/Erdos_Pal (I cannot reproduce Hungarian umlaut in slashdot)

Although an amphetamine taking mathematician is maybe not the best hero for an 8 year old :)

Yeah, and this mechanism hinders deep research. The problem is that the most interesting research subjects are also the riskiest ones. You cannot publish papers on failures, therefore you are highly pressed to go for the low hanging fruit. This means that journals will be full of the (n+1)th refinement of a well known algorithm/technology/formula/theorem.

We need more scientific risk-taking.

It is great to see that we can produce scientific puzzles in the 21th century that are based on simple mechanics (no quantum theory, no higher math), and confuses the hell out of a lot of knowledgeable people! Really intriguing!

I wanted to write v_2 (lowerthannorequalto) v_1, but slashdot swallowed the relation sign.

It is interesting how people always come to conservation of energy, but they talk about speed at the end. They basically say "hey, if wind blows at v_1 relative to the ground and your cart goes at v_2 only gathering energy from wind, then v_2 = v_1 must hold (at least in the infinite), because otherwise we would have a perpetum mobile". Now the only problem is that speed is NOT energy, so relation of speed between an energy source and a worker depending on the source does not matter by itself alone.

If you interpret the manifesto in the original context in its own age, you will understand that documentation means there not "developer documentation" or "user documentation" but the various "project documentation" artifacts that were the holy grail of that age.

The same is true for processes. It is not about the small scale ones (source control, review processes, whatever), but the overengineered project processes prevalent in that era.

If you read the original manifesto, it is very carefully worded. It does not say "abandon processes", it says that the priority should be on the developers as creative individuals, instead of mechanized drones.

Also, it is not against "processes" (with small "p"). A build system is itself a process, a source control software also enforces a process. The manifesto is against Process with a capital P. It is hard to explain, but easy to give an example what I mean about this:

http://www.ogcio.gov.hk/eng/prodev/es3.htm

The above link is about the SSADM Process. Read it and you will immediately understand what I mean.

Also, lot of people misunderstand "Working code over documentation" and think that documentation is not important. In fact, it should be read primarily as "project documentation", the things that most old fashioned processes mandate. Again, look how many and what kind of docs SSADM needs.

The original Manifesto:

"We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more."

I think it is hard to disagree with the original statement. What is frustrating now, is that "Agile" degraded to a bunch of buzzwords and processes (SCRUM, XP, TDD, BDD, etc.) which it was going against originally. Of course it is more business in selling these (by consulting companies) than the vague "do what fits you best" statement.

Also, the problem is not with particular practices, or processes but the mindless, inflexible application of them to every project and team on earth. Teams are different, software are different, why should we all use the same processes then?

The original manifesto's key message was "people over processes" which I still agree with. On the other hand the word "Agile" now means just as many processes as waterfall or RUP meant in the past. Shame.

To clarify my below comment, I use your running analogy:

  - while two runners may run at the same speed, they may not start from the same position. I do not care who "wins" (is the fist) I care only how far they get at the end
  - unlike running, it is not immediately obvious who runs faster
  - running speed is not constant, but grows slowly. For some students it starts growing later but stronger and lets them close the gap
  - some students are behind because of an injury -- you cure them and they will be as fast as the others
  - unlike running, you are not alone

Of course there are guys that will never be up to the challenge. It is just quite complex to figure out which ones. Have you been to "class reunion" (is this the correct English term?) events? Which are the students who lived up to everyones expectations? Who were the ones that surprised you?

I personally think that assessing people is very hard, and most of us think that we are good judge of character. I keep a mental list on people I misjudged and that constantly reminds me how hard is to judge others.

There is a misunderstanding here. My original comment was a reaction to the comment that "most people don't need the math". Following that same logic you end up realizing that most people do not use any (or most) of the stuff their learned -- so we should not teach it.

Of course I do not agree with this conclusion at all.

Why don't we?

You see, lack of smartness is just one cause of struggling, but there are others. There are many vectors for a student and you will see them in very different mixtures:

SmartnessDumbness
ConfidenceLack of confidence
BraveryCowardice, passiveness
Hard workingLaziness
InterestedUninterested, skeptic
Sense of safetyWorries, depression
etc...

I am a teacher, not a fucking judge. Who am I to decide which students deserve hours of work and who don't? I rather leave it to life and I do instead my best to do whatever to teach them. And I am no idealist, I know that there are children as stupid as a rock, still, I give a chance at least.

Primary sources -- what makes them more reliable?

The fallacy you make is that "closing the gap" means "slowing down".