From: RobG on
On Feb 1, 7:23 am, denis <d...(a)doc.ic.ac.uk> 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
From: Thomas 'PointedEars' Lahn on
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.)
From: Thomas 'PointedEars' Lahn on
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
From: Lasse Reichstein Nielsen on
Jorge <jorge(a)jorgechamorro.com> 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'

From: Lasse Reichstein Nielsen on
RobG <rgqld(a)iinet.net.au> 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'