FOLDOC definition

[denis]

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.

 

[Luuk]

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

 

[Lasse Reichstein Nielsen]

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

 

[Thomas 'PointedEars' Lahn]

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

 

[Jorge]

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 ?

 

[RobG]

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 >

 

[Luuk]

Op 1-2-2010 0:07, Thomas 'PointedEars' Lahn schreef:

Before it gets interpreted it gets compiled, though.

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

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?

 

[rf]

Op 1-2-2010 0:07, Thomas 'PointedEars' Lahn schreef:

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?

 

[Luuk]

Op 1-2-2010 13:37, rf schreef:

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

 

[Thomas 'PointedEars' Lahn]

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>

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

 

[Thomas 'PointedEars' Lahn]

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

 

[Lasse Reichstein Nielsen]

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

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

 

[RobG]

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?

 

[RobG]

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

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.

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?

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

[...]

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.

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

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.


[...]

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.


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

[...]

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

 

[Thomas 'PointedEars' Lahn]

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

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


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.


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.

[...]

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?

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.

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.

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

No, I didn't.

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.


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.

[...]

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

 

[Thomas 'PointedEars' Lahn]

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

 

[RobG]

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.

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.

[...]

Of course not.  You misunderstand.


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.

So what?

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

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?

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.



No, I didn't.

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

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.

 

[Thomas 'PointedEars' Lahn]

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.

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

 

[Thomas 'PointedEars' Lahn]

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.

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.

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.

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.

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

I don't think so.

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

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

Provided the OP is the editor.

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?

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.

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.

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