Michael,
You've spent a considerable amount of time putting your thoughts into
writing, so I don't intend to be dismissive of them, but this doesn't seem
to be the right distribution channel for whatever you're getting at.
As it stands, you've thrown quite a few questions out that don't seem to be
related to the ongoing standardization and specification process that this
group is primarily focused on. E.g.,
- Are RxJS Observables basically streams?
- What will our children be learning in 100 years?
- What are generators?
- ...do they work with Promises?
- ...do they work with streams?
- etc.
There are reams of documentation, articles, and guides that delve into
these topics in great detail, including the excellent *General Theory of
Reactivity* that you already mentioned. The questions you've brought up are
all valid, and these resources will help you gain the knowledge you need if
you still want to put a specific proposal forward -- but for now your
points seem to awkwardly highlight that you've already identified the best
resources to do this, but refuse to actually read them.
And while es-discuss is indeed an appropriate place to solicit feedback on
language-level proposals, the ideas you've thrown out read like an
off-the-cuff stream of consciousness:
- Promises that automatically render diagrams?
- A GUI for loading/defining modules (somehow related to an AST)?
- Async strings with some informal behavior around branching and
transforms, that are someone analogous to version control, and again, a GUI
is involved somewhere?
- Real-time booleans with change events (but with a new definition for
"change events" that is oddly based around a non-reactive datastructure).
I made an honest attempt to make it through your posts with an eye for what
your point is, but these simply aren't concrete or coherent enough to
facilitate a conversation, much less be actionable.
The concept of "do it now" or "do it later" is as easy as 123.
I urge you to consider that statements like this belie that you haven't
grappled with the subject matter enough. It frankly trivializes the topic
beyond recognition.
If you have a concrete proposal you'd like to see discussed, then a
dedicated thread with a clear description, examples, and motivating factors
is completely welcome. If you're looking to rant or ruminate around topics
like Promises, Generators, Observables, Streams, etc., while simultaneously
admitting that you aren't taking the time to understand them, then this is
simply the wrong venue.
On Tue, Nov 7, 2017 at 3: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
>
>
--
Jeremy Martin
661.312.3853
@jmar777 <https://twitter.com/jmar777> / @j <https://stream.live/j>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
