CrossEye

I wonder if whatever is left of Netscape can sue Microsoft now over JScript...

And many of us have gained a great deal by having you publish on the side.

Thanks, raganwald!

Ok, that helps make it a bit more palatable to me.

Thanks for the information.

One question, though: How do user functions interact in here? If you didn't include `flatten`, but I had my own version of it, would it be straightforward for me to build `process` using my own `flatten`? Do I have to modify some Trine objects, or can I use some simple function references?

Obviously I haven't yet actually dug into the Trine code. Perhaps this weekend.

It's a funny world. Each of us is looking at the other library thinking there's too much magic involved. :-)

Ramda is [considering a technique][1] that would significantly reduce call stacks. But there is nothing likely to help with you understand parameter orders of your functions. Many users annotate their functions with something like Haskell signatures.

Thank you for bringing forth another interesting library. I'll be following your progress. Best of luck!

[1]: https://github.com/ramda/ramda/pull/907

as inglor said, this depends on strict mode:

    > var isboxed = (function() {"use strict"; return function isboxed() {return this instanceof Number;}}());
    > isboxed.call(5);
    false

That is ceratainly one of my standard examples.

The best answer to this seems to be simply:

    var sum = ls => ls.reduce(add, 0)

ISTM that this is neither as elegant nor as easy to reason about, but it's also not horrible. It really moves away from the easy association that Ramda makes between

    var currentTotal = reduce(add, 0, nbrs);

and

    var sum = reduce(add, 0); //=> :: [Number] -> Number

Of course this arrow syntax is ES6 (or transpiler) only, but the library is predicated on that notion. Ramda is a bit of an oddity, still maintaining compatibility with ES3 - ES6.

No, in fact the real problem has been that too many incompetent people were far too certain about how to use it.

The difference starts to show when you want to partially apply some values.

    // process1 :: (Item -> Bool) -> [Item] -> [OtherType]
    // process2 :: [Item] -> [OtherType]
    process1(isOk, items); //=> [otherType1, otherType2, ...]
    process2(items); //=> [otherType1, otherType2, ...]

    
    var processR1 = seq(filter, map(toOtherType), flatten);
    var processR2 = processR1(isOk);

    
    var processT1 = (isOk, items) => items.filter(isOk).map(toOtherType).flatten()
    var processT2 = items => processT1(isOk, items)

That's why I'm wondering if there's some easier way to do this.

That's not sad. Use the tools that work for you.

It was finding that those tools were no longer supporting the way I wanted to work that got me started on Ramda. I'm guessing the same is true for the author of Trine.

(Disclosure: one of the authors of Ramda here, so I may well be biased toward a very different approach.)

This is an interesting approach, but I get caught right at the beginning, where you say "What you'd really want to do is this:

    items
      .filter(isOk)
      .map(toOtherType)
      .flatten()
      
      

But what I really want to do is build a reusable function:

    var process = seq(filter(isOk), map(toOtherType), flatten);
    

So I can at my leisure call

    process(items);
    

Or later put `process` in another sequence, or do something like:

    map(process, groupsOfItems)
    

And I don't see that Trine helps with that. Am I missing the way to use Trine to build functions, or do I simply have to wrap up a Trine construct in a function that takes a parameter, does its Trine magic, and returns that result?

"governments and private companies" certainly do not preclude committees. Quite to the contrary, in fact.

Disclosure: self-submission

Yes, and those damned Italians still refuse to switch to English too!

Very well said. I work on the Ramda (http://ramdajs.com/) FP JS library with the OP. Ramda is heavily invested in currying, and I don't yet have a clue how we'll deal with default parameters. At first guess, we'll simply have to explain that we can't curry such functions. Such a shame!

I think the concern is simple, really.

People are going to be told (rightly so) to use `let` instead of `var`. If they do so too mechanically, and their code is structured in certain ways, an expression which could never before throw an exception in Javascript, `typeof x`, now will do so.

This is not the end of the world, by any means. And it doesn't add an exception into unchanged code, but it still is a legitimate concern.

I've just started learning Clojure, and I haven't spent any time yet on Clojurescript.

I've read and commented on many of these posts (the latest one far too frequently! :-) ). Excellent stuff.

Hasn't that meme died yet? Well, I for one won't help keep it alive by pointing to the recently discovered talk video found here:....

I apologize. I really posted it on my site only as a convenience for myself, not to be published. I never really considered anything but projection at the time. Although I can view it on my fairly large phone, the experience is not great.

While I'm not upset that this has been posted here and has been garnering some attention, this talk wasn't designed for this kind of consumption. I have given this talk to two kinds of audiences:

* In a large corporate office with heterogeneous skill-sets among developers, but where almost all had some experience with Javascript.

* Javascript Users Groups

In each case, the idea was to make the case that FP could offer them practical advantages. The goal was definitely not to teach them FP or to suggest the best FP tool.

There are definitely better languages in which to do FP. But if for whatever reasons you're working in Javascript, I would suggest that a functional style could be useful.

That, I think, is working with the grain in Javascript. It's extremely difficult to do static checking in the language in any case, because in the language `foo.bar` is just syntactic sugar for `foo['bar']`. A FP approach in JS is by its very nature going to be different from one in something more strongly typed like Haskell; this is actually one of the easier differences to swallow.

The idea was just to show that, contrary to many people's expectations, OOP is not the only widely used paradigm in business programming.

No video was recorded on the occasions I gave the talk. I'd apologize, but actually, you should probably thank me. :-)

Very nice talk! I've used that formatting too, and while it can be very useful when running a presentation by yourself, it's not so nice for slides shared with someone who doesn't know it.

There is no video for this. I gave the talk several times to small groups, but never recorded it. Sorry. But you don't want to see my ugly mug, anyway.

One of the co-authors, yes. Mike Hurley and I have been developing the library for around 18 months. For the last six months, we've had many additional contributors, including some prolific ones, and David Chambers has recently joined the team.

For JS people wanting to learn FP, I'd recommend Allonge first. For FP people wanting to see how they can use JS in and FP manner, Fogus' Functional Javascript is a good book, and it's not a bad second book for the JS crowd.

(Author of that talk (and co-author of Ramda) here. Your perf test only times the parsing of the function -- not exactly fair.

The other side of this, though, is that you're now coupling your tests to the implementation of your solution and not the interface you want to present. You can't simply refactor your code to improve it; you will also have to find the failing tests, remove them, and write new ones for your new private functions, all while the public behavior of your system has remained working perfectly.

That's my primary reason for not testing private functions.

My alternative is simple, and has been stated elsewhere in the thread; if a function rises to the level of complexity of really needing its own tests, then it probably should be exposed as a public function somewhere in my system. Otherwise, I haven't factored the problem properly yet.

I'm not really a C# person, but from what I know of the language, although it has some lambdas and some other functional features especially around LINQ, functional programming really is against the grain of the language, and would not be easy to integrate into the same code.

The .NET platform of course has F#, which is a dedicated functional language. Some day I'll spend some time learning this one... perhaps.