FOLDOC definition
 

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.

Re: FOLDOC definition
 

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

Re: FOLDOC definition
 

Luuk <luuk@invalid.lan> 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'

Re: FOLDOC definition
 

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

Re: FOLDOC definition
 

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.

Re: FOLDOC definition
 

On Feb 1, 7:23 am, denis <d...@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

Re: FOLDOC definition
 

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

Re: FOLDOC definition
 

"Luuk" <luuk@invalid.lan> wrote in message
news:iqti37-14l.ln1@qqqqq.xs4all.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?

Re: FOLDOC definition
 

Op 1-2-2010 13:37, rf schreef:
> "Luuk" <luuk@invalid.lan> wrote in message
> news:iqti37-14l.ln1@qqqqq.xs4all.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

Re: FOLDOC definition
 

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