What is a software engineer?
in [JavaScript]
|
Prev: html form in javascript variable
Next: Microsoft and attributes--will they ever figure them out?
From: RobG on 15 Nov 2009 19:24 On Nov 15, 11:07 pm, The Natural Philosopher <t...(a)invalid.invalid> wrote: > RobG wrote: > > Empirical evidence is used to develop and support a theory, however > > the theory itself must have a scientific basis - that is, it must have > > a rational explanation that will predict behaviour in similar > > circumstances. Simply observing that something happens is just an > > observation of a fact, an experiment. Being able to repeat an > > experiment and achieve the same outcome every time doesn't prove > > anything other than that the experiment is repeatable, it doesn't > > provide any explanation of why the experiment "works", nor predict the > > likely outcome if the parameters are changed, nor provide any bounds > > within which it "works" or "fails". > > However most of science is, in the *final* analysis, precisely what you > describe. No, it isn't. Science attempts to understand and explain the underlying system that causes outcomes. It is also open to new theories that better explain outcomes, it doesn't blindly accept that because something "always happens" that it will continue to happen. > a set of propositions that may (or may not!) reflect an underlying > reality, whose predictions have failed to ever be falsified by > experiment, and whose propositions CAN in principle be falsified. > > And which actually add some value that competing theories do not. It is by disproof that new theories emerge or existing ones are strengthened. You can't disprove a theory by contrary experimentation alone, you have to propose a theory as to *why* the evidence is contradictory. The contrary evidence may simply provide a boundary for where the theory holds and where it doesn't. Quantum theory is the antithesis of relativity, but doesn't disprove it. Kepler's laws of planetary motion were fine until instruments were accurate enough to discover the errors, but then the hunt was on for a better theory. Without Einstein's theory of relativity, modern GPS systems would be impossible. Without Hawking's theories we'd never have found black holes, even though they were predicted by Einstein's theories. > Cf Kuhn, Popper, Instrumentalism, et al. There's a big difference between instrumentalism and scientific experimentation. Experiments and their results are a fundamental part of developing theories, it is the people that I call tradesmen that are instrumentalists. > > Without the explanation, there is no theory. There is no application > > of scientific knowledge, no understanding of why the result occurs. It > > is no more than faith - it's always worked before in their limited > > experience, therefore they expect it to always work. Anyone who > > performs work using such methods should be categorised as a trades > > person. They are certainly not professionals applying scientific > > theories or methods. They are not engineers. > > :-) sadly, there are no final explanations for anything. I think you're being deliberately disingenuous. Science is constantly evaluating new theories and updating old ones, even tossing them out. There is no expectation that a theory will last forever, nor that any theory is "final". > will the sun rise tomorrow? Can't say really. Then you should learn the physics of solar motion. There are theories that predict when the sun won't rise tomorrow - it's a few billion years away, but it's been predicted for quite some time. > It always HAS...whether > that's because it obeys certain immutable laws of physics that we > BELIEVE to be universal true (nay DEFINE to be universally true) or > whether its because the Ngongobongo tribe absolutely do a special tribal > dance every sunset to make sure it does, is a very moot point. You don't seem to know much about science - there is no such thing as an immutable law of physics. Newton's laws were good enough for the time in which they were proposed, however we now know much more than we did in the 1600s. Einstein's laws were pretty good too, but they have their limits also - he never did find his unifying theory, perhaps there isn't one. But that wont stop people trying to find it. > Oh, and an explanation is not a theory, and certainly not a scientific > theory, nor is a scientific theory an explanation. Now you've lost it. > It is if you like, > the expression of the result of a lot of experimental data in terms of > an algorithm. More or less. And that algorithm is the explanation. > In the same way that the reality of our perceptions is a > compressed representation of all the salient features of all the data we > are subjected to. That isn't a scientific theory - you're back to simple observed results. > E=mc^2 is a shorthand algorithm for calculating mass-energy > relationships. That is borne out by observation. I am not sure it > explains anything at all. Not in any fundamental way. Its just the > expression of a constancy of relationship between certain elements of a > world we have defined in certain precise terms. I think this is some kind of straw man argument. You put up a famous equation and say "that's not a theory", well, it isn't, and I didn't say it was. That equation is part of a theory - Einstein's theory of special relativity, which built on work by many others incuding Galileo. > 'Because God wills it' is the ultimately irrefutable explanation for > everything. Rubbish. It is refuted quite simply - where is the proof of this god? If rational explanation exists, then clearly there is no need for a god and hence no evidence for its existence. > That doesn't make it a scientific theory in any sense. More straw men - no one said it was, it's faith. Science does not state categorically that one or more gods can't or don't exist, it just says that there is no proof of a god. Read a bit of Richard Dawkins' work, specifically "The God Delusion". > A professional engineer is one who makes his living out of designing > engines. HOW he does it, is really no part of what he is. That is an utterly superficial excuse for logic. It's all about how the work is done that matters, that's the whole point of this thread. > > Professional is no guarantee of quality. Of course not, and I didn't I say that. Quality is a whole new topic - as if this hasn't gone far enough off topic already. -- Rob
From: David Mark on 15 Nov 2009 20:04 On Nov 15, 7:24 pm, RobG <rg...(a)iinet.net.au> wrote: [...] > > There's a big difference between instrumentalism and scientific > experimentation. Experiments and their results are a fundamental part > of developing theories, it is the people that I call tradesmen that > are instrumentalists. > Yes, one of them sees something work in a handful of browsers, writes a blog about it, another copies it for a new wonder-library and blogs about that. The current culture says that you trust these people as they must know what they are doing (they wrote these wonderful libraries!) Try to explain that their chosen tools are bunk and they refer back to the blogs as "proof".
From: The Natural Philosopher on 15 Nov 2009 22:26 David Mark wrote: > On Nov 15, 7:24 pm, RobG <rg...(a)iinet.net.au> wrote: > > [...] > >> There's a big difference between instrumentalism and scientific >> experimentation. Experiments and their results are a fundamental part >> of developing theories, it is the people that I call tradesmen that >> are instrumentalists. >> > > Yes, one of them sees something work in a handful of browsers, writes > a blog about it, another copies it for a new wonder-library and blogs > about that. The current culture says that you trust these people as > they must know what they are doing (they wrote these wonderful > libraries!) Try to explain that their chosen tools are bunk and they > refer back to the blogs as "proof". Another person without a clue what instrumentalists are. God the effort we went to to build the Internet, and they cant even look up Wiki.
From: RobG on 16 Nov 2009 01:20 On Nov 16, 1:25 pm, The Natural Philosopher <t...(a)invalid.invalid> wrote: > RobG wrote: > > On Nov 15, 11:07 pm, The Natural Philosopher <t...(a)invalid.invalid> > > wrote: > >> RobG wrote: > >>> Empirical evidence is used to develop and support a theory, however > >>> the theory itself must have a scientific basis - that is, it must have > >>> a rational explanation that will predict behaviour in similar > >>> circumstances. Simply observing that something happens is just an > >>> observation of a fact, an experiment. Being able to repeat an > >>> experiment and achieve the same outcome every time doesn't prove > >>> anything other than that the experiment is repeatable, it doesn't > >>> provide any explanation of why the experiment "works", nor predict the > >>> likely outcome if the parameters are changed, nor provide any bounds > >>> within which it "works" or "fails". > >> However most of science is, in the *final* analysis, precisely what you > >> describe. > > > No, it isn't. Science attempts to understand and explain the > > underlying system that causes outcomes. > > Nope. Not in the final analysis. Not in your "final analysis" perhaps. We aren't arguing about what is or isn't science, we're discussing whether the use of scientific methods is a suitable criterion for distinguishing a software engineer from a hack. > Its just a set of consistent hypotheses that hang together and haven't > been shown to be wrong, yet. Based on the assumption that the behaviour > of the world is governed by casuality, and laws. Both of these are human > inventions. You can characterise all knowledge as "human invention" if you like. Your "final analysis" is just you refusing to accept a particular argument on the basis that it's all made up. Of course it is, as is our entire system of mathematics and physics, but that system is fundamental to our ability to develop technologies. Anything and everything can be resolved to being "just a theory", but that's a pretty useless conclusion. [...] > Ultimately an engineer is a caveman who, with no science at all, ties a > stone on the end of a stick, and bashes idiots who are still looking for > Explanations as to *why* it works, over the head, and eases their > troubled minds that way. That caveman is not an engineer by my definition. The original question is "What is a software engineer". My position was that the difference between an engineer and a tradesman is that the engineer uses scientific methods to develop solutions. Doing something simply because it works without any understanding is not a scientific approach. It might be successful (i.e. it might "work"), but it's not scientific. > He doesn't know *why* it works, he merely notes > that it *does*, and that the bigger the stone and the longer the stick, > the more dead the Dawks are when he's finished hitting them. No more is > needful for the purpose of commiting useful assault and battery. Which is a suitable analogy for developers who have no understanding of why the code they write works, and therefore no understanding of when it will fail. Your caveman will be bewildered by the mob who work out how clubs work and develop suitable defences or superior weaponry. [...] > You should note that this is why computer *scientists* are such an > infernal waste of space. They want to know how it all works. Software > engineers don't need to know how it works. Such broad generalisations are a poor substitute for reasoned argument. It's absurd to argue that computer scientists are a waste of space as without them there'd be no computers or software engineers, or this discussion. Or were computers invented by a bunch of people connecting a stack of valves together and messing around with them until the light (literally) came on? Was the first logic circuit simply chance, or did someone actually design it from first principles? And if someone finally develops a feasible quantum computer, will that be put down to "trial and error" or scientific endeavour? Yeah, computer scientists are completely over rated. Your entire argument has been about splitting hairs using simplistic analogies. Of course science doesn't have answers for everything and depends on the results of experiments to prove (as in provide supporting evidence for, not to define irrefutably) its theories. Nor does a scientific approach necessarily result in a better or faster "solution" than trial and error - the success of concepts like lateral thinking are proof of that. But a scientific approach is more likely to provide a better solution in the majority of cases, and it provides information that can be used to further knowledge at a much greater rate than purely empirical methods. That is why it is regarded as the best methodology for developing things. > Just how to *make* it work. So in your version of reality engineers must work purely by trial and error - you can't win a debate by simply defining your protagonist out of the argument. -- Rob
From: Garrett Smith on 16 Nov 2009 03:10
David Mark wrote: > On Nov 15, 2:41 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: >> David Mark wrote: >>> On Nov 15, 1:35 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: >>>> Richard Cornford wrote: >>>>> David Mark wrote: >>>>>> On Nov 14, 11:55 pm, Richard Cornford wrote: >>>>>>> Richard Cornford wrote: >>>>>>>> ... After all, you can show them the environments where >>>>>>>> objects result in 'undefined'... >>>>>>> That 'undefined' should have been 'unknown', but you probably >>>>>>> figured that out already. >>>>>> Actually, I thought you meant document.all in FF quirks mode. ;) >>>>> Fair enough, that will do as your third example of a host object - >>>>> typeof - oddity that can be stated. (Which reminds me, there is (or was, >>>>> as it has been criticised) something in Safari that claims to be >>>>> 'undefined' even though it can be shown to exist (be an object or >>>>> function). I don't recall the detail, but I think Garrett may be in a >>>>> position to say what it is (without looking it up in the ES 4/3.1 >>>>> mailing list archives.)) >>>> Was an SVG "filter" style property, as a string value:- >>>> typeof el.style.filter >>>> "undefined". >>>> javascript:var s=document.body.style;alert([typeof s.filter,"filter"in s]); >>>> elerts "undefined, true" >> And: >> >> javascript:var s=document.body.style;prompt('',[typeof s.filter, s]); >> >> results: >> >> undefined,[object CSSStyleDeclaration] >> >>> Right. The collection item method is IE and "string". So to sum up, >>> typeof for native objects is specified and all known implementations >>> follow the specification in this regard (and would be broken as >>> designed otherwise). >> Ah, not completely. >> >> We recently discussed callable regexp. >> >> In Spidermonkey typeof /a/ results "object" (where it should, by >> following the typeof table, result "function". This is because RegExp is >> callable in Spidermonkey, using Function Call syntax as: >> >> /a/("a");// results ["a"] >> >> javascript: alert( /a/("a") ) >> >> elerts "a" > > Fair enough, but it is still within the specified range for native > types. There are about 5 different implementations where RegExp may or may not implement [[Call]] (or a bastardized version thereof) and where result when used with typeof operator varies. ECMA-262 table for the typeof operator states: +----------------------------------------------+-----------+ | Type | Result | +----------------------------------------------+-----------+ | Object (native and implements [[Call]]) |"function" | +----------------------------------------------+-----------+ So, where RegExp implements [[Call]], the result of typeof should be function. Actual implementations: +---------------------------------------+-----------------+ | RegExp Behavior | typeof Result | +---------------------------------------+-----------------+ | 1) implements [[Call]] | "object" | | 2) implements [[Call]] | "function" | | 3) callable for Function Call only | "object" | | 4) callable for Function Call only | "function" | | 5) does not implement [[Call]] | "object" | +---------------------------------------+-----------------+ Behavior seen in implementations: (1) Opera (2) Safari (3) Firefox 3+ (4) Older Spidermonkey (Firefox 2, Seamonkey) (5) IE Quick example: javascript:var a=/a/;alert(typeof a);alert(a('a'));alert(isNaN.call.call(a,a,'a')); The first alert checks the result of typeof The second alert shows if the RegExp can be used in a Function Call. The third alert test [[Call]] indirectly, via Function.prototype.call. Firefox 3: "object", "a", (TypeError) Seamonkey: "function", "a", (TypeError) Webkit: "function", "a", "a" Opera: "object", "a", "a" IE: "object", (Error -> Completion) This doesn't mean typeof is unusable, but care should be taken when using it, even with a native object. Implementations other than IE implement non ECMA-defined objects as native ECMAScript objects. These implementations have copied IE behavior with respect to particular object type result with typeof operator, where IE's result is unintuitive (e.g. typeof alert == "object"). It is also worth noting that document.all is a callable object in some implementations where typeof document.all result may be "object" or "undefined". javascript:var d=document;alert([typeof d.all, d.all.constructor,d.all("q")]); The results depend on the browser, its version, and compatibility mode of the document. It doesn't matter if document.all is not used There really isn't any good reason to use it, so its a non-issue. IE <= 8 implement "Host" objects so that when used with the typeof operator, the result is "object", "unknown", or "string"). While this does not violate ECMA-262, it provides results that are incongruent and unintuitive. Check in your intuition at the door. Part of the problem with the typeof table, and with the ECMA-262 r3 specification overall, is the great leeway given to Host objects. There is no encouragement that the implementation of a Host object SHOULD implement an interface which behave as Native ECMAScript object. and no incentive by providing a pertinent description of desirable behavior. Fictitions spec example, for callable Host object:- (fictitious, hypothetical table) +-----------------------------------------------------+-----------+ | Type | Result | +-----------------------------------------------------+-----------+ | Object (Host and implements [[Call]])* (see Note) |"function" | +-----------------------------------------------------+-----------+ * *Note* Host object that implements [[Call]] operator, when used with the typeof operator, SHOULD result "function". Implementations are discouraged for providing different behavior, unless for good reason. Although that is fiction, it encourages implementations to implement Host object so that it behaves as a native object. That would make the outcome of typeof more predictable. The current specification gives wide-open leeway. It provides no guidance for Host objects. It does this in full knowledge that the implementation will have objects that are not defined by the specification, as stated in the specification: | 4. Overview | | [...] | | ECMAScript is an object-oriented programming language for performing | computations and manipulating computational objects within a host | environment. There, and: | ECMAScript as defined here is not intended to be | computationally self-sufficient; indeed, there are no provisions in | this specification for input of external data or output of computed | results. Again, this is defining that ECMAScript is for a Host environment (obviously). It goes on to provide great leeway for Host object to have any behavior: | Instead, it is expected that the computational environment of | an ECMAScript program will provide not only the objects and other | facilities described in this specification but also certain | environment-specific host objects, whose description and behaviour are | beyond the scope of this specification except to indicate that they | may provide certain properties that can be accessed and certain | functions that can be called from an ECMAScript program. | 4.3.8 Host Object | A host object is any object supplied by the host environment to | complete the execution environment of ECMAScript. Any object that is | not native is a host object. A reasonable expectation would be that implementations will do anything, even introducing useless and undesirable complexities and quirks. Implementations would not have had the incentive to copy IE's odd implementation with result of typeof operator on callable "Host" object, had IE just used native jscript object from the beginning. Had Microsoft implemented Host objects as native jscript objects, you would not be reading this message. Perhaps future revisions of ECMAScript will include stronger wording for Host objects, so that implementations will have at least some conformance guidelines, though it seems too late for WebIDL, which also takes liberty to implement special behavior on Host object, defining a very large number of additional internal properties. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/ |