A
Asen Bozhilov
Richard said:
window.alert(typeof window.Image.create); //string
window.alert(typeof window.Option.create); //string
window.alert(typeof window.Image.create); //string
window.alert(typeof window.Option.create); //string
J
John G Harris
.... who is trying to convince management he deserves a higher salary.
Real engineers are people who desperately want to be promoted to
management in order to get away from this nasty technical stuff. You can
shout at a person and say that it's all their fault; if you start
shouting at transistors they'll fetch the men in white coats.
John
J
John G Harris
And at the time of this writing, a "proof" seems to be any bullshit
pattern you can observe and report with your installed browser(s).
It's like, if you saw it on the monitor, it must be true. Or more
like if _anyone_ ever reported it.
It is my contention that browsers (especially modern browsers) are not
mysterious, illogical creatures to be observed. Neither are the
people that make them.
Seen in a Usenet news group, from an Associate Professor of computing at
a US university :
"Proof enough for me until I see a counter example."
John
A
Asen Bozhilov
At the moment in Bulgaria is just like in Netherlands. Here everybody
can write html/css/JavaScript/php, but nobody wants to understood what
exactly write. In the place where i job i have three Project Managers.
These people not only disagrees web development but they has dummy
question and conclusions like:
"Do you use JQuery? Because we don't want conflicted between our code
and code produced by clients."
"There in JavaScript pointer?"
"Do you resize that picture or you scale to dimension?"
These people don't gives damn about quality of code. The don't want to
learn.. They only want to get our salary, and wants project been
ready before deadline.
That is the reason if i have opportunity, i will be start freelance
practice. I'm not software engineer, but the different between me and
these people is, i want to learn. I want to know how it works things.
And i want to have clear mind to analize code who i write.
You talk about bad design. What about this snippet code:
makeArray: function( array ) {
var ret = [];
if( array != null ){
var i = array.length;
// The window, strings (and functions) also have 'length'
if( i == null || typeof array === "string" || jQuery.isFunction
(array) || array.setInterval )
ret[0] = array;
else
while( i )
ret[--i] = array;
}
return ret;
}
That is totally wrong. Author create black list with `object' who
haves `length' property but these `object' it self's is not Array. In
future if author discover `object' who have `length' property but is
not array like object, will be come back to that code. This means
`makeArray' is hard to support, and error prone in different
environments.
Richard Cornford in one entry says:
Do you thing author of makeArray thing about that words? If i replace
in Richard Cornford sentence word 'function' with 'array', what will
be answer?
Regards.
T
The Natural Philosopher
Richard said:
well study the way it works then.
so? thats what I was saying yes...? So what. A simple 'I agree' would
have done..
Well I think you have fallen into your won trap. There may be an
ultimate underlying reality, sure. which we have a picture of, but an
explanation is already in the realm of a theory or at least an
abstraction from that reality. So no, there are no final explanations
either. The universe IS its own explanation, is about as good as it gets.
Well it is guaranteed if te laws say it will.And they are correct.
On the other hand, you could simply shoot them all and see whether the
sun rises. Thus forever refuting their thesis.
;-)
Hardly scientific.
It doesn't explain anything. No science explains anything. It simply
replaces a lot of oraginised stuff with more primitive constructs
allegedly connected by causal relationships.
Its power is is its predictability. Not in its explanations, because
there are no explanations of anything, in absolute terms.
Engineering is even less precise. Engineering is full of rules of thumb,
rather than complex formulae, simply because mostly engineers need fast
but approximate answers. Not 'how many tons will this bridge stand if
every bolt is perfect steel but 'will it stand 50 tons assuming its
built by morons (out of crap steel) drunk on a friday afternoon with
half the bolts missing'
And the acid test is taking a 50 ton truck across it, and then putting a
red sign 'max load 50 tons' on it.
No explanations involved. Not much science required really. Only if you
are pushing the limits to see how little steel you can get away with,
might you actually need to understand structural theory beyond 'a big
lump is stronger than a little lump'
I am not sure we had the concept of anti-matter prior to it.
And the above is not an explanation of anything. Its merely saying if
you do X, Y will happen, quantitatively of the following amount.
Indeed. The better the explanation, the less scientific it generally is,
and the more useless it generally is..
Engines in the sense of man made functional products of any description.
Working doesn't mean working well.
WE all seen appalling code that is sold, and works, and is ipso facto
'professional code' WEr have all met the old bugger in the corner with
his '20 years professional sofware experience in IT' who still cant
write a clean line of code.
WEll again, I think you are too strong. Ive seen people still analysing
problems that rather less academic and rather more practical people have
solved and sold solutions for.
You have to decide whether the bloke that props a girder on two blocks
of concrete and drives a 50 ton digger over it, is what you want versus
the guy in the office who spends a week doing stress calculations, to
tell him it will actually stand the weight. And who is the engineer. And
who is the professional engineer.
I've done it both ways, and MOST engineering its faster to build and
test, than predict. And its always quicker NOT to argue the toss with
armchair computer scientists, who never agree on anything, expect that
in general they know better than anyone else.
Above all, engineering is NOT science. Science aims to arrive at
reductionist theories that appear to accurately reflect reality. They
almost ALWAYS come after the area in question is already well studied
and fully familiar to practitioners like engineers. Bridges existed long
before stress calculations. Planets predate notions of gravitation.
Engineering only aims to provide cost effective solutions to real world
problems by whatever means and technology is to hand. Science is just
one of its tools. And not the main one.
If a given bit of code works against all known testable browsers who
cares if at some future date it MIGHT blow up because it relies on
implementation details? The day it does, you rewrite it, or more likely
in this imperfect world, you rewrite the browser to mimic the (arguably
broken, but who gives a shit?) browsers that predated it.
It the line in your code that says
/* this section mimics an obscure bug in IE5, that should never have
been there, but is, and makes this bit, against all the laws of nature,
and against the actual latest specs of this language., and in the
ugliest, but very simplest way possible, make this code run as expected
on the aforesaid steaming pile of wombat turds: Touch it at your peril
see www.proengineerblog.com/ie5-crap#bug47943210 */
that makes you a professional software engineer. ;-)
..
T
The Natural Philosopher
No real engineers are 'people who can do for sixpence, what any damnedJohn said:
fool can do for a quid'. According to Neville Shute, anyway.
Real engineers hate management more than anything, because once having
done it for sixpence, they think that fourpence halfpenny is merely
another week away...
D
David Mark
Yes, clipboard jockeys with no time to learn anything. And they
wonder why they are constantly rewriting the same code, year after
year. That's why there is this myth that cross-browser scripting is
"impossible" without using a (constantly rewritten) library that "just
works". Because those library guys really get it.
Because they have no idea what is being done, they cannot estimate
anything about it. So when their estimation proves incorrect, it's
the programmers' fault (and if only they would have used jQuery as it
"just works" and the author is such a JS luminary). And, of course,
if there is a precedent set by code monkeys, that's the estimate in
their mind. They just don't realize that the wasted time comes later
(and in spades). Or maybe they don't care? Seems like a good way to
lose clients to me.
I can tell you it is very rewarding and there is lots of money to be
made cleaning up after "awesome hackers" (and teaching those who
really wish to learn) and the mess-makers aren't going away.
That's the only sane approach to programming (particularly browser
scripting). Coding by observation leads to scripts that must be
rewritten every year, nonsense code like typeof xyz == 'array', etc.
That's a good thing to have.
I get the feeling this is a first effort (and never revisited).
Yes, I remember this now (from jQuery). The isFunction function is
infamous for its futility. I know I cleaned this mess up for them
years ago, so this must be an old copy.
It's complete bullshit. Erase it (and any code like it) from your
mind.
This discussion was held about two years ago and even Resig dropped in
to show off his cluelessness. It's good for a laugh. But if you
actually ever built anything with jQuery, it will make you cry in
frustration (and do they ever) and try to wish it away. Like it's my
fault they have to revisit all of their old code (should have been
paying attention two years ago).
D
David Mark
On Nov 15, 10:34 am, "Richard Cornford" <[email protected]>
wrote:
[...]
Sure, IE preserves the old bizarre behavior in quirks mode. Same way
they preserved the old attributes nonsense in compatibility mode. End
result is a CSS selector query engine that magically changes behavior
per a rather large button on the user's toolbar. Think that raises
red flags? Nah, I'm just showing off my knowledge (of the IE8 toolbar
apparently).
wrote:
[...]
Sure, IE preserves the old bizarre behavior in quirks mode. Same way
they preserved the old attributes nonsense in compatibility mode. End
result is a CSS selector query engine that magically changes behavior
per a rather large button on the user's toolbar. Think that raises
red flags? Nah, I'm just showing off my knowledge (of the IE8 toolbar
apparently).
R
RobG
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.
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.
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 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".
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.
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.
Now you've lost it.
More or less. And that algorithm is the explanation.
That isn't a scientific theory - you're back to simple observed
results.
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.
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.
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".
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.
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.
D
David Mark
[...]
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".
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".
T
The Natural Philosopher
RobG said:
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.
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.
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.
I dont think that it actually is.
So what? the models get better and more accurate. They are still models
though. The map is not the territory.
I dont think you know what instrumentalism is.
so how can it be a 'true' picture of anything?
Until such time as it doesn't rise, and we need a new theory ;-)
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.
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.
No, you have. About 3 paragraphs back.
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.
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
Observeed reults are anything but simple, unless you are a rational
materialist, in which case I wont argue with your faith.
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.
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.
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.
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.
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 rightducks.
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.
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.
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
T
The Natural Philosopher
David said:
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.
R
RobG
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.
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.
[...]
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.
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.
[...]
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.
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.
G
Garrett Smith
David said:And:David said: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"
javascript:var s=document.body.style;prompt('',[typeof s.filter, s]);
results:
undefined,[object CSSStyleDeclaration]
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.
T
The Natural Philosopher
RobG said:
entirely subjective.
Science snobbery probably.
I dont notice trees doing quantum physics. Wat else would it be?
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.
Sure, but he got there first.
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.
99% the first, 1% the latter.
I agree.
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.
That is true.
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.
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
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 shit,
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 fucking 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.
G
Garrett Smith
Richard said:
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.
J
John G Harris
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.
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.
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.
Elegance can also be very, very, very, clear. See the writings of
Bertrand Russel and John von Neumann for example.
John
G
Garrett Smith
Stefan said:
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"' );
A
Asen Bozhilov
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.
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
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.
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
D
David Mark
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"');