Re: First class developer: who ?
On 18-03-2010 06:02, Arved Sandstrom wrote:
Arne Vajh?j wrote:
On 17-03-2010 18:35, 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.
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.
My experience is that concurrency problems have a bad tendency to
happen even with good programmers and concurrency problems have
a very nasty characteristics of being very difficult to find.
That's suggestive language, Arne: "concurrency problems have a bad
tendency to happen". Well, perhaps they do for many programmers,
although it's then arguable as to whether they are good concurrency
programmers or simply good programmers except when it comes to concurrency.
The reason I say it's suggestive is because it makes it sound like the
programmer didn't cause the concurrency problems. They "just" happened.
Well, no, they didn't just happen - a misunderstanding of how to write
concurrent code is what led to the programmer writing incorrect code.
I will concede that if a programmer has written a dog's breakfast as far
as concurrency is concerned that it's then frequently a losing cause to
try to diagnose defects.
Of course it is the programming writing code with a bug in.
But whether it is possible to write guaranteed correct code
is not very important for for real world software.
What is important is the number of bugs possible to introduce.
If there are lots of possibilities to introduce bugs, then
some of them will be introduced.
A normal development team has a few very good programmers,
a bunch of OK programmers and a few very bad programmers.
Any of those programmers has a few relative brilliant days,
a bunch of OK days and a few horrible days.
Programming language designs and development methodologies
that assumes very good programmers not having bad days
are useless.
Because those assumptions are rarely met.
Multithreaded code often result in concurrency problems, because
there are so many ways to create problems that some problems will
get created.
And those problems:
- has a higher chance of slipping through code review and test
- can be very difficult to troubleshoot
- can have distasterous impact
I hate those bugs!
Arne