Array.prototype.replace

[kai zhu]

> 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 <isiahmeadows at gmail.com> 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 <kaizhu256 at gmail.com> 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 <isiahmeadows at gmail.com> 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
>> > me at isiahmeadows.com
>> > www.isiahmeadows.com
>> >
>> > On Tue, Jul 10, 2018 at 11:18 AM, Ben Wiley <therealbenwiley at gmail.com>
>> > 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 <andrea.giammarchi at gmail.com>
>> >> *Date: *Tuesday, July 10, 2018 at 10:50 AM
>> >> *To: *"T.J. Crowder" <tj.crowder at farsightsoftware.com>
>> >> *Cc: *"therealbenwiley at gmail.com" <therealbenwiley at gmail.com>, "
>> >> es-discuss at mozilla.org" <es-discuss at mozilla.org>
>> >> *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 <
>> >> tj.crowder at farsightsoftware.com> wrote:
>> >>
>> >> On Tue, Jul 10, 2018 at 2:18 PM, Ben Wiley <therealbenwiley at gmail.com>
>> >> 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
>> >> es-discuss at mozilla.org
>> >> https://mail.mozilla.org/listinfo/es-discuss
>> >>
>> >>
>> >> _______________________________________________
>> >> es-discuss mailing list
>> >> es-discuss at mozilla.org
>> >> https://mail.mozilla.org/listinfo/es-discuss
>> >>
>> >>
>> >
>>
>