naveen.chwl at gmail.com (2017-11-08T05:34:10.374Z)
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:
```js
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.
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 >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20171107/2c072868/attachment-0001.html>