Wow dude... Again, you're trying to pick a fight. I'm not "publicly shaming" anyone, that's ridiculous.
All I have to say is, just watch. On Wed, Nov 8, 2017 at 1:22 PM, Jeremy Martin <jmar...@gmail.com> wrote: > I don't represent TC39, and I don't like adding so much noise to this > list, so this will be my last reply on the topic. > > There's nothing fundamentally wrong with what you want, but you're barking > up the wrong tree to get it: > > >> This (not concerning themselves with the end users experience) is a >> mistake (an opinion). > > > This group is acutely aware of, and concerned with, the end user > experience. As previously stated, many (if not most) of the members > actively contribute from their personal time to assist in these areas. But > that *doesn't* mean that as a committee they are obligated to all aspects > of the developer experience. > > 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. > > > Whether scarce or abundant, when the "resource" is someone else's time and > effort, you simply don't have any claim to it. If you want to help, then do > it! Publicly shaming people who are *already* helping, simply because > they're not helping where and how you want them to, is not ok, though. > > 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. > > > I wasn't going to respond until I read this part. Someone has already > spent hours upon hours researching and compiling a useful resource (*A > General Theory of Reactivity*), and instead of reading it, you're > demanding *more* time from complete strangers to distill it into the > exact level of verbosity that *you* want. That's not ok, and not what > this mailing list is for. People in this list dedicate countless hours to > save other people time, but their efforts aren't at your beck and call. > > Visual development is inevitable. > > > Even if I am 100% in support of that statement, that doesn't mean that the > visual development facilities are a part of the language itself. Again, I'm > not trying to say that you have bad ideas, just that you've found the wrong > mailing list for some of these. > > There's no need for a governing body that's not doing their job. > > > The abundance of new features in the language is prima facie evidence that > they are doing their job. Their job just isn't what you want it to be. > > 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. > > > That's fine, there's no harm in trying. But when the people you reach out > to suggest that it's off topic or out of scope for the venue you've chosen, > then it's not fine to start ranting and publicly shaming them. > > The problem is real. The conclusion: "won't fix". > > > Yes, there is a real problem (at least a challenge, anyway). But the > existence of a problem isn't a license to demand a solution from whomever > you deem responsible. Even when members in this list have tried to offer > some help, primarily by referencing relevant reading material, those > efforts have been rejected because we didn't create the cliff notes for > you. Again, I'm not the authority on what is or isn't within scope of this > list, but the sum total of these demands, shaming, and wandering subject > matter do not seem to be appropriate here. > > > On Wed, Nov 8, 2017 at 1:05 PM, Michael Lewis <m...@lew42.com> wrote: > >> >> >> 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/to >>>>>>>>>>>>>>>>> pic/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> >>> >>> >> > > > -- > 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
