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: Mike Schilling on 17 Mar 2010 17:35 Arved Sandstrom wrote: > I don't doubt that 80-90 percent of the people who currently work as > programmers couldn't competently write reliable concurrent code, but > then OTOH they can't write reliable code period, so it's really got > nothing to do with concurrency. A software developer who can write > high-quality code can write high-quality concurrent code, and not have > to agonize over it either. Concurrency leads to difficult and subtle problems, particualry as code evolves over the years. That makes it more difficult to write correctly and more fragile than code which does not need to be concurrent.
From: Arved Sandstrom on 17 Mar 2010 18:35 Mike Schilling wrote: > Arved Sandstrom wrote: >> I don't doubt that 80-90 percent of the people who currently work as >> programmers couldn't competently write reliable concurrent code, but >> then OTOH they can't write reliable code period, so it's really got >> nothing to do with concurrency. A software developer who can write >> high-quality code can write high-quality concurrent code, and not have >> to agonize over it either. > > Concurrency leads to difficult and subtle problems, particualry as code > evolves over the years. That makes it more difficult to write correctly and > more fragile than code which does not need to be concurrent. I don't believe for a second that concurrency _inherently_ leads to difficult and subtle problems. I do believe that not understanding concurrent programming leads to difficult and subtle problems. I'll agree that you probably don't want junior programmers writing your multi-threaded code. But too many people make it sound like writing concurrent code is insanely difficult. Well, no, it's not. The execution of concurrent code is not a roll of the dice; it's as well-behaved as any other code if you knew what you were doing when you wrote it. Is "Java Concurrency In Practice" a really hard read? No. Is there such a huge amount of material in there that it's difficult to learn what you really need to know? No. Similarly for .NET - is "Concurrent Programming on Windows" (by Joe Duffy) such a hard read? No. I still believe that programmers who are finding that writing concurrent code is really, really hard probably find most other kinds of coding pretty difficult too. In my experience most programmers who are having problems reasoning about what their code may or may not do in a concurrent situation don't fully understand what their code is doing in a single-threaded environment, nor do they adequately understand the concurrency capabilities of their language. AHS
From: Mike Schilling on 17 Mar 2010 19:06 Arved Sandstrom wrote: > Mike Schilling wrote: >> Arved Sandstrom wrote: >>> I don't doubt that 80-90 percent of the people who currently work as >>> programmers couldn't competently write reliable concurrent code, but >>> then OTOH they can't write reliable code period, so it's really got >>> nothing to do with concurrency. A software developer who can write >>> high-quality code can write high-quality concurrent code, and not >>> have to agonize over it either. >> >> Concurrency leads to difficult and subtle problems, particualry as >> code evolves over the years. That makes it more difficult to write >> correctly and more fragile than code which does not need to be >> concurrent. > > I don't believe for a second that concurrency _inherently_ leads to > difficult and subtle problems. I do believe that not understanding > concurrent programming leads to difficult and subtle problems. Then your intuition disagrees with what I've observed over decades. I'm afraid I won't defer to it. > > I'll agree that you probably don't want junior programmers writing > your multi-threaded code. But too many people make it sound like > writing concurrent code is insanely difficult. Well, no, it's not. > The execution of concurrent code is not a roll of the dice; it's as > well-behaved as any other code if you knew what you were doing when > you wrote it. Multithreaded code beahves different every time you run it. The same inputs can lead toi different output, which is bad enough, but in the real world you oten find quite different inputs. It has problems like thread starvation that non-concurrent code does not have. It's inherently less portable than other Java code, because different platforms have different threading models; in particular, this can severely affect efficiency. > > Is "Java Concurrency In Practice" a really hard read? No. Is there > such a huge amount of material in there that it's difficult to learn > what you really need to know? No. Similarly for .NET - is "Concurrent > Programming on Windows" (by Joe Duffy) such a hard read? No. And? The JLS isn't particularly a hard read. That doesn't mean that Java programming is simple, regardless of the problem you're trying to solve. > > I still believe that programmers who are finding that writing > concurrent code is really, really hard probably find most other kinds > of coding pretty difficult too. In my experience most programmers who > are having problems reasoning about what their code may or may not do > in a concurrent situation don't fully understand what their code is > doing in a single-threaded environment, nor do they adequately > understand the concurrency capabilities of their language. I'm afraid my experience doesn't match these assertions.
From: Patricia Shanahan on 17 Mar 2010 19:20 Arved Sandstrom wrote: .... > I still believe that programmers who are finding that writing concurrent > code is really, really hard probably find most other kinds of coding > pretty difficult too. In my experience most programmers who are having > problems reasoning about what their code may or may not do in a > concurrent situation don't fully understand what their code is doing in > a single-threaded environment, nor do they adequately understand the > concurrency capabilities of their language. .... There may be a lot of people who find programming difficult regardless of concurrency, and even a few people like you who find concurrent programming easy, but there are definitely programmers who find concurrent programming harder than single thread. I'm one of them. If that is due to inherent incompetence as a programmer, it's a bit late to find out, after working as a programmer and computer architect from 1970 through 2002. I don't think it is due to any lack of understanding of concurrency. Several of the computer design patents on which I'm an inventor involve concurrency issues. I've debugged cache coherence in multiprocessor server prototypes. I still remember my delight when I switched from multiprocessor operating systems to compilers for a while in the 1980's, and got to work on something that ran the same way *every* time it ran with the same inputs. I could even stop the compiler at a break point, spend half an hour contemplating its state, tell it to continue, and it did exactly what it would have done without the break point. Sheer luxury. Patricia
From: Mike Schilling on 17 Mar 2010 19:39
Patricia Shanahan wrote: > I still remember my delight when I switched from multiprocessor > operating systems to compilers for a while in the 1980's, and got to > work on something that ran the same way *every* time it ran with the > same inputs. I could even stop the compiler at a break point, spend > half an hour contemplating its state, tell it to continue, and it did > exactly what it would have done without the break point. Sheer luxury. And when you step forward, you know you're going to stop where you expect, not in some other thread that happens to be executing the same code. |