Question of the Day: What about all this asynchrony?

Naveen Chawla naveen.chwl at
Tue Nov 7 20:13:55 UTC 2017

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

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

More information about the es-discuss mailing list