First class developer: who ?
in [Java Help]
|
Prev: Speaking of thread safety?
Next: solutions manual to A First Course In Probability 7th Edition by Sheldon M. Ross
From: Lew on 20 Mar 2010 10:32 Arved Sandstrom wrote: > Let me ask you this, Mike. I would have to assume that you've done > substantially the same reading I have (nature of, if not the same > titles), and likely also have considerable experience in concurrent > programming. Let's take Java concurrent programming as an example, > because of the NG we're in, and examine the JCIP book specifically. > After reading and re-reading that book, is there anything in it that > leads you to believe that only a tiny elite of superstar developers can > ever "get" concurrent programming in Java? This is an irresolvable discussion. Many programmers find concurrency programming to be subtle and difficult compared to other areas, Arved's experience notwithstanding. Arved's facility in that area will never convince them otherwise, just as their difficulties will never make concurrency seem especially difficult to Arved. There are a number of programmers out there who have trouble getting a (single-threaded) 'for' loop correct. There's no objective way to say /a priori/ that such-and-such area of programming is especially difficult because it's so dependent on an individual's talents. That said, across the industry there are many programmers who find concurrency difficult and subtle. Perhaps their talents are that different from Arved's, or perhaps like the hapless 'for'-loop schmo they just haven't grokked it yet and they'll improve when they do. It is objective that concurrency bugs are harder to diagnose, test and debug than many other kinds, and that elevates the importance of catching them at the source rather than at runtime. It behooves us to form mental models of concurrency that let us program for it as effectively and effortlessly as Arved, Josh Bloch, Doug Lea and Brian Goetz do. -- Lew
From: Mike Schilling on 20 Mar 2010 11:00 Arved Sandstrom wrote: > > Let me ask you this, Mike. I would have to assume that you've done > substantially the same reading I have (nature of, if not the same > titles), and likely also have considerable experience in concurrent > programming. Let's take Java concurrent programming as an example, > because of the NG we're in, and examine the JCIP book specifically. > After reading and re-reading that book, is there anything in it that > leads you to believe that only a tiny elite of superstar developers > can ever "get" concurrent programming in Java? I've never said that. Nor has Patricia, nor anpne else in this thread. What we have said is that concurrency introduces compleixty and bugs that are difficult to reproduce, so that, compared to single-threaded programs, more effort is involved in producing a product of the same quality. So I'll ask you again: do you think you could code ConcurrentLinkedQueue from scratch and be satisfied that it's bug-free in roughly the same amount of time as, say, TreeMap?
From: Arved Sandstrom on 20 Mar 2010 11:20 Lew wrote: > Arved Sandstrom wrote: >> Let me ask you this, Mike. I would have to assume that you've done >> substantially the same reading I have (nature of, if not the same >> titles), and likely also have considerable experience in concurrent >> programming. Let's take Java concurrent programming as an example, >> because of the NG we're in, and examine the JCIP book specifically. >> After reading and re-reading that book, is there anything in it that >> leads you to believe that only a tiny elite of superstar developers >> can ever "get" concurrent programming in Java? > > This is an irresolvable discussion. Many programmers find concurrency > programming to be subtle and difficult compared to other areas, Arved's > experience notwithstanding. Arved's facility in that area will never > convince them otherwise, just as their difficulties will never make > concurrency seem especially difficult to Arved. There are a number of > programmers out there who have trouble getting a (single-threaded) 'for' > loop correct. There's no objective way to say /a priori/ that > such-and-such area of programming is especially difficult because it's > so dependent on an individual's talents. > > That said, across the industry there are many programmers who find > concurrency difficult and subtle. Perhaps their talents are that > different from Arved's, or perhaps like the hapless 'for'-loop schmo > they just haven't grokked it yet and they'll improve when they do. It > is objective that concurrency bugs are harder to diagnose, test and > debug than many other kinds, and that elevates the importance of > catching them at the source rather than at runtime. It behooves us to > form mental models of concurrency that let us program for it as > effectively and effortlessly as Arved, Josh Bloch, Doug Lea and Brian > Goetz do. > Well, here's the thing - it's not just me. Clearly fairly large numbers of developers are getting it, because there's a lot of pretty reliable concurrent code out there. And it's not like Josh Bloch, Doug Lea and Brian Goetz (and Joe Duffy going apeshit on the .NET side of things) wrote all of it. If I ran across a reasonably senior developer who, when presented with a concurrent programming problem, said that he or she was finding multi-threading complicated and hard to reason about, I'd simply ask them how much experience they have with concurrent programming. And how much study they have devoted to it. If the answer is "none" or 'not much", well, duh. I wouldn't expect any developer to be particularly good at anything if they have little knowledge of it. I will absolutely agree on one thing, and that's that in concurrent programming, more so than in most other types of programming, you'd better have your act together when it comes to being a rounded software developer. In many other areas you can be sloppy and write sloppy ill-designed code, and user testing finds your defects, and you fix them...not so in concurrent programming. But the fact that the nature of programmer-created defects in concurrent code - let me re-emphasize that, _programmer-created defects_ in concurrent code - is such that they are harder to reason about than defects in most non-concurrent code does not equate to an observation that concurrent programming is actually that much more difficult. We should maybe separate this discussion into two parts: are people saying that correct concurrent programming is very difficult, or are they saying that debugging badly written concurrent code is very difficult? I certainly won't argue with the latter statement. AHS
From: Arved Sandstrom on 20 Mar 2010 16:48 Mike Schilling wrote: > Arved Sandstrom wrote: >> Let me ask you this, Mike. I would have to assume that you've done >> substantially the same reading I have (nature of, if not the same >> titles), and likely also have considerable experience in concurrent >> programming. Let's take Java concurrent programming as an example, >> because of the NG we're in, and examine the JCIP book specifically. >> After reading and re-reading that book, is there anything in it that >> leads you to believe that only a tiny elite of superstar developers >> can ever "get" concurrent programming in Java? > > I've never said that. Nor has Patricia, nor anpne else in this thread. > What we have said is that concurrency introduces compleixty and bugs that > are difficult to reproduce, so that, compared to single-threaded programs, > more effort is involved in producing a product of the same quality. Perhaps I'm reading more into what you guys are saying than I should, but the sense I am getting from your statements is that concurrency introduces _much_ more complexity and difficulty, so much more that simple problems become difficult ones, and difficult single-threaded problems become almost infernally complicated with concurrency. My argument is more along the lines that introducing concurrency into a problem may add minor, moderate or major levels of extra difficulty, but that I see no evidence that it's always or even often got to be the latter. > So I'll > ask you again: do you think you could code ConcurrentLinkedQueue from > scratch and be satisfied that it's bug-free in roughly the same amount of > time as, say, TreeMap? Looking at the Java 6 versions of the APIs for both, and given that you imposed no other requirements other than that both be bug free, I'd say yes. After all, given no requirements other than correctness, I don't have to produce a ConcurrentLinkedQueue that is as performant or efficient or elegant, with extra classes like java.util.concurrent.atomic.AtomicReferenceFieldUpdater and sun.misc.Unsafe, as what Doug Lea wrote. AHS
From: Arved Sandstrom on 20 Mar 2010 20:35
Arved Sandstrom wrote: [ SNIP ] > After all, given no requirements other than correctness, I don't have to > produce a ConcurrentLinkedQueue that is as performant or efficient or > elegant, with extra classes like > java.util.concurrent.atomic.AtomicReferenceFieldUpdater and > sun.misc.Unsafe, as what Doug Lea wrote. I meant to add, there isn't a single use of the "synchronized" keyword in ConcurrentLinkedQueue. I consider myself a competent concurrency programmer, but not a god like Doug Lea or Brian Goetz. My estimate was based on being allowed to use "synchronized", which as a first cut is a sensible thing to do. AHS |