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 <[email protected]> wrote: > ... that should be `await doMoveAsync()` > > On Wed, 8 Nov 2017 at 01:16 Naveen Chawla <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>>> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>>>>>> 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 >>>>>>>> [email protected] >>>>>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>>>>> >>>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> es-discuss mailing list >>>>>> [email protected] >>>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>>> >>>>> >>>> >>> > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
