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: Tom Anderson on 17 Mar 2010 19:44 On Tue, 16 Mar 2010, Arne Vajh?j wrote: > So a 50 MB log4j log file from each cluster member. > > :-( That reminds me: i had a 3.1 GB error log file then other day. It filled up a partition and stopped everything working. I have no idea why the app did that. I just deleted the file and restarted. Seemed to be fine. tom -- Gens una summus.
From: Mike Schilling on 17 Mar 2010 19:46 Tom Anderson wrote: > On Tue, 16 Mar 2010, Arne Vajh?j wrote: > >> So a 50 MB log4j log file from each cluster member. >> >> :-( > > That reminds me: i had a 3.1 GB error log file then other day. It > filled up a partition and stopped everything working. > > I have no idea why the app did that. I just deleted the file and > restarted. Seemed to be fine. You didn't examine the file to see which messages were being logged repeatedly?
From: Arne Vajhøj on 17 Mar 2010 20:40 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. Arne
From: Arne Vajhøj on 17 Mar 2010 20:42 On 17-03-2010 19:46, Mike Schilling wrote: > Tom Anderson wrote: >> On Tue, 16 Mar 2010, Arne Vajh?j wrote: >>> So a 50 MB log4j log file from each cluster member. >>> >>> :-( >> >> That reminds me: i had a 3.1 GB error log file then other day. It >> filled up a partition and stopped everything working. >> >> I have no idea why the app did that. I just deleted the file and >> restarted. Seemed to be fine. > > You didn't examine the file to see which messages were being logged > repeatedly? That would be very nice to know. Arne
From: Mike Schilling on 17 Mar 2010 20:45
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. Very like memory leaks and memory corruption (in non-GC'd environments) in both of those tendencies. |