Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

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

Ideas behind programming language syntax choices?

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

Contents

  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 1 of 4  [1] 2 3 4  Next page →

#35622 — Ideas behind programming language syntax choices?

Often i find it a bit backward reading code, so i wonder a bit about the reason behind choices done in programming languages.

Why
track[recTrack].midiMess.splice(trackevent,1);
and not
track[recTrack].midiMess[trackevent].splice(1);

Isn't the later more readable, maybe it is just a personal preference?
But if you replace the indexname with just the index, the former make no sense if you do not know the parameter order. 

But the later is still readable right out of the box?
Well i could be wrong but i find the later more intuitive.

[toc] | [next] | [standalone]

#35642

</killfile>

Jonas Thörnvall wrote:
> Often i find it a bit backward reading code, so i wonder a bit about the
> reason behind choices done in programming languages.
> 
> Why track[recTrack].midiMess.splice(trackevent,1); and not 
> track[recTrack].midiMess[trackevent].splice(1);

Because they mean completely different things.

The first one is calling the splice() method of an object referred to by
“track[recTrack].midiMess”, i.e. specified by the property named “midiMess”
of the object referred to by “track[recTrack]”, passing to it a value
identified by “trackevent”, and the value 1.

The second one is calling the splice() method of an object referred to by
“track[recTrack].midiMess[trackevent]”, i.e. an object referred to by a
*property* of an object where the property *name* is specified by the
*value* of “trackevent”, passing to it the value 1.

(If that was too complex for you to understand, dissect the sentences and
draw a diagram.)

The object on which the standard splice() method is called is supposed to be
*Array*-like because of the way the method works.

> Isn't the later more readable, maybe it is just a personal preference?

Yes, it is not; and no, it is not.

> But if you replace the indexname with just the index, the former make no
> sense if you do not know the parameter order.

*You* are not making sense.

> But the later is still readable right out of the box?

It does not matter if a sentence is readable if it means something else than
what it replaces, or if it does not mean anything at all.

  The cat’s eye is looking at the mouse’s tail.

means something else than

  The cat’s mouse is looking at the eye’s tail.

Incidentally, the latter sentence is meaningless nonsense as is your
suggestion for alternative code.

> Well i could be wrong but i find the later more intuitive.

You will never succeed at software development in general, and programming
in particular, if you continue to go by gut feeling alone, ignoring logic.
I have observed you fiddling around with source code for several years now,
obviously without your gaining a deeper understanding of anything.

Why do you expect to make any progress with your current approach when it
has not helped you to make any considerable progress in the past?  Has it
not occurred to you by now that something with your approach to programming
might be deeply wrong?

I can promise you that one year, two years, three years aso. from now you
will still not have made any considerable progress unless you change your
approach to really *learning* these things *from the ground up*, *with
rigor* instead of your current sloppiness, and putting all your (illogical,
uninformed) preconceptions aside about how programming should be.

Mark my words.

<killfile>


PointedEars
-- 
When all you know is jQuery, every problem looks $(olvable).

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

#35645

Den lördag 22 september 2018 kl. 15:17:32 UTC+2 skrev Thomas 'PointedEars' Lahn:
> </killfile>
> 
> Jonas Thörnvall wrote:
> > Often i find it a bit backward reading code, so i wonder a bit about the
> > reason behind choices done in programming languages.
> > 
> > Why track[recTrack].midiMess.splice(trackevent,1); and not 
> > track[recTrack].midiMess[trackevent].splice(1);
> 
> Because they mean completely different things.
> 
> The first one is calling the splice() method of an object referred to by
> “track[recTrack].midiMess”, i.e. specified by the property named “midiMess”
> of the object referred to by “track[recTrack]”, passing to it a value
> identified by “trackevent”, and the value 1.
> 
> The second one is calling the splice() method of an object referred to by
> “track[recTrack].midiMess[trackevent]”, i.e. an object referred to by a
> *property* of an object where the property *name* is specified by the
> *value* of “trackevent”, passing to it the value 1.
> 
> (If that was too complex for you to understand, dissect the sentences and
> draw a diagram.)
> 
> The object on which the standard splice() method is called is supposed to be
> *Array*-like because of the way the method works.
> 
> > Isn't the later more readable, maybe it is just a personal preference?
> 
> Yes, it is not; and no, it is not.
> 
> > But if you replace the indexname with just the index, the former make no
> > sense if you do not know the parameter order.
> 
> *You* are not making sense.
> 
> > But the later is still readable right out of the box?
> 
> It does not matter if a sentence is readable if it means something else than
> what it replaces, or if it does not mean anything at all.
> 
>   The cat’s eye is looking at the mouse’s tail.
> 
> means something else than
> 
>   The cat’s mouse is looking at the eye’s tail.
> 
> Incidentally, the latter sentence is meaningless nonsense as is your
> suggestion for alternative code.
> 
> > Well i could be wrong but i find the later more intuitive.
> 
> You will never succeed at software development in general, and programming
> in particular, if you continue to go by gut feeling alone, ignoring logic.
> I have observed you fiddling around with source code for several years now,
> obviously without your gaining a deeper understanding of anything.
> 
> Why do you expect to make any progress with your current approach when it
> has not helped you to make any considerable progress in the past?  Has it
> not occurred to you by now that something with your approach to programming
> might be deeply wrong?
> 
> I can promise you that one year, two years, three years aso. from now you
> will still not have made any considerable progress unless you change your
> approach to really *learning* these things *from the ground up*, *with
> rigor* instead of your current sloppiness, and putting all your (illogical,
> uninformed) preconceptions aside about how programming should be.
> 
> Mark my words.
> 
> <killfile>
> 
> 
> PointedEars
> -- 
> When all you know is jQuery, every problem looks $(olvable).

You are indeed a prisoner of your own faulthy idea world Thomas.
What you want to do is to splice the element midiMess[index].splice(one in a million you low IQ moron, 1 to whatever below 100)

Only a total idiot or someone building fantasy castles would think otherwise.

Only lowIQ idiots would create a syntax where splice is a parmeter upon array.
midiMess.splice(trackevent,1); 

You see the cardhouse you built is wrong altogehter both lexical and semantical outside javascript. You do not splice a parameter, you some splice some elements using a specific engine.

Now you little lowIQ bastard go do that IQ test, and get it confirmed you are not even average.

When they set lowIQ people like you to be caretakers of programming languages they always in the end to be useless and abandoned because in the the end the actual syntax to do something get ridiculous. 

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

#35646

Den lördag 22 september 2018 kl. 15:17:32 UTC+2 skrev Thomas 'PointedEars' Lahn:
> </killfile>
> 
> Jonas Thörnvall wrote:
> > Often i find it a bit backward reading code, so i wonder a bit about the
> > reason behind choices done in programming languages.
> > 
> > Why track[recTrack].midiMess.splice(trackevent,1); and not 
> > track[recTrack].midiMess[trackevent].splice(1);
> 
> Because they mean completely different things.
> 
> The first one is calling the splice() method of an object referred to by
> “track[recTrack].midiMess”, i.e. specified by the property named “midiMess”
> of the object referred to by “track[recTrack]”, passing to it a value
> identified by “trackevent”, and the value 1.
> 
> The second one is calling the splice() method of an object referred to by
> “track[recTrack].midiMess[trackevent]”, i.e. an object referred to by a
> *property* of an object where the property *name* is specified by the
> *value* of “trackevent”, passing to it the value 1.
> 
> (If that was too complex for you to understand, dissect the sentences and
> draw a diagram.)
> 
> The object on which the standard splice() method is called is supposed to be
> *Array*-like because of the way the method works.
> 
> > Isn't the later more readable, maybe it is just a personal preference?
> 
> Yes, it is not; and no, it is not.
> 
> > But if you replace the indexname with just the index, the former make no
> > sense if you do not know the parameter order.
> 
> *You* are not making sense.
> 
> > But the later is still readable right out of the box?
> 
> It does not matter if a sentence is readable if it means something else than
> what it replaces, or if it does not mean anything at all.
> 
>   The cat’s eye is looking at the mouse’s tail.
> 
> means something else than
> 
>   The cat’s mouse is looking at the eye’s tail.
> 
> Incidentally, the latter sentence is meaningless nonsense as is your
> suggestion for alternative code.
> 
> > Well i could be wrong but i find the later more intuitive.
> 
> You will never succeed at software development in general, and programming
> in particular, if you continue to go by gut feeling alone, ignoring logic.
> I have observed you fiddling around with source code for several years now,
> obviously without your gaining a deeper understanding of anything.
> 
> Why do you expect to make any progress with your current approach when it
> has not helped you to make any considerable progress in the past?  Has it
> not occurred to you by now that something with your approach to programming
> might be deeply wrong?
> 
> I can promise you that one year, two years, three years aso. from now you
> will still not have made any considerable progress unless you change your
> approach to really *learning* these things *from the ground up*, *with
> rigor* instead of your current sloppiness, and putting all your (illogical,
> uninformed) preconceptions aside about how programming should be.
> 
> Mark my words.
> 
> <killfile>
> 
> 
> PointedEars
> -- 
> When all you know is jQuery, every problem looks $(olvable).

If your actually part of some board making designing choices for ECMA/Javascript i feel sorry for the whole project, sooner or later the syntax will be so convoluted/polluted by bad ideas that it start to stink.

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

#35647

Den lördag 22 september 2018 kl. 19:31:37 UTC+2 skrev Jonas Thörnvall:
> Den lördag 22 september 2018 kl. 15:17:32 UTC+2 skrev Thomas 'PointedEars' Lahn:
> > </killfile>
> > 
> > Jonas Thörnvall wrote:
> > > Often i find it a bit backward reading code, so i wonder a bit about the
> > > reason behind choices done in programming languages.
> > > 
> > > Why track[recTrack].midiMess.splice(trackevent,1); and not 
> > > track[recTrack].midiMess[trackevent].splice(1);
> > 
> > Because they mean completely different things.
> > 
> > The first one is calling the splice() method of an object referred to by
> > “track[recTrack].midiMess”, i.e. specified by the property named “midiMess”
> > of the object referred to by “track[recTrack]”, passing to it a value
> > identified by “trackevent”, and the value 1.
> > 
> > The second one is calling the splice() method of an object referred to by
> > “track[recTrack].midiMess[trackevent]”, i.e. an object referred to by a
> > *property* of an object where the property *name* is specified by the
> > *value* of “trackevent”, passing to it the value 1.
> > 
> > (If that was too complex for you to understand, dissect the sentences and
> > draw a diagram.)
> > 
> > The object on which the standard splice() method is called is supposed to be
> > *Array*-like because of the way the method works.
> > 
> > > Isn't the later more readable, maybe it is just a personal preference?
> > 
> > Yes, it is not; and no, it is not.
> > 
> > > But if you replace the indexname with just the index, the former make no
> > > sense if you do not know the parameter order.
> > 
> > *You* are not making sense.
> > 
> > > But the later is still readable right out of the box?
> > 
> > It does not matter if a sentence is readable if it means something else than
> > what it replaces, or if it does not mean anything at all.
> > 
> >   The cat’s eye is looking at the mouse’s tail.
> > 
> > means something else than
> > 
> >   The cat’s mouse is looking at the eye’s tail.
> > 
> > Incidentally, the latter sentence is meaningless nonsense as is your
> > suggestion for alternative code.
> > 
> > > Well i could be wrong but i find the later more intuitive.
> > 
> > You will never succeed at software development in general, and programming
> > in particular, if you continue to go by gut feeling alone, ignoring logic.
> > I have observed you fiddling around with source code for several years now,
> > obviously without your gaining a deeper understanding of anything.
> > 
> > Why do you expect to make any progress with your current approach when it
> > has not helped you to make any considerable progress in the past?  Has it
> > not occurred to you by now that something with your approach to programming
> > might be deeply wrong?
> > 
> > I can promise you that one year, two years, three years aso. from now you
> > will still not have made any considerable progress unless you change your
> > approach to really *learning* these things *from the ground up*, *with
> > rigor* instead of your current sloppiness, and putting all your (illogical,
> > uninformed) preconceptions aside about how programming should be.
> > 
> > Mark my words.
> > 
> > <killfile>
> > 
> > 
> > PointedEars
> > -- 
> > When all you know is jQuery, every problem looks $(olvable).
> 
> If your actually part of some board making designing choices for ECMA/Javascript i feel sorry for the whole project, sooner or later the syntax will be so convoluted/polluted by bad ideas that it start to stink.

Yeah the choice of syntax looks like shit and stink "blip,blop semantics"

track[tracknr].midiMess.splice(trackEvent,0,{time:instime,data0:144,data1:insnote,data2:insvel}); 

No in a logical language with working semantics it should be

track[tracknr].midiMess[trackEvent].splice(0,{time:instime,data0:144,data1:insnote,data2:insvel});

Only lowIQ morons would chose the former syntax.

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

#35648

Den lördag 22 september 2018 kl. 19:39:29 UTC+2 skrev Jonas Thörnvall:
> Den lördag 22 september 2018 kl. 19:31:37 UTC+2 skrev Jonas Thörnvall:
> > Den lördag 22 september 2018 kl. 15:17:32 UTC+2 skrev Thomas 'PointedEars' Lahn:
> > > </killfile>
> > > 
> > > Jonas Thörnvall wrote:
> > > > Often i find it a bit backward reading code, so i wonder a bit about the
> > > > reason behind choices done in programming languages.
> > > > 
> > > > Why track[recTrack].midiMess.splice(trackevent,1); and not 
> > > > track[recTrack].midiMess[trackevent].splice(1);
> > > 
> > > Because they mean completely different things.
> > > 
> > > The first one is calling the splice() method of an object referred to by
> > > “track[recTrack].midiMess”, i.e. specified by the property named “midiMess”
> > > of the object referred to by “track[recTrack]”, passing to it a value
> > > identified by “trackevent”, and the value 1.
> > > 
> > > The second one is calling the splice() method of an object referred to by
> > > “track[recTrack].midiMess[trackevent]”, i.e. an object referred to by a
> > > *property* of an object where the property *name* is specified by the
> > > *value* of “trackevent”, passing to it the value 1.
> > > 
> > > (If that was too complex for you to understand, dissect the sentences and
> > > draw a diagram.)
> > > 
> > > The object on which the standard splice() method is called is supposed to be
> > > *Array*-like because of the way the method works.
> > > 
> > > > Isn't the later more readable, maybe it is just a personal preference?
> > > 
> > > Yes, it is not; and no, it is not.
> > > 
> > > > But if you replace the indexname with just the index, the former make no
> > > > sense if you do not know the parameter order.
> > > 
> > > *You* are not making sense.
> > > 
> > > > But the later is still readable right out of the box?
> > > 
> > > It does not matter if a sentence is readable if it means something else than
> > > what it replaces, or if it does not mean anything at all.
> > > 
> > >   The cat’s eye is looking at the mouse’s tail.
> > > 
> > > means something else than
> > > 
> > >   The cat’s mouse is looking at the eye’s tail.
> > > 
> > > Incidentally, the latter sentence is meaningless nonsense as is your
> > > suggestion for alternative code.
> > > 
> > > > Well i could be wrong but i find the later more intuitive.
> > > 
> > > You will never succeed at software development in general, and programming
> > > in particular, if you continue to go by gut feeling alone, ignoring logic.
> > > I have observed you fiddling around with source code for several years now,
> > > obviously without your gaining a deeper understanding of anything.
> > > 
> > > Why do you expect to make any progress with your current approach when it
> > > has not helped you to make any considerable progress in the past?  Has it
> > > not occurred to you by now that something with your approach to programming
> > > might be deeply wrong?
> > > 
> > > I can promise you that one year, two years, three years aso. from now you
> > > will still not have made any considerable progress unless you change your
> > > approach to really *learning* these things *from the ground up*, *with
> > > rigor* instead of your current sloppiness, and putting all your (illogical,
> > > uninformed) preconceptions aside about how programming should be.
> > > 
> > > Mark my words.
> > > 
> > > <killfile>
> > > 
> > > 
> > > PointedEars
> > > -- 
> > > When all you know is jQuery, every problem looks $(olvable).
> > 
> > If your actually part of some board making designing choices for ECMA/Javascript i feel sorry for the whole project, sooner or later the syntax will be so convoluted/polluted by bad ideas that it start to stink.
> 
> Yeah the choice of syntax looks like shit and stink "blip,blop semantics"
> 
> track[tracknr].midiMess.splice(trackEvent,0,{time:instime,data0:144,data1:insnote,data2:insvel}); 
> 
> No in a logical language with working semantics it should be
> 
> track[tracknr].midiMess[trackEvent].splice(0,{time:instime,data0:144,data1:insnote,data2:insvel});
> 
> Only lowIQ morons would chose the former syntax.

For fuck sake the index is a property of the array not of the object you fucking idiots.

You have to have a fucking weird polluted brain to come with your syntax choices, they are built around some weird fucking paper model of object oriented programming, that isn't even coherent.

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

#35649

Den lördag 22 september 2018 kl. 15:17:32 UTC+2 skrev Thomas 'PointedEars' Lahn:
> </killfile>
> 
> Jonas Thörnvall wrote:
> > Often i find it a bit backward reading code, so i wonder a bit about the
> > reason behind choices done in programming languages.
> > 
> > Why track[recTrack].midiMess.splice(trackevent,1); and not 
> > track[recTrack].midiMess[trackevent].splice(1);
> 
> Because they mean completely different things.
> 
> The first one is calling the splice() method of an object referred to by
> “track[recTrack].midiMess”, i.e. specified by the property named “midiMess”
> of the object referred to by “track[recTrack]”, passing to it a value
> identified by “trackevent”, and the value 1.
> 
> The second one is calling the splice() method of an object referred to by
> “track[recTrack].midiMess[trackevent]”, i.e. an object referred to by a
> *property* of an object where the property *name* is specified by the
> *value* of “trackevent”, passing to it the value 1.
> 
> (If that was too complex for you to understand, dissect the sentences and
> draw a diagram.)
> 
> The object on which the standard splice() method is called is supposed to be
> *Array*-like because of the way the method works.
> 
> > Isn't the later more readable, maybe it is just a personal preference?
> 
> Yes, it is not; and no, it is not.
> 
> > But if you replace the indexname with just the index, the former make no
> > sense if you do not know the parameter order.
> 
> *You* are not making sense.
> 
> > But the later is still readable right out of the box?
> 
> It does not matter if a sentence is readable if it means something else than
> what it replaces, or if it does not mean anything at all.
> 
>   The cat’s eye is looking at the mouse’s tail.
> 
> means something else than
> 
>   The cat’s mouse is looking at the eye’s tail.
> 
> Incidentally, the latter sentence is meaningless nonsense as is your
> suggestion for alternative code.
> 
> > Well i could be wrong but i find the later more intuitive.
> 
> You will never succeed at software development in general, and programming
> in particular, if you continue to go by gut feeling alone, ignoring logic.
> I have observed you fiddling around with source code for several years now,
> obviously without your gaining a deeper understanding of anything.
> 
> Why do you expect to make any progress with your current approach when it
> has not helped you to make any considerable progress in the past?  Has it
> not occurred to you by now that something with your approach to programming
> might be deeply wrong?
> 
> I can promise you that one year, two years, three years aso. from now you
> will still not have made any considerable progress unless you change your
> approach to really *learning* these things *from the ground up*, *with
> rigor* instead of your current sloppiness, and putting all your (illogical,
> uninformed) preconceptions aside about how programming should be.
> 
> Mark my words.
> 
> <killfile>
> 
> 
> PointedEars
> -- 
> When all you know is jQuery, every problem looks $(olvable).

https://www.youtube.com/watch?v=INXyVlF8IRk&feature=share

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

#35652

</killfile>

Jonas Thörnvall full-quoted, and replied with nonsense and insults to,
the same posting for the fifth(!) time within four(!) hours:

> […]
> 
> https://www.youtube.com/watch?v=INXyVlF8IRk&feature=share

<https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect>
<https://en.wikipedia.org/wiki/Logorrhea_(psychology)>

Hopeless case.

*PLONK*


PointedEars

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

#35653

Den söndag 23 september 2018 kl. 09:14:48 UTC+2 skrev Thomas 'PointedEars' Lahn:
> </killfile>
> 
> Jonas Thörnvall full-quoted, and replied with nonsense and insults to,
> the same posting for the fifth(!) time within four(!) hours:
> 
> > […]
> > 
> > https://www.youtube.com/watch?v=INXyVlF8IRk&feature=share
> 
> <https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect>
> <https://en.wikipedia.org/wiki/Logorrhea_(psychology)>
> 
> Hopeless case.
> 
> *PLONK*
> 
> 
> PointedEars

Well how sad, lowIQ and out of arguments who could had thoght...

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

#35658

Am 23.09.2018 um 09:23 schrieb Jonas Thörnvall:

> Well how sad, lowIQ and out of arguments who could had thoght...

Can't say I like Thomas, but he at least knows what he is talking about.
You on the other hand... don't.

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

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

#35657

On 22-09-18 06:53, Jonas Thörnvall wrote:
> Often i find it a bit backward reading code, so i wonder a bit about the reason behind choices done in programming languages.
> 
> Why
> track[recTrack].midiMess.splice(trackevent,1);
> and not
> track[recTrack].midiMess[trackevent].splice(1);
> 
> Isn't the later more readable, maybe it is just a personal preference?
> But if you replace the indexname with just the index, the former make no sense if you do not know the parameter order.
> 
> But the later is still readable right out of the box?
> Well i could be wrong but i find the later more intuitive.
> 

Programming language syntax is just a way of writing down programming 
semantics. Since you do not grasp the latter at all it is hard to 
explain the former to you.
The syntactic alternative you propose is an expression of completely 
different semantics.

Elsewhere in this thread you boast about your own high IQ versus the low 
IQ of people you do not understand. I am sure you will also not 
understand what I said above and cope with that by calling me stupid. 
The world must be a strange and hostile place for you.

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

#35659

Den måndag 24 september 2018 kl. 00:33:55 UTC+2 skrev Silvio:
> On 22-09-18 06:53, Jonas Thörnvall wrote:
> > Often i find it a bit backward reading code, so i wonder a bit about the reason behind choices done in programming languages.
> > 
> > Why
> > track[recTrack].midiMess.splice(trackevent,1);
> > and not
> > track[recTrack].midiMess[trackevent].splice(1);
> > 
> > Isn't the later more readable, maybe it is just a personal preference?
> > But if you replace the indexname with just the index, the former make no sense if you do not know the parameter order.
> > 
> > But the later is still readable right out of the box?
> > Well i could be wrong but i find the later more intuitive.
> > 
> 
> Programming language syntax is just a way of writing down programming 
> semantics. Since you do not grasp the latter at all it is hard to 
> explain the former to you.
> The syntactic alternative you propose is an expression of completely 
> different semantics.
> 
> Elsewhere in this thread you boast about your own high IQ versus the low 
> IQ of people you do not understand. I am sure you will also not 
> understand what I said above and cope with that by calling me stupid. 
> The world must be a strange and hostile place for you.

Mo syntax and semantics are just models of what actions taken at lowlevel.
But there is rules created from when the primitives was invented.
One of them is that the index is a part of the array to reach an element object, it is not a part of the object even in object oriented languages.
But javascript have methods upon arrays not upon elements, that is why the parameters includes the index but in look fucking weird.

Yes it is semantics but it is weird.

track[tracknr].midiMess.splice(trackEvent,0,{time:instime,data0:144,data1:insnote,data2:insvel});



Below the splice is done upon element, because index is part of the array, it simply a matter of choice of syntax, i claim the one below is much easier to read. "Because the index as parameter to splice will just be a name", you can't see it is the index. But index is already part of the array primitive so why throw into the method.

track[tracknr].midiMess[trackEvent].splice(0,{time:instime,data0:144,data1:insnote,data2:insvel}); 

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

#35660

Den måndag 24 september 2018 kl. 00:33:55 UTC+2 skrev Silvio:
> On 22-09-18 06:53, Jonas Thörnvall wrote:
> > Often i find it a bit backward reading code, so i wonder a bit about the reason behind choices done in programming languages.
> > 
> > Why
> > track[recTrack].midiMess.splice(trackevent,1);
> > and not
> > track[recTrack].midiMess[trackevent].splice(1);
> > 
> > Isn't the later more readable, maybe it is just a personal preference?
> > But if you replace the indexname with just the index, the former make no sense if you do not know the parameter order.
> > 
> > But the later is still readable right out of the box?
> > Well i could be wrong but i find the later more intuitive.
> > 
> 
> Programming language syntax is just a way of writing down programming 
> semantics. Since you do not grasp the latter at all it is hard to 
> explain the former to you.
> The syntactic alternative you propose is an expression of completely 
> different semantics.
> 
> Elsewhere in this thread you boast about your own high IQ versus the low 
> IQ of people you do not understand. I am sure you will also not 
> understand what I said above and cope with that by calling me stupid. 
> The world must be a strange and hostile place for you.

No that is not the way it started but i do not suck up to lowIQ people on a mission to ridicule me, it is quite easy don't fuck with me and i will not fuck with you.  

But the moron ENTP Thomas should pull out the ENTP polluted stick he has up his ass, and go take an IQ test to get his lowIQ confirmed.

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

#35661

Den måndag 24 september 2018 kl. 00:33:55 UTC+2 skrev Silvio:
> On 22-09-18 06:53, Jonas Thörnvall wrote:
> > Often i find it a bit backward reading code, so i wonder a bit about the reason behind choices done in programming languages.
> > 
> > Why
> > track[recTrack].midiMess.splice(trackevent,1);
> > and not
> > track[recTrack].midiMess[trackevent].splice(1);
> > 
> > Isn't the later more readable, maybe it is just a personal preference?
> > But if you replace the indexname with just the index, the former make no sense if you do not know the parameter order.
> > 
> > But the later is still readable right out of the box?
> > Well i could be wrong but i find the later more intuitive.
> > 
> 
> Programming language syntax is just a way of writing down programming 
> semantics. Since you do not grasp the latter at all it is hard to 
> explain the former to you.
> The syntactic alternative you propose is an expression of completely 
> different semantics.
> 
> Elsewhere in this thread you boast about your own high IQ versus the low 
> IQ of people you do not understand. I am sure you will also not 
> understand what I said above and cope with that by calling me stupid. 
> The world must be a strange and hostile place for you.

Yes syntax is just semantics "of ones choices", the choice they did was to make the method splice work on the array, not upon the element.

That made it necessary to pass the index as a parameter to the method, it was a bad choice. Because it do get hard to read.

Is that clear enough?

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

#35662

Den måndag 24 september 2018 kl. 01:24:45 UTC+2 skrev Jonas Thörnvall:
> Den måndag 24 september 2018 kl. 00:33:55 UTC+2 skrev Silvio:
> > On 22-09-18 06:53, Jonas Thörnvall wrote:
> > > Often i find it a bit backward reading code, so i wonder a bit about the reason behind choices done in programming languages.
> > > 
> > > Why
> > > track[recTrack].midiMess.splice(trackevent,1);
> > > and not
> > > track[recTrack].midiMess[trackevent].splice(1);
> > > 
> > > Isn't the later more readable, maybe it is just a personal preference?
> > > But if you replace the indexname with just the index, the former make no sense if you do not know the parameter order.
> > > 
> > > But the later is still readable right out of the box?
> > > Well i could be wrong but i find the later more intuitive.
> > > 
> > 
> > Programming language syntax is just a way of writing down programming 
> > semantics. Since you do not grasp the latter at all it is hard to 
> > explain the former to you.
> > The syntactic alternative you propose is an expression of completely 
> > different semantics.
> > 
> > Elsewhere in this thread you boast about your own high IQ versus the low 
> > IQ of people you do not understand. I am sure you will also not 
> > understand what I said above and cope with that by calling me stupid. 
> > The world must be a strange and hostile place for you.
> 
> Yes syntax is just semantics "of ones choices", the choice they did was to make the method splice work on the array, not upon the element.
> 
> That made it necessary to pass the index as a parameter to the method, it was a bad choice. Because it do get hard to read.
> 
> Is that clear enough?

Bad design choice.
https://www.w3schools.com/js/tryit.asp?filename=tryjs_array_splice

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

#35677

On Sun, 23 Sep 2018 16:24:38 -0700 (PDT), Jonas Thörnvall
<jonas.thornvall@gmail.com> wrote:

  <snip>
>Yes syntax is just semantics "of ones choices", 

>the choice they did was to make the method splice work on the array, not upon the element.
>
>That made it necessary to pass the index as a parameter to the method, it was a bad choice. Because it do get hard to read.
  <snip>

Haven't you noticed? Splice acts on the elements of an array. You tell
it the start index and the number of elements to remove, then it
replaces the removed elements with the elements you have supplied.

If you want to tell splice to start at element 3, remove 5 elements,
and replace them with "splish", "splosh" then why not say
	a.splice(3, 5, "splish", "splosh");

If you want f(x, 2, "TV") to be written as f.x(2, "TV") then you can't
do anything with the f's property named x :-(

And if you want f.(x, 1, "TV") to be a special syntax case then you've
got a really horrible mess.

  John

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

#35678

Den tisdag 25 september 2018 kl. 20:52:41 UTC+2 skrev John G Harris:
> On Sun, 23 Sep 2018 16:24:38 -0700 (PDT), Jonas Thörnvall
> <jonas.thornvall@gmail.com> wrote:
> 
>   <snip>
> >Yes syntax is just semantics "of ones choices", 
> 
> >the choice they did was to make the method splice work on the array, not upon the element.
> >
> >That made it necessary to pass the index as a parameter to the method, it was a bad choice. Because it do get hard to read.
>   <snip>
> 
> Haven't you noticed? Splice acts on the elements of an array. You tell
> it the start index and the number of elements to remove, then it
> replaces the removed elements with the elements you have supplied.
> 
> If you want to tell splice to start at element 3, remove 5 elements,
> and replace them with "splish", "splosh" then why not say
> 	a.splice(3, 5, "splish", "splosh");
> 
> If you want f(x, 2, "TV") to be written as f.x(2, "TV") then you can't
> do anything with the f's property named x :-(
> 
> And if you want f.(x, 1, "TV") to be a special syntax case then you've
> got a really horrible mess.
> 
>   John

But why send index as parameter, you guys just do things that seem incoherent and give no reason.

Again why not.
a[3].update(3, 5, "splish", "splosh");
Oh i forgot you love your pioneering splushy thingy
a[3].splice(5, "splish", "splosh");

Again i ask the reason for passing startindex as a paremeter?
a[3] it seem to me the index is set to correct place....

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

#35679

Den tisdag 25 september 2018 kl. 21:15:32 UTC+2 skrev Jonas Thörnvall:
> Den tisdag 25 september 2018 kl. 20:52:41 UTC+2 skrev John G Harris:
> > On Sun, 23 Sep 2018 16:24:38 -0700 (PDT), Jonas Thörnvall
> > <jonas.thornvall@gmail.com> wrote:
> > 
> >   <snip>
> > >Yes syntax is just semantics "of ones choices", 
> > 
> > >the choice they did was to make the method splice work on the array, not upon the element.
> > >
> > >That made it necessary to pass the index as a parameter to the method, it was a bad choice. Because it do get hard to read.
> >   <snip>
> > 
> > Haven't you noticed? Splice acts on the elements of an array. You tell
> > it the start index and the number of elements to remove, then it
> > replaces the removed elements with the elements you have supplied.
> > 
> > If you want to tell splice to start at element 3, remove 5 elements,
> > and replace them with "splish", "splosh" then why not say
> > 	a.splice(3, 5, "splish", "splosh");
> > 
> > If you want f(x, 2, "TV") to be written as f.x(2, "TV") then you can't
> > do anything with the f's property named x :-(
> > 
> > And if you want f.(x, 1, "TV") to be a special syntax case then you've
> > got a really horrible mess.
> > 
> >   John
> 
> But why send index as parameter, you guys just do things that seem incoherent and give no reason.
> 
> Again why not.
> a[3].update(3, 5, "splish", "splosh");
> Oh i forgot you love your pioneering splushy thingy
> a[3].splice(5, "splish", "splosh");
> 
> Again i ask the reason for passing startindex as a paremeter?
> a[3] it seem to me the index is set to correct place....

I like explicit code so i would prefer
a[3].delete(5).insert("splish,"splosh");
I mean anyone who knows what an array is will immediately see what is going on.
Compare with.
a[3].splice(5, "splish", "splosh");

Yeah what the fuck is going on here, if you have not read the splice method.
It is so fucking utterly stupid, someone wanted to be pioneering splice? what kind of fucking akronym is that? And then he do not position him self in array, no fuck it is much better to send as a parameter.
No it is utterly fucking stupid when i look at the code it looks like someon got lost and catched a random phrase, "oh he is so inventive so brilliant splice LoL what the fuck"

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

#35701

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

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

#35702

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"); 

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

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web