Oh, you're right :-\ empty async functions return a promise, interesting...
On Tue, Nov 7, 2017 at 2:27 PM, Michael Lewis <m...@lew42.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 > > 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