Need help? and Prelude vs Lambda

[cgarciae]

1st: Id like to contribute, so if you need any help (coding, documentation, tutorials, etc) don't hesitate.

2nd: I would like to use/help create a functional programming library that has these characteristics:

• True to Haskell.
• Continuously developed.
• Point-free style
• Will someday include more advance concepts like, functors, monoids, monads, lenses.
• Great documentation

Loop-recur has two libraries, I am guessing that since Lambda is more recent then the development of Prelude will halt, but that may not be the case. With which library should I partner with?

[DrBoolean]

Awesome!

My plan had been to make these libraries:

• A Basic ecmascript wrapper, but pure and point free (this one: lambdajs)
• A utility library for the serious (like lodash, but without variable args and more fp-ish. I'd created scoreunder as a start, but I'm not sure about it)
• An add-on that makes them play nice wiht monoids/monads/etc like you mentioned (per fantasy land spec).

I also have https://github.com/DrBoolean/pointfree-fantasy and https://github.com/DrBoolean/lenses which are available for typeclassy things. I'm currently working with @nodename to make them more accessible. Feel free to help wherever, we need all the help we can get as I'm basically alone in this stuff.

[cgarciae]

Brian,

If you create a wishlist or roadmap for each project, or at least for one of them, I can start filling in the gaps. For the moment I'll start by using LambdaJS.

[DrBoolean]

Hi @cgarciae

For sure!

I think that https://github.com/CrossEye/ramda is that utility lib I wanted. Lambda should work quite well with it too as being all the standard js functions. Perhaps we can help there.

The add-ons that might take a function like car and return an Option(a) instead of just the a.

[cgarciae]

@DrBoolean,

Ramda seems like a great initiative, they have a lot of the basic functionality you would expect. Rambda and Lambda overlap quite a bit, maintaining two similar libraries does not seems like a good idea. I'll gladly help anyone as long as the effort is well coordinated.

At least for LambdaJS, how about we first improve the documentation (I'll help), then, when some new feature is decided, document it first (at least briefly) so others (including myself) can code it for you.

I'll finish my autoType for the moment.

[DrBoolean]

I think that's a terrific idea about documenting it first.

autoType is a welcome addition to the base library. I'm interested in the experiment and what it might lead to though I don't want to make promises on it's usefulness since there's no static analysis. But I see that a class of confusing runtime type coercion errors can be eliminated with the extra effort there.

As for more functions...I can't see many more features except for when more functions make their way into ecmascript.

The mentality of this project is to be a slim wrapper around the built-in methods since utility libraries rarely include standard js functions like toUpperCase() for instance.

Ramda should pick up where this left off without having to define things like split() and join(). In that regard, that and other utility libs should work very well with this one. @crosseye may agree or disagree with that, not sure.

Either way, I suppose I'm thinking the next steps could be to create add-ons:

1 Enable fantasy: functions that might return null will return Option instead. I would like to do that for functions like match and others.

1. Enable extra basic helpers: functions like log, flip, constant, identity, and other base level functions that are fundamental, but don't cross the line into a utility lib.

Thanks for the direction and help!

[CrossEye]

Ramda is growing into a combination of all three of the libraries you talk about building, but quite haphazardly, and without a real plan.

There is a lot of overlap with lambdajs. But we haven't been as comprehensive, adding wrappers for these native functions as we needed them, never looking to see if we capture everything. And of course, its main goal is more in line with @DrBoolean 's second objective: an FPish JS library for the serious. We've been lately working on the algebraic types and will soon turn them into an extension to Ramda.

I expect that Ramda will be able to play very nicely with lambdajs with no issues at all. And it's definitely worth discussing whether it would be better to pull out the lamdajs--style native wrappers, as Ramda is growing to be a large-ish library. But I'd have to think hard before making that decision. If we could get the algebraic types working well with Ramda without losing the focus, it could well become a reasonably concise one-stop shopping for basic JS FP needs. And that would also be nice to have.

[DrBoolean]

If Ramda can do it all, then hell yeah!

This library should keep up to date with ecmascript and try to polyfill features around the corner. I certainly don't want to compete with or maintain a utility library.

Honestly, I'm not much of a library maintainer or creator. I'm just making things I need for the time being.

[CrossEye]

I don't think @buzzdecafe or I really set out to be library maintainers. And it's not at all clear if we'll be any good at it.

It was just an itch we had to scratch.

... and scratch some more.

... and a year later, it seems to be a library.

Although I didn't know it at the time, my cri de coeur was captured in a thread on an Underscore issue:

https://github.com/jashkenas/underscore/pull/1062#issuecomment-16191984

https://github.com/jashkenas/underscore/pull/1062#issuecomment-16216753

I'd already been playing with these things in a little playground, a predecessor to Ramda, but I finally realized that this was simply how I wanted to code from now on, as much as possible.

@buzzdecafe today showed me some two-year-old code that he'd a had a hand in, and how much cleaner it was when refactored this way. That's the point. If we can make our code clean and eminently readable, we've improved our own lives and those of the maintainers who come later.

Whether its Ramda, lambdajs, some combination, or something else entirely, I just want to be able to use this style of coding.

[DrBoolean]

You guys are doing fine work! I guess that's how all libraries start...

[haywoood]

As a fulltime javascript programmer messing with clojurescript / functional programming on the side, this stuff is really exciting to me. I came across @CrossEye 's currying article, which lead me to @DrBoolean 's presentation on underscore.js... which lead me to consume everything @DrBoolean has out there (the most entertaining speaker I've seen). This world is hard to break into, I'd love to help in this initiative and can start with creating docs for rambda.

Where else can I go to learn about functors / monads / monoids / point free etc? Is there a book that does a great job showing how these abstractions solve common real world problems. That is what I liked most about @DrBoolean 's talks, is they made these intimidating concepts super tangible / approachable.

[CrossEye]

@lsdafjklsd: I think a quick web search will teach well about points-free. The algebraic types are trickier to find good material. While it's almost the opposite of teaching about real-world problems, I would highly recommend the cartoonish Functors, Applicatives, And Monads In Pictures as a good introduction. And keep rewatching Brian's stuff! :-)

I learned most about them while trying to learn Haskell, which is one of those places they are just a natural way of thinking. I never quite got there, but even trying helped quite a bit.

[buzzdecafe]

thanks, that's exactly why I wanted to work on this lib, 'cuz I wanted to learn the material. :-) Now a year-plus later, and I realize I have a lot left to learn. But IMHO, the best way to learn this stuff is to implement it yourself. Then learn from your mistakes. This approach also motivates you to seek out the resources that address your particular needs.

[haywoood]

Thanks @CrossEye, that link does a great job cementing the concepts Brian touches on in his talks.