Question of the Day: What about all this asynchrony?
Logan Smyth
loganfsmyth at gmail.com
Tue Nov 7 19:50:42 UTC 2017
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20171107/5e0a33dc/attachment-0001.html>
More information about the es-discuss
mailing list