Dude, you are rude. Grow some people skills

You said, Just use databases and transactions. Fixed! This was in response to a post suggesting that programmers need to learn to deal with concurrency.

The problem is that this is not enough in real applications! You can wave the magic wand of databases and transactions, but you haven't replaced the need to understand how transactions work.

And, contrary to what you claim, it is stupid to just say, "OK, so now we need concurrency experts." It is easier to understand concurrency issues than it is to learn a new application. Therefore if concurrency matters, it is more efficient to make sure that your programmers understand concurrency than it is to try to hire an expert after the fact to solve the problem. This goes doubly because bad application design can easily make scalability impossible, and programmers who do not understand concurrency issues have no idea when they are taking a dangerous path.

Put another way, it can be faster and cheaper to hire competent people in the first place than it is to hire incompetents then hire competent people to fix the crap that the incompetents produce.

Regards,
Ben

Post #190,347 by tablizer 1/16/05 2:16:01 AM Reply	Dude, you are rude. Grow some people skills So your answer reflected both ignorance of what kinds of issues concurrent applications hit under load, and also ignorance of the fact that transactions are not created equal. I didn't answer anything. I only asked questions. Of course you have to bring in or have transaction experts on hand for heavy-duty issues. However, they tend to only have to focus a handful of bottleneck areas rather than every transaction. ________________ oop.ismad.com
Post #190,458 by CRConrad 1/17/05 1:57:50 AM Reply	This was one of your most hilarious posts ever, Bryce.
Post #190,533 by tablizer 1/17/05 10:59:48 PM Reply	I am learning NOT to flame back. Me grow up........I think ________________ oop.ismad.com
Post #190,552 by CRConrad 1/18/05 2:00:54 AM Reply	A: Doubt it. B: Still, YOU calling SOMEONE ELSE rude=>funnee
Post #190,858 by ben_tilly 1/19/05 6:29:29 PM Reply	Yes, you did answer something You said, Just use databases and transactions. Fixed! This was in response to a post suggesting that programmers need to learn to deal with concurrency. The problem is that this is not enough in real applications! You can wave the magic wand of databases and transactions, but you haven't replaced the need to understand how transactions work. And, contrary to what you claim, it is stupid to just say, "OK, so now we need concurrency experts." It is easier to understand concurrency issues than it is to learn a new application. Therefore if concurrency matters, it is more efficient to make sure that your programmers understand concurrency than it is to try to hire an expert after the fact to solve the problem. This goes doubly because bad application design can easily make scalability impossible, and programmers who do not understand concurrency issues have no idea when they are taking a dangerous path. Put another way, it can be faster and cheaper to hire competent people in the first place than it is to hire incompetents then hire competent people to fix the crap that the incompetents produce. Regards, Ben I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)

Welcome to IWETHEY!