From Newsgroup: comp.lang.javascript

OK, so the actual anniversary was back in March. But I just
(re)discovered the InfoWorld site, and was surprised to discover it
has become such a software-development-focused place (was it before?).

This article <https://www.infoworld.com/article/3836901/10-things-developers-love-about-javascript-and-10-things-they-dont.html>
goes over some of the things the author(s) love about JavaScript, and
some things they donrCOt.

In terms of punctuation, didnrCOt they know semicolons (at least as
statement terminators) are optional in JavaScript? Yes, the rule is a
bit more subtle than in Python, but even I, a Python programmer, was
able to figure it out.

Type conversion: this I do not love. Being able to compare integers
and reals is natural and reasonably safe, bringing strings into the
mix is not. ThererCOs a reason why Python is able to get away with not
needing a rCL===rCY operator, while JavaScript and PHP are not.

Truthiness: yes, this is a pitfall, too. Languages should just take
the Pascal route and insist that conditions be of Boolean type.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.javascript

On 24/04/2025 04:52, Lawrence D'Oliveiro wrote:

OK, so the actual anniversary was back in March. But I just
(re)discovered the InfoWorld site, and was surprised to discover it
has become such a software-development-focused place (was it before?).

This article <https://www.infoworld.com/article/3836901/10-things-developers-love-about-javascript-and-10-things-they-dont.html>
goes over some of the things the author(s) love about JavaScript, and
some things they donrCOt.

In terms of punctuation, didnrCOt they know semicolons (at least as
statement terminators) are optional in JavaScript? Yes, the rule is a
bit more subtle than in Python, but even I, a Python programmer, was
able to figure it out.

I would like to have the semicolons mandatory. They should also be
required after a '}' if the statement the block is part of endt there
(no 'else' or 'until' follows).

Type conversion: this I do not love. Being able to compare integers
and reals is natural and reasonably safe, bringing strings into the
mix is not. ThererCOs a reason why Python is able to get away with not needing a rCL===rCY operator, while JavaScript and PHP are not.

At least '===' and '!==' are there so there is no need to use '=='
or '!=' when one doesn't want.

Truthiness: yes, this is a pitfall, too. Languages should just take
the Pascal route and insist that conditions be of Boolean type.

Fortunatly conditions are usually in contexts that marks them as
conditions.

One problem with many program languages is that the program does not
identify the revision of the standard. This would be important with
Javascript as the same program is intended for a large variety of implementations that are not updated to the latest revision or are
aleady updated to a revision that is published after the publication
of the program.

In Javascript there is the pragma "use strict". A similar pragma could
be used to identify the revision expected to be supported. In addition
there should be a global constant or constants or function that tells
the revision acutally supported so that program can adapt to what is
available.

The subject line means that Javascript already existed 30 years ago.
In some sense that is false: the Javascript that we know today is
not the same as the Javascript 30 years ago. But it is true as much
of what Javascript was 30 years ago is still present in the moders
Javascript.
--
Mikko
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.javascript

On 2025-04-24, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

Truthiness: yes, this is a pitfall, too. Languages should just take
the Pascal route and insist that conditions be of Boolean type.

Absolutely not. While getting "truthiness" wrong is a flaw in some
programming languages, and while JavaScript doesn't quite get it 100%
right (although some of this is probably down to the way JavaScript
objects work), going to the other extreme of saying that only literal
'true' is true and only literal 'false' is false is also an error.

It's incredibly useful to say:

if (x)

and not to have to write something like:

if (x !== undefined && x !== null && x !== '')

and the former is, if anything, *more* readable - in any language
with a sensible "truthiness" definition anyway.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.javascript

On Mon, 13 Jul 2026 16:12:42 +0300, Mikko wrote:

I would like to have the semicolons mandatory.

So would I. But given that theyrCOre not, we have to work with the
language as it is specified.

At least '===' and '!==' are there so there is no need to use '=='
or '!=' when one doesn't want.

Think about why a language like Python doesnrCOt need rCL===rCY and rCL!==rCY. ItrCOs because it eschews the more error-prone automatic type
conversions, so it doesnrCOt need a way to turn them off.

Fortunatly conditions are usually in contexts that marks them as
conditions.

And if an expression returns certain values, the result of
(mis)interpreting them as booleans can be ... interesting.

One problem with many program languages is that the program does not
identify the revision of the standard. This would be important with Javascript as the same program is intended for a large variety of implementations that are not updated to the latest revision or are
aleady updated to a revision that is published after the publication
of the program.

HTML used to have rCL<script language=javascript>rCY versus rCL<script language=javascript1.2>rCY etc. For some reason that was considered more trouble than it was worth.

The subject line means that Javascript already existed 30 years ago.
In some sense that is false: the Javascript that we know today is
not the same as the Javascript 30 years ago.

So when did todayrCOs JavaScript come into being? How old would you say
it really was, if not 30 years?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.javascript

On 14/07/2026 01:31, Lawrence DrCOOliveiro wrote:

On Mon, 13 Jul 2026 16:12:42 +0300, Mikko wrote:

The subject line means that Javascript already existed 30 years ago.
In some sense that is false: the Javascript that we know today is
not the same as the Javascript 30 years ago.

So when did todayrCOs JavaScript come into being? How old would you say
it really was, if not 30 years?

One can say that every time the standard is updated it creates a new
lanugage. But often it is reasonable to say otherwise.
--
Mikko
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.javascript

On Tue, 14 Jul 2026 09:59:35 +0300, Mikko wrote:

On 14/07/2026 01:31, Lawrence DrCOOliveiro wrote:

On Mon, 13 Jul 2026 16:12:42 +0300, Mikko wrote:

The subject line means that Javascript already existed 30 years
ago. In some sense that is false: the Javascript that we know
today is not the same as the Javascript 30 years ago.

So when did todayrCOs JavaScript come into being? How old would you
say it really was, if not 30 years?

One can say that every time the standard is updated it creates a new lanugage. But often it is reasonable to say otherwise.

So how old is it really?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.javascript

On 13/07/2026 14:12, Mikko wrote:

On 24/04/2025 04:52, Lawrence D'Oliveiro wrote:

OK, so the actual anniversary was back in March. But I just
(re)discovered the InfoWorld site, and was surprised to discover it
has become such a software-development-focused place (was it before?).

This article
<https://www.infoworld.com/article/3836901/10-things-developers-love-
about-javascript-and-10-things-they-dont.html>
goes over some of the things the author(s) love about JavaScript, and
some things they donrCOt.

In terms of punctuation, didnrCOt they know semicolons (at least as
statement terminators) are optional in JavaScript? Yes, the rule is a
bit more subtle than in Python, but even I, a Python programmer, was
able to figure it out.

I would like to have the semicolons mandatory. They should also be
required after a '}' if the statement the block is part of endt there
(no 'else' or 'until' follows).

This is a statement :
{ }
and so is this :
;
Therefore
{ } ;
is two statements.
The way to solve the Dangling Else problem is to end every if statement
with :
endif
but that's unlikely to happen.

Incidentally, the history of semicolons in javascript is that a lot of
people scream loudly if semicolons aren't used, and just as many scream
loudly if they are. :-(


John

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.javascript

On Tue, 14 Jul 2026 10:50:33 +0100, John Harris wrote:

Incidentally, the history of semicolons in javascript is that a lot
of people scream loudly if semicolons aren't used, and just as many
scream loudly if they are. :-(

I think there are more that scream loudly if they arenrCOt ...

function add_element(parent, name, objattrs, tagattrs, children = null)
/* general routine for creating a new HTMLElement, initializing
attributes, and attaching it to a parent element and attaching
child elements, if specified. */
/* I think objattrs and tagattrs are largely interchangeable ... */
{
const result = document.createElement(name)
if (objattrs !== null)
{
for (const [name, value] of Object.entries(objattrs))
{
result[name] = value
} /*for*/
} /*if*/
if (tagattrs !== null && tagattrs !== undefined)
{
for (const [name, value] of Object.entries(tagattrs))
{
const attr = document.createAttribute(name)
attr.value = value
result.attributes.setNamedItem(attr)
} /*for*/
} /*if*/
if (children !== null)
{
for (const child of children)
{
result.appendChild(child)
} /*for*/
} /*if*/
if (parent !== null)
{
parent.appendChild(result)
} /*if*/
return result
} /*add_element*/
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.javascript

On 14/07/2026 23:12, Lawrence DrCOOliveiro wrote:

On Tue, 14 Jul 2026 10:50:33 +0100, John Harris wrote:

Incidentally, the history of semicolons in javascript is that a lot
of people scream loudly if semicolons aren't used, and just as many
scream loudly if they are. :-(

I think there are more that scream loudly if they arenrCOt ...

function add_element(parent, name, objattrs, tagattrs, children = null)
/* general routine for creating a new HTMLElement, initializing
attributes, and attaching it to a parent element and attaching
child elements, if specified. */
/* I think objattrs and tagattrs are largely interchangeable ... */
{
const result = document.createElement(name)
if (objattrs !== null)
{
for (const [name, value] of Object.entries(objattrs))
{
result[name] = value
} /*for*/
} /*if*/
if (tagattrs !== null && tagattrs !== undefined)
{
for (const [name, value] of Object.entries(tagattrs))
{
const attr = document.createAttribute(name)
attr.value = value
result.attributes.setNamedItem(attr)
} /*for*/
} /*if*/
if (children !== null)
{
for (const child of children)
{
result.appendChild(child)
} /*for*/
} /*if*/
if (parent !== null)
{
parent.appendChild(result)
} /*if*/
return result
} /*add_element*/

The people who loudly want semicolons want :-
a = 3;
b = "Yes"; // No semicolon would be a syntax error
c = 42;

John


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.javascript

Mikko wrote:

On 24/04/2025 04:52, Lawrence D'Oliveiro wrote:

Truthiness: yes, this is a pitfall, too. Languages should just take
the Pascal route and insist that conditions be of Boolean type.

Fortunatly conditions are usually in contexts that marks them as
conditions.

One problem with many program languages is that the program does not
identify the revision of the standard.

What do you mean by that?

This would be important with Javascript

There (still) is no "Javascript": <http://PointedEars.de/es-matrix>

[Granted, the feature list is not up-to-date anymore, and I am not sure if I will manage to update it -- I have so much else to deal with right now; but
the basic argument that I presented there is still correct.]

as the same program is intended for a large variety of
implementations that are not updated to the latest revision or are
aleady updated to a revision that is published after the publication
of the program.

In Javascript there is the pragma "use strict".

In ECMAScript Ed. 5 and later, therefore in implementations of that.

A similar pragma could be used to identify the revision expected to
be supported.

I think that you have a major misconception about ECMAScript and the
landscape of ECMAScript implementations.

In addition there should be a global constant or constants or function
that tells the revision acutally supported so that program can adapt to
what is available.

This is pointless because there is no implementtion that is fully compliant with any Edition of ECMAScript, and there are so many features that it is impossible to keep track of them. It is better to test the features that
one actually uses. And eventually one has to decide which syntactical constructs one uses, considering that every syntactical construct sacrifices
a bit of backwards compatibility.

The subject line means that Javascript already existed 30 years ago.

Not "Javascript", but (Netscape) JavaScript, literally.

In some sense that is false: the Javascript that we know today is
not the same as the Javascript 30 years ago.

You are the one who started with this false equivalence in the first place.

But it is true as much of what Javascript was 30 years ago

30 years ago the nonsensical term "Javascript" that was introduced by people who were either too lazy or too uninformed did not exist yet.

is still present in the moders Javascript.

You do not know what you are talking about. That probably comes from
reading books by people who also do not know what they are talking about but present themselves as "gurus", like John Resig.
--
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.javascript

Mikko wrote:

On 14/07/2026 01:31, Lawrence DrCOOliveiro wrote:

On Mon, 13 Jul 2026 16:12:42 +0300, Mikko wrote:

The subject line means that Javascript already existed 30 years ago.
In some sense that is false: the Javascript that we know today is
not the same as the Javascript 30 years ago.

So when did todayrCOs JavaScript come into being? How old would you say
it really was, if not 30 years?

One can say that every time the standard is updated it creates a new lanugage.

That is simply not so.

But often it is reasonable to say otherwise.

It is always reasonable to say otherwise.
--
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.javascript

On 18/07/2026 05:46, Thomas 'PointedEars' Lahn wrote:

Mikko wrote:

On 24/04/2025 04:52, Lawrence D'Oliveiro wrote:

Truthiness: yes, this is a pitfall, too. Languages should just take
the Pascal route and insist that conditions be of Boolean type.

Fortunatly conditions are usually in contexts that marks them as
conditions.

One problem with many program languages is that the program does not
identify the revision of the standard.

What do you mean by that?

That reading the program text does not reveal what revision of the
standard did the programmer or programmer's or tester's compiler
or interpreter use.

This would be important with Javascript

There (still) is no "Javascript": <http://PointedEars.de/es-matrix>

[Granted, the feature list is not up-to-date anymore, and I am not sure if I will manage to update it -- I have so much else to deal with right now; but the basic argument that I presented there is still correct.]

as the same program is intended for a large variety of
implementations that are not updated to the latest revision or are
aleady updated to a revision that is published after the publication
of the program.

In Javascript there is the pragma "use strict".

In ECMAScript Ed. 5 and later, therefore in implementations of that.

A similar pragma could be used to identify the revision expected to
be supported.

I think that you have a major misconception about ECMAScript and the landscape of ECMAScript implementations.

In addition there should be a global constant or constants or function
that tells the revision acutally supported so that program can adapt to
what is available.

This is pointless because there is no implementtion that is fully compliant with any Edition of ECMAScript, and there are so many features that it is impossible to keep track of them. It is better to test the features that
one actually uses. And eventually one has to decide which syntactical constructs one uses, considering that every syntactical construct sacrifices a bit of backwards compatibility.

The subject line means that Javascript already existed 30 years ago.

Not "Javascript", but (Netscape) JavaScript, literally.

That's false, the subject line did not say "Netscape JavaScript".

In some sense that is false: the Javascript that we know today is
not the same as the Javascript 30 years ago.

You are the one who started with this false equivalence in the first place.

No, it already was on the subject line.

But it is true as much of what Javascript was 30 years ago

30 years ago the nonsensical term "Javascript" that was introduced by people who were either too lazy or too uninformed did not exist yet.

The name was introduced with the release of Netsace Navigator in
December 1995.

is still present in the moders Javascript.

You do not know what you are talking about. That probably comes from
reading books by people who also do not know what they are talking about but present themselves as "gurus", like John Resig.

Much of what I said above is based on my experiences with various
programming languages, including old and new Javascript.
--
Mikko

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.javascript

On Sun, 19 Jul 2026 11:40:07 +0300, Mikko wrote:

Much of what I said above is based on my experiences with various
programming languages, including old and new Javascript.

You still havenrCOt said what you consider to be rCLoldrCY versus rCLnewrCY JavaScript.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.javascript

On 20/07/2026 02:29, Lawrence DrCOOliveiro wrote:

On Sun, 19 Jul 2026 11:40:07 +0300, Mikko wrote:

Much of what I said above is based on my experiences with various
programming languages, including old and new Javascript.

You still havenrCOt said what you consider to be rCLoldrCY versus rCLnewrCY JavaScript.

What was released 30 years ago is old. The current standard is new,
at least until the next revison.
--
Mikko
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.javascript

On Mon, 20 Jul 2026 09:42:55 +0300, Mikko wrote:

On 20/07/2026 02:29, Lawrence DrCOOliveiro wrote:

On Sun, 19 Jul 2026 11:40:07 +0300, Mikko wrote:

Much of what I said above is based on my experiences with various
programming languages, including old and new Javascript.

You still havenrCOt said what you consider to be rCLoldrCY versus rCLnewrCY >> JavaScript.

What was released 30 years ago is old. The current standard is new,
at least until the next revison.

If I understand you correctly, are you saying that everything prior to
the latest version (16th edition, from June 2025 as of this writing),
is rCLoldrCY?

So your idea of rCLnewrCY JavaScript can never be much more than about a
year old?

ThatrCOs fine. The rest of us will continue to refer to rCL30 years of JavaScriptrCY. You do you.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.javascript

On 20/07/2026 11:08, Lawrence DrCOOliveiro wrote:

On Mon, 20 Jul 2026 09:42:55 +0300, Mikko wrote:

On 20/07/2026 02:29, Lawrence DrCOOliveiro wrote:

On Sun, 19 Jul 2026 11:40:07 +0300, Mikko wrote:

Much of what I said above is based on my experiences with various
programming languages, including old and new Javascript.

You still havenrCOt said what you consider to be rCLoldrCY versus rCLnewrCY >>> JavaScript.

What was released 30 years ago is old. The current standard is new,
at least until the next revison.

If I understand you correctly, are you saying that everything prior to
the latest version (16th edition, from June 2025 as of this writing),
is rCLoldrCY?

Depends on what you are doing. For some pusposes it is best to use the
latest standard but often it is better to avoid the need to upgrade
customer's equipment.

So your idea of rCLnewrCY JavaScript can never be much more than about a
year old?

Sometimes old enough means at least ten years old.

ThatrCOs fine. The rest of us will continue to refer to rCL30 years of JavaScriptrCY. You do you.

Others may count the years. I con't care.
--
Mikko
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.javascript

On Tue, 21 Jul 2026 08:57:57 +0300, Mikko wrote:

On 20/07/2026 11:08, Lawrence DrCOOliveiro wrote:

On Mon, 20 Jul 2026 09:42:55 +0300, Mikko wrote:

What was released 30 years ago is old. The current standard is
new, at least until the next revison.

If I understand you correctly, are you saying that everything prior
to the latest version (16th edition, from June 2025 as of this
writing), is rCLoldrCY?

Depends on what you are doing.

ThatrCOs not what you said above. You said rCLthe current standard is
newrCY, and nothing else was.

ThatrCOs fine. The rest of us will continue to refer to rCL30 years of
JavaScriptrCY. You do you.

Others may count the years. I con't care.

Funny, didnrCOt you do exactly the same thing?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.javascript

On 22/07/2026 02:08, Lawrence DrCOOliveiro wrote:

On Tue, 21 Jul 2026 08:57:57 +0300, Mikko wrote:

On 20/07/2026 11:08, Lawrence DrCOOliveiro wrote:

On Mon, 20 Jul 2026 09:42:55 +0300, Mikko wrote:

What was released 30 years ago is old. The current standard is
new, at least until the next revison.

If I understand you correctly, are you saying that everything prior
to the latest version (16th edition, from June 2025 as of this
writing), is rCLoldrCY?

Depends on what you are doing.

ThatrCOs not what you said above. You said rCLthe current standard is
newrCY, and nothing else was.

The current standard is the newest there is. But I did not say that
nothing else was, I said that 30 years old is not.

ThatrCOs fine. The rest of us will continue to refer to rCL30 years of
JavaScriptrCY. You do you.

Others may count the years. I con't care.

Funny, didnrCOt you do exactly the same thing?

--
Mikko
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.javascript

Mikko wrote:
^^^^^
Your full name belongs there.

On 18/07/2026 05:46, Thomas 'PointedEars' Lahn wrote:

Mikko wrote:

On 24/04/2025 04:52, Lawrence D'Oliveiro wrote:

Truthiness: yes, this is a pitfall, too. Languages should just take
the Pascal route and insist that conditions be of Boolean type.

Fortunatly conditions are usually in contexts that marks them as
conditions.

One problem with many program languages is that the program does not
identify the revision of the standard.

What do you mean by that?

That reading the program text does not reveal what revision of the
standard did the programmer or programmer's or tester's compiler
or interpreter use.

[Source code written in ECMAScript implementations is _always_ compiled
first, but it is compiled JIT most of the time.]

It does to the well-educated and those who can use linters (when put to the test, ESLint is good at least at telling code that uses ES6+ syntactical features apart from code that does not; it is my preferred linter). For example, to the well-educated, the arrow function syntax cries out "implementation of ECMAScript Ed. 6 and later". So does an array literal *left-hand side*.

However, I agree that it is becoming increasingly difficult to tell. Based
on my ECMAScript Support Matrix, I have been working on, but never finished,
a tool that, given a piece of source code, can make an educated guess; but,
as I indicated, it is difficult to keep track now given that there is a new Edition of ECMAScript every year, and that one has to keep track of both new syntactical constructs and new built-in objects and properties.

However, as I have pointed out, it would be of little use to declare the Edition of the ECMAScript in the source code by a syntactical construct
because to my knowledge there is no full standards compliance in any implementation, and I doubt anybody is still able to keep track of it in
their head anyway. The tag would need to be constantly updated, and it
would be difficult to get it right (see above), but to the average developer
it would mean nothing.

As it is, if ECMAScript-based source code does not even compile in an implementation, but compiles in another, chances are is that it is using syntactical features that did not exist yet in the Edition of ECMAScript
that the compiler is based on (at least), and you can see that in the
compiler output (in Web browsers: in the Developer Console).

[irrelevant quotes]

You ought to trim your quotes to the relevant minimum.

The subject line means that Javascript already existed 30 years ago.

Not "Javascript", but (Netscape) JavaScript, literally.

That's false, the subject line did not say "Netscape JavaScript".

Context is important. To the well-educated the "JavaScript" in "30 Years Of JavaScript" *means* Netscape JavaScript because there was no other
programming language whose name contained that string of characters 30 years ago. This language, Netscape JavaScript 1.0, was not even an ECMAScript implementation yet because ECMAScript did not exist yet, as you can read in
my thesis and on my Web site:

<http://PointedEars.de/es-matrix/#ecmascript>

In some sense that is false: the Javascript that we know today is
not the same as the Javascript 30 years ago.

You are the one who started with this false equivalence in the first place.

No, it already was on the subject line.

Identifiers in ECMAScript implementations are case-sensitive ;-)

But it is true as much of what Javascript was 30 years ago

30 years ago the nonsensical term "Javascript" that was introduced by people >> who were either too lazy or too uninformed did not exist yet.

The name was introduced with the release of Netsace Navigator in
December 1995.

Netscape _JavaScript_ 1.0 was actually introduced with the release of _Netscape_-aNavigator _2.0_ in _March 1996_.

[I have been *there*, kid. Have you read my thesis/Web site yet?]

is still present in the moders Javascript.

You do not know what you are talking about. That probably comes from
reading books by people who also do not know what they are talking about but >> present themselves as "gurus", like John Resig.

Much of what I said above is based on my experiences with various
programming languages, including old and new Javascript.

You are living in a convenient fantasy world where there is an "old and new Javascript" (sic). There is no hope for you until you snap out of this wannabe-induced fever dream, and learn to appreciate both the chaos and the diversity of ECMAScript implementations :'-)
--
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.javascript

Mikko wrote:

On 20/07/2026 02:29, Lawrence DrCOOliveiro wrote:

On Sun, 19 Jul 2026 11:40:07 +0300, Mikko wrote:

Much of what I said above is based on my experiences with various
programming languages, including old and new Javascript.

You still havenrCOt said what you consider to be rCLoldrCY versus rCLnewrCY >> JavaScript.

What was released 30 years ago is old. The current standard is new,
at least until the next revison.

Utter nonsense.
--
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.
--- Synchronet 3.22a-Linux NewsLink 1.2