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: Arved Sandstrom on 14 Mar 2010 19:54 Arne Vajhøj wrote: > On 14-03-2010 13:03, Martin Gregorie wrote: >> On Sun, 14 Mar 2010 09:00:47 -0700, BGB / cr88192 wrote: >>> "Martin Gregorie"<martin(a)address-in-sig.invalid> wrote in message >>>> IMO, an essential part of the design is making it testable. That should >>>> have equal priority with usability, adequate error and incident >>>> reporting and a way to measure performance. All are essential to >>>> developing a good application. I seldom use a debugger, preferring to >>>> use the trace log approach to debugging& testing. I make sure the >>>> tracing and its detail levels are easily controlled and invariably >>>> leave this code in the product. The performance hit is almost >>>> undetectable when its turned off and the payoff from being able to turn >>>> it on during a production run is huge. >>> I use a debugger some amount, usually to identify where a problem has >>> occured and the situation at the place it has occured. >>> >> I've usually found debuggers to be the slower option in terms of >> programmer time. Tracing statements that show data as well as location >> are a better way of tracking down the problem - especially when the >> causative code is some distance from the apparent trouble spot. > > Not to mention that quite often the problem does not happen > when debugging. Concurrency problems are frequent problems. > Often debugging requires optimization turned off and then > bad code may work. Etc.. > > In server programming debuggers are mostly a tool to > impress pointy haired bosses with. I beg to differ. Not two weeks ago I saved a lot of time by debugging down into a library used by a client's J2EE application; the problem was almost certainly caused by *our* code, but it was manifesting in the 3rd party library. Any other approach other than using a debugger would have been considerably more time-consuming. I've found that in J2EE programming, unless you're actually the guy writing the guts of the app server, that a very small percentage of all defects have anything to do with concurrency issues, provided that the app programmers have half a clue. And debugging can often be the easiest way to trace one's way through what can be rather convoluted paths of execution. AHS
From: jebblue on 14 Mar 2010 20:20 On Fri, 12 Mar 2010 10:26:57 +0000, Arved Sandstrom wrote: > Lew wrote: >> sl(a)my-rialto wrote: >>>> Someone says if one does not know the difference between "equality" >>>> and "equivalence", then one is an entry-level developer at best. >>>> >>>> What is your opnion ? (I think we should not talk about mathematical >>>> concepts, since it is the software developer in question.) >> >> Patricia Shanahan wrote: >>> I think the question needs some context to make sense. Both terms are >>> very heavily overloaded in computer science. >>> >>> For example, consider the following: "The equals method implements an >>> equivalence relation on non-null object references:" >>> >>> http://java.sun.com/javase/6/docs/api/java/lang/Object.html#equals(java.lang.Object) >>> >>> >>> Maybe this is a rather vague way of getting at the following issue: I >>> would indeed expect a competent Java developer to understand the >>> difference, in Java, between a.equals(b) and a==b for reference >>> expressions a and b. >> >> Well, there we go introducing mathematical concepts, from right there >> in the Javadocs, no less!, despite the OP's attempt to eliminate the >> only reasonable context in which to answer his point. >> > Both terms actually have clear English meanings - "equality" means (or > should mean) that two things *are* the same, and "equivalence" means (or > should mean) that two things can be substituted, that they behave the > same way. A man and woman are equal and yet very different. -- // This is my opinion.
From: Patricia Shanahan on 15 Mar 2010 01:15 Tom Anderson wrote: > On Sun, 14 Mar 2010, Patricia Shanahan wrote: > >> BGB / cr88192 wrote: >> ... >>> often, if there is no good way to test or use a piece of code, well >>> then this is a bit of an issue... >> >> The conditions that trigger a piece of code in operation may be >> difficult to cause in system test, > > If it's difficult to cause with a system test, then it's possible, and > that's something that can and should be tested - corner cases are > something you should pay particular attention to, because they usually > won't be caught by informal testing. > > If it's impossible to cause with a system test, then why is the code there? I take the view that any multi-processor or multi-thread timing case that cannot be proved impossible will happen sooner or later, even if there is no known system test that can be guaranteed to produce it. That means the code to handle it should be there, and should be tested. Patricia
From: Arved Sandstrom on 15 Mar 2010 04:48 jebblue wrote: > On Fri, 12 Mar 2010 10:26:57 +0000, Arved Sandstrom wrote: > >> Lew wrote: >>> sl(a)my-rialto wrote: >>>>> Someone says if one does not know the difference between "equality" >>>>> and "equivalence", then one is an entry-level developer at best. >>>>> >>>>> What is your opnion ? (I think we should not talk about mathematical >>>>> concepts, since it is the software developer in question.) >>> Patricia Shanahan wrote: >>>> I think the question needs some context to make sense. Both terms are >>>> very heavily overloaded in computer science. >>>> >>>> For example, consider the following: "The equals method implements an >>>> equivalence relation on non-null object references:" >>>> >>>> http://java.sun.com/javase/6/docs/api/java/lang/Object.html#equals(java.lang.Object) >>>> >>>> >>>> Maybe this is a rather vague way of getting at the following issue: I >>>> would indeed expect a competent Java developer to understand the >>>> difference, in Java, between a.equals(b) and a==b for reference >>>> expressions a and b. >>> Well, there we go introducing mathematical concepts, from right there >>> in the Javadocs, no less!, despite the OP's attempt to eliminate the >>> only reasonable context in which to answer his point. >>> >> Both terms actually have clear English meanings - "equality" means (or >> should mean) that two things *are* the same, and "equivalence" means (or >> should mean) that two things can be substituted, that they behave the >> same way. > > A man and woman are equal and yet very different. > Then clearly how they are equal needs to be qualified, does it not? In fact when the word "equal" is applied in the sense of gender equality, or equality before the law, or "all men are created equal", such qualifications are made. We make exactly the same qualifications in a programming language like Java when we write equals() methods. AHS
From: Arved Sandstrom on 15 Mar 2010 04:57
Patricia Shanahan wrote: > Tom Anderson wrote: >> On Sun, 14 Mar 2010, Patricia Shanahan wrote: >> >>> BGB / cr88192 wrote: >>> ... >>>> often, if there is no good way to test or use a piece of code, well >>>> then this is a bit of an issue... >>> >>> The conditions that trigger a piece of code in operation may be >>> difficult to cause in system test, >> >> If it's difficult to cause with a system test, then it's possible, and >> that's something that can and should be tested - corner cases are >> something you should pay particular attention to, because they usually >> won't be caught by informal testing. >> >> If it's impossible to cause with a system test, then why is the code >> there? > > I take the view that any multi-processor or multi-thread timing case > that cannot be proved impossible will happen sooner or later, even if > there is no known system test that can be guaranteed to produce it. That > means the code to handle it should be there, and should be tested. > > Patricia It seems to me that if you are sufficiently skilled in concurrency programming that you can pinpoint a situation that you cannot test but can't prove impossible, that rather than spend time writing code to handle the execution of the "possibly impossible" code, and then testing that handler code, that you might be better off simplifying your original code in the first place. AHS |