> 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 <naveen.c...@gmail.com> wrote:
> Correct, `for..of` instead of `forEach`
>
> On Wed, 8 Nov 2017 at 01:21 Logan Smyth <loganfsm...@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.c...@gmail.com>
>> wrote:
>>
>>> ... that should be `await doMoveAsync()`
>>>
>>> On Wed, 8 Nov 2017 at 01:16 Naveen Chawla <naveen.c...@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 <m...@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 <m...@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.c...@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 <m...@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 <r...@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 <m...@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@mozilla.org
>>>>>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> es-discuss mailing list
>>>>>>>> es-discuss@mozilla.org
>>>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
