Question of the Day: What about all this asynchrony?

Jeremy Martin jmar777 at gmail.com
Tue Nov 7 21:11:19 UTC 2017 

:(

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 <jmar777 at gmail.com> 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 <naveen.chwl at gmail.com>
> wrote:
>
>> Correct, `for..of` instead of `forEach`
>>
>> On Wed, 8 Nov 2017 at 01:21 Logan Smyth <loganfsmyth at gmail.com> 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 gmail.com>
>>> wrote:
>>>
>>>> ... 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
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
>
>
> --
> Jeremy Martin
> 661.312.3853 <(661)%20312-3853>
> @jmar777 <https://twitter.com/jmar777> / @j <https://stream.live/j>
>
>


-- 
Jeremy Martin
661.312.3853
@jmar777 <https://twitter.com/jmar777> / @j <https://stream.live/j>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20171107/4865600f/attachment-0001.html>

More information about the es-discuss mailing list