Groups > comp.lang.javascript > #35622 > unrolled thread

Ideas behind programming language syntax choices?

Started by	Jonas Thörnvall <jonas.thornvall@gmail.com>
First post	2018-09-21 21:53 -0700
Last post	2018-09-26 04:53 -0700
Articles	20 on this page of 64 — 7 participants

Back to article view | Back to comp.lang.javascript

  Ideas behind programming language syntax choices? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-09-21 21:53 -0700
    Re: Ideas behind programming language syntax choices? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-09-22 15:17 +0200
      Re: Ideas behind programming language syntax choices? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-09-22 10:23 -0700
      Re: Ideas behind programming language syntax choices? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-09-22 10:31 -0700
        Re: Ideas behind programming language syntax choices? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-09-22 10:39 -0700
          Re: Ideas behind programming language syntax choices? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-09-22 11:20 -0700
      Re: Ideas behind programming language syntax choices? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-09-22 15:21 -0700
        Re: Ideas behind programming language syntax choices? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-09-23 09:14 +0200
          Re: Ideas behind programming language syntax choices? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-09-23 00:23 -0700
            Re: Ideas behind programming language syntax choices? Maik Koenig <usenetspam@maikkoenig.de> - 2018-09-24 00:56 +0200
    Re: Ideas behind programming language syntax choices? Silvio <silvio@internet.com> - 2018-09-24 00:33 +0200
      Re: Ideas behind programming language syntax choices? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-09-23 16:07 -0700
      Re: Ideas behind programming language syntax choices? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-09-23 16:13 -0700
      Re: Ideas behind programming language syntax choices? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-09-23 16:24 -0700
        Re: Ideas behind programming language syntax choices? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-09-23 16:37 -0700
        Re: Ideas behind programming language syntax choices? John G Harris <niam@jghnorth.org.uk.invalid> - 2018-09-25 19:52 +0100
          Re: Ideas behind programming language syntax choices? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-09-25 12:15 -0700
            Re: Ideas behind programming language syntax choices? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-09-25 12:35 -0700
              Re: Ideas behind programming language syntax choices? John G Harris <niam@jghnorth.org.uk.invalid> - 2018-09-26 18:31 +0100
                Re: Ideas behind programming language syntax choices? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-09-26 11:28 -0700
                  Re: Ideas behind programming language syntax choices? John G Harris <niam@jghnorth.org.uk.invalid> - 2018-09-27 10:49 +0100
                    Re: Ideas behind programming language syntax choices? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-09-27 03:38 -0700
                      Re: Ideas behind programming language syntax choices? John G Harris <niam@jghnorth.org.uk.invalid> - 2018-09-27 19:42 +0100
                        Re: Ideas behind programming language syntax choices? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-09-27 14:44 -0700
                        Re: Ideas behind programming language syntax choices? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-09-27 14:48 -0700
                        Re: Ideas behind programming language syntax choices? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-09-28 21:04 +0200
                          Re: Ideas behind programming language syntax choices? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-10-02 12:47 -0700
                            Re: Ideas behind programming language syntax choices? John G Harris <niam@jghnorth.org.uk.invalid> - 2018-10-03 18:19 +0100
                              Re: Ideas behind programming language syntax choices? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-10-04 05:43 -0700
                                Re: Ideas behind programming language syntax choices? John G Harris <niam@jghnorth.org.uk.invalid> - 2018-10-05 18:17 +0100
                                  Re: Ideas behind programming language syntax choices? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2018-10-05 22:37 +0200
                                    Re: Ideas behind programming language syntax choices? John G Harris <niam@jghnorth.org.uk.invalid> - 2018-10-06 14:30 +0100
                                  Re: Ideas behind programming language syntax choices? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-10-07 09:57 -0700
                                    Re: Ideas behind programming language syntax choices? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2018-10-07 23:08 +0200
                                    Re: Ideas behind programming language syntax choices? John G Harris <niam@jghnorth.org.uk.invalid> - 2018-10-08 19:43 +0100
                              Re: Ideas behind programming language syntax choices? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-10-06 18:04 +0200
                                Re: Ideas behind programming language syntax choices? John G Harris <niam@jghnorth.org.uk.invalid> - 2018-10-07 10:14 +0100
                                  Re: Ideas behind programming language syntax choices? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-10-07 15:15 +0200
                                    Re: Ideas behind programming language syntax choices? John G Harris <niam@jghnorth.org.uk.invalid> - 2018-10-09 10:38 +0100
                                      Re: Ideas behind programming language syntax choices? dr.s.lartius@gmail.com - 2018-10-09 08:27 -0700
                                        Re: Ideas behind programming language syntax choices? John G Harris <niam@jghnorth.org.uk.invalid> - 2018-10-09 19:12 +0100
      Re: Ideas behind programming language syntax choices? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-09-23 16:52 -0700
        Re: Ideas behind programming language syntax choices? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-09-23 16:56 -0700
          Re: Ideas behind programming language syntax choices? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-09-23 17:02 -0700
            Re: Ideas behind programming language syntax choices? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-09-23 18:06 -0700
              Re: Ideas behind programming language syntax choices? Silvio <silvio@internet.com> - 2018-09-24 23:51 +0200
                Re: Ideas behind programming language syntax choices? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-09-25 01:58 -0700
                  Re: Ideas behind programming language syntax choices? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-09-25 02:25 -0700
                Re: Ideas behind programming language syntax choices? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-09-25 02:51 -0700
                  Re: Ideas behind programming language syntax choices? Silvio <silvio@internet.com> - 2018-09-25 19:41 +0200
                    Re: Ideas behind programming language syntax choices? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-09-25 11:22 -0700
                      Re: Ideas behind programming language syntax choices? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-09-25 11:42 -0700
                        Re: Ideas behind programming language syntax choices? Silvio <silvio@internet.com> - 2018-09-25 21:47 +0200
                          Re: Ideas behind programming language syntax choices? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-09-25 14:24 -0700
                            Re: Ideas behind programming language syntax choices? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2018-09-25 23:37 +0200
                              Re: Ideas behind programming language syntax choices? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-09-25 14:46 -0700
                                Re: Ideas behind programming language syntax choices? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2018-09-26 10:52 +0200
                            Re: Ideas behind programming language syntax choices? Silvio <silvio@internet.com> - 2018-09-26 00:06 +0200
                              Re: Ideas behind programming language syntax choices? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-09-25 15:55 -0700
                                Re: Ideas behind programming language syntax choices? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2018-09-26 10:58 +0200
                                  Re: Ideas behind programming language syntax choices? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-09-26 02:48 -0700
                                    Re: Ideas behind programming language syntax choices? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2018-09-26 12:30 +0200
                                      Re: Ideas behind programming language syntax choices? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-09-26 04:45 -0700
                                      Re: Ideas behind programming language syntax choices? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-09-26 04:53 -0700

Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →

#35714

From	John G Harris <niam@jghnorth.org.uk.invalid>
Date	2018-09-27 10:49 +0100
Message-ID	<re9pqdhhena4m8hhlaeslgju5uvtma4obe@4ax.com>
In reply to	#35702

On Wed, 26 Sep 2018 11:28:22 -0700 (PDT), Jonas Thörnvall
<jonas.thornvall@gmail.com> wrote:

>Den onsdag 26 september 2018 kl. 19:32:03 UTC+2 skrev John G Harris:
>> On Tue, 25 Sep 2018 12:35:00 -0700 (PDT), Jonas Thörnvall
>> <jonas.thornvall@gmail.com> wrote:
>> 
>>   <snip>
>> >Yeah what the fuck is going on here, if you have not read the splice method.
>>   <snip>
>> 
>> The answer to your question is obvious : 
>>   Read the definition of the splice method.
>> 
>>   John
>I did and concluded it it an uttetly poor replacement for a delete and an insert.
>a[3].delete(5).insert("splish,"splosh"); 

Suppose a's element 3 holds the value 17.

Do you agree that
  x + a[3]
would then mean add 17 to x?

If you do, what do you think
  17.delete(5)
should do ?

  John

[toc] | [prev] | [next] | [standalone]

#35715

From	Jonas Thörnvall <jonas.thornvall@gmail.com>
Date	2018-09-27 03:38 -0700
Message-ID	<f91f4ded-44c1-44c9-823d-1a3ada97648b@googlegroups.com>
In reply to	#35714

Den torsdag 27 september 2018 kl. 11:49:24 UTC+2 skrev John G Harris:
> On Wed, 26 Sep 2018 11:28:22 -0700 (PDT), Jonas Thörnvall
> <jonas.thornvall@gmail.com> wrote:
> 
> >Den onsdag 26 september 2018 kl. 19:32:03 UTC+2 skrev John G Harris:
> >> On Tue, 25 Sep 2018 12:35:00 -0700 (PDT), Jonas Thörnvall
> >> <jonas.thornvall@gmail.com> wrote:
> >> 
> >>   <snip>
> >> >Yeah what the fuck is going on here, if you have not read the splice method.
> >>   <snip>
> >> 
> >> The answer to your question is obvious : 
> >>   Read the definition of the splice method.
> >> 
> >>   John
> >I did and concluded it it an uttetly poor replacement for a delete and an insert.
> >a[3].delete(5).insert("splish,"splosh"); 
> 
> Suppose a's element 3 holds the value 17.
> 
> Do you agree that
>   x + a[3]
> would then mean add 17 to x?
> 
> If you do, what do you think
>   17.delete(5)
> should do ?
> 
>   John

In the former case it is clear that .delete is a method that work upon an array of elements. It has one argument/parameter it simply must be the number of elements to delete. What could it else be, you have funny suggestions. Replace it with splice bwahahahah, or that it would mean arr[17].delete(5) would subtract 5 from arr{17], no no no that method would be named subtract it is quite different noone in their right mind would suggest that. These would be  possible methods on integers and variables but they seem utterly redundant arr[17].subtract(5), arr[17].add(5) 

Well if there also was a method working on variables called .delete i don't see it would mean a shit, unless you specify it in the programming language. Or did you have a suggestion?
And since operators like +,- already part of the arithmetic operations i don't see the use of any of them working on variables or values.

Your point is lost to me.

[toc] | [prev] | [next] | [standalone]

#35716

From	John G Harris <niam@jghnorth.org.uk.invalid>
Date	2018-09-27 19:42 +0100
Message-ID	<m49qqdt8mtmn94balupllsso3h8e4do9d7@4ax.com>
In reply to	#35715

On Thu, 27 Sep 2018 03:38:09 -0700 (PDT), Jonas Thörnvall
<jonas.thornvall@gmail.com> wrote:

  <snip>
>Your point is lost to me.

You don't know what a[3] means in this or any other programming
language. No wonder we are having trouble helping you.

  John

[toc] | [prev] | [next] | [standalone]

#35717

From	Jonas Thörnvall <jonas.thornvall@gmail.com>
Date	2018-09-27 14:44 -0700
Message-ID	<893e1584-7655-40c1-b698-1b9a33472e7b@googlegroups.com>
In reply to	#35716

Den torsdag 27 september 2018 kl. 20:42:56 UTC+2 skrev John G Harris:
> On Thu, 27 Sep 2018 03:38:09 -0700 (PDT), Jonas Thörnvall
> <jonas.thornvall@gmail.com> wrote:
> 
>   <snip>
> >Your point is lost to me.
> 
> You don't know what a[3] means in this or any other programming
> language. No wonder we are having trouble helping you.
> 
>   John

It is the index 3 of array a You are just confused, and the index is just a pointer to some stack of data.

[toc] | [prev] | [next] | [standalone]

#35718

From	Jonas Thörnvall <jonas.thornvall@gmail.com>
Date	2018-09-27 14:48 -0700
Message-ID	<599efd9b-5154-4085-a0ca-a60c6a766cf9@googlegroups.com>
In reply to	#35716

Den torsdag 27 september 2018 kl. 20:42:56 UTC+2 skrev John G Harris:
> On Thu, 27 Sep 2018 03:38:09 -0700 (PDT), Jonas Thörnvall
> <jonas.thornvall@gmail.com> wrote:
> 
>   <snip>
> >Your point is lost to me.
> 
> You don't know what a[3] means in this or any other programming
> language. No wonder we are having trouble helping you.
> 
>   John

Well actually array i have no problem with, objects in javascript i beleive behave weird though.

http://anybase.co.nf/index.html

[toc] | [prev] | [next] | [standalone]

#35719

From	Thomas 'PointedEars' Lahn <PointedEars@web.de>
Date	2018-09-28 21:04 +0200
Message-ID	<46cf39ce-0411-f576-198a-21b876b1b45d@PointedEars.de>
In reply to	#35716

</killfile>

John G Harris wrote:
> On Thu, 27 Sep 2018 03:38:09 -0700 (PDT), Jonas Thörnvall
> <jonas.thornvall@gmail.com> wrote:
> 
>   <snip>
>> Your point is lost to me.
> 
> You don't know what a[3] means in this or any other programming
> language. No wonder we are having trouble helping you.

To be fair, not all operations work the same in all programming languages.

IIRC, Jonas Thörnvall was coming from Python (a programming language that
I like, too), in which there is

  ".".join(["foo", "bar"]) == "foo.bar"

  "foo.bar".split(".")

instead of the ECMAScript-like

  ["foo", "bar"].join(".") == "foo.bar"

  "foo.bar".split(".")

(I find the latter more intuitive, but the former is just how things work
in Python.  One must learn to accept the things that one cannot change.)

So someone with superficial knowledge in programming in general, or Python
in particuloar, could get the idea that it should always work in the former way.

With that said,

  a[3]

for an object referred to by “a” that is an instance of a subtype/subclass
of the “list” type/class conceptually works exactly the same in Python as it
does in ECMAScript for an Array-like object referred to by “a”, e.g.

  ["foo", "bar", "baz", "bla"][3] == "bla"

in both languages/language families.

As you indicated, it matters what an expression resolves to.  Chaining
cannot be arbitrary.

  track[recTrack].midiMess[trackevent].splice(1);

to splice

  track[recTrack].midiMess

would require an unnecessarily complex implementation where an element of a
list/Array-like object would have to keep a reference to its owner so that
it "knew" what the owner’s element with index 1 was.  As an element can be a
reference to an object, and that object can be referred by several other
objects (“owners”), there is no clear owner for a referred object, and
automatically modifying all owners is not only inefficient, it also usually
makes no sense.

            ,---------.   ,------------.   ,---------.
  track --->: : Array :   :  : Object  :   : : Array :
            :---------:   :------------:   :---------:   ,-----------------.
            : +0 -------->: +midiMess ---->: +0 -------->: : Object        :
            : +1      :   `------------'   : +1      :   :-----------------:
            : ...     :                    : +2      :   : ...             :
            :         :                    `---------'   :                 :
            :         :                                  :                 :
            `---------'                 ,------------.   :-----------------:
                                        : : Function :<--- +splice(Number) :
                                        :------------:   `-----------------'
                                        : ...        :            ^
                                        :------------:            : What
                                        : -[[Call]]  :            : now?
                                        : ...        :            :
                                        `------------'         myTrack

    [That is why I recommended to draw a diagram.]

This would also violate the *Law of Demeter*, which for object-oriented
programming can be formulated as follows:

  An object should only access its *own* properties directly; access to the
  properties of other objects should be performed using only the methods
  provided by those objects.

    [“property” means only non-callable attributes of an object here.
     This is not generally true in ECMAScript where methods are implemented
     as properties whose value is a reference to a callable object.  Also,
     implicit getters and setters, methods *declaratively* attached to read
     and write access to a property, blur the difference between properties
     and methods (in that sense).]

Otherwise, if the internal data structure encapsulated by the other object
would change, the direct property accesses in the accessing code would have
to be modified as well.

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

It is often indicated by one or more leading underscore characters [“_”] in
the property/attribute name that a property/attribute is not suited to be
referenced directly from outside the object’s code.  Those
properties/attributes are often implemented or designated “private” or
“protected”.

AFAIK, in all current ECMAScript implementations this distinction still
cannot be declared built-in; workarounds like the module pattern exist instead.

See also:

<https://github.com/tc39/proposal-class-fields#private-fields>

found in

<https://stackoverflow.com/a/52237988/855543>

and

<https://tc39.github.io/proposal-class-fields/>

found through

<https://stackoverflow.com/a/22160051/855543>

<killfile>

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

[toc] | [prev] | [next] | [standalone]

#35728

From	Jonas Thörnvall <jonas.thornvall@gmail.com>
Date	2018-10-02 12:47 -0700
Message-ID	<a5028a2d-ca08-4ade-8734-06b7fdc925d0@googlegroups.com>
In reply to	#35719

Den fredag 28 september 2018 kl. 21:04:41 UTC+2 skrev Thomas 'PointedEars' Lahn:
> </killfile>
> 
> John G Harris wrote:
> > On Thu, 27 Sep 2018 03:38:09 -0700 (PDT), Jonas Thörnvall
> > <jonas.thornvall@gmail.com> wrote:
> > 
> >   <snip>
> >> Your point is lost to me.
> > 
> > You don't know what a[3] means in this or any other programming
> > language. No wonder we are having trouble helping you.
> 
> To be fair, not all operations work the same in all programming languages.
> 
> IIRC, Jonas Thörnvall was coming from Python (a programming language that
> I like, too), in which there is
> 
>   ".".join(["foo", "bar"]) == "foo.bar"
> 
>   "foo.bar".split(".")
> 
> instead of the ECMAScript-like
> 
>   ["foo", "bar"].join(".") == "foo.bar"
> 
>   "foo.bar".split(".")
> 
> (I find the latter more intuitive, but the former is just how things work
> in Python.  One must learn to accept the things that one cannot change.)
> 
> So someone with superficial knowledge in programming in general, or Python
> in particuloar, could get the idea that it should always work in the former way.
> 
> With that said,
> 
>   a[3]
> 
> for an object referred to by “a” that is an instance of a subtype/subclass
> of the “list” type/class conceptually works exactly the same in Python as it
> does in ECMAScript for an Array-like object referred to by “a”, e.g.
> 
>   ["foo", "bar", "baz", "bla"][3] == "bla"
> 
> in both languages/language families.
> 
> As you indicated, it matters what an expression resolves to.  Chaining
> cannot be arbitrary.
> 
>   track[recTrack].midiMess[trackevent].splice(1);
> 
> to splice
> 
>   track[recTrack].midiMess
> 
> would require an unnecessarily complex implementation where an element of a
> list/Array-like object would have to keep a reference to its owner so that
> it "knew" what the owner’s element with index 1 was.  As an element can be a
> reference to an object, and that object can be referred by several other
> objects (“owners”), there is no clear owner for a referred object, and
> automatically modifying all owners is not only inefficient, it also usually
> makes no sense.
> 
>             ,---------.   ,------------.   ,---------.
>   track --->: : Array :   :  : Object  :   : : Array :
>             :---------:   :------------:   :---------:   ,-----------------.
>             : +0 -------->: +midiMess ---->: +0 -------->: : Object        :
>             : +1      :   `------------'   : +1      :   :-----------------:
>             : ...     :                    : +2      :   : ...             :
>             :         :                    `---------'   :                 :
>             :         :                                  :                 :
>             `---------'                 ,------------.   :-----------------:
>                                         : : Function :<--- +splice(Number) :
>                                         :------------:   `-----------------'
>                                         : ...        :            ^
>                                         :------------:            : What
>                                         : -[[Call]]  :            : now?
>                                         : ...        :            :
>                                         `------------'         myTrack
> 
>     [That is why I recommended to draw a diagram.]
> 
> This would also violate the *Law of Demeter*, which for object-oriented
> programming can be formulated as follows:
> 
>   An object should only access its *own* properties directly; access to the
>   properties of other objects should be performed using only the methods
>   provided by those objects.
> 
>     [“property” means only non-callable attributes of an object here.
>      This is not generally true in ECMAScript where methods are implemented
>      as properties whose value is a reference to a callable object.  Also,
>      implicit getters and setters, methods *declaratively* attached to read
>      and write access to a property, blur the difference between properties
>      and methods (in that sense).]
> 
> Otherwise, if the internal data structure encapsulated by the other object
> would change, the direct property accesses in the accessing code would have
> to be modified as well.
> 
> <https://en.wikipedia.org/wiki/Law_of_Demeter>
> 
> It is often indicated by one or more leading underscore characters [“_”] in
> the property/attribute name that a property/attribute is not suited to be
> referenced directly from outside the object’s code.  Those
> properties/attributes are often implemented or designated “private” or
> “protected”.
> 
> AFAIK, in all current ECMAScript implementations this distinction still
> cannot be declared built-in; workarounds like the module pattern exist instead.
> 
> See also:
> 
> <https://github.com/tc39/proposal-class-fields#private-fields>
> 
> found in
> 
> <https://stackoverflow.com/a/52237988/855543>
> 
> and
> 
> <https://tc39.github.io/proposal-class-fields/>
> 
> found through
> 
> <https://stackoverflow.com/a/22160051/855543>
> 
> 
> <killfile>
> 
> -- 
> 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.

Well Thomas you seem to think that the semantic choice that makeup/create the of syntax should reflect, how things stored internally.

That is just bullocks and you know it. No it should reflect what people intend to do in simplest most obvious manner.

[toc] | [prev] | [next] | [standalone]

#35729

From	John G Harris <niam@jghnorth.org.uk.invalid>
Date	2018-10-03 18:19 +0100
Message-ID	<hfu9rdlp73vp5paksc2h3ogvcsqf3f0t2g@4ax.com>
In reply to	#35728

On Tue, 2 Oct 2018 12:47:03 -0700 (PDT), Jonas Thörnvall
<jonas.thornvall@gmail.com> wrote:

  <snip>
>Well Thomas you seem to think that the semantic choice that makeup/create the of syntax should reflect, how things stored internally.
>
>That is just bullocks and you know it. No it should reflect what people intend to do in simplest most obvious manner.

What people intend to do with a[3] is to get hold of the value held in
element 3 of the array and do something with it.

If the value is a number then they can add it to another number.

If the value is a string then they can display it.

If the value is a function object then they can call it.

If the value is some other kind of object then they can do whatever is
possible with that kind of object.

Why isn't that most obvious ?

  John

[toc] | [prev] | [next] | [standalone]

#35730

From	Jonas Thörnvall <jonas.thornvall@gmail.com>
Date	2018-10-04 05:43 -0700
Message-ID	<eb7405e5-cba5-4d5e-a095-52b1938f3b15@googlegroups.com>
In reply to	#35729

Den onsdag 3 oktober 2018 kl. 19:19:28 UTC+2 skrev John G Harris:
> On Tue, 2 Oct 2018 12:47:03 -0700 (PDT), Jonas Thörnvall
> <jonas.thornvall@gmail.com> wrote:
> 
>   <snip>
> >Well Thomas you seem to think that the semantic choice that makeup/create the of syntax should reflect, how things stored internally.
> >
> >That is just bullocks and you know it. No it should reflect what people intend to do in simplest most obvious manner.
> 
> What people intend to do with a[3] is to get hold of the value held in
> element 3 of the array and do something with it.
> 
> If the value is a number then they can add it to another number.
> 
> If the value is a string then they can display it.
> 
> If the value is a function object then they can call it.
> 
> If the value is some other kind of object then they can do whatever is
> possible with that kind of object.
> 
> Why isn't that most obvious ?
> 
>   John

Well you are certainly lost on me that is exactly my point, when you want to delete, insert or update an array element you use the index.

Not a parameter to the method.

[toc] | [prev] | [next] | [standalone]

#35731

From	John G Harris <niam@jghnorth.org.uk.invalid>
Date	2018-10-05 18:17 +0100
Message-ID	<q37frdhcqv0nl1jq07bbm71o2pm756beps@4ax.com>
In reply to	#35730

On Thu, 4 Oct 2018 05:43:15 -0700 (PDT), Jonas Thörnvall
<jonas.thornvall@gmail.com> wrote:

  <snip>
>Well you are certainly lost on me that is exactly my point, when you want to delete, insert or update an array element you use the index.
>
>Not a parameter to the method.


var a = new Array();

a[3] = 5;      // Insert element 3

a[3] = 7;      // Update element 3

a[3] = null;   // Nullify element 3


What's the problem ?

  John

[toc] | [prev] | [next] | [standalone]

#35732

From	"Evertjan." <exxjxw.hannivoort@inter.nl.net>
Date	2018-10-05 22:37 +0200
Message-ID	<XnsA972E633C835Feejj99@194.109.6.166>
In reply to	#35731

John G Harris <niam@jghnorth.org.uk.invalid> wrote on 05 Oct 2018 in
comp.lang.javascript: 

> var a = new Array();
> 
> a[3] = 5;      // Insert element 3
> 
> a[3] = 7;      // Update element 3
> 
> a[3] = null;   // Nullify element 3

Warning: Null and empty are not the same:

var a = new Array();
a[1] = 22;
a[3] = 7;
a[3] = null;
console.log(a); // (4) [empty, 22, empty, null]
delete(a[3]);
console.log(a); // (4) [empty, 22, empty × 2]
a.length = 2;
console.log(a); // (2) [empty, 22]
a.length = 222;
console.log(a); // (222) [empty, 22, empty × 220]



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

[toc] | [prev] | [next] | [standalone]

#35734

From	John G Harris <niam@jghnorth.org.uk.invalid>
Date	2018-10-06 14:30 +0100
Message-ID	<p0ehrd1mjbo6moe0rre4f0ie4gpaeq938v@4ax.com>
In reply to	#35732

On Fri, 05 Oct 2018 22:37:47 +0200, "Evertjan."
<exxjxw.hannivoort@inter.nl.net> wrote:

>John G Harris <niam@jghnorth.org.uk.invalid> wrote on 05 Oct 2018 in
>comp.lang.javascript: 
>
>> var a = new Array();
>> 
>> a[3] = 5;      // Insert element 3
>> 
>> a[3] = 7;      // Update element 3
>> 
>> a[3] = null;   // Nullify element 3
>
>Warning: Null and empty are not the same:
  <snip>

True, and
  delete a[3];
deletes the entry, but Jonas doesn't understand a[3] on its own, he
says. Also splice doesn't really delete in the usual sense. It's more
a case of moving entries. In particular, the entries covered by the
deleteCount are moved to a new array.

  John

[toc] | [prev] | [next] | [standalone]

#35742

From	Jonas Thörnvall <jonas.thornvall@gmail.com>
Date	2018-10-07 09:57 -0700
Message-ID	<047dac02-a257-4e7f-b54d-17bc78ef2c74@googlegroups.com>
In reply to	#35731

Den fredag 5 oktober 2018 kl. 19:17:22 UTC+2 skrev John G Harris:
> On Thu, 4 Oct 2018 05:43:15 -0700 (PDT), Jonas Thörnvall
> <jonas.thornvall@gmail.com> wrote:
> 
>   <snip>
> >Well you are certainly lost on me that is exactly my point, when you want to delete, insert or update an array element you use the index.
> >
> >Not a parameter to the method.
> 
> 
> var a = new Array();
> 
> a[3] = 5;      // Insert element 3
LoL that is no insert into a filled array that is an update... see below

> 
> a[3] = 7;      // Update element 3

LoL that does actually update the array, no need for splice.

> a[3] = null;   // Nullify element 3

LoL no that does not remove the index you will have alot of empty slots with that approach not nice at all having a case with null elements in your array.

> 
> 
> What's the problem ?
> 
>   John

The problem is to "insert and delete" elements in an array the idiots that made up javascript came up with the halfbaked idiot phrase splice that use the index as a paramterer to insert and delete.

var months = ['Jan', 'March', 'April', 'June'];
months.splice(1, 0, 'Feb');
// inserts at 1st index position
console.log(months);
// expected output: Array ['Jan', 'Feb', 'March', 'April', 'June']

months.splice(4, 1, 'May');
// replaces 1 element at 4th index
console.log(months);
// expected output: Array ['Jan', 'Feb', 'March', 'April', 'May']

months.splice(index, 1);
//deletes element at index

I told them the syntax is idiotic not readable.... because you can't see what is going on reading it.

a.splice(3, 5, "splish", "splosh"); //WTF try read that and come up with what that syntax is supposed to do by reading it.

Compare with something that is "symantically coherent", and that  a normal brain would come up with.

a[3].delete(5).insert("splish,"splosh"); 
I mean anyone who knows what an array is will immediately see what is going on.

Parameter forking readable "would not think so".... Of course it works but it looks like shit and is confusing when reading code.
Today i spliced myself.

[toc] | [prev] | [next] | [standalone]

#35744

From	"Evertjan." <exxjxw.hannivoort@inter.nl.net>
Date	2018-10-07 23:08 +0200
Message-ID	<XnsA974EB7A8C7E5eejj99@194.109.6.166>
In reply to	#35742

<jonas.thornvall@gmail.com> wrote on 07 Oct 2018 in comp.lang.javascript:
>  the idiots that made up javascript 

Dear Jonas,

What a convoluted idea.

If someone has a crazy idea, that does not mean he is crazy.

Please stop demeaning people if you attack an idea.

I do not think you are crazy, but your above utterance is.

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

[toc] | [prev] | [next] | [standalone]

#35753

From	John G Harris <niam@jghnorth.org.uk.invalid>
Date	2018-10-08 19:43 +0100
Message-ID	<389nrdhs26fgu6v4795itvrc6jm86k4lds@4ax.com>
In reply to	#35742

On Sun, 7 Oct 2018 09:57:51 -0700 (PDT), Jonas Thörnvall
<jonas.thornvall@gmail.com> wrote:

>Den fredag 5 oktober 2018 kl. 19:17:22 UTC+2 skrev John G Harris:
>> On Thu, 4 Oct 2018 05:43:15 -0700 (PDT), Jonas Thörnvall
>> <jonas.thornvall@gmail.com> wrote:
>> 
>>   <snip>
>> >Well you are certainly lost on me that is exactly my point, when you want to delete, insert or update an array element you use the index.
>> >
>> >Not a parameter to the method.
>> 
>> 
>> var a = new Array();
>> 
>> a[3] = 5;      // Insert element 3
>LoL that is no insert into a filled array that is an update... see below

It is an insert. The expression new Array() creates an array with no
elements. Putting an element into an empty array is an insert action.

  <snip>
>Compare with something that is "symantically coherent", and that  a normal brain would come up with.
>
>a[3].delete(5).insert("splish,"splosh"); 
>I mean anyone who knows what an array is will immediately see what is going on.
  <snip>

No, there's a better way :
  a.splice( start = 3, removeCnt = 5, insert = ["splish", "splosh"] );

Some programming languages let you do it this way. The closest to that
in ECMAScript is to have the function require you to supply an object
with its properties :
  a.splice( {start:3, removeCnt:5, insert:["splish", "splosh"]} );

A problem with your suggestion is that there is no way to return a new
array containing the removed entries. Some people will want that
array.

  John

[toc] | [prev] | [next] | [standalone]

#35735

From	Thomas 'PointedEars' Lahn <PointedEars@web.de>
Date	2018-10-06 18:04 +0200
Message-ID	<b1d06603-719d-55ea-4349-d57fd4bc147a@PointedEars.de>
In reply to	#35729

</killfile>

John G Harris wrote:
> On Tue, 2 Oct 2018 12:47:03 -0700 (PDT), Jonas Thörnvall
> <jonas.thornvall@gmail.com> wrote:
> 
>   <snip>
>> Well Thomas you seem to think that the semantic choice that makeup/create the of syntax should reflect, how things stored internally.
>>
>> That is just bullocks and you know it. No it should reflect what people intend to do in simplest most obvious manner.
> 
> What people intend to do with a[3] is to get hold of the value held in
> element 3 of the array and do something with it.

element _4_, as the index is usually 0-based

<killfile>


PointedEars
-- 
    realism:    HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness:    XHTML 1.1 as application/xhtml+xml
                                                    -- Bjoern Hoehrmann

[toc] | [prev] | [next] | [standalone]

#35739

From	John G Harris <niam@jghnorth.org.uk.invalid>
Date	2018-10-07 10:14 +0100
Message-ID	<kfjjrdtpapskjorces6phakbvuqck1t3f2@4ax.com>
In reply to	#35735

On Sat, 6 Oct 2018 18:04:25 +0200, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

></killfile>
>
>John G Harris wrote:
  <snip>

Dear me, a 3 line attribution novel from Thomas!

>> What people intend to do with a[3] is to get hold of the value held in
>> element 3 of the array and do something with it.
>
>element _4_, as the index is usually 0-based

What a load of bollocks.

Element 0 is the first element.
Element 1 is the second element.
Element 2 is the third element.
Element 3 is the fourth element, not element 4 as any fule kno.

  John

[toc] | [prev] | [next] | [standalone]

#35741

From	Thomas 'PointedEars' Lahn <PointedEars@web.de>
Date	2018-10-07 15:15 +0200
Message-ID	<80014561-6cfc-d986-f637-f8b52a8f2457@PointedEars.de>
In reply to	#35739

</killfile>

John G Harris wrote:
> On Sat, 6 Oct 2018 18:04:25 +0200, Thomas 'PointedEars' Lahn
> <PointedEars@web.de> wrote:
> 
>> </killfile>
>>
>> John G Harris wrote:
>   <snip>
> 
> Dear me, a 3 line attribution novel from Thomas!

Idiot.

>>> What people intend to do with a[3] is to get hold of the value held in
>>> element 3 of the array and do something with it.
>>
>> element _4_, as the index is usually 0-based
> 
> What a load of bollocks.
> 
> Element 0 is the first element.
          ^        ^^^^^
> Element 1 is the second element.
> Element 2 is the third element.
> Element 3 is the fourth element, not element 4 as any fule kno.
                   ^^^^^^^^^^^^^^      ^^^^^^^^^
Idiot.

<killfile>

PointedEars
-- 
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
  -- Richard Cornford, cljs, <cife6q$253$1$8300dec7@news.demon.co.uk> (2004)

[toc] | [prev] | [next] | [standalone]

#35757

From	John G Harris <niam@jghnorth.org.uk.invalid>
Date	2018-10-09 10:38 +0100
Message-ID	<2ntordlikb6ktp76plj1pr7hmcku84bm8l@4ax.com>
In reply to	#35741

On Sun, 7 Oct 2018 15:15:42 +0200, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

></killfile>
>
>John G Harris wrote:
>> On Sat, 6 Oct 2018 18:04:25 +0200, Thomas 'PointedEars' Lahn
>> <PointedEars@web.de> wrote:
>> 
>>> </killfile>
>>>
>>> John G Harris wrote:
>>   <snip>
>> 
>> Dear me, a 3 line attribution novel from Thomas!
>
>Idiot.

A well reasoned and concise argument.

Thomas screams at people who use two lines to say which article is
being quoted. Then Thomas uses three lines.

Idiot is not really the right word. Hypocrite is the word.

>>>> What people intend to do with a[3] is to get hold of the value held in
>>>> element 3 of the array and do something with it.
>>>
>>> element _4_, as the index is usually 0-based
>> 
>> What a load of bollocks.
>> 
>> Element 0 is the first element.
>          ^        ^^^^^
>> Element 1 is the second element.
>> Element 2 is the third element.
>> Element 3 is the fourth element, not element 4 as any fule kno.
>                   ^^^^^^^^^^^^^^      ^^^^^^^^^
>Idiot.

This year is the nineth year of the second decade of the first
centuary of the third millenium. So Thomas insists that you write 
  3129  instead  of 2018.
Idiot indeed.

Thomas has forgotten that 'first' has two meanings. It can imply the
number 1, or it can say the foremost, the thing at the front of the
queue, the top football club in the league, regardless of whether it
is numbered 0, 1, or 77.

  John

[toc] | [prev] | [next] | [standalone]

#35758

From	dr.s.lartius@gmail.com
Date	2018-10-09 08:27 -0700
Message-ID	<78062652-4d3f-4c09-a996-2dab5171ab80@googlegroups.com>
In reply to	#35757

On Tuesday, October 9, 2018 at 10:38:25 AM UTC+1, John G Harris wrote:

> This year is the nineth year of the second decade of the first
> centuary of the third millenium.

Some, including myself and Chrome's spell-checker, would prefer :-

  "This year is the ninth year of the second decade of the first
  century of the third millennium." - but, except for astronomers,
  it is the eighth year.  A.D. 0 is noteworthy for non-existence.


ASIDE : In the evidently-misnamed product "Windows", is it possible
	for an ordinary programmer to make an editable window (not
	necessarily a browser window) or part-window, with DOM
	Textarea being an example, properly transparent, so that
	one can compose text overlaid on whatever would appear in
	that region if the editing application was minimised or
	closed?

	[ Misnamed, because one normally is able to see _through_
	  a _real_ glass window. ]

-- 
  (c) John Stockton, near London, UK.  Using Google Groups.           |
 Mail: J.R.""""""""@physics.org - or as Reply-To, if any.             |

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →

csiph-web

Ideas behind programming language syntax choices?

Contents

#35714

#35715

#35716

#35717

#35718

#35719

#35728

#35729

#35730

#35731

#35732

#35734

#35742

#35744

#35753

#35735

#35739

#35741

#35757

#35758