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 13 Mar 2010 07:46 Arne Vajhøj wrote: > On 12-03-2010 21:08, Arved Sandstrom wrote: >> Arne Vajhøj wrote: >>> On 12-03-2010 05:26, Arved Sandstrom wrote: >>>> 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 mathematical and CS definition in fact tracks the common English >>>> meanings of these 2 words, and the language concerning Object.equals >>>> that Patricia quoted does say exactly this: equals is an implementation >>>> of equivalence. >>>> >>>> My point is that the common English, the mathematical and the CS >>>> definitions of the two terms are pretty much the same. And programming >>>> languages that differentiate between the two also track those >>>> definitions. We see that Java does. >>> >>> I don't think Java follow those rules. >>> >>> I assume that you consider equals to be equivalence and >>> == to be equality. >>> >>> But it is not so. >>> >>> Example: >>> >>> public class ZZ { >>> public static void main(String[] args) { >>> int iv = 2; >>> double xv = 2.0; >>> System.out.println(iv == xv); >>> } >>> } >> >> I do consider == to be equality (identity). Same object for references, >> same value for primitives...that's equality. > > But 2 and 2.0 are not identity equals. No, but as I indicate I don't see that we ever compared 2 and 2.0 for identity in your example. You can't do that with direct use of ==, because of promotion. This is one of the C-based hiccups of Java. For primitives of different types we shouldn't even be asking the question ==? >> An implementation of equals() I consider to be _an_ implementation of an >> equivalence relation; == is clearly another. >> >> I'm not that perturbed by your example. Java == equality for primitives >> of different types is what we define it to be, so defining it to be an >> operation that takes place after primitive conversions is not wrong. In >> effect we're not saying that (int 2) == (double 2.0), we're saying that >> (double 2.0) == (double 2.0); the binary numeric promotion happened >> before the ==. > > That promotion is done by ==. "Done by?" I don't see that. "Done on behalf of", sure. Unless a bytecode guru tells me otherwise I expect that == just like + is blissfully unaware that it could ever be asked to work with two primitives of differing types. Now, if each binary operator duplicates all the numeric promotion logic I could see that they are responsible for it. AHS
From: Martin Gregorie on 13 Mar 2010 08:16 On Fri, 12 Mar 2010 21:34:10 -0500, Arne Vajhøj wrote: > On 12-03-2010 20:33, Martin Gregorie wrote: >> On Fri, 12 Mar 2010 20:02:01 -0500, Arne Vajhøj wrote: >>> Developers that google solutions and copy paste them and generally >>> consider the computer a black box may not use math. >>> >> No argument here. >> >>> But developers that like to understand what they are doing and why >>> will be thinking math every hour at work whether they realize it or >>> not. >>> >> Here we diverge. Despite spending my working life in IT, I'm a >> scientist by training, not a mathematician. >> >> I work on the principle that a software design is a hypothesis from >> which true and false predictions can be made. Code written to implement >> the design is then exhaustively tested against the predictions to >> verify the correctness of the design. > > I somehow doubt that you always test and never deduct. > Probably true and the analogy is a bit stretched too, but I do write tests from the spec (*never* from the code). I like to have some form of spec, even if the code is for my own use, unless the requirement is trivially simple. I usually design the test set so it can be used for regression testing with automated results checking, even if the results check is merely via 'diff'. As I said: not a mathematical approach but, I hope, a reasonably scientific one. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
From: BGB / cr88192 on 13 Mar 2010 09:30 "Martin Gregorie" <martin(a)address-in-sig.invalid> wrote in message news:hng384$97p$1(a)localhost.localdomain... > On Fri, 12 Mar 2010 21:34:10 -0500, Arne Vajh�j wrote: > >> On 12-03-2010 20:33, Martin Gregorie wrote: >>> On Fri, 12 Mar 2010 20:02:01 -0500, Arne Vajh�j wrote: >>>> Developers that google solutions and copy paste them and generally >>>> consider the computer a black box may not use math. >>>> >>> No argument here. >>> >>>> But developers that like to understand what they are doing and why >>>> will be thinking math every hour at work whether they realize it or >>>> not. >>>> >>> Here we diverge. Despite spending my working life in IT, I'm a >>> scientist by training, not a mathematician. >>> >>> I work on the principle that a software design is a hypothesis from >>> which true and false predictions can be made. Code written to implement >>> the design is then exhaustively tested against the predictions to >>> verify the correctness of the design. >> >> I somehow doubt that you always test and never deduct. >> > Probably true and the analogy is a bit stretched too, but I do write > tests from the spec (*never* from the code). I like to have some form of > spec, even if the code is for my own use, unless the requirement is > trivially simple. I usually design the test set so it can be used for > regression testing with automated results checking, even if the results > check is merely via 'diff'. > > As I said: not a mathematical approach but, I hope, a reasonably > scientific one. > agreed... yes, one does testing based mostly on the public API's and defined behavior. however, as I see it, this isn't about either math or proof, rather about verifying that the thing works and does about what it is said to do. as I see it, a major part of the programming task is, in effect, defining and implementing API's. one decides what the code "should" do, and implements an external interface to make it reasonably do so. what happens internally, then, is outside the scope of concern, as the particular code is, in itself, a black box (the code which uses it should not know or care how it works apart from its external behavior and characteristics). likewise, things are specified in terms of their externalities, and not their internal structure. very often, code tends to be large and complicated enough that, to me, mathematical-style proof seems almost useless here (and even then, what is to say that the code is itself conforming to the proof and does not contain many of the other far more common bugs, such as the sort resulting from occasional typing errors or momentary brain-deadedness?...). what "proof" can be meaningfully done on code is often instead implemented within the compilers (such as type-checking, ...). far more useful then is to test and verify that all works, and if reasonable (or often even unreasonable) inputs are found which break the code, then one can look into fixing these as well.
From: BGB / cr88192 on 13 Mar 2010 09:49 "Arved Sandstrom" <dcest61(a)hotmail.com> wrote in message news:RFomn.67942$Db2.60974(a)edtnps83... > 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 mathematical and CS definition in fact tracks the common English > meanings of these 2 words, and the language concerning Object.equals that > Patricia quoted does say exactly this: equals is an implementation of > equivalence. > > My point is that the common English, the mathematical and the CS > definitions of the two terms are pretty much the same. And programming > languages that differentiate between the two also track those definitions. > We see that Java does. > > Having said all this I did have to do a few minutes of research to remind > myself that the way the words are used in math and in CS are also what > they mean in common speech. And I don't normally walk around thinking that > equals is an implementation of an equivalence relation. :-) > I will assert here that even in English their meanings are not sufficiently solid to make this point. the words in natural speech tend to float all over the place, and to say solidly that X means Y is misguided at best. even "trivial" words, such as "the" or "an" have no clearly defined meaning, and tend to vary from one context to the next, and depend on the words to which they apply, ... "logic" is then almost meaningless on natural speech, and one is probably far better off with a probablistic interpretation. "look, hand raised birds" vs "look, hand raised children" (or "look, hand raised, children", ...). the first 2 have different meanings even though the structure is about the same, and the 3rd means something different despite using the same words in the same order. birds may be raised by hand, children may raise hands, and children may be told that the proper way to ask the questions is to have hand raised. (with awkwardities in interpretations as to confuse even native speakers...). it is not meaningful to expect much more than this.
From: Martin Gregorie on 13 Mar 2010 11:27
On Sat, 13 Mar 2010 07:30:49 -0700, BGB / cr88192 wrote: > yes, one does testing based mostly on the public API's and defined > behavior. > Quite, which puts many 'designers' and 'design methods' on the spot, especially use-cases. All too frequently these are all airy-fairy handwaving stuff that serves as the specification because anything more rigorous in the way of specifications is entirely absent. I've even seen cases where, when this was pointed out to the designer, he simply changed the entire use-case to omit the problem area: if the problem isn't mentioned in the use-case it doesn't exist. In the case I'm thinking of, the final use-case's relationship to the client's requirements were pretty much illusory. Now write a set of useful regression tests from that type of specification! > as I see it, a major part of the programming task is, in effect, > defining and implementing API's. one decides what the code "should" > do, and implements an external interface to make it reasonably do so. > I'd move that activity further up the food chain. If API specification is left to programmers then the designers haven't thought sufficiently about their job and you're probably on track for major problems and rewrites during integration testing. > what happens internally, then, is outside the scope of concern, as the > particular code is, in itself, a black box (the code which uses it > should not know or care how it works apart from its external behaviour > and characteristics). > Yes. The designers must specify both the external behaviour and appearance, i.e. both the API and the actions to be taken for or valid inputs. The calibre of the programmers determine whether the designer can leave sensible handling of invalid input to them or if this too must be specified. -- martin@ | Martin Gregorie gregorie. | Essex, UK org | |