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
