Re: Question of the Day: What about all this asynchrony?

[Dwayne]

Yes, I understand. Thanks for being polite!
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Question of the Day: What about all this asynchrony?

[Dwayne]

Hi,

Micheal, you sound like one of the foolish virgins that forgot to bring oil
for their lamps. You know that you need to do more research and that you
lack conceptual understanding. Now, because you've brought to little, your
asking for what you failed to bring. No, go rather to them that sell, and
buy for yourself.

Listen to those who were wise enough to bring oil for their lamps and can
see clearly on this issue.

Imagine if everybody started sending emails to es-discuss with your level
of appropiateness If they did, I'd unsubscribe, mark it as spam, and
create a custom filter just to ensure all emails with the words
'es-discuss' would be immediately deleted.

tl;dr Slap yourself.

I responded simply because I was annoyed that I actually read everything
you said.

Yawn...I mean, I would actually add something of value but umm... I wasted
all my reading time on this. lol

I've silently followed es-discuss for years. Please excuse me
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Question of the Day: What about all this asynchrony?

[T.J. Crowder]

On Wed, Nov 8, 2017 at 10:03 PM, Till Schneidereit
 wrote:
> (Also FTR, I don't think the discussions you're starting here and
> the way you're going about it and ignoring feedback people give
> you is very productive, but that's all I'm going to say on the
> matter.)

@Michael - FTR, he's not alone in that. The most *I'll* say on it is that I
would recommend looking again at the feedback provided by some cool heads
here, particularly Jeremy Martin who -- very far from seeming to try to
pick a fight -- shows every sign of having tried to do his best to be
engaged, understanding, and encouraging of a *useful* approach to
addressing the problems you see. I respect that you seem to have a
different view on that, but FWIW, that was what I saw in his replies, it
may be worth a re-read. Your call, naturally.

Best,

-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Question of the Day: What about all this asynchrony?

[T.J. Crowder]

On Wed, Nov 8, 2017 at 7:05 PM, kai zhu
 wrote:
>
> many of theses issues wouldn't exist if tc39 had responsibly
> gatekeeped es6 with a more modest feature-set of languages-changes

They did. You just disagree with the decisions that were taken, unlike
the vast, overwhelming majority of other people I've interacted with
on the subject, who see ES2015 and ES2017 as dramatic improvements.
You're entitled to your opinion, of course, but don't mistake it for a
general dissatisfaction felt by others.

I see people confused and uncertain whether to use a framework or
library and if so which one(s) (apparently this is an area where the
paradox of choice occurs), not unhappy with the improvements made to
the *language*.

-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Question of the Day: What about all this asynchrony?

[Till Schneidereit]

On Wed, Nov 8, 2017 at 7:05 PM, Michael Lewis  wrote:

> I don't want to break the rules and get removed from the list.  But it
> seems this list is powered by mozilla, and not "owned" by TC39 anyway.  And
> because there are no official topic rules, I think that discussing aspects
> that are *required* for JavaScript development is fair game.  Unless
> someone (at mozilla) requests otherwise.
>

FTR, that someone would be me, theoretically. In practice, Mozilla hosts
this mailing list, but you should consider TC39 to be the body it's
associated with, so my voice really doesn't have any more weight than other
members'.

(Also FTR, I don't think the discussions you're starting here and the way
you're going about it and ignoring feedback people give you is very
productive, but that's all I'm going to say on the matter.)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Question of the Day: What about all this asynchrony?

[Michael Lewis]

Wow dude... Again, you're trying to pick a fight.  I'm not "publicly
shaming" anyone, that's ridiculous.

All I have to say is, just watch.



On Wed, Nov 8, 2017 at 1:22 PM, Jeremy Martin  wrote:

> I don't represent TC39, and I don't like adding so much noise to this
> list, so this will be my last reply on the topic.
>
> There's nothing fundamentally wrong with what you want, but you're barking
> up the wrong tree to get it:
>
>
>> This (not concerning themselves with the end users experience) is a
>> mistake (an opinion).
>
>
> This group is acutely aware of, and concerned with, the end user
> experience. As previously stated, many (if not most) of the members
> actively contribute from their personal time to assist in these areas. But
> that *doesn't* mean that as a committee they are obligated to all aspects
> of the developer experience.
>
> I understand, but we can always do better (nothing is perfect).  And that
>> applies even with scarce resources.  It could be better.  I want to help.
>
>
> Whether scarce or abundant, when the "resource" is someone else's time and
> effort, you simply don't have any claim to it. If you want to help, then do
> it! Publicly shaming people who are *already* helping, simply because
> they're not helping where and how you want them to, is not ok, though.
>
> If I get time, I might head back there.  Honestly, though, I'm looking for
>> simple summaries as opposed to exhaustive histories.  Give me the
>> takeaways.  Save me some time.
>
>
> I wasn't going to respond until I read this part. Someone has already
> spent hours upon hours researching and compiling a useful resource (*A
> General Theory of Reactivity*), and instead of reading it, you're
> demanding *more* time from complete strangers to distill it into the
> exact level of verbosity that *you* want. That's not ok, and not what
> this mailing list is for. People in this list dedicate countless hours to
> save other people time, but their efforts aren't at your beck and call.
>
> Visual development is inevitable.
>
>
> Even if I am 100% in support of that statement, that doesn't mean that the
> visual development facilities are a part of the language itself. Again, I'm
> not trying to say that you have bad ideas, just that you've found the wrong
> mailing list for some of these.
>
> There's no need for a governing body that's not doing their job.
>
>
> The abundance of new features in the language is prima facie evidence that
> they are doing their job. Their job just isn't what you want it to be.
>
> Yet, many of the people on this list work on those runtime implementations
>> (Chrome, node, whatever).  I'm reaching out to anyone who will listen.
>
>
> That's fine, there's no harm in trying. But when the people you reach out
> to suggest that it's off topic or out of scope for the venue you've chosen,
> then it's not fine to start ranting and publicly shaming them.
>
> The problem is real.  The conclusion:  "won't fix".
>
>
> Yes, there is a real problem (at least a challenge, anyway). But the
> existence of a problem isn't a license to demand a solution from whomever
> you deem responsible. Even when members in this list have tried to offer
> some help, primarily by referencing relevant reading material, those
> efforts have been rejected because we didn't create the cliff notes for
> you. Again, I'm not the authority on what is or isn't within scope of this
> list, but the sum total of these demands, shaming, and wandering subject
> matter do not seem to be appropriate here.
>
>
> On Wed, Nov 8, 2017 at 1:05 PM, Michael Lewis  wrote:
>
>>
>>
>> On Wed, Nov 8, 2017 at 10:00 AM, Jeremy Martin  wrote:
>>
>>> Michael,
>>>
>>> You are not alone in your frustrations. Many of your points are valid,
>>> have been voiced before, and will no doubt be voiced again. No one on here
>>> is unsympathetic to this, and many members of TC39, as well as other
>>> community members, dedicate significant amounts of time, freely, to
>>> educational resources.
>>>
>>
>> Thanks, it's a relief to finally hear.  This was definitely *not* the
>> impression that I've gotten so far.  I've essentially heard, "there is no
>> problem, what are you talking about?"
>>
>>
>>>
>>> Lambasting TC39 for not formalizing and centralizing these educational
>>> resources -- a task that exists far outside of their charter -- is not
>>> productive.
>>>
>>
>> This (not concerning themselves with the end users experience) is a
>> mistake (an opinion).  The JavaScript community would be better off if more
>> care were given to this aspect (not an opinion).
>>
>>
>>>
>>> The list of useful resources out there is pretty extensive, and as
>>> you've pointed out, that can have a downside if you don't know where to go.
>>> If it's helpful, here's a non-canonical overview of some of the more useful
>>> ones, though:
>>>
>>> *For a one-stop shop:*
>>>
>>> MDN 

Re: Question of the Day: What about all this asynchrony?

[Terence M. Bandoian]

Thank you for this, Jeremy.

-Terence


On 11/8/2017 10:00 AM, Jeremy Martin wrote:

Michael,

You are not alone in your frustrations. Many of your points are valid, 
have been voiced before, and will no doubt be voiced again. No one on 
here is unsympathetic to this, and many members of TC39, as well as 
other community members, dedicate significant amounts of time, freely, 
to educational resources.


Lambasting TC39 for not formalizing and centralizing these educational 
resources -- a task that exists far outside of their charter -- is not 
productive.


The list of useful resources out there is pretty extensive, and as 
you've pointed out, that can have a downside if you don't know where 
to go. If it's helpful, here's a non-canonical overview of some of the 
more useful ones, though:


*/For a one-stop shop:/*

MDN (https://developer.mozilla.org/en-US/docs/Web/JavaScript). If you 
want a single destination, choose this one. It has introductory 
material, beginner, intermediate, and advanced-level tutorials, and is 
the most complete and well-maintained developer-focused JavaScript 
reference site.


*/For non-formal discussion of cutting-edge, emergent features:/*
*/
/*
Axel Rauschmayer's blog (http://2ality.com/). As it pertains to some 
of your specific questions, there is a lot of great material here on 
Promises in particular.


Dr. Rauschmayer has also written a series of extraordinarily useful 
books that he has graciously made freely available online, here: 
http://exploringjs.com/.


*/Regarding the "closed" nature of TC39:/*
*/
/*
Most discussion happens here on this mailing list, in public. Copious 
meeting notes for all in-person meetings are available here, as well: 
http://tc39.github.io/tc39-notes/.


*/If you want to search past es-discuss threads:/*
*/
/*
https://esdiscuss.org/

*/For "why doesn't this code work?" or "how do I do this?" questions:/*
*/
/*
StackOverflow (https://stackoverflow.com/). Still the gold standard 
here, IMO.


*/For your specific questions about why we have Promises AND 
Generators AND Iterators AND.../*

*/
/*
The General Theory of Relativity (https://github.com/kriskowal/gtor/). 
You obviously already mentioned this, but I encourage you to please go 
and read it. While this isn't a general resource for the language, it 
is the most comprehensive and useful exploration of this specific 
topic that I'm aware of, and I genuinely believe you would find it 
illuminating on why this complexity exists around asynchrony.


There are clearly many in addition to these, but that's a short list 
of some that I've personally found to be useful.


--

If you don't like that this all exists as discrete, separate 
resources, then that's an opinion that you're entitled to. A 
canonical, comprehensive, and centralized resource for all of this 
would required thousands of hours, either volunteered or paid for by 
others, and that's something no one is entitled to. If you want to 
make that happen, I suggest a strategy other than reprimanding a group 
of people that are already contributing significant time to what 
resources do exist.


Regarding topic appropriateness for this mailing list, admittedly the 
lines can be blurry at times. GUI's and developer tooling are 
typically outside of scope, though. Visualizations around Promises are 
an interesting topic, but as a non-TC39 member, I think I can still 
safely say that it won't be making it into the language itself. 
Tooling is best left to evolve independent of the language itself, 
rather than being frozen at the specification level. Even the most 
basic developer tools, like the `console` object, are not a part of 
the ecmascript spec - they are host objects provided by the runtime.


Again, I'm not trying to be dismissive of your ideas here, but the 
validity of an idea or a frustration isn't the measure for whether or 
not it's on-topic for es-discuss. If you want to continue discussing 
some of your ideas for the language, I'm not discouraging you from 
that, but I /am/ encouraging you to perhaps choose one to start with, 
evolve the idea until it's sufficiently clear and concrete to present 
for discussion.


On Wed, Nov 8, 2017 at 9:00 AM, Michael Lewis > wrote:


How difficult is it for a web developer to make a website?

What if everyone in this mailing list shared their personal
websites, and we ranked them?  Not that mine is great, but at
least I'm admitting that it's really fucking hard to make a simple
website... I know a *lot *of web developers that *don't have their
own website*.  And most that do, probably used WordPress, a static
site generator, or another crutch.

I was reading a post by Jake Archibald
 the
other day, and noticed he had some interactive elements within the
content of his page.  Wow, what a concept, right? Besides some
major 

Re: Question of the Day: What about all this asynchrony?

[Jeremy Martin]

I don't represent TC39, and I don't like adding so much noise to this list,
so this will be my last reply on the topic.

There's nothing fundamentally wrong with what you want, but you're barking
up the wrong tree to get it:


> This (not concerning themselves with the end users experience) is a
> mistake (an opinion).


This group is acutely aware of, and concerned with, the end user
experience. As previously stated, many (if not most) of the members
actively contribute from their personal time to assist in these areas. But
that *doesn't* mean that as a committee they are obligated to all aspects
of the developer experience.

I understand, but we can always do better (nothing is perfect).  And that
> applies even with scarce resources.  It could be better.  I want to help.


Whether scarce or abundant, when the "resource" is someone else's time and
effort, you simply don't have any claim to it. If you want to help, then do
it! Publicly shaming people who are *already* helping, simply because
they're not helping where and how you want them to, is not ok, though.

If I get time, I might head back there.  Honestly, though, I'm looking for
> simple summaries as opposed to exhaustive histories.  Give me the
> takeaways.  Save me some time.


I wasn't going to respond until I read this part. Someone has already spent
hours upon hours researching and compiling a useful resource (*A General
Theory of Reactivity*), and instead of reading it, you're demanding *more* time
from complete strangers to distill it into the exact level of verbosity
that *you* want. That's not ok, and not what this mailing list is for.
People in this list dedicate countless hours to save other people time, but
their efforts aren't at your beck and call.

Visual development is inevitable.


Even if I am 100% in support of that statement, that doesn't mean that the
visual development facilities are a part of the language itself. Again, I'm
not trying to say that you have bad ideas, just that you've found the wrong
mailing list for some of these.

There's no need for a governing body that's not doing their job.


The abundance of new features in the language is prima facie evidence that
they are doing their job. Their job just isn't what you want it to be.

Yet, many of the people on this list work on those runtime implementations
> (Chrome, node, whatever).  I'm reaching out to anyone who will listen.


That's fine, there's no harm in trying. But when the people you reach out
to suggest that it's off topic or out of scope for the venue you've chosen,
then it's not fine to start ranting and publicly shaming them.

The problem is real.  The conclusion:  "won't fix".


Yes, there is a real problem (at least a challenge, anyway). But the
existence of a problem isn't a license to demand a solution from whomever
you deem responsible. Even when members in this list have tried to offer
some help, primarily by referencing relevant reading material, those
efforts have been rejected because we didn't create the cliff notes for
you. Again, I'm not the authority on what is or isn't within scope of this
list, but the sum total of these demands, shaming, and wandering subject
matter do not seem to be appropriate here.


On Wed, Nov 8, 2017 at 1:05 PM, Michael Lewis  wrote:

>
>
> On Wed, Nov 8, 2017 at 10:00 AM, Jeremy Martin  wrote:
>
>> Michael,
>>
>> You are not alone in your frustrations. Many of your points are valid,
>> have been voiced before, and will no doubt be voiced again. No one on here
>> is unsympathetic to this, and many members of TC39, as well as other
>> community members, dedicate significant amounts of time, freely, to
>> educational resources.
>>
>
> Thanks, it's a relief to finally hear.  This was definitely *not* the
> impression that I've gotten so far.  I've essentially heard, "there is no
> problem, what are you talking about?"
>
>
>>
>> Lambasting TC39 for not formalizing and centralizing these educational
>> resources -- a task that exists far outside of their charter -- is not
>> productive.
>>
>
> This (not concerning themselves with the end users experience) is a
> mistake (an opinion).  The JavaScript community would be better off if more
> care were given to this aspect (not an opinion).
>
>
>>
>> The list of useful resources out there is pretty extensive, and as you've
>> pointed out, that can have a downside if you don't know where to go. If
>> it's helpful, here's a non-canonical overview of some of the more useful
>> ones, though:
>>
>> *For a one-stop shop:*
>>
>> MDN (https://developer.mozilla.org/en-US/docs/Web/JavaScript). If you
>> want a single destination, choose this one. It has introductory material,
>> beginner, intermediate, and advanced-level tutorials, and is the most
>> complete and well-maintained developer-focused JavaScript reference site.
>>
>
> MDN is great, I find myself here frequently.
>
>
>>
>> *For non-formal discussion of cutting-edge, emergent features:*
>>

Re: Question of the Day: What about all this asynchrony?

[Isiah Meadows]

Michael,

>>
>>
>> Lambasting TC39 for not formalizing and centralizing these educational
>> resources -- a task that exists far outside of their charter -- is not
>> productive.
>
>
> This (not concerning themselves with the end users experience) is a mistake
> (an opinion).  The JavaScript community would be better off if more care
> were given to this aspect (not an opinion).
>

The point Jeremy was trying to make is that it's one thing to complain
that there doesn't exist any decent centralized resources about this
outside maybe MDN (which has a focus on docs, not so much tutorials or
committee stuff). TC39 does attempt to be as open as practically
possible, unusually more so than any other ECMA technical committee
(they've noted several struggles with ECMA and ISO here).

Also, most TC39 committee members are *excessively* busy, with
families, jobs, talks, and expert consultation. A little perspective
helps here.

>>
>>
>> Dr. Rauschmayer has also written a series of extraordinarily useful books
>> that he has graciously made freely available online, here:
>> http://exploringjs.com/.
>>
>> Regarding the "closed" nature of TC39:
>>
>> Most discussion happens here on this mailing list, in public. Copious
>> meeting notes for all in-person meetings are available here, as well:
>> http://tc39.github.io/tc39-notes/.
>
>
> So this mailing list is it, and it seems my efforts here are failing.
>

I wouldn't say they're failing so much as there's a lot more nuance
than what meets the eye. My complaints have historically been in the
case of certain implementors not being quite open enough on why they
would refuse to accept certain proposals ([Google on one of the
cancellation proposals][1], for example).

[1]: https://github.com/tc39/proposal-cancelable-promises/issues/70

>>
>>
>> For your specific questions about why we have Promises AND Generators AND
>> Iterators AND...
>>
>> The General Theory of Relativity (https://github.com/kriskowal/gtor/). You
>> obviously already mentioned this, but I encourage you to please go and read
>> it. While this isn't a general resource for the language, it is the most
>> comprehensive and useful exploration of this specific topic that I'm aware
>> of, and I genuinely believe you would find it illuminating on why this
>> complexity exists around asynchrony.
>
>
> If I get time, I might head back there.  Honestly, though, I'm looking for
> simple summaries as opposed to exhaustive histories.  Give me the takeaways.
> Save me some time.  And, more importantly, what will the future be like?
> That's what I was in search of.  What has this committee concluded on is the
> vision for the future (in terms of all the various async solutions, and
> creating interoperable adapters)?  I don't think the answer to this is in
> that document.

That does include some history, but it's probably more of an
exhaustive explanation of asynchrony than a simple summary.\*

\* It's actually called "A General Theory of Reactivity", for future readers.

>>
>> Tooling is best left to evolve independent of the language itself, rather
>> than being frozen at the specification level. Even the most basic developer
>> tools, like the `console` object, are not a part of the ecmascript spec -
>> they are host objects provided by the runtime.
>
>
> I understand.  Yet, many of the people on this list work on those runtime
> implementations (Chrome, node, whatever).  I'm reaching out to anyone who
> will listen.

Just because some of them work on tooling doesn't obligate them to
include any of it in the spec - in particular, it might encourage them
to leave certain things out, just to keep the tooling separate.
Another example: the C++ standard doesn't mandate any linter warnings,
but all major C++ compilers implement numerous linter options anyways.

> I guess the average developer is required to follow all the people, read all
> the blogs, come back to MDN every so often and reread the entire site to
> make sure they don't miss something that appears in there.

The average developer only really needs to care about what's shipping
in browsers, and IMHO, [JavaScript Weekly][2] fills 90% of that void
(it also includes other interesting developments). Pretty much
everything that's hit stage 4 (shipping in the next spec revision) has
made it to JavaScript Weekly, including smaller things like the
[template literal revision][3].

[2]: http://javascriptweekly.com/
[3]: http://javascriptweekly.com/issues/300

-

Isiah Meadows
m...@isiahmeadows.com

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Question of the Day: What about all this asynchrony?

[kai zhu]

criticizing tc39 for the current problems in frontend-development is fair-game.

many of theses issues wouldn't exist if tc39 had responsibly
gatekeeped es6 with a more modest feature-set of languages-changes,
instead of creating an entirely new language.

On 11/9/17, Michael Lewis  wrote:
> On Wed, Nov 8, 2017 at 10:00 AM, Jeremy Martin  wrote:
>
>> Michael,
>>
>> You are not alone in your frustrations. Many of your points are valid,
>> have been voiced before, and will no doubt be voiced again. No one on
>> here
>> is unsympathetic to this, and many members of TC39, as well as other
>> community members, dedicate significant amounts of time, freely, to
>> educational resources.
>>
>
> Thanks, it's a relief to finally hear.  This was definitely *not* the
> impression that I've gotten so far.  I've essentially heard, "there is no
> problem, what are you talking about?"
>
>
>>
>> Lambasting TC39 for not formalizing and centralizing these educational
>> resources -- a task that exists far outside of their charter -- is not
>> productive.
>>
>
> This (not concerning themselves with the end users experience) is a mistake
> (an opinion).  The JavaScript community would be better off if more care
> were given to this aspect (not an opinion).
>
>
>>
>> The list of useful resources out there is pretty extensive, and as you've
>> pointed out, that can have a downside if you don't know where to go. If
>> it's helpful, here's a non-canonical overview of some of the more useful
>> ones, though:
>>
>> *For a one-stop shop:*
>>
>> MDN (https://developer.mozilla.org/en-US/docs/Web/JavaScript). If you
>> want a single destination, choose this one. It has introductory material,
>> beginner, intermediate, and advanced-level tutorials, and is the most
>> complete and well-maintained developer-focused JavaScript reference site.
>>
>
> MDN is great, I find myself here frequently.
>
>
>>
>> *For non-formal discussion of cutting-edge, emergent features:*
>>
>> Axel Rauschmayer's blog (http://2ality.com/). As it pertains to some of
>> your specific questions, there is a lot of great material here on
>> Promises
>> in particular.
>>
>
> I read a good portion of his Meta Programming chapter, and find myself here
> frequently.
>
>
>>
>> Dr. Rauschmayer has also written a series of extraordinarily useful books
>> that he has graciously made freely available online, here:
>> http://exploringjs.com/.
>>
>> *Regarding the "closed" nature of TC39:*
>>
>> Most discussion happens here on this mailing list, in public. Copious
>> meeting notes for all in-person meetings are available here, as well:
>> http://tc39.github.io/tc39-notes/.
>>
>
> So this mailing list is it, and it seems my efforts here are failing.
>
>
>>
>> *If you want to search past es-discuss threads:*
>>
>> https://esdiscuss.org/
>>
>>
> Yes, my original post in this thread links there.  I'm aware that all these
> emails are public archived.
>
>
>>
>> *For your specific questions about why we have Promises AND Generators
>> AND
>> Iterators AND...*
>>
>> The General Theory of Relativity (https://github.com/kriskowal/gtor/).
>> You obviously already mentioned this, but I encourage you to please go
>> and
>> read it. While this isn't a general resource for the language, it is the
>> most comprehensive and useful exploration of this specific topic that I'm
>> aware of, and I genuinely believe you would find it illuminating on why
>> this complexity exists around asynchrony.
>>
>
> If I get time, I might head back there.  Honestly, though, I'm looking for
> simple summaries as opposed to exhaustive histories.  Give me the
> takeaways.  Save me some time.  And, more importantly, what will the future
> be like?  That's what I was in search of.  What has this committee
> concluded on is the vision for the future (in terms of all the various
> async solutions, and creating interoperable adapters)?  I don't think the
> answer to this is in that document.
>
>
>
>>
>> There are clearly many in addition to these, but that's a short list of
>> some that I've personally found to be useful.
>>
>
> I sincerely appreciate your time in compiling the list.
>
>
>>
>> --
>>
>> If you don't like that this all exists as discrete, separate resources,
>> then that's an opinion that you're entitled to. A canonical,
>> comprehensive,
>> and centralized resource for all of this would required thousands of
>> hours,
>> either volunteered or paid for by others, and that's something no one is
>> entitled to. If you want to make that happen, I suggest a strategy other
>> than reprimanding a group of people that are already contributing
>> significant time to what resources do exist.
>>
>
> I understand, but we can always do better (nothing is perfect).  And that
> applies even with scarce resources.  It could be better.  I want to help.
>
>
>>
>> Regarding topic appropriateness for this mailing list, admittedly the
>> lines can be blurry at times. GUI's and 

Re: Question of the Day: What about all this asynchrony?

[Michael Lewis]

On Wed, Nov 8, 2017 at 10:00 AM, Jeremy Martin  wrote:

> Michael,
>
> You are not alone in your frustrations. Many of your points are valid,
> have been voiced before, and will no doubt be voiced again. No one on here
> is unsympathetic to this, and many members of TC39, as well as other
> community members, dedicate significant amounts of time, freely, to
> educational resources.
>

Thanks, it's a relief to finally hear.  This was definitely *not* the
impression that I've gotten so far.  I've essentially heard, "there is no
problem, what are you talking about?"


>
> Lambasting TC39 for not formalizing and centralizing these educational
> resources -- a task that exists far outside of their charter -- is not
> productive.
>

This (not concerning themselves with the end users experience) is a mistake
(an opinion).  The JavaScript community would be better off if more care
were given to this aspect (not an opinion).


>
> The list of useful resources out there is pretty extensive, and as you've
> pointed out, that can have a downside if you don't know where to go. If
> it's helpful, here's a non-canonical overview of some of the more useful
> ones, though:
>
> *For a one-stop shop:*
>
> MDN (https://developer.mozilla.org/en-US/docs/Web/JavaScript). If you
> want a single destination, choose this one. It has introductory material,
> beginner, intermediate, and advanced-level tutorials, and is the most
> complete and well-maintained developer-focused JavaScript reference site.
>

MDN is great, I find myself here frequently.


>
> *For non-formal discussion of cutting-edge, emergent features:*
>
> Axel Rauschmayer's blog (http://2ality.com/). As it pertains to some of
> your specific questions, there is a lot of great material here on Promises
> in particular.
>

I read a good portion of his Meta Programming chapter, and find myself here
frequently.


>
> Dr. Rauschmayer has also written a series of extraordinarily useful books
> that he has graciously made freely available online, here:
> http://exploringjs.com/.
>
> *Regarding the "closed" nature of TC39:*
>
> Most discussion happens here on this mailing list, in public. Copious
> meeting notes for all in-person meetings are available here, as well:
> http://tc39.github.io/tc39-notes/.
>

So this mailing list is it, and it seems my efforts here are failing.


>
> *If you want to search past es-discuss threads:*
>
> https://esdiscuss.org/
>
>
Yes, my original post in this thread links there.  I'm aware that all these
emails are public archived.


>
> *For your specific questions about why we have Promises AND Generators AND
> Iterators AND...*
>
> The General Theory of Relativity (https://github.com/kriskowal/gtor/).
> You obviously already mentioned this, but I encourage you to please go and
> read it. While this isn't a general resource for the language, it is the
> most comprehensive and useful exploration of this specific topic that I'm
> aware of, and I genuinely believe you would find it illuminating on why
> this complexity exists around asynchrony.
>

If I get time, I might head back there.  Honestly, though, I'm looking for
simple summaries as opposed to exhaustive histories.  Give me the
takeaways.  Save me some time.  And, more importantly, what will the future
be like?  That's what I was in search of.  What has this committee
concluded on is the vision for the future (in terms of all the various
async solutions, and creating interoperable adapters)?  I don't think the
answer to this is in that document.



>
> There are clearly many in addition to these, but that's a short list of
> some that I've personally found to be useful.
>

I sincerely appreciate your time in compiling the list.


>
> --
>
> If you don't like that this all exists as discrete, separate resources,
> then that's an opinion that you're entitled to. A canonical, comprehensive,
> and centralized resource for all of this would required thousands of hours,
> either volunteered or paid for by others, and that's something no one is
> entitled to. If you want to make that happen, I suggest a strategy other
> than reprimanding a group of people that are already contributing
> significant time to what resources do exist.
>

I understand, but we can always do better (nothing is perfect).  And that
applies even with scarce resources.  It could be better.  I want to help.


>
> Regarding topic appropriateness for this mailing list, admittedly the
> lines can be blurry at times. GUI's and developer tooling are typically
> outside of scope, though.  Visualizations around Promises are an
> interesting topic, but as a non-TC39 member, I think I can still safely say
> that it won't be making it into the language itself.
>

Visual development is inevitable.  If TC39 doesn't address it, then by the
time visual development becomes the norm, TC39 probably won't exist.
There's no need for a governing body that's not doing their job.


> Tooling is best left to evolve 

Re: Question of the Day: What about all this asynchrony?

[Jeremy Martin]

Michael,

You are not alone in your frustrations. Many of your points are valid, have
been voiced before, and will no doubt be voiced again. No one on here is
unsympathetic to this, and many members of TC39, as well as other community
members, dedicate significant amounts of time, freely, to educational
resources.

Lambasting TC39 for not formalizing and centralizing these educational
resources -- a task that exists far outside of their charter -- is not
productive.

The list of useful resources out there is pretty extensive, and as you've
pointed out, that can have a downside if you don't know where to go. If
it's helpful, here's a non-canonical overview of some of the more useful
ones, though:

*For a one-stop shop:*

MDN (https://developer.mozilla.org/en-US/docs/Web/JavaScript). If you want
a single destination, choose this one. It has introductory material,
beginner, intermediate, and advanced-level tutorials, and is the most
complete and well-maintained developer-focused JavaScript reference site.

*For non-formal discussion of cutting-edge, emergent features:*

Axel Rauschmayer's blog (http://2ality.com/). As it pertains to some of
your specific questions, there is a lot of great material here on Promises
in particular.

Dr. Rauschmayer has also written a series of extraordinarily useful books
that he has graciously made freely available online, here:
http://exploringjs.com/.

*Regarding the "closed" nature of TC39:*

Most discussion happens here on this mailing list, in public. Copious
meeting notes for all in-person meetings are available here, as well:
http://tc39.github.io/tc39-notes/.

*If you want to search past es-discuss threads:*

https://esdiscuss.org/

*For "why doesn't this code work?" or "how do I do this?" questions:*

StackOverflow (https://stackoverflow.com/). Still the gold standard here,
IMO.

*For your specific questions about why we have Promises AND Generators AND
Iterators AND...*

The General Theory of Relativity (https://github.com/kriskowal/gtor/). You
obviously already mentioned this, but I encourage you to please go and read
it. While this isn't a general resource for the language, it is the most
comprehensive and useful exploration of this specific topic that I'm aware
of, and I genuinely believe you would find it illuminating on why this
complexity exists around asynchrony.

There are clearly many in addition to these, but that's a short list of
some that I've personally found to be useful.

--

If you don't like that this all exists as discrete, separate resources,
then that's an opinion that you're entitled to. A canonical, comprehensive,
and centralized resource for all of this would required thousands of hours,
either volunteered or paid for by others, and that's something no one is
entitled to. If you want to make that happen, I suggest a strategy other
than reprimanding a group of people that are already contributing
significant time to what resources do exist.

Regarding topic appropriateness for this mailing list, admittedly the lines
can be blurry at times. GUI's and developer tooling are typically outside
of scope, though.  Visualizations around Promises are an interesting topic,
but as a non-TC39 member, I think I can still safely say that it won't be
making it into the language itself. Tooling is best left to evolve
independent of the language itself, rather than being frozen at the
specification level. Even the most basic developer tools, like the
`console` object, are not a part of the ecmascript spec - they are host
objects provided by the runtime.

Again, I'm not trying to be dismissive of your ideas here, but the validity
of an idea or a frustration isn't the measure for whether or not it's
on-topic for es-discuss. If you want to continue discussing some of your
ideas for the language, I'm not discouraging you from that, but I *am*
encouraging
you to perhaps choose one to start with, evolve the idea until it's
sufficiently clear and concrete to present for discussion.


On Wed, Nov 8, 2017 at 9:00 AM, Michael Lewis  wrote:

> How difficult is it for a web developer to make a website?
>
> What if everyone in this mailing list shared their personal websites, and
> we ranked them?  Not that mine is great, but at least I'm admitting that
> it's really fucking hard to make a simple website... I know a *lot *of
> web developers that *don't have their own website*.  And most that do,
> probably used WordPress, a static site generator, or another crutch.
>
> I was reading a post by Jake Archibald
>  the
> other day, and noticed he had some interactive elements within the content
> of his page.  Wow, what a concept, right?  Besides some major news outlets,
> I very rarely see this on the web.  Aside from an image (non interactive)
> or a video (hardly "interactive"), how often do you see *interactive
> content* on the web?  Very rarely.  How long did it take to create?  

Re: Question of the Day: What about all this asynchrony?

[Naveen Chawla]

I did help you. I answered your question: I said async functions are
preferable over all the other alternatives. And I said others can weigh in
with their own perspective if they disagree. Of course TC39 justifies their
decisions: but it's left up to us, as the developers, to find out what the
best way is. For example, I use "const" almost everywhere, but nobody at
TC39 told me to do that: they just introduced it and explained the
reasoning for its introduction. The same with boolean expressions: I use
things like `car && car.drive()` instead of `if(car) car.drive()` but
nobody told me to do so: I just find it terser.

On Wed, 8 Nov 2017 at 19:30 Michael Lewis  wrote:

> How difficult is it for a web developer to make a website?
>
> What if everyone in this mailing list shared their personal websites, and
> we ranked them?  Not that mine is great, but at least I'm admitting that
> it's really fucking hard to make a simple website... I know a *lot *of
> web developers that *don't have their own website*.  And most that do,
> probably used WordPress, a static site generator, or another crutch.
>
> I was reading a post by Jake Archibald
>  the
> other day, and noticed he had some interactive elements within the content
> of his page.  Wow, what a concept, right?  Besides some major news outlets,
> I very rarely see this on the web.  Aside from an image (non interactive)
> or a video (hardly "interactive"), how often do you see *interactive
> content* on the web?  Very rarely.  How long did it take to create?  Jake
> says he spent his entire weekend on that one blog post.
>
> *THE WEB IS BROKEN.  FOR CHRIST'S SAKE.  *And yes, I understand that
> nobody in this mailing list cares.  Maybe I need to join the whatwg group,
> and yell at them.  Or maybe I just continue working on it, by myself, in my
> basement.  Or maybe I'll get some help someday.  Lead me, follow me, or get
> the fuck out of my way.
>
> Also, this is a fitting time to share a page
>  I wanted to share a while
> back (due to Jeremy Martin's inability to imagine a visual development
> experience).  It doesn't live re-evaluate the code for each block, as it
> could.  But it shows some object renderings.  If you scroll down to the
> last test block, and click on the object titled "this", you'll see a
> rendering of the actual Test object.  You can see the 1 line of code used
> to render that:  View.inspect(this, "this");
>
> So yes, Jeremy, you could "automatically render Promise diagrams"... Maybe
> I'll get around to showing you how that works.
>
> What does your app *look like?*  Creating views for all the things is
> really important.  If you can see it, you can understand it.
>
> On Wed, Nov 8, 2017 at 7:39 AM, Michael Lewis  wrote:
>
>> So, the group that designs the language that the world uses for building
>> web apps, cannot provide insight as to why they do what they do?  Smells
>> like bullshit.  Maybe you can expand on that part further?
>>
>> Check this  out.  It seems
>> the ECMA/TC39 group is closed to the public.
>>
>> I'm just trying to make this easier for everyone...
>>
>> This reminds me of our government, who writes laws so dense even the
>> lawmakers don't read them.  And then they expect everyone to abide by
>> them.  It's *somewhat* understandable (given the complexity of life).
>> Yet, there's an easy/obvious solution:  summarize, organize, and simplify.
>> The law/specifications can be complex and simple, at the same time.  And I
>> feel like it's the responsibility of those who understand it the best to
>> accurately reduce the complexity into simpler form.
>>
>> This process (organizing, summarizing, simplifying) is the ultimate key
>> to life.  Science, education, content, knowledge... Sometimes we do this,
>> but it can always be done better.
>>
>> Have we taken JavaScript knowledge, and organized, summarized, and
>> simplified it to its purest form?  Absolutely not.  Not even close.
>>
>> In some areas of JS development (such as module management (dep mgmt,
>> loading/import), version control, debugging, persistence, etc) the *best* 
>> solutions
>> that we have, are *severely broken*, *have been broken for decades*, and 
>> *TC39
>> isn't concerned with*.  That sounds like a problem to me.  I'm sure
>> everyone here would like to argue with me about this.  The point is to
>> realize where these areas *can be better*, and *make them better*.  Not
>> to argue about why they're not broken... Duh.
>>
>> But, it seems like we need a new umbrella organization that's allowed to
>> discuss the entire picture.  Hahaha... it's so stupid.  "Don't talk about
>> that here."  "That's not a problem, you're the problem."  So much broken.
>>
>> On Wed, Nov 8, 2017 at 6:49 AM, Naveen Chawla 
>> wrote:
>>
>>> Hi Michael! TC39 

Re: Question of the Day: What about all this asynchrony?

[T.J. Crowder]

I was hoping the last message was a one-off. As it now clearly isn't...

Michael, along with all the other feedback you've received, please DO NOT
swear on this list. This is a professional environment. It's entirely
possible to express oneself clearly (and, er, concisely) without resorting
to swearing.

Thank you,

-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Question of the Day: What about all this asynchrony?

[Michael Lewis]

How difficult is it for a web developer to make a website?

What if everyone in this mailing list shared their personal websites, and
we ranked them?  Not that mine is great, but at least I'm admitting that
it's really fucking hard to make a simple website... I know a *lot *of web
developers that *don't have their own website*.  And most that do, probably
used WordPress, a static site generator, or another crutch.

I was reading a post by Jake Archibald
 the
other day, and noticed he had some interactive elements within the content
of his page.  Wow, what a concept, right?  Besides some major news outlets,
I very rarely see this on the web.  Aside from an image (non interactive)
or a video (hardly "interactive"), how often do you see *interactive
content* on the web?  Very rarely.  How long did it take to create?  Jake
says he spent his entire weekend on that one blog post.

*THE WEB IS BROKEN.  FOR CHRIST'S SAKE.  *And yes, I understand that nobody
in this mailing list cares.  Maybe I need to join the whatwg group, and
yell at them.  Or maybe I just continue working on it, by myself, in my
basement.  Or maybe I'll get some help someday.  Lead me, follow me, or get
the fuck out of my way.

Also, this is a fitting time to share a page
 I wanted to share a while back
(due to Jeremy Martin's inability to imagine a visual development
experience).  It doesn't live re-evaluate the code for each block, as it
could.  But it shows some object renderings.  If you scroll down to the
last test block, and click on the object titled "this", you'll see a
rendering of the actual Test object.  You can see the 1 line of code used
to render that:  View.inspect(this, "this");

So yes, Jeremy, you could "automatically render Promise diagrams"... Maybe
I'll get around to showing you how that works.

What does your app *look like?*  Creating views for all the things is
really important.  If you can see it, you can understand it.

On Wed, Nov 8, 2017 at 7:39 AM, Michael Lewis  wrote:

> So, the group that designs the language that the world uses for building
> web apps, cannot provide insight as to why they do what they do?  Smells
> like bullshit.  Maybe you can expand on that part further?
>
> Check this  out.  It seems
> the ECMA/TC39 group is closed to the public.
>
> I'm just trying to make this easier for everyone...
>
> This reminds me of our government, who writes laws so dense even the
> lawmakers don't read them.  And then they expect everyone to abide by
> them.  It's *somewhat* understandable (given the complexity of life).
> Yet, there's an easy/obvious solution:  summarize, organize, and simplify.
> The law/specifications can be complex and simple, at the same time.  And I
> feel like it's the responsibility of those who understand it the best to
> accurately reduce the complexity into simpler form.
>
> This process (organizing, summarizing, simplifying) is the ultimate key to
> life.  Science, education, content, knowledge... Sometimes we do this, but
> it can always be done better.
>
> Have we taken JavaScript knowledge, and organized, summarized, and
> simplified it to its purest form?  Absolutely not.  Not even close.
>
> In some areas of JS development (such as module management (dep mgmt,
> loading/import), version control, debugging, persistence, etc) the *best* 
> solutions
> that we have, are *severely broken*, *have been broken for decades*, and *TC39
> isn't concerned with*.  That sounds like a problem to me.  I'm sure
> everyone here would like to argue with me about this.  The point is to
> realize where these areas *can be better*, and *make them better*.  Not
> to argue about why they're not broken... Duh.
>
> But, it seems like we need a new umbrella organization that's allowed to
> discuss the entire picture.  Hahaha... it's so stupid.  "Don't talk about
> that here."  "That's not a problem, you're the problem."  So much broken.
>
> On Wed, Nov 8, 2017 at 6:49 AM, Naveen Chawla 
> wrote:
>
>> Hi Michael! TC39 is rightfully reluctant to offer usage advice. People
>> should develop their best practices from experiences and the use cases
>> they're involved in.
>>
>> For me, to answer your question, since I'm not a TC39 member, it's async
>> functions all the way, and ditch observables, raw promises, callbacks. I'd
>> love to hear from those who think observables might ever be preferable over
>> using async functions to do the same thing... since I don't currently see
>> how it could ever be
>>
>> On Wed, 8 Nov 2017 at 17:56 Michael Lewis  wrote:
>>
>>> Hi Felipe,
>>>
>>> I read and generally understand your points (while I don't fully
>>> understand all the new async syntax and best practices
>>> 

Re: Question of the Day: What about all this asynchrony?

[Michael Lewis]

So, the group that designs the language that the world uses for building
web apps, cannot provide insight as to why they do what they do?  Smells
like bullshit.  Maybe you can expand on that part further?

Check this  out.  It seems the
ECMA/TC39 group is closed to the public.

I'm just trying to make this easier for everyone...

This reminds me of our government, who writes laws so dense even the
lawmakers don't read them.  And then they expect everyone to abide by
them.  It's *somewhat* understandable (given the complexity of life).  Yet,
there's an easy/obvious solution:  summarize, organize, and simplify.  The
law/specifications can be complex and simple, at the same time.  And I feel
like it's the responsibility of those who understand it the best to
accurately reduce the complexity into simpler form.

This process (organizing, summarizing, simplifying) is the ultimate key to
life.  Science, education, content, knowledge... Sometimes we do this, but
it can always be done better.

Have we taken JavaScript knowledge, and organized, summarized, and
simplified it to its purest form?  Absolutely not.  Not even close.

In some areas of JS development (such as module management (dep mgmt,
loading/import), version control, debugging, persistence, etc) the
*best* solutions
that we have, are *severely broken*, *have been broken for decades*, and *TC39
isn't concerned with*.  That sounds like a problem to me.  I'm sure
everyone here would like to argue with me about this.  The point is to
realize where these areas *can be better*, and *make them better*.  Not to
argue about why they're not broken... Duh.

But, it seems like we need a new umbrella organization that's allowed to
discuss the entire picture.  Hahaha... it's so stupid.  "Don't talk about
that here."  "That's not a problem, you're the problem."  So much broken.

On Wed, Nov 8, 2017 at 6:49 AM, Naveen Chawla  wrote:

> Hi Michael! TC39 is rightfully reluctant to offer usage advice. People
> should develop their best practices from experiences and the use cases
> they're involved in.
>
> For me, to answer your question, since I'm not a TC39 member, it's async
> functions all the way, and ditch observables, raw promises, callbacks. I'd
> love to hear from those who think observables might ever be preferable over
> using async functions to do the same thing... since I don't currently see
> how it could ever be
>
> On Wed, 8 Nov 2017 at 17:56 Michael Lewis  wrote:
>
>> Hi Felipe,
>>
>> I read and generally understand your points (while I don't fully
>> understand all the new async syntax and best practices
>> ).
>> You agree that there's a lot to learn, but nobody wants to even
>> acknowledge that this committee has the power (responsibility?) to fix that
>> problem .  To make learning
>> simpler, easier, etc.  It could start with an official blog.  There are too
>> many scattered resources.  Too much conflicting advice, and not an official
>> direction.
>>
>> If Babel is here to stay - and transpiling custom syntax into official
>> syntax is going to proliferate, this problem will only get worse.
>>
>> This has to do with leadership - there doesn't seem to be a strong
>> presence leading the pack.  There are millions of developers scrambling to
>> make sense of all this stuff, and the best resources we have are the
>> continuous stream of blog posts that are constantly introducing new things,
>> and often create more questions than answers.
>>
>> It's clear to me that the people in this mailing list tend to stay at the
>> cutting edge.  You all read about the latest immediately when it's
>> released.  It makes sense to you, and there is no problem.  The "rest of
>> us" who struggle just aren't doing it right.
>>
>> On Tue, Nov 7, 2017 at 6:09 PM, Felipe Nascimento de Moura <
>> felipenmo...@gmail.com> wrote:
>>
>>> Hi.
>>>
>>> Michael, the JavaScript (and Web in general) communities are very open
>>> and always queen to help.
>>> I just think you hit the wrong mailing list to discuss all that.
>>>
>>> For new comers, indeed, there is plenty to work on, practice and study.
>>> But keep in mind that many of those features came from different languages
>>> and technologies.
>>> And there are a lot of conferences, meetups, groups, slack channels,
>>> newsletters, articles, videos...tons of content out there :)
>>>
>>> Trying to answer your question.
>>> I understand the feeling you are having, but think it this way...
>>> - Asynchronous code opens doors for possible gains in performance. Many
>>> improvements have only been possible due to this asynchronicity.
>>> - Async code helps you modulate/split your code. If your are an
>>> organized person, it will be good...otherwise, things can get messy!
>>> - Async code nowadays can be 

Re: Question of the Day: What about all this asynchrony?

[Naveen Chawla]

Hi Michael! TC39 is rightfully reluctant to offer usage advice. People
should develop their best practices from experiences and the use cases
they're involved in.

For me, to answer your question, since I'm not a TC39 member, it's async
functions all the way, and ditch observables, raw promises, callbacks. I'd
love to hear from those who think observables might ever be preferable over
using async functions to do the same thing... since I don't currently see
how it could ever be

On Wed, 8 Nov 2017 at 17:56 Michael Lewis  wrote:

> Hi Felipe,
>
> I read and generally understand your points (while I don't fully
> understand all the new async syntax and best practices
> ).
> You agree that there's a lot to learn, but nobody wants to even
> acknowledge that this committee has the power (responsibility?) to fix that
> problem .  To make learning
> simpler, easier, etc.  It could start with an official blog.  There are too
> many scattered resources.  Too much conflicting advice, and not an official
> direction.
>
> If Babel is here to stay - and transpiling custom syntax into official
> syntax is going to proliferate, this problem will only get worse.
>
> This has to do with leadership - there doesn't seem to be a strong
> presence leading the pack.  There are millions of developers scrambling to
> make sense of all this stuff, and the best resources we have are the
> continuous stream of blog posts that are constantly introducing new things,
> and often create more questions than answers.
>
> It's clear to me that the people in this mailing list tend to stay at the
> cutting edge.  You all read about the latest immediately when it's
> released.  It makes sense to you, and there is no problem.  The "rest of
> us" who struggle just aren't doing it right.
>
> On Tue, Nov 7, 2017 at 6:09 PM, Felipe Nascimento de Moura <
> felipenmo...@gmail.com> wrote:
>
>> Hi.
>>
>> Michael, the JavaScript (and Web in general) communities are very open
>> and always queen to help.
>> I just think you hit the wrong mailing list to discuss all that.
>>
>> For new comers, indeed, there is plenty to work on, practice and study.
>> But keep in mind that many of those features came from different languages
>> and technologies.
>> And there are a lot of conferences, meetups, groups, slack channels,
>> newsletters, articles, videos...tons of content out there :)
>>
>> Trying to answer your question.
>> I understand the feeling you are having, but think it this way...
>> - Asynchronous code opens doors for possible gains in performance. Many
>> improvements have only been possible due to this asynchronicity.
>> - Async code helps you modulate/split your code. If your are an organized
>> person, it will be good...otherwise, things can get messy!
>> - Async code nowadays can be dealt with, as if it was sync (using async
>> await), the other way around was a problem! Many times you needed something
>> asynchronous and had to create layers on top of it.
>> - Async allows new APIs. For example, Web workers and Service Workers.
>> They simply wouldn't be possible if not by asynchronous ways.
>> - Creating async APIs allows developers to explore and use your API in
>> different ways...also, if your code is well organized, it has an easier
>> maintanence.
>> - APIs related to interoperability and usability also benefit from this.
>> Let's say, you need a user permission to do something and have to way for
>> the user to agree with it. Or maybe you ware waiting for another app to
>> answer with the result from something else, like a picture or a share(from
>> shareAPI).
>>
>> As for "which" way you want to make your code async...that goes with what
>> you are working on.
>> If you are using promises, you can easily** have it working with
>> async/await.
>> Observables and promises can work together, but you will have to study a
>> little further to feel familiar with it.
>>
>> I hope I have helped somehow :)
>>
>>
>>
>> On Tue, Nov 7, 2017 at 8:42 PM, Michael Lewis  wrote:
>>
>>> Making things simpler, clearer, and more visual has obvious benefits.
>>>
>>> I think I was very clear from the beginning that this was *NOT* a
>>> concrete proposal.  And I've seen many posts on here that are not.  From
>>> now on, I'll title my posts to more clearly indicate that *reading is
>>> abstract, discussion, optional.*
>>>
>>> The confusion about async interoperability
>>> 
>>>  isn't
>>> mine alone.  I'm a new comer to this scene, and my original curiosity was
>>> this community's long-term vision for asynchrony.  How do we get all the
>>> pieces to play well together?  Thank you for contributing 0 to that
>>> understanding.
>>>
>>> And my point about the new comers to JavaScript or 

Re: Question of the Day: What about all this asynchrony?

[Michael Lewis]

Hi Felipe,

I read and generally understand your points (while I don't fully understand
all the new async syntax and best practices
).
You agree that there's a lot to learn, but nobody wants to even acknowledge
that this committee has the power (responsibility?) to fix that problem
.  To make learning simpler, easier,
etc.  It could start with an official blog.  There are too many scattered
resources.  Too much conflicting advice, and not an official direction.

If Babel is here to stay - and transpiling custom syntax into official
syntax is going to proliferate, this problem will only get worse.

This has to do with leadership - there doesn't seem to be a strong presence
leading the pack.  There are millions of developers scrambling to make
sense of all this stuff, and the best resources we have are the continuous
stream of blog posts that are constantly introducing new things, and often
create more questions than answers.

It's clear to me that the people in this mailing list tend to stay at the
cutting edge.  You all read about the latest immediately when it's
released.  It makes sense to you, and there is no problem.  The "rest of
us" who struggle just aren't doing it right.

On Tue, Nov 7, 2017 at 6:09 PM, Felipe Nascimento de Moura <
felipenmo...@gmail.com> wrote:

> Hi.
>
> Michael, the JavaScript (and Web in general) communities are very open and
> always queen to help.
> I just think you hit the wrong mailing list to discuss all that.
>
> For new comers, indeed, there is plenty to work on, practice and study.
> But keep in mind that many of those features came from different languages
> and technologies.
> And there are a lot of conferences, meetups, groups, slack channels,
> newsletters, articles, videos...tons of content out there :)
>
> Trying to answer your question.
> I understand the feeling you are having, but think it this way...
> - Asynchronous code opens doors for possible gains in performance. Many
> improvements have only been possible due to this asynchronicity.
> - Async code helps you modulate/split your code. If your are an organized
> person, it will be good...otherwise, things can get messy!
> - Async code nowadays can be dealt with, as if it was sync (using async
> await), the other way around was a problem! Many times you needed something
> asynchronous and had to create layers on top of it.
> - Async allows new APIs. For example, Web workers and Service Workers.
> They simply wouldn't be possible if not by asynchronous ways.
> - Creating async APIs allows developers to explore and use your API in
> different ways...also, if your code is well organized, it has an easier
> maintanence.
> - APIs related to interoperability and usability also benefit from this.
> Let's say, you need a user permission to do something and have to way for
> the user to agree with it. Or maybe you ware waiting for another app to
> answer with the result from something else, like a picture or a share(from
> shareAPI).
>
> As for "which" way you want to make your code async...that goes with what
> you are working on.
> If you are using promises, you can easily** have it working with
> async/await.
> Observables and promises can work together, but you will have to study a
> little further to feel familiar with it.
>
> I hope I have helped somehow :)
>
>
>
> On Tue, Nov 7, 2017 at 8:42 PM, Michael Lewis  wrote:
>
>> Making things simpler, clearer, and more visual has obvious benefits.
>>
>> I think I was very clear from the beginning that this was *NOT* a
>> concrete proposal.  And I've seen many posts on here that are not.  From
>> now on, I'll title my posts to more clearly indicate that *reading is
>> abstract, discussion, optional.*
>>
>> The confusion about async interoperability
>> 
>>  isn't
>> mine alone.  I'm a new comer to this scene, and my original curiosity was
>> this community's long-term vision for asynchrony.  How do we get all the
>> pieces to play well together?  Thank you for contributing 0 to that
>> understanding.
>>
>> And my point about the new comers to JavaScript or computers in general,
>> how are they to make sense of this ever-moving language?  You need better
>> documentation, publication (an official blog), etc.
>>
>> On Tue, Nov 7, 2017 at 3:03 PM, Jeremy Martin  wrote:
>>
>>> Michael,
>>>
>>> You've spent a considerable amount of time putting your thoughts into
>>> writing, so I don't intend to be dismissive of them, but this doesn't seem
>>> to be the right distribution channel for whatever you're getting at.
>>>
>>> As it stands, you've thrown quite a few questions out that don't seem to
>>> be related to the ongoing standardization and specification process that
>>> this group is primarily 

Re: Question of the Day: What about all this asynchrony?

[Felipe Nascimento de Moura]

Hi.

Michael, the JavaScript (and Web in general) communities are very open and
always queen to help.
I just think you hit the wrong mailing list to discuss all that.

For new comers, indeed, there is plenty to work on, practice and study. But
keep in mind that many of those features came from different languages and
technologies.
And there are a lot of conferences, meetups, groups, slack channels,
newsletters, articles, videos...tons of content out there :)

Trying to answer your question.
I understand the feeling you are having, but think it this way...
- Asynchronous code opens doors for possible gains in performance. Many
improvements have only been possible due to this asynchronicity.
- Async code helps you modulate/split your code. If your are an organized
person, it will be good...otherwise, things can get messy!
- Async code nowadays can be dealt with, as if it was sync (using async
await), the other way around was a problem! Many times you needed something
asynchronous and had to create layers on top of it.
- Async allows new APIs. For example, Web workers and Service Workers. They
simply wouldn't be possible if not by asynchronous ways.
- Creating async APIs allows developers to explore and use your API in
different ways...also, if your code is well organized, it has an easier
maintanence.
- APIs related to interoperability and usability also benefit from this.
Let's say, you need a user permission to do something and have to way for
the user to agree with it. Or maybe you ware waiting for another app to
answer with the result from something else, like a picture or a share(from
shareAPI).

As for "which" way you want to make your code async...that goes with what
you are working on.
If you are using promises, you can easily** have it working with
async/await.
Observables and promises can work together, but you will have to study a
little further to feel familiar with it.

I hope I have helped somehow :)



On Tue, Nov 7, 2017 at 8:42 PM, Michael Lewis  wrote:

> Making things simpler, clearer, and more visual has obvious benefits.
>
> I think I was very clear from the beginning that this was *NOT* a
> concrete proposal.  And I've seen many posts on here that are not.  From
> now on, I'll title my posts to more clearly indicate that *reading is
> abstract, discussion, optional.*
>
> The confusion about async interoperability
> 
>  isn't
> mine alone.  I'm a new comer to this scene, and my original curiosity was
> this community's long-term vision for asynchrony.  How do we get all the
> pieces to play well together?  Thank you for contributing 0 to that
> understanding.
>
> And my point about the new comers to JavaScript or computers in general,
> how are they to make sense of this ever-moving language?  You need better
> documentation, publication (an official blog), etc.
>
> On Tue, Nov 7, 2017 at 3:03 PM, Jeremy Martin  wrote:
>
>> Michael,
>>
>> You've spent a considerable amount of time putting your thoughts into
>> writing, so I don't intend to be dismissive of them, but this doesn't seem
>> to be the right distribution channel for whatever you're getting at.
>>
>> As it stands, you've thrown quite a few questions out that don't seem to
>> be related to the ongoing standardization and specification process that
>> this group is primarily focused on. E.g.,
>>
>>- Are RxJS Observables basically streams?
>>- What will our children be learning in 100 years?
>>- What are generators?
>>- ...do they work with Promises?
>>- ...do they work with streams?
>>- etc.
>>
>> There are reams of documentation, articles, and guides that delve into
>> these topics in great detail, including the excellent *General Theory of
>> Reactivity* that you already mentioned. The questions you've brought up
>> are all valid, and these resources will help you gain the knowledge you
>> need if you still want to put a specific proposal forward -- but for now
>> your points seem to awkwardly highlight that you've already identified the
>> best resources to do this, but refuse to actually read them.
>>
>> And while es-discuss is indeed an appropriate place to solicit feedback
>> on language-level proposals, the ideas you've thrown out read like an
>> off-the-cuff stream of consciousness:
>>
>>- Promises that automatically render diagrams?
>>- A GUI for loading/defining modules (somehow related to an AST)?
>>- Async strings with some informal behavior around branching and
>>transforms, that are someone analogous to version control, and again, a 
>> GUI
>>is involved somewhere?
>>- Real-time booleans with change events (but with a new definition
>>for "change events" that is oddly based around a non-reactive
>>datastructure).
>>
>> I made an honest attempt to make it through your posts with an eye for
>> what your point is, but these simply 

Re: Question of the Day: What about all this asynchrony?

[Michael Lewis]

Making things simpler, clearer, and more visual has obvious benefits.

I think I was very clear from the beginning that this was *NOT* a concrete
proposal.  And I've seen many posts on here that are not.  From now on,
I'll title my posts to more clearly indicate that *reading is abstract,
discussion, optional.*

The confusion about async interoperability

isn't
mine alone.  I'm a new comer to this scene, and my original curiosity was
this community's long-term vision for asynchrony.  How do we get all the
pieces to play well together?  Thank you for contributing 0 to that
understanding.

And my point about the new comers to JavaScript or computers in general,
how are they to make sense of this ever-moving language?  You need better
documentation, publication (an official blog), etc.

On Tue, Nov 7, 2017 at 3:03 PM, Jeremy Martin  wrote:

> Michael,
>
> You've spent a considerable amount of time putting your thoughts into
> writing, so I don't intend to be dismissive of them, but this doesn't seem
> to be the right distribution channel for whatever you're getting at.
>
> As it stands, you've thrown quite a few questions out that don't seem to
> be related to the ongoing standardization and specification process that
> this group is primarily focused on. E.g.,
>
>- Are RxJS Observables basically streams?
>- What will our children be learning in 100 years?
>- What are generators?
>- ...do they work with Promises?
>- ...do they work with streams?
>- etc.
>
> There are reams of documentation, articles, and guides that delve into
> these topics in great detail, including the excellent *General Theory of
> Reactivity* that you already mentioned. The questions you've brought up
> are all valid, and these resources will help you gain the knowledge you
> need if you still want to put a specific proposal forward -- but for now
> your points seem to awkwardly highlight that you've already identified the
> best resources to do this, but refuse to actually read them.
>
> And while es-discuss is indeed an appropriate place to solicit feedback on
> language-level proposals, the ideas you've thrown out read like an
> off-the-cuff stream of consciousness:
>
>- Promises that automatically render diagrams?
>- A GUI for loading/defining modules (somehow related to an AST)?
>- Async strings with some informal behavior around branching and
>transforms, that are someone analogous to version control, and again, a GUI
>is involved somewhere?
>- Real-time booleans with change events (but with a new definition for
>"change events" that is oddly based around a non-reactive datastructure).
>
> I made an honest attempt to make it through your posts with an eye for
> what your point is, but these simply aren't concrete or coherent enough to
> facilitate a conversation, much less be actionable.
>
> The concept of "do it now" or "do it later" is as easy as 123.
>
>
> I urge you to consider that statements like this belie that you haven't
> grappled with the subject matter enough. It frankly trivializes the topic
> beyond recognition.
>
> If you have a concrete proposal you'd like to see discussed, then a
> dedicated thread with a clear description, examples, and motivating factors
> is completely welcome. If you're looking to rant or ruminate around topics
> like Promises, Generators, Observables, Streams, etc., while simultaneously
> admitting that you aren't taking the time to understand them, then this is
> simply the wrong venue.
>
>
> On Tue, Nov 7, 2017 at 3:13 PM, Naveen Chawla 
> wrote:
>
>> Correct, `for..of` instead of `forEach`
>>
>> On Wed, 8 Nov 2017 at 01:21 Logan Smyth  wrote:
>>
>>> A nit, but that would have to be `for (const move of moves) await 
>>> doMoveAsync()`
>>> since the `forEach` callback is a normal function.
>>>
>>> On Tue, Nov 7, 2017 at 11:47 AM, Naveen Chawla 
>>> wrote:
>>>
 ... that should be `await doMoveAsync()`

 On Wed, 8 Nov 2017 at 01:16 Naveen Chawla 
 wrote:

> async functions create a new promise for you upon every invocation,
> which you resolve via `await`, but that's all invisible in the background.
> It's basically:
>
> async function doMovesAsync(){
> moves.forEach(
>  move=>{
>   doMoveAsync(); //another async function
>  }
> );
> }
>
> ...so you can do regular programming, in async world. This is why I
> believe it's more powerful than observables, thereby making them 
> redundant.
>
> When I say branching into multiple outputs, I do mean creating new
> data that leaves the original data untouched.
>
> On Tue, 7 Nov 2017 at 20:57 Michael Lewis  wrote:
>
>> Also, if you've made 

Re: Question of the Day: What about all this asynchrony?

[Jeremy Martin]

:(

Apologies, I didn't intend to reply-all on that. :\

I'll keep this one public too, since I just subjected everyone to the
previous email as well.

On Tue, Nov 7, 2017 at 4:03 PM, Jeremy Martin  wrote:

> Michael,
>
> You've spent a considerable amount of time putting your thoughts into
> writing, so I don't intend to be dismissive of them, but this doesn't seem
> to be the right distribution channel for whatever you're getting at.
>
> As it stands, you've thrown quite a few questions out that don't seem to
> be related to the ongoing standardization and specification process that
> this group is primarily focused on. E.g.,
>
>- Are RxJS Observables basically streams?
>- What will our children be learning in 100 years?
>- What are generators?
>- ...do they work with Promises?
>- ...do they work with streams?
>- etc.
>
> There are reams of documentation, articles, and guides that delve into
> these topics in great detail, including the excellent *General Theory of
> Reactivity* that you already mentioned. The questions you've brought up
> are all valid, and these resources will help you gain the knowledge you
> need if you still want to put a specific proposal forward -- but for now
> your points seem to awkwardly highlight that you've already identified the
> best resources to do this, but refuse to actually read them.
>
> And while es-discuss is indeed an appropriate place to solicit feedback on
> language-level proposals, the ideas you've thrown out read like an
> off-the-cuff stream of consciousness:
>
>- Promises that automatically render diagrams?
>- A GUI for loading/defining modules (somehow related to an AST)?
>- Async strings with some informal behavior around branching and
>transforms, that are someone analogous to version control, and again, a GUI
>is involved somewhere?
>- Real-time booleans with change events (but with a new definition for
>"change events" that is oddly based around a non-reactive datastructure).
>
> I made an honest attempt to make it through your posts with an eye for
> what your point is, but these simply aren't concrete or coherent enough to
> facilitate a conversation, much less be actionable.
>
> The concept of "do it now" or "do it later" is as easy as 123.
>
>
> I urge you to consider that statements like this belie that you haven't
> grappled with the subject matter enough. It frankly trivializes the topic
> beyond recognition.
>
> If you have a concrete proposal you'd like to see discussed, then a
> dedicated thread with a clear description, examples, and motivating factors
> is completely welcome. If you're looking to rant or ruminate around topics
> like Promises, Generators, Observables, Streams, etc., while simultaneously
> admitting that you aren't taking the time to understand them, then this is
> simply the wrong venue.
>
>
> On Tue, Nov 7, 2017 at 3:13 PM, Naveen Chawla 
> wrote:
>
>> Correct, `for..of` instead of `forEach`
>>
>> On Wed, 8 Nov 2017 at 01:21 Logan Smyth  wrote:
>>
>>> A nit, but that would have to be `for (const move of moves) await 
>>> doMoveAsync()`
>>> since the `forEach` callback is a normal function.
>>>
>>> On Tue, Nov 7, 2017 at 11:47 AM, Naveen Chawla 
>>> wrote:
>>>
 ... that should be `await doMoveAsync()`

 On Wed, 8 Nov 2017 at 01:16 Naveen Chawla 
 wrote:

> async functions create a new promise for you upon every invocation,
> which you resolve via `await`, but that's all invisible in the background.
> It's basically:
>
> async function doMovesAsync(){
> moves.forEach(
>  move=>{
>   doMoveAsync(); //another async function
>  }
> );
> }
>
> ...so you can do regular programming, in async world. This is why I
> believe it's more powerful than observables, thereby making them 
> redundant.
>
> When I say branching into multiple outputs, I do mean creating new
> data that leaves the original data untouched.
>
> On Tue, 7 Nov 2017 at 20:57 Michael Lewis  wrote:
>
>> Also, if you've made it this far, I think it's worth mentioning that
>> these async strings are basically all you need for a realtime file 
>> system.
>>
>> File("newFile.ext").append(File("fileA"), File("fileB"),
>> ...).transpile().save();
>> // --> automatically watches, all inputs (fileA, fileB, etc), caches
>> unchanged files, reapplies transforms, writes to file...
>>
>> Webpack and gulp are basically async plugin systems w/ transforms.
>> They're just way too complicated.
>>
>> Simplify all the things.
>>
>> And while we're at it, why not make a realtime version control
>> system?  Not just for files, but for all the things (any data structure
>> inside the app).  For example, if 

Re: Question of the Day: What about all this asynchrony?

[Jeremy Martin]

Michael,

You've spent a considerable amount of time putting your thoughts into
writing, so I don't intend to be dismissive of them, but this doesn't seem
to be the right distribution channel for whatever you're getting at.

As it stands, you've thrown quite a few questions out that don't seem to be
related to the ongoing standardization and specification process that this
group is primarily focused on. E.g.,

   - Are RxJS Observables basically streams?
   - What will our children be learning in 100 years?
   - What are generators?
   - ...do they work with Promises?
   - ...do they work with streams?
   - etc.

There are reams of documentation, articles, and guides that delve into
these topics in great detail, including the excellent *General Theory of
Reactivity* that you already mentioned. The questions you've brought up are
all valid, and these resources will help you gain the knowledge you need if
you still want to put a specific proposal forward -- but for now your
points seem to awkwardly highlight that you've already identified the best
resources to do this, but refuse to actually read them.

And while es-discuss is indeed an appropriate place to solicit feedback on
language-level proposals, the ideas you've thrown out read like an
off-the-cuff stream of consciousness:

   - Promises that automatically render diagrams?
   - A GUI for loading/defining modules (somehow related to an AST)?
   - Async strings with some informal behavior around branching and
   transforms, that are someone analogous to version control, and again, a GUI
   is involved somewhere?
   - Real-time booleans with change events (but with a new definition for
   "change events" that is oddly based around a non-reactive datastructure).

I made an honest attempt to make it through your posts with an eye for what
your point is, but these simply aren't concrete or coherent enough to
facilitate a conversation, much less be actionable.

The concept of "do it now" or "do it later" is as easy as 123.


I urge you to consider that statements like this belie that you haven't
grappled with the subject matter enough. It frankly trivializes the topic
beyond recognition.

If you have a concrete proposal you'd like to see discussed, then a
dedicated thread with a clear description, examples, and motivating factors
is completely welcome. If you're looking to rant or ruminate around topics
like Promises, Generators, Observables, Streams, etc., while simultaneously
admitting that you aren't taking the time to understand them, then this is
simply the wrong venue.


On Tue, Nov 7, 2017 at 3:13 PM, Naveen Chawla  wrote:

> Correct, `for..of` instead of `forEach`
>
> On Wed, 8 Nov 2017 at 01:21 Logan Smyth  wrote:
>
>> A nit, but that would have to be `for (const move of moves) await 
>> doMoveAsync()`
>> since the `forEach` callback is a normal function.
>>
>> On Tue, Nov 7, 2017 at 11:47 AM, Naveen Chawla 
>> wrote:
>>
>>> ... that should be `await doMoveAsync()`
>>>
>>> On Wed, 8 Nov 2017 at 01:16 Naveen Chawla  wrote:
>>>
 async functions create a new promise for you upon every invocation,
 which you resolve via `await`, but that's all invisible in the background.
 It's basically:

 async function doMovesAsync(){
 moves.forEach(
  move=>{
   doMoveAsync(); //another async function
  }
 );
 }

 ...so you can do regular programming, in async world. This is why I
 believe it's more powerful than observables, thereby making them redundant.

 When I say branching into multiple outputs, I do mean creating new data
 that leaves the original data untouched.

 On Tue, 7 Nov 2017 at 20:57 Michael Lewis  wrote:

> Also, if you've made it this far, I think it's worth mentioning that
> these async strings are basically all you need for a realtime file system.
>
> File("newFile.ext").append(File("fileA"), File("fileB"),
> ...).transpile().save();
> // --> automatically watches, all inputs (fileA, fileB, etc), caches
> unchanged files, reapplies transforms, writes to file...
>
> Webpack and gulp are basically async plugin systems w/ transforms.
> They're just way too complicated.
>
> Simplify all the things.
>
> And while we're at it, why not make a realtime version control
> system?  Not just for files, but for all the things (any data structure
> inside the app).  For example, if we have variable strings, could we 
> enable
> a history on it?  Instead of branching onto a separate entity/value, could
> we branch *within *the string itself, so that we have an entire *verrsion
> tree *for any value?
>
> *What are the fundamental data structures in computer science?*
> The Boolean, obviously.  The Integer.  The String.
>
> Why not a realtime 

Re: Question of the Day: What about all this asynchrony?

[Michael Lewis]

Oh, you're right :-\ empty async functions return a promise, interesting...

On Tue, Nov 7, 2017 at 2:27 PM, Michael Lewis  wrote:

> > async functions create a new promise for you upon every invocation,
> which you resolve via `await`, but that's all invisible in the background
>
> Is that correct?  I thought async functions simply await promises.  `await
> something()` works because something() returns a promise.  But is there a
> promise created "invisibly" every time you invoke an async function?
>
> On Tue, Nov 7, 2017 at 2:13 PM, Naveen Chawla 
> wrote:
>
>> Correct, `for..of` instead of `forEach`
>>
>> On Wed, 8 Nov 2017 at 01:21 Logan Smyth  wrote:
>>
>>> A nit, but that would have to be `for (const move of moves) await 
>>> doMoveAsync()`
>>> since the `forEach` callback is a normal function.
>>>
>>> On Tue, Nov 7, 2017 at 11:47 AM, Naveen Chawla 
>>> wrote:
>>>
 ... that should be `await doMoveAsync()`

 On Wed, 8 Nov 2017 at 01:16 Naveen Chawla 
 wrote:

> async functions create a new promise for you upon every invocation,
> which you resolve via `await`, but that's all invisible in the background.
> It's basically:
>
> async function doMovesAsync(){
> moves.forEach(
>  move=>{
>   doMoveAsync(); //another async function
>  }
> );
> }
>
> ...so you can do regular programming, in async world. This is why I
> believe it's more powerful than observables, thereby making them 
> redundant.
>
> When I say branching into multiple outputs, I do mean creating new
> data that leaves the original data untouched.
>
> On Tue, 7 Nov 2017 at 20:57 Michael Lewis  wrote:
>
>> Also, if you've made it this far, I think it's worth mentioning that
>> these async strings are basically all you need for a realtime file 
>> system.
>>
>> File("newFile.ext").append(File("fileA"), File("fileB"),
>> ...).transpile().save();
>> // --> automatically watches, all inputs (fileA, fileB, etc), caches
>> unchanged files, reapplies transforms, writes to file...
>>
>> Webpack and gulp are basically async plugin systems w/ transforms.
>> They're just way too complicated.
>>
>> Simplify all the things.
>>
>> And while we're at it, why not make a realtime version control
>> system?  Not just for files, but for all the things (any data structure
>> inside the app).  For example, if we have variable strings, could we 
>> enable
>> a history on it?  Instead of branching onto a separate entity/value, 
>> could
>> we branch *within *the string itself, so that we have an entire *verrsion
>> tree *for any value?
>>
>> *What are the fundamental data structures in computer science?*
>> The Boolean, obviously.  The Integer.  The String.
>>
>> Why not a realtime boolean?  I suppose that's just a boolean + change
>> events.  What is a "change event"?  Just an array of functions.  But
>> JavaScript functions are an abstract concept (compared to processor
>> instructions).  What do functions look like at the processor level?
>> They're compiled with all the dependent values, right?  How many 
>> processor
>> ticks does the average line of JavaScript use?
>>
>> I feel like all languages could boil down to a very small set of
>> fundamental data structures, and maybe a slightly larger set of 
>> specialized
>> data structures.
>>
>> What are the different types of circuits in a process?  I understand
>> (roughly) the basic logic gates, but is there specialized circuitry for
>> specialized data structures?  What if those fundamental data structures
>> were optimized at the circuitry level?
>>
>> What if we can optimize our programs to run as nearly instantly as
>> possible?  Most scripts are *mostly *instant - at least, there's no
>> external input.  For any process that's *nearly* instant, couldn't
>> it actually be instant?  In other words, 1 tick of the processor?  Load 
>> up
>> all the registers with the necessary values, and shine the light down 
>> those
>> transistors/logic gates, so that we arrive at our result, instantly?
>>
>> I really feel like this is possible.  Like I mentioned earlier, I've
>> never compiled a lick of code in my life, and have very little
>> understanding of those things.  But from my sense of JavaScript, it's far
>> from instant.  How many processor ticks per line of JavaScript code, on
>> average?
>>
>>
>>
>>
>> Is anyone still listening?
>>
>> On Tue, Nov 7, 2017 at 8:47 AM, Michael Lewis  wrote:
>>
>>> I'm not experienced in async/await enough to know what "using async
>>> 

Re: Question of the Day: What about all this asynchrony?

[Michael Lewis]

> async functions create a new promise for you upon every invocation, which
you resolve via `await`, but that's all invisible in the background

Is that correct?  I thought async functions simply await promises.  `await
something()` works because something() returns a promise.  But is there a
promise created "invisibly" every time you invoke an async function?

On Tue, Nov 7, 2017 at 2:13 PM, Naveen Chawla  wrote:

> Correct, `for..of` instead of `forEach`
>
> On Wed, 8 Nov 2017 at 01:21 Logan Smyth  wrote:
>
>> A nit, but that would have to be `for (const move of moves) await 
>> doMoveAsync()`
>> since the `forEach` callback is a normal function.
>>
>> On Tue, Nov 7, 2017 at 11:47 AM, Naveen Chawla 
>> wrote:
>>
>>> ... that should be `await doMoveAsync()`
>>>
>>> On Wed, 8 Nov 2017 at 01:16 Naveen Chawla  wrote:
>>>
 async functions create a new promise for you upon every invocation,
 which you resolve via `await`, but that's all invisible in the background.
 It's basically:

 async function doMovesAsync(){
 moves.forEach(
  move=>{
   doMoveAsync(); //another async function
  }
 );
 }

 ...so you can do regular programming, in async world. This is why I
 believe it's more powerful than observables, thereby making them redundant.

 When I say branching into multiple outputs, I do mean creating new data
 that leaves the original data untouched.

 On Tue, 7 Nov 2017 at 20:57 Michael Lewis  wrote:

> Also, if you've made it this far, I think it's worth mentioning that
> these async strings are basically all you need for a realtime file system.
>
> File("newFile.ext").append(File("fileA"), File("fileB"),
> ...).transpile().save();
> // --> automatically watches, all inputs (fileA, fileB, etc), caches
> unchanged files, reapplies transforms, writes to file...
>
> Webpack and gulp are basically async plugin systems w/ transforms.
> They're just way too complicated.
>
> Simplify all the things.
>
> And while we're at it, why not make a realtime version control
> system?  Not just for files, but for all the things (any data structure
> inside the app).  For example, if we have variable strings, could we 
> enable
> a history on it?  Instead of branching onto a separate entity/value, could
> we branch *within *the string itself, so that we have an entire *verrsion
> tree *for any value?
>
> *What are the fundamental data structures in computer science?*
> The Boolean, obviously.  The Integer.  The String.
>
> Why not a realtime boolean?  I suppose that's just a boolean + change
> events.  What is a "change event"?  Just an array of functions.  But
> JavaScript functions are an abstract concept (compared to processor
> instructions).  What do functions look like at the processor level?
> They're compiled with all the dependent values, right?  How many processor
> ticks does the average line of JavaScript use?
>
> I feel like all languages could boil down to a very small set of
> fundamental data structures, and maybe a slightly larger set of 
> specialized
> data structures.
>
> What are the different types of circuits in a process?  I understand
> (roughly) the basic logic gates, but is there specialized circuitry for
> specialized data structures?  What if those fundamental data structures
> were optimized at the circuitry level?
>
> What if we can optimize our programs to run as nearly instantly as
> possible?  Most scripts are *mostly *instant - at least, there's no
> external input.  For any process that's *nearly* instant, couldn't it
> actually be instant?  In other words, 1 tick of the processor?  Load up 
> all
> the registers with the necessary values, and shine the light down those
> transistors/logic gates, so that we arrive at our result, instantly?
>
> I really feel like this is possible.  Like I mentioned earlier, I've
> never compiled a lick of code in my life, and have very little
> understanding of those things.  But from my sense of JavaScript, it's far
> from instant.  How many processor ticks per line of JavaScript code, on
> average?
>
>
>
>
> Is anyone still listening?
>
> On Tue, Nov 7, 2017 at 8:47 AM, Michael Lewis  wrote:
>
>> I'm not experienced in async/await enough to know what "using async
>> functions to process [streams]" would look like.
>>
>> You would have to create a new promise for every iteration?  Even if
>> performance isn't an issue, it just doesn't make sense to me.  It's like,
>> you could use `obj.value = "my string"` instead of `var myString = "my
>> string"`, 

Re: Question of the Day: What about all this asynchrony?

[Naveen Chawla]

Correct, `for..of` instead of `forEach`

On Wed, 8 Nov 2017 at 01:21 Logan Smyth  wrote:

> A nit, but that would have to be `for (const move of moves) await 
> doMoveAsync()`
> since the `forEach` callback is a normal function.
>
> On Tue, Nov 7, 2017 at 11:47 AM, Naveen Chawla 
> wrote:
>
>> ... that should be `await doMoveAsync()`
>>
>> On Wed, 8 Nov 2017 at 01:16 Naveen Chawla  wrote:
>>
>>> async functions create a new promise for you upon every invocation,
>>> which you resolve via `await`, but that's all invisible in the background.
>>> It's basically:
>>>
>>> async function doMovesAsync(){
>>> moves.forEach(
>>>  move=>{
>>>   doMoveAsync(); //another async function
>>>  }
>>> );
>>> }
>>>
>>> ...so you can do regular programming, in async world. This is why I
>>> believe it's more powerful than observables, thereby making them redundant.
>>>
>>> When I say branching into multiple outputs, I do mean creating new data
>>> that leaves the original data untouched.
>>>
>>> On Tue, 7 Nov 2017 at 20:57 Michael Lewis  wrote:
>>>
 Also, if you've made it this far, I think it's worth mentioning that
 these async strings are basically all you need for a realtime file system.

 File("newFile.ext").append(File("fileA"), File("fileB"),
 ...).transpile().save();
 // --> automatically watches, all inputs (fileA, fileB, etc), caches
 unchanged files, reapplies transforms, writes to file...

 Webpack and gulp are basically async plugin systems w/ transforms.
 They're just way too complicated.

 Simplify all the things.

 And while we're at it, why not make a realtime version control system?
 Not just for files, but for all the things (any data structure inside the
 app).  For example, if we have variable strings, could we enable a history
 on it?  Instead of branching onto a separate entity/value, could we branch 
 *within
 *the string itself, so that we have an entire *verrsion tree *for any
 value?

 *What are the fundamental data structures in computer science?*
 The Boolean, obviously.  The Integer.  The String.

 Why not a realtime boolean?  I suppose that's just a boolean + change
 events.  What is a "change event"?  Just an array of functions.  But
 JavaScript functions are an abstract concept (compared to processor
 instructions).  What do functions look like at the processor level?
 They're compiled with all the dependent values, right?  How many processor
 ticks does the average line of JavaScript use?

 I feel like all languages could boil down to a very small set of
 fundamental data structures, and maybe a slightly larger set of specialized
 data structures.

 What are the different types of circuits in a process?  I understand
 (roughly) the basic logic gates, but is there specialized circuitry for
 specialized data structures?  What if those fundamental data structures
 were optimized at the circuitry level?

 What if we can optimize our programs to run as nearly instantly as
 possible?  Most scripts are *mostly *instant - at least, there's no
 external input.  For any process that's *nearly* instant, couldn't it
 actually be instant?  In other words, 1 tick of the processor?  Load up all
 the registers with the necessary values, and shine the light down those
 transistors/logic gates, so that we arrive at our result, instantly?

 I really feel like this is possible.  Like I mentioned earlier, I've
 never compiled a lick of code in my life, and have very little
 understanding of those things.  But from my sense of JavaScript, it's far
 from instant.  How many processor ticks per line of JavaScript code, on
 average?




 Is anyone still listening?

 On Tue, Nov 7, 2017 at 8:47 AM, Michael Lewis  wrote:

> I'm not experienced in async/await enough to know what "using async
> functions to process [streams]" would look like.
>
> You would have to create a new promise for every iteration?  Even if
> performance isn't an issue, it just doesn't make sense to me.  It's like,
> you could use `obj.value = "my string"` instead of `var myString = "my
> string"`, and it will work.  And the performance difference is negligible.
> But, it just doesn't make as much sense...
>
> *Branching vs Mutation*
> The point you bring up regarding "branching the stream into multiple
> outputs" is another fundamental concept in programming (that I'm still
> trying to wrap my head around).  Basically, does an operation (aka a
> method) operate on the original data, or fork/branch, preserving the
> original, and creating a clone to apply the transform to.
>
> For example, arr.push() 

Re: Question of the Day: What about all this asynchrony?

[Logan Smyth]

A nit, but that would have to be `for (const move of moves) await
doMoveAsync()`
since the `forEach` callback is a normal function.

On Tue, Nov 7, 2017 at 11:47 AM, Naveen Chawla 
wrote:

> ... that should be `await doMoveAsync()`
>
> On Wed, 8 Nov 2017 at 01:16 Naveen Chawla  wrote:
>
>> async functions create a new promise for you upon every invocation, which
>> you resolve via `await`, but that's all invisible in the background. It's
>> basically:
>>
>> async function doMovesAsync(){
>> moves.forEach(
>>  move=>{
>>   doMoveAsync(); //another async function
>>  }
>> );
>> }
>>
>> ...so you can do regular programming, in async world. This is why I
>> believe it's more powerful than observables, thereby making them redundant.
>>
>> When I say branching into multiple outputs, I do mean creating new data
>> that leaves the original data untouched.
>>
>> On Tue, 7 Nov 2017 at 20:57 Michael Lewis  wrote:
>>
>>> Also, if you've made it this far, I think it's worth mentioning that
>>> these async strings are basically all you need for a realtime file system.
>>>
>>> File("newFile.ext").append(File("fileA"), File("fileB"),
>>> ...).transpile().save();
>>> // --> automatically watches, all inputs (fileA, fileB, etc), caches
>>> unchanged files, reapplies transforms, writes to file...
>>>
>>> Webpack and gulp are basically async plugin systems w/ transforms.
>>> They're just way too complicated.
>>>
>>> Simplify all the things.
>>>
>>> And while we're at it, why not make a realtime version control system?
>>> Not just for files, but for all the things (any data structure inside the
>>> app).  For example, if we have variable strings, could we enable a history
>>> on it?  Instead of branching onto a separate entity/value, could we branch 
>>> *within
>>> *the string itself, so that we have an entire *verrsion tree *for any
>>> value?
>>>
>>> *What are the fundamental data structures in computer science?*
>>> The Boolean, obviously.  The Integer.  The String.
>>>
>>> Why not a realtime boolean?  I suppose that's just a boolean + change
>>> events.  What is a "change event"?  Just an array of functions.  But
>>> JavaScript functions are an abstract concept (compared to processor
>>> instructions).  What do functions look like at the processor level?
>>> They're compiled with all the dependent values, right?  How many processor
>>> ticks does the average line of JavaScript use?
>>>
>>> I feel like all languages could boil down to a very small set of
>>> fundamental data structures, and maybe a slightly larger set of specialized
>>> data structures.
>>>
>>> What are the different types of circuits in a process?  I understand
>>> (roughly) the basic logic gates, but is there specialized circuitry for
>>> specialized data structures?  What if those fundamental data structures
>>> were optimized at the circuitry level?
>>>
>>> What if we can optimize our programs to run as nearly instantly as
>>> possible?  Most scripts are *mostly *instant - at least, there's no
>>> external input.  For any process that's *nearly* instant, couldn't it
>>> actually be instant?  In other words, 1 tick of the processor?  Load up all
>>> the registers with the necessary values, and shine the light down those
>>> transistors/logic gates, so that we arrive at our result, instantly?
>>>
>>> I really feel like this is possible.  Like I mentioned earlier, I've
>>> never compiled a lick of code in my life, and have very little
>>> understanding of those things.  But from my sense of JavaScript, it's far
>>> from instant.  How many processor ticks per line of JavaScript code, on
>>> average?
>>>
>>>
>>>
>>>
>>> Is anyone still listening?
>>>
>>> On Tue, Nov 7, 2017 at 8:47 AM, Michael Lewis  wrote:
>>>
 I'm not experienced in async/await enough to know what "using async
 functions to process [streams]" would look like.

 You would have to create a new promise for every iteration?  Even if
 performance isn't an issue, it just doesn't make sense to me.  It's like,
 you could use `obj.value = "my string"` instead of `var myString = "my
 string"`, and it will work.  And the performance difference is negligible.
 But, it just doesn't make as much sense...

 *Branching vs Mutation*
 The point you bring up regarding "branching the stream into multiple
 outputs" is another fundamental concept in programming (that I'm still
 trying to wrap my head around).  Basically, does an operation (aka a
 method) operate on the original data, or fork/branch, preserving the
 original, and creating a clone to apply the transform to.

 For example, arr.push() manipulates (mutates) the original array, but
 arr.slice() branches, giving you a brand new array, leaving the underlying
 array untouched (immutable).

 This has always been an area of confusion for me.  Which methods 

Re: Question of the Day: What about all this asynchrony?

[Naveen Chawla]

... that should be `await doMoveAsync()`

On Wed, 8 Nov 2017 at 01:16 Naveen Chawla  wrote:

> async functions create a new promise for you upon every invocation, which
> you resolve via `await`, but that's all invisible in the background. It's
> basically:
>
> async function doMovesAsync(){
> moves.forEach(
>  move=>{
>   doMoveAsync(); //another async function
>  }
> );
> }
>
> ...so you can do regular programming, in async world. This is why I
> believe it's more powerful than observables, thereby making them redundant.
>
> When I say branching into multiple outputs, I do mean creating new data
> that leaves the original data untouched.
>
> On Tue, 7 Nov 2017 at 20:57 Michael Lewis  wrote:
>
>> Also, if you've made it this far, I think it's worth mentioning that
>> these async strings are basically all you need for a realtime file system.
>>
>> File("newFile.ext").append(File("fileA"), File("fileB"),
>> ...).transpile().save();
>> // --> automatically watches, all inputs (fileA, fileB, etc), caches
>> unchanged files, reapplies transforms, writes to file...
>>
>> Webpack and gulp are basically async plugin systems w/ transforms.
>> They're just way too complicated.
>>
>> Simplify all the things.
>>
>> And while we're at it, why not make a realtime version control system?
>> Not just for files, but for all the things (any data structure inside the
>> app).  For example, if we have variable strings, could we enable a history
>> on it?  Instead of branching onto a separate entity/value, could we branch 
>> *within
>> *the string itself, so that we have an entire *verrsion tree *for any
>> value?
>>
>> *What are the fundamental data structures in computer science?*
>> The Boolean, obviously.  The Integer.  The String.
>>
>> Why not a realtime boolean?  I suppose that's just a boolean + change
>> events.  What is a "change event"?  Just an array of functions.  But
>> JavaScript functions are an abstract concept (compared to processor
>> instructions).  What do functions look like at the processor level?
>> They're compiled with all the dependent values, right?  How many processor
>> ticks does the average line of JavaScript use?
>>
>> I feel like all languages could boil down to a very small set of
>> fundamental data structures, and maybe a slightly larger set of specialized
>> data structures.
>>
>> What are the different types of circuits in a process?  I understand
>> (roughly) the basic logic gates, but is there specialized circuitry for
>> specialized data structures?  What if those fundamental data structures
>> were optimized at the circuitry level?
>>
>> What if we can optimize our programs to run as nearly instantly as
>> possible?  Most scripts are *mostly *instant - at least, there's no
>> external input.  For any process that's *nearly* instant, couldn't it
>> actually be instant?  In other words, 1 tick of the processor?  Load up all
>> the registers with the necessary values, and shine the light down those
>> transistors/logic gates, so that we arrive at our result, instantly?
>>
>> I really feel like this is possible.  Like I mentioned earlier, I've
>> never compiled a lick of code in my life, and have very little
>> understanding of those things.  But from my sense of JavaScript, it's far
>> from instant.  How many processor ticks per line of JavaScript code, on
>> average?
>>
>>
>>
>>
>> Is anyone still listening?
>>
>> On Tue, Nov 7, 2017 at 8:47 AM, Michael Lewis  wrote:
>>
>>> I'm not experienced in async/await enough to know what "using async
>>> functions to process [streams]" would look like.
>>>
>>> You would have to create a new promise for every iteration?  Even if
>>> performance isn't an issue, it just doesn't make sense to me.  It's like,
>>> you could use `obj.value = "my string"` instead of `var myString = "my
>>> string"`, and it will work.  And the performance difference is negligible.
>>> But, it just doesn't make as much sense...
>>>
>>> *Branching vs Mutation*
>>> The point you bring up regarding "branching the stream into multiple
>>> outputs" is another fundamental concept in programming (that I'm still
>>> trying to wrap my head around).  Basically, does an operation (aka a
>>> method) operate on the original data, or fork/branch, preserving the
>>> original, and creating a clone to apply the transform to.
>>>
>>> For example, arr.push() manipulates (mutates) the original array, but
>>> arr.slice() branches, giving you a brand new array, leaving the underlying
>>> array untouched (immutable).
>>>
>>> This has always been an area of confusion for me.  Which methods are
>>> mutators, and which are immutable?
>>>
>>> *Async Strings*
>>> An interesting away to look at all this async stuff, is to consider
>>> strings, and their operations (methods), in an asynchronous way.  How can a
>>> string be asynchronous?  Just let it change over time, and broadcast change
>>> events.
>>>
>>> 

Re: Question of the Day: What about all this asynchrony?

[Naveen Chawla]

async functions create a new promise for you upon every invocation, which
you resolve via `await`, but that's all invisible in the background. It's
basically:

async function doMovesAsync(){
moves.forEach(
 move=>{
  doMoveAsync(); //another async function
 }
);
}

...so you can do regular programming, in async world. This is why I believe
it's more powerful than observables, thereby making them redundant.

When I say branching into multiple outputs, I do mean creating new data
that leaves the original data untouched.

On Tue, 7 Nov 2017 at 20:57 Michael Lewis  wrote:

> Also, if you've made it this far, I think it's worth mentioning that these
> async strings are basically all you need for a realtime file system.
>
> File("newFile.ext").append(File("fileA"), File("fileB"),
> ...).transpile().save();
> // --> automatically watches, all inputs (fileA, fileB, etc), caches
> unchanged files, reapplies transforms, writes to file...
>
> Webpack and gulp are basically async plugin systems w/ transforms.
> They're just way too complicated.
>
> Simplify all the things.
>
> And while we're at it, why not make a realtime version control system?
> Not just for files, but for all the things (any data structure inside the
> app).  For example, if we have variable strings, could we enable a history
> on it?  Instead of branching onto a separate entity/value, could we branch 
> *within
> *the string itself, so that we have an entire *verrsion tree *for any
> value?
>
> *What are the fundamental data structures in computer science?*
> The Boolean, obviously.  The Integer.  The String.
>
> Why not a realtime boolean?  I suppose that's just a boolean + change
> events.  What is a "change event"?  Just an array of functions.  But
> JavaScript functions are an abstract concept (compared to processor
> instructions).  What do functions look like at the processor level?
> They're compiled with all the dependent values, right?  How many processor
> ticks does the average line of JavaScript use?
>
> I feel like all languages could boil down to a very small set of
> fundamental data structures, and maybe a slightly larger set of specialized
> data structures.
>
> What are the different types of circuits in a process?  I understand
> (roughly) the basic logic gates, but is there specialized circuitry for
> specialized data structures?  What if those fundamental data structures
> were optimized at the circuitry level?
>
> What if we can optimize our programs to run as nearly instantly as
> possible?  Most scripts are *mostly *instant - at least, there's no
> external input.  For any process that's *nearly* instant, couldn't it
> actually be instant?  In other words, 1 tick of the processor?  Load up all
> the registers with the necessary values, and shine the light down those
> transistors/logic gates, so that we arrive at our result, instantly?
>
> I really feel like this is possible.  Like I mentioned earlier, I've never
> compiled a lick of code in my life, and have very little understanding of
> those things.  But from my sense of JavaScript, it's far from instant.  How
> many processor ticks per line of JavaScript code, on average?
>
>
>
>
> Is anyone still listening?
>
> On Tue, Nov 7, 2017 at 8:47 AM, Michael Lewis  wrote:
>
>> I'm not experienced in async/await enough to know what "using async
>> functions to process [streams]" would look like.
>>
>> You would have to create a new promise for every iteration?  Even if
>> performance isn't an issue, it just doesn't make sense to me.  It's like,
>> you could use `obj.value = "my string"` instead of `var myString = "my
>> string"`, and it will work.  And the performance difference is negligible.
>> But, it just doesn't make as much sense...
>>
>> *Branching vs Mutation*
>> The point you bring up regarding "branching the stream into multiple
>> outputs" is another fundamental concept in programming (that I'm still
>> trying to wrap my head around).  Basically, does an operation (aka a
>> method) operate on the original data, or fork/branch, preserving the
>> original, and creating a clone to apply the transform to.
>>
>> For example, arr.push() manipulates (mutates) the original array, but
>> arr.slice() branches, giving you a brand new array, leaving the underlying
>> array untouched (immutable).
>>
>> This has always been an area of confusion for me.  Which methods are
>> mutators, and which are immutable?
>>
>> *Async Strings*
>> An interesting away to look at all this async stuff, is to consider
>> strings, and their operations (methods), in an asynchronous way.  How can a
>> string be asynchronous?  Just let it change over time, and broadcast change
>> events.
>>
>> What if you compose a string with several pieces:
>>  asyncParentStr.append(asyncStrA, asyncStrB, asyncStrC).
>>
>> Each asyncString can have change events, and will propagate changes to
>> anyone depending on it.   asyncStrB.set("new value") 

Re: Question of the Day: What about all this asynchrony?

[Michael Lewis]

Also, if you've made it this far, I think it's worth mentioning that these
async strings are basically all you need for a realtime file system.

File("newFile.ext").append(File("fileA"), File("fileB"),
...).transpile().save();
// --> automatically watches, all inputs (fileA, fileB, etc), caches
unchanged files, reapplies transforms, writes to file...

Webpack and gulp are basically async plugin systems w/ transforms.  They're
just way too complicated.

Simplify all the things.

And while we're at it, why not make a realtime version control system?  Not
just for files, but for all the things (any data structure inside the
app).  For example, if we have variable strings, could we enable a history
on it?  Instead of branching onto a separate entity/value, could we
branch *within
*the string itself, so that we have an entire *verrsion tree *for any value?

*What are the fundamental data structures in computer science?*
The Boolean, obviously.  The Integer.  The String.

Why not a realtime boolean?  I suppose that's just a boolean + change
events.  What is a "change event"?  Just an array of functions.  But
JavaScript functions are an abstract concept (compared to processor
instructions).  What do functions look like at the processor level?
They're compiled with all the dependent values, right?  How many processor
ticks does the average line of JavaScript use?

I feel like all languages could boil down to a very small set of
fundamental data structures, and maybe a slightly larger set of specialized
data structures.

What are the different types of circuits in a process?  I understand
(roughly) the basic logic gates, but is there specialized circuitry for
specialized data structures?  What if those fundamental data structures
were optimized at the circuitry level?

What if we can optimize our programs to run as nearly instantly as
possible?  Most scripts are *mostly *instant - at least, there's no
external input.  For any process that's *nearly* instant, couldn't it
actually be instant?  In other words, 1 tick of the processor?  Load up all
the registers with the necessary values, and shine the light down those
transistors/logic gates, so that we arrive at our result, instantly?

I really feel like this is possible.  Like I mentioned earlier, I've never
compiled a lick of code in my life, and have very little understanding of
those things.  But from my sense of JavaScript, it's far from instant.  How
many processor ticks per line of JavaScript code, on average?




Is anyone still listening?

On Tue, Nov 7, 2017 at 8:47 AM, Michael Lewis  wrote:

> I'm not experienced in async/await enough to know what "using async
> functions to process [streams]" would look like.
>
> You would have to create a new promise for every iteration?  Even if
> performance isn't an issue, it just doesn't make sense to me.  It's like,
> you could use `obj.value = "my string"` instead of `var myString = "my
> string"`, and it will work.  And the performance difference is negligible.
> But, it just doesn't make as much sense...
>
> *Branching vs Mutation*
> The point you bring up regarding "branching the stream into multiple
> outputs" is another fundamental concept in programming (that I'm still
> trying to wrap my head around).  Basically, does an operation (aka a
> method) operate on the original data, or fork/branch, preserving the
> original, and creating a clone to apply the transform to.
>
> For example, arr.push() manipulates (mutates) the original array, but
> arr.slice() branches, giving you a brand new array, leaving the underlying
> array untouched (immutable).
>
> This has always been an area of confusion for me.  Which methods are
> mutators, and which are immutable?
>
> *Async Strings*
> An interesting away to look at all this async stuff, is to consider
> strings, and their operations (methods), in an asynchronous way.  How can a
> string be asynchronous?  Just let it change over time, and broadcast change
> events.
>
> What if you compose a string with several pieces:  
> asyncParentStr.append(asyncStrA,
> asyncStrB, asyncStrC).
>
> Each asyncString can have change events, and will propagate changes to
> anyone depending on it.   asyncStrB.set("new value") will trigger
> asyncParentStr.change() event.
>
> I feel like this is fundamental functionality that is lacking from
> JavaScript.  Now that we have `const`, shouldn't `var` automatically set up
> change events for that "var"?
>
> *Async transforms*
> But lets say we do asyncParentStr.append(asyncStrA,
> asyncStrB.replace("hello", "goodbye"), asyncStrC).
>
> Now we have the question: do we want this .replace() to be a "live"
> transform?  When we asyncStrB.set("hello world"), does it re-apply the
> replace?  I think there are many use cases for both: mutate the original
> asyncStrB, so that all references to this value also exhibit the
> transform.  And also the alternative, the immutable, branching kind of
> transform, where you don't mutate the 

Re: Question of the Day: What about all this asynchrony?

[Michael Lewis]

I'm not experienced in async/await enough to know what "using async
functions to process [streams]" would look like.

You would have to create a new promise for every iteration?  Even if
performance isn't an issue, it just doesn't make sense to me.  It's like,
you could use `obj.value = "my string"` instead of `var myString = "my
string"`, and it will work.  And the performance difference is negligible.
But, it just doesn't make as much sense...

*Branching vs Mutation*
The point you bring up regarding "branching the stream into multiple
outputs" is another fundamental concept in programming (that I'm still
trying to wrap my head around).  Basically, does an operation (aka a
method) operate on the original data, or fork/branch, preserving the
original, and creating a clone to apply the transform to.

For example, arr.push() manipulates (mutates) the original array, but
arr.slice() branches, giving you a brand new array, leaving the underlying
array untouched (immutable).

This has always been an area of confusion for me.  Which methods are
mutators, and which are immutable?

*Async Strings*
An interesting away to look at all this async stuff, is to consider
strings, and their operations (methods), in an asynchronous way.  How can a
string be asynchronous?  Just let it change over time, and broadcast change
events.

What if you compose a string with several pieces:
 asyncParentStr.append(asyncStrA, asyncStrB, asyncStrC).

Each asyncString can have change events, and will propagate changes to
anyone depending on it.   asyncStrB.set("new value") will trigger
asyncParentStr.change() event.

I feel like this is fundamental functionality that is lacking from
JavaScript.  Now that we have `const`, shouldn't `var` automatically set up
change events for that "var"?

*Async transforms*
But lets say we do asyncParentStr.append(asyncStrA,
asyncStrB.replace("hello", "goodbye"), asyncStrC).

Now we have the question: do we want this .replace() to be a "live"
transform?  When we asyncStrB.set("hello world"), does it re-apply the
replace?  I think there are many use cases for both: mutate the original
asyncStrB, so that all references to this value also exhibit the
transform.  And also the alternative, the immutable, branching kind of
transform, where you don't mutate the underlying value, and instead are
branching.

This concept is also the core concept of version control: do we continue
down the same path, or branch off?

*GUIs will prevail*
You can try and create different methods ( ._replace() vs .$replace() ) to
represent transform vs branching (I don't know which looks more like
which).  But, in the end, the GUI will prevail.  Artists can dream about
how to envision these version trees, and perfect the GUI/experience.  The
code interface just can't compete with GUI, in the long run.

I suppose, its necessarily true that the API preceeds the GUI.

API before GUI, but GUI all the things.  That's my new motto.

*What if variables were automatically async, and referential? *(As opposed
to `const` that could be the immutable flavor)
var str = "hello world";

str.replace("hello", "goodbye"); // transforms `str` var "in place"
log(str) // "goodbye world"

str = "hello cruel world"; // transform is reapplied
log(str) // "goodbye cruel world"

This will never happen, but it shows the fundamental difference in logic.
Both are logical/useful...

On Tue, Nov 7, 2017 at 8:08 AM, Naveen Chawla  wrote:

> For me the future is async functions (the present actually). I asked a
> question about possible support for async streams / observables here:
> https://esdiscuss.org/topic/stream-async-await and I realized that my use
> case was much better served by just using async functions to process each
> input value in the stream.
>
> I think using async functions is much more powerful than "observables",
> since it allows you to easily branch the stream off into multiple outputs
> etc. Using Promise.all etc. is also trivial to use where desired, etc.
>
> Furthermore, async functions allow while/for loops that include other
> async function calls, and this looks like programming with regular
> functions, so it's trivial to set up asynchronous iteration, and/or
> infinite event processing, etc., even without the new "async iteration"
> proposal.
>
> On Tue, 7 Nov 2017 at 17:25 Michael Lewis  wrote:
>
>> The email wasn't about my kids, and you don't have to read it (duh).  If
>> your time is so valuable, maybe you shouldn't be picking fights with
>> rambling parents.
>>
>> Where is the list of approved topics?
>>
>> On Tue, Nov 7, 2017 at 5:44 AM, Bob Myers  wrote:
>>
>>> I'm confused. You don't have time to read "The General Theory of
>>> Reactivity", yet (1) you have time to write this long, rambling email about
>>> your kids, and (2) expect people on this mailing list to spend their
>>> valuable time reading it?
>>>
>>> Please stay on topic for the list.
>>>
>>> Bob
>>>
>>> On Tue, 

Re: Question of the Day: What about all this asynchrony?

[Naveen Chawla]

For me the future is async functions (the present actually). I asked a
question about possible support for async streams / observables here:
https://esdiscuss.org/topic/stream-async-await and I realized that my use
case was much better served by just using async functions to process each
input value in the stream.

I think using async functions is much more powerful than "observables",
since it allows you to easily branch the stream off into multiple outputs
etc. Using Promise.all etc. is also trivial to use where desired, etc.

Furthermore, async functions allow while/for loops that include other async
function calls, and this looks like programming with regular functions, so
it's trivial to set up asynchronous iteration, and/or infinite event
processing, etc., even without the new "async iteration" proposal.

On Tue, 7 Nov 2017 at 17:25 Michael Lewis  wrote:

> The email wasn't about my kids, and you don't have to read it (duh).  If
> your time is so valuable, maybe you shouldn't be picking fights with
> rambling parents.
>
> Where is the list of approved topics?
>
> On Tue, Nov 7, 2017 at 5:44 AM, Bob Myers  wrote:
>
>> I'm confused. You don't have time to read "The General Theory of
>> Reactivity", yet (1) you have time to write this long, rambling email about
>> your kids, and (2) expect people on this mailing list to spend their
>> valuable time reading it?
>>
>> Please stay on topic for the list.
>>
>> Bob
>>
>> On Tue, Nov 7, 2017 at 4:48 PM, Michael Lewis  wrote:
>>
>>> Good morning JavaScript world,
>>>
>>> Maybe I'll start my mornings with a cup of coffee, and a discussion
>>> prompt.  We'll see how long it lasts.  It's 4:39am.  I live in Aurora,
>>> Illinois, about an hour outside of Chicago.  My kids will wake up in an
>>> hour or two, so I don't have long, and should be working on my framework
>>> anyway.
>>>
>>> *So much asynchrony*
>>> There are callbacks, promises, async/await.  We have streams in
>>> node.js.  There are libraries like RxJS for Observables (that are basically
>>> streams?).
>>>
>>> What's the end game?  What will our children's children be learning in
>>> 100 years?  Let's reduce these pieces, distilling them into their simplest
>>> components.
>>>
>>> This  is an
>>> interesting thread (from es-discuss) regarding asynchrony, which references
>>> Kris Kowal's General Theory of Reactivity
>>> , which is too long for me to dig
>>> into at this point in my life.
>>>
>>> The disappointing part, is that this community (who has mastered
>>> asynchrony) doesn't feel like there are any shortcomings, and so we
>>> continue onward without fixing the mess.
>>>
>>> Oh, and generators?  I don't fully understand these things.  Do they
>>> work with promises?  Can you use a generator to process a stream?  How do
>>> generators work with or compare to async/await?  Who knows...
>>>
>>> I think it's safe to say that asynchrony is a confusing mess.  *But it
>>> shouldn't be.   *The concept of "do it now" or "do it later" is as easy
>>> as 123.
>>>
>>> Recently, I read through Jake Archibald's JavaScript Promises: an
>>> Introduction
>>> .  I
>>> really enjoy Jake Archibald's writing.  He makes JavaScript less boring.
>>> But wow, understanding promises in their full depth is really complicated.
>>> Sure, a simple promise is more or less a callback, easy peasy.  But once
>>> you start composing parallel and series tasks, add error handling, and try
>>> to understand the control flow - it's a lot.
>>>
>>> I feel like Promises could automatically *render a diagram *when using
>>> them.  In Jake's very practical example (request a list of chapters, load
>>> all chapters in parallel, then append them to the page in order) there's a
>>> lot going on, to say the least.  Wouldn't it be nice to see a diagram of
>>> these tasks?  A timeline maybe?
>>>
>>> Imagine debugging a complex sequence of async actions.  And you have no
>>> idea which piece is failing.  Using the console to log values, and trying
>>> to step through the code with the debugger are two of your basic
>>> approaches.  But honestly, neither of these really *show *you what's
>>> going on.
>>>
>>> Chrome Dev Tools has an awesome timeline GUI.  I've spent an hour here
>>> or there tinkering with it, but can't make sense of a lot of it.  There are
>>> 100's if not 1000's of very generic blocks that show up on the timeline,
>>> that don't clearly identify what they are.  And I don't believe there's any
>>> way to visualize promises on this timeline.
>>>
>>> *The problem with Promises*
>>> I want to create a file system framework for node.  I'd like to make
>>> watching the files for changes a default feature.  The problem with
>>> promises, is that you can't re-resolve them.
>>>
>>> So I'm basically left with streams, or plain old callbacks.  

Re: Question of the Day: What about all this asynchrony?

[Michael Lewis]

The email wasn't about my kids, and you don't have to read it (duh).  If
your time is so valuable, maybe you shouldn't be picking fights with
rambling parents.

Where is the list of approved topics?

On Tue, Nov 7, 2017 at 5:44 AM, Bob Myers  wrote:

> I'm confused. You don't have time to read "The General Theory of
> Reactivity", yet (1) you have time to write this long, rambling email about
> your kids, and (2) expect people on this mailing list to spend their
> valuable time reading it?
>
> Please stay on topic for the list.
>
> Bob
>
> On Tue, Nov 7, 2017 at 4:48 PM, Michael Lewis  wrote:
>
>> Good morning JavaScript world,
>>
>> Maybe I'll start my mornings with a cup of coffee, and a discussion
>> prompt.  We'll see how long it lasts.  It's 4:39am.  I live in Aurora,
>> Illinois, about an hour outside of Chicago.  My kids will wake up in an
>> hour or two, so I don't have long, and should be working on my framework
>> anyway.
>>
>> *So much asynchrony*
>> There are callbacks, promises, async/await.  We have streams in node.js.
>> There are libraries like RxJS for Observables (that are basically streams?).
>>
>> What's the end game?  What will our children's children be learning in
>> 100 years?  Let's reduce these pieces, distilling them into their simplest
>> components.
>>
>> This  is an interesting
>> thread (from es-discuss) regarding asynchrony, which references Kris
>> Kowal's General Theory of Reactivity ,
>> which is too long for me to dig into at this point in my life.
>>
>> The disappointing part, is that this community (who has mastered
>> asynchrony) doesn't feel like there are any shortcomings, and so we
>> continue onward without fixing the mess.
>>
>> Oh, and generators?  I don't fully understand these things.  Do they work
>> with promises?  Can you use a generator to process a stream?  How do
>> generators work with or compare to async/await?  Who knows...
>>
>> I think it's safe to say that asynchrony is a confusing mess.  *But it
>> shouldn't be.   *The concept of "do it now" or "do it later" is as easy
>> as 123.
>>
>> Recently, I read through Jake Archibald's JavaScript Promises: an
>> Introduction
>> .  I
>> really enjoy Jake Archibald's writing.  He makes JavaScript less boring.
>> But wow, understanding promises in their full depth is really complicated.
>> Sure, a simple promise is more or less a callback, easy peasy.  But once
>> you start composing parallel and series tasks, add error handling, and try
>> to understand the control flow - it's a lot.
>>
>> I feel like Promises could automatically *render a diagram *when using
>> them.  In Jake's very practical example (request a list of chapters, load
>> all chapters in parallel, then append them to the page in order) there's a
>> lot going on, to say the least.  Wouldn't it be nice to see a diagram of
>> these tasks?  A timeline maybe?
>>
>> Imagine debugging a complex sequence of async actions.  And you have no
>> idea which piece is failing.  Using the console to log values, and trying
>> to step through the code with the debugger are two of your basic
>> approaches.  But honestly, neither of these really *show *you what's
>> going on.
>>
>> Chrome Dev Tools has an awesome timeline GUI.  I've spent an hour here or
>> there tinkering with it, but can't make sense of a lot of it.  There are
>> 100's if not 1000's of very generic blocks that show up on the timeline,
>> that don't clearly identify what they are.  And I don't believe there's any
>> way to visualize promises on this timeline.
>>
>> *The problem with Promises*
>> I want to create a file system framework for node.  I'd like to make
>> watching the files for changes a default feature.  The problem with
>> promises, is that you can't re-resolve them.
>>
>> So I'm basically left with streams, or plain old callbacks.  Or trying to
>> recreate the promises every time they resolve...
>>
>> What's the end game?  100 years from now?
>>
>> Frankly, this is the most important question.  I feel like if we take a
>> step back, and try to solve these problems for the long term, we'd be
>> better off.
>>
>> And so, it's 5:15.  Well done, Michael.  Well done.
>>
>> *The Future*
>> If anyone has made it this far, I'm going to tell you a quick summary of
>> my plan:
>>
>>1. make an ultra-simple web framework (almost done?)
>>2. use that framework to make a CMS to kill WordPress
>>3. turn that CMS into a web OS that does everything a real OS can do,
>>only better
>>4. turn that web OS into a real, bare metal OS
>>5. make lots of amazing (useful) software (like photoshop, blender,
>>after effects, CAD, etc)
>>
>> Software development is sluggish.  Most software is painful to use.
>> Windows, Photoshop/Illustrator, many websites...  Open source software
>> doesn't get the 

Re: Question of the Day: What about all this asynchrony?

[Bob Myers]

I'm confused. You don't have time to read "The General Theory of
Reactivity", yet (1) you have time to write this long, rambling email about
your kids, and (2) expect people on this mailing list to spend their
valuable time reading it?

Please stay on topic for the list.

Bob

On Tue, Nov 7, 2017 at 4:48 PM, Michael Lewis  wrote:

> Good morning JavaScript world,
>
> Maybe I'll start my mornings with a cup of coffee, and a discussion
> prompt.  We'll see how long it lasts.  It's 4:39am.  I live in Aurora,
> Illinois, about an hour outside of Chicago.  My kids will wake up in an
> hour or two, so I don't have long, and should be working on my framework
> anyway.
>
> *So much asynchrony*
> There are callbacks, promises, async/await.  We have streams in node.js.
> There are libraries like RxJS for Observables (that are basically streams?).
>
> What's the end game?  What will our children's children be learning in 100
> years?  Let's reduce these pieces, distilling them into their simplest
> components.
>
> This  is an interesting
> thread (from es-discuss) regarding asynchrony, which references Kris
> Kowal's General Theory of Reactivity ,
> which is too long for me to dig into at this point in my life.
>
> The disappointing part, is that this community (who has mastered
> asynchrony) doesn't feel like there are any shortcomings, and so we
> continue onward without fixing the mess.
>
> Oh, and generators?  I don't fully understand these things.  Do they work
> with promises?  Can you use a generator to process a stream?  How do
> generators work with or compare to async/await?  Who knows...
>
> I think it's safe to say that asynchrony is a confusing mess.  *But it
> shouldn't be.   *The concept of "do it now" or "do it later" is as easy
> as 123.
>
> Recently, I read through Jake Archibald's JavaScript Promises: an
> Introduction
> .  I
> really enjoy Jake Archibald's writing.  He makes JavaScript less boring.
> But wow, understanding promises in their full depth is really complicated.
> Sure, a simple promise is more or less a callback, easy peasy.  But once
> you start composing parallel and series tasks, add error handling, and try
> to understand the control flow - it's a lot.
>
> I feel like Promises could automatically *render a diagram *when using
> them.  In Jake's very practical example (request a list of chapters, load
> all chapters in parallel, then append them to the page in order) there's a
> lot going on, to say the least.  Wouldn't it be nice to see a diagram of
> these tasks?  A timeline maybe?
>
> Imagine debugging a complex sequence of async actions.  And you have no
> idea which piece is failing.  Using the console to log values, and trying
> to step through the code with the debugger are two of your basic
> approaches.  But honestly, neither of these really *show *you what's
> going on.
>
> Chrome Dev Tools has an awesome timeline GUI.  I've spent an hour here or
> there tinkering with it, but can't make sense of a lot of it.  There are
> 100's if not 1000's of very generic blocks that show up on the timeline,
> that don't clearly identify what they are.  And I don't believe there's any
> way to visualize promises on this timeline.
>
> *The problem with Promises*
> I want to create a file system framework for node.  I'd like to make
> watching the files for changes a default feature.  The problem with
> promises, is that you can't re-resolve them.
>
> So I'm basically left with streams, or plain old callbacks.  Or trying to
> recreate the promises every time they resolve...
>
> What's the end game?  100 years from now?
>
> Frankly, this is the most important question.  I feel like if we take a
> step back, and try to solve these problems for the long term, we'd be
> better off.
>
> And so, it's 5:15.  Well done, Michael.  Well done.
>
> *The Future*
> If anyone has made it this far, I'm going to tell you a quick summary of
> my plan:
>
>1. make an ultra-simple web framework (almost done?)
>2. use that framework to make a CMS to kill WordPress
>3. turn that CMS into a web OS that does everything a real OS can do,
>only better
>4. turn that web OS into a real, bare metal OS
>5. make lots of amazing (useful) software (like photoshop, blender,
>after effects, CAD, etc)
>
> Software development is sluggish.  Most software is painful to use.
> Windows, Photoshop/Illustrator, many websites...  Open source software
> doesn't get the funding/momentum it needs to really kill these proprietary
> alternatives.  We need to change that.  I'm going to change that.
>
> Stay tuned.
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list

Re: Question of the Day: What about all this asynchrony?

[Michael Lewis]

*Side note about loading/defining Modules *(somewhat related to asynchrony)
I've been writing a Module loader that's a hybrid between require.js and
webpack.  And in doing so, the obvious end-game solution for modules is a
*GUI*.  A GUI to help you scaffold the folders, files, import statements,
package.json, and even the `var thing = require("thing")` statements.
Click a [ + ] button in the folder where I want my module, and browse
through a list of available modules to require, or go browse external
package managers to find additional modules.

This is sort of that AST stuff I was talking about over the weekend.
Instead of typing all this info into the file, it should be encoded.  So
webpack doesn't have to scan through and find your require statements, and
parse them.

Just one small piece of the big picture...  GUI all the things for the
ultimate developer experience!

On Tue, Nov 7, 2017 at 5:18 AM, Michael Lewis  wrote:

> Good morning JavaScript world,
>
> Maybe I'll start my mornings with a cup of coffee, and a discussion
> prompt.  We'll see how long it lasts.  It's 4:39am.  I live in Aurora,
> Illinois, about an hour outside of Chicago.  My kids will wake up in an
> hour or two, so I don't have long, and should be working on my framework
> anyway.
>
> *So much asynchrony*
> There are callbacks, promises, async/await.  We have streams in node.js.
> There are libraries like RxJS for Observables (that are basically streams?).
>
> What's the end game?  What will our children's children be learning in 100
> years?  Let's reduce these pieces, distilling them into their simplest
> components.
>
> This  is an interesting
> thread (from es-discuss) regarding asynchrony, which references Kris
> Kowal's General Theory of Reactivity ,
> which is too long for me to dig into at this point in my life.
>
> The disappointing part, is that this community (who has mastered
> asynchrony) doesn't feel like there are any shortcomings, and so we
> continue onward without fixing the mess.
>
> Oh, and generators?  I don't fully understand these things.  Do they work
> with promises?  Can you use a generator to process a stream?  How do
> generators work with or compare to async/await?  Who knows...
>
> I think it's safe to say that asynchrony is a confusing mess.  *But it
> shouldn't be.   *The concept of "do it now" or "do it later" is as easy
> as 123.
>
> Recently, I read through Jake Archibald's JavaScript Promises: an
> Introduction
> .  I
> really enjoy Jake Archibald's writing.  He makes JavaScript less boring.
> But wow, understanding promises in their full depth is really complicated.
> Sure, a simple promise is more or less a callback, easy peasy.  But once
> you start composing parallel and series tasks, add error handling, and try
> to understand the control flow - it's a lot.
>
> I feel like Promises could automatically *render a diagram *when using
> them.  In Jake's very practical example (request a list of chapters, load
> all chapters in parallel, then append them to the page in order) there's a
> lot going on, to say the least.  Wouldn't it be nice to see a diagram of
> these tasks?  A timeline maybe?
>
> Imagine debugging a complex sequence of async actions.  And you have no
> idea which piece is failing.  Using the console to log values, and trying
> to step through the code with the debugger are two of your basic
> approaches.  But honestly, neither of these really *show *you what's
> going on.
>
> Chrome Dev Tools has an awesome timeline GUI.  I've spent an hour here or
> there tinkering with it, but can't make sense of a lot of it.  There are
> 100's if not 1000's of very generic blocks that show up on the timeline,
> that don't clearly identify what they are.  And I don't believe there's any
> way to visualize promises on this timeline.
>
> *The problem with Promises*
> I want to create a file system framework for node.  I'd like to make
> watching the files for changes a default feature.  The problem with
> promises, is that you can't re-resolve them.
>
> So I'm basically left with streams, or plain old callbacks.  Or trying to
> recreate the promises every time they resolve...
>
> What's the end game?  100 years from now?
>
> Frankly, this is the most important question.  I feel like if we take a
> step back, and try to solve these problems for the long term, we'd be
> better off.
>
> And so, it's 5:15.  Well done, Michael.  Well done.
>
> *The Future*
> If anyone has made it this far, I'm going to tell you a quick summary of
> my plan:
>
>1. make an ultra-simple web framework (almost done?)
>2. use that framework to make a CMS to kill WordPress
>3. turn that CMS into a web OS that does everything a real OS can do,
>only better
>4. turn that web OS into a real, bare metal OS
>5. make lots of amazing (useful)