FOLDOC definition

Discussion in 'Javascript' started by denis, Jan 31, 2010.

  1. denis

    denis Guest

    denis, Jan 31, 2010
    #1
    1. Advertising

  2. denis

    Luuk Guest

    Op 31-1-2010 22:23, denis schreef:
    > Please have a look at the FOLDOC (http://foldoc.org/) definition of
    > JavaScript:
    > http://foldoc.org/javascript
    > and send any comments or corrections via the feedback button. Thanks.


    this is not true:
    JavaScript runs "100x" slower than C, as it is purely interpreted (Java
    runs "10x" slower than C code).

    Because:
    Javascript does not "run", but JavaScript code gets interpreted and
    executed. But the executed code does not know if its Javascript or Java or C

    --
    Luuk
    Luuk, Jan 31, 2010
    #2
    1. Advertising

  3. Luuk <> writes:

    > this is not true:
    > JavaScript runs "100x" slower than C, as it is purely interpreted (Java
    > runs "10x" slower than C code).


    It's even misguided to talk about the speed of a language at all.

    You can, at best, talk about the speed of an implementation of the
    language, and preferably only about the speed of a specific program in
    a particular implementation of the language.

    There are programs where Java is faster than C, probably because the
    HotSpot compiler does dynamic optimization at runtime, based on the
    actual data being processed (but then, a profile based optimizer for
    C/C++ could probably make a difference too).

    The dynamic nature of JavaScript makes it hard to make it really fast,
    because you need to check at runtime, e.g., that noone has changed
    what window.Math refers to, or what properties are on Object.prototype.

    /L
    --
    Lasse Reichstein Holst Nielsen
    'Javascript frameworks is a disruptive technology'
    Lasse Reichstein Nielsen, Jan 31, 2010
    #3
  4. Luuk wrote:

    > Javascript does not "run", but JavaScript code gets interpreted and
    > executed.


    Before it gets interpreted it gets compiled, though.

    > But the executed code does not know if its Javascript or Java or
    > C


    Wrong, because: 1. Code is not an entity; it never can know. 2. The script
    engine, if regarded an entity, "knows" what it is because consists of a
    Virtual Machine that needs to interpret the resulting bytecode. It could
    not interpret Java bytecode, for example.

    Please refrain from making further suggestions until you got the basics
    right; this includes, but is not limited to, a From header that complies
    with RFC 1036 (and therefore, RFC 2822).


    Score adjusted

    PointedEars
    --
    realism: HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness: XHTML 1.1 as application/xhtml+xml
    -- Bjoern Hoehrmann
    Thomas 'PointedEars' Lahn, Jan 31, 2010
    #4
  5. denis

    Jorge Guest

    Luuk wrote:
    >
    > this is not true:
    > JavaScript runs "100x" slower than C, as it is purely interpreted (Java
    > runs "10x" slower than C code).


    Very likely it *was* true back then: (2003-04-28).

    Any ideas as for what would be a reasonable, short C vs. JS
    benchmark ? :)
    --
    Jorge.
    Jorge, Feb 1, 2010
    #5
  6. denis

    RobG Guest

    On Feb 1, 7:23 am, denis <> wrote:
    > Please have a look at the FOLDOC (http://foldoc.org/) definition of
    > JavaScript:http://foldoc.org/javascript
    > and send any comments or corrections via the feedback button. Thanks.


    There doesn't seem to be much to recommend it at all. How can a
    definition of JavaScript be considered complete if it doesn't mention
    ECMAScript? Or the standards involved? Nor does it attempt to
    distinguish between JavaScript, the trade mark, and the generic term
    "javascript" used to describe ECMAScript implementations that interact
    with DOMs, mostly in browsers.


    | (Formerly "LiveScript") Netscape's simple,

    What are the criteria for "simple"? If the criterion is features
    provided by the base language, then ECAMScript is more complex than C,
    but C is not described as simple.


    | cross-platform,

    That might be better as "platform independent".


    | World-Wide Web scripting language, only very vaguely
    | related to Java

    It isn't related to Java at all, at least not any more than it's
    related to say C.


    | (which is a Sun trademark).

    So is JavaScript.


    | JavaScript is intimately tied to the World-Wide Web,

    More correctly, it is used most commonly for scripting in browsers on
    the World Wide Web.


    | and currently runs in only three environments

    If you are talking specifically about JavaScript(tm), perhaps.


    | - as a
    | server-side scripting language, as an embedded language
    | in server-parsed HTML, and as an embedded language run
    | in web browsers where it is the most important part of DHTML.

    They are 3 common environments, but certainly aren't the only ones -
    Adobe has ECMAScript-based languages running in database and robotics
    applications too, as well as inside Flash. All might be called
    "javascript".


    | JavaScript has a simplified C-like syntax and is tightly
    | integrated with the browser Document Object Model. It is

    Better to say "...in browsers, JavaScript is tightly integrated with
    the Document Object Model..."


    | useful for implementing enhanced forms, simple web database
    | front-ends, and navigation enhancements.

    .... amongst other things, such as user interface functions,
    animations, enhanced server communication and local storage and
    retrieval of data.


    | It is unusual in that the scope of variables extends
    | throughout the function in which they are declared
    | rather than the smallest enclosing block as in C.

    Is that the only language feature worth mentioning? Prototype
    inheritance, closures and first class objects are likely more
    interesting to programmers than variable scope.


    | JavaScript originated from Netscape and, for a time,
    | only their products supported it. Microsoft now supports
    | a work-alike which they call JScript.

    Now? For at least 15 years, and not just Microsoft. This part seems to
    come from about 1996.


    | The resulting inconsistencies make it difficult to write
    | JavaScript that behaves the same in all browsers.

    That statement does not follow from the first. There are differences
    that...


    | This
    | could be attributed to the slow progress of JavaScript
    | through the standards bodies.

    But there is no standard for JavaScript, it's just a trade mark. There
    are standards for ECMAScript and DOMs that it interacts with.
    Inconsistencies are due more to the early proprietary nature of
    JavaScript and JScript, the competitive nature of their development
    and the almost non-existence of WWW standards during early
    development. I don't think you can blame standards bodies themselves
    for the differences, they've been working to help reduce them.


    | JavaScript runs "100x" slower than C, as it is
    | purely interpreted (Java runs "10x" slower than C code).

    As noted by others, these are pure guesses that are probably wrong for
    any particular platform. It is better to simply say that as JavaScript
    is interpreted and will therefore likely run slower than native code.
    But since it interacts with objects and methods supplied by the host
    environment, its overall speed is very much dependent on that
    environment.


    | Netscape and allies say JavaScript is an "open standard"
    | in an effort to keep Microsoft from monopolising web software
    | as they have desktop software.

    Do you have a reference for that assertion?


    | Netscape and Sun have co-operated to enable Java and
    | JavaScript to exchange messages and data.

    That seems to be a very out dated comment. Is it the only recent
    development of browser scripting worth noting?

    Why doesn't the dictionary provide a very brief comment about the
    trademark "JavaScript" (similar to the ECMAScript entry) and link to
    Wikipedia[1]? Or the Mozilla description[2]?

    1. <URL: http://en.wikipedia.org/wiki/Javascript >
    2. <URL: https://developer.mozilla.org/en/About_JavaScript >


    --
    Rob
    RobG, Feb 1, 2010
    #6
  7. denis

    Luuk Guest

    Op 1-2-2010 0:07, Thomas 'PointedEars' Lahn schreef:
    > Luuk wrote:
    >
    >> Javascript does not "run", but JavaScript code gets interpreted and
    >> executed.

    >
    > Before it gets interpreted it gets compiled, though.


    before it gets compiled, it gets interpreted by the compiler?

    >
    >> But the executed code does not know if its Javascript or Java or
    >> C

    >
    > Wrong, because: 1. Code is not an entity; it never can know. 2. The script
    > engine, if regarded an entity, "knows" what it is because consists of a
    > Virtual Machine that needs to interpret the resulting bytecode. It could
    > not interpret Java bytecode, for example.
    >
    > Please refrain from making further suggestions until you got the basics
    > right; this includes, but is not limited to, a From header that complies
    > with RFC 1036 (and therefore, RFC 2822).



    wtf are you talking about? do you really expect /me to read the full RFC
    and try to find out what YOU think that i'm doing wrong?

    >
    >
    > Score adjusted
    >
    > PointedEars



    --
    Luuk
    Luuk, Feb 1, 2010
    #7
  8. denis

    rf Guest

    "Luuk" <> wrote in message
    news:4all.nl...
    > Op 1-2-2010 0:07, Thomas 'PointedEars' Lahn schreef:
    >> Luuk wrote:


    > wtf are you talking about? do you really expect /me to read the full RFC
    > and try to find out what YOU think that i'm doing wrong?


    If you have not read and understood the relevant RFCs then how can you think
    that anybody would take any of your comments seriously?
    rf, Feb 1, 2010
    #8
  9. denis

    Luuk Guest

    Op 1-2-2010 13:37, rf schreef:
    > "Luuk" <> wrote in message
    > news:4all.nl...
    >> Op 1-2-2010 0:07, Thomas 'PointedEars' Lahn schreef:
    >>> Luuk wrote:

    >
    >> wtf are you talking about? do you really expect /me to read the full RFC
    >> and try to find out what YOU think that i'm doing wrong?

    >
    > If you have not read and understood the relevant RFCs then how can you think
    > that anybody would take any of your comments seriously?
    >
    >
    >


    What relevant RFCs are there, that are about javascript?
    (because this is stil comp.lang.javascript)

    And please point out the location in that RFC that has to do with:
    "a From header that complies with RFC 1036 (and therefore, RFC 2822)."
    in relation to javascript.

    The from-header in messages i send i perfectly in order when i read this
    RFC-thing....


    --
    Luuk
    Luuk, Feb 1, 2010
    #9
  10. RobG wrote:

    > denis wrote:
    >> Please have a look at the FOLDOC (http://foldoc.org/) definition of
    >> JavaScript:http://foldoc.org/javascript
    >> and send any comments or corrections via the feedback button. Thanks.

    >
    > There doesn't seem to be much to recommend it at all. How can a
    > definition of JavaScript be considered complete if it doesn't mention
    > ECMAScript? Or the standards involved? Nor does it attempt to
    > distinguish between JavaScript, the trade mark, and the generic term
    > "javascript" used to describe ECMAScript implementations that interact
    > with DOMs, mostly in browsers.


    The term "javascript" is the invention of a wannabe here that failed to see
    the differences between the many implementations, and fell into common use
    because of other wannabes here that failed to or did not want to see them.

    > | (Formerly "LiveScript") Netscape's simple,
    >
    > What are the criteria for "simple"? If the criterion is features
    > provided by the base language, then ECAMScript is more complex than C,
    > but C is not described as simple.


    Perhaps simple as compared to Java, because that was the intention for
    creating it.

    > | cross-platform,
    >
    > That might be better as "platform independent".


    It is neither.

    > | World-Wide Web scripting language, only very vaguely
    > | related to Java
    >
    > It isn't related to Java at all, at least not any more than it's
    > related to say C.


    Incorrect. JavaScriptâ„¢ was designed to be a Java-like scripting language;
    as a result, it has much more in common with Java than with, e.g., C(++).
    This is also supported by the ES3F/ES5 Overview sections:

    | 4 Overview
    |
    | [...]
    | Some of the facilities of ECMAScript are similar to those used in other
    | programming languages; in particular Java and Self [ES5: and Scheme], as
    | described in:
    |
    | • Gosling, James, Bill Joy and Guy Steele. The Java™ Language
    | Specification. Addison Wesley Publishing Co., 1996.
    |
    | • Ungar, David, and Smith, Randall B. Self: The Power of Simplicity.
    | OOPSLA '87 Conference Proceedings, pp.
    | 227–241, Orlando, FL, October 1987.
    |
    | [ES5:
    | IEEE Standard for the Scheme Programming Language. IEEE Std 1178-1990.]
    |
    | [...]
    | 4.2 Language Overview
    |
    | [...]
    | ECMAScript syntax intentionally resembles Java syntax. ECMAScript syntax
    | is relaxed to enable it to serve as an easy-to-use scripting language.
    | For example, a variable is not required to have its type declared nor are
    | types associated with properties, and defined functions are not required
    | to have their declarations appear textually before calls to them.
    [ES5: same]

    > | (which is a Sun trademark).
    >
    > So is JavaScript.


    And that does not make you think?

    > | JavaScript is intimately tied to the World-Wide Web,
    >
    > More correctly, it is used most commonly for scripting in browsers on
    > the World Wide Web.


    If you adopt the position that this dictionary entry should not only
    describe JavaScriptâ„¢, but also JScript aso., you have to take into account
    that there is Server-Side JavaScript on NES-compatible servers, and
    Service-side JScript (.NET) in ASP (.NET).

    Therefore, the statement above is correct, and your "more correct" version
    is in fact "less correct".

    > | and currently runs in only three environments
    >
    > If you are talking specifically about JavaScript(tm), perhaps.


    You do know what a dictionary is, don't you?

    > | - as a
    > | server-side scripting language, as an embedded language
    > | in server-parsed HTML, and as an embedded language run
    > | in web browsers where it is the most important part of DHTML.
    >
    > They are 3 common environments, but certainly aren't the only ones -
    > Adobe has ECMAScript-based languages running in database and robotics
    > applications too, as well as inside Flash. All might be called
    > "javascript".


    Yes, by wannabes.

    > | JavaScript has a simplified C-like syntax and is tightly
    > | integrated with the browser Document Object Model. It is
    >
    > Better to say "...in browsers, JavaScript is tightly integrated with
    > the Document Object Model..."


    Better not to say anything of the sort, as it no longer (since JavaScript
    1.3) holds true. JavaScript and other ECMAScript implementations are merely
    possibilities for interfacing languages with regard to the DOM API, in
    particular with regard to the W3C DOM API:

    <http://www.w3.org/TR/DOM-Level-3-Core/java-binding.html>
    <http://www.w3.org/TR/DOM-Level-3-Core/ecma-script-binding.html>
    <http://msdn.microsoft.com/en-us/library/d1et7k7c%28VS.85%29.aspx>

    > [...]
    > | It is unusual in that the scope of variables extends
    > | throughout the function in which they are declared
    > | rather than the smallest enclosing block as in C.
    >
    > Is that the only language feature worth mentioning? Prototype
    > inheritance, closures and first class objects are likely more
    > interesting to programmers than variable scope.


    ACK

    > | JavaScript originated from Netscape and, for a time,
    > | only their products supported it. Microsoft now supports
    > | a work-alike which they call JScript.
    >
    > Now? For at least 15 years,


    You are exaggerating. JScript 1.0 was released with Internet Explorer 3.0
    for Windows in 1996-08 (CE).

    > and not just Microsoft.


    What other vendors are there that support JScript?

    > This part seems to come from about 1996.


    ACK

    > | The resulting inconsistencies make it difficult to write
    > | JavaScript that behaves the same in all browsers.
    >
    > That statement does not follow from the first. There are differences
    > that...


    "That ..."?

    > | This could be attributed to the slow progress of JavaScript
    > | through the standards bodies.
    >
    > But there is no standard for JavaScript, it's just a trade mark.


    The language standard for JavaScript is ECMAScript. That holds true
    whether we adopt your position that this entry should also be about
    other implementations of ECMAScript or not.

    > There are standards for ECMAScript


    Nonsense. ECMAScript *is* (the name of) the standard.

    > and DOMs that it interacts with.


    No, there are standards for DOM APIs that support implementations of
    ECMAScript to be used as interfacing languages (by language binding).

    > Inconsistencies are due more to the early proprietary nature of
    > JavaScript and JScript, the competitive nature of their development
    > and the almost non-existence of WWW standards during early
    > development. I don't think you can blame standards bodies themselves
    > for the differences, they've been working to help reduce them.


    ACK

    > | JavaScript runs "100x" slower than C, as it is
    > | purely interpreted (Java runs "10x" slower than C code).
    >
    > As noted by others, these are pure guesses that are probably wrong for
    > any particular platform. It is better to simply say that as JavaScript
    > is interpreted and will therefore likely run slower than native code.
    > But since it interacts with objects and methods supplied by the host
    > environment, its overall speed is very much dependent on that
    > environment.


    Yes, those guesses are non-encyclopedic. The statement is also wrong
    because it has been established (citing Brendan Eich and Eric Lippert)
    that J(ava)Script is _not_ "purely interpreted", and never has been.

    <http://groups.google.com/group/de.comp.lang.javascript/msg/e2cd612ba3ee4b31?hl=de&dmode=source>

    (The citations there are in English.)

    > | Netscape and Sun have co-operated to enable Java and
    > | JavaScript to exchange messages and data.
    >
    > That seems to be a very out dated comment.


    No, it still holds true.

    > Is it the only recent development of browser scripting worth noting?


    ACK, more can be added here.

    > Why doesn't the dictionary provide a very brief comment about the
    > trademark "JavaScript" (similar to the ECMAScript entry) and link to
    > Wikipedia[1]? Or the Mozilla description[2]?


    Because both are Wikis, I suppose. With regard to Wikipedia, perhaps
    because last I checked the Wikipedia article contained a number of
    inaccuracies, misconceptions, and falsehoods, too.

    I am therefore glad that your comments will probably have no impact on
    FOLDOC since they have been made in the wrong place.


    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, Feb 1, 2010
    #10
  11. Thomas 'PointedEars' Lahn wrote:

    > RobG wrote:
    >> denis wrote:
    >> | JavaScript has a simplified C-like syntax and is tightly
    >> | integrated with the browser Document Object Model. It is
    >>
    >> Better to say "...in browsers, JavaScript is tightly integrated with
    >> the Document Object Model..."

    >
    > Better not to say anything of the sort, as it no longer (since JavaScript
    > 1.3) holds true. [...]


    That's 1.4 (server-side)/1.5 (client-side), of course.


    PointedEars
    --
    realism: HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness: XHTML 1.1 as application/xhtml+xml
    -- Bjoern Hoehrmann
    Thomas 'PointedEars' Lahn, Feb 1, 2010
    #11
  12. Jorge <> writes:

    > Any ideas as for what would be a reasonable, short C vs. JS
    > benchmark ? :)


    I wouldn't want anything too short. Micro-benchmarks generally suck
    at showing anything relevant for actual use.

    You could check out the computer language shootout (although I think
    it's a little misleading to allow a Java implementation that is one
    just JNI call to native code).

    /L
    --
    Lasse Reichstein Holst Nielsen
    'Javascript frameworks is a disruptive technology'
    Lasse Reichstein Nielsen, Feb 1, 2010
    #12
  13. RobG <> writes:

    > As noted by others, these are pure guesses that are probably wrong for
    > any particular platform. It is better to simply say that as JavaScript
    > is interpreted and will therefore likely run slower than native code.


    That would be wrong too.
    A programming language isn't inherently interpreted. That's a property
    of an implementation, not the language. Different implementations can
    have different properties. There are compilers for JavaScript (e.g.,
    Rhino) just as there are interpreters.

    Another problem is that people don't always agree on what it means
    to be an interpreter. Personally, I take the extensional view: If
    it takes source as input and executes the program, then it's an
    interpreter (by definition). An interpreter may internally consist
    of a compiler and an iterpreter for the target language of the
    compiler.

    /L
    --
    Lasse Reichstein Holst Nielsen
    'Javascript frameworks is a disruptive technology'
    Lasse Reichstein Nielsen, Feb 1, 2010
    #13
  14. denis

    RobG Guest

    On Feb 1, 11:19 am, Jorge <> wrote:
    [...]
    > Any ideas as for what would be a reasonable, short C vs. JS
    > benchmark ? :)


    Is there any point?

    Such comparisons only really matter where you have a choice of doing
    something in both languages and other criteria for discrimination are
    (more-or-less) equal.

    For example, if the objective is a program that can be downloaded and
    run in most browsers, C is probably a not a consideration no matter
    how much faster it runs. On the other hand, if the requirement is for
    complex server-side processing, javascript probably isn't in the race
    as it doesn't have any built-in input/output mechanism and is
    dependent on a suitable host environment. If requirements indicate a
    scripting language, a platform-native shell script may be the best
    choice.

    Do you have a proposed scenario?


    --
    Rob
    RobG, Feb 2, 2010
    #14
  15. denis

    RobG Guest

    On Feb 2, 2:13 am, Thomas 'PointedEars' Lahn <>
    wrote:
    > RobG wrote:
    > > denis wrote:
    > >> Please have a look at the FOLDOC (http://foldoc.org/) definition of
    > >> JavaScript:http://foldoc.org/javascript
    > >> and send any comments or corrections via the feedback button. Thanks.

    >
    > > There doesn't seem to be much to recommend it at all. How can a
    > > definition of JavaScript be considered complete if it doesn't mention
    > > ECMAScript? Or the standards involved? Nor does it attempt to
    > > distinguish between JavaScript, the trade mark, and the generic term
    > > "javascript" used to describe ECMAScript implementations that interact
    > > with DOMs, mostly in browsers.

    >
    > The term "javascript" is the invention of a wannabe here that failed to see
    > the differences between the many implementations, and fell into common use
    > because of other wannabes here that failed to or did not want to see them..


    Regardless of its heritage, it is by far the most popular general term
    for the various ECMAScript implementations. If agreement could have
    been reached to use Netscape's trademark for the standard, it would be
    called JavaScript.

    But that was not to be, so JavaScript is a Sun trademark and the name
    used by Mozilla for one of its ECMAScript implementations.
    Consequently it is necessary to distinguish (here) between the generic
    term "javascript" and the specific implementation or trademark
    "JavaScript".


    > > | (Formerly "LiveScript") Netscape's simple,

    >
    > > What are the criteria for "simple"? If the criterion is features
    > > provided by the base language, then ECAMScript is more complex than C,
    > > but C is not described as simple.

    >
    > Perhaps simple as compared to Java, because that was the intention for
    > creating it.


    So you agree that some criterion for "simple" should be included in
    the statement.


    > > | cross-platform,

    >
    > > That might be better as "platform independent".

    >
    > It is neither.


    It's not designed for any specific platform (where "platform" is taken
    to be an operating system and hardware combination) so it fits my
    definition of platform independence.

    Do you have a suggested improvement?


    > > | World-Wide Web scripting language, only very vaguely
    > > | related to Java

    >
    > > It isn't related to Java at all, at least not any more than it's
    > > related to say C.

    >
    > Incorrect. JavaScript™ was designed to be a Java-like scripting language;


    I don't think Java had much influence on JavaScript at all. From the
    quotes I've seen from Brendan Eich, the link with Java was just
    chance. Netscape were developing a simple scripting language for
    browsers. Java was released at about the same time (1995) as he was
    working on Mocha, which became LiveScript and then JavaScript in the
    space of about 6 months.

    Changing the name and linking it to Java was mostly a marketing
    exercise when Netscape teamed up with Sun to leverage the hype
    surrounding Java[1], so I don't think there was a specific intention
    to be "Java-like".

    [...]
    > > | (which is a Sun trademark).

    >
    > > So is JavaScript.

    >
    > And that does not make you think?


    That JavaScript is simplified Java? No. Sun wanted to protect the name
    Java and JavaScript, so they acquired the trademark. I don't see any
    link between the languages as a consequence.

    And the article doesn't mention that JavaScript is a Sun trademark.


    > > | JavaScript is intimately tied to the World-Wide Web,

    >
    > > More correctly, it is used most commonly for scripting in browsers on
    > > the World Wide Web.

    >
    > If you adopt the position that this dictionary entry should not only
    > describe JavaScript™, but also JScript aso.,


    I don't.

    > you have to take into account
    > that there is Server-Side JavaScript on NES-compatible servers, and
    > Service-side JScript (.NET) in ASP (.NET).


    Yes, but those uses are far less common than the use in browsers.


    > Therefore, the statement above is correct, and your "more correct" version
    > is in fact "less correct".


    No, it's not. You seem to have missed the phrase "used most commonly",
    or misread it as "used exclusively".


    > > | and currently runs in only three environments

    >
    > > If you are talking specifically about JavaScript(tm), perhaps.

    >
    > You do know what a dictionary is, don't you?


    I don't understand your point. There is an assertion that javascript
    runs in *only* three environments, I provided additional environments
    (as did you) to show the statement is incorrect. A dictionary should
    not contain errors of fact so the statement should be corrected.


    [...]
    > > | JavaScript originated from Netscape and, for a time,
    > > | only their products supported it. Microsoft now supports
    > > | a work-alike which they call JScript.

    >
    > > Now? For at least 15 years,

    >
    > You are exaggerating. JScript 1.0 was released with Internet Explorer 3.0
    > for Windows in 1996-08 (CE).


    Ok, 13 years and 5 months and perhaps a few days, as of 2010-02-02.
    And counting...


    [...]
    > The language standard for JavaScript is ECMAScript. That holds true
    > whether we adopt your position that this entry should also be about
    > other implementations of ECMAScript or not.
    >
    > > There are standards for ECMAScript

    >
    > Nonsense. ECMAScript *is* (the name of) the standard.


    Ok, there's a standard with a couple of versions.

    [...]
    > Yes, those guesses are non-encyclopedic. The statement is also wrong
    > because it has been established (citing Brendan Eich and Eric Lippert)
    > that J(ava)Script is _not_ "purely interpreted", and never has been.


    I didn't assert that it is "purely interpreted", the emphasis is
    yours. Clearly some implementations are going to compile it to make it
    faster, I agree Lasse's interpretation of "interpreted".

    [...]
    >
    > > | Netscape and Sun have co-operated to enable Java and
    > > | JavaScript to exchange messages and data.

    >
    > > That seems to be a very out dated comment.

    >
    > No, it still holds true.


    Yes, but the statement seem to infer that is the only development
    worth mentioning.

    [...]
    > I am therefore glad that your comments will probably have no impact on
    > FOLDOC since they have been made in the wrong place.



    Even though you agreed with some of them and provided useful criticism
    of others? I intend to send feedback as requested in the OP, but am
    glad to have had my comments reviewed here first. Thank you for
    contributing.

    1. <URL: http://www.infoworld.com/d/developer-world/javascript-creator-ponders-past-future-704
    >



    --
    Rob
    RobG, Feb 2, 2010
    #15
  16. RobG wrote:

    > Thomas 'PointedEars' Lahn wrote:
    >> RobG wrote:
    >> > denis wrote:
    >> >> Please have a look at the FOLDOC (http://foldoc.org/) definition of
    >> >> JavaScript:http://foldoc.org/javascript
    >> >> and send any comments or corrections via the feedback button.
    >> >> Thanks.
    >> > There doesn't seem to be much to recommend it at all. How can a
    >> > definition of JavaScript be considered complete if it doesn't mention
    >> > ECMAScript? Or the standards involved? Nor does it attempt to
    >> > distinguish between JavaScript, the trade mark, and the generic term
    >> > "javascript" used to describe ECMAScript implementations that interact
    >> > with DOMs, mostly in browsers.

    >> The term "javascript" is the invention of a wannabe here that failed to
    >> see the differences between the many implementations, and fell into
    >> common use because of other wannabes here that failed to or did not want
    >> to see them.

    >
    > Regardless of its heritage, it is by far the most popular general term
    > for the various ECMAScript implementations. If agreement could have
    > been reached to use Netscape's trademark for the standard, it would be
    > called JavaScript.
    >
    > But that was not to be, so JavaScript is a Sun trademark and the name
    > used by Mozilla for one of its ECMAScript implementations.
    > Consequently it is necessary to distinguish (here) between the generic
    > term "javascript" and the specific implementation or trademark
    > "JavaScript".


    However, it is a mistake to use one term for all the implementations that
    does not make it obvious that several languages are being discussed (by
    contrast to, e.g. "ECMAScript implementation*s*"). AISB, "javascript"
    promotes the common misconception of the one scripting language where there
    are in fact several, different ones that need to be considered when writing
    especially client-side script code (not considering non-ECMAScript-
    compliant ones, of course).

    >> > | (Formerly "LiveScript") Netscape's simple,

    >>
    >> > What are the criteria for "simple"? If the criterion is features
    >> > provided by the base language, then ECAMScript is more complex than C,
    >> > but C is not described as simple.

    >> Perhaps simple as compared to Java, because that was the intention for
    >> creating it.

    >
    > So you agree that some criterion for "simple" should be included in
    > the statement.


    No.

    >> > | cross-platform,

    >>
    >> > That might be better as "platform independent".

    >>
    >> It is neither.

    >
    > It's not designed for any specific platform (where "platform" is taken
    > to be an operating system and hardware combination) so it fits my
    > definition of platform independence.
    >
    > Do you have a suggested improvement?


    Omission.

    >> > | World-Wide Web scripting language, only very vaguely
    >> > | related to Java

    >>
    >> > It isn't related to Java at all, at least not any more than it's
    >> > related to say C.

    >>
    >> Incorrect. JavaScriptâ„¢ was designed to be a Java-like scripting
    >> language;

    >
    > I don't think Java had much influence on JavaScript at all.


    Of course not. You misunderstand.

    > From the quotes I've seen from Brendan Eich, the link with Java was just
    > chance.


    Read again.

    > Netscape were developing a simple scripting language for
    > browsers. Java was released at about the same time (1995) as he was
    > working on Mocha, which became LiveScript and then JavaScript in the
    > space of about 6 months.
    >
    > Changing the name and linking it to Java was mostly a marketing
    > exercise when Netscape teamed up with Sun to leverage the hype
    > surrounding Java[1], so I don't think there was a specific intention
    > to be "Java-like".


    Regardless what you think, that is what it was. The name and syntax was
    _not_ chosen by mere coincidence, nor is the statement of "Java-like" there
    in the Specification since ECMAScript Edition 1 by mere chance.

    > [...]
    >> > | (which is a Sun trademark).
    >> > So is JavaScript.

    >> And that does not make you think?

    >
    > That JavaScript is simplified Java? No. [...]


    Then you are a fool.

    > And the article doesn't mention that JavaScript is a Sun trademark.


    So what?

    >> > | JavaScript is intimately tied to the World-Wide Web,

    >>
    >> > More correctly, it is used most commonly for scripting in browsers on
    >> > the World Wide Web.

    >>
    >> If you adopt the position that this dictionary entry should not only
    >> describe JavaScriptâ„¢, but also JScript aso.,

    >
    > I don't.


    Yes, you do. This dictionary entry is specifically about JavaScriptâ„¢, yet
    you by your own account you want it to contain more elaborate descriptions
    about this "javascript" fantasy, JScript, ActionScript aso. That does not
    belong there, it belongs in the entries about "javascript", JScript, and
    ActionScript aso., if that.

    >> you have to take into account
    >> that there is Server-Side JavaScript on NES-compatible servers, and
    >> Service-side JScript (.NET) in ASP (.NET).

    >
    > Yes, but those uses are far less common than the use in browsers.


    Stop making assumptions, show some facts for a change. Your assumptions
    do not belong any more in that entry than the original author's about JS
    speed.

    >> Therefore, the statement above is correct, and your "more correct"
    >> version is in fact "less correct".

    >
    > No, it's not. You seem to have missed the phrase "used most commonly",
    > or misread it as "used exclusively".


    No, I didn't.

    >> > | and currently runs in only three environments

    >>
    >> > If you are talking specifically about JavaScript(tm), perhaps.

    >>
    >> You do know what a dictionary is, don't you?

    >
    > I don't understand your point.


    This entry is about JavaScript, not about any delusions of "javascript".

    > There is an assertion that javascript runs in *only* three environments,
    > [...]


    There is no assertion about a "javascript" there at all!

    > [...]
    >> The language standard for JavaScript is ECMAScript. That holds true
    >> whether we adopt your position that this entry should also be about
    >> other implementations of ECMAScript or not.
    >>
    >> > There are standards for ECMAScript

    >>
    >> Nonsense. ECMAScript *is* (the name of) the standard.

    >
    > Ok, there's a standard with a couple of versions.


    _Editions_, and _revisions_ of those (most notably, revisions ES3 and ES3F,
    and editions ES1 to 3, and ES5).

    > [...]
    >> Yes, those guesses are non-encyclopedic. The statement is also wrong
    >> because it has been established (citing Brendan Eich and Eric Lippert)
    >> that J(ava)Script is _not_ "purely interpreted", and never has been.

    >
    > I didn't assert that it is "purely interpreted", [...]


    But the original author did. Learn to read.

    > [...]
    >>
    >> > | Netscape and Sun have co-operated to enable Java and
    >> > | JavaScript to exchange messages and data.

    >>
    >> > That seems to be a very out dated comment.

    >>
    >> No, it still holds true.

    >
    > Yes, but the statement seem to infer that is the only development
    > worth mentioning.


    In your dreams.

    > [...]
    >> I am therefore glad that your comments will probably have no impact on
    >> FOLDOC since they have been made in the wrong place.

    >
    > Even though you agreed with some of them and provided useful criticism
    > of others?


    Yes. Hopefully this discussion will help to sort out all the
    misconceptions that are so common about this language and these
    languages first.

    > I intend to send feedback as requested in the OP, but am
    > glad to have had my comments reviewed here first. Thank you for
    > contributing.


    OK.


    PointedEars
    --
    Prototype.js was written by people who don't know javascript for people
    who don't know javascript. People who don't know javascript are not
    the best source of advice on designing systems that use javascript.
    -- Richard Cornford, cljs, <f806at$ail$1$>
    Thomas 'PointedEars' Lahn, Feb 2, 2010
    #16
  17. kangax wrote:

    > Thomas 'PointedEars' Lahn wrote:
    >> RobG wrote:

    > [...]
    >>> | This could be attributed to the slow progress of JavaScript
    >>> | through the standards bodies.
    >>>
    >>> But there is no standard for JavaScript, it's just a trade mark.

    >>
    >> The language standard for JavaScript is ECMAScript. That holds true
    >> whether we adopt your position that this entry should also be about
    >> other implementations of ECMAScript or not.
    >>
    >>> There are standards for ECMAScript

    >>
    >> Nonsense. ECMAScript *is* (the name of) the standard.

    >
    > Not exactly.
    >
    > The name of the standard is *ECMA-262*, not ECMAScript. ECMAScript is a
    > name of the *language* (defined by ECMA-262 standard).


    You are mistaken. ECMA-262 is _not_ the name, it is merely the original
    registry number. Another registry number for the standard of the same name
    is ISO/IEC 16262:2002. Much as RFC0959 or STD 9 are only registry numbers
    for the Internet Standard named File Transfer Protocol (FTP).


    PointedEars
    --
    Prototype.js was written by people who don't know javascript for people
    who don't know javascript. People who don't know javascript are not
    the best source of advice on designing systems that use javascript.
    -- Richard Cornford, cljs, <f806at$ail$1$>
    Thomas 'PointedEars' Lahn, Feb 2, 2010
    #17
  18. denis

    RobG Guest

    On Feb 2, 4:01 pm, Thomas 'PointedEars' Lahn <>
    wrote:
    > RobG wrote:
    > > Thomas 'PointedEars' Lahn wrote:

    [...]
    > >> The term "javascript" is the invention of a wannabe here that failed to
    > >> see the differences between the many implementations, and fell into
    > >> common use because of other wannabes here that failed to or did not want
    > >> to see them.

    >
    > > Regardless of its heritage, it is by far the most popular general term
    > > for the various ECMAScript implementations. If agreement could have
    > > been reached to use Netscape's trademark for the standard, it would be
    > > called JavaScript.

    [...]
    > However, it is a mistake to use one term for all the implementations that
    > does not make it obvious that several languages are being discussed (by
    > contrast to, e.g. "ECMAScript implementation*s*").


    You can rail against the tide of opinion all you like, but
    "javascript" is the generic term used for the various ECMAScript
    implementations in browsers at least, and several other environments
    as well. The FAQ seems to agree:

    "1.2 What questions are on-topic for comp.lang.javascript?
    "The comp.lang.javascript newsgroup deals with ECMAScript languages,
    so any questions about JavaScript or JScript are welcome. However, the
    majority of questions sent to this group relates to javascript in a
    web browser."

    The name of this group infers it.


    > AISB, "javascript"
    > promotes the common misconception of the one scripting language where there
    > are in fact several, different ones that need to be considered when writing
    > especially client-side script code (not considering non-ECMAScript-
    > compliant ones, of course).


    Which is why a general definition of JavaScript should note the
    difference between the generic term, the trademark and the
    implementation.



    > >> > | (Formerly "LiveScript") Netscape's simple,

    >
    > >> > What are the criteria for "simple"? If the criterion is features
    > >> > provided by the base language, then ECAMScript is more complex than C,
    > >> > but C is not described as simple.
    > >> Perhaps simple as compared to Java, because that was the intention for
    > >> creating it.

    >
    > > So you agree that some criterion for "simple" should be included in
    > > the statement.

    >
    > No.


    So when you wrote "Perhaps simple as compared to Java" you seem to
    think a qualification was necessary. It was clearly an intention of
    Brendan Eich to make JavaScript a simple language to use, but to state
    that without qualification can easily give the impression that it is
    also not suitable for anything other than simple tasks.

    [...]
    > >> > | World-Wide Web scripting language, only very vaguely
    > >> > | related to Java

    >
    > >> > It isn't related to Java at all, at least not any more than it's
    > >> > related to say C.

    >
    > >> Incorrect.  JavaScript™ was designed to be a Java-like scripting
    > >> language;

    >
    > > I don't think Java had much influence on JavaScript at all.

    >
    > Of course not.  You misunderstand.
    >
    > > From the quotes I've seen from Brendan Eich, the link with Java was just
    > > chance.

    >
    > Read again.


    Perhaps if you just write slower and louder I'll come around to your
    point of view.


    > > Netscape were developing a simple scripting language for
    > > browsers. Java was released at about the same time (1995) as he was
    > > working on Mocha, which became LiveScript and then JavaScript in the
    > > space of about 6 months.

    >
    > > Changing the name and linking it to Java was mostly a marketing
    > > exercise when Netscape teamed up with Sun to leverage the hype
    > > surrounding Java[1], so I don't think there was a specific intention
    > > to be "Java-like".

    >
    > Regardless what you think, that is what it was.  The name and syntax was
    > _not_ chosen by mere coincidence, nor is the statement of "Java-like" there
    > in the Specification since ECMAScript Edition 1 by mere chance.


    The ECMAScript spec was long after the original development of
    JavaScript and continued the name association with Java (for whatever
    reason). The term "Java-like" is better though than "vaguely related
    to Java".


    > > [...]
    > >> > | (which is a Sun trademark).
    > >> > So is JavaScript.
    > >> And that does not make you think?

    >
    > > That JavaScript is simplified Java? No.  [...]

    >
    > Then you are a fool.


    Maybe, but not because you say so.

    Brendan Eich stated (in the article I linked to):

    "And then in early December, Netscape and Sun did a license agreement
    and it became JavaScript. And the idea was to make it a complementary
    scripting language to go with Java, with the compiled language"

    There you have it - JavaScript was intended (at that time) to be
    *complementary* to Java. The idea was that Java plugins would do the
    heavy client-side stuff and JavaScript the light stuff. JavaScript was
    developed independently of Java and its name changed as a marketing
    tactic. One that has backfired to some extent as for a long time
    JavaScript was seen as a dumbed-down version of Java. It isn't, it
    never was and was never intended to be.


    > > And the article doesn't mention that JavaScript is a Sun trademark.

    >
    > So what?


    Because a complete definition of "JavaScript" should do that.


    > >> > | JavaScript is intimately tied to the World-Wide Web,

    >
    > >> > More correctly, it is used most commonly for scripting in browsers on
    > >> > the World Wide Web.

    >
    > >> If you adopt the position that this dictionary entry should not only
    > >> describe JavaScript™, but also JScript aso.,

    >
    > > I don't.

    >
    > Yes, you do.


    No, I don't.

    > This dictionary entry is specifically about JavaScript™,


    Is it? The trademark isn't mentioned anywhere, and you're the one who
    can't see a reason to include it. Now you claim the article is
    specifically about a Netscape (now Mozilla) implementation of
    ECMAScript.

    Perhaps *you* should provide a concise definition of your use of the
    terms "JavaScript" and "JavaScript™". It's becoming less clear to me.


    > yet
    > you by your own account you want it to contain more elaborate descriptions
    > about this "javascript" fantasy, JScript, ActionScript aso.


    I've explained that "fantasy" and its relevance to the article. It's
    over to the OP now.


    > That does not
    > belong there, it belongs in the entries about "javascript", JScript, and
    > ActionScript aso., if that.


    So you think the article should constrain itself to JavaScript™ only?
    But not mention the trademark?


    > >> you have to take into account
    > >> that there is Server-Side JavaScript on NES-compatible servers, and
    > >> Service-side JScript (.NET) in ASP (.NET).

    >
    > > Yes, but those uses are far less common than the use in browsers.

    >
    > Stop making assumptions, show some facts for a change.


    I think it's a pretty reasonable assumption. There are hundreds of
    millions of browsers in daily use. How many server-side JavaScript
    applications do you know of?


    > Your assumptions
    > do not belong any more in that entry than the original author's about JS
    > speed.
    >
    > >> Therefore, the statement above is correct, and your "more correct"
    > >> version is in fact "less correct".

    >
    > > No, it's not. You seem to have missed the phrase "used most commonly",
    > > or misread it as "used exclusively".

    >
    > No, I didn't.


    So you think server-side uses of JavaScript are more common that
    client-side uses? Where's *your* proof?


    > >> > | and currently runs in only three environments

    >
    > >> > If you are talking specifically about JavaScript(tm), perhaps.

    >
    > >> You do know what a dictionary is, don't you?

    >
    > > I don't understand your point.

    >
    > This entry is about JavaScript, not about any delusions of "javascript".


    You seem to be deliberatly obtuse. I can't decide whether you think
    this article is about JavaScript™ or the generic term JavaScript. If
    the assertion that either JavaScript™ or JavaScript runs in only the 3
    enviroments mentioned, it is wrong.


    --
    Rob
    RobG, Feb 2, 2010
    #18
  19. kangax wrote:

    > Thomas 'PointedEars' Lahn wrote:
    >> kangax wrote:
    >>> Thomas 'PointedEars' Lahn wrote:
    >>>> RobG wrote:
    >>>>> There are standards for ECMAScript
    >>>> Nonsense. ECMAScript *is* (the name of) the standard.
    >>> Not exactly.
    >>>
    >>> The name of the standard is *ECMA-262*, not ECMAScript. ECMAScript is a
    >>> name of the *language* (defined by ECMA-262 standard).

    >>
    >> You are mistaken. ECMA-262 is _not_ the name, it is merely the original
    >> registry number.

    >
    > ECMA clearly states that standard is called "ECMA-262".


    No. (There is also no ECMA anymore, the organization is called "Ecma
    International" since quite a while.)

    > On the download page (with the link to publication):
    >
    > Standard ECMA-262


    That is the original registry number.

    > ECMAScript Language Specification


    That is the name. It can also be found from Edition 1 to Edition 3 in the
    header of each page of the document, on the cover sheet, and from Editions
    1 to 5 as highest-level heading (right before section 1).

    > <http://www.ecma-international.org/publications/standards/Ecma-262.htm>
    >
    > In the actual document, the term "Ecma standard" is used most often,


    As in "*this* ECMA/Ecma standard"? Yes, and rightly so. ES5,
    Introduction:

    | This Ecma Standard is based on several originating technologies, the
    | most well known being JavaScript (Netscape) and JScript (Microsoft).
    | [...]

    "This Ecma Standard" is, of course, to be understood here as "This Standard
    published (first) by Ecma International" since Ecma International
    (formerly: ECMA) also published a lot of other standards.

    > although there's also one occurrence of "ECMAScript standard".


    To be precise, in ES5, Introduction:

    | The third edition of the ECMAScript standard was adopted by
    | the Ecma General Assembly of December 1999 and published as
    | ISO/IEC 16262:2002 in June 2002.

    Which removes any doubts as to the name of the standard.

    >> Another registry number for the standard of the same name
    >> is ISO/IEC 16262:2002.

    >
    > Where does it say that the standard with ISO/IEC 16262:2002 registry
    > number is called "ECMAScript standard"?


    To be precise, it says "ECMAScript Language Specification" there, too (the
    same name, independent of the registry number), but that is a rather long
    term, so in discussion the short-hand terms "ECMAScript" and "ECMAScript
    standard" (the latter to emphasize that it is a standard document being
    referred to) are often used instead.


    PointedEars
    --
    realism: HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness: XHTML 1.1 as application/xhtml+xml
    -- Bjoern Hoehrmann
    Thomas 'PointedEars' Lahn, Feb 2, 2010
    #19
  20. RobG wrote:

    > Thomas 'PointedEars' Lahn wrote:
    >> RobG wrote:
    >> > Thomas 'PointedEars' Lahn wrote:
    >> >> [...]
    >> >> The term "javascript" is the invention of a wannabe here that failed
    >> >> to see the differences between the many implementations, and fell
    >> >> into common use because of other wannabes here that failed to or did
    >> >> not want to see them.
    >> >
    >> > Regardless of its heritage, it is by far the most popular general term
    >> > for the various ECMAScript implementations. If agreement could have
    >> > been reached to use Netscape's trademark for the standard, it would be
    >> > called JavaScript.

    >> [...]
    >> However, it is a mistake to use one term for all the implementations
    >> that does not make it obvious that several languages are being discussed
    >> (by contrast to, e.g. "ECMAScript implementation*s*").

    >
    > You can rail against the tide of opinion all you like,


    The "tide of opinion" merely exists in your vivid imagination and that of
    other wannabes.

    > but "javascript" is the generic term used for the various ECMAScript
    > implementations in browsers at least,


    To be precise, it is used by people who don't know what they are talking
    about, or are too lazy to be precise. Unfortunately, their number has
    increased here in recent years.

    > and several other environments as well. The FAQ seems to agree:


    Unfortunately, the FAQ is currently maintained by a wannabe, and has often
    (as in this case) been modified without general agreement by him to fit the
    fantasies and lazyness of himself and others. Granted, the FAQ at least
    defines the term it *invents*; however, that does not prevent the
    misconception that must occur when (not if) the term is used without the
    definition text or reference to it.

    "javascript" becomes even more ambiguous when (not if) it is written
    "Javascript" (at the beginning of a sentence, or elsewhere a leading
    capital letter would be recommended) as if it would be definitively obvious
    to the uninitiated what was meant then. "ECMAScript implementation", by
    contrast, does not have either problem; even though it raises questions to
    the uninitiated as to what ECMAScript and an ECMAScript implementation is,
    those are questions that ultimately lead to *greater* understanding.

    > The name of this group infers it.


    That is probably the stupidest thing you have ever said.

    >> AISB, "javascript" promotes the common misconception of the one
    >> scripting language where there are in fact several, different ones
    >> that need to be considered when writing especially client-side script
    >> code (not considering non-ECMAScript- compliant ones, of course).

    >
    > Which is why a general definition of JavaScript should note the
    > difference between the generic term, the trademark and the
    > implementation.


    Rubbish. "JavaScript" is the name of one implementation and it is a
    trademark. Period.

    >> >> > | (Formerly "LiveScript") Netscape's simple,
    >> >> >
    >> >> > What are the criteria for "simple"? If the criterion is features
    >> >> > provided by the base language, then ECAMScript is more complex than
    >> >> > C, but C is not described as simple.
    >> >> Perhaps simple as compared to Java, because that was the intention
    >> >> for creating it.
    >> > So you agree that some criterion for "simple" should be included in
    >> > the statement.

    >> No.

    >
    > So when you wrote "Perhaps simple as compared to Java" you seem to
    > think a qualification was necessary. [...]


    No. I tried to explain to you why the word "simple" was chosen, and why it
    can be understood without further quibbling.

    >> > From the quotes I've seen from Brendan Eich, the link with Java was
    >> > just chance.

    >> Read again.

    >
    > Perhaps if you just write slower and louder I'll come around to your
    > point of view.


    Perhaps if you stopped talking about things that you don't know about as if
    you knew about them, you looked a bit wiser.

    >> > Netscape were developing a simple scripting language for
    >> > browsers. Java was released at about the same time (1995) as he was
    >> > working on Mocha, which became LiveScript and then JavaScript in the
    >> > space of about 6 months.
    >> >
    >> > Changing the name and linking it to Java was mostly a marketing
    >> > exercise when Netscape teamed up with Sun to leverage the hype
    >> > surrounding Java[1], so I don't think there was a specific intention
    >> > to be "Java-like".

    >>
    >> Regardless what you think, that is what it was. The name and syntax was
    >> _not_ chosen by mere coincidence, nor is the statement of "Java-like"
    >> there in the Specification since ECMAScript Edition 1 by mere chance.

    >
    > The ECMAScript spec was long after the original development of
    > JavaScript


    You don't know what you are talking about. JavaScript 1.0 was released,
    with Netscape Navigator 2.0, in 1996-03, and ECMAScript Edition 1 was
    published in 1997-06. Development of Edition 1 started in 1996-11.

    > and continued the name association with Java (for whatever
    > reason). The term "Java-like" is better though than "vaguely related
    > to Java".


    "Java-like" is merely a rewording of "ECMAScript syntax intentionally
    resembles Java syntax." that can be found in all Editions and revisions
    of the Specification, as I have pointed out to you in this thread several
    times before.

    >> > [...]
    >> >> > | (which is a Sun trademark).
    >> >> > So is JavaScript.
    >> >> And that does not make you think?
    >> > That JavaScript is simplified Java? No. [...]

    >> Then you are a fool.

    >
    > Maybe, but not because you say so.
    >
    > Brendan Eich stated (in the article I linked to):
    >
    > "And then in early December, Netscape and Sun did a license agreement
    > and it became JavaScript. And the idea was to make it a complementary
    > scripting language to go with Java, with the compiled language"
    >
    > There you have it - JavaScript was intended (at that time) to be
    > *complementary* to Java. The idea was that Java plugins would do the
    > heavy client-side stuff and JavaScript the light stuff. JavaScript was
    > developed independently of Java and its name changed as a marketing
    > tactic. One that has backfired to some extent as for a long time
    > JavaScript was seen as a dumbed-down version of Java. It isn't, it
    > never was and was never intended to be.


    You are mistaken. "Complementary" means "one adds to the other", not "one
    is concurrent of the other". You don't give a programming language syntax
    that closely resembles the syntax of another programming language, and a
    name that resembles the name of another programming language to fight the
    latter. You obviously do it instead because you think the latter language
    is popular enough so that the similarities will help the adoption of your
    new language. That has been so with Java and JavaScript at the time, and
    Eich's statement clearly says that the agreement was done for mutual
    benefit.

    >> > And the article doesn't mention that JavaScript is a Sun trademark.

    >> So what?

    >
    > Because a complete definition of "JavaScript" should do that.


    I don't think so.

    >> >> > | JavaScript is intimately tied to the World-Wide Web,
    >> >> >
    >> >> > More correctly, it is used most commonly for scripting in browsers
    >> >> > on the World Wide Web.
    >> >> If you adopt the position that this dictionary entry should not only
    >> >> describe JavaScriptâ„¢, but also JScript aso.,
    >> > I don't.

    >> Yes, you do.

    > No, I don't.
    >> This dictionary entry is specifically about JavaScriptâ„¢,

    >
    > Is it?


    Obviously.

    > The trademark isn't mentioned anywhere,


    The distinction is made there with JScript to begin with. So quite
    obviously this is _not_ a generic description of ECMAScript implementations
    (in your parallel universe: "javascript").

    >> yet you by your own account you want it to contain more elaborate
    >> descriptions about this "javascript" fantasy, JScript, ActionScript aso.

    >
    > I've explained that "fantasy" and its relevance to the article. It's
    > over to the OP now.


    Provided the OP is the editor.

    >> That does not belong there, it belongs in the entries about
    >> "javascript", JScript, and ActionScript aso., if that.

    >
    > So you think the article should constrain itself to JavaScriptâ„¢ only?


    As it already does.

    > But not mention the trademark?


    What would it be good for? That there is yet another name that is
    trademarked? That the entry needs to be changed if the trademark
    owner changes?

    >> >> you have to take into account
    >> >> that there is Server-Side JavaScript on NES-compatible servers, and
    >> >> Service-side JScript (.NET) in ASP (.NET).
    >> > Yes, but those uses are far less common than the use in browsers.

    >> Stop making assumptions, show some facts for a change.

    >
    > I think it's a pretty reasonable assumption. There are hundreds of
    > millions of browsers in daily use. How many server-side JavaScript
    > applications do you know of?


    Irrelevant. Try again.

    >> >> Therefore, the statement above is correct, and your "more correct"
    >> >> version is in fact "less correct".
    >> > No, it's not. You seem to have missed the phrase "used most commonly",
    >> > or misread it as "used exclusively".

    >> No, I didn't.

    >
    > So you think server-side uses of JavaScript are more common that
    > client-side uses?


    No, I don't.

    > Where's *your* proof?


    I don't need to prove statements that exist only in your head.

    >> >> > | and currently runs in only three environments
    >> >> >
    >> >> > If you are talking specifically about JavaScript(tm), perhaps.
    >> >> You do know what a dictionary is, don't you?
    >> > I don't understand your point.

    >> This entry is about JavaScript, not about any delusions of "javascript".

    >
    > You seem to be deliberatly obtuse.


    Pot, kettle, black.

    > I can't decide whether you think this article is about JavaScriptâ„¢ or
    > the generic term JavaScript.


    Well, we know by now that you have a considerable reading problem.


    PointedEars
    --
    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, Feb 2, 2010
    #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.
Similar Threads
  1. Erik Markert
    Replies:
    2
    Views:
    806
    Erik Markert
    Sep 25, 2003
  2. Jianli Shen
    Replies:
    1
    Views:
    556
    Victor Bazarov
    Mar 13, 2005
  3. Ark
    Replies:
    1
    Views:
    398
    Chris Torek
    Aug 7, 2004
  4. Jon Slaughter
    Replies:
    4
    Views:
    422
    Jon Slaughter
    Oct 26, 2005
  5. Pierre Yves
    Replies:
    2
    Views:
    468
    Pierre Yves
    Jan 10, 2008
Loading...

Share This Page