On Wed, Nov 8, 2017 at 10:00 AM, Jeremy Martin <jmar...@gmail.com> wrote:
> Michael, > > You are not alone in your frustrations. Many of your points are valid, > have been voiced before, and will no doubt be voiced again. No one on here > is unsympathetic to this, and many members of TC39, as well as other > community members, dedicate significant amounts of time, freely, to > educational resources. > Thanks, it's a relief to finally hear. This was definitely *not* the impression that I've gotten so far. I've essentially heard, "there is no problem, what are you talking about?" > > Lambasting TC39 for not formalizing and centralizing these educational > resources -- a task that exists far outside of their charter -- is not > productive. > This (not concerning themselves with the end users experience) is a mistake (an opinion). The JavaScript community would be better off if more care were given to this aspect (not an opinion). > > The list of useful resources out there is pretty extensive, and as you've > pointed out, that can have a downside if you don't know where to go. If > it's helpful, here's a non-canonical overview of some of the more useful > ones, though: > > *For a one-stop shop:* > > MDN (https://developer.mozilla.org/en-US/docs/Web/JavaScript). If you > want a single destination, choose this one. It has introductory material, > beginner, intermediate, and advanced-level tutorials, and is the most > complete and well-maintained developer-focused JavaScript reference site. > MDN is great, I find myself here frequently. > > *For non-formal discussion of cutting-edge, emergent features:* > > Axel Rauschmayer's blog (http://2ality.com/). As it pertains to some of > your specific questions, there is a lot of great material here on Promises > in particular. > I read a good portion of his Meta Programming chapter, and find myself here frequently. > > Dr. Rauschmayer has also written a series of extraordinarily useful books > that he has graciously made freely available online, here: > http://exploringjs.com/. > > *Regarding the "closed" nature of TC39:* > > Most discussion happens here on this mailing list, in public. Copious > meeting notes for all in-person meetings are available here, as well: > http://tc39.github.io/tc39-notes/. > So this mailing list is it, and it seems my efforts here are failing. > > *If you want to search past es-discuss threads:* > > https://esdiscuss.org/ > > Yes, my original post in this thread links there. I'm aware that all these emails are public archived. > > *For your specific questions about why we have Promises AND Generators AND > Iterators AND...* > > The General Theory of Relativity (https://github.com/kriskowal/gtor/). > You obviously already mentioned this, but I encourage you to please go and > read it. While this isn't a general resource for the language, it is the > most comprehensive and useful exploration of this specific topic that I'm > aware of, and I genuinely believe you would find it illuminating on why > this complexity exists around asynchrony. > If I get time, I might head back there. Honestly, though, I'm looking for simple summaries as opposed to exhaustive histories. Give me the takeaways. Save me some time. And, more importantly, what will the future be like? That's what I was in search of. What has this committee concluded on is the vision for the future (in terms of all the various async solutions, and creating interoperable adapters)? I don't think the answer to this is in that document. > > There are clearly many in addition to these, but that's a short list of > some that I've personally found to be useful. > I sincerely appreciate your time in compiling the list. > > ------ > > If you don't like that this all exists as discrete, separate resources, > then that's an opinion that you're entitled to. A canonical, comprehensive, > and centralized resource for all of this would required thousands of hours, > either volunteered or paid for by others, and that's something no one is > entitled to. If you want to make that happen, I suggest a strategy other > than reprimanding a group of people that are already contributing > significant time to what resources do exist. > I understand, but we can always do better (nothing is perfect). And that applies even with scarce resources. It could be better. I want to help. > > Regarding topic appropriateness for this mailing list, admittedly the > lines can be blurry at times. GUI's and developer tooling are typically > outside of scope, though. Visualizations around Promises are an > interesting topic, but as a non-TC39 member, I think I can still safely say > that it won't be making it into the language itself. > Visual development is inevitable. If TC39 doesn't address it, then by the time visual development becomes the norm, TC39 probably won't exist. There's no need for a governing body that's not doing their job. > Tooling is best left to evolve independent of the language itself, rather > than being frozen at the specification level. Even the most basic developer > tools, like the `console` object, are not a part of the ecmascript spec - > they are host objects provided by the runtime. > I understand. Yet, many of the people on this list work on those runtime implementations (Chrome, node, whatever). I'm reaching out to anyone who will listen. > > Again, I'm not trying to be dismissive of your ideas here, but the > validity of an idea or a frustration isn't the measure for whether or not > it's on-topic for es-discuss. If you want to continue discussing some of > your ideas for the language, I'm not discouraging you from that, but I > *am* encouraging you to perhaps choose one to start with, evolve the idea > until it's sufficiently clear and concrete to present for discussion. > I don't want to break the rules and get removed from the list. But it seems this list is powered by mozilla, and not "owned" by TC39 anyway. And because there are no official topic rules, I think that discussing aspects that are *required* for JavaScript development is fair game. Unless someone (at mozilla) requests otherwise. I'm learning very quickly that the problems are systemic, and yelling around here won't get anywhere. By the way, I just found this <https://tc39.github.io/process-document/> and this <https://github.com/tc39/proposals> and this <http://tc39.github.io/tc39-notes/>. These would have been helpful a while ago. Even still, they raise more questions than answers. These won't help someone struggling to make sense of things. They will only confuse them more. I guess the average developer is required to follow all the people, read all the blogs, come back to MDN every so often and reread the entire site to make sure they don't miss something that appears in there. The problem is real. The conclusion: "won't fix". > > On Wed, Nov 8, 2017 at 9:00 AM, Michael Lewis <m...@lew42.com> wrote: > >> How difficult is it for a web developer to make a website? >> >> What if everyone in this mailing list shared their personal websites, and >> we ranked them? Not that mine is great, but at least I'm admitting that >> it's really fucking hard to make a simple website... I know a *lot *of >> web developers that *don't have their own website*. And most that do, >> probably used WordPress, a static site generator, or another crutch. >> >> I was reading a post by Jake Archibald >> <https://jakearchibald.com/2015/tasks-microtasks-queues-and-schedules/> the >> other day, and noticed he had some interactive elements within the content >> of his page. Wow, what a concept, right? Besides some major news outlets, >> I very rarely see this on the web. Aside from an image (non interactive) >> or a video (hardly "interactive"), how often do you see *interactive >> content* on the web? Very rarely. How long did it take to create? >> Jake says he spent his entire weekend on that one blog post. >> >> *THE WEB IS BROKEN. FOR CHRIST'S SAKE. *And yes, I understand that >> nobody in this mailing list cares. Maybe I need to join the whatwg group, >> and yell at them. Or maybe I just continue working on it, by myself, in my >> basement. Or maybe I'll get some help someday. Lead me, follow me, or get >> the fuck out of my way. >> >> Also, this is a fitting time to share a page >> <https://lew42.com/test/view42/View1/Clean/> I wanted to share a while >> back (due to Jeremy Martin's inability to imagine a visual development >> experience). It doesn't live re-evaluate the code for each block, as it >> could. But it shows some object renderings. If you scroll down to the >> last test block, and click on the object titled "this", you'll see a >> rendering of the actual Test object. You can see the 1 line of code used >> to render that: View.inspect(this, "this"); >> >> So yes, Jeremy, you could "automatically render Promise diagrams"... >> Maybe I'll get around to showing you how that works. >> >> What does your app *look like?* Creating views for all the things is >> really important. If you can see it, you can understand it. >> >> On Wed, Nov 8, 2017 at 7:39 AM, Michael Lewis <m...@lew42.com> wrote: >> >>> So, the group that designs the language that the world uses for building >>> web apps, cannot provide insight as to why they do what they do? Smells >>> like bullshit. Maybe you can expand on that part further? >>> >>> Check this <https://github.com/tc39/agendas/issues/272> out. It seems >>> the ECMA/TC39 group is closed to the public. >>> >>> I'm just trying to make this easier for everyone... >>> >>> This reminds me of our government, who writes laws so dense even the >>> lawmakers don't read them. And then they expect everyone to abide by >>> them. It's *somewhat* understandable (given the complexity of life). >>> Yet, there's an easy/obvious solution: summarize, organize, and simplify. >>> The law/specifications can be complex and simple, at the same time. And I >>> feel like it's the responsibility of those who understand it the best to >>> accurately reduce the complexity into simpler form. >>> >>> This process (organizing, summarizing, simplifying) is the ultimate key >>> to life. Science, education, content, knowledge... Sometimes we do this, >>> but it can always be done better. >>> >>> Have we taken JavaScript knowledge, and organized, summarized, and >>> simplified it to its purest form? Absolutely not. Not even close. >>> >>> In some areas of JS development (such as module management (dep mgmt, >>> loading/import), version control, debugging, persistence, etc) the >>> *best* solutions that we have, are *severely broken*, *have been broken >>> for decades*, and *TC39 isn't concerned with*. That sounds like a >>> problem to me. I'm sure everyone here would like to argue with me about >>> this. The point is to realize where these areas *can be better*, and *make >>> them better*. Not to argue about why they're not broken... Duh. >>> >>> But, it seems like we need a new umbrella organization that's allowed to >>> discuss the entire picture. Hahaha... it's so stupid. "Don't talk about >>> that here." "That's not a problem, you're the problem." So much broken. >>> >>> On Wed, Nov 8, 2017 at 6:49 AM, Naveen Chawla <naveen.c...@gmail.com> >>> wrote: >>> >>>> Hi Michael! TC39 is rightfully reluctant to offer usage advice. People >>>> should develop their best practices from experiences and the use cases >>>> they're involved in. >>>> >>>> For me, to answer your question, since I'm not a TC39 member, it's >>>> async functions all the way, and ditch observables, raw promises, >>>> callbacks. I'd love to hear from those who think observables might ever be >>>> preferable over using async functions to do the same thing... since I don't >>>> currently see how it could ever be >>>> >>>> On Wed, 8 Nov 2017 at 17:56 Michael Lewis <m...@lew42.com> wrote: >>>> >>>>> Hi Felipe, >>>>> >>>>> I read and generally understand your points (while I don't fully >>>>> understand all the new async syntax and best practices >>>>> <https://stackoverflow.com/questions/47178411/custom-thenables-can-i-create-my-own-objects-with-a-then-method>). >>>>> You agree that there's a lot to learn, but nobody wants to even >>>>> acknowledge that this committee has the power (responsibility?) to fix >>>>> that >>>>> problem <https://esdiscuss.org/topic/web-docs>. To make learning >>>>> simpler, easier, etc. It could start with an official blog. There are >>>>> too >>>>> many scattered resources. Too much conflicting advice, and not an >>>>> official >>>>> direction. >>>>> >>>>> If Babel is here to stay - and transpiling custom syntax into official >>>>> syntax is going to proliferate, this problem will only get worse. >>>>> >>>>> This has to do with leadership - there doesn't seem to be a strong >>>>> presence leading the pack. There are millions of developers scrambling to >>>>> make sense of all this stuff, and the best resources we have are the >>>>> continuous stream of blog posts that are constantly introducing new >>>>> things, >>>>> and often create more questions than answers. >>>>> >>>>> It's clear to me that the people in this mailing list tend to stay at >>>>> the cutting edge. You all read about the latest immediately when it's >>>>> released. It makes sense to you, and there is no problem. The "rest of >>>>> us" who struggle just aren't doing it right. >>>>> >>>>> On Tue, Nov 7, 2017 at 6:09 PM, Felipe Nascimento de Moura < >>>>> felipenmo...@gmail.com> wrote: >>>>> >>>>>> Hi. >>>>>> >>>>>> Michael, the JavaScript (and Web in general) communities are very >>>>>> open and always queen to help. >>>>>> I just think you hit the wrong mailing list to discuss all that. >>>>>> >>>>>> For new comers, indeed, there is plenty to work on, practice and >>>>>> study. But keep in mind that many of those features came from different >>>>>> languages and technologies. >>>>>> And there are a lot of conferences, meetups, groups, slack channels, >>>>>> newsletters, articles, videos...tons of content out there :) >>>>>> >>>>>> Trying to answer your question. >>>>>> I understand the feeling you are having, but think it this way... >>>>>> - Asynchronous code opens doors for possible gains in performance. >>>>>> Many improvements have only been possible due to this asynchronicity. >>>>>> - Async code helps you modulate/split your code. If your are an >>>>>> organized person, it will be good...otherwise, things can get messy! >>>>>> - Async code nowadays can be dealt with, as if it was sync (using >>>>>> async await), the other way around was a problem! Many times you needed >>>>>> something asynchronous and had to create layers on top of it. >>>>>> - Async allows new APIs. For example, Web workers and Service >>>>>> Workers. They simply wouldn't be possible if not by asynchronous ways. >>>>>> - Creating async APIs allows developers to explore and use your API >>>>>> in different ways...also, if your code is well organized, it has an >>>>>> easier >>>>>> maintanence. >>>>>> - APIs related to interoperability and usability also benefit from >>>>>> this. Let's say, you need a user permission to do something and have to >>>>>> way >>>>>> for the user to agree with it. Or maybe you ware waiting for another app >>>>>> to >>>>>> answer with the result from something else, like a picture or a >>>>>> share(from >>>>>> shareAPI). >>>>>> >>>>>> As for "which" way you want to make your code async...that goes with >>>>>> what you are working on. >>>>>> If you are using promises, you can easily** have it working with >>>>>> async/await. >>>>>> Observables and promises can work together, but you will have to >>>>>> study a little further to feel familiar with it. >>>>>> >>>>>> I hope I have helped somehow :) >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Nov 7, 2017 at 8:42 PM, Michael Lewis <m...@lew42.com> wrote: >>>>>> >>>>>>> Making things simpler, clearer, and more visual has obvious benefits. >>>>>>> >>>>>>> I think I was very clear from the beginning that this was *NOT* a >>>>>>> concrete proposal. And I've seen many posts on here that are not. From >>>>>>> now on, I'll title my posts to more clearly indicate that *reading >>>>>>> is abstract, discussion, optional.* >>>>>>> >>>>>>> The confusion about async interoperability >>>>>>> <https://medium.com/@benlesh/rxjs-observable-interop-with-promises-and-async-await-bebb05306875> >>>>>>> isn't >>>>>>> mine alone. I'm a new comer to this scene, and my original curiosity >>>>>>> was >>>>>>> this community's long-term vision for asynchrony. How do we get all the >>>>>>> pieces to play well together? Thank you for contributing 0 to that >>>>>>> understanding. >>>>>>> >>>>>>> And my point about the new comers to JavaScript or computers in >>>>>>> general, how are they to make sense of this ever-moving language? You >>>>>>> need >>>>>>> better documentation, publication (an official blog), etc. >>>>>>> >>>>>>> On Tue, Nov 7, 2017 at 3:03 PM, Jeremy Martin <jmar...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>>> 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 <(661)%20312-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 >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> es-discuss mailing list >>>>>>> es-discuss@mozilla.org >>>>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> [ ]s >>>>>> >>>>>> *--* >>>>>> >>>>>> *Felipe N. Moura* >>>>>> Web Developer, Google Developer Expert >>>>>> <https://developers.google.com/experts/people/felipe-moura>, Founder >>>>>> of BrazilJS <https://braziljs.org/> and Nasc <http://nasc.io/>. >>>>>> >>>>>> Website: http://felipenmoura.com / http://nasc.io/ >>>>>> Twitter: @felipenmoura <http://twitter.com/felipenmoura> >>>>>> Facebook: http://fb.com/felipenmoura >>>>>> LinkedIn: http://goo.gl/qGmq >>>>>> --------------------------------- >>>>>> *Changing the world* is the least I expect from myself! >>>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 <(661)%20312-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
