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: Arne Vajhøj on 17 Mar 2010 20:52 On 17-03-2010 20:45, Mike Schilling 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. > > Very like memory leaks and memory corruption (in non-GC'd environments) in > both of those tendencies. Yep. For sufficient large code bases, then there will always be some bad programmers or good programmers with a bad day that makes mistakes. "errare humanum est" Arne
From: Arved Sandstrom on 18 Mar 2010 05:38 Patricia Shanahan wrote: > 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. I don't think I wrote that I find concurrent programming easy, although much of it is. I'm sure even you have found that much concurrent programming is quite straightforward. My point was is that concurrent programming simply isn't incredibly difficult, as many other folks seem to delight in pointing out in articles and posts. I took pains in my posts in this thread to emphasize that point, using words like "insanely" and "really, really". It's not that concurrent programming, all other things being equal in a given situation, isn't more difficult (as a rule), it's simply that I find that it's not usually *way more* difficult. So let's be clear on that - it's not that concurrent programming isn't somewhat harder - it is. But I don't think or believe or find that it's *much, much* harder. Period. > 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. Well, let me ask, are you actually struggling with run of the mill code that needs to execute in a multithreaded environment? Do you find the use of java.util.concurrent classes to be a black art? I doubt very much that you are struggling or that you do find concurrency classes to be difficult to use. > 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 AHS
From: Arved Sandstrom on 18 Mar 2010 05:56 Mike Schilling wrote: > 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. Nobody is asking you to defer to anyone else's observations. I'm simply stating that I don't believe that concurrent programming is very difficult. If you think that concurrent programming is inherently very difficult then that's your prerogative. >> 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. Wait, hold on - let's be clear on what you just said. "Same inputs can lead to different output". And "multithreaded code behaves different every time you run it". That, translated, means that the code isn't thread-safe. > 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. Are you finding it difficult, though? Leaving aside the specific real-world problems, are you finding the implementations in Java to be really hard work? I doubt that you are. In the same vein, do you really find concurrent programming to be _very_ difficult, or simply deserving of some extra care and attention just like you'd apply to the efficient and correct implementation of a complex algorithm? I find it much more like the latter, rather than that multi-threading suddenly makes everything really, really hard. >> 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. Well, it could be that the concurrency code that you are writing is considerably more complex than run of the mill concurrency problems. That could bias your views. Of course, the same could be said of me - perhaps all of the dozens of concurrency scenarios that I've had to implement were all rudimentary and trivial, and that's why I think they all are. AHS
From: Arved Sandstrom on 18 Mar 2010 06:02 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. > > Arne 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. AHS
From: Thomas Pornin on 18 Mar 2010 07:22
According to Mike Schilling <mscottschilling(a)hotmail.com>: > Very like memory leaks and memory corruption (in non-GC'd > environments) in both of those tendencies. That's the point, actually. Tremendous design efforts went into Java to make many aspects of programming easier. In particular, the GC is an automatic system to solve the problem of memory allocation, problem which proved to be very difficult to tackle by most programmers, even good programmers, regardless of how "simple" it may look from an overly theoretical point of view. The same amount of efforts did not went (yet) into concurrency. Right now, Java has some primitives ('synchronized' and wait()/notify(), mostly), which are quite low-level. They are much better than nothing at all, but I would still classify them at the same "level" than malloc()/free() with regards to memory allocation. In that view, Java's support for concurrency is still very "C". You may observe, for instance, that if you write a multi-threaded application in C, it will use, for the concurrency part, the same structure than a similar Java application (you replace synchronized blocks with pthread_mutex_lock() or EnterCriticalSection(), and wait()/notify() with conditions or semaphores). Thus it is not that concurrency is especially hard, only that everything else has been made easier. Making concurrency easier, in a way similar to what GC provides to memory allocation, is an active research field. What Java does is not the nec plus ultra in that matter; quite the opposite. One approach (that's not the only one) is known as "actor programming" and the Erlang language shows how it runs. --Thomas Pornin |