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

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

Why not fix problem, but instead build a new structure and syntax overlay?

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

Contents

  Why not fix problem, but instead build a new structure and syntax overlay? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-02-26 12:00 -0800
    Re: Why not fix problem, but instead build a new structure and syntax overlay? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-02-26 12:08 -0800
    Re: Why not fix problem, but instead build a new structure and syntax overlay? JJ <jj4public@gmail.com> - 2021-02-27 16:48 +0700
      Re: Why not fix problem, but instead build a new structure and syntax overlay? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-02-27 03:11 -0800
        Re: Why not fix problem, but instead build a new structure and syntax overlay? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-02-27 11:02 -0800
          Re: Why not fix problem, but instead build a new structure and syntax overlay? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-02-28 08:52 -0800
            Re: Why not fix problem, but instead build a new structure and syntax overlay? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-02-28 09:50 -0800
              Re: Why not fix problem, but instead build a new structure and syntax overlay? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-02-28 15:58 -0800
                Re: Why not fix problem, but instead build a new structure and syntax overlay? JJ <jj4public@gmail.com> - 2021-03-01 15:06 +0700
                  Re: Why not fix problem, but instead build a new structure and syntax overlay? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2021-03-01 11:06 +0100
                    Re: Why not fix problem, but instead build a new structure and syntax overlay? Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-03-01 08:50 -0800
                      Re: Why not fix problem, but instead build a new structure and syntax overlay? JJ <jj4public@gmail.com> - 2021-03-02 23:46 +0700
                        Re: Why not fix problem, but instead build a new structure and syntax overlay? "Mark-" <nospam@mapson.xyz> - 2021-03-03 14:39 +0000
          Re: Why not fix problem, but instead build a new structure and syntax overlay? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2021-03-01 00:19 +0100
            Re: Why not fix problem, but instead build a new structure and syntax overlay? John G Harris <niam@jghnorth.org.uk.invalid> - 2021-03-01 19:30 +0000

#39521 — Why not fix problem, but instead build a new structure and syntax overlay?

When iteration of things like setTimeOut causes lag, why do one take the route to add a new type of element "webworkers?" rather then fix the setTimeOut problem?

I mean ideally i guess setTimeOut should fire on time and you could having threading in background????

Instead someone immediately think oh here we can add some syntax that will to what should been done in first place?

How does that workflow leading to such conclusions look?

[toc] | [next] | [standalone]

#39522

fredag 26 februari 2021 kl. 21:00:57 UTC+1 skrev Jonas Thörnvall:
> When iteration of things like setTimeOut causes lag, why do one take the route to add a new type of element "webworkers?" rather then fix the setTimeOut problem? 
> 
> I mean ideally i guess setTimeOut should fire on time and you could having threading in background???? 
> 
> Instead someone immediately think oh here we can add some syntax that will to what should been done in first place? 
> 
> How does that workflow leading to such conclusions look?
Is this the soul reason for it?
https://www.youtube.com/watch?v=9LZ35Ar3r2k

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

#39525

On Fri, 26 Feb 2021 12:00:52 -0800 (PST), Jonas Thörnvall wrote:

> When iteration of things like setTimeOut causes lag, why do one take the route to add a new type of element "webworkers?" rather then fix the setTimeOut problem?
> 
> I mean ideally i guess setTimeOut should fire on time and you could having threading in background????
> 
> Instead someone immediately think oh here we can add some syntax that will to what should been done in first place?
> 
> How does that workflow leading to such conclusions look?

If you're aware of the single threaded script execution, you wouldn't have
blamed setTimeout().

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

#39526

lördag 27 februari 2021 kl. 10:48:17 UTC+1 skrev JJ:
> On Fri, 26 Feb 2021 12:00:52 -0800 (PST), Jonas Thörnvall wrote: 
> 
> > When iteration of things like setTimeOut causes lag, why do one take the route to add a new type of element "webworkers?" rather then fix the setTimeOut problem? 
> > 
> > I mean ideally i guess setTimeOut should fire on time and you could having threading in background???? 
> > 
> > Instead someone immediately think oh here we can add some syntax that will to what should been done in first place? 
> > 
> > How does that workflow leading to such conclusions look?
> If you're aware of the single threaded script execution, you wouldn't have 
> blamed setTimeout().
I do not blame setTimeout its excellent idea, but why was it not made to run in threads the use of such function almost say it will be threaded?
When they come so far they wanted to thread Javascript, why did they not change setTimeout and setinterval to run in threads.
But they chose instead, to create a new syntax structural  element to do the same LoL

They are fucking funny that is what they are, but someone wanted to put his name on coming up with the new syntax, keep pling it boys LoL 
"I created webworkers" LoL
It so unbeleivable moronic....

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

#39527

On Saturday, February 27, 2021 at 5:11:27 AM UTC-6, jonas.t...@gmail.com wrote:
> I do not blame setTimeout its excellent idea, but why was it not made to run in threads the use of such function almost say it will be threaded? 
> When they come so far they wanted to thread Javascript, why did they not change setTimeout and setinterval to run in threads. 
> But they chose instead, to create a new syntax structural element to do the same LoL 
> 
> They are fucking funny that is what they are, but someone wanted to put his name on coming up with the new syntax, keep pling it boys LoL 
> "I created webworkers" LoL 
> It so unbeleivable moronic....

What's moronic are your assumptions. Changing setTimeout and setInterval to create a new thread would break the web. Backwards compatibility matters. Given your challenges with one thread, I can imagine how you'd react to your first race condition...

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

#39528

lördag 27 februari 2021 kl. 20:02:54 UTC+1 skrev Michael Haufe (TNO):
> On Saturday, February 27, 2021 at 5:11:27 AM UTC-6, jonas.t...@gmail.com wrote: 
> > I do not blame setTimeout its excellent idea, but why was it not made to run in threads the use of such function almost say it will be threaded? 
> > When they come so far they wanted to thread Javascript, why did they not change setTimeout and setinterval to run in threads. 
> > But they chose instead, to create a new syntax structural element to do the same LoL 
> > 
> > They are fucking funny that is what they are, but someone wanted to put his name on coming up with the new syntax, keep pling it boys LoL 
> > "I created webworkers" LoL 
> > It so unbeleivable moronic....
> What's moronic are your assumptions. Changing setTimeout and setInterval to create a new thread would break the web. Backwards compatibility matters. Given your challenges with one thread, I can imagine how you'd react to your first race condition...
 
I don't see how moving a process to its own thread could make it break, the interval is what it is, the timeout is what it is...

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

#39529

On Sunday, February 28, 2021 at 10:52:27 AM UTC-6, jonas.t...@gmail.com wrote:

> I don't see how moving a process to its own thread could make it break, the interval is what it is, the timeout is what it is...

```
var x = 5

setTimeout(() => console.log(x++), 16)

setTimeout(() => console.log(x--), 16)
```

If each setTimeout call created its own thread, what does the above code print to the console?

5 followed by 6, or 6 followed by 5? The answer is you don't know; both are possible.

Now take less trivial example:

```
setInterval(() => {
   // read the last line in a file
}, 30)

setInterval(() => {
  // write the last line in a file
}, 50)
```

Every 150ms the two threads would be simultaneously reading and writing the last line in a file. What would the result be?

Today settimeout/setinterval use the same single thread as the rest of your code. You know
what the order of execution is. In the case of a tie the first defined one wins. If you
just change this to multithreaded an untold amount of code would break across the web.

That's why a new construct was created (WebWorkers) and the means of communication well defined:

<https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers>

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

#39531

söndag 28 februari 2021 kl. 18:50:42 UTC+1 skrev Michael Haufe (TNO):
> On Sunday, February 28, 2021 at 10:52:27 AM UTC-6, jonas.t...@gmail.com wrote: 
> 
> > I don't see how moving a process to its own thread could make it break, the interval is what it is, the timeout is what it is...
> ``` 
> var x = 5 
> 
> setTimeout(() => console.log(x++), 16) 
> 
> setTimeout(() => console.log(x--), 16) 
> ``` 
> 
> If each setTimeout call created its own thread, what does the above code print to the console? 
> 
> 5 followed by 6, or 6 followed by 5? The answer is you don't know; both are possible. 
> 
> Now take less trivial example: 
> 
> ``` 
> setInterval(() => { 
> // read the last line in a file 
> }, 30) 
> 
> setInterval(() => { 
> // write the last line in a file 
> }, 50) 
> ``` 
> 
> Every 150ms the two threads would be simultaneously reading and writing the last line in a file. What would the result be? 
> 
> Today settimeout/setinterval use the same single thread as the rest of your code. You know 
> what the order of execution is. In the case of a tie the first defined one wins. If you 
> just change this to multithreaded an untold amount of code would break across the web. 
> 
> That's why a new construct was created (WebWorkers) and the means of communication well defined: 
> 
> <https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers>
I kind of doubt your counterexample to beleive with but if that is true, you make a wrapper.
create,thread.wassup(setTimeout);
release.thread.wassup;

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

#39534

On Sun, 28 Feb 2021 15:58:50 -0800 (PST), Jonas Thörnvall wrote:
> I kind of doubt your counterexample to beleive with but if that is true, you make a wrapper.
> create,thread.wassup(setTimeout);
> release.thread.wassup;

I get your frustration. Sometimes I loathe JavaScript limitations too. But
what can we do? We can't simply change how JavaScript works. We can
actuatually change it, but it will no longer be compatible with JavaScript.
And since setTimeout() and setInterval are part of the DOM specification, we
can also change that too, but it will no longer be compatible with the DOM
specification.

World standards are not perfect, but we who aren't part of those who are
responsible for updating those standards, only have a "take it or leave it"
choice.

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

#39535

JJ wrote:

> On Sun, 28 Feb 2021 15:58:50 -0800 (PST), Jonas Thörnvall wrote:
>> I kind of doubt your counterexample to beleive with but if that is true,
>> you make a wrapper. create,thread.wassup(setTimeout);
>> release.thread.wassup;
> 
> I get your frustration. Sometimes I loathe JavaScript limitations too. But
> what can we do? We can't simply change how JavaScript works.

Blind leading the blind :-D

setTimeout() is NOT a language feature; it is a DOM feature.

Although it might not have been intended to be, it evolved into a workaround 
for the fact that the language is single-threaded.

In the meantime, better workarounds have been developed, including threads.  

So STFU and RTFM:

<https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers>

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

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

#39536

måndag 1 mars 2021 kl. 11:07:02 UTC+1 skrev Thomas 'PointedEars' Lahn:
> JJ wrote: 
> 
> > On Sun, 28 Feb 2021 15:58:50 -0800 (PST), Jonas Thörnvall wrote: 
> >> I kind of doubt your counterexample to beleive with but if that is true, 
> >> you make a wrapper. create,thread.wassup(setTimeout); 
> >> release.thread.wassup; 
> > 
> > I get your frustration. Sometimes I loathe JavaScript limitations too. But 
> > what can we do? We can't simply change how JavaScript works.
> Blind leading the blind :-D 
> 
> setTimeout() is NOT a language feature; it is a DOM feature. 
> 
> Although it might not have been intended to be, it evolved into a workaround 
> for the fact that the language is single-threaded. 
> 
> In the meantime, better workarounds have been developed, including threads. 
> 
> So STFU and RTFM: 
> 
> <https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers>
> -- 
> PointedEars 
> FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix> 
> <https://github.com/PointedEars> | <http://PointedEars.de/wsvn/> 
> Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.
Ypu are a low IQ moron so fuckoff.

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

#39541

On Mon, 1 Mar 2021 08:50:34 -0800 (PST), Jonas Thörnvall wrote:
> måndag 1 mars 2021 kl. 11:07:02 UTC+1 skrev Thomas 'PointedEars' Lahn:
>> JJ wrote: 
>> 
>>> On Sun, 28 Feb 2021 15:58:50 -0800 (PST), Jonas Thörnvall wrote: 
>>>> I kind of doubt your counterexample to beleive with but if that is true, 
>>>> you make a wrapper. create,thread.wassup(setTimeout); 
>>>> release.thread.wassup; 
>>> 
>>> I get your frustration. Sometimes I loathe JavaScript limitations too. But 
>>> what can we do? We can't simply change how JavaScript works.
>> Blind leading the blind :-D 
>> 
>> setTimeout() is NOT a language feature; it is a DOM feature. 
>> 
>> Although it might not have been intended to be, it evolved into a workaround 
>> for the fact that the language is single-threaded. 
>> 
>> In the meantime, better workarounds have been developed, including threads. 
>> 
>> So STFU and RTFM: 
>> 
>> <https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers>
>> -- 
>> PointedEars 
>> FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix> 
>> <https://github.com/PointedEars> | <http://PointedEars.de/wsvn/> 
>> Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.
> Ypu are a low IQ moron so fuckoff.

Seriously, I don't get why he's always angry and hateful each time he opens
his mouth.

I never did state that setTimeout and setInterval is part of JavaScript
specification.

He doesn't even BOTHER to read:

> And since setTimeout() and setInterval are part of the DOM specification, we
> can also change that too, but it will no longer be compatible with the DOM
> specification.

Instead, his flat world only sees that everything discussed here must be
related to, or belong to JavaScript.

For me, smart people are still society's trash if they look down on others.

I feel sorry for those around him in real world during this pandemic time.

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

#39554

JJ wrote:

> Seriously, I don't get why he's always angry and hateful each time he
> opens his mouth.
> 

Oldest reason in the book. 
He has done/is doing things he should not do.
He thinks it will help hide his overts.
When in reality it is a red flashing beacon.

 
 

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

#39530

Michael Haufe (TNO) wrote:

> On Saturday, February 27, 2021 at 5:11:27 AM UTC-6, jonas.t...@gmail.com
> wrote:
>> They are fucking funny that is what they are, but someone wanted to put
>> his name on coming up with the new syntax, keep pling it boys LoL "I
>> created webworkers" LoL It so unbeleivable moronic....
> 
> What's moronic are your assumptions. […]

Do not feed the troll.

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

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

#39537

On Mon, 01 Mar 2021 00:19:49 +0100, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

>Michael Haufe (TNO) wrote:
>
>> On Saturday, February 27, 2021 at 5:11:27 AM UTC-6, jonas.t...@gmail.com
>> wrote:
>>> They are fucking funny that is what they are, but someone wanted to put
>>> his name on coming up with the new syntax, keep pling it boys LoL "I
>>> created webworkers" LoL It so unbeleivable moronic....
>> 
>> What's moronic are your assumptions. 
  [snip]
>
>Do not feed the troll.

He's not feeding the "troll", he's explaining to everyone else,
especially beginners, where the "troll" has not understood the
problem.

  John

[toc] | [prev] | [standalone]

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

csiph-web