«

RobG wrote:
> On Nov 15, 11:07 pm, The Natural Philosopher <t...@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.

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.



> 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.
>

Never said it did. Howver the only thing science is successful at, and
its only use is in predicting the future, even if its where the sun
will rise tomorrow.

That the experimental results are in accord with its predictions, is its
sole claim to any validity whatoever.

As to whether this is indicative of some correlation between its
theoretical concepts and reality at some level, opinions are divided,
from those who claim it gives 'strong evidence' that reality is in fact
like science says it is, to those (myself among them) who claim it says
nothing at all about the real nature of reality, Its only a means of
foretelling how that will behave.


>
>> 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.

No, simply showing that there is not a green unicorn at the bottom of my
garden right now, is sufficient to refute the proposition that there is.
No competing theory is required.




>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.
>

I dont think that it actually is.

> 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.
>

So what? the models get better and more accurate. They are still models
though. The map is not the territory.

>
>> 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.
>

I dont think you know what instrumentalism is.

>
>>> 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".
>
so how can it be a 'true' picture of anything?


>
>> 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.
>

Until such time as it doesn't rise, and we need a new theory

>> 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.

All laws of physics are by definition held to be immutable. WE may have
to change our descriptions, but we don't really deal with a law that
works today and doesn't work in the same way tomorrow.


> 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.
>

I think you had better study the history and philosophy of science a bit
more. Otherwise you are in danger of confusing science with something else.



>
>> 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.
>

No, you have. About 3 paragraphs back.

>> 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.
>

Algorithms don't explain anything. Algorithms calculate results. You can
sum an infinite series and get a sine wave, but it doesn't explain it.
Merely shows how to define where its going to be.

Science merely avoids the question of a final explanation by pushing its
causal models further and further back till it gets to something like a
big bang, at which point all bets are off, because nothing can cause a
big bang. In fasct, nothing *did* cause a big bang.

WE merely can say that if we extrapolate the timelines of all the
stuff we can observe, backwards, they meet at aq given place and time.



>> 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

I didnt say it was., I was merely pointing out the fact that the reality
of or perceptions is ALSO a mdoel of reality, not reality itself.

Our perceptions are already algorithmically compressed before we
cogitate upon them, and create yet more compression using the axes of
space, time and causality that we have used to form them in the first
place.


- you're back to simple observed
> results.
>

Observeed reults are anything but simple, unless you are a rational
materialist, in which case I wont argue with your faith.

>
>> 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",

NO., I said it wasn't an *explanation.*, It is however, a theory (or teh
emathematical repersentation of one). Jolly neat one in fact. Ties up a
lot of loose ends.

> 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.
>
Did you actually think I didn't know that?

I am trying to draw a fine, but very important line between theories,
and explanations.

The pope does explanations. Science does theories. But you don't seem to
know what a theory actually is.

I've pionted you at things like Popper, Kuhn, and Instrumentalism, which
is about where the debate is right now, and its not just academic willy
waving. Its actually very important, especially if you are doing primary
research. Or getting into arguments with creationsists. Science is not a
religion, And yet it too is ultimately based not perhaps on Faith, but
certainly on some a priori assumptions, which are essentially
metaphysical. Namely that the world is really there, and its more or
less as we observe it to be (or at least that's a fair but limited
aspect of it), and for the purposes of doing science, its actually held
to be a casual matrix of events that cause other events, governed by
immutable laws that do not change from place to place or day to day.
That's what science assumes for the purposes of its practice.

None of those are demonstrably true statements. And if you discount a
spiritual dimension, free will is a myth as so defined by those
assumptions, as well. WE are simply puppets playing out the causes.

But I am not here to argue for or against that: I merely note the
difficulty of free agents describing an unfree world, of which they hold
themselves to be a complete part. It is an intrinsic paradox, which
shows that the description is delightfully incomplete, and can never
represent reality accurately by that fact.

Quantum physicist need to understands all that or they will end up with
their knickers in a twist. Almost anyone who probes the depths of
knowledge looking for a solid foundation, comes up against this basic
recursion problem. Godel, Heisenberg..everywhere you look the ultimate
fact is there are no ultimate facts. Which leasd to another
philosophical movement called Relativism.

>
>> 'Because God wills it' is the ultimately irrefutable explanation for
>> everything.
>
> Rubbish. It is refuted quite simply - where is the proof of this god?

No proof of his existence is required . I merely posited it as in
irrefutable statement. I am playing devils advocate here of course. I
have no Faith.

No proof is required of the validity of any scientific theory. Again I
direct you to Karl Popper. No scientific theory ever has ore ever will
be, proven. Science don't work like that. At best it posits useful
theories that can potentially be disporioven BUT NEVER HAVE BEEN, YET.

> If rational explanation exists, then clearly there is no need for a
> god and hence no evidence for its existence.
>

But no rational explanation does exist for anything, which is why people
who like certainty, invent God to paper over the cracks. As if giving
the huge unknowns as to WTF is going on, and why, a name, actually
helped any.

>> That doesn't make it a scientific theory in any sense.
>
> More straw men - no one said it was, it's faith.

Oh, a LOT of creationists would argue that it is precisily on a par with
science, believe me Thst why you need your ducks in a row. The right
ducks.

> 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".
>

I have. Philosophically its embarrassing. He's really crap. There are
some devastating arguments, but not his. In fact he damages the cause of
science massively, because there is no scientific proof of anything
else, either. That is not what makes science superior. What makes it
superior, is that it predicts the future. Faith does not.



>
>> 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.
>

And I am pointing out taht engineering is not about how things work, its
about making things work. The how of it is just a step along the way,
and not even necessary to achieve a functional mechanism.

After all, yoiu almost certainly don't know how a semiconductor *works*
even if you know how it *behaves*. But you don't even need to know
that to write code.


I probably know a bit more than you do, but I wouldn't claim to know HOW
it finally works. Its a quantum effect device really. But that doesn't
explain it. It just passes the msytery down to the quantum boys.

>> 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.
>

No it has not gone off topic.

The question is what is a software engineer? well he's a sort of
engineer., and so the question is what is an engineer?, and my answer is
that he is someone who constructs effective machines in the broadest
sense, you or someone cried out that he was a scientist applying
science, and I attempted to refute that, and that's how we got here. In
order to understand whether or not an engineer is applying science, and
that's *all* he does, we have to understand what science is. Here we
find that you don't actually have the answer as defined by what are the
accepted norms, from those who make the business of precise definitions
their life's work, and you are not aware of the debates surrounding the
finer parts of that definition. I have tried to make you aware of them,
that's all.

Dont read Dawkin, Read Popper, if you want the real difference between
science and religion. Dawkin is, pardon me, a bit of a Dawk.

A quick browse through a potted precis of Kant wouldn't be amiss either:

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. 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.

Simples!!


Of course it wont get a rocket to the moon, but it's a start, and it
does mean if he is feeling generous, he can kill enough woolly mammoths
to feed the woolly minds that will one day dream up a Theory that may be
tested at Cape Canaveral.

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. Just how to *make* it work.
They may well also pick up some knowledge of how it works, but its only
an adjunct to the main purpose of their craft. Not its purpose.



ob

David Mark wrote:
> On Nov 15, 7:24 pm, RobG <rg...@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.

On Nov 16, 1:25 pm, The Natural Philosopher <t...@invalid.invalid>
wrote:
> RobG wrote:
> > On Nov 15, 11:07 pm, The Natural Philosopher <t...@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

David Mark wrote:
> On Nov 15, 2:41 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>> David Mark wrote:
>>> On Nov 15, 1:35 am, Garrett Smith <dhtmlkitc...@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/

RobG wrote:
> On Nov 16, 1:25 pm, The Natural Philosopher <t...@invalid.invalid>
> wrote:
>> RobG wrote:
>>> On Nov 15, 11:07 pm, The Natural Philosopher <t...@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.
>

entirely subjective.
Science snobbery probably.


>
>> 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.

I dont notice trees doing quantum physics. Wat else would it be?

> 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.
>

Actually, its not.
Beacause it leads to a general theory of Knowledge, and enables you to
e.g. pit creationism against science on the CORRECT terms., and see them
for what they are.


> [...]
>
>> 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.
>

Sure, but he got there first.



>
> [...]
>> 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?

Actually the first logic circuits were invented by mathematicians, not
computer scientists, and the first electronic computer was built by a
post office engineer, because the mathematicians hadn't got a clue how
to make 20,000 valves run for more than a minute without one failing.

>And if someone finally develops a feasible quantum
> computer, will that be put down to "trial and error" or scientific
> endeavour?
>

99% the first, 1% the latter.

> Yeah, computer scientists are completely over rated.
>

I agree.


> 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,

Only if you apply the science correctly, can do the massive
calculations, needed, and do actually ask the right questions.

In just about every place I've ever worked the actual science underlying
the engineering has been really really small as a part of the overall
project.

At best it shows what the theoretical limits are. At worst it is simply
too long winded to get the answers needed in the timescales available,
and too simplistic to cover all the bases.99% of engineering is trial
and error testing and calculation by rule of thumb, or tables.

One pof my professors was a world expert in pre-stressed concrete beams,
He had been for 20 years. I asked him how he could spend 20 years
understanding concrete beams. "Its very complicated", he said, "many
factors to be taken into account, and an awful lot of statistics".

"So how do we manage to use it when we don't fully understand it"

"Oh, we test its to make sure it works" he said. "And there are tables
of the results of all those tests available. Then we add a safety
margin, and that's what we build to"

Not quite the learned science I was expecting with hard clear answers.



> and it provides information that can be used
> to further knowledge at a much greater rate than purely empirical
> methods.
That is true.

>That is why it is regarded as the best methodology for
> developing things.
>

That is not.

You obviously haven't been involved in developing things. Development is
an iterative process of build-test-redesign until its 'good enough'.

The concepts of e.g. the gas turbine were written up in a paper in 1925,
it was about 1942 before materials technology was good enough to make one.

Babbages Difference engine, a computer made out of brass cogs, was
posited by an ENGINEER in 1786. Babbage proposed to make it in 1822

and finally gave up around 1860

It wasn't till around 1940 that the advent of valves made a functional
digital computer a possibility, and it took a dedicated engineer to make
it work. Yes, it was some advanced mathematics that hinted at the idea
of a general purpose programmable computer, but having hinted, that's
roughly where the clever bit stopped.

And its no coincidence that it was the mathematics of iteratatively
calculated series, that led to the idea of an iterative calculation
machine stepping through a set of instructions, an using the results of
one iteration to work out what the net one should be. In short iteration
is at the heart of how computers work, and the basic development process
of any machine.

And of course, it also had its usual paradox inherent in it, in that
Turing showed that you couldn't actually work out whether a given
algorithm would ever finish without actually trying it (gross
simplification). See Turings incomputability theorems.


The principles of digital computing go back to the Abacus.

In fact the principles of most things go way way back. Computer science
per se has its place in the theoretical design of new chips and
architectures, and a little place in the laying down of basic
algorithms, but after that its all grunt work. Build and test, debug,
build and test and debug.



>> Just how to *make* it work.
>
> So in your version of reality engineers must work purely by trial and
> error

No, in my EXPERIENCE of reality, as a practicing engineer across many
fields, most engineers work most of the time purely by trial and error.

Only occasionally do they need to apply science as you understand it.As
a last resort. Or to establish the basic possibility of a new mechanism.

A very little science igos a very long way, in engineering. If you buy a
textbook on software engineering, it isnt full of Knuthian algorithms,
its full of techniques for getting the 100 monkeys that grind out code,
to behave more or less slightly less randomly, how to manage them, how
to test the results, and how to ensure bug free code. In fact on the
latter, which is very important in mission critical applications, a lot
of work was done. Sadly the computer scientists actually concluded that
beyond a certain level of complexity, it couldn't be done, which is why
aircraft fly with redundant systems written in different languages on
different hardware.

And of course all betrs are off if, for example, you are designing for a
weapons system exposed to high EMP. And your precious totally 100%
predictable logic circuit does something completely random. The solutin
in the particular units I worked on, was to insert JMP RESTART opcodes
randomly between areas of real code, in the hope that even if the
program counter and all the registers did end up in random states, at
least there was a better than even chance it would end up in one of
those places, and restart itself, and the missile would make it through
after a massive glitch.


Many a compsci have I seen grappling with code when it was obvious to an
engineer, that there was a hardware fault






- you can't win a debate by simply defining your protagonist out
> of the argument.
>
I am merely trying to point out, that the scientific disciplines are not
about developing usable artefacts: at best they lay the groundwork for
them, and all technological development is tedious trial and error
testing to attempt to fulfil the theoretical promise of what the science
or mathematics actually shows.

The arguments here are essentially spurious, as the the concept of
'correct' code in absolute terms: There is only stuff that works, and
stuff that doesn't. All the 'correctness' doesn't guarantee jack ****,
and has been proven to be that way. Its pure intellectual snobbery by
people who think they know what science is, but don't.

Thomas pointed ears had the only real valid point. If you see a bit of
code you don't understand, you RTFM till you do. If it turns out that it
works DESPITE what the manual says, you are on very thin ice.

But a proper professional engineer wouldn't even do that. He wouldn't
write it in the first place. I've been there, and told my coders 'I dont
care how ****ing elegant it is, and how smug you feel having written it,
no one but you understands it, no one has the time to read the obscure
page in the manual where it says it will work, potentially not even the
next browser writers to come along, and frankly you are not the most
essential person here, and I won't have you writing code that makes you
so: There are no prizes for elegance. The prizes go to the humble people
who turn out plain standard workmanlike code that everyone else can
understand and fix, and if that's too dull for you, the door is over
there ->, and if you like intellectual puzzles, do the crossword in your
lunch break'

THAT is software engineering. The management of people whose egos exceed
their overall understanding and usefulness. They generally have compsci
degrees.













>
> --
> Rob

Richard Cornford wrote:
> Garrett Smith wrote:
> <snip>
>> IIRC jquery uses window["eval"] in the source code. looking...
>>
>> hat rack:
>> | // Get the JavaScript object, if JSON is used.
>> | if ( type == "json" )
>> | data = window["eval"]("(" + data + ")");
>>
>> Not sure why they chose that approach over:
>> data = eval("(" + data + ")");
>>
>> That approach uses indirect eval. The calling context's scope is
>> used, so is just as unsafe in that regard. Only difference is older
>> implementations' thisArg is different.
>>
>> It indirect eval, for reasons I'm failing to comprehend.
>>
>> I believe I mentioned this very issue about a year or so ago on
>> the jquery newsgroup.
>
> I have a recollection of discussions around the use of - eval - relating
> the 'compressors' (YUI compressor, as I recall) that modify (shorten)
> Identifier names. Much like the way such a compressor cannot act on code
> within a - with - statement because there is no means of determining
> whether an unqualified Identifier in that context is a name of a
> property of the object added to the scope chain or a reference to a
> variable/function/parameter from a containing scope, such compressors
> cannot act on unqualified Identifiers in the lexically containing scopes
> when - eval - is used, because it has no way of determining whether any
> string that is - eval-ed will attempt to use them to refer to items from
> those containing scopes.
>
> My impression was JQuery's authors were then going to do whatever was
> necessary to fool the compressor in question into not noticing the -
> eval - use (and making it unrecognisably indirect should achieve that).
> Obviously the sane alternative, of using - new Function - to create a
> minimal scope chain function that wrapped the (now not indirect) eval
> call, did not occur to them.
>

I see.

That could be avoided by either Function constructor or a separate,
globally-accssible method:

jQuery.evalString = function(s) {
return eval(s);
};

That function would not be compressed, but it would be so short that it
wouldn't matter.

The eval call, as used there, has potential to modify variables in the
calling context's scope chain. Using new Function or a call to eval
in global context and scope avoids that. ES5 would "fix" that:

| 10.4.2: In Edition 5, indirect calls to the eval function use the
| global environment as both the variable environment and lexical
| environment for the eval code. In Edition 3, the variable and lexical
| environments of the caller of an indirect eval was used as the
| environments for the eval code.

That would be a significant change, but one that would be of use to
jQuery here.

Indirect eval does not throw EvalError in ES5.

| 15.1.2.1. Implementations are no longer permitted to restrict the use
| of eval in ways that are not a direct call. In addition, any
| invocation of eval that is not a direct call uses the global
| environment as its variable environment rather than the caller‘s
| variable environment.

The jQuery code escapes any problem with indirect eval throwing
EvalError.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/

On Mon, 16 Nov 2009 at 11:52:33, in comp.lang.javascript, The Natural
Philosopher wrote:

<snip>
>Babbages Difference engine, a computer made out of brass cogs, was
>posited by an ENGINEER in 1786. Babbage proposed to make it in 1822
>
>and finally gave up around 1860

Actually he thought of a better idea, and then the money ran out, mainly
because of his talent for annoying everyone he had any dealings with.


<snip>
>It wasn't till around 1940 that the advent of valves made a functional
>digital computer a possibility, and it took a dedicated engineer to
>make it work. Yes, it was some advanced mathematics that hinted at the
>idea of a general purpose programmable computer, but having hinted,
>that's roughly where the clever bit stopped.

Yes, Babbage was a mathematician, and because of what he published in
the early 1800s the main principles of the programmable computer
couldn't be patented in the 1940s.

Babbage also invented new ways of designing and making mechanical
contrivances.


<snip>
>And of course, it also had its usual paradox inherent in it, in that
>Turing showed that you couldn't actually work out whether a given
>algorithm would ever finish without actually trying it (gross
>simplification). See Turings incomputability theorems.

Turing proved that you can't have a single algorithm that will say for
every program and their legal inputs whether it will terminate. That
doesn't mean you can't prove it for an individual program. Often you
can, but you may need a different way to prove it for different
programs.

Most "Hello World" programs provably terminate.


<snip>
>There are no prizes for elegance. The prizes go to the humble people
>who turn out plain standard workmanlike code that everyone else can
>understand and fix, and if that's too dull for you, the door is over
>there ->, and if you like intellectual puzzles, do the crossword in
>your lunch break'

Elegance can also be very, very, very, clear. See the writings of
Bertrand Russel and John von Neumann for example.

John
--
John Harris

Stefan Weiss wrote:
> On 16/11/09 20:23, Garrett Smith wrote:
>> Richard Cornford wrote:
[...]

>> jQuery.evalString = function(s) {
>> return eval(s);
>> };
>>
>> That function would not be compressed, but it would be so short that it
>> wouldn't matter.
>>
>> The eval call, as used there, has potential to modify variables in the
>> calling context's scope chain. Using new Function or a call to eval
>> in global context and scope avoids that.
>
> Your evalString example cannot be used to create new global variables:
>

No, obviously not; "How do I make a global variable from eval" was not a
proposed problem nor was there any such solution discussed.

If creating properties of the global object through a string is desired,
then it can be done in the string, as:
eval( 'window.x = "s"' );
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/

Garrett Smith wrote:

>>> jQuery.evalString = function(s) {
>>> * *return eval(s);
>> };

But `this' still associated with execution context in which been
executed `eval'. With [[Construct]] and [[Call]] method of object who
refer `Function' you create `object' who internal [[scope]] refer
Global Object independent of execution context in who's been called
Function.[[Construct]] or Function.[[Call]]. After that if you call
this `object' without providing `this' value from caller, `this' in
created execution context will be referrer to Global Object. I like
much more that approach with Function construct and call method.

> If creating properties of the global object through a string is desired,
> then it can be done in the string, as:
> eval( 'window.x = "s"' );

What about this in Spider Monkey:

function evalCode(code)
{
return eval.call(null, code);
}

evalCode('var a = 10;');
window.alert('a' in this); //true
window.alert(a); //10

On Nov 16, 3:38*pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> Stefan Weiss wrote:
> > On 16/11/09 20:23, Garrett Smith wrote:
> >> Richard Cornford wrote:
>
> [...]
>
> >> jQuery.evalString = function(s) {
> >> * *return eval(s);
> >> };
>
> >> That function would not be compressed, but it would be so short that it
> >> wouldn't matter.
>
> >> The eval call, as used there, has potential to modify variables in the
> >> calling context's scope chain. Using new Function or a call to eval
> >> in global context and scope avoids that.
>
> > Your evalString example cannot be used to create new global variables:
>
> No, obviously not; "How do I make a global variable from eval" was not a
> proposed problem nor was there any such solution discussed.
>
> If creating properties of the global object through a string is desired,
> then it can be done in the string, as:
> eval( 'window.x = "s"' );

But that's not really what that does (or what it can be rationally
expected to do). If you really want to do this in lieu of standard
declarations (would require script injection instead of eval), use
something like this:-

var GLOBAL = this;
eval('GLOBAL.x = "s"');