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>
> 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
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
> 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
> > 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
> 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
> 'Because God wills it' is the ultimately irrefutable explanation for
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.
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
From: RobG on 16 Nov 2009 01:20
On Nov 16, 1:25 pm, The Natural Philosopher <t...(a)invalid.invalid>
> 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
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
> 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
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
> 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.
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
>>>> elerts "undefined, true"
>> 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"]
>> elerts "a"
> Fair enough, but it is still within the specified range for native
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.
| 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:
(3) Firefox 3+
(4) Older Spidermonkey (Firefox 2, Seamonkey)
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.
"object", "a", (TypeError)
"function", "a", (TypeError)
"function", "a", "a"
"object", "a", "a"
"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
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
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
| 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
Again, this is defining that ECMAScript is for a Host environment
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.