> The iterable utilities would be geared towards *sync* iterators primarily, > which are typically *not* used for I/O.
can you give common use-cases for javascript *sync* iterators in an industry-context (e.g. web-programming) that are superior to existing es5 design-patterns? because i honestly cannot think of any. as a former pythonista (for 7 years), i recall using python-iterators primarily for blocking-io (e.g. readline) or algorithms, both of which are niche-applications of javascript in industry (nobody hires javascript-programmers to waste *days* writing algorithms, when good-enough results can be achieved in *hours* with sqlite3 or child_process calls to imagemagick/numpy/grep/find/"rm -r"/etc). the typical scenario for *sync* iterators that plays out in my head, is that the pm will eventually request a feature requiring unavoidable async io, turning the *sync* iterator into an *async* one, which quickly devolves into technical-debt during integration (and will eventually have to be rewritten as a non-iterator for anyone who has the will to do the cleanup). On 7/12/18, Isiah Meadows <[email protected]> wrote: > The iterable utilities would be geared towards *sync* iterators primarily, > which are typically *not* used for I/O. They would have more in common with > Lodash than RxJS. > > And JS is not async-first - that's Go, Haskell (with GHC), Clojure > (somewhat), and some mostly obscure and/or niche languages, which feature > non-blocking I/O with deep language integration (you don't have to code > explicit support for it) complete with easy parallelism and syntactic sugar > for other things concurrency-related. JS is async-second, like C# and F#, > which each feature native non-blocking and (in some cases) optional > blocking I/O along with native syntax and/or DSLs with appropriate builtins > to support the non-blocking variants, but you still have to code specially > for them. > > Observables are typically used for *input*, not *output*, but they do > actually shine well for what they do. They aren't IMHO the ideal > abstraction, but they're pretty close for relatively procedural languages. > (I prefer duplex streams as a primitive, not observables - they're usually > more fault-tolerant, and they're easier to compose and integrate with.) > > One last thing: Koa now uses promises, not generators. They only used > generators to emulate what async functions provided, and they first made > the decision before the feature went stable in V8, even before the feature > hit stage 4 in the spec. > > On Wed, Jul 11, 2018, 12:06 kai zhu <[email protected]> wrote: > >> > The main things I know of that are blocked on the pipeline operator >> > IIUC >> > are observables and iterable utilities. >> >> unlike synchronous languages like python where everything blocks, do >> we really want iterable utilities for a [one-of-a-kind] async-first >> language like javascript? >> >> nothing good has ever come from mixing generators with async i/o from >> my experience. it typically results in hard-to-reason >> logical-nightmares (and hard-to-fix timeout bugs), that makes >> web-project integration-work more hellish than it already is (think of >> how un-debuggable most projects that use koajs-middlewares end up). >> >> -kai >> >> On 7/11/18, Isiah Meadows <[email protected]> wrote: >> > The main things I know of that are blocked on the pipeline operator >> > IIUC >> > are observables and iterable utilities. As-is, using observables >> > without >> > methods or a pipeline operator starts to feel like you're using Lisp, >> > not >> > JS, because of the sheer number of operators. (It's an array over >> > *time*, >> > not *space*, so you have things like debouncing, throttling, etc. that >> you >> > have to address.) Iterables are in a similar situation because they're >> > lazy, it's protocol-based rather than prototype-based, and JS lacks >> > anything like monads. >> > >> > ----- >> > >> > Isiah Meadows >> > [email protected] >> > www.isiahmeadows.com >> > >> > On Tue, Jul 10, 2018 at 11:18 AM, Ben Wiley <[email protected]> >> > wrote: >> > >> >> It’s not clear to me that pursuit of new Array methods should be >> >> abandoned >> >> purely on speculation that the pipe operator will pass Stage 1. >> >> >> >> >> >> >> >> That said, the realization that Object.assign provides this >> functionality >> >> is enough for me to quit pursuing (my version of) >> >> Array.prototype.replace. >> >> >> >> >> >> >> >> I’d prefer that further discussion concern the earlier-discussed >> >> extension >> >> to the Array rest spread syntax. :) >> >> >> >> >> >> >> >> Ben >> >> >> >> >> >> >> >> *From: *Andrea Giammarchi <[email protected]> >> >> *Date: *Tuesday, July 10, 2018 at 10:50 AM >> >> *To: *"T.J. Crowder" <[email protected]> >> >> *Cc: *"[email protected]" <[email protected]>, " >> >> [email protected]" <[email protected]> >> >> *Subject: *Re: Array.prototype.replace >> >> >> >> >> >> >> >> just a few days ago another full stack JS dev mentioned Array replace >> and >> >> it has nothing to do with what was proposed in here: >> >> >> >> https://medium.com/@gajus/the-case-for-array-replace-cd9330707243 >> >> >> >> >> >> >> >> My TL;DR response was that once the pipe operator is in, everyone can >> >> bring in its own meaning for `array |> replace` and call it a day. >> >> >> >> >> >> >> >> Keep polluting the already most polluted prototype of them all doesn't >> >> look like a good strategy to improve the language. >> >> >> >> >> >> >> >> Just my 2 cents. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Tue, Jul 10, 2018 at 3:37 PM T.J. Crowder < >> >> [email protected]> wrote: >> >> >> >> On Tue, Jul 10, 2018 at 2:18 PM, Ben Wiley <[email protected]> >> >> wrote: >> >> > Hm, despite the fewer number of points in the cons category I'm >> >> persuaded by >> >> > the argument that we don't want people getting arrays and objects >> >> confused. >> >> > Might be best to limit that until there is a compelling use case >> >> > which >> >> there >> >> > might not be. >> >> >> >> Heh, whereas despite having written that first bullet in the footgun >> >> column somewhat forcefully (looking back), I go the other way. :-) >> >> >> >> >> >> >> >> -- T.J. Crowder >> >> >> >> _______________________________________________ >> >> es-discuss mailing list >> >> [email protected] >> >> https://mail.mozilla.org/listinfo/es-discuss >> >> >> >> >> >> _______________________________________________ >> >> es-discuss mailing list >> >> [email protected] >> >> https://mail.mozilla.org/listinfo/es-discuss >> >> >> >> >> > >> > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
