> Harvest tomatoes from your back yard on ToteDay, drop them into Amazon mini-totes, and have them delivered, at market prices, to people in your area.
Then you run the risk of people selling Tomacco[1].
The difference between this and true overloaded methods (which, correct me if I'm wrong, is the what he meant by "MultiMethod") is that an overloaded method is created at compile-time and does not incur the added cost of determining the type of the object at runtime.
That being said, I didn't know that Python doesn't have function signatures. Would someone care to comment on how a function is identified?
An interesting way to keep people interested in the game (during a fight, that is) would be to allow players to update the AI on the fly.
I'm thinking each player would submit an AI to start the game. At any point during the game players could "check-in" code (VCS-style) and cells created from that point on (via the splitting described in the article) would have this new code. Players would be allow, for instance, 2 check-ins per game. The upgraded cells would be represented by different shades of the player's color so that they could be kept track of.
I see this being useful for times when a player drastically misuses his cells initially or for an entirely different style of play (a different bracket on the ladder server).
As interesting of a problem as this is, I don't quite understand how a) BP and other oil companies aren't required to have solved it prior to drilling and b) after more than a month of the world watching, all they could come up with was a solution that might work.
I'm inclined to call to question the caliber of the engineer s working to resolve the leak. Maybe I'm being too harsh?
EDIT: To clarify point (a), I would have assumed that oil rigs would be required to build-in some sort of kill-switch in the event that even the smallest part of the process didn't go as planned.
I've used pairs off and on at work but never long-term. The part I find most useful about coding side-by-side with someone is that there is someone to question (or reassure) every small decision I make (for better or worse!). Particularly in coding, there are always many ways to solve each problem and having two sets of eyes (with even mediocre brains attached) frequently yields a better solution.
I find that a necessary part of pair programming is to switch up the pairs fairly often. Pairs have a tendency to become "comfortable" with each other's habits and can fall into a rut -- pairs should be shaken up to keep each everyone on their toes.
Also, you can learn a lot (about programming, people, life, etc.) when pair programming.
I always enjoy seeing posts like this. Project leaders know more about the code than anyone -- it's like seeing a lecture on a PhD thesis: this person knows more about this topic than anyone, anywhere. Feels good.
The Millenium Series (Girl With the Dragon Tattoo series) by Stieg Larrson