Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #29635

Re: library for fast map/filter/reduce

Show all headers | View raw

glathoud wrote:
> I'd like to share a library that permits to write map/filter/reduce code 
> that runs much faster than the corresponding native Array methods. It 
> works by generating fast JS code automatically, with a single for loop
> whenever possible, and also includes logical functions and object/array 
> conversions functions.
> 
> http://glat.info/transfun/

Please, when posting to USENET, give more information than a sound-bite
and a link.  The link is fine, but it should be backed up by further 
discussion, code, questions, debate, flame-wars, pedantry, ... in short,
by *content*.  You certainly do not need to replicate all the content to
which your link makes reference, but there should be enough that people
here can discuss it without chasing down the link, and only visit that
page if it still seems interesting to them.

-----

Now, as to your library, congratulations!  It's very interesting.  It
seems to combine aspects of two ideas that I haven't seen put together
before.  First, it uses a syntax very similar to Oliver Steele's
Functional JavaScript [1], the first fairly comprehensive library for
doing functional programming in Javascript.  The similarity here is
in the string-based lambda expressions, such as `'.p'` for the 
equivalent of `obj => obj.p` or `function(obj) {return obj.p;}`, and
`'+'` for `(a, b) => a + b`.

Second, you implement the relatively new notion of *transducers*
[2], which, at their core, replace a sequence of iterations of
transformations with an iteration of a sequence of transformations. 
This prevents the creation of intermediate containers and can gain
some serious efficiency.

There are two reasons that this API does not appeal to me.  First,
although I appreciate the _tour de force_ that was Oliver Steele's
original library, I don't at all care for the string lambdas.  They
feel entirely wrong, as though all the lessons we've learned over 
the years about problems with `eval` are to be discarded.  Second,
I absolutely prefer to work by building composing more sophisticated
functions out of simpler ones.  Chaining methods together holds
absolutely no appeal.

So this example from transfun:

    var appfun = tfun.map( '.p' ).filter( '!=null' ).reduce( '+' );

I would write using Ramda as

    const appfun = pipe(map(prop('p')), filter(complement(isNil)), sum);

The main difference is that I can pass ANY function through a pipeline
like this.  It does not have to be a fixed method of some object or 
set of objects.  So for instance, if I wanted to reuse the ability to
filter out the null values, I would simply name that function:

    const removeNulls = filter(complement(isNil));
    const appfun = pipe(map(prop('p')), removeNulls, sum);

I don't see a way to do this with a chained set of method calls.  But
I have only looked at your documentation and haven't dug into the code
so I may be missing something interesting.

But regardless of whether it's something that appeals to me personally,
kudos on putting this together.  There's definitely some interesting
ideas here!

  [1]: The original documentation page seems to be offline, but the code
       is on GitHub at <https://github.com/osteele/functional-javascript>
       and an initial announcement is at 
       <https://github.com/osteele/functional-javascript>

  [2]: First discussed in the Clojure community, e.g.: 
       <http://blog.cognitect.com/blog/2014/8/6/transducers-are-coming>.
       There are several well-known Javascript versions, including 
       <https://github.com/jlongster/transducers.js> and
       <https://github.com/cognitect-labs/transducers-js>.  They're also
       partially folded into some more general-purpose libraries like
       Ramda: <http://ramdajs.com> (disclosure: I'm one of the authors.)


  -- Scott

Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

library for fast map/filter/reduce glathoud <glathoud@yahoo.fr> - 2016-02-16 22:24 -0800
  Re: library for fast map/filter/reduce Scott Sauyet <scott.sauyet@gmail.com> - 2016-02-18 20:01 -0800
    Re: library for fast map/filter/reduce glathoud <glathoud@yahoo.fr> - 2016-02-19 02:10 -0800
      Re: library for fast map/filter/reduce Scott Sauyet <scott.sauyet@gmail.com> - 2016-02-19 08:44 -0800
        Re: library for fast map/filter/reduce glathoud <glathoud@yahoo.fr> - 2016-02-20 04:03 -0800
          Re: library for fast map/filter/reduce Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-02-20 13:59 +0000
            Re: library for fast map/filter/reduce glathoud <glathoud@yahoo.fr> - 2016-02-23 21:53 -0800
  Re: library for fast map/filter/reduce "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-02-23 19:22 -0800
    Re: library for fast map/filter/reduce glathoud <glathoud@yahoo.fr> - 2016-02-23 22:11 -0800

csiph-web