These are chat archives for ramda/ramda

23rd
Feb 2015
Pablo Rosales
@PabloRosales
Feb 23 2015 04:26

I don't think I can help with the Ramda library code itself but probably could help with tutorials, examples or sample code. I'm still learning FP but have experience writing tutorials and play code like:

https://github.com/PabloRosales/javascript-play/blob/master/playground/various/todo.js

https://github.com/PabloRosales/javascript-play/blob/master/playground/various/html.js

Ludwig Magnusson
@TheLudd
Feb 23 2015 09:23
Ramda people: Anyone here experienced in functional reactive programming?
Nathan
@terakilobyte
Feb 23 2015 09:40
@TheLudd perhaps maybe not of much help, but I found this a few days ago and have been glancing it over as I have time https://gist.github.com/staltz/868e7e9bc2a7b8c1f754
and apologies, no idea gitter rendered gists
Ludwig Magnusson
@TheLudd
Feb 23 2015 09:42
@terakilobyte Yes I have also read that =)
Now I wonder if anyone has used FRP..
Eero Saynatkari
@rue
Feb 23 2015 13:01
@TheLudd I’ve worked on a fairly large (F)RP project with baconjs
Ludwig Magnusson
@TheLudd
Feb 23 2015 13:16
@rue I am fairly new to the concept and have a hard time digesting it all but would you say that baconjs is implemented in a ramda way? (curriable functions with correct argument order, one function does one thing etc)
I am not even sure the question is applicable to FRP libraries =)
Eero Saynatkari
@rue
Feb 23 2015 13:32
Currying and such are perhaps a different level of abstraction… bacon and Rx mainly deal with (asynchronous) dataflow, so composition and combination. Pipelines of transformations and combinations thereof
Ludwig Magnusson
@TheLudd
Feb 23 2015 13:47

I had a quick look at the rxjs code base earlier today and I just go the feeling that there is very much code there. Which makes me wonder if they use FP concepts to their fullest. I was wondering how much code would be needed to write an FRP library if one were to use ramda as a base with basic functions such as map, chain...

This is comparable to many promise libraries which may contain thousands of lines of code. Much of the functionality could be provided by using Future monads along with ramda. I am wondering if the case is similar for FRP libraries...

Martin Algesten
@algesten
Feb 23 2015 13:57
I had an idea going from the promise angle towards FRP. The difference being that my “promise chains” can take more than one value and act more like event chains and that .then == .map – but then I’m trying to learn FP so it’s currently not a FP implementation at all. I struggle to see how to get there.
But I stand by the basic idea. I really don’t see why the user should need to chose between .flatMap and .map. Just resolve the future for me thank you very much.
Hardy Jones
@joneshf
Feb 23 2015 14:38
map and flatMap should have widely different behavior
Martin Algesten
@algesten
Feb 23 2015 14:45
well they do. for no reason i find interesting. anything you shove in .map can pretty much also go in .flatMap the opposite is not the case for event streams/observables.
this is why i find promises much better. .then .then .then. doesn’t matter whether it’s a vanilla value or a deferred.
rx could be the same. just make .map aware of observables/event streams and we could go .map .map .map
Ludwig Magnusson
@TheLudd
Feb 23 2015 15:00
@algesten I certanly don't think that map and flatMap (chain) should be the same. Those kind of "features" are what leads to what I called "not using FP concepts to their fullest". Ramda makes a big thing out of having each function do one thing and one thing only. This leads to easier imlementations, better re-usability and composability.
I have recently adopted the same thinking in my own business specific code and I have to say it pays of very well
Hardy Jones
@joneshf
Feb 23 2015 15:20
@algesten If you just have functions that do whatever named map and flatMap then it doesn't really matter what they do. But if you're trying to implement some Functor/Monad spec, then at least one of them is broken.
If you attempt to dispatch behavior based on what is passed in (or what comes out), you've broken any ability to reason in the large about what a program will do.
Scott Sauyet
@CrossEye
Feb 23 2015 23:53
@joneshf Ramda does do a sort of dynamic dispatch on types for some of its functions. For the most part, our functions are very simple, and map, for instance, accepts a function and a list, and does the obvious thing. But we do overload it so that if you pass in a non-list with a map method, then we delgate to that method. It's not perfect, but it does give us an FP integration with FantasyLand and other third-party libraries and specifications. I'd actually like to expand this further.