What is a software engineer?

8 views
Skip to first unread message

David Mark

unread,
Nov 14, 2009, 3:38:06 PM11/14/09
to
What is a software engineer? I talked to a group recently and
presented this pattern:

var myEval = function(str) {
return window.eval ? window.eval(str) : eval(str);
};

I know a lot of programmers of various degrees of proficiency read
this group. Can anyone not see the problem with this in the second it
takes to read it?

Even if you don't know the language, but know that the code must be
executed in various environments (which may or may not feature an eval
method on host objects), logic dictates that this is about as bad as a
design can get (designed to give varying cross-browser results).

Would you hang your hat on this? I've been asked by these engineers
to "prove" that this is a bad idea (I say the proof is right there in
the code). They say they've never _seen_ it fail. For this one, I
don't know what that means (it's obviously designed to fail). So when
did programming becomes a process of gathering empirical evidence, as
opposed to understanding logic? Seems like browser scripting would be
the worst discipline for such a change in strategy.

How about this one:-

if (typeof xyz == 'array' || xyz instanceof Array) {
...
}

First test is _never_ true in an ECMAScript implementation. Same
engineers want "proof" of that too. (proof that something does not
exist!) Second test is known to be inconsistent due to frames. Is it
really possible to program JS and not know these things?

By the same token, what if you had wrappers for get/set/hasAttribute
that made little or no attempt to deal with the broken MSHTML
implementations (e.g. jQuery), built a CSS selector engine on top of
them and found out years later that you made a *huge* mistake. You
can see all of the support tickets that have come up over the years
because of this mistake. Would you leave all of the bugs in place for
the sake of some perverse form of backwards compatibility?

These are all lynchpin functions. It boggles my mind that people
could rely on (and waste time maintaining) code like this for
absolutely everything, with the only understanding being that it "just
works" (despite the fact that it is patched constantly, especially
when new browsers emerge).. I guess thousands of similarly challenged
engineers can't be wrong. ;)

Eric Bednarz

unread,
Nov 14, 2009, 4:33:57 PM11/14/09
to
David Mark <dmark....@gmail.com> writes:

> What is a software engineer?

In the Netherlands at the time of writing, anything from a computer
science graduate to a HTML/CSS code monkey who can copy and paste
[insert javascript[insert naming controversy here] library name
here]-code.

David Mark

unread,
Nov 14, 2009, 5:09:44 PM11/14/09
to
On Nov 14, 4:33 pm, Eric Bednarz <bedn...@fahr-zur-hoelle.org> wrote:

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

Thomas 'PointedEars' Lahn

unread,
Nov 14, 2009, 5:12:44 PM11/14/09
to
David Mark wrote:

> What is a software engineer? I talked to a group recently and
> presented this pattern:
>
> var myEval = function(str) {
> return window.eval ? window.eval(str) : eval(str);
> };
>
> I know a lot of programmers of various degrees of proficiency read
> this group. Can anyone not see the problem with this in the second it
> takes to read it?
>
> Even if you don't know the language, but know that the code must be
> executed in various environments (which may or may not feature an eval
> method on host objects), logic dictates that this is about as bad as a
> design can get (designed to give varying cross-browser results).
>
> Would you hang your hat on this? I've been asked by these engineers
> to "prove" that this is a bad idea (I say the proof is right there in
> the code). They say they've never _seen_ it fail. For this one, I
> don't know what that means (it's obviously designed to fail). So when
> did programming becomes a process of gathering empirical evidence, as
> opposed to understanding logic? Seems like browser scripting would be
> the worst discipline for such a change in strategy.

Without trying to justify their response, when analyzing this problem I
think it is important to take a step back and understand that very much
depends on one's position in the learning curve and one's level of
experience in the field. It is also a matter of the methodology chosen to
employ in order to learn (a new programming language), which is strongly
related to the two former aspects.

If you do not know the difference between native objects and host objects
(perhaps because you chose to learn by example only), and the possible
difference in behavior that this involves, you do not get the idea of using
an alternative to a type-converting test. And if you have never seen the
type-converting test to fail, but you have seen some environments to expose
an eval() method (and never a non-function `eval' property) on Window
instances and others to have no such property, but an eval() method
elsewhere instead, you can get the idea that this test was a good idea.

Of course, that eval() is primarily a method of the ECMAScript Global Object
and that therefore the wrapper is either unnecessary or error-prone, can
already be ascertained by reading the first page of the Netscape/Mozilla.org
Core JavaScript Reference¹, so the person's position in the learning curve
and level of experience must be assessed as being rather early and low.

As Richard stated more aptly before, the main problem with people learning
JS/ES is extreme, objectively unjustified overconfidence; the languages are
so dynamic in nature and the results of their application in a browser
immediately visible that they appear too easy to learn from so-called
tutorials (written by usually equally inexperienced individuals) instead of
the -- to some apparently more painful -- process of RTFM. (This goes
especially with the ignorance of the difference between ECMAScript,
JavaScript, JScript, and the many other ECMAScript implementations and their
versions, which is seldom, if ever, even mentioned in tutorials and books
intended for learners.)

Quick successes with superficial tests in a handful of browsers, inexact or
bogus (script-kiddie) terminology employed by people at approximately the
same position of the learning curve, suggest to the uninitiated that this
simple appearance would be true, that the complexity the other people are
talking about does not exist at all, and that those are just blowing up
their egos. So these people tend to become victim to the fallacy of
shifting the burden of proof, asking "show me where it fails", falsely
assuming that failure would be the exception without recognizing for an
instant (until told, but sometimes not even after that) that the approach is
destined to fail (as Specifications are written to adhere to them) and that
its working is the (fortunate?) exception instead.



> How about this one:-
>
> if (typeof xyz == 'array' || xyz instanceof Array) {
> ...
> }
>
> First test is _never_ true in an ECMAScript implementation.

That is not quite correct. The first test could result in `true' in a
conforming implementation of ECMAScript if `xyz' referred to a host object.
But I doubt the person writing it was aware of that or even intended to meet
the case.

> Same engineers want "proof" of that too. (proof that something does not
> exist!) Second test is known to be inconsistent due to frames. Is it
> really possible to program JS and not know these things?

As for the frames argument, if you never used this code cross-window or
cross-frame, you probably would never notice the difference. That is what
happened to me, and I am not too proud to admit that it took me reading
replies in this newsgroup a few months ago to see the problem, even though
my code uses the `constructor' property instead as I considered it more
compatible. And the library providing the testing function (but AFAIK not
using it for crucial functionality) existed in that form since approximately
*5 years* before that!



> By the same token, what if you had wrappers for get/set/hasAttribute
> that made little or no attempt to deal with the broken MSHTML
> implementations (e.g. jQuery), built a CSS selector engine on top of
> them and found out years later that you made a *huge* mistake. You
> can see all of the support tickets that have come up over the years
> because of this mistake. Would you leave all of the bugs in place for
> the sake of some perverse form of backwards compatibility?

Probably not; at least I would try to implement a version that eases the
transition to a better approach.

However, if you are inexperienced enough it is too easy to attribute
problems newly discovered only in one or a few runtime environments to a bug
in those environments. The misconception so built is understandable, but
not acceptable, of course.


HTH :)

PointedEars
___________
¹ However, the current Reference says "JavaScript functions not associated
with any object" which is wrong, and "In the ECMAScript specification,
these functions are referred to as methods of the global object." which
is misleading with regard to the former sentence. Because in
Netscape and Mozilla.org JavaScript, among other implementations, too,
these functions are methods of the global object, and knowing that is a
requirement for writing a sufficiently reliable feature test for those
methods.
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

David Mark

unread,
Nov 14, 2009, 5:30:33 PM11/14/09
to
On Nov 14, 5:12 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:

Yes, the (unjustified) thinking goes that calling eval as a method of
the Global object (or a host object) will set the - this - identifier
and scope accordingly. But the logic is broken in any event as - eval
- certainly won't do that. Unless the aim is for cross-browser chaos,
it's a one-liner in need of a do-over.

[...]

>
> > How about this one:-
>
> > if (typeof xyz == 'array' || xyz instanceof Array) {
> >     ...
> > }
>
> > First test is _never_ true in an ECMAScript implementation.
>
> That is not quite correct.  The first test could result in `true' in a
> conforming implementation of ECMAScript if `xyz' referred to a host object.  

Fair enough. Should point out that - for host objects - it could just
as easily be 'mickeymouse'.


> But I doubt the person writing it was aware of that or even intended to meet
> the case.

Definitely not. It's paired with instanceof Array and roughly the
same mistake I fixed (by proxy) in jQuery two years ago.

David Mark

unread,
Nov 14, 2009, 5:49:04 PM11/14/09
to
On Nov 14, 5:12 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:

[...]

>
> Of course, that eval() is primarily a method of the ECMAScript Global Object
> and that therefore the wrapper is either unnecessary or error-prone, can
> already be ascertained by reading the first page of the Netscape/Mozilla.org
> Core JavaScript Reference¹, so the person's position in the learning curve
> and level of experience must be assessed as being rather early and low.
>

True, but beside the main point I was trying to illustrate with this
(bad) example. This is just as illogical a design:-

var GLOBAL = this;

var myEval = function(str) {
return GLOBAL.eval ? GLOBAL.eval(str) : eval(str);
};

...though a tiny bit closer to competent. I made my example doubly
bad. The point is that there is no way this could be counted on to
evaluate script with global scope. In short, by design, some
percentage of browsers will not be able to - for one - declare global
variables. As written, resolving - str - will be an adventure as well.

Garrett Smith

unread,
Nov 14, 2009, 6:19:27 PM11/14/09
to
David Mark wrote:
> What is a software engineer? I talked to a group recently and
> presented this pattern:
>
> var myEval = function(str) {
> return window.eval ? window.eval(str) : eval(str);
> };
>
> I know a lot of programmers of various degrees of proficiency read
> this group. Can anyone not see the problem with this in the second it
> takes to read it?
>
> Even if you don't know the language, but know that the code must be
> executed in various environments (which may or may not feature an eval
> method on host objects), logic dictates that this is about as bad as a
> design can get (designed to give varying cross-browser results).
>

Object.prototype.eval was removed from Spidermonkey in 2007, IIRC.

I believe that in the case where Object.prototype.eval is implemented
(nonstandard), the |this| value is Base object (window here).

I never relied Object.prototype.eval, so the quirks of that are not
something I attach much value to (worth forgetting).

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.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/

David Mark

unread,
Nov 14, 2009, 6:35:57 PM11/14/09
to
On Nov 14, 6:19 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> David Mark wrote:
> > What is a software engineer?  I talked to a group recently and
> > presented this pattern:
>
> > var myEval = function(str) {
> >     return window.eval ? window.eval(str) : eval(str);
> > };
>
> > I know a lot of programmers of various degrees of proficiency read
> > this group.  Can anyone not see the problem with this in the second it
> > takes to read it?
>
> > Even if you don't know the language, but know that the code must be
> > executed in various environments (which may or may not feature an eval
> > method on host objects), logic dictates that this is about as bad as a
> > design can get (designed to give varying cross-browser results).
>
> Object.prototype.eval was removed from Spidermonkey in 2007, IIRC.
>
> I believe that in the case where Object.prototype.eval is implemented
> (nonstandard), the |this| value is Base object (window here).
>
> I never relied Object.prototype.eval, so the quirks of that are not
> something I attach much value to (worth forgetting).

Definitely.

>
> 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 + ")");

Voodoo.

Richard Cornford

unread,
Nov 14, 2009, 10:17:01 PM11/14/09
to
Thomas 'PointedEars' Lahn wrote:
> David Mark wrote:
<snip>

>> How about this one:-
>>
>> if (typeof xyz == 'array' || xyz instanceof Array) {
>> ...
>> }
>>
>> First test is _never_ true in an ECMAScript implementation.
>
> That is not quite correct. The first test could result in `true'
> in a conforming implementation of ECMAScript if `xyz' referred to
> a host object. But I doubt the person writing it was aware of
> that or even intended to meet the case.
<snip>

That "could result in 'true'" is very much a theoretical possibility; a
host object may result in any string when - typeof - is applied to it,
but it is extremely rare that they do result in anything that is not
already in the ECMAScript list, and the exception ('unknown' in IE when
testing ActiveX objects, methods and properties) is literally the only
one that I have ever encountered, or heard tell off.

Personally, I don't believe that there has ever been a browser
environment in which any object (host or otherwise) resulted in 'array'
when - typeof - was applied to it. I think that is formulation (and the
many similar - typeof - tests) is just another of those mystical
inactions that start out as someone's mistake and propagate precisely
because they are essentially harmless (the 'array' result never happens
and so the code guarded by it is either unconditionally executed or not
executed).

That is probably the measure of an 'engineer' in this context; an
engineer would want to identify and eliminate the mystical incantations
from what they were doing.

Richard.

Richard Cornford

unread,
Nov 14, 2009, 10:39:37 PM11/14/09
to
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.

Richard.

David Mark

unread,
Nov 14, 2009, 10:48:36 PM11/14/09
to
On Nov 14, 10:17 pm, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:

> Thomas 'PointedEars' Lahn wrote:
> > David Mark wrote:
> <snip>
> >> How about this one:-
>
> >> if (typeof xyz == 'array' || xyz instanceof Array) {
> >>     ...
> >> }
>
> >> First test is _never_ true in an ECMAScript implementation.
>
> > That is not quite correct.  The first test could result in `true'
> > in a conforming implementation of ECMAScript if `xyz' referred to
> > a host object. But I doubt the person writing it was aware of
> > that or even intended to meet the case.
>
> <snip>
>
> That "could result in 'true'" is very much a theoretical possibility; a
> host object may result in any string when - typeof - is applied to it,
> but it is extremely rare that they do result in anything that is not
> already in the ECMAScript list, and the exception ('unknown' in IE when
> testing ActiveX objects, methods and properties) is literally the only
> one that I have ever encountered, or heard tell off.

That's be

>
> Personally, I don't believe that there has ever been a browser
> environment in which any object (host or otherwise) resulted in 'array'
> when - typeof - was applied to it. I think that is formulation (and the
> many similar - typeof - tests) is just another of those mystical
> inactions that start out as someone's mistake and propagate precisely
> because they are essentially harmless (the 'array' result never happens
> and so the code guarded by it is either unconditionally executed or not
> executed).
>
> That is probably the measure of an 'engineer' in this context; an
> engineer would want to identify and eliminate the mystical incantations
> from what they were doing.
>

It seems some are unsure how to identify mystical decision decisions.
There is this "show me" attitude that seems to reduce programming to
observation. The programmer role is reduced to one who can observe
patterns, rather than one who can understand abstractions. And, as
mentioned, this is one bug that will never "show" its face (and is
actually just an ineffectual waste of space and a telltale sign of the
author's spot on the JS learning curve).

But this attitude becomes dangerous on more critical design
decisions. I've heard talk of a script loading mechanism that will
rely solely on the non-standard onreadystatechange and onload
properties of created SCRIPT elements. The plan is to inject SCRIPT
elements directly into the HTML element and then rely on the non-
standard events to fire and put everything in order. ISTM that
relying on observations of these two hacks working together in a
limited set of present environments is folly. Furthermore,
investigating its viability by searching for an environment that fails
is a waste of time (i.e. what does it prove if one can't be found?)
and a backwards approach to browser scripting. I think an engineer
would dismiss the fantasy scenario(s) out of hand and think about
better alternatives with at least some basis in present reality and/or
tradition in history.

Can you imagine if C++ - for example - were written like this? It
would actually be easier in some respects. Trying to script browsers
by feel seems like Mission Impossible by comparison (and perhaps
that's why so many involved with JS consider it impossible).

Richard Cornford

unread,
Nov 14, 2009, 11:36:36 PM11/14/09
to
David Mark wrote:
> On Nov 14, 10:17 pm, Richard Cornford wrote:
><snip>

>> That is probably the measure of an 'engineer' in this context;
>> an engineer would want to identify and eliminate the mystical
>> incantations from what they were doing.
>>
>
> It seems some are unsure how to identify mystical decision
> decisions. There is this "show me" attitude that seems to
> reduce programming to observation.

But in this case that can easily be turned around, and the question
"show me the browser environment in which any object results in 'array'
when a - typeof - operation is applied to it". After all, you can show
them the environments where objects result in 'undefined' and methods in
'string' (IE <= 7, - item - methods of all 'collection' objects). It
seems reasonable that if you know the oddities that do exist then your
not knowing of this oddity suggest that is does not exist.

> The programmer role is reduced to one who can observe
> patterns, rather than one who can understand abstractions.

I am noticing a resurgence in object inference testing, it the mistaken
belief that it represents feature detection. Object inference is
probably one of the better examples of decisions based on observing a
pattern. The ubiquitous example being:-

if(document.images){
image = new Image();
img.src = 'some URL'
}

- where the inference is that an environment in which -
document.images - exists will be an environment in which the - Image -
constructor exists. The code works fine, and I am unaware of any
environment where - document.images - exists and the - Image -
constructor odes not, or where the - Image - constructor exists and -
document.images - does not. So the observed relationship (*probably*)
will not be empirically contradicted.

On the other hand, the feature-testing alternative where the subject of
the test is the - Image - constructor should be obviously superior to
anyone rational. The relationship between the existence of -
document.images - and existence of the - Image - constructor is
coincidental, even if it does hold universally, but the relationship
between the existence of the - Image - and the existence of the -
Image - constructor is direct and can be expected to hold universally
for logical reasons.

The question is not 'what is wrong with the object inference version if
it has never been shown to fail?', but rather 'what is wrong with the
more logical feature detection version that would suggest using the
object inference version in its place?.

> And, as mentioned, this is one bug that will never "show"
> its face (and is actually just an ineffectual waste of
> space and a telltale sign of the author's spot on the JS
> learning curve).

Yes, it is a mystical incantation.

> But this attitude becomes dangerous on more critical design
> decisions. I've heard talk of a script loading mechanism
> that will rely solely on the non-standard onreadystatechange
> and onload properties of created SCRIPT elements. The plan
> is to inject SCRIPT elements directly into the HTML element

> and then rely on the non-standard events to fire and put


> everything in order. ISTM that relying on observations of
> these two hacks working together in a limited set of present
> environments is folly.

Yes, it is precisely that sort of thing that places arbitrary
constraints on the set of supported browsers without there being any
real need to be doing so.

> Furthermore, investigating its viability by searching for an
> environment that fails is a waste of time (i.e. what does it
> prove if one can't be found?)

It proves that another browser is going to be labelled "C Grade" (so it
is the user's fault if the code does not work on their browser). ;-)

> and a backwards approach to browser scripting. I think an
> engineer would dismiss the fantasy scenario(s) out of hand
> and think about better alternatives with at least some basis
> in present reality and/or tradition in history.
>
> Can you imagine if C++ - for example - were written like this?
> It would actually be easier in some respects. Trying to script
> browsers by feel seems like Mission Impossible by comparison
> (and perhaps that's why so many involved with JS consider it
> impossible).

Whether software authoring is engineering or not has always been
disputed. It would be nice to think that things could be done on a more
(or increasingly) rational basis, but a lot of experience of 'average'
web developers tends to justify my natural cynicism.

Richard.

Richard Cornford

unread,
Nov 14, 2009, 11:55:24 PM11/14/09
to
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.

Richard.

David Mark

unread,
Nov 15, 2009, 12:08:31 AM11/15/09
to
On Nov 14, 11:55 pm, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:

Actually, I thought you meant document.all in FF quirks mode. ;)

Richard Cornford

unread,
Nov 15, 2009, 12:20:09 AM11/15/09
to
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.))

Richard.

David Mark

unread,
Nov 15, 2009, 12:23:46 AM11/15/09
to
On Nov 15, 12:20 am, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:

The - item - method of DOM collections I think. So yeah, in reported
history, there are a handful of host object typeof anomalies and all
but one - unknown - are native type names. Not one "array" in the
bunch.

David Mark

unread,
Nov 15, 2009, 12:56:45 AM11/15/09
to
On Nov 14, 11:36 pm, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:

[...]

>
> Yes, it is precisely that sort of thing that places arbitrary
> constraints on the set of supported browsers without there being any
> real need to be doing so.
>

And I think it goes without saying that such arbitrary constraints are
confining even on the desktop. But for scripts with mobile
aspirations (one of the reasons dynamic script loading is being
considered) it seems like the worst possible choice.

Garrett Smith

unread,
Nov 15, 2009, 1:35:02 AM11/15/09
to

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"

David Mark

unread,
Nov 15, 2009, 2:30:17 AM11/15/09
to

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). The allowed results do not include "array".
Host objects are allowed to return anything, but save for one case,
they return native type names (and the exception is not "array"
either). And it would be a dubious assumption that a host object
returning typeof "array" means that the object is an Array (certainly
document.all !== undefined in FF quirks mode).

It's not 100%, but proof enough for me that the code in question is at
best superfluous (for native objects) and could be harmful (for host
objects). As Richard has speculated (for some time), it is likely the
result of a misconception that has spread over the years (programming
by copying patterns can produce oddities like this). I've certainly
seen this particular example in a lot of scripts. I'll give it to
jQuery that they didn't demand "proof" for this one. Of course,
there's that pesky attribute "question". And now I see they actually
use window.eval. Whatever.

Garrett Smith

unread,
Nov 15, 2009, 2:41:04 AM11/15/09
to
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"

David Mark

unread,
Nov 15, 2009, 3:13:36 AM11/15/09
to

Fair enough, but it is still within the specified range for native
types.

Thomas 'PointedEars' Lahn

unread,
Nov 15, 2009, 6:50:42 AM11/15/09
to
Richard Cornford wrote:

> Thomas 'PointedEars' Lahn wrote:
>> David Mark wrote:
> <snip>
>>> How about this one:-
>>>
>>> if (typeof xyz == 'array' || xyz instanceof Array) {
>>> ...
>>> }
>>>
>>> First test is _never_ true in an ECMAScript implementation.
>>
>> That is not quite correct. The first test could result in `true'
>> in a conforming implementation of ECMAScript if `xyz' referred to
>> a host object. But I doubt the person writing it was aware of
>> that or even intended to meet the case.
> <snip>
>
> That "could result in 'true'" is very much a theoretical possibility;

A possibility nonetheless, which disproves the "never". Nothing more,
nothing less.

> a host object may result in any string when - typeof - is applied to it,

That was my point.

> but it is extremely rare that they do result in anything that is not
> already in the ECMAScript list, and the exception ('unknown' in IE when
> testing ActiveX objects, methods and properties) is literally the only

> one that I have ever encountered, or heard tell off. [...]

You appear to think that I said it would be a likely case; I did not.


PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)

RobG

unread,
Nov 15, 2009, 7:49:44 AM11/15/09
to
On Nov 15, 6:38 am, David Mark <dmark.cins...@gmail.com> wrote:
> What is a software engineer?

To me, an engineer is a skilled technical professional who is able to
apply scientific knowledge to solve practical problems.

[...]


> Would you hang your hat on this?  I've been asked by these engineers
> to "prove" that this is a bad idea (I say the proof is right there in
> the code).  They say they've never _seen_ it fail.

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

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.


> For this one, I
> don't know what that means (it's obviously designed to fail).  So when
> did programming becomes a process of gathering empirical evidence, as
> opposed to understanding logic?  Seems like browser scripting would be
> the worst discipline for such a change in strategy.

It is an extremely common strategy, encouraged by modern programming
environments that attempt to improve productivity by offering features
like IntelliSense, I call it programming by feel. If you dare
challenge the methodology, you'll be told they don't have time to
learn the language thoroughly, that they don't need to understand it
as long as it works.

The only explanation I have for why such programmers get away with it
is because their programs are compiled and very few ever get to see
the awfulness of the raw code. It seems that passing user acceptance
testing is the sole criterion of quality, that the source code totally
sucks is likely seen as a good way to make money on maintenance.


--
Rob

Asen Bozhilov

unread,
Nov 15, 2009, 7:59:08 AM11/15/09
to
Richard Cornford wrote:

> That "could result in 'true'" is very much a theoretical possibility; a
> host object may result in any string when - typeof - is applied to it,
> but it is extremely rare that they do result in anything that is not
> already in the ECMAScript list, and the exception ('unknown' in IE when
> testing ActiveX objects, methods and properties) is literally the only
> one that I have ever encountered, or heard tell off.

You are rioght, but that behavior of `typeof' is not the same for
whole ActiveXObject instances in IE.

window.alert(typeof document.nodeType == 'unknown'); //false - typeof
number
window.alert(document instanceof ActiveXObject); //true

var XHR = new ActiveXObject('Microsoft.XMLHTTP');
window.alert(typeof XHR.open == 'unknown'); //true
window.alert(XHR instanceof ActiveXObject); //true


The Natural Philosopher

unread,
Nov 15, 2009, 8:07:08 AM11/15/09
to
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.

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.

Cf Kuhn, Popper, Instrumentalism, et al.

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

will the sun rise tomorrow? Can't say really. 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.

Oh, and an explanation is not a theory, and certainly not a scientific
theory, nor is a scientific theory an explanation. It is if you like,
the expression of the result of a lot of experimental data in terms of
an algorithm. 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.

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.

'Because God wills it' is the ultimately irrefutable explanation for
everything. That doesn't make it a scientific theory in any sense.

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.

Professional is no guarantee of quality.

Asen Bozhilov

unread,
Nov 15, 2009, 8:32:25 AM11/15/09
to
Richard Cornford wrote:

> .... and methods in


> 'string' (IE <= 7, - item - methods of all 'collection' objects).

window.alert(typeof window.Image.create); //string
window.alert(typeof window.Option.create); //string

Richard Cornford

unread,
Nov 15, 2009, 10:34:14 AM11/15/09
to

For that to be significant you have to point out that the - create -
properties of these objects can be called, despite their appearing to be
string primitives in most regards.

It turns out that the apparent fix for the item methods on IE 8 is
dependent on the 'mode' triggered by the DOCTYPE. I.E.:-

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title></title>
</head>
<body>
<pre>
<script type="text/javascript">

var x = window.Image.create();

document.write(
'(typeof x) -> '+
(typeof x)+'\n'+
'(\'\' + c) -> '+
('' + x)
)

document.write(
'\n\n(typeof window.Image.create) -> '+
(typeof window.Image.create)+'\n'+
'(window.Image.create instanceof String) -> '+
(window.Image.create instanceof String)+'\n'+
'(Object(window.Image.create) instanceof String) -> '+
(Object(window.Image.create) instanceof String)+'\n'+
'(typeof Object(window.Image.create)) -> '+
(typeof Object(window.Image.create))+'\n'+
'(Object(window.Image.create) == window.Image.create) -> '+
(Object(window.Image.create) == window.Image.create)+'\n'+
'(Object(window.Image.create) === window.Image.create) -> '+
(Object(window.Image.create) === window.Image.create)+'\n'+
'\'[object HTMLImageElement]\' === window.Image.create) -> '+
('[object HTMLImageElement]' === window.Image.create)
)

document.write(
'\n\n(typeof document.forms.item) -> '+
(typeof document.forms.item)+'\n'+
'(document.forms.item instanceof String) -> '+
(document.forms.item instanceof String)+'\n'+
'(Object(document.forms.item) instanceof String) -> '+
(Object(document.forms.item) instanceof String)+'\n'+
'(typeof Object(document.forms.item)) -> '+
(typeof Object(document.forms.item))+'\n'+
'(Object(document.forms.item) == document.forms.item) -> '+
(Object(document.forms.item) == document.forms.item)+'\n'+
'(Object(document.forms.item) === document.forms.item) -> '+
(Object(document.forms.item) === document.forms.item)+'\n'+
'\'[object]\' === document.forms.item) -> '+
('[object]' === document.forms.item)
)

</script>
</pre>
</body>
</html>

- outputs:-

(typeof x) -> object
('' + x) -> [object HTMLImageElement]

(typeof window.Image.create) -> string
(window.Image.create instanceof String) -> false
(Object(window.Image.create) instanceof String) -> true
(typeof Object(window.Image.create)) -> object
(Object(window.Image.create) == window.Image.create) -> true
(Object(window.Image.create) === window.Image.create) -> false
'[object HTMLImageElement]' === window.Image.create) -> true

(typeof document.forms.item) -> object
(document.forms.item instanceof String) -> false
(Object(document.forms.item) instanceof String) -> false
(typeof Object(document.forms.item)) -> object
(Object(document.forms.item) == document.forms.item) -> true
(Object(document.forms.item) === document.forms.item) -> true
'[object]' === document.forms.item) -> false

- but if you remove the DOCTYPE the final section for -
document.forms.item - changes to:-

(typeof document.forms.item) -> string
(document.forms.item instanceof String) -> false
(Object(document.forms.item) instanceof String) -> true
(typeof Object(document.forms.item)) -> object
(Object(document.forms.item) == document.forms.item) -> true
(Object(document.forms.item) === document.forms.item) -> false
'[object]' === document.forms.item) -> true

That is, apparently in 'quirks' mode the - item - method reverts to its
previous nature. (There is an apparent inference test for IE 8
'standards' mode in there).

Richard.

Richard Cornford

unread,
Nov 15, 2009, 10:34:15 AM11/15/09
to
The Natural Philosopher 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.

I don't think so.

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

Being 'falsifiable in principle' means being in a position to make
predictions such that those predictions can be empirically tested in a
way that could produce result that would contradict theory that produced
the perditions.

> And which actually add some value that competing theories
> do not.
>
> Cf Kuhn, Popper, Instrumentalism, et al.
>
>> 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.

There may be final explanations, what there isn't is any way of
recognising them as final if/when they do exist.

> will the sun rise tomorrow? Can't say really. 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)

Even if the sun does obey immutable laws of physics that would be no
guarantee that it will "rise tomorrow" (even if the assumption that it
does will significantly influence out judgements about whether it is
likely to rise tomorrow).

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

Not really. If you credit the mystical explanation, you risk squandering
resources indefinitely preserving the tribe that has the power over life
and death, and facilitating their dancing activates.

> Oh, and an explanation is not a theory, and certainly not a
> scientific theory,

The assertion is the other way around; that a scientific theory will be
an explanation (of something).

> nor is a scientific theory an explanation.

Yes they are.

> It is if you like, the expression of the result of a lot of
> experimental data in terms of an algorithm.

It is entirely feasible for an explanation to be made up off the top of
someone's head on the spot, no empirical data necessary.

> 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.
>
> E=mc^2 is a shorthand algorithm for calculating mass-energy
> relationships.

E=mc^2 isn't really an explanation, it is more part of an explanation.

> That is borne out by observation.

The point of being born out by observations in that case is that the
theory predicted that the observations would be made before some of them
had been made (and before some of them could be made, due to
technological limitations). Relativity predicts gravitational lensing
(and predicts the observable distortion that results), then the
observation is made during a subsequent eclipse and the observed results
correspond to the predicted results. Not 'proof' of the theory but
certainly an opportunity for the theory to be shot down in flames if it
were wrong.

> I am not sure it explains anything at all.

It does explain why matter/anti-matter annihilation (where all mass is
transformed to energy) can be expected to release so much energy (and
indeed, how much energy for any given mass).

> 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.
>
> 'Because God wills it' is the ultimately irrefutable explanation
> for everything. That doesn't make it a scientific theory in
> any sense.

That would be because a science/metaphysics demarcation requires
refutability of the things that are science.

> A professional engineer is one who makes his living out of
> designing engines.

That becomes a very specific definition of 'engineer'. (I bet the
majority of the worlds engineers have never designed anything that would
generally be perceived as an 'engine' by the majority of the population
of the plant.)

> HOW he does it, is really no part of what he is.

Even if the definition is no more than 'making a living by designing
engines' then certain things do follow. If the engines designed don't
actually work (don't run at all, don't last for a reasonable time when
run, etc.) then no living will be being made from designing them. Thus
there is the implication of an individual that has sufficient knowledge
to design a 'working' engine that can be created.

> Professional is no guarantee of quality.

No quality/professionalism relationship was being asserted in the
statement; "They are certainly not professionals applying scientific
theories or methods. They are not engineers.".

Professional or amateur, this is an area where there are rational (so
'scientific') principles/methods to be applied and where criticising
people for failing to apply them is reasonable and valid.

Richard.

Richard Cornford

unread,
Nov 15, 2009, 11:27:09 AM11/15/09
to
David Mark wrote:

>On Nov 15, 1:35 am, Garrett Smith 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:-

Yes, that was the one I was thinking of.

>> typeof el.style.filter
>>
>> "undefined".
>>
>> javascript:var s=document.body.style;alert(
>> [typeof s.filter,"filter"in s]);
>>
>> elerts "undefined, true"
>
> 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). The
> allowed results do not include "array". Host objects are
> allowed to return anything, but save for one case, they
> return native type names (and the exception is not "array"
> either). And it would be a dubious assumption that a host
> object returning typeof "array" means that the object is
> an Array (certainly document.all !== undefined in FF
> quirks mode).

Earlier this year it was proposed that:-

<URL: http://www.google.com/codesearch >

- could be used to say something about the prevalence of this particular
mystical incantation, by entering the search term:-

typeof\s*\(?\s*[\S]+\s*\)?\s*(!|=)==?\s*("|')array("|') lang:javascript

In March this year that search was finding 2000 entries, today it was
finding 3000. There are some false positives, but their proportion has
not increased. I did find one splendid example in those results:-

if( typeof(this.ansObj[ltag.id] == "array") )

Obviously someone wasn't getting the code they wanted executed because
no objects (including Arrays) were resulting in 'array' from a -
typeof - operation, so they played around with the placement of the
parenthesise until something happed. Of course the author of that code
cannot appreciate that the string 'boolean' will never be false and so
the whole - if - statement can be replaced with the contents of its
block to achieve precisely the same outcome.


> It's not 100%, but proof enough for me that the code in question
> is at best superfluous (for native objects) and could be harmful
> (for host objects).

Yes, the odds of successfully treating any host object that id result in
'array' from a - typeof - test (if such an object did exist) as a
javascript Array are extremely low. The very fact that the - typeof -
operation is not resulting in 'object' means that the object is not an
Array, and so it quite unlikely to have, for example, all the array
methods.

> As Richard has speculated (for some time), it is likely the
> result of a misconception that has spread over the years
> (programming by copying patterns can produce oddities like
> this).

I would still like to know who started this one off. The earliest
example that was drawn to my attention was the one in JQurey, but I
would hesitate to credit its authors with making an original mistake.

Granted the JQurey example was immediately preceded with the comment;
"// Need to use typeof to fight Safari childNodes crashes", but when you
examine Safari (going back to its first version) the - typeof - result
for - childNodes - collections was never 'array', so the comment was
never about some host environment oddity.

> I've certainly seen this particular example in a lot of scripts.

I have seen a few thousand examples by now.

> I'll give it to jQuery that they didn't demand "proof" for
> this one. Of course, there's that pesky attribute "question".
> And now I see they actually use window.eval. Whatever.

;-)

Richard.

John G Harris

unread,
Nov 15, 2009, 11:55:52 AM11/15/09
to
On Sat, 14 Nov 2009 at 22:33:57, in comp.lang.javascript, Eric Bednarz
wrote:

>David Mark <dmark....@gmail.com> writes:
>
>> What is a software engineer?
>
>In the Netherlands at the time of writing, anything from a computer
>science graduate to a HTML/CSS code monkey who can copy and paste
>[insert javascript[insert naming controversy here] library name
>here]-code.

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

John G Harris

unread,
Nov 15, 2009, 12:13:07 PM11/15/09
to
On Sat, 14 Nov 2009 at 14:09:44, in comp.lang.javascript, David Mark
wrote:
>On Nov 14, 4:33�pm, Eric Bednarz <bedn...@fahr-zur-hoelle.org> wrote:

>> David Mark <dmark.cins...@gmail.com> writes:
>> > What is a software engineer?
>>
>> In the Netherlands at the time of writing, anything from a computer
>> science graduate to a HTML/CSS code monkey who can copy and paste
>> [insert javascript[insert naming controversy here] library name
>> here]-code.
>
>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
--
John Harris

Asen Bozhilov

unread,
Nov 15, 2009, 12:14:56 PM11/15/09
to
On 14 Ноем, 22:38, David Mark <dmark.cins...@gmail.com> wrote:
> What is a software engineer?  

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[i];
}

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:
> If you can give a clear definition
> of what 'being a function' is then you are probably in a position to
> either design and effective - isFunction - method

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.

The Natural Philosopher

unread,
Nov 15, 2009, 1:24:24 PM11/15/09
to
Richard Cornford wrote:
> The Natural Philosopher 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.
>
> I don't think so.

well study the way it works then.

>
>> 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.
>
> Being 'falsifiable in principle' means being in a position to make
> predictions such that those predictions can be empirically tested in a
> way that could produce result that would contradict theory that produced
> the perditions.
>

so? thats what I was saying yes...? So what. A simple 'I agree' would
have done..

> And which actually add some value that competing theories
>> do not.
>>
>> Cf Kuhn, Popper, Instrumentalism, et al.
>>
>>> 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.
>
> There may be final explanations, what there isn't is any way of
> recognising them as final if/when they do exist.

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.


>
>> will the sun rise tomorrow? Can't say really. 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)
>
> Even if the sun does obey immutable laws of physics that would be no
> guarantee that it will "rise tomorrow" (even if the assumption that it
> does will significantly influence out judgements about whether it is
> likely to rise tomorrow).
>

Well it is guaranteed if te laws say it will.And they are correct.

>> 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.
>
> Not really. If you credit the mystical explanation, you risk squandering
> resources indefinitely preserving the tribe that has the power over life
> and death, and facilitating their dancing activates.

On the other hand, you could simply shoot them all and see whether the
sun rises. Thus forever refuting their thesis.
;-)


>
>> Oh, and an explanation is not a theory, and certainly not a
>> scientific theory,
>
> The assertion is the other way around; that a scientific theory will be
> an explanation (of something).
>
>> nor is a scientific theory an explanation.
>
> Yes they are.
>
>> It is if you like, the expression of the result of a lot of
>> experimental data in terms of an algorithm.
>
> It is entirely feasible for an explanation to be made up off the top of
> someone's head on the spot, no empirical data necessary.

Hardly scientific.

>
>> 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.
>>
>> E=mc^2 is a shorthand algorithm for calculating mass-energy
>> relationships.
>
> E=mc^2 isn't really an explanation, it is more part of an explanation.
>

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'


>> That is borne out by observation.
>
> The point of being born out by observations in that case is that the
> theory predicted that the observations would be made before some of them
> had been made (and before some of them could be made, due to
> technological limitations). Relativity predicts gravitational lensing
> (and predicts the observable distortion that results), then the
> observation is made during a subsequent eclipse and the observed results
> correspond to the predicted results. Not 'proof' of the theory but
> certainly an opportunity for the theory to be shot down in flames if it
> were wrong.
>
>> I am not sure it explains anything at all.
>
> It does explain why matter/anti-matter annihilation (where all mass is
> transformed to energy) can be expected to release so much energy (and
> indeed, how much energy for any given mass).
>

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.

>> 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.
>>
>> 'Because God wills it' is the ultimately irrefutable explanation
>> for everything. That doesn't make it a scientific theory in
>> any sense.
>
> That would be because a science/metaphysics demarcation requires
> refutability of the things that are science.
>

Indeed. The better the explanation, the less scientific it generally is,
and the more useless it generally is..


>> A professional engineer is one who makes his living out of
>> designing engines.
>
> That becomes a very specific definition of 'engineer'. (I bet the
> majority of the worlds engineers have never designed anything that would
> generally be perceived as an 'engine' by the majority of the population
> of the plant.)
>

Engines in the sense of man made functional products of any description.

>> HOW he does it, is really no part of what he is.
>
> Even if the definition is no more than 'making a living by designing
> engines' then certain things do follow. If the engines designed don't
> actually work (don't run at all, don't last for a reasonable time when
> run, etc.) then no living will be being made from designing them. Thus
> there is the implication of an individual that has sufficient knowledge
> to design a 'working' engine that can be created.
>

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.

>> Professional is no guarantee of quality.
>
> No quality/professionalism relationship was being asserted in the
> statement; "They are certainly not professionals applying scientific
> theories or methods. They are not engineers.".
>
> Professional or amateur, this is an area where there are rational (so
> 'scientific') principles/methods to be applied and where criticising
> people for failing to apply them is reasonable and valid.
>

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


.


> Richard.

The Natural Philosopher

unread,
Nov 15, 2009, 1:26:53 PM11/15/09
to
No real engineers are 'people who can do for sixpence, what any damned
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...

David Mark

unread,
Nov 15, 2009, 4:07:49 PM11/15/09
to
On Nov 15, 12:14 pm, Asen Bozhilov <asen.bozhi...@gmail.com> wrote:
> On 14 îÏÅÍ, 22:38, David Mark <dmark.cins...@gmail.com> wrote:
>
> > What is a software engineer? š

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

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

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

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


> That is the reason if i have opportunity, i will be start freelance
> practice.

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

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

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.

> And i want to have clear mind to analize code who i write.

That's a good thing to have.

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

I get the feeling this is a first effort (and never revisited).

>         if( i == null || typeof array === "string" || jQuery.isFunction
> (array) || array.setInterval )
>             ret[0] = array;
>         else
>             while( i )
>                 ret[--i] = array[i];
>     }
>
>     return ret;
>
> }

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.

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

It's complete bullshit. Erase it (and any code like it) from your
mind.

>
> Richard Cornford in one entry says:
>
> > If you can give a clear definition
> > of what 'being a function' is then you are probably in a position to
> > either design and effective - isFunction - method
>
> 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?

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). :(

David Mark

unread,
Nov 15, 2009, 4:59:24 PM11/15/09
to
On Nov 15, 10:34 am, "Richard Cornford" <Rich...@litotes.demon.co.uk>
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). ;)

RobG

unread,
Nov 15, 2009, 7:24:09 PM11/15/09
to
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. It is also open to new
theories that better explain outcomes, it doesn't blindly accept that
because something "always happens" that it will continue to happen.


> a set of propositions that may (or may not!) reflect an underlying
> reality, whose predictions have failed to ever be falsified by
> experiment, and whose propositions CAN in principle be falsified.
>
> And which actually add some value that competing theories do not.

It is by disproof that new theories emerge or existing ones are
strengthened. You can't disprove a theory by contrary experimentation
alone, you have to propose a theory as to *why* the evidence is
contradictory. The contrary evidence may simply provide a boundary for
where the theory holds and where it doesn't. Quantum theory is the
antithesis of relativity, but doesn't disprove it.

Kepler's laws of planetary motion were fine until instruments were
accurate enough to discover the errors, but then the hunt was on for a
better theory. Without Einstein's theory of relativity, modern GPS
systems would be impossible. Without Hawking's theories we'd never
have found black holes, even though they were predicted by Einstein's
theories.


> Cf Kuhn, Popper, Instrumentalism, et al.

There's a big difference between instrumentalism and scientific
experimentation. Experiments and their results are a fundamental part
of developing theories, it is the people that I call tradesmen that
are instrumentalists.


> > Without the explanation, there is no theory. There is no application
> > of scientific knowledge, no understanding of why the result occurs. It
> > is no more than faith - it's always worked before in their limited
> > experience, therefore they expect it to always work. Anyone who
> > performs work using such methods should be categorised as a trades
> > person. They are certainly not professionals applying scientific
> > theories or methods. They are not engineers.
>
> :-) sadly, there are no final explanations for anything.

I think you're being deliberately disingenuous. Science is constantly
evaluating new theories and updating old ones, even tossing them out.
There is no expectation that a theory will last forever, nor that any
theory is "final".


> will the sun rise tomorrow? Can't say really.

Then you should learn the physics of solar motion. There are theories
that predict when the sun won't rise tomorrow - it's a few billion
years away, but it's been predicted for quite some time.

> It always HAS...whether
> that's because it obeys certain immutable laws of physics that we
> BELIEVE to be universal true (nay DEFINE to be universally true) or
> whether its because the Ngongobongo tribe absolutely do a special tribal
> dance every sunset to make sure it does, is a very moot point.

You don't seem to know much about science - there is no such thing as
an immutable law of physics. Newton's laws were good enough for the
time in which they were proposed, however we now know much more than
we did in the 1600s. Einstein's laws were pretty good too, but they
have their limits also - he never did find his unifying theory,
perhaps there isn't one. But that wont stop people trying to find it.


> Oh, and an explanation is not a theory, and certainly not a scientific
> theory, nor is a scientific theory an explanation.

Now you've lost it.

> It is if you like,
> the expression of the result of a lot of experimental data in terms of
> an algorithm.

More or less. And that algorithm is the explanation.

> In the same way that the reality of our perceptions is a
> compressed representation of all the salient features of all the data we
> are subjected to.

That isn't a scientific theory - you're back to simple observed
results.


> E=mc^2 is a shorthand algorithm for calculating mass-energy
> relationships. That is borne out by observation. I am not sure it
> explains anything at all. Not in any fundamental way. Its just the
> expression of a constancy of relationship between certain elements of a
> world we have defined in certain precise terms.

I think this is some kind of straw man argument. You put up a famous
equation and say "that's not a theory", well, it isn't, and I didn't
say it was. That equation is part of a theory - Einstein's theory of
special relativity, which built on work by many others incuding
Galileo.


> 'Because God wills it' is the ultimately irrefutable explanation for
> everything.

Rubbish. It is refuted quite simply - where is the proof of this god?
If rational explanation exists, then clearly there is no need for a
god and hence no evidence for its existence.

> That doesn't make it a scientific theory in any sense.

More straw men - no one said it was, it's faith. Science does not
state categorically that one or more gods can't or don't exist, it
just says that there is no proof of a god. Read a bit of Richard
Dawkins' work, specifically "The God Delusion".


> A professional engineer is one who makes his living out of designing
> engines. HOW he does it, is really no part of what he is.

That is an utterly superficial excuse for logic. It's all about how
the work is done that matters, that's the whole point of this thread.

>
> Professional is no guarantee of quality.

Of course not, and I didn't I say that. Quality is a whole new topic -
as if this hasn't gone far enough off topic already.


--
Rob

David Mark

unread,
Nov 15, 2009, 8:04:51 PM11/15/09
to
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".

The Natural Philosopher

unread,
Nov 15, 2009, 10:25:27 PM11/15/09
to
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

The Natural Philosopher

unread,
Nov 15, 2009, 10:26:58 PM11/15/09
to

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.

RobG

unread,
Nov 16, 2009, 1:20:23 AM11/16/09
to
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

Garrett Smith

unread,
Nov 16, 2009, 3:10:57 AM11/16/09
to

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.

The Natural Philosopher

unread,
Nov 16, 2009, 6:52:33 AM11/16/09
to

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

>
> --
> Rob

Garrett Smith

unread,
Nov 16, 2009, 2:23:52 PM11/16/09
to
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.

Stefan Weiss

unread,
Nov 16, 2009, 3:08:40 PM11/16/09
to
On 16/11/09 20:23, Garrett Smith wrote:
> Richard Cornford wrote:

Your evalString example cannot be used to create new global variables:

function evalStr (code) {
return eval(code);
}
evalStr("var foo = 42");
// --> foo was not declared globally

Neither can |new Function|:

function evalStr (code) {
return (new Function(code))();
}
evalStr("var foo = 42");
// --> foo was not declared globally

window.eval, on the other hand, can do it:

function evalStr (code) {
return window.eval(code);
}
evalStr("var foo = 42");
// --> global foo is now 42

execScript() can be used for the same purpose in IE. Neither of these
are well supported, of course; it may be better to just do without
global 'var' statements in the evaluated strings.


cheers,
stefan

John G Harris

unread,
Nov 16, 2009, 3:13:42 PM11/16/09
to
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

Garrett Smith

unread,
Nov 16, 2009, 3:38:21 PM11/16/09
to
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"' );

Asen Bozhilov

unread,
Nov 16, 2009, 4:36:23 PM11/16/09
to
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

Richard Cornford

unread,
Nov 16, 2009, 6:49:20 PM11/16/09
to

Recall that as it stands JQurey is wrapped in the inline execution of a
function expression, which provides a 'private' 'global' scope for just
the JQuery code. If your function was defined within that function
expression its obvious - eval - use would prevent any modification to
the Identifiers employed in the 'private' 'global' scope facilitated by
the function expression. That would be a bad thing from the point of
view of code minimisation. If your function were defined outside of the
function expression then the whole becomes less of a discreet single
unit. Opinions on the latter are likely to vary, but I can see
justification in arguing against doing that.

The advantage in the use of - new Function - to create the function is
that doing so will create a function with the minimum scope chain, and
can achieve that even from within the containing function expression. A
'smart' code compressor should be able to see that the lexically
containing scopes (except the global scope, which could never be
modified anyway because that would cost the external API (if you munge
the Identifier - JQuery - the whole library is dead)) could not be
influenced by the code within such a function.

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

It would be of use to anyone who wanted to dynamically import script
source text. It is a pity that much of the dynamic importing of script
source text that goes on at present is already largely inadvisable.

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

Well, in few years when ES5 implementations have replaced ES3
implementations. In the meanwhile what it is doing is non-standard by
ES3, and one of the factors arbitrarily restricting its supported
browser set (as it can only be believed to work where it has been
observed to work).

Richard.

David Mark

unread,
Nov 16, 2009, 8:59:23 PM11/16/09
to

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"');

RobG

unread,
Nov 16, 2009, 11:12:09 PM11/16/09