Question of the Day: What about all this asynchrony?

classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Question of the Day: What about all this asynchrony?

Michael Lewis
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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Bob Myers
In reply to this post by Michael Lewis
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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <[hidden email]> 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 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> wrote:
... that should be `await doMoveAsync()`

On Wed, 8 Nov 2017 at 01:16 Naveen Chawla <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <[hidden email]> wrote:
... that should be `await doMoveAsync()`

On Wed, 8 Nov 2017 at 01:16 Naveen Chawla <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> wrote:
Correct, `for..of` instead of `forEach`

On Wed, 8 Nov 2017 at 01:21 Logan Smyth <[hidden email]> 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 <[hidden email]> wrote:
... that should be `await doMoveAsync()`

On Wed, 8 Nov 2017 at 01:16 Naveen Chawla <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <[hidden email]> wrote:
Correct, `for..of` instead of `forEach`

On Wed, 8 Nov 2017 at 01:21 Logan Smyth <[hidden email]> 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 <[hidden email]> wrote:
... that should be `await doMoveAsync()`

On Wed, 8 Nov 2017 at 01:16 Naveen Chawla <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss





_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Jeremy Martin
In reply to this post by Naveen Chawla
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 <[hidden email]> wrote:
Correct, `for..of` instead of `forEach`

On Wed, 8 Nov 2017 at 01:21 Logan Smyth <[hidden email]> 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 <[hidden email]> wrote:
... that should be `await doMoveAsync()`

On Wed, 8 Nov 2017 at 01:16 Naveen Chawla <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
Jeremy Martin
661.312.3853

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <[hidden email]> wrote:
Correct, `for..of` instead of `forEach`

On Wed, 8 Nov 2017 at 01:21 Logan Smyth <[hidden email]> 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 <[hidden email]> wrote:
... that should be `await doMoveAsync()`

On Wed, 8 Nov 2017 at 01:16 Naveen Chawla <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
Jeremy Martin
<a href="tel:(661)%20312-3853" value="+16613123853" target="_blank">661.312.3853



--
Jeremy Martin
661.312.3853

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Michael Lewis
In reply to this post by Jeremy Martin
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 <[hidden email]> 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 <[hidden email]> wrote:
Correct, `for..of` instead of `forEach`

On Wed, 8 Nov 2017 at 01:21 Logan Smyth <[hidden email]> 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 <[hidden email]> wrote:
... that should be `await doMoveAsync()`

On Wed, 8 Nov 2017 at 01:16 Naveen Chawla <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
Jeremy Martin
<a href="tel:(661)%20312-3853" value="+16613123853" target="_blank">661.312.3853

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Correct, `for..of` instead of `forEach`

On Wed, 8 Nov 2017 at 01:21 Logan Smyth <[hidden email]> 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 <[hidden email]> wrote:
... that should be `await doMoveAsync()`

On Wed, 8 Nov 2017 at 01:16 Naveen Chawla <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
Jeremy Martin
<a href="tel:(661)%20312-3853" value="+16613123853" target="_blank">661.312.3853

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
[ ]s

--

Felipe N. Moura
Web Developer, Google Developer ExpertFounder of BrazilJS and Nasc.

Website:  http://felipenmoura.com / http://nasc.io/ 
Twitter:    @felipenmoura
---------------------------------
Changing  the  world  is the least I expect from  myself!

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Correct, `for..of` instead of `forEach`

On Wed, 8 Nov 2017 at 01:21 Logan Smyth <[hidden email]> 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 <[hidden email]> wrote:
... that should be `await doMoveAsync()`

On Wed, 8 Nov 2017 at 01:16 Naveen Chawla <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
Jeremy Martin
<a href="tel:(661)%20312-3853" value="+16613123853" target="_blank">661.312.3853

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
[ ]s

--

Felipe N. Moura
Web Developer, Google Developer ExpertFounder of BrazilJS and Nasc.

Website:  http://felipenmoura.com / http://nasc.io/ 
Twitter:    @felipenmoura
---------------------------------
Changing  the  world  is the least I expect from  myself!


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Correct, `for..of` instead of `forEach`

On Wed, 8 Nov 2017 at 01:21 Logan Smyth <[hidden email]> 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 <[hidden email]> wrote:
... that should be `await doMoveAsync()`

On Wed, 8 Nov 2017 at 01:16 Naveen Chawla <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
Jeremy Martin
<a href="tel:(661)%20312-3853" value="+16613123853" target="_blank">661.312.3853

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
[ ]s

--

Felipe N. Moura
Web Developer, Google Developer ExpertFounder of BrazilJS and Nasc.

Website:  http://felipenmoura.com / http://nasc.io/ 
Twitter:    @felipenmoura
---------------------------------
Changing  the  world  is the least I expect from  myself!

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Correct, `for..of` instead of `forEach`

On Wed, 8 Nov 2017 at 01:21 Logan Smyth <[hidden email]> 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 <[hidden email]> wrote:
... that should be `await doMoveAsync()`

On Wed, 8 Nov 2017 at 01:16 Naveen Chawla <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
Jeremy Martin
<a href="tel:(661)%20312-3853" value="+16613123853" target="_blank">661.312.3853

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
[ ]s

--

Felipe N. Moura
Web Developer, Google Developer ExpertFounder of BrazilJS and Nasc.

Website:  http://felipenmoura.com / http://nasc.io/ 
Twitter:    @felipenmoura
---------------------------------
Changing  the  world  is the least I expect from  myself!

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
12