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

#35759

On Tue, 9 Oct 2018 08:27:56 -0700 (PDT), dr.s.lartius@gmail.com wrote:

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

I relied on the spelling checker, which for some reason didn't hiccup
in that article. Anyway, I'm not too worried about spelling when
replying to Thomas.


>  A.D. 0 is noteworthy for non-existence.
  <snip>

I'm with the astronomers.

Incidentally, how does one provide irrefutable proof that 0 AD did not
exist? We know that AD/BC was invented by people who didn't think 0
was a number, and that it can't be written in Latin. So the year
before +1 could only be -1, except that they didn't know about
negative numbers either. But knowledge has moved on since. 

It must have been awkward back then when a child's 1st birthday
happened in 1 AD. How old were they at birth? Oh, 1 Before First
Birthday.

HTH
  John

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

#35663

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.

I do get that they try to keep the language minimalistic and do not want to reserve words.

But one can questoin why use splice? who the fuck come up with that???
Why not
track[tracknr].midiMess[trackEvent].delete({time:instime,data0:144,data1:insnote,data2:insvel}); 

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

Well i can tell you why they are anal ENTP fucks that feel smart, when they come up with splice which make the readability dependent of that you know the parameters.

"Yeah feel smart.. but it is utterly stupid"
Did they think they were saving something?

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

#35664

Den måndag 24 september 2018 kl. 01:52:17 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.
> 
> I do get that they try to keep the language minimalistic and do not want to reserve words.
> 
> But one can questoin why use splice? who the fuck come up with that???
> Why not
> track[tracknr].midiMess[trackEvent].delete({time:instime,data0:144,data1:insnote,data2:insvel}); 
> 
> and
> track[tracknr].midiMess[trackEvent].insert({time:instime,data0:144,data1:insnote,data2:insvel}); 
> 
> Well i can tell you why they are anal ENTP fucks that feel smart, when they come up with splice which make the readability dependent of that you know the parameters.
> 
> "Yeah feel smart.. but it is utterly stupid"
> Did they think they were saving something?

Yeah it is methods on the elements you morons...

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

#35665

Den måndag 24 september 2018 kl. 01:56:53 UTC+2 skrev Jonas Thörnvall:
> Den måndag 24 september 2018 kl. 01:52:17 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.
> > 
> > I do get that they try to keep the language minimalistic and do not want to reserve words.
> > 
> > But one can questoin why use splice? who the fuck come up with that???
> > Why not
> > track[tracknr].midiMess[trackEvent].delete({time:instime,data0:144,data1:insnote,data2:insvel}); 
> > 
> > and
> > track[tracknr].midiMess[trackEvent].insert({time:instime,data0:144,data1:insnote,data2:insvel}); 
> > 
> > Well i can tell you why they are anal ENTP fucks that feel smart, when they come up with splice which make the readability dependent of that you know the parameters.
> > 
> > "Yeah feel smart.. but it is utterly stupid"
> > Did they think they were saving something?
> 
> Yeah it is methods on the elements you morons...

You see you can't go wrong with element methods like
arr[muppets].insert():
arr[muppets].delete();

No the stupid fucks want to be pioneering, by remove the index, replace "the real method names" with an akronym and throw in the index as a parameter and "call it array methods"

You stupid fucks should not work with webdevelopment at all, go back to your blip blop cave.

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

#35666

Den måndag 24 september 2018 kl. 02:02:10 UTC+2 skrev Jonas Thörnvall:
> Den måndag 24 september 2018 kl. 01:56:53 UTC+2 skrev Jonas Thörnvall:
> > Den måndag 24 september 2018 kl. 01:52:17 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.
> > > 
> > > I do get that they try to keep the language minimalistic and do not want to reserve words.
> > > 
> > > But one can questoin why use splice? who the fuck come up with that???
> > > Why not
> > > track[tracknr].midiMess[trackEvent].delete({time:instime,data0:144,data1:insnote,data2:insvel}); 
> > > 
> > > and
> > > track[tracknr].midiMess[trackEvent].insert({time:instime,data0:144,data1:insnote,data2:insvel}); 
> > > 
> > > Well i can tell you why they are anal ENTP fucks that feel smart, when they come up with splice which make the readability dependent of that you know the parameters.
> > > 
> > > "Yeah feel smart.. but it is utterly stupid"
> > > Did they think they were saving something?
> > 
> > Yeah it is methods on the elements you morons...
> 
> You see you can't go wrong with element methods like
> arr[muppets].insert():
> arr[muppets].delete();
> 
> No the stupid fucks want to be pioneering, by remove the index, replace "the real method names" with an akronym and throw in the index as a parameter and "call it array methods"
> 
> You stupid fucks should not work with webdevelopment at all, go back to your blip blop cave.

Yeah they can throw out the array methods splice and slice altogether from language and replace it with element methods, so one do not have to guess howto use them.

arr[muppets].delete(4);
arr[muppets].insert(4,"A",7,"C",11);
arr[muppets].swap(muppets); 
arr[muppets].swap(muppets+-x);
arr[muppets].calc(sqrt(arr(muppets)+3);

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

#35670

On 24-09-18 03:06, Jonas Thörnvall wrote:
> Den måndag 24 september 2018 kl. 02:02:10 UTC+2 skrev Jonas Thörnvall:
>> Den måndag 24 september 2018 kl. 01:56:53 UTC+2 skrev Jonas Thörnvall:
>>> Den måndag 24 september 2018 kl. 01:52:17 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.
>>>>
>>>> I do get that they try to keep the language minimalistic and do not want to reserve words.
>>>>
>>>> But one can questoin why use splice? who the fuck come up with that???
>>>> Why not
>>>> track[tracknr].midiMess[trackEvent].delete({time:instime,data0:144,data1:insnote,data2:insvel});
>>>>
>>>> and
>>>> track[tracknr].midiMess[trackEvent].insert({time:instime,data0:144,data1:insnote,data2:insvel});
>>>>
>>>> Well i can tell you why they are anal ENTP fucks that feel smart, when they come up with splice which make the readability dependent of that you know the parameters.
>>>>
>>>> "Yeah feel smart.. but it is utterly stupid"
>>>> Did they think they were saving something?
>>>
>>> Yeah it is methods on the elements you morons...
>>
>> You see you can't go wrong with element methods like
>> arr[muppets].insert():
>> arr[muppets].delete();
>>
>> No the stupid fucks want to be pioneering, by remove the index, replace "the real method names" with an akronym and throw in the index as a parameter and "call it array methods"
>>
>> You stupid fucks should not work with webdevelopment at all, go back to your blip blop cave.
> 
> Yeah they can throw out the array methods splice and slice altogether from language and replace it with element methods, so one do not have to guess howto use them.
> 
> arr[muppets].delete(4);
> arr[muppets].insert(4,"A",7,"C",11);
> arr[muppets].swap(muppets);
> arr[muppets].swap(muppets+-x);
> arr[muppets].calc(sqrt(arr(muppets)+3);
> 
> 

You still do not get it do you, high IQ carrying one?

If you would grasp the concept of instances and references you would not 
say this. Knowing that I am probably wasting my breath:

var a = new Date(2017,2,11,12,30,10,0);
var b = new Date(2018,2,11,12,31,20,0);
var c = new Date(2016,3,5,9,0,45,0);

var array1 = [a,b,c];
var array2 = [c,b,a];

array1[0].delete;

is then the equivalent of:

array2[2].delete;

and of:

a.delete

See how this could never implement an operation on array1 or array2? 
Since a does not know "in" which array it is (in fact, it is "in" two 
arrays at the same time) it is impossible to implement an operation on 
the array via a itself. The arrays refer to a and not the other way around.

Nah, forget it.

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

#35671

Den måndag 24 september 2018 kl. 23:51:50 UTC+2 skrev Silvio:
> On 24-09-18 03:06, Jonas Thörnvall wrote:
> > Den måndag 24 september 2018 kl. 02:02:10 UTC+2 skrev Jonas Thörnvall:
> >> Den måndag 24 september 2018 kl. 01:56:53 UTC+2 skrev Jonas Thörnvall:
> >>> Den måndag 24 september 2018 kl. 01:52:17 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.
> >>>>
> >>>> I do get that they try to keep the language minimalistic and do not want to reserve words.
> >>>>
> >>>> But one can questoin why use splice? who the fuck come up with that???
> >>>> Why not
> >>>> track[tracknr].midiMess[trackEvent].delete({time:instime,data0:144,data1:insnote,data2:insvel});
> >>>>
> >>>> and
> >>>> track[tracknr].midiMess[trackEvent].insert({time:instime,data0:144,data1:insnote,data2:insvel});
> >>>>
> >>>> Well i can tell you why they are anal ENTP fucks that feel smart, when they come up with splice which make the readability dependent of that you know the parameters.
> >>>>
> >>>> "Yeah feel smart.. but it is utterly stupid"
> >>>> Did they think they were saving something?
> >>>
> >>> Yeah it is methods on the elements you morons...
> >>
> >> You see you can't go wrong with element methods like
> >> arr[muppets].insert():
> >> arr[muppets].delete();
> >>
> >> No the stupid fucks want to be pioneering, by remove the index, replace "the real method names" with an akronym and throw in the index as a parameter and "call it array methods"
> >>
> >> You stupid fucks should not work with webdevelopment at all, go back to your blip blop cave.
> > 
> > Yeah they can throw out the array methods splice and slice altogether from language and replace it with element methods, so one do not have to guess howto use them.
> > 
> > arr[muppets].delete(4);
> > arr[muppets].insert(4,"A",7,"C",11);
> > arr[muppets].swap(muppets);
> > arr[muppets].swap(muppets+-x);
> > arr[muppets].calc(sqrt(arr(muppets)+3);
> > 
> > 
> 
> You still do not get it do you, high IQ carrying one?
> 
> If you would grasp the concept of instances and references you would not 
> say this. Knowing that I am probably wasting my breath:
> 
> var a = new Date(2017,2,11,12,30,10,0);
> var b = new Date(2018,2,11,12,31,20,0);
> var c = new Date(2016,3,5,9,0,45,0);
> 
> var array1 = [a,b,c];
> var array2 = [c,b,a];
> 
> array1[0].delete;
> 
> is then the equivalent of:
> 
> array2[2].delete;
> 
> and of:
> 
> a.delete
> 
> See how this could never implement an operation on array1 or array2? 
> Since a does not know "in" which array it is (in fact, it is "in" two 
> arrays at the same time) it is impossible to implement an operation on 
> the array via a itself. The arrays refer to a and not the other way around.
> 
> Nah, forget it.

Well i do not see the problem? What do you mean you want to delete the object from array one but it also will be deleted from array 2?

Well why should var A get undefined by removing the index pointer, i do not get it.

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

#35672

Den tisdag 25 september 2018 kl. 10:58:57 UTC+2 skrev Jonas Thörnvall:
> Den måndag 24 september 2018 kl. 23:51:50 UTC+2 skrev Silvio:
> > On 24-09-18 03:06, Jonas Thörnvall wrote:
> > > Den måndag 24 september 2018 kl. 02:02:10 UTC+2 skrev Jonas Thörnvall:
> > >> Den måndag 24 september 2018 kl. 01:56:53 UTC+2 skrev Jonas Thörnvall:
> > >>> Den måndag 24 september 2018 kl. 01:52:17 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.
> > >>>>
> > >>>> I do get that they try to keep the language minimalistic and do not want to reserve words.
> > >>>>
> > >>>> But one can questoin why use splice? who the fuck come up with that???
> > >>>> Why not
> > >>>> track[tracknr].midiMess[trackEvent].delete({time:instime,data0:144,data1:insnote,data2:insvel});
> > >>>>
> > >>>> and
> > >>>> track[tracknr].midiMess[trackEvent].insert({time:instime,data0:144,data1:insnote,data2:insvel});
> > >>>>
> > >>>> Well i can tell you why they are anal ENTP fucks that feel smart, when they come up with splice which make the readability dependent of that you know the parameters.
> > >>>>
> > >>>> "Yeah feel smart.. but it is utterly stupid"
> > >>>> Did they think they were saving something?
> > >>>
> > >>> Yeah it is methods on the elements you morons...
> > >>
> > >> You see you can't go wrong with element methods like
> > >> arr[muppets].insert():
> > >> arr[muppets].delete();
> > >>
> > >> No the stupid fucks want to be pioneering, by remove the index, replace "the real method names" with an akronym and throw in the index as a parameter and "call it array methods"
> > >>
> > >> You stupid fucks should not work with webdevelopment at all, go back to your blip blop cave.
> > > 
> > > Yeah they can throw out the array methods splice and slice altogether from language and replace it with element methods, so one do not have to guess howto use them.
> > > 
> > > arr[muppets].delete(4);
> > > arr[muppets].insert(4,"A",7,"C",11);
> > > arr[muppets].swap(muppets);
> > > arr[muppets].swap(muppets+-x);
> > > arr[muppets].calc(sqrt(arr(muppets)+3);
> > > 
> > > 
> > 
> > You still do not get it do you, high IQ carrying one?
> > 
> > If you would grasp the concept of instances and references you would not 
> > say this. Knowing that I am probably wasting my breath:
> > 
> > var a = new Date(2017,2,11,12,30,10,0);
> > var b = new Date(2018,2,11,12,31,20,0);
> > var c = new Date(2016,3,5,9,0,45,0);
> > 
> > var array1 = [a,b,c];
> > var array2 = [c,b,a];
> > 
> > array1[0].delete;
> > 
> > is then the equivalent of:
> > 
> > array2[2].delete;
> > 
> > and of:
> > 
> > a.delete
> > 
> > See how this could never implement an operation on array1 or array2? 
> > Since a does not know "in" which array it is (in fact, it is "in" two 
> > arrays at the same time) it is impossible to implement an operation on 
> > the array via a itself. The arrays refer to a and not the other way around.
> > 
> > Nah, forget it.
> 
> Well i do not see the problem? What do you mean you want to delete the object from array one but it also will be deleted from array 2?
> 
> Well why should var A get undefined by removing the index pointer, i do not get it.

Well to me it seem fucking weird language structure if you have two arrays refering to same *object*. You remove the *index* holding A in one array, and you tell me it also dissapear in *array2* then the language must be seriously broken...

That is all i can conclude. It should not affect a shit of array 2, if slice and splice do this may i ask why?

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

#35673

Den måndag 24 september 2018 kl. 23:51:50 UTC+2 skrev Silvio:
> On 24-09-18 03:06, Jonas Thörnvall wrote:
> > Den måndag 24 september 2018 kl. 02:02:10 UTC+2 skrev Jonas Thörnvall:
> >> Den måndag 24 september 2018 kl. 01:56:53 UTC+2 skrev Jonas Thörnvall:
> >>> Den måndag 24 september 2018 kl. 01:52:17 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.
> >>>>
> >>>> I do get that they try to keep the language minimalistic and do not want to reserve words.
> >>>>
> >>>> But one can questoin why use splice? who the fuck come up with that???
> >>>> Why not
> >>>> track[tracknr].midiMess[trackEvent].delete({time:instime,data0:144,data1:insnote,data2:insvel});
> >>>>
> >>>> and
> >>>> track[tracknr].midiMess[trackEvent].insert({time:instime,data0:144,data1:insnote,data2:insvel});
> >>>>
> >>>> Well i can tell you why they are anal ENTP fucks that feel smart, when they come up with splice which make the readability dependent of that you know the parameters.
> >>>>
> >>>> "Yeah feel smart.. but it is utterly stupid"
> >>>> Did they think they were saving something?
> >>>
> >>> Yeah it is methods on the elements you morons...
> >>
> >> You see you can't go wrong with element methods like
> >> arr[muppets].insert():
> >> arr[muppets].delete();
> >>
> >> No the stupid fucks want to be pioneering, by remove the index, replace "the real method names" with an akronym and throw in the index as a parameter and "call it array methods"
> >>
> >> You stupid fucks should not work with webdevelopment at all, go back to your blip blop cave.
> > 
> > Yeah they can throw out the array methods splice and slice altogether from language and replace it with element methods, so one do not have to guess howto use them.
> > 
> > arr[muppets].delete(4);
> > arr[muppets].insert(4,"A",7,"C",11);
> > arr[muppets].swap(muppets);
> > arr[muppets].swap(muppets+-x);
> > arr[muppets].calc(sqrt(arr(muppets)+3);
> > 
> > 
> 
> You still do not get it do you, high IQ carrying one?
> 
> If you would grasp the concept of instances and references you would not 
> say this. Knowing that I am probably wasting my breath:
> 
> var a = new Date(2017,2,11,12,30,10,0);
> var b = new Date(2018,2,11,12,31,20,0);
> var c = new Date(2016,3,5,9,0,45,0);
> 
> var array1 = [a,b,c];
> var array2 = [c,b,a];
> 
> array1[0].delete;
> 
> is then the equivalent of:
> 
> array2[2].delete;
> 
> and of:
> 
> a.delete
> 
> See how this could never implement an operation on array1 or array2? 
> Since a does not know "in" which array it is (in fact, it is "in" two 
> arrays at the same time) it is impossible to implement an operation on 
> the array via a itself. The arrays refer to a and not the other way around.
> 
> Nah, forget it.

No i do not actually get the problem, here i push a "set of data" object?, it isn't refered by any name variable name just the array index is it still an object?

 track[tracknr].midiMess.push({time:clock,data0:message.data[0],data1:message.data[1],data2:message.data[2]});

Why would it be wrong to refer do the index when you remove it, do not fucking get it?

track[tracknr].midiMess[i].delete?

What is the problem, i can't even see there is one?
You mean the dataset would still exist elsewhere, is that whay you getting at?
Your point is lost for me.

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

#35674

On 25-09-18 11:51, Jonas Thörnvall wrote:
> Den måndag 24 september 2018 kl. 23:51:50 UTC+2 skrev Silvio:
>> On 24-09-18 03:06, Jonas Thörnvall wrote:
>>> Den måndag 24 september 2018 kl. 02:02:10 UTC+2 skrev Jonas Thörnvall:
>>>> Den måndag 24 september 2018 kl. 01:56:53 UTC+2 skrev Jonas Thörnvall:
>>>>> Den måndag 24 september 2018 kl. 01:52:17 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.
>>>>>>
>>>>>> I do get that they try to keep the language minimalistic and do not want to reserve words.
>>>>>>
>>>>>> But one can questoin why use splice? who the fuck come up with that???
>>>>>> Why not
>>>>>> track[tracknr].midiMess[trackEvent].delete({time:instime,data0:144,data1:insnote,data2:insvel});
>>>>>>
>>>>>> and
>>>>>> track[tracknr].midiMess[trackEvent].insert({time:instime,data0:144,data1:insnote,data2:insvel});
>>>>>>
>>>>>> Well i can tell you why they are anal ENTP fucks that feel smart, when they come up with splice which make the readability dependent of that you know the parameters.
>>>>>>
>>>>>> "Yeah feel smart.. but it is utterly stupid"
>>>>>> Did they think they were saving something?
>>>>>
>>>>> Yeah it is methods on the elements you morons...
>>>>
>>>> You see you can't go wrong with element methods like
>>>> arr[muppets].insert():
>>>> arr[muppets].delete();
>>>>
>>>> No the stupid fucks want to be pioneering, by remove the index, replace "the real method names" with an akronym and throw in the index as a parameter and "call it array methods"
>>>>
>>>> You stupid fucks should not work with webdevelopment at all, go back to your blip blop cave.
>>>
>>> Yeah they can throw out the array methods splice and slice altogether from language and replace it with element methods, so one do not have to guess howto use them.
>>>
>>> arr[muppets].delete(4);
>>> arr[muppets].insert(4,"A",7,"C",11);
>>> arr[muppets].swap(muppets);
>>> arr[muppets].swap(muppets+-x);
>>> arr[muppets].calc(sqrt(arr(muppets)+3);
>>>
>>>
>>
>> You still do not get it do you, high IQ carrying one?
>>
>> If you would grasp the concept of instances and references you would not
>> say this. Knowing that I am probably wasting my breath:
>>
>> var a = new Date(2017,2,11,12,30,10,0);
>> var b = new Date(2018,2,11,12,31,20,0);
>> var c = new Date(2016,3,5,9,0,45,0);
>>
>> var array1 = [a,b,c];
>> var array2 = [c,b,a];
>>
>> array1[0].delete;
>>
>> is then the equivalent of:
>>
>> array2[2].delete;
>>
>> and of:
>>
>> a.delete
>>
>> See how this could never implement an operation on array1 or array2?
>> Since a does not know "in" which array it is (in fact, it is "in" two
>> arrays at the same time) it is impossible to implement an operation on
>> the array via a itself. The arrays refer to a and not the other way around.
>>
>> Nah, forget it.
> 
> No i do not actually get the problem, here i push a "set of data" object?, it isn't refered by any name variable name just the array index is it still an object?
> 
>   track[tracknr].midiMess.push({time:clock,data0:message.data[0],data1:message.data[1],data2:message.data[2]});
> 
> Why would it be wrong to refer do the index when you remove it, do not fucking get it?
> 
> track[tracknr].midiMess[i].delete?
> 
> What is the problem, i can't even see there is one?
> You mean the dataset would still exist elsewhere, is that whay you getting at?
> Your point is lost for me.
> 

After:

var a = new Date();
var b = [a];

b[0].delete;

is equal to:

(b[0]).delete;

which is equal to:

var t = b[0];
t.delete;

which is equal to:

a.delete;

In all three cases the delete is invoked on a and not on the array b 
that holds a reference to a. So if delete is supposed to work on the 
array, b, at some index, it has to be invoked on the array, hence the 
notation:

b.delete(0)

Capiche?

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

#35675

Den tisdag 25 september 2018 kl. 19:41:49 UTC+2 skrev Silvio:
> On 25-09-18 11:51, Jonas Thörnvall wrote:
> > Den måndag 24 september 2018 kl. 23:51:50 UTC+2 skrev Silvio:
> >> On 24-09-18 03:06, Jonas Thörnvall wrote:
> >>> Den måndag 24 september 2018 kl. 02:02:10 UTC+2 skrev Jonas Thörnvall:
> >>>> Den måndag 24 september 2018 kl. 01:56:53 UTC+2 skrev Jonas Thörnvall:
> >>>>> Den måndag 24 september 2018 kl. 01:52:17 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.
> >>>>>>
> >>>>>> I do get that they try to keep the language minimalistic and do not want to reserve words.
> >>>>>>
> >>>>>> But one can questoin why use splice? who the fuck come up with that???
> >>>>>> Why not
> >>>>>> track[tracknr].midiMess[trackEvent].delete({time:instime,data0:144,data1:insnote,data2:insvel});
> >>>>>>
> >>>>>> and
> >>>>>> track[tracknr].midiMess[trackEvent].insert({time:instime,data0:144,data1:insnote,data2:insvel});
> >>>>>>
> >>>>>> Well i can tell you why they are anal ENTP fucks that feel smart, when they come up with splice which make the readability dependent of that you know the parameters.
> >>>>>>
> >>>>>> "Yeah feel smart.. but it is utterly stupid"
> >>>>>> Did they think they were saving something?
> >>>>>
> >>>>> Yeah it is methods on the elements you morons...
> >>>>
> >>>> You see you can't go wrong with element methods like
> >>>> arr[muppets].insert():
> >>>> arr[muppets].delete();
> >>>>
> >>>> No the stupid fucks want to be pioneering, by remove the index, replace "the real method names" with an akronym and throw in the index as a parameter and "call it array methods"
> >>>>
> >>>> You stupid fucks should not work with webdevelopment at all, go back to your blip blop cave.
> >>>
> >>> Yeah they can throw out the array methods splice and slice altogether from language and replace it with element methods, so one do not have to guess howto use them.
> >>>
> >>> arr[muppets].delete(4);
> >>> arr[muppets].insert(4,"A",7,"C",11);
> >>> arr[muppets].swap(muppets);
> >>> arr[muppets].swap(muppets+-x);
> >>> arr[muppets].calc(sqrt(arr(muppets)+3);
> >>>
> >>>
> >>
> >> You still do not get it do you, high IQ carrying one?
> >>
> >> If you would grasp the concept of instances and references you would not
> >> say this. Knowing that I am probably wasting my breath:
> >>
> >> var a = new Date(2017,2,11,12,30,10,0);
> >> var b = new Date(2018,2,11,12,31,20,0);
> >> var c = new Date(2016,3,5,9,0,45,0);
> >>
> >> var array1 = [a,b,c];
> >> var array2 = [c,b,a];
> >>
> >> array1[0].delete;
> >>
> >> is then the equivalent of:
> >>
> >> array2[2].delete;
> >>
> >> and of:
> >>
> >> a.delete
> >>
> >> See how this could never implement an operation on array1 or array2?
> >> Since a does not know "in" which array it is (in fact, it is "in" two
> >> arrays at the same time) it is impossible to implement an operation on
> >> the array via a itself. The arrays refer to a and not the other way around.
> >>
> >> Nah, forget it.
> > 
> > No i do not actually get the problem, here i push a "set of data" object?, it isn't refered by any name variable name just the array index is it still an object?
> > 
> >   track[tracknr].midiMess.push({time:clock,data0:message.data[0],data1:message.data[1],data2:message.data[2]});
> > 
> > Why would it be wrong to refer do the index when you remove it, do not fucking get it?
> > 
> > track[tracknr].midiMess[i].delete?
> > 
> > What is the problem, i can't even see there is one?
> > You mean the dataset would still exist elsewhere, is that whay you getting at?
> > Your point is lost for me.
> > 
> 
> After:
> 
> var a = new Date();
> var b = [a];
> 
> b[0].delete;
> 
> is equal to:
> 
> (b[0]).delete;
> 
> which is equal to:
> 
> var t = b[0];
> t.delete;
> 
> which is equal to:
> 
> a.delete;
> 
> In all three cases the delete is invoked on a and not on the array b 
> that holds a reference to a. So if delete is supposed to work on the 
> array, b, at some index, it has to be invoked on the array, hence the 
> notation:
> 
> b.delete(0)
> 
> Capiche?

I do not even see that what you say is relevant?
What is it you try to convey, how is it relevant. 

You show me some syntax and pretend it somehow god given?
Why should b[0].delete erase the object?
Because b is an array and it is the index that point at the object?

So why doesn't it delete the index pointer just?
I think you are confused honestly, maybe it some weird convoluted or polluted semi object oriented structure that confuse you?

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

#35676

Den tisdag 25 september 2018 kl. 20:22:57 UTC+2 skrev Jonas Thörnvall:
> Den tisdag 25 september 2018 kl. 19:41:49 UTC+2 skrev Silvio:
> > On 25-09-18 11:51, Jonas Thörnvall wrote:
> > > Den måndag 24 september 2018 kl. 23:51:50 UTC+2 skrev Silvio:
> > >> On 24-09-18 03:06, Jonas Thörnvall wrote:
> > >>> Den måndag 24 september 2018 kl. 02:02:10 UTC+2 skrev Jonas Thörnvall:
> > >>>> Den måndag 24 september 2018 kl. 01:56:53 UTC+2 skrev Jonas Thörnvall:
> > >>>>> Den måndag 24 september 2018 kl. 01:52:17 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.
> > >>>>>>
> > >>>>>> I do get that they try to keep the language minimalistic and do not want to reserve words.
> > >>>>>>
> > >>>>>> But one can questoin why use splice? who the fuck come up with that???
> > >>>>>> Why not
> > >>>>>> track[tracknr].midiMess[trackEvent].delete({time:instime,data0:144,data1:insnote,data2:insvel});
> > >>>>>>
> > >>>>>> and
> > >>>>>> track[tracknr].midiMess[trackEvent].insert({time:instime,data0:144,data1:insnote,data2:insvel});
> > >>>>>>
> > >>>>>> Well i can tell you why they are anal ENTP fucks that feel smart, when they come up with splice which make the readability dependent of that you know the parameters.
> > >>>>>>
> > >>>>>> "Yeah feel smart.. but it is utterly stupid"
> > >>>>>> Did they think they were saving something?
> > >>>>>
> > >>>>> Yeah it is methods on the elements you morons...
> > >>>>
> > >>>> You see you can't go wrong with element methods like
> > >>>> arr[muppets].insert():
> > >>>> arr[muppets].delete();
> > >>>>
> > >>>> No the stupid fucks want to be pioneering, by remove the index, replace "the real method names" with an akronym and throw in the index as a parameter and "call it array methods"
> > >>>>
> > >>>> You stupid fucks should not work with webdevelopment at all, go back to your blip blop cave.
> > >>>
> > >>> Yeah they can throw out the array methods splice and slice altogether from language and replace it with element methods, so one do not have to guess howto use them.
> > >>>
> > >>> arr[muppets].delete(4);
> > >>> arr[muppets].insert(4,"A",7,"C",11);
> > >>> arr[muppets].swap(muppets);
> > >>> arr[muppets].swap(muppets+-x);
> > >>> arr[muppets].calc(sqrt(arr(muppets)+3);
> > >>>
> > >>>
> > >>
> > >> You still do not get it do you, high IQ carrying one?
> > >>
> > >> If you would grasp the concept of instances and references you would not
> > >> say this. Knowing that I am probably wasting my breath:
> > >>
> > >> var a = new Date(2017,2,11,12,30,10,0);
> > >> var b = new Date(2018,2,11,12,31,20,0);
> > >> var c = new Date(2016,3,5,9,0,45,0);
> > >>
> > >> var array1 = [a,b,c];
> > >> var array2 = [c,b,a];
> > >>
> > >> array1[0].delete;
> > >>
> > >> is then the equivalent of:
> > >>
> > >> array2[2].delete;
> > >>
> > >> and of:
> > >>
> > >> a.delete
> > >>
> > >> See how this could never implement an operation on array1 or array2?
> > >> Since a does not know "in" which array it is (in fact, it is "in" two
> > >> arrays at the same time) it is impossible to implement an operation on
> > >> the array via a itself. The arrays refer to a and not the other way around.
> > >>
> > >> Nah, forget it.
> > > 
> > > No i do not actually get the problem, here i push a "set of data" object?, it isn't refered by any name variable name just the array index is it still an object?
> > > 
> > >   track[tracknr].midiMess.push({time:clock,data0:message.data[0],data1:message.data[1],data2:message.data[2]});
> > > 
> > > Why would it be wrong to refer do the index when you remove it, do not fucking get it?
> > > 
> > > track[tracknr].midiMess[i].delete?
> > > 
> > > What is the problem, i can't even see there is one?
> > > You mean the dataset would still exist elsewhere, is that whay you getting at?
> > > Your point is lost for me.
> > > 
> > 
> > After:
> > 
> > var a = new Date();
> > var b = [a];
> > 
> > b[0].delete;
> > 
> > is equal to:
> > 
> > (b[0]).delete;
> > 
> > which is equal to:
> > 
> > var t = b[0];
> > t.delete;
> > 
> > which is equal to:
> > 
> > a.delete;
> > 
> > In all three cases the delete is invoked on a and not on the array b 
> > that holds a reference to a. So if delete is supposed to work on the 
> > array, b, at some index, it has to be invoked on the array, hence the 
> > notation:
> > 
> > b.delete(0)
> > 
> > Capiche?
> 
> I do not even see that what you say is relevant?
> What is it you try to convey, how is it relevant. 
> 
> You show me some syntax and pretend it somehow god given?
> Why should b[0].delete erase the object?
> Because b is an array and it is the index that point at the object?
> 
> So why doesn't it delete the index pointer just?
> I think you are confused honestly, maybe it some weird convoluted or polluted semi object oriented structure that confuse you?

I think you are all lost in some weird paper structure you can't break lose from and then you end up with ridiculous syntax built aroudn ridiculous semantics.

If b is an array
then b.delete would remove the array "that is logical"
but b[0].delete delete the pointer from the array to either the data, or variable, or object stored there. Only if idiots constructed language it would be otherwise.

We have the options to store things at an index
Could be data
a[0]=10;
Could be variable
a[0]=zapp;
or it could be an object
a[0]={type:"Fiat", model:"500", color:"white"};

So a[0].delete why the fuck should it be the same as zapp.delete, it does not make sense?

Similar if
zapp={type:"Fiat", model:"500", color:"white"};
a[0]=zapp;

a[0].delete why should it deledte zapp the semantics and syntax  doesn't even make any sense to me?

If i want to delete zapp shold it not be zapp.delete.
a[0].delete just remove the index pointer to whatever data, variable or object.

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

#35680

On 25-09-18 20:42, Jonas Thörnvall wrote:

> 
> I think you are all lost in some weird paper structure you can't break lose from and then you end up with ridiculous syntax built aroudn ridiculous semantics.
> 
> If b is an array
> then b.delete would remove the array "that is logical"

No, it would invoke some action called delete on the array. If that 
action had an index parameter, like:

b.delete(2);

this might "delete" (whatever that means) the element at index 2 in 
array b. The exact semantics of this delete action would be defined by 
the array.

> but b[0].delete delete the pointer from the array to either the data, or variable, or object stored there. Only if idiots constructed language it would be otherwise.

You somehow see the syntax:

b[0].delete

as some compound operation on b using an index 0 and invoking some 
delete operation. That is not the case. Although compound *expressions* 
exist their semantics fall apart in *atomic operations*.

b[0].delete;

consists of two separate operations. The first is expressed by:

b[0]

it gets the value at "index" 0 from array b and yields only that value, 
thereby loosing any connection to the array b.

The next operation is expressed by the:

.delete

part and that is executed on the value that is yielded by the first 
operation and on that value only.

> 
> We have the options to store things at an index
> Could be data
> a[0]=10;
> Could be variable
> a[0]=zapp;
> or it could be an object
> a[0]={type:"Fiat", model:"500", color:"white"};

This is where things get messy. You could say the languages DOES treat 
the special builtin syntax:

a[b] = c;

as a compound operation on a using b and c as "parameters" for the 
action. I can see why you might think that the same holds for:

a[b].c;

but that is NOT the case. It parses this as two separate operations, the 
first accesses a at b yielding some value, and the second invoking c on 
that yielded value.

> 
> So a[0].delete why the fuck should it be the same as zapp.delete, it does not make sense?

Mentally parsing both expressions without knowing what the basic builtin 
operations of the language are this does not necessarily make sense. But 
that is just the way it is.

It is not uncommon among languages. In Scala:

a(b) = c

is syntactic sugar for:

a.update(b,c)

so you can use that syntax with every class that defines an update 
method with two parameters.

> 
> Similar if
> zapp={type:"Fiat", model:"500", color:"white"};
> a[0]=zapp;
> 
> a[0].delete why should it deledte zapp the semantics and syntax  doesn't even make any sense to me?
> 
> If i want to delete zapp shold it not be zapp.delete.
> a[0].delete just remove the index pointer to whatever data, variable or object.
> 
> 

Please see above.

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

#35681

Den tisdag 25 september 2018 kl. 21:47:09 UTC+2 skrev Silvio:
> On 25-09-18 20:42, Jonas Thörnvall wrote:
> 
> > 
> > I think you are all lost in some weird paper structure you can't break lose from and then you end up with ridiculous syntax built aroudn ridiculous semantics.
> > 
> > If b is an array
> > then b.delete would remove the array "that is logical"
> 
> No, it would invoke some action called delete on the array. If that 
> action had an index parameter, like:
> 
> b.delete(2);
> 
> this might "delete" (whatever that means) the element at index 2 in 
> array b. The exact semantics of this delete action would be defined by 
> the array.
> 
> > but b[0].delete delete the pointer from the array to either the data, or variable, or object stored there. Only if idiots constructed language it would be otherwise.
> 
> You somehow see the syntax:
> 
> b[0].delete
> 
> as some compound operation on b using an index 0 and invoking some 
> delete operation. That is not the case. Although compound *expressions* 
> exist their semantics fall apart in *atomic operations*.
> 
> b[0].delete;
> 
> consists of two separate operations. The first is expressed by:
> 
> b[0]
> 
> it gets the value at "index" 0 from array b and yields only that value, 
> thereby loosing any connection to the array b.
> 
> The next operation is expressed by the:
> 
> .delete
> 
> part and that is executed on the value that is yielded by the first 
> operation and on that value only.
> 
> > 
> > We have the options to store things at an index
> > Could be data
> > a[0]=10;
> > Could be variable
> > a[0]=zapp;
> > or it could be an object
> > a[0]={type:"Fiat", model:"500", color:"white"};
> 
> This is where things get messy. You could say the languages DOES treat 
> the special builtin syntax:
> 
> a[b] = c;
> 
> as a compound operation on a using b and c as "parameters" for the 
> action. I can see why you might think that the same holds for:
> 
> a[b].c;
> 
> but that is NOT the case. It parses this as two separate operations, the 
> first accesses a at b yielding some value, and the second invoking c on 
> that yielded value.
> 
> > 
> > So a[0].delete why the fuck should it be the same as zapp.delete, it does not make sense?
> 
> Mentally parsing both expressions without knowing what the basic builtin 
> operations of the language are this does not necessarily make sense. But 
> that is just the way it is.
> 
> It is not uncommon among languages. In Scala:
> 
> a(b) = c
> 
> is syntactic sugar for:
> 
> a.update(b,c)
> 
> so you can use that syntax with every class that defines an update 
> method with two parameters.
> 
> > 
> > Similar if
> > zapp={type:"Fiat", model:"500", color:"white"};
> > a[0]=zapp;
> > 
> > a[0].delete why should it deledte zapp the semantics and syntax  doesn't even make any sense to me?
> > 
> > If i want to delete zapp shold it not be zapp.delete.
> > a[0].delete just remove the index pointer to whatever data, variable or object.
> > 
> > 
> 
> Please see above.

Well you are correct in everything you said, but as i said from the beginning syntax expressions is about choices.

Yeah but why build the expressions around such fucked up unreadable semantics i asked, and you basicly tell well that the way it yes.

Yes it is bananas.

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

#35682

<jonas.thornvall@gmail.com> wrote on 25 Sep 2018 in comp.lang.javascript: 

> Well you are correct in everything you said, but as i said from the
> beginning syntax expressions is about choices. 

What the hell is a "syntax expression"?
 
> Yeah but why build the expressions around such fucked up unreadable
> semantics i asked, and you basicly tell well that the way it yes. 

That is called "logic".
 
> Yes it is bananas.

So your enormous IQ even is instrumental in recognizing kinds of fruit?

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

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

#35684

Den tisdag 25 september 2018 kl. 23:37:28 UTC+2 skrev Evertjan.:
> <jonas.thornvall@gmail.com> wrote on 25 Sep 2018 in comp.lang.javascript: 
> 
> > Well you are correct in everything you said, but as i said from the
> > beginning syntax expressions is about choices. 
> 
> What the hell is a "syntax expression"?

Well it is rules of a programming language, combination of one or more constants, variables, operators, and functions they make up the syntax. Syntax is just the programming equivalent of semantic expressions, maybe you heard of those or maybe you were born blip blopping.

>  
> > Yeah but why build the expressions around such fucked up unreadable
> > semantics i asked, and you basicly tell well that the way it yes. 
> 
> That is called "logic".
No the choice of syntax are in cases idiotic when in come to arrays, the guys who did the string functions had a much better logic.

> > Yes it is bananas.
> 
> So your enormous IQ even is instrumental in recognizing kinds of fruit?

You are not only intelligent you are also witty LoL

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

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

#35691

=?UTF-8?Q?Jonas_Th=C3=B6rnvall?= <jonas.thornvall@gmail.com> wrote on 25
Sep 2018 in comp.lang.javascript: 

> Den tisdag 25 september 2018 kl. 23:37:28 UTC+2 skrev Evertjan.:
>> <jonas.thornvall@gmail.com> wrote on 25 Sep 2018 in
>> comp.lang.javascript: 
>  
>> 
>> > Well you are correct in everything you said, but as i said from the
>> > beginning syntax expressions is about choices. 
>> 
>> What the hell is a "syntax expression"?
> 
> Well it is rules of a programming language, combination of one or more
> constants, variables, operators, and functions they make up the syntax.
> Syntax is just the programming equivalent of semantic expressions,

That would be "expression syntax".

> maybe
> you heard of those or maybe you were born blip blopping. 

Hey, it is you who claims to be even more intelligent than Trump.

>> > Yeah but why build the expressions around such fucked up unreadable
>> > semantics i asked, and you basicly tell well that the way it yes. 
>> 
>> That is called "logic".

> No the choice of syntax are in cases idiotic when in come to arrays, the
> guys who did the string functions had a much better logic. 

Whether it is better or not, it is still "logic" that drove them.

So your "no" is wrong.
 
>> > Yes it is bananas.
>> 
>> So your enormous IQ even is instrumental in recognizing kinds of fruit?
> 
> You are not only intelligent you are also witty LoL

Thank you.

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



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

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

#35685

On 25-09-18 23:24, Jonas Thörnvall wrote:
> 
> Well you are correct in everything you said, but as i said from the beginning syntax expressions is about choices.
> 
> Yeah but why build the expressions around such fucked up unreadable semantics i asked, and you basicly tell well that the way it yes.
> 
> Yes it is bananas.
> 

Your mental approach to programming is the cause of your confusion.

A programming language has nothing in common with a natural language. 
The latter is organic and you can get the point of a story without 
understanding every subtle detail. You may even succeed in telling your 
own stories using broken sentences and still have people mostly 
understand you.

Programming languages do not work that way. Unless you master the 
essential details and subtleties you can not really understand code 
written by others. And although you may succeed partially in creating 
something using trial-and-error this will not scale to anything 
meaningful, let alone flawless.

You do not program, you mess around with (sample) code until it does 
something that resembles your objectives. In the process you share your 
musings with yourself in this newsgroup.

If you had devoted 5% of the time you wasted this way to actually 
learning programming and, in this case, JavaScript you could have 
achieved much much more. But you will probably perpetuate your 
stubborn-es and disregard my advice.

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

#35687

Den onsdag 26 september 2018 kl. 00:06:40 UTC+2 skrev Silvio:
> On 25-09-18 23:24, Jonas Thörnvall wrote:
> > 
> > Well you are correct in everything you said, but as i said from the beginning syntax expressions is about choices.
> > 
> > Yeah but why build the expressions around such fucked up unreadable semantics i asked, and you basicly tell well that the way it yes.
> > 
> > Yes it is bananas.
> > 
> 
> Your mental approach to programming is the cause of your confusion.
> 
> A programming language has nothing in common with a natural language. 
> The latter is organic and you can get the point of a story without 
> understanding every subtle detail. You may even succeed in telling your 
> own stories using broken sentences and still have people mostly 
> understand you.
> 
> Programming languages do not work that way. Unless you master the 
> essential details and subtleties you can not really understand code 
> written by others. And although you may succeed partially in creating 
> something using trial-and-error this will not scale to anything 
> meaningful, let alone flawless.
> 
> You do not program, you mess around with (sample) code until it does 
> something that resembles your objectives. In the process you share your 
> musings with yourself in this newsgroup.
> 
> If you had devoted 5% of the time you wasted this way to actually 
> learning programming and, in this case, JavaScript you could have 
> achieved much much more. But you will probably perpetuate your 
> stubborn-es and disregard my advice.

Well i am quite on my way to a working midisequenser in javascript, that actually requires a little effort. maybe i have programmed for some 300-400 hundred hours and i am learning constantly. But it is fucking weird when the api and syntax is the main obstacle from achieving ones goal to finnish it.

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

#35692

<jonas.thornvall@gmail.com> wrote on 26
Sep 2018 in comp.lang.javascript: 

> But it is fucking weird when the api and syntax is the main obstacle
> from achieving ones goal to finnish it. 

So now you claim to be officially fucking weird Finnish?

Finnish is also an official minority language in Sweden.

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

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

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

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

csiph-web