What is a software engineer?

Discussion in 'Javascript' started by David Mark, Nov 14, 2009.

  1. David Mark

    David Mark Guest

    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. ;)
     
    David Mark, Nov 14, 2009
    #1
    1. Advertising

  2. David Mark

    Eric Bednarz Guest

    David Mark <> 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.
     
    Eric Bednarz, Nov 14, 2009
    #2
    1. Advertising

  3. David Mark

    David Mark Guest

    On Nov 14, 4:33 pm, Eric Bednarz <> wrote:
    > David Mark <> 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. :)
     
    David Mark, Nov 14, 2009
    #3
  4. 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
     
    Thomas 'PointedEars' Lahn, Nov 14, 2009
    #4
  5. David Mark

    David Mark Guest

    On Nov 14, 5:12 pm, Thomas 'PointedEars' Lahn <>
    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).

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


    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, Nov 14, 2009
    #5
  6. David Mark

    David Mark Guest

    On Nov 14, 5:12 pm, Thomas 'PointedEars' Lahn <>
    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.
     
    David Mark, Nov 14, 2009
    #6
  7. 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/
     
    Garrett Smith, Nov 14, 2009
    #7
  8. David Mark

    David Mark Guest

    On Nov 14, 6:19 pm, Garrett Smith <> 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.
     
    David Mark, Nov 14, 2009
    #8
  9. David Mark

    David Mark Guest

    On Nov 14, 10:17 pm, "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
    > 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).
     
    David Mark, Nov 15, 2009
    #9
  10. David Mark

    David Mark Guest

    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. ;)
     
    David Mark, Nov 15, 2009
    #10
  11. David Mark

    David Mark Guest

    On Nov 15, 12:20 am, "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.))
    >


    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, Nov 15, 2009
    #11
  12. David Mark

    David Mark Guest

    On Nov 14, 11:36 pm, "Richard Cornford" <>
    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.
     
    David Mark, Nov 15, 2009
    #12
  13. 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"
    --
    Garrett
    comp.lang.javascript FAQ: http://jibbering.com/faq/
     
    Garrett Smith, Nov 15, 2009
    #13
  14. David Mark

    David Mark Guest

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

    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.
     
    David Mark, Nov 15, 2009
    #14
  15. 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:-
    >>
    >> 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"
    --
    Garrett
    comp.lang.javascript FAQ: http://jibbering.com/faq/
     
    Garrett Smith, Nov 15, 2009
    #15
  16. David Mark

    David Mark Guest

    On Nov 15, 2:41 am, Garrett Smith <> wrote:
    > 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:-

    >
    > >> typeof el.style.filter

    >
    > >> "undefined".

    >
    > >> javascript:var s=document.body.style;alert([typeof s.filter,"filter"in s]);

    >
    > >> elerts "undefined, true"

    >
    > And:
    >
    > javascript:var s=document.body.style;prompt('',[typeof s.filter, s]);
    >
    > results:
    >
    > undefined,[object CSSStyleDeclaration]
    >
    > > Right.  The collection item method is IE and "string".  So to sum up,
    > > typeof for native objects is specified and all known implementations
    > > follow the specification in this regard (and would be broken as
    > > designed otherwise).  

    >
    > Ah, not completely.
    >
    > We recently discussed callable regexp.
    >
    > In Spidermonkey typeof /a/ results "object" (where it should, by
    > following the typeof table, result "function". This is because RegExp is
    > callable in Spidermonkey, using Function Call syntax as:
    >
    > /a/("a");// results ["a"]
    >
    >    javascript: alert(  /a/("a") )
    >
    > elerts "a"


    Fair enough, but it is still within the specified range for native
    types.
     
    David Mark, Nov 15, 2009
    #16
  17. 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.)
     
    Thomas 'PointedEars' Lahn, Nov 15, 2009
    #17
  18. David Mark

    RobG Guest

    On Nov 15, 6:38 am, David Mark <> 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
     
    RobG, Nov 15, 2009
    #18
  19. 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
     
    Asen Bozhilov, Nov 15, 2009
    #19
  20. 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.
     
    The Natural Philosopher, Nov 15, 2009
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.

Share This Page