Question of the Day: What about all this asynchrony?

Naveen Chawla naveen.chwl at gmail.com
Tue Nov 7 19:47:38 UTC 2017


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

On Wed, 8 Nov 2017 at 01:16 Naveen Chawla <naveen.chwl at gmail.com> 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 <mike at lew42.com> 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 <mike at lew42.com> 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 <naveen.chwl at gmail.com>
>>> 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 <mike at lew42.com> 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 <rtm at gol.com> 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 <mike at lew42.com> 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 <https://esdiscuss.org/topic/promises-vs-streams> is an
>>>>>>> interesting thread (from es-discuss) regarding asynchrony, which references
>>>>>>> Kris Kowal's General Theory of Reactivity
>>>>>>> <https://github.com/kriskowal/gtor/>, 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
>>>>>>> <https://developers.google.com/web/fundamentals/primers/promises>.
>>>>>>> I really enjoy Jake Archibald's writing.  He makes JavaScript less boring.
>>>>>>> But wow, understanding promises in their full depth is really complicated.
>>>>>>> Sure, a simple promise is more or less a callback, easy peasy.  But once
>>>>>>> you start composing parallel and series tasks, add error handling, and try
>>>>>>> to understand the control flow - it's a lot.
>>>>>>>
>>>>>>> I feel like Promises could automatically *render a diagram *when
>>>>>>> using them.  In Jake's very practical example (request a list of chapters,
>>>>>>> load all chapters in parallel, then append them to the page in order)
>>>>>>> there's a lot going on, to say the least.  Wouldn't it be nice to see a
>>>>>>> diagram of these tasks?  A timeline maybe?
>>>>>>>
>>>>>>> Imagine debugging a complex sequence of async actions.  And you have
>>>>>>> no idea which piece is failing.  Using the console to log values, and
>>>>>>> trying to step through the code with the debugger are two of your basic
>>>>>>> approaches.  But honestly, neither of these really *show *you
>>>>>>> what's going on.
>>>>>>>
>>>>>>> Chrome Dev Tools has an awesome timeline GUI.  I've spent an hour
>>>>>>> here or there tinkering with it, but can't make sense of a lot of it.
>>>>>>> There are 100's if not 1000's of very generic blocks that show up on the
>>>>>>> timeline, that don't clearly identify what they are.  And I don't believe
>>>>>>> there's any way to visualize promises on this timeline.
>>>>>>>
>>>>>>> *The problem with Promises*
>>>>>>> I want to create a file system framework for node.  I'd like to make
>>>>>>> watching the files for changes a default feature.  The problem with
>>>>>>> promises, is that you can't re-resolve them.
>>>>>>>
>>>>>>> So I'm basically left with streams, or plain old callbacks.  Or
>>>>>>> trying to recreate the promises every time they resolve...
>>>>>>>
>>>>>>> What's the end game?  100 years from now?
>>>>>>>
>>>>>>> Frankly, this is the most important question.  I feel like if we
>>>>>>> take a step back, and try to solve these problems for the long term, we'd
>>>>>>> be better off.
>>>>>>>
>>>>>>> And so, it's 5:15.  Well done, Michael.  Well done.
>>>>>>>
>>>>>>> *The Future*
>>>>>>> If anyone has made it this far, I'm going to tell you a quick
>>>>>>> summary of my plan:
>>>>>>>
>>>>>>>    1. make an ultra-simple web framework (almost done?)
>>>>>>>    2. use that framework to make a CMS to kill WordPress
>>>>>>>    3. turn that CMS into a web OS that does everything a real OS
>>>>>>>    can do, only better
>>>>>>>    4. turn that web OS into a real, bare metal OS
>>>>>>>    5. make lots of amazing (useful) software (like photoshop,
>>>>>>>    blender, after effects, CAD, etc)
>>>>>>>
>>>>>>> Software development is sluggish.  Most software is painful to use.
>>>>>>> Windows, Photoshop/Illustrator, many websites...  Open source software
>>>>>>> doesn't get the funding/momentum it needs to really kill these proprietary
>>>>>>> alternatives.  We need to change that.  I'm going to change that.
>>>>>>>
>>>>>>> Stay tuned.
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> es-discuss mailing list
>>>>>>> es-discuss at mozilla.org
>>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>>>
>>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> es-discuss mailing list
>>>>> es-discuss at mozilla.org
>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>
>>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20171107/809c1ffa/attachment-0001.html>


More information about the es-discuss mailing list