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
