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: BGB / cr88192 on 13 Mar 2010 12:21 "Martin Gregorie" <martin(a)address-in-sig.invalid> wrote in message news:hngedh$iq1$1(a)localhost.localdomain... > 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! > yep... I think an API should handle pretty much all input that "could" be reasonably generated, even if outside of the expected domain. granted, edge cases are often a "try to fail gracefully" condition, rather than something which should be "crash and burn". >> 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. > this of course assumes that the designers and the programmers are not the same people. the programmers may be left deciding on matters of API as they are the ones' designing the API's (this being within the programmers' domain rather than the end-user's, which is where much more "design" attention is often directed...). >> 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. > granted (assuming, of course, there are such designers, rather than expecting all the programmers to be essentially self-directed and work out the details amongst themselves). a lot may then depend on who will use the API and for what. since the main user is often other programmers, one could argue that it them makes sense that the programmers should also specify matters of the API, overall project architecture, ...
From: Lew on 13 Mar 2010 12:36 BGB / cr88192 wrote: > I guess one can clarify what they mean by "math". Certainly not what you describe so rhetorically and prejudicially in your post. > there is a lot that is arguably math which I have noted is rather useful > (say: vectors, quaternions, matrices, ...). > similarly, nearly all manners of "calculating stuff" and "doing stuff" can > be useful with computers... > > > what is not so useful though is the sort of ultra-abstracting anti-reality > aspects of math, where one forsakes the thing being described for a big mass > of set notation or abstract logic. Strip away the pejorative descriptive terms, provide evidence that anything at all is "forsaken", and talk about things as they really are. You make a claim that something is "not useful" by mis-characterizing it, and using unupported claims that something is "forsaken", and depend on the emotional connotations of "ultra-" and "anti-" and "big mass" to make your point, thus hiding that your point is not, in fact, valid. The reality is that there is math, and there is mathematical. Some in this thread have tried to impose an artificial distinction between "math" and "science". I argue that there is not so much separation; one can see mathematics as the science of certain kinds of relationships, perhaps even harder than "science" since in math one can actually prove things. Likewise, science is an expansion of mathematics into the "real" world. It is troublesome at best to draw conclusions about reality by the application of artificial linguistic conventions. I would agree that computer programming is not math as such, nor is it science. It is, however, quite mathematical and scientific as a discipline, and uses the noetic principles and practices thereof to accomplish its goals. As to the utility of math, arguing that, say, set theory or predicate calculus are not useful is just the sort of anti-intellectualism and prejudice that makes education such a joke, deprives research of funding, and generally increases the stupidity of the population. Without those two things in particular, we would not have developed the amazingly powerful database systems in use today, to pick one example. Those disciplines are very useful, as anyone not too weak-egoed about their own intellectual capacity would recognize. It's a matter of understanding that theoretical research is an end unto itself, and that concomitant "real-world" applications emerge after that research has borne fruit. > IMO, this side of math is not particularly useful to the greater goods: > "make it work" and "get it done". You're absolutely right, that is opinion. > I would almost rather be stupid than live in that sort of "reality"... Tempting, so tempting ... -- Lew
From: Lew on 13 Mar 2010 12:40 BGB / cr88192 wrote: > this of course assumes that the designers and the programmers are not the > same people. .... > granted (assuming, of course, there are such designers, rather than > expecting all the programmers to be essentially self-directed and work out > the details amongst themselves). That is a specious distinction. When the same individual dons the roles of both designer and implementer, they are still distinct roles and carry the same responsibilities as when carried out by different people. This discussion woke me up to a mistake I was risking on my new project, that of not applying good design and specification first before programming, though I am in the roles of designer, architect and implementer on this one. I do not exclude iterative development and convergent specification in this model, only point out that when assuming the different roles one must still fully fulfill their obligations. -- Lew
From: BGB / cr88192 on 13 Mar 2010 14:43 "Lew" <noone(a)lewscanon.com> wrote in message news:hngimt$733$1(a)news.albasani.net... > BGB / cr88192 wrote: >> this of course assumes that the designers and the programmers are not the >> same people. > ... >> granted (assuming, of course, there are such designers, rather than >> expecting all the programmers to be essentially self-directed and work >> out the details amongst themselves). > > That is a specious distinction. When the same individual dons the roles > of both designer and implementer, they are still distinct roles and carry > the same responsibilities as when carried out by different people. > > This discussion woke me up to a mistake I was risking on my new project, > that of not applying good design and specification first before > programming, though I am in the roles of designer, architect and > implementer on this one. > > I do not exclude iterative development and convergent specification in > this model, only point out that when assuming the different roles one must > still fully fulfill their obligations. > yes, ok... well, sometimes specs are found and implemented, other times, they are designed and then implemented, and sometimes they develop naturally and are codified later. a lot depends on the particular situation. > -- > Lew
From: BGB / cr88192 on 13 Mar 2010 15:10
"Lew" <noone(a)lewscanon.com> wrote in message news:hngif2$6lp$1(a)news.albasani.net... > BGB / cr88192 wrote: >> I guess one can clarify what they mean by "math". > > Certainly not what you describe so rhetorically and prejudicially in your > post. > it depends... some endorse math by despising reality... >> there is a lot that is arguably math which I have noted is rather useful >> (say: vectors, quaternions, matrices, ...). >> similarly, nearly all manners of "calculating stuff" and "doing stuff" >> can be useful with computers... >> >> >> what is not so useful though is the sort of ultra-abstracting >> anti-reality aspects of math, where one forsakes the thing being >> described for a big mass of set notation or abstract logic. > > Strip away the pejorative descriptive terms, provide evidence that > anything at all is "forsaken", and talk about things as they really are. > > You make a claim that something is "not useful" by mis-characterizing it, > and using unupported claims that something is "forsaken", and depend on > the emotional connotations of "ultra-" and "anti-" and "big mass" to make > your point, thus hiding that your point is not, in fact, valid. > <snip> I think you mis my point... I am not saying that neither set theory not predicate logic are useful (for the things they do), rather, that it is not useful to use them and then disregard the underlying reality of the matter... a simple example is in talking about vectors: one can describe (in an introductory context) vectors in terms of their properties and their operations, and all is well. or, one can sit around with things like: <exists> alpha,beta <within> R^n <such-that> (alpha <circle> beta --> V) <within> E^n, ... this does not help, as the topic is then obscured, and for no particularly good reason... logic and sets can be used where they are appropriate, and IMO, this is not necessarily in the context of describing other things which can typically be described much more simply and much more directly within an introductory context... for example, if the purpose is that one will learn a topic (such as vector math) for sake of making use of it (say, for doing something with it), then it is not as helpful to be faced with lots of set theory, and not actually calculating anything (and then bombing tests due to in short order having little idea what is going on anymore...). after all, wouldn't all the set theory have presumably been in a class about using set theory?... what of the stuff a programmer does in a 3D engine?... it is almost entirely different... similarly, most of the conventional definitions (like one finds in places like Wikipedia or Mathworld) are based primarily on algebraic definitions, not on set-theoretic ones... or such... |