Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Trying to create array of object literals

227 views
Skip to first unread message

bit-n...@hotmail.com

unread,
Apr 12, 2018, 3:17:26 PM4/12/18
to
I have this in my code:

var point = {
x:0,
y:0
};


Now I want to build an array of the "point" array literal (ie. storing 3 points):

var projectedpoly = point[3];

So that I can do this:

document.write(projectedpoly[i].x);



But the "var projectedpoly = point[3]; " statement is not working, far as I can see - what must I do?

bit-n...@hotmail.com

unread,
Apr 12, 2018, 3:26:17 PM4/12/18
to
Oops I forgot to say: the document.write thing will actually be in a loop, like this:

for (var i=0; i<3; i++) {
document.write(projectedpoly[i].x);
}

Maik Koenig

unread,
Apr 12, 2018, 3:48:22 PM4/12/18
to
},
{
x:1,
y:1
},
{
x:2,
y:2
},
{
x:3,
y:3
}];
console.log (point[2].x); // 2



Greetz,
MK
--
Kopp-Verlag-Gläubige, Religionsdeppen, rechte Vollidioten
und ähnlicher Bio-Abfall werden ohne Hinweis ignoriert!
- Sei eine Möwe: Scheiss drauf -

Julio Di Egidio

unread,
Apr 12, 2018, 3:49:53 PM4/12/18
to
On Thursday, 12 April 2018 21:17:26 UTC+2, bit-n...@hotmail.com wrote:
> I have this in my code:
>
> var point = {
> x:0,
> y:0
> };
>
>
> Now I want to build an array of the "point" array literal (ie. storing 3
> points):

A way to define it "in place" is like this:

var points = [
{ x:0, y:0 },
{ x:1, y:1 },
{ x:2, y:2 }
];

> var projectedpoly = point[3];

The name is usually plural. Anyway, to the point, that just does not exist
in JS: <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array>

Julio

Thomas 'PointedEars' Lahn

unread,
Apr 13, 2018, 4:27:53 AM4/13/18
to
Stefan Ram wrote:

> bit-n...@hotmail.com writes:
>>var point = {
>>x:0,
>>y:0
>>};
>>Now I want to build an array of the "point" array literal (ie. storing 3
>>points):
>
> A literal is solely an entity of the source code model,
> literals are not run-time values.

Also, it is _not_ an Array literal, but an _Object_ literal/initialiser,
equivalent to:

var point = new Object();
point.x = 0;
point.y = 0;

IOW, in both cases “point” holds a reference to an Object instance; “x” and
“y” are the names of the *properties* of that object, and the zeroes are the
*property values*.

JavaScript/ECMAScript *basics* (and told to the anonymous, address-munging¹
OP several times before²).

________
¹ <http://www.interhack.net/pubs/munging-harmful/>
<https://tools.ietf.org/html/rfc5536#section-3.1.2>

² <http://www.catb.org/esr/faqs/smart-questions.html>

>>var projectedpoly = point[3];
>
> You might want:
>
> { const p = []; for( let i = 0; i < 3; ++i )p.push({ x: 0, y: 0 }); }

Readable:

{
const polygon = [];
for (let i = 0; i < 3; ++i)
{
polygon.push({x: 0, y: 0});
}
}

Probably closer to what was *really* being looked for:

var point1 = {x: 1, y: 2};
var point2 = {x: 3, y: 4};
var point3 = {x: 5, y: 6};
var polygon = [point1, point2, point3];

or (functionally equivalent)

var polygon = [
{x: 1, y: 2},
{x: 3, y: 4},
{x: 5, y: 6}
];

or (functionally equivalent)

function Point (x, y)
{
this.x = x;
this.y = y;
}

var point1 = new Point(1, 2);
var point2 = new Point(3, 4);
var point3 = new Point(5, 6);
var polygon = [point1, point2, point3];

or (functionally equivalent)

function Point (x, y)
{
this.x = x;
this.y = y;
}

var polygon = [
new Point(1, 2),
new Point(3, 4),
new Point(5, 6)
];

then

/* an Object instance equivalent to {x: 5, y: 6} */
var point = polygon[2];

Definining a point as an instance of a custom object type (“Point” is its
constructor) has the advantages that all point objects automatically have
the same structure, can have the same methods (this allows polymorphism),
and details of the implementation are hidden from the user of the object
(information hiding). [The properties are still publicly accessible
directly here, but that can be fixed.]

In that sense, “polygon” should be a reference to an instance of a custom
object type as well (there are operations that apply to all polygons).

<https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide>


In order to DRY,

var polygon = [
{x: 1, y: 2},
{x: 3, y: 4},
{x: 5, y: 6}
];

can be converted thus:

function Point (x, y)
{
/* When called as a function, work as factory (type conversion) */
if (!(this instanceof Point)) return new Point(x, y);

if (x instanceof Object)
{
/*
* Assume a reference to an object to be converted;
* this also allows Point({x: 42, y: 23}) instead of
* Point(42, 23), getting rid of the opaqueness of
* arguments, and the dependency on argument order.
*/
this.x = x.x;
this.y = x.y;
}
else
{
this.x = x;
this.y = y;
}
}

polygon = polygon.map(Point);

This approach is very useful when dealing with JSON, e.g.:

var data = `[
{"x": 1, "y": 2},
{"x": 3, "y": 4},
{"x": 5, "y": 6}
]`;

var points = JSON.parse(data).map(Point);

“points” now refers to an Array instance of references to Point instances
that are initialized with the values in the JSON (and could itself be passed
as an argument to, e.g., a Polygon constructor/factory).

--
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

John G Harris

unread,
Apr 13, 2018, 5:57:42 AM4/13/18
to
On Fri, 13 Apr 2018 10:27:44 +0200, Thomas 'PointedEars' Lahn
<Point...@web.de> wrote:


<snip>
>IOW, in both cases “point” holds a reference to an Object instance;
^^^^^^^^^
<snip>

Why describe values in a complicated way when there is a simpler
way, a way that is compatible with the ECMAScript Standard?

Say that each variable and property contains a pointer to its
current Value-structure. Other variables and properties can
point to the same Value-structure. Now it's easier to see why
the following fragment of code behaves the way it does :
a; // Where a.c exists, and a.c == 5
b = a; // Now also b.c == 5
b.c = 42; // Now a.c == 42 also!
// a and b share the same Value-structure (an object, here)

Also, with this description a megabyte primitive string can be an
argument in a function call efficiently. There is no need for the
argument value to be a copy of the long string. And no need for
this to be a special case in the implementation.

John

bit-n...@hotmail.com

unread,
Apr 13, 2018, 7:09:02 AM4/13/18
to
On Friday, April 13, 2018 at 1:57:53 PM UTC+5:30, Thomas 'PointedEars' Lahn >

> Also, it is _not_ an Array literal, but an _Object_ literal/initialiser,

Ahh yes, of course -sheepish grin- :) After the late night I had last night, my brain just wasn't functioning today... :)

Thomas 'PointedEars' Lahn

unread,
Apr 13, 2018, 5:38:57 PM4/13/18
to
John G Harris wrote:

> On Fri, 13 Apr 2018 10:27:44 +0200, Thomas 'PointedEars' Lahn
> <Point...@web.de> wrote:

Again: Attribution _line_, not attribution novel.

>> IOW, in both cases “point” holds a reference to an Object instance;
> ^^^^^^^^^
>
> Why describe values in a complicated way when there is a simpler
> way, a way that is compatible with the ECMAScript Standard?
>
> Say that each variable and property contains a pointer to its
> current Value-structure. […]

That "simpler" way is _not_ compatible with whatever you think "the
ECMAScript Standard" is. *No* Edition of the ECMAScript Language
Specification (so far) specifies such *implementation* details.

John G Harris

unread,
Apr 14, 2018, 6:22:37 AM4/14/18
to
On Fri, 13 Apr 2018 23:38:49 +0200, Thomas 'PointedEars' Lahn
<Point...@web.de> wrote:

>John G Harris wrote:
>
>> On Fri, 13 Apr 2018 10:27:44 +0200, Thomas 'PointedEars' Lahn
>> <Point...@web.de> wrote:
>
>Again: Attribution _line_, not attribution novel.
>
>>> IOW, in both cases ?point? holds a reference to an Object instance;
>> ^^^^^^^^^
>>
>> Why describe values in a complicated way when there is a simpler
>> way, a way that is compatible with the ECMAScript Standard?
>>
>> Say that each variable and property contains a pointer to its
>> current Value-structure. [匽

On writing
> something [Remark]
a sensible person would notice that it is ambiguous. Was Remark
written by the person quoted, or by the person doing the quoting?
A sensible person would then use a scheme that does not have this
serious design flaw, such as
> something
[Your remark here]
> something else


>That "simpler" way is _not_ compatible with whatever you think "the
>ECMAScript Standard" is. *No* Edition of the ECMAScript Language
>Specification (so far) specifies such *implementation* details.

What an amazingly silly remark. *Obviously*, 'pointer' is an
implementation detail. Equally obviously, so is 'reference'. The
difference is that 'reference' gives a thouroughly misleading
description of the ECMAScript language's semantics.

John

Julio Di Egidio

unread,
Apr 14, 2018, 10:25:21 AM4/14/18
to
On Saturday, 14 April 2018 12:22:37 UTC+2, John G Harris wrote:
> On Fri, 13 Apr 2018 23:38:49 +0200, Thomas 'PointedEars' Lahn
> <Point...@web.de> wrote:
<snip>
> >That "simpler" way is _not_ compatible with whatever you think "the
> >ECMAScript Standard" is. *No* Edition of the ECMAScript Language
> >Specification (so far) specifies such *implementation* details.
>
> What an amazingly silly remark. *Obviously*, 'pointer' is an
> implementation detail. Equally obviously, so is 'reference'. The
> difference is that 'reference' gives a thouroughly misleading
> description of the ECMAScript language's semantics.

There are no pointers in JS, not even near. And a reference is not a pointer,
and no, a reference is not an implementation detail. You have it upside down.

Julio

Julio Di Egidio

unread,
Apr 14, 2018, 12:09:44 PM4/14/18
to
On Saturday, 14 April 2018 16:25:21 UTC+2, Julio Di Egidio wrote:
> On Saturday, 14 April 2018 12:22:37 UTC+2, John G Harris wrote:
> > On Fri, 13 Apr 2018 23:38:49 +0200, Thomas 'PointedEars' Lahn
> > <Point...@web.de> wrote:
> <snip>
> > >That "simpler" way is _not_ compatible with whatever you think "the
> > >ECMAScript Standard" is. *No* Edition of the ECMAScript Language
> > >Specification (so far) specifies such *implementation* details.
> >
> > What an amazingly silly remark. *Obviously*, 'pointer' is an
> > implementation detail. Equally obviously, so is 'reference'. The
> > difference is that 'reference' gives a thouroughly misleading
> > description of the ECMAScript language's semantics.
>
> There are no pointers in JS, not even near.

JS is a *functional* language: the modularity is modularity of *lexical*
constructs and contexts... (Someone else might be able to say it better.)

John G Harris

unread,
Apr 16, 2018, 4:43:44 AM4/16/18
to
On Sat, 14 Apr 2018 09:09:36 -0700 (PDT), Julio Di Egidio
<ju...@diegidio.name> wrote:


<snip>
>JS is a *functional* language: the modularity is modularity of *lexical*
>constructs and contexts... (Someone else might be able to say it better.)
<snip>

What has this to do with the question of whether or not the value of a
variable can be an object?

John

John G Harris

unread,
Apr 16, 2018, 5:02:57 AM4/16/18
to
On Sat, 14 Apr 2018 07:25:13 -0700 (PDT), Julio Di Egidio
<ju...@diegidio.name> wrote:

>On Saturday, 14 April 2018 12:22:37 UTC+2, John G Harris wrote:
>> On Fri, 13 Apr 2018 23:38:49 +0200, Thomas 'PointedEars' Lahn
>> <Point...@web.de> wrote:
><snip>
>> >That "simpler" way is _not_ compatible with whatever you think "the
>> >ECMAScript Standard" is. *No* Edition of the ECMAScript Language
>> >Specification (so far) specifies such *implementation* details.
>>
>> What an amazingly silly remark. *Obviously*, 'pointer' is an
>> implementation detail. Equally obviously, so is 'reference'. The
>> difference is that 'reference' gives a thouroughly misleading
>> description of the ECMAScript language's semantics.
>
>There are no pointers in JS, not even near.

You are saying that the machine instructions when a program is
executing *never* have a register or field containing the address of
another field ?

I don't believe you.

And, by the way, this news group is about ES; it is not restricted to
just JS.


>And a reference is not a pointer,
>and no, a reference is not an implementation detail. You have it upside down.

You'll have to tell us what you mean by 'reference'. An ECMAScript
reference is a tuple, often consisting of an object, a string, and a
flag. It cannot be returned by a function, and is obviously not what
you are talking about. Are you sure you are using the same
non-ECMAScript meaning as Thomas?

Julio Di Egidio

unread,
Apr 16, 2018, 5:04:39 AM4/16/18
to
What has that to do with my "There are no pointers"? Snip, deny and repeat?

Julio

Julio Di Egidio

unread,
Apr 16, 2018, 5:05:54 AM4/16/18
to
On Monday, 16 April 2018 11:02:57 UTC+2, John G Harris wrote:
> On Sat, 14 Apr 2018 07:25:13 -0700 (PDT), Julio Di Egidio
<snip>
> > There are no pointers in JS, not even near.
>
> You are saying that the machine instructions when a program is
> executing *never* have a register or field containing the address of
> another field ?

You are conflating JS with the implementation of a JS runtime.

Julio

Evertjan.

unread,
Apr 16, 2018, 5:23:17 AM4/16/18
to
John G Harris <ni...@jghnorth.org.uk.invalid> wrote on 16 Apr 2018 in
comp.lang.javascript:
That would stretch the meaning of 'value'.

JS variables and constants can
1 have numeric or string 'values'.
2 be a 'pointer' to an object.

More than one variable can point to the same object,
so we cannot externally identify such object by a specific name.
so perhaps say that the "pointer value" is hidden to the programmer.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

Evertjan.

unread,
Apr 16, 2018, 5:27:37 AM4/16/18
to
Julio Di Egidio <ju...@diegidio.name> wrote on 16 Apr 2018 in
comp.lang.javascript:

> You are conflating JS with the implementation of a JS runtime.

There is nothing wrong with such flatulence.

Would you say that unimplemented runtimes can exist?

Julio Di Egidio

unread,
Apr 16, 2018, 5:33:59 AM4/16/18
to
On Monday, 16 April 2018 11:27:37 UTC+2, Evertjan. wrote:

> Would you say that unimplemented runtimes can exist?

It's two different things, not that it does not exist: the fact that you write
a JS runtime and implement closures and stuff using C++ and pointers and memory
allocations is totally separate issue from what the JS language is.

Julio

Evertjan.

unread,
Apr 16, 2018, 8:03:47 AM4/16/18
to
Julio Di Egidio <ju...@diegidio.name> wrote on 16 Apr 2018 in
comp.lang.javascript:

You cannot "write a JS runtime".

John G Harris

unread,
Apr 16, 2018, 2:32:52 PM4/16/18
to
On Mon, 16 Apr 2018 11:23:13 +0200, "Evertjan."
<exxjxw.h...@inter.nl.net> wrote:

>John G Harris <ni...@jghnorth.org.uk.invalid> wrote on 16 Apr 2018 in
>comp.lang.javascript:
>
>> On Sat, 14 Apr 2018 09:09:36 -0700 (PDT), Julio Di Egidio
>> <ju...@diegidio.name> wrote:
>>
>>
>> <snip>
>>>JS is a *functional* language: the modularity is modularity of *lexical*
>>>constructs and contexts... (Someone else might be able to say it better.)
>> <snip>
>>
>> What has this to do with the question of whether or not the value of a
>> variable can be an object?
>
>That would stretch the meaning of 'value'.
>
>JS variables and constants can
>1 have numeric or string 'values'.
>2 be a 'pointer' to an object.

Now explain why ECMA 262, the ECMAScript standard, says

"An ECMAScript language type corresponds to values that are directly
manipulated by an ECMAScript programmer using the ECMAScript
language."

and

"The ECMAScript language types are Undefined, Null, Boolean, String,
Symbol, Number, and Object."

and

"An ECMAScript language value is a value that is characterized by an
ECMAScript language type."

Tell me why you think "characterized by" means "sometimes a pointer
to".


>More than one variable can point to the same object,
>so we cannot externally identify such object by a specific name.
>so perhaps say that the "pointer value" is hidden to the programmer.

And I have demonstrated that there is another implementation that does
the same without needing the value field/structure to be a pointer.

John

John G Harris

unread,
Apr 16, 2018, 2:37:46 PM4/16/18
to
No I'm not. I'm talking about implementations of ES. 99.999999% of
them will use pointers, e.g to point to newly allocated free store.

John G Harris

unread,
Apr 16, 2018, 2:40:43 PM4/16/18
to
And what the ES language is is one that does not have programmable
pointers and does not have programmable references (for any reasonable
definition of 'reference').

Julio Di Egidio

unread,
Apr 16, 2018, 2:48:32 PM4/16/18
to
That's still your JS *runtime* implementation and not the JS language itself.
You really do not see the difference? That a compiler or interpreter needn't
be written in the same language that they process? Meanwhile, and funnily
enough, you are the one who has claimed that one needn't use a language with
pointers and similar to implement a compiler or a runtime: which is correct.

*Plonk*

Julio

John G Harris

unread,
Apr 17, 2018, 4:45:48 AM4/17/18
to
On 16 Apr 2018 20:42:08 GMT, r...@zedat.fu-berlin.de (Stefan Ram)
wrote:

>John G Harris <ni...@jghnorth.org.uk.invalid> writes:
>>And what the ES language is is one that does not have programmable
>>pointers and does not have programmable references (for any reasonable
>>definition of 'reference').
>
> »A Reference is a resolved name or property binding.
>
> A Reference consists of three components,
> the base value component, the referenced name component,
> and the Boolean-valued strict reference flag.«
>
> ECMA-262 8th Edition / June 2017, 6.2.4
<snip>

That's what I called an ECMAScript reference. It's not something that
you can manipulate with your ES program, and it's not something that
can be the value of a variable or property. It's something that is
(notionally) created and used during the execution of certain
operations, such as assignment.

Unfortunately, Thomas and co are using 'reference' to mean something
else, and screaming at people who don't use the word.

John

John G Harris

unread,
Apr 17, 2018, 4:52:35 AM4/17/18
to
On Mon, 16 Apr 2018 11:48:26 -0700 (PDT), Julio Di Egidio
<ju...@diegidio.name> wrote:

<snip>
>That's still your JS *runtime* implementation and not the JS language itself.

I say I'm talking about implementation and you say no, you are talking
about implementation, then I say I'm talking about implementation and
you say no, you are talking about implementation, ...

>You really do not see the difference?
<snip>
>*Plonk*

Thank goodness you've plonked. No more criticising me for saying what
you say I ought to say.

John

Julio Di Egidio

unread,
Apr 17, 2018, 6:22:44 AM4/17/18
to
On Tuesday, 17 April 2018 10:52:35 UTC+2, John G Harris wrote:
> On Mon, 16 Apr 2018 11:48:26 -0700 (PDT), Julio Di Egidio
> <ju...@diegidio.name> wrote:
> <snip>
> >That's still your JS *runtime* implementation and not the JS language itself.
>
> I say I'm talking about implementation and you say no, you are talking
> about implementation, then I say I'm talking about implementation and
> you say no, you are talking about implementation, ...

Incompetent and liar.

*Plonk*

Julio

John G Harris

unread,
Apr 17, 2018, 1:28:09 PM4/17/18
to
On Tue, 17 Apr 2018 03:22:17 -0700 (PDT), Julio Di Egidio
<ju...@diegidio.name> wrote:

>On Tuesday, 17 April 2018 10:52:35 UTC+2, John G Harris wrote:
>> On Mon, 16 Apr 2018 11:48:26 -0700 (PDT), Julio Di Egidio
>> <ju...@diegidio.name> wrote:
>> <snip>
>> >That's still your JS *runtime* implementation and not the JS language itself.
>>
>> I say I'm talking about implementation and you say no, you are talking
>> about implementation, then I say I'm talking about implementation and
>> you say no, you are talking about implementation, ...
>
>Incompetent and liar.
>
>*Plonk*

All right, you insist on talking about the ES language so here goes :

In ES the values of variables and properties can NOT be references nor
can they be pointers nor can they be anything resembling references or
pointers.

Does that conform to your rules for what people can talk about here ?

John

Evertjan.

unread,
Apr 17, 2018, 5:37:54 PM4/17/18
to
John G Harris <ni...@jghnorth.org.uk.invalid> wrote on 16 Apr 2018 in
comp.lang.javascript:

> On Mon, 16 Apr 2018 11:23:13 +0200, "Evertjan."
> <exxjxw.h...@inter.nl.net> wrote:
>
>>John G Harris <ni...@jghnorth.org.uk.invalid> wrote on 16 Apr 2018 in
>>comp.lang.javascript:
>>
>>> On Sat, 14 Apr 2018 09:09:36 -0700 (PDT), Julio Di Egidio
>>> <ju...@diegidio.name> wrote:
>>>
>>>
>>> <snip>
>>>>JS is a *functional* language: the modularity is modularity of
>>>>*lexical* constructs and contexts... (Someone else might be able to
>>>>say it better.)
>>> <snip>
>>>
>>> What has this to do with the question of whether or not the value of a
>>> variable can be an object?
>>
>>That would stretch the meaning of 'value'.
>>
>>JS variables and constants can
>>1 have numeric or string 'values'.
>>2 be a 'pointer' to an object.
>
> Now explain why ECMA 262, the ECMAScript standard, says

Will you stop ordering others what to do.

I am a JS user, not the writer of a standard, so ask them.

> "An ECMAScript language type corresponds to values that are directly
> manipulated by an ECMAScript programmer using the ECMAScript
> language."
>
> and
>
> "The ECMAScript language types are Undefined, Null, Boolean, String,
> Symbol, Number, and Object."
>
> and
>
> "An ECMAScript language value is a value that is characterized by an
> ECMAScript language type."
>
> Tell me why you think "characterized by" means "sometimes a pointer
> to".

Will you stop ordering others what to do.

If you disagree with an argument, give a better one.

>>More than one variable can point to the same object,
>>so we cannot externally identify such object by a specific name.
>>so perhaps say that the "pointer value" is hidden to the programmer.
>
> And I have demonstrated that there is another implementation that does
> the same without needing the value field/structure to be a pointer.

C++?

I don't hold "the value field/structure to be a pointer",
I don't even think in "value field/structures",
but in the JS meaning of contant and variable names.

Thomas 'PointedEars' Lahn

unread,
Apr 17, 2018, 9:25:46 PM4/17/18
to
Stefan Ram wrote:

> John G Harris <ni...@jghnorth.org.uk.invalid> writes:
>> And what the ES language is is one that does not have programmable
>> pointers and does not have programmable references (for any reasonable
^^^^^^^^^^^^
>> definition of 'reference').

By that statement, John G Harris has solidly *refuted* their own ridiculous
claim. Congratulations.

ECMAScript is not an actual programming language in the sense that you can
write computer programs in it. It is a standard for programming languages
that requires implementation, and you can write computer programs in
implementations of ECMAScript. When we speak for brevity of ECMAScript as
if it were a programming language (instead of a standard for them), we
actually implicitly mean *strict* *implementations* of ECMAScript.

> »A Reference is a resolved name or property binding.

Note the marked word. This is _not_ what “reference” means when talking
about ECMAScript *implementations*.

Instead, as the anti-socially address-munging John G Harris *knows*, but
trollingly pretends not to know *every* *single* *time*, it means
“reference” as in object-oriented programming languages in general, which
is related to garbage collection.

[For those reasons and others, I have John G Harris in my killfile;
I respond to his baits only occasionally, so that he cannot confuse
beginners with his half-wit nonsense.]

After an object has been constructed, it can only be accessed by the program
through a *reference* to it, by which we (reasonable people) simply mean
*“a conceptual entity that refers to something”*.

There can be multiple references (with the same value) referring to the same
object. An object can be garbage-collected (after a potential destructor
has been called to release resources used by the object¹): the memory
reserved for its data can be “freed”, to be reservable again for other
data/objects, if there are no more references to it, because then the
program cannot access it anymore anyway. (This wording and similar ones can
be found in every description of garbage collection.)

> [tl;dr]

_______
¹ ECMAScript has no built-in concept of a destructor (yet). In ECMAScript
implementations, a destructor to release resources has to be called
explicitly, by the programmer. However, many public APIs usable with
ECMAScript implementations are usually designed so that resources are
automatically released, e.g. the handles for “File”s are closed.

John G Harris

unread,
Apr 18, 2018, 10:51:14 AM4/18/18
to
On Wed, 18 Apr 2018 03:25:38 +0200, Thomas 'PointedEars' Lahn
<Point...@web.de> wrote:

<snip>
>ECMAScript is not an actual programming language in the sense that you can
>write computer programs in it. It is a standard for programming languages
>that requires implementation, and you can write computer programs in
>implementations of ECMAScript.

Thomas has turned into a raving lunatic. He is saying that ECMAScript,
C, COBOL, Pascal, and Algol are not programming languages because they
have international standards!


<snip>
>This is _not_ what “reference” means when talking
>about ECMAScript *implementations*.

Says Thomas, as though there is world-wide agreement on this.


<snip>
>*every* *single* *time*, it means
>“reference” as in object-oriented programming languages in general,

Except, of course, C++, where a reference is defined to be an alias.


>which
>is related to garbage collection.

A conforming implementation of the ECMAScript standard does not have
to implement a garbage collector. Garbage collection is mentioned only
in two non-normative notes. (Says Acrobat's Search.)


<snip>
>After an object has been constructed, it can only be accessed by the program
>through a *reference* to it, by which we (reasonable people) simply mean
>*“a conceptual entity that refers to something”*.

Thomas can't get his head around the idea that there is more than one
way to implement the standard. He insists that the pointer to an
object is named 'value' and definately not named 'pointer to value'.
(I'm using "pointer" to mean anything that can do the job of Thomas's
references.)

That's why I insist that it is totally wrong to shout at people for
saying that the value of a variable is an object.

John

John G Harris

unread,
Apr 18, 2018, 11:08:07 AM4/18/18
to
On Wed, 18 Apr 2018 03:25:38 +0200, Thomas 'PointedEars' Lahn
<Point...@web.de> wrote:

<snip>
>Instead, as the anti-socially address-munging John G Harris

My headers include a Reply-To: header which contains a working
address. Therefore the From: header, snipped here, is irrelevant.

Incidentally, if you use the Reply-To: address be aware that your
e-mail must conform to the laws of the State of California and the
Federal laws of the USA, say the T&Cs.


>*knows*, but
>trollingly pretends not to know *every* *single* *time*, it means
>“reference” as in object-oriented programming languages in general,
<snip>

Is that supposed to be the definition of "reference" as used by
Thomas?


> [For those reasons and others, I have John G Harris in my killfile;
> I respond to his baits only occasionally, so that he cannot confuse
> beginners with his half-wit nonsense.]
<snip>

More accurately, Thomas doesn't approve of me pointing out that he is
sometimes wrong. One of his problems is that he is not very good at
noticing flaws in his proposed designs, and insists that no-one is
allowed to differ.

John

John G Harris

unread,
Apr 18, 2018, 11:18:34 AM4/18/18
to
On Tue, 17 Apr 2018 23:37:47 +0200, "Evertjan."
<exxjxw.h...@inter.nl.net> wrote:

<snip>
>Will you stop ordering others what to do.
<snip>

Does that mean that a polite request would get a proper reply?


>I don't hold "the value field/structure to be a pointer",
>I don't even think in "value field/structures",
>but in the JS meaning of contant and variable names.

Ah, you are talking denotational semantics, as in :

x denotes an object
y denotes a long string
z denotes false

Or do you prefer :

x denotes a pointer to an object
y denotes a pointer to a long string
z denotes false


John
Message has been deleted

Thomas 'PointedEars' Lahn

unread,
Apr 18, 2018, 9:25:47 PM4/18/18
to
Stefan Ram wrote:

> http://www.purl.org/stefan_ram/pub/zuweisungswirkung_javascript
>
> . That section contains a simplified analysis of the
> mechanics of assignment to a global name in JavaScript
> using JavaScript's concept of a reference (simplified).

[The referred article is in German, which is my native language.]

Unfortunately unsurprisingly, that article is *factually* *wrong* in many
ways. Indeed, is is that strewn with misconceptions using ad-hoc invented
fantasy terminology (such as „globale Einträge“ “global entries” and „Echte
Eintragsausdrücke“ “true entry-expressions”) that it would be faster to say
what is remotely right in it than what is wrong. It is a complete waste of
time to read it, except maybe as yet another example of
<https://www.crockford.com/javascript/javascript.html>.

For example,

(a = 3 + 4) - 2 === 5

_not_ because a === 7 would be the "effect" („Wirkung“) of the assignment as
the author believes and wants us to believe, but because the *evaluation
result* of the *right-hand* side of an assignment operation is its
evaluation *result* (see ES 2017, § 12.15.4 [1]; note that it says “Return
*rval*”, and has *always* said something to that effect).

The right-hand side here is the expression “3 + 4” whose evaluation result
is “7”. So *that* is the result of the assignment expression.

The entire expression is evaluated as follows:

1. (a = (3 + 4)) - 2 === 5
2. (a = 7) - 2 === 5
3. 7 - 2 === 5
4. 5 === 5
5. true

And _not_:

1. (a = (3 + 4)) - 2 === 5
2. (a = 7) - 2 === 5
3. a - 2 === 5
4. 7 - 2 === 5
5. 5 === 5
6. true

As I have explained before (here and in de.comp.lang.javascript),
this difference may be subtle, but it is important. For example:

/* Afterwards, “o” refers to an object with a read-only “a” property */
var o = Object.create(null, {a: {value: 42}});

/* in non-strict mode */
/* true */
console.log((o.a = 3 + 4) - 2 === 5);

/* false; contrary to what one might intuitively expect */
console.log((o.a = 3 + 4) - 2 === 40);

BTW, this behavior is true of other programming languages as well.
(Why that is so, I actually do not know.)


[1] <http://www.ecma-international.org/ecma-262/8.0/#sec-assignment-operators-runtime-semantics-evaluation>

Thomas 'PointedEars' Lahn

unread,
Apr 18, 2018, 9:34:19 PM4/18/18
to
John G Harris wrote:

> On Wed, 18 Apr 2018 03:25:38 +0200, Thomas 'PointedEars' Lahn
> <Point...@web.de> wrote:
>
> <snip>
>>Instead, as the anti-socially address-munging John G Harris
>
> My headers include a Reply-To: header which contains a working
> address. Therefore the From: header, snipped here, is irrelevant.
>
> Incidentally, if you use the Reply-To: address be aware that your
> e-mail must conform to the laws of the State of California and the
> Federal laws of the USA, say the T&Cs.

You have not the slightest idea what you are blathering about.

<http://www.eternal-september.org/index.php?showpage=terms>

(The allowance of this/your Usenet provider or any other person for
.invalid in the “From” does not make it any less anti-social.)

John G Harris

unread,
Apr 19, 2018, 5:38:01 AM4/19/18
to
On Thu, 19 Apr 2018 03:34:12 +0200, Thomas 'PointedEars' Lahn
<Point...@web.de> wrote:

>John G Harris wrote:
>
>> On Wed, 18 Apr 2018 03:25:38 +0200, Thomas 'PointedEars' Lahn
>> <Point...@web.de> wrote:
>>
>> <snip>
>>>Instead, as the anti-socially address-munging John G Harris
>>
>> My headers include a Reply-To: header which contains a working
>> address. Therefore the From: header, snipped here, is irrelevant.
>>
>> Incidentally, if you use the Reply-To: address be aware that your
>> e-mail must conform to the laws of the State of California and the
>> Federal laws of the USA, say the T&Cs.
>
>You have not the slightest idea what you are blathering about.
>
><http://www.eternal-september.org/index.php?showpage=terms>
>
>(The allowance of this/your Usenet provider or any other person for
>.invalid in the “From” does not make it any less anti-social.)

How can it be anti-social when eternal-september permits email
addresses I own and permits the addition of .invalid, and it's an
address you are not permitted to use anyway ? For goodness sake, it's
not there to uniquely identify a person, it's there to facilitate
communication, which is what Reply-To is for.

John

John G Harris

unread,
Apr 19, 2018, 2:02:49 PM4/19/18
to
On Wed, 18 Apr 2018 03:25:38 +0200, Thomas 'PointedEars' Lahn
<Point...@web.de> wrote:

<snip>
>ECMAScript is not an actual programming language in the sense that you can
>write computer programs in it. It is a standard for programming languages
>that requires implementation, and you can write computer programs in
>implementations of ECMAScript. When we speak for brevity of ECMAScript as
>if it were a programming language (instead of a standard for them), we
>actually implicitly mean *strict* *implementations* of ECMAScript.
<snip>

There is a flaw in that argument. First, ECMA-262's title is
"ECMAScript 2017 Language Specification"
not
"Standard for programming languages".

Second, ECMA-262 is extremely detailed. As a result, any source text
that obeys the ECMA-262 rules will do the same things in any
conforming product. So which language is the source text written in?
Does it have a name? Is the name one product's implementation? Surely
the only sensible answer is that it is an ECMAScript program written
in the ECMAScript language, even if it never goes near a conforming
product.

Third, if the language resides in each conforming product then every
web site's home page should declare
"This site can be viewed with browser " ... .
Ugh!

John

Evertjan.

unread,
Apr 19, 2018, 5:08:54 PM4/19/18
to
John G Harris <ni...@jghnorth.org.uk.invalid> wrote on 18 Apr 2018 in
comp.lang.javascript:

> On Tue, 17 Apr 2018 23:37:47 +0200, "Evertjan."
> <exxjxw.h...@inter.nl.net> wrote:
>
> <snip>
>>Will you stop ordering others what to do.
> <snip>
>
> Does that mean that a polite request would get a proper reply?

No, it does not, the end of impoliteness does not buy cooperation.



>>I don't hold "the value field/structure to be a pointer",
>>I don't even think in "value field/structures",
>>but in the JS meaning of contant and variable names.
>
> Ah, you are talking denotational semantics, as in :
>
> x denotes an object
> y denotes a long string
> z denotes false

Not at all, I describe JS implementation.

> Or do you prefer :
>
> x denotes a pointer to an object
> y denotes a pointer to a long string
> z denotes false

See, again you are narrowing another down to choose from your views,
only a slightly better form of ordering.

John G Harris

unread,
Apr 20, 2018, 5:17:13 AM4/20/18
to
On Thu, 19 Apr 2018 23:08:46 +0200, "Evertjan."
<exxjxw.h...@inter.nl.net> wrote:

>John G Harris <ni...@jghnorth.org.uk.invalid> wrote on 18 Apr 2018 in
>comp.lang.javascript:
>
>> On Tue, 17 Apr 2018 23:37:47 +0200, "Evertjan."
>> <exxjxw.h...@inter.nl.net> wrote:
<snip>
>>>I don't hold "the value field/structure to be a pointer",
>>>I don't even think in "value field/structures",
>>>but in the JS meaning of contant and variable names.
>>
>> Ah, you are talking denotational semantics, as in :

In case it wasn't clear : the "meaning of contant and variable names"
is what denotational semantics defines.


>> x denotes an object
>> y denotes a long string
>> z denotes false
>
>Not at all, I describe JS implementation.

There is more than one possible implementation. Are you describing
your preferred implementation? Or were you not aware of alternatives?
Or do you prefer to be a dictator?


>> Or do you prefer :
>>
>> x denotes a pointer to an object
>> y denotes a pointer to a long string
>> z denotes false
>
>See, again you are narrowing another down to choose from your views,
>only a slightly better form of ordering.

You've said earlier that x means pointer to object. Are you saying you
don't approve of these meanings of y and z?

John

Evertjan.

unread,
Apr 20, 2018, 6:45:28 AM4/20/18
to
John G Harris <ni...@jghnorth.org.uk.invalid> wrote on 20 Apr 2018 in
comp.lang.javascript:

> On Thu, 19 Apr 2018 23:08:46 +0200, "Evertjan."
> <exxjxw.h...@inter.nl.net> wrote:
>
>>John G Harris <ni...@jghnorth.org.uk.invalid> wrote on 18 Apr 2018 in
>>comp.lang.javascript:
>>
>>> On Tue, 17 Apr 2018 23:37:47 +0200, "Evertjan."
>>> <exxjxw.h...@inter.nl.net> wrote:
> <snip>
>>>>I don't hold "the value field/structure to be a pointer",
>>>>I don't even think in "value field/structures",
>>>>but in the JS meaning of contant and variable names.
>>>
>>> Ah, you are talking denotational semantics, as in :
>
> In case it wasn't clear : the "meaning of contant and variable names"
> is what denotational semantics defines.
>
>
>>> x denotes an object
>>> y denotes a long string
>>> z denotes false
>>
>>Not at all, I describe JS implementation.
>
> There is more than one possible implementation.

That's why I wrote "JS implementation"
not "THE JS implementation".

> Are you describing
> your preferred implementation?

No.

> Or were you not aware of alternatives?

See, again you are in the limiting mode.

> Or do you prefer to be a dictator?

You are acting silly.

This is a discussion, try to take arguments on their value.

>>> Or do you prefer :
>>>
>>> x denotes a pointer to an object
>>> y denotes a pointer to a long string
>>> z denotes false
>>
>>See, again you are narrowing another down to choose from your views,
>>only a slightly better form of ordering.
>
> You've said earlier that x means pointer to object.

I did not use x.

> Are you saying you
> don't approve of these meanings of y and z?

Why would you think that?

I did not use y and z.

John G Harris

unread,
Apr 20, 2018, 2:08:51 PM4/20/18
to
On Fri, 20 Apr 2018 12:45:22 +0200, "Evertjan."
<exxjxw.h...@inter.nl.net> wrote:

>John G Harris <ni...@jghnorth.org.uk.invalid> wrote on 20 Apr 2018 in
>comp.lang.javascript:
>
>> On Thu, 19 Apr 2018 23:08:46 +0200, "Evertjan."
>> <exxjxw.h...@inter.nl.net> wrote:
>>
>>>John G Harris <ni...@jghnorth.org.uk.invalid> wrote on 18 Apr 2018 in
>>>comp.lang.javascript:
>>>
>>>> On Tue, 17 Apr 2018 23:37:47 +0200, "Evertjan."
>>>> <exxjxw.h...@inter.nl.net> wrote:

<snip>
>>>>>I don't even think in "value field/structures",
>>>>>but in the JS meaning of contant and variable names.
<snip>

>This is a discussion, try to take arguments on their value.
<snip>

But you said you don't think about value!

John

(And yes, I am writing in the style of Evertjan)

c.l.js

unread,
Apr 20, 2018, 4:04:40 PM4/20/18
to
Julio Di Egidio babbled:
> JS is a *functional* language: the modularity is modularity of *lexical*
> constructs and contexts... (Someone else might be able to say it better.)
>

Yes, JavaScript is a "functional" language. Here is an example:

class Moron {
constructor(name) {
this.name = name;
}
speak() {
alert(`${this.name} says:
"JS is a functional language."`);
}
}

var Julio = new Moron('Julio');
Julio.speak();

Try using npm to install a brain in your head. LOL

Julio Di Egidio

unread,
Apr 20, 2018, 4:15:21 PM4/20/18
to
You try getting your head out of your ass: the JS standard is poorly written,
and they are indeed making it worse, but only the truly incompetent trips on
some poor labelling. That said, you piece of shit learn some education, too.

*Plonk*

Julio

Thomas 'PointedEars' Lahn

unread,
Apr 20, 2018, 11:28:00 PM4/20/18
to
c.l.js wrote:
^^^^^^
It ill-behoves you, having so little knowledge about what you are talking
about, to claim to speak for the entire newsgroup, and the address part of
the “From” header of your posting is a violation of Internet standards
(RFC 5536).

You do not want anyone to report you for network abuse, do you?

> Julio Di Egidio babbled:
>> JS is a *functional* language: the modularity is modularity of *lexical*
>> constructs and contexts... (Someone else might be able to say it
>> better.)

Modularity is not the key property of a functional programming language.

> Yes, JavaScript is a "functional" language. Here is an example:
>
> class Moron {
> constructor(name) {
> this.name = name;
> }
> speak() {
> alert(`${this.name} says:
> "JS is a functional language."`);
> }
> }

Note that the “speak” method of the “Moron” class is implemented as an
*object*, a *Function* *instance*.

Note also that this does not work in several earlier implementations of
ECMAScript, where you have to write

function Moron (name)
{
this.name = name;
}

Moron.prototype.speak = function () {
window.alert(this.name
+ ' says: "JS is not a functional programming language."');
};

(new Moron('The troll posting as "c.l.js"')).speak();

or something to that effect, instead.

> var Julio = new Moron('Julio');
> Julio.speak();

[It is the standing recommendation that only class, constructor, and
constant identifiers should start with a capital letter (after leading
“_”s are trimmed. “Julio” is an *instance* and a *variable*; the
identifier should start lowercase.]

Your unnecessary insult aside:

Functional programming is a programming *paradigm*. A functional
programming language is a programming language where functions are first-
class objects: they can appear on the right-hand side of an assignment
expression and/or they can be passed as arguments to other functions.
*Functional programming is _not_, in general, a contradiction to object-
oriented programming.*

Proof that JS is/are (a) functional programming language(s) has been given
implicitly above. Another example:

var f = Julio.speak;
(function (func) { func.call({name: "Thomas ‘PointedEars’ Lahn"}); }(f));

To be more precise, implementations of ECMAScript, such as the languages
that have “JavaScript” in their name, are procedural-imperative, functional
and object-oriented programming languages that support both the prototype-
based and (to some extent) class-based inheritance programming paradigm.

*That* they support *all* of *those* programming paradigms, in *addition* to
others, is an important reason for their versatility and wide distribution.

<https://en.wikipedia.org/wiki/Programming_paradigm>

See also the FAQ (referred below).

Julio Di Egidio

unread,
Apr 21, 2018, 4:36:53 AM4/21/18
to
On Saturday, 21 April 2018 05:28:00 UTC+2, Thomas 'PointedEars' Lahn wrote:

> > Julio Di Egidio babbled:
> >> JS is a *functional* language: the modularity is modularity of *lexical*
> >> constructs and contexts... (Someone else might be able to say it
> >> better.)
>
> Modularity is not the key property of a functional programming language.

I didn't say it's the key property but I'd certainly say functional is the
*most* modular: while OO is the *least* modular. Then of course I do know I
am saying the opposite that one can read pretty much everywhere: it's simply
all badly wrong and the result of the OO uber alles speculation that is not
even over yet, and the fact that 90%+ of people do not know what they are
talking about in this arena and just echo each other...

> Functional programming is a programming *paradigm*. A functional
> programming language is a programming language where functions are first-
> class objects:

Yes, but there is *more*: a functional language is a language of *lexical*
constructs and *contexts*: it's about *closures*, not just functions!

That said, having some actual disagreement in this newsgroup is indeed a great
step ahead...

Cheers,

Julio

Michael Haufe (TNO)

unread,
Apr 21, 2018, 2:46:14 PM4/21/18
to
Julio Di Egidio wrote:

> I didn't say it's the key property but I'd certainly say functional is the
> *most* modular: while OO is the *least* modular. Then of course I do know I
> am saying the opposite that one can read pretty much everywhere: it's simply
> all badly wrong and the result of the OO uber alles speculation that is not
> even over yet, and the fact that 90%+ of people do not know what they are
> talking about in this arena and just echo each other...

You're going to have to back up your claim here, preferably with an example. Show me the code.

I'll even set the stage for you. Below are two partial implementations of a Singly List List in TypeScript. The first one in Functional style, and the second in Object Oriented style. Which is more "modular" by your definition?

<script>

// Data
type List<T> = { tag: 'Nil' } | { tag: 'Cons', head: T, tail: List<T> }

// Operations
function length(xs: List<any>): number {
return xs.tag == "Nil" ? 0 : length(xs.tail) + 1
}

function isEmpty(xs: List<any>): boolean {
return xs.tag == "Nil" ? true : false
}

function contains<T>(x: T, xs: List<T>): boolean {
return xs.tag == "Nil" ? false :
xs.head === x || contains(x,xs.tail)
}

function append<T>(x: T, xs: List<T>): List<T> {
return xs.tag == "Nil" ? { tag: "Cons", head: x, tail: xs } :
append(x,xs.tail)
}

</script>

<script>
abstract class List<T> {
abstract length(): number
abstract isEmpty(): boolean
abstract contains(x: T): boolean
abstract append(x): List<T>
}

class Nil<T> extends List<T> {
length(): number { return 0 }
isEmpty(): boolean { return true }
contains(x: T): boolean { return false }
append(x): List<T> { return new Cons(x, this) }
}

class Cons<T> extends List<T> {
constructor(
readonly head: T,
readonly tail: List<T>
) { super() }
length(): number { return 1 + this.tail.length() }
isEmpty(): boolean { return false }
contains(x: T): boolean {
return this.head === x || this.tail.contains(x)
}
append(x: T): List<T> { return this.tail.append(x) }
}
</script>

Michael Haufe (TNO)

unread,
Apr 21, 2018, 2:48:50 PM4/21/18
to
Michael Haufe (TNO) wrote:

> [...]
> I'll even set the stage for you. Below are two partial implementations of a Singly List List in TypeScript. The first one in Functional style, and the second in Object Oriented style. Which is more "modular" by your definition?
> [...]

s/Singly List List/Singly Linked List

c.l.js

unread,
Apr 21, 2018, 6:51:47 PM4/21/18
to
A Troll called Thomas 'PointedEars' Lahn wrote:
>
>> Julio Di Egidio babbled:
>>> JS is a *functional* language: the modularity is modularity of *lexical*
>>> constructs and contexts... (Someone else might be able to say it
>>> better.)
>
> Modularity is not the key property of a functional programming language.
>

I already knew another troll would drop by to back their pal up. LOL

JavaScript is a multi-paradigm language, but the resident moron called
Julio insists that JavaScript is a functional programming language just
because it offers the possibility of using the functional programming
paradigm. In JavaScript, functions are first-class *objects*. You won't
find prototype-based or procedural-imperative paradigms in pure
functional programming languages. Period. Stop spreading bullshit and
fuck off!

--
TH


Thomas 'PointedEars' Lahn

unread,
Apr 21, 2018, 7:18:49 PM4/21/18
to
c.l.js wrote:
^^^^^^
I take it that you do want to be reported for network abuse. Can do!

> A Troll called Thomas 'PointedEars' Lahn wrote:
>>> Julio Di Egidio babbled:
>>>> JS is a *functional* language: the modularity is modularity of
>>>> *lexical*
>>>> constructs and contexts... (Someone else might be able to say it
>>>> better.)
>> Modularity is not the key property of a functional programming language.
>
> I already knew another troll would drop by

You are the only troll here. Evidence is marked below.

> to back their pal up. LOL

You have not the slightest clue what you are talking about. For how long
have you been reading the newsgroup, a week or so? The record shows that
Julio Di Egidio and I are anything *but* pals. In fact, I had him killfiled
a long time ago (which is why I posted a follow-up to your posting, not
his).

That does not change the fact that he is *correct* in his choice of
terminology there.

> JavaScript is a multi-paradigm language, but the resident moron called
^^^^^^^^^^^^^^
> Julio insists that JavaScript is a functional programming language just
> because it offers the possibility of using the functional programming
> paradigm.

And that is where he is *correct*.

> In JavaScript, functions are first-class *objects*.

If you had read more carefully, you would have realized that the term
“first-class object” does _not_ imply object-oriented programming.

> You won't find prototype-based or procedural-imperative paradigms in pure
> functional programming languages.

But there is a difference between a functional programming language (like
ECMAScript implementations), where the functional programming paradigm can
be used, and a *pure* functional programming language (like Haskell), where
*only* the functional programming paradigm (and related paradigms) can be
used.

> Period. Stop spreading bullshit

Yeah, have you looked into a mirror lately?

<https://www.crockford.com/javascript/javascript.html>

> and fuck off!

Read my signature, ignoramus.

Thomas 'PointedEars' Lahn

unread,
Apr 21, 2018, 8:19:07 PM4/21/18
to
Ship’s log, supplemental…

Thomas 'PointedEars' Lahn wrote:

> <https://www.crockford.com/javascript/javascript.html>

JFTR: I do not agree with much that Crockford claims there (maybe I will add
my remarks on it some day), but the point I wanted to make with this
reference is where he is correct there: “JavaScript”, if you understand that
to mean all ECMAScript implementations (and you should not; Crockford
*oversimplifies* there), is “Lisp in C's Clothing” indeed.

In fact, Brendan Eich, creator of (Netscape) JavaScript, wrote *verbatim* in
his 2008 blog entry that he “was recruited to Netscape with the promise of
‘doing Scheme’ in the browser”. Scheme, too, supports both imperative and
functional programming as it was influenced by Lisp, and is described as one
of the main dialects of Lisp (the other being Common Lisp).

<https://brendaneich.com/2008/04/popularity/>
<https://en.wikipedia.org/wiki/Scheme_(programming_language)>

Also, ECMAScript and its implementations ActionScript (Macromedia/Adobe in
Flash), ECMAScript for XML (formerly, Mozilla in Firefox), JavaScript
(Netscape et al. in various environments), and JScript (Microsoft in
Internet Explorer, maybe also Edge)¹ are rightfully listed under

<https://en.wikipedia.org/wiki/List_of_programming_languages_by_type#Functional_languages>

in the “Impure” subsection, along with Lisp and Scheme. (Whereas AISB,
Haskell is rightfully listed in the “Pure” subsection.)

[Not my doing this time, but good to see for a change, as Wikipedia
unfortunately has a history of propagating misconceptions about
ECMAScript.]

_______
¹ see also the ECMAScript Support Matrix (URI in the signature below)

Mark-

unread,
Apr 21, 2018, 9:53:05 PM4/21/18
to
Thomas 'PointedEars' Lahn wrote:

> ...as Wikipedia
> unfortunately has a history of propagating misconceptions about
> ECMAScript.

But you continue to use WP as a source.

How is that "logical"?

Thomas 'PointedEars' Lahn

unread,
Apr 21, 2018, 10:30:40 PM4/21/18
to
Mark- wrote:

> Thomas 'PointedEars' Lahn wrote:
>> ...as Wikipedia unfortunately has a history of propagating
>> misconceptions about ECMAScript.
>
> But you continue to use WP as a source.

… if and when it is justified, i.e. there are supporting sources referred by
the cited article (which is a requirement for Wikipedia content that lasts)
or elsewhere to back it up (many Wikipedia articles provide excellent
introductory material about a complex subject).

> How is that "logical"?

How is it not? Your logic is flawed; it is the opposite of an /ipse dixit/
argument (which is a fallacy, too).

<https://en.wikipedia.org/wiki/Poisoning_the_well>

Mark-

unread,
Apr 21, 2018, 10:45:14 PM4/21/18
to
Thomas 'PointedEars' Lahn wrote:

>… if and when it is justified,

Right, you use WP when you agree with what is written.

> Your logic is flawed;

No, it is clear. That you fail to see the logic is something you should
consider working on. But you won't. :)

Good luck.


Thomas 'PointedEars' Lahn

unread,
Apr 21, 2018, 11:55:09 PM4/21/18
to
Mark- trolled:

> Thomas 'PointedEars' Lahn wrote:
>> … if and when it is justified,
>
> Right, you use WP when you agree with what is written.

That is _not_ what I said.

> […]

Score adjusted.

Mark-

unread,
Apr 22, 2018, 12:04:50 AM4/22/18
to
Thomas 'PointedEars' Lahn wrote:

> That is not what I said.

Not in those exact words but, in meaning.

> Mark- trolled:

It appears I struck a truth and you lost the debate.

Julio Di Egidio

unread,
Apr 22, 2018, 2:54:23 AM4/22/18
to
On Saturday, 21 April 2018 20:46:14 UTC+2, Michael Haufe (TNO) wrote:
> Julio Di Egidio wrote:
>
> > I didn't say it's the key property but I'd certainly say functional is the
> > *most* modular: while OO is the *least* modular. Then of course I do know I
> > am saying the opposite that one can read pretty much everywhere: it's simply
> > all badly wrong and the result of the OO uber alles speculation that is not
> > even over yet, and the fact that 90%+ of people do not know what they are
> > talking about in this arena and just echo each other...
>
> You're going to have to back up your claim here, preferably with an example.
> Show me the code.

I owe you retarded cunts less than zero. Indeed which one, that functional is
most modular or that you don't know what you are talking about?

> I'll even set the stage for you.

The stage of your cluelessness.

> Below are two partial implementations of a Singly List List in TypeScript.
> The first one in Functional style, and the second in Object Oriented style.
> Which is more "modular" by your definition?

Two implementations that are quite representative just of your utter lack of
perspective. Indeed "styles"?? *Paradigms* are no stupid styles, you clueless
moron, and paradigms are way above your dishonest and stupid head, learn to walk
before you can run. I mean "pointers"... just go fuck yourself.

*Plonk*

Julio

Evertjan.

unread,
Apr 22, 2018, 4:59:16 AM4/22/18
to
"Mark-" <nos...@mapson.xyz> wrote on 22 Apr 2018 in comp.lang.javascript:

> Thomas 'PointedEars' Lahn wrote:
>
>> That is not what I said.
>
> Not in those exact words but, in meaning.

Nonsense, the meaning belongs to the one that says something.

>> Mark- trolled:
>
> It appears I struck a truth and you lost the debate.

Since when needs a debate to be about winning,
when you are older than 7?

A debate is about expecting ideas that are not your own to begin with,
and entering ideas that are not the ones of the 'opponents'.

Incidentally you are bound to learn something.

So grow up all of you.

John G Harris

unread,
Apr 22, 2018, 6:03:34 AM4/22/18
to
On Sun, 22 Apr 2018 10:59:08 +0200, "Evertjan."
<exxjxw.h...@inter.nl.net> wrote:

<snip>
>So grow up all of you.

In spite of Evertjan saying earlier
>Will you stop ordering others what to do.
:-)

John

Evertjan.

unread,
Apr 22, 2018, 6:50:48 AM4/22/18
to
John G Harris <ni...@jghnorth.org.uk.invalid> wrote on 22 Apr 2018 in
comp.lang.javascript:
Not in spite of.

Ordering others what to do is also childish behavour.

Mark-

unread,
Apr 22, 2018, 8:58:52 AM4/22/18
to
Evertjan. wrote:

> Nonsense, the meaning belongs to the one that says something.

Nonsense. The person that duplicates the communication, the receiver,
the intended target, his duplication/understanding is more important
than the sender of the communication.

If you say to me, "eat your carrots", and I hit you with a pan, because
that is what I thought you said/the meaning of what you said, which is
more important, what the sender said or what the receiver understood?

Regardless of the cause of the communication failure, it does not alter
the communication forumla. The communication receiver and what he
duplicates is the total point of the communication, otherwise why have
a communication. To hear yourself. :)

If that is not true for you so be it.

> A debate is about expecting ideas that are not your own to begin with,
> and entering ideas that are not the ones of the 'opponents'.

Says you. (And is incorrect)






Michael Haufe (TNO)

unread,
Apr 22, 2018, 1:34:10 PM4/22/18
to
Julio Di Egidio wrote:
> Michael Haufe (TNO) wrote:
> > You're going to have to back up your claim here, preferably with an example.
> > Show me the code.
>
> I owe you retarded cunts less than zero. Indeed which one, that functional is
> most modular or that you don't know what you are talking about?

Then why waste your time here in the group? Is this your version of Primal Therapy? [1]. I provably know what I'm talking talking about and very likely know more about this topic than you do. This is what, at least the third time you've thrown claims claims around without any backup? Even MentiFake at least tries to backup his nonsense.

> > I'll even set the stage for you.
>
> The stage of your cluelessness.

If that was too hard, I could give you an even simpler example. Put up or shut up.

> > Below are two partial implementations of a Singly List List in TypeScript.
> > The first one in Functional style, and the second in Object Oriented style.
> > Which is more "modular" by your definition?

> Two implementations that are quite representative just of your utter lack of
> perspective. Indeed "styles"?? *Paradigms* are no stupid styles, you clueless
> moron, and paradigms are way above your dishonest and stupid head, learn to walk
> before you can run. I mean "pointers"... just go fuck yourself.

You can't even stay consistent with your own definitions [2]. Besides even basic English is on my side with this usage:

"A manner of doing or presenting things"
<https://en.wiktionary.org/wiki/style#Noun>

"A pattern, a way of doing something"
<https://en.wiktionary.org/wiki/paradigm#Noun>

[1] <https://en.wikipedia.org/wiki/Primal_therapy>
[2] <https://groups.google.com/d/msg/comp.lang.javascript/paDy9O_kOdc/ZOyMMS_0DQAJ>

Julio Di Egidio

unread,
Apr 23, 2018, 3:27:53 AM4/23/18
to
On Sunday, 22 April 2018 19:34:10 UTC+2, Michael Haufe (TNO) wrote:
> Julio Di Egidio wrote:
> > Michael Haufe (TNO) wrote:
> > > You're going to have to back up your claim here, preferably with an example.
> > > Show me the code.
> >
> > I owe you retarded cunts less than zero. Indeed which one, that functional is
> > most modular or that you don't know what you are talking about?
>
> Then why waste your time here in the group? Is this your version of Primal Therapy? [1]. I provably know what I'm talking talking about and very likely know more about this topic than you do. This is what, at least the third time you've thrown claims claims around without any backup? Even MentiFake at least tries to backup his nonsense.
>
> > > I'll even set the stage for you.
> >
> > The stage of your cluelessness.
>
> If that was too hard, I could give you an even simpler example. Put up or shut up.

You are the one raising objections...

> > > Below are two partial implementations of a Singly List List in TypeScript.
> > > The first one in Functional style, and the second in Object Oriented style.
> > > Which is more "modular" by your definition?
>
> > Two implementations that are quite representative just of your utter lack of
> > perspective. Indeed "styles"?? *Paradigms* are no stupid styles, you clueless
> > moron, and paradigms are way above your dishonest and stupid head, learn to walk
> > before you can run. I mean "pointers"... just go fuck yourself.
>
> You can't even stay consistent with your own definitions [2].

What are you complaining about now? Can you even read?

> Besides even basic English is on my side with this usage:

Basic English is irrelevant, besides you should really get past just the first
line when reading any dictionary. That said, it's plain ridiculous that you
cannot appreciate the difference (at least that there is a difference) between
a *coding style* and a *language paradigm*. In fact OO is not even just a
language paradigm, it's a full technical paradigm going from OOA to OOD to
OOP. But the same goes for functional or, say , the logical paradigm: these
are essentially different since the outset, the very way one defines solutions.

Get a good software engineering book: Pressman's is a classic.

Julio

John G Harris

unread,
Apr 23, 2018, 4:19:22 AM4/23/18
to
On Sun, 22 Apr 2018 12:50:35 +0200, "Evertjan."
<exxjxw.h...@inter.nl.net> wrote:

>John G Harris <ni...@jghnorth.org.uk.invalid> wrote on 22 Apr 2018 in
>comp.lang.javascript:
>
>> On Sun, 22 Apr 2018 10:59:08 +0200, "Evertjan."
>> <exxjxw.h...@inter.nl.net> wrote:
>>
>> <snip>
>>>So grow up all of you.
>>
>> In spite of Evertjan saying earlier
>>>Will you stop ordering others what to do.
>
>Not in spite of.
>
>Ordering others what to do is also childish behavour.

So saying "Grow up all of you" is childish behaviour. I see.

John

Michael Haufe (TNO)

unread,
Apr 23, 2018, 2:50:33 PM4/23/18
to
Julio Di Egidio wrote:
> Michael Haufe (TNO) wrote:
> > Julio Di Egidio wrote:
> > > Michael Haufe (TNO) wrote:

> > If that was too hard, I could give you an even simpler example. Put up or shut up.
>
> You are the one raising objections...

Objecting to claims without justification. Objecting to your FUD

> Basic English is irrelevant [...]

That much seems obvious. You're just digging a deeper hole for yourself.

> That said, it's plain ridiculous that you
> cannot appreciate the difference (at least that there is a difference) between
> a *coding style* and a *language paradigm*.

Are you ever going to provide something concrete, or just keep throwing shit against a wall to see which sticks?

> In fact OO is not even just a
> language paradigm, it's a full technical paradigm going from OOA to OOD to
> OOP. But the same goes for functional or, say , the logical paradigm: these
> are essentially different since the outset, the very way one defines solutions.

We've been through this little dance already, and I've given you formal definitions and usage in the past. Your response then was even more shallow then, but at least there is some progress this time around:

<https://groups.google.com/d/msg/comp.lang.javascript/7yR6urAZypU/CF7Ucfj-BAAJ>

> Get a good software engineering book: Pressman's is a classic.

"Homo unius libri". I'm assuming you mean this one?

<https://archive.org/details/SoftwareEngineering7thEDByRogerS.Pressman>


Julio Di Egidio

unread,
Apr 23, 2018, 3:00:28 PM4/23/18
to
On Monday, 23 April 2018 20:50:33 UTC+2, Michael Haufe (TNO) wrote:
> Julio Di Egidio wrote:
<snip>
> > Basic English is irrelevant [...]
>
> That much seems obvious. You're just digging a deeper hole for yourself.

Except that you were the one quoting from the basic dictionary: snip, deny,
and insult, i.e. yet another retarded cunt who's definitely lost the right
to waste my time. (But I'll keep debunking your bullshit, stay confident.)

*Plonk*

Julio

Michael Haufe (TNO)

unread,
Apr 23, 2018, 6:07:33 PM4/23/18
to
Julio Di Egidio wrote:
> Michael Haufe (TNO) wrote:
> > Julio Di Egidio wrote:
> <snip>
> > > Basic English is irrelevant [...]
> >
> > That much seems obvious. You're just digging a deeper hole for yourself.
>
> Except that you were the one quoting from the basic dictionary: snip, deny,
> and insult, i.e. yet another retarded cunt who's definitely lost the right
> to waste my time. (But I'll keep debunking your bullshit, stay confident.)

You can't "keep debunking" if you never start. Every time I counter your rantings or push you to justify them, you retreat into insults and more generalizations.

Are you able to even back up or expand on your current claim:

"I'd certainly say functional is the *most* modular: while OO is the *least* modular."

Why? I don't believe you and I'd be surprised if anyone else does either.

There is a big difference between something being true, what you think is true, and what you can demonstrate to be true.

AFAICT, you've never demonstrated so therefore it doesn't matter if it might actually be true. I would think that any effort in producing one would save you far more time in the long run.

If I'm wrong and you've actually demonstrated your proof, present it or link to it. I've asked for your prior evidence/work before and you were just as evasive then.

Since you're keen on "debunking". Here is that simplified example. Why is the functional approach more modular?

<script type="TypeScript">
/** Number Expressions */

// Functional

// data
type Exp =
{ tag: 'Lit', value: number } |
{ tag: 'Add', left: Exp, right: Exp }

// operations
function evaluate(exp: Exp): number {
switch (exp.tag) {
case 'Lit':
return exp.value;
case 'Add':
return evaluate(exp.left) + evaluate(exp.right)
}
}

function print(exp: Exp): string {
switch (exp.tag) {
case 'Lit':
return `Lit(${exp.value})`;
case 'Add':
return `Add(${print(exp.left)},${print(exp.right)})`
}
}

// 1 + 3
let exp: Exp = {
tag: 'Add',
left: { tag: 'Lit', value: 1 },
right: { tag: 'Lit', value: 3 }
}

evaluate(exp) //4
print(exp) // Add(Lit(1),Lit(3))

// Object Oriented
abstract class Exp {
abstract print(): string
abstract evaluate(): number
}

class Lit extends Exp {
// data
constructor(readonly value: number) { super() }

//operations
evaluate(): number {
return this.value
}
print(): string {
return `Lit(${this.value})`
}
}

class Add implements Exp {
// data
constructor(readonly left: Exp, readonly right: Exp) { }

// operations
evaluate(): number {
return this.left.evaluate() + this.right.evaluate()
}
print(): string {
return `Add(${this.left.print()},${this.right.print()})`
}
}

// 1 + 3
let exp: Exp = new Add(
new Lit(1),
new Lit(3)
)

exp.evaluate() // 4
exp.print() // Add(Lit(1),Lit(3))
</script>

Christoph M. Becker

unread,
Apr 23, 2018, 6:47:10 PM4/23/18
to
On 24.04.2018 at 00:07, Michael Haufe (TNO) wrote:

> Julio Di Egidio wrote:
>
>> Except that you were the one quoting from the basic dictionary: snip, deny,
>> and insult, i.e. yet another retarded cunt who's definitely lost the right
>> to waste my time. (But I'll keep debunking your bullshit, stay confident.)
>
> You can't "keep debunking" if you never start.

Indeed. It seems to me that Julio confuses claiming something, and if
anybody *argues* against that claim, following up with insults, with
debunking.

Anyhow, to boost this discussion, John Hughes' "Why Functional
Programming Matters"[1] might be useful, as well as the more JS related
"Professor Frisby's Most Adequate Guide to Functional Programming"[2],
and Scott Sauyet's "Why Ramda?"[3].

Disclaimer: I do not claim that ECMAScript implementations are
functional programming languages, but rather that functional programming
can be done with those, and that it might be a preferable alternative to
OOP, depending on the task at hand.

[1] <https://www.cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.pdf>
[2] <https://drboolean.gitbooks.io/mostly-adequate-guide-old/content/>
[3] <http://fr.umio.us/why-ramda/>

--
Christoph M. Becker

Julio Di Egidio

unread,
Apr 23, 2018, 7:12:38 PM4/23/18
to
On Tuesday, 24 April 2018 00:47:10 UTC+2, Christoph M. Becker wrote:
> On 24.04.2018 at 00:07, Michael Haufe (TNO) wrote:
> > Julio Di Egidio wrote:
> >
> >> Except that you were the one quoting from the basic dictionary: snip, deny,
> >> and insult, i.e. yet another retarded cunt who's definitely lost the right
> >> to waste my time. (But I'll keep debunking your bullshit, stay confident.)
> >
> > You can't "keep debunking" if you never start.
>
> Indeed. It seems to me that Julio confuses claiming something, and if
> anybody *argues* against that claim, following up with insults, with
> debunking.
>
> Anyhow, to boost this discussion

Gratuitous accusations and a bunch of links, yet another idiot.

(You see, I always explain, some just don't get it.)

*Plonk*

Julio

Christoph M. Becker

unread,
Apr 23, 2018, 7:30:39 PM4/23/18
to
On 24.04.2018 at 01:12, Julio Di Egidio wrote:

> *Plonk*

Thanks! :)

--
Christoph M. Becker

Julio Di Egidio

unread,
Apr 23, 2018, 7:45:22 PM4/23/18
to
On Tuesday, 24 April 2018 00:47:10 UTC+2, Christoph M. Becker wrote:

> Disclaimer: I do not claim that ECMAScript implementations are
> functional programming languages,

That's not even very meaningful: the JavaScript *language*, ECMAScript if you
like, is a functional language. Look at the spec, not the labels, what it is.

> but rather that functional programming
> can be done with those, and that it might be a preferable alternative to
> OOP, depending on the task at hand.

Rather OO can be done in JS...

Julio

John G Harris

unread,
Apr 24, 2018, 4:55:00 AM4/24/18
to
On Tue, 24 Apr 2018 00:47:06 +0200, "Christoph M. Becker"
<cmbec...@arcor.de> wrote:

<snip>
>Disclaimer: I do not claim that ECMAScript implementations are
>functional programming languages, but rather that functional programming
>can be done with those, and that it might be a preferable alternative to
>OOP, depending on the task at hand.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Hear, here, and so say all (er ... most) of us.

John

Michael Haufe (TNO)

unread,
Apr 24, 2018, 3:02:40 PM4/24/18
to
Christoph M. Becker wrote:

[...]

> Anyhow, to boost this discussion, John Hughes' "Why Functional
> Programming Matters"[1] might be useful, as well as the more JS related
> "Professor Frisby's Most Adequate Guide to Functional Programming"[2],
> and Scott Sauyet's "Why Ramda?"[3].

#1 Is a good lead into the book: "Introduction to Functional Programming" :

<https://www.amazon.com/Introduction-Functional-Programming-International-Computing/dp/0134841972/ref=sr_1_3?ie=UTF8&qid=1524595376&sr=8-3&keywords=Introduction+to+Functional+Programming+Languages>

The book is also written in Miranda.

#2 I haven't seen this one yet and will take a look.

#3 You might recall that we've discussed Ramda before here in the group when it was being developed:

<https://groups.google.com/d/msg/jsmentors/wH6X8SDPnbw/dF8ON8LkT2wJ>


> Disclaimer: I do not claim that ECMAScript implementations are
> functional programming languages, but rather that functional programming
> can be done with those, and that it might be a preferable alternative to
> OOP, depending on the task at hand.

For OOP, I'd suggest "A Little Java, A Few Patterns":

<https://www.amazon.com/Little-Java-Few-Patterns-Press-ebook/dp/B004GCK2MO/ref=sr_1_1?ie=UTF8&qid=1516482984&sr=8-1&keywords=a+little+java%2C+a+few+patterns>

Followed by the Self Papers. I'm not to going to link to them here since it feels excessive, but I will if requested.

The main point I was setting up with Julio was that Object-Oriented and Functional programming are duals[1] of each other and when you attempt to extend either of my examples it becomes clear the failures of both paradigms. In other words I was setting up an example of the Expression Problem [2]

[1] <https://en.wikipedia.org/wiki/Duality_(mathematics)>
[2] <https://en.wikipedia.org/wiki/Expression_problem>

Thomas 'PointedEars' Lahn

unread,
Apr 24, 2018, 11:04:25 PM4/24/18
to
Michael Haufe (TNO) wrote:

> The main point I was setting up with Julio was that Object-Oriented and
> Functional programming are duals[1] of each other […]
>
> [1] <https://en.wikipedia.org/wiki/Duality_(mathematics)>

But *that* is _not_ true. Because you can employ the object-oriented
programming paradigm *without* employing the functional paradigm, and vice-
versa. And there are, among implementations of those two paradigms, pure
object-oriented programming languages (e.g., Visual Basic) as well as there
are pure functional programming languages (e.g., Haskell). I happen to have
used both, so I can confirm

<https://en.wikipedia.org/wiki/Comparison_of_programming_languages#General_comparison>

in that regard.

AISB, the key property of a functional programming language is that
“functions are first-class objects”. Superficialls that looks like a
contradiction; but it _not_ because “first-class object” must be understood
like “first-class citizen”: we are talking about objects/targets *of
operations* there.[1]

So the most fundamental operation that a functional programming language
must allow is passing a (reference to a) function as an argument to another
function. (ECMAScript implementations, like the various JavaScripts, allow
that, as functions are specified and implemented as real *OOP* objects¹ and
you can always pass references to objects as arguments of functions.)

Also, it is not always helpful or correct to migrate mathematic terminology
to other fields; in this case it certainly is not.

_________
¹ Functions have *properties*, a *constructor* (Function), a
*prototype chain*, aso.

[1] <https://en.wikipedia.org/wiki/First-class_object>

Julio Di Egidio

unread,
Apr 25, 2018, 5:16:42 AM4/25/18
to
On Wednesday, 25 April 2018 05:04:25 UTC+2, Thomas 'PointedEars' Lahn wrote:

> AISB, the key property of a functional programming language is that
> “functions are first-class objects”.

And I have already told you that there is more than that:
functional is about *lexical* *bottom-up* *substitution*.

Julio

Julio Di Egidio

unread,
Apr 25, 2018, 5:20:37 AM4/25/18
to
As well as I have already mentioned that it's closures, not just functions.

How fucking stupid you too are? I said "someone else might be able to say it
better" just because *I* am super conscious of specialisations and subtleties,
not because that was far from the point and certainly not because you moron can
feel safe ignoring it. Stop being a bunch of retarded asses, you all.

Julio

John G Harris

unread,
Apr 25, 2018, 1:22:59 PM4/25/18
to
Unfortunately, functional languages are useless. They can't be used to
control a petrol pump. They can't be used to control bank accounts.
They can't be used to fly an aeroplane. And they can't be used to
manipulate the display of a web page.

Because if they could they wouldn't be functional languages.

John

Jon Ribbens

unread,
Apr 25, 2018, 1:26:00 PM4/25/18
to
On 2018-04-25, John G Harris <ni...@jghnorth.org.uk.invalid> wrote:
> Unfortunately, functional languages are useless. They can't be used to
> control a petrol pump. They can't be used to control bank accounts.
> They can't be used to fly an aeroplane. And they can't be used to
> manipulate the display of a web page.
>
> Because if they could they wouldn't be functional languages.

Are you saying... functional languages are non-functional? ;-)

Michael Haufe (TNO)

unread,
Apr 25, 2018, 5:39:28 PM4/25/18
to
Thomas 'PointedEars' Lahn wrote:
> Michael Haufe (TNO) wrote:
>
> > The main point I was setting up with Julio was that Object-Oriented and
> > Functional programming are duals[1] of each other […]
> >
> > [1] <https://en.wikipedia.org/wiki/Duality_(mathematics)>
>
> But *that* is _not_ true. Because you can employ the object-oriented
> programming paradigm *without* employing the functional paradigm, and vice-
> versa. And there are, among implementations of those two paradigms, pure
> object-oriented programming languages (e.g., Visual Basic) as well as there
> are pure functional programming languages (e.g., Haskell). I happen to have
> used both, so I can confirm

I don't think you can include any version of VB in the category of Pure OOP. Every one of them I've seen has procedural constructs. For example, compare the solutions of Smalltalk and Visual Basic :

<http://rosettacode.org/wiki/Sieve_of_Eratosthenes#Visual_Basic>
<http://rosettacode.org/wiki/Sieve_of_Eratosthenes#Smalltalk>

'if/then/else' would be methods of boolean in a pure OO. Also IIRC, 'Nothing' in VB has never been an object.

Regarding the first part of your paragraph, I'm not sure we're on the same page yet so I don't know if I agree/disagree. Here is the duality I'm referring to (building on my earlier examples [1])

/* Functional */
If I want to add a new operation, such as isValue(exp) to the functional example it's easy and I don't have to modify anything to implement it.

But if I want to add a new Exp type such a Mul(left,right) then I have a problem. All operations have to be updated to support this new case.

/* OO */
Same example. If I want to add the new Exp type Mul(left,right) then it's easy.
Just extend the Exp type and implement the specific methods.

But if I want to add that new operation: Exp.isValue() then I have a different problem. All of my existing data types have to be touched to support this new method.

Summary:


New Operations | New Data
FP Easy | Hard
OOP Hard | Easy


This is the duality I'm referring to.

Yes, it's possible for them to emulate each other, but in those emulations
I'm claiming you are making things even more complicated.

For instance, in OOP to make new operations easy you utilize the Visitor Pattern, in FP you have Type Classes, or explicit records you thread through all of your functions.


[1] <https://groups.google.com/d/msg/comp.lang.javascript/9FxKCWG7NLQ/iXVPdwuaCgAJ>


> AISB, the key property of a functional programming language is that
> “functions are first-class objects”. Superficialls that looks like a
> contradiction; but it _not_ because “first-class object” must be understood
> like “first-class citizen”: we are talking about objects/targets *of
> operations* there.[1]

Yes, I know what this means. An interesting exercise (if you've ever tried it), is to try and emulate functional programming in C. What I ended up doing was managing my own lookup table of procedure references in order to not just pass the references but emulate partial application. Turned into a nightmare to maintain, but interesting to try anyway.

> So the most fundamental operation that a functional programming language
> must allow is passing a (reference to a) function as an argument to another
> function.

aka. Function Composition is more important than Function Application.
Take that to the extreme and you don't even have values in the language anymore.
If you can represent values and functions then everything is truly a function.
But this isn't a "Functional" Programming Language anymore. This would be called a Function Level language and it's an old idea (John Backus's FP language).

I used to be a major fan of this for a couple years. The modern term for this paradigm is Concatenative, there is/was an active community around it:

<http://concatenative.org>
<https://groups.yahoo.com/neo/groups/concatenative/conversations/topics>

And a good intro: <https://web.archive.org/web/20111007025545/http://www.latrobe.edu.au:80/phimvt/joy/j00rat.html>


> Also, it is not always helpful or correct to migrate mathematic terminology
> to other fields; in this case it certainly is not.

Duality is a well known concept in PLT, I accept the blame for not expressing that concept better. Wikipedia is admittedly not a good reference for this, but I don't have a better one that doesn't require some prerequisite knowledge. The following shot paper is better though:

<https://www.researchgate.net/publication/228975512_Dualities_in_Programming_Languages>

Michael Haufe (TNO)

unread,
Apr 25, 2018, 5:50:36 PM4/25/18
to
John G Harris wrote:

> Unfortunately, functional languages are useless. They can't be used to
> control a petrol pump. They can't be used to control bank accounts.
> They can't be used to fly an aeroplane. And they can't be used to
> manipulate the display of a web page.
>
> Because if they could they wouldn't be functional languages.

Are you referring to immutability? Erik Meijer had an excellent write-up on this you might enjoy:

"The Curse of the Excluded Middle:
'Mostly functional' programming does not work."

<https://queue.acm.org/detail.cfm?id=2611829>

Thomas 'PointedEars' Lahn

unread,
Apr 29, 2018, 2:44:49 PM4/29/18
to
Michael Haufe (TNO) wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Michael Haufe (TNO) wrote:
>> > The main point I was setting up with Julio was that Object-Oriented and
>> > Functional programming are duals[1] of each other […]
>> >
>> > [1] <https://en.wikipedia.org/wiki/Duality_(mathematics)>
>> But *that* is _not_ true. Because you can employ the object-oriented
>> programming paradigm *without* employing the functional paradigm, and
>> vice-versa. And there are, among implementations of those two paradigms,
>> pure object-oriented programming languages (e.g., Visual Basic) as well
>> as there are pure functional programming languages (e.g., Haskell). I
>> happen to have used both, so I can confirm
>
> I don't think you can include any version of VB in the category of Pure
> OOP. Every one of them I've seen has procedural constructs.

Semantic fallacy and /argumentum ad ignorantiam/.

When I am distinguishing “pure object-oriented” and “pure functional”
programming languages, I am of course referring to the fact that one
set has none of the *key* properties of the other.

> For example, compare the solutions of Smalltalk and Visual Basic :
>
> <http://rosettacode.org/wiki/Sieve_of_Eratosthenes#Visual_Basic>

There is “Debug.Print”, is there not?

> <http://rosettacode.org/wiki/Sieve_of_Eratosthenes#Smalltalk>
>
> 'if/then/else' would be methods of boolean in a pure OO.

Utter nonsense.

> Also IIRC, 'Nothing' in VB has never been an object.

Irrelevant.

> [tl;dr yet]

Michael Haufe (TNO)

unread,
Apr 29, 2018, 4:45:24 PM4/29/18
to
Thomas 'PointedEars' Lahn wrote:
> Michael Haufe (TNO) wrote:

[...]

> > I don't think you can include any version of VB in the category of Pure
> > OOP. Every one of them I've seen has procedural constructs.
>
> Semantic fallacy and /argumentum ad ignorantiam/.
>
> When I am distinguishing “pure object-oriented” and “pure functional”
> programming languages, I am of course referring to the fact that one
> set has none of the *key* properties of the other.

If we disagree on the definition of "Pure", then fair enough. The definition I use for "Pure" is the lack of mutable state in addition to the key properties you mentioned.

"Pure" OOP doesn't have a commonly accepted equivalent definition, though I refer to it as also meaning a lack of side-effects (Admittedly a minority opinion). The community definition (SmallTalk, Self, Ruby, etc.) is more-so "Pure" as meaning "Purely" OOP where every construct in the language is an object or a method/message of that object. This difference is what I was showing with the Rosetta Code comparison

> > For example, compare the solutions of Smalltalk and Visual Basic :
> >
> > <http://rosettacode.org/wiki/Sieve_of_Eratosthenes#Visual_Basic>
>
> There is “Debug.Print”, is there not?

What's your point?

> > <http://rosettacode.org/wiki/Sieve_of_Eratosthenes#Smalltalk>
> >
> > 'if/then/else' would be methods of boolean in a pure OO.
>
> Utter nonsense.

Based on my earlier definition, hardly. Example:

<script type="SmallTalk">
a < b
ifTrue: [^'a is less than b']
ifFalse: [^'a is greater than or equal to b']
</script>

<script type="VB.NET>
If (a < b) Then
Return "a is less than b"
Else
Return "a is greater than or equal to b"
End If
</script>

> > Also IIRC, 'Nothing' in VB has never been an object.
>
> Irrelevant.

Relevant per above.

> > [tl;dr yet]

No rush. It will be awhile before I can dedicate time to read another response properly.
0 new messages