Btw, if you are really interested in the algorithms for solving hypergeometric identities check out the ebook by Marko Petkovsek, Herbert Wilf and Doron Zeilberger:
I feel the same. I spend most of the time at my job thinking, not typing. That said, there are moments once in a while, when I feel like the code is just flowing out of my brain, through my body and fingers, directly into the screen. Now these moments make me really appreciate touch typing.
"Capturing requirements is pretty useful and having a repeatable, reproducible way of doing this is also useful. Need to take over some other person's 3 year old steaming pile of spaghetti? Requirements are a good start. Need to replace a home-grown system with a market solution? Requirements are pretty useful in negotiating a contract with the vendor (unless you don't mind the vendor nailing your balls to their invoice because you couldn't actually tell them what you needed their software to do)."
Yes, IF your contractor is COMPETENT ENOUGH to give reasonable requirements. In reality this rarely happens. And while you can point a finger at them, that their requirements were stupid, they will think you just deceived them. They will pay you, but they will not come back.
The list of "institutional causes" can be addresses through process
This is FALSE. In fact, "institutional causes" are ALWAYS lack of communication, lack of REAL teamwork, lot of ass-cover, responsibility avoidance, bureaucracy and fear. This is exactly CAUSED by such processes.
AAAAAH! Now I remember! Now I remember all the pain! These memories were suppressed, and buried deep down in my mind... This explains all the nightmares. Oh God. I need a therapist.
If I understand correctly, you can run your own Diaspora server, is it right?
Well, then there must be a protocol to communicate between Diaspora servers. If that protocol is sound, then I will just write my OWN server with all the security features I need.
Do we know anything about the security of the protocol? I am more interested in that not in the security of the webapp.
There simply is no good metric. You have to judge the quality of the papers and authors by reading them. Tht is not the answer accounting departments want to hear, though.
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.
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!
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:
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.
"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.
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.
"Democracy does not work if people are not well educated."
Exactly. Also, the best way to learn is not necessarily to learn always the things most relevant to your current work. There is a reason why most of us like games, puzzles, riddles, even though they are not directly applicable to the real world.
"It even harms the kids who are good at math and want to do it because the teacher has to slow down for the kids who have no talent for math, aren't going to go into a math related profession and shouldn't be forced to learn about the square roots of negative numbers or quadratic equations."
Returning for this sentence for a moment: my experience is that the best teachers were those who were actually able to close the gap between the students with different abilities.
Slashdot Mirror
Btw, if you are really interested in the algorithms for solving hypergeometric identities check out the ebook by Marko Petkovsek, Herbert Wilf and Doron Zeilberger:
http://www.math.upenn.edu/~wilf/AeqB.html
It is one of the best free mathematics ebooks out there...
Yes, exactly! In fact 0.333... is just a notation for the number that is the limit of the series: 0.3, 0.33, 0.333, ..., and that limit is exactly 1/3.
I feel the same. I spend most of the time at my job thinking, not typing. That said, there are moments once in a while, when I feel like the code is just flowing out of my brain, through my body and fingers, directly into the screen. Now these moments make me really appreciate touch typing.
Does he pass the Voigt-Kampf test?
"Capturing requirements is pretty useful and having a repeatable, reproducible way of doing this is also useful. Need to take over some other person's 3 year old steaming pile of spaghetti? Requirements are a good start. Need to replace a home-grown system with a market solution? Requirements are pretty useful in negotiating a contract with the vendor (unless you don't mind the vendor nailing your balls to their invoice because you couldn't actually tell them what you needed their software to do)."
Yes, IF your contractor is COMPETENT ENOUGH to give reasonable requirements. In reality this rarely happens. And while you can point a finger at them, that their requirements were stupid, they will think you just deceived them. They will pay you, but they will not come back.
I agree with you except:
The list of "institutional causes" can be addresses through process
This is FALSE. In fact, "institutional causes" are ALWAYS lack of communication, lack of REAL teamwork, lot of ass-cover, responsibility avoidance, bureaucracy and fear. This is exactly CAUSED by such processes.
AAAAAH! Now I remember! Now I remember all the pain! These memories were suppressed, and buried deep down in my mind... This explains all the nightmares. Oh God. I need a therapist.
If I understand correctly, you can run your own Diaspora server, is it right?
Well, then there must be a protocol to communicate between Diaspora servers. If that protocol is sound, then I will just write my OWN server with all the security features I need.
Do we know anything about the security of the protocol? I am more interested in that not in the security of the webapp.
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 :)
There simply is no good metric. You have to judge the quality of the papers and authors by reading them. Tht is not the answer accounting departments want to hear, though.
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".
"Democracy does not work if people are not well educated."
Exactly. Also, the best way to learn is not necessarily to learn always the things most relevant to your current work. There is a reason why most of us like games, puzzles, riddles, even though they are not directly applicable to the real world.
"It even harms the kids who are good at math and want to do it because the teacher has to slow down for the kids who have no talent for math, aren't going to go into a math related profession and shouldn't be forced to learn about the square roots of negative numbers or quadratic equations."
Returning for this sentence for a moment: my experience is that the best teachers were those who were actually able to close the gap between the students with different abilities.