Re: First class developer: who ?
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
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.