Zibulon

Just for the records, Grothendieck maybe "disappeared", but he also died a couple of months ago, it was all over the press...

Why is an account needed for the demo??? That turned me off enough to give up. I am tired of having to create an account for everything and anything - and it makes managing passwords harder, or promotes using weaker passwords. I don't want to live in a world where each step I take on the internet requires a separate account/password!

IMHO, he doesn't have the technique to handle 80 lbs.

I wouldn't worry about his bow weight. The trajectory of his arrow on one of outdoor shots show he is not even shooting 30 lbs. You can hold that as long as you want.

Actually not so hard - below 30 meters, you can have that kind of accuracy with not too much effort IMHO - in recurve archery, we shoot only 3 arrows, on separate targets, starting at 50 meters, to avoid breaking arrows (the next one hitting the preceding one). At 30 meters, I can let go of sight and a lot of technique and still be "bullseye" as he is.

IMHO, he is shooting a bow that's too light for hunting or fighting. I'd say he shoots below 30 pounds, which works for what he does, but nothing else.

Hunting at 70 yards? All the bowhunters at my club practice below 50 yards.

Concur. Besides, he is probably shooting less than 30 lbs which is enough for his stunts, when you want to be shooting 70-80 lbs for hunting. Given his technique, I'd like to see him pull that. As for "war", I've seen medieval estimates of 140 lbs, which always left me wondering, because after 20 years pulling 45 lbs myself, 140 lbs just means "injury" to me.

Yes the arrow is slow, because the bows are not heavy, probably in the 25-30 lbs range.

From the trajectory of one of his outdoor shots, IMHO, he shoots 25-30 lbs.

He seems to be shooting a very light bow, from the trajectory of his arrow in one of the outdoor shots, and his technique probably wouldn't work very long for a heavier bow or more arrows, because he doesn't seem to be using his back very much. (I'm an archer).

Maybe that's too short sighted. Constantly rewriting code has a big cost. A huge cost actually. I see it at my work everyday: there is a pervasive (fashionable?) attitude that no code lives more than 3 years, and we have incessant "migrations" to new and better systems. You wouldn't believe how costly those migrations are, including through losing good people who don't want to suffer through them (and I am sympathetic to their plight, it's really horrible)...

Sounds to me that the real issue is either mission creep, or a bad programmer/designer who doesn't see that the "generic" piece of code now needs to be split into components? In my practice, an issue that comes back often and seems to be related though, is trying to anticipate future use cases. Maybe a failure to anticipate reasonable future use cases is what leads to the mess: the first solution is not "generic" enough, and therefore more and more options are added as new use cases are discovered. But I find it hard to balance future use cases and immediate requirements.

I don't understand: I thought that flexbility and abstraction went together, rather than against each other.

Or failure to generalize might hide a failure to abstract out properly.

Weird. To make software more generic, I usually reduce the number of assumptions and edge case handling that goes in the APIs. If you start adding options to handle more cases, that's just not "generic". But in any case, we should start from the use cases, and avoid mission creep... and an interesting question becomes: how much do you need to design for future use cases, and how much do you need to design for the use cases currently at hand?

The author is missing maybe the following point: when there will be multiple objects that need to move, and some of the move methods will require state, then it will be nice to encapsulate the state within objects, rather than having messy global state and methods that access a global state... which can lead to coupling between methods, if not concurrency issues, and before you know it, you end up with hard to understand, non-maintainable, non-refactorable spaghetti code.