the frisby videos were primarily fluent...

[faceyspacey]

but isn't the goal primarily pointfree lol?

My goal has been to drop the fluent style. But I'm only just beginning to level up to the fantasy land stage :)

Why is it fluent syntax something you may wanna use with fantasy land types and functions? Is it not possible to go completely point-free there?

i thought my fluent days of chaining functions were over. Enlighten me brotha!

[ccorcos]

So this is just an experiment, but it's something you couldn't do before! :)

It's definitely point free -- these two functions are equivalent:

fn = pipe(
  map(inc),
  filter(even)
  reduce(add, 0)
)

fn = pointfree
  .map(inc)
  .filter(even)
  .reduce(add, 0)

So it's basically just replacing pipe, but its composition which is what we wanted.

As I mentioned in the other thread about immutable.js and prototype methods, I've come to realize that aesthetics are pretty much the worst reason to make a technical decision. At the end of the day, we should be using the benefits that a language gives us. So fluent APIs are cool, but you don't have to use them which is also cool.

[faceyspacey]

I still don't understand why we wanna go back to a fluent interface. What goal are u trying to achieve? The fluent syntax or so U can do something else I'm not seeing? Why not just stick to compose or pipe? I'm here trying to switch to just a point free interface and ur going back to what I perceive the old way. Enlighten me

As far as aesthetics, I agree they can come second to other priorities such as immutable when considering tradeoffs, but if using immutable is the only thing holding one back from a consistent functional style, my current stance is to forgo immutable. For example, I rather my project consistently point free using either and maybe and as close to zero let assignments as possible or even consistently old fashioned lodash using let. I don't want other developers in my team confused by having to context-switch between seeing several different styles of coding. Not that I have developers other than me on my current project, but I will.

This past year did u end up using all this fantasy land stuff for ur entire project? Was it something ur project was able to even able to allow for? i.e. cuz it's not a brand new greenfield project? Or did u save this stuff just for personal experiments and only sprinkle it in here or there within ur work project? Here's the thing--we may be coming from different perspectives. I did quite a bit of studying a year ago on all this as well, but since then had to get practical and drop the fully functional fantasy. However just recently i re-picked up the torch. In between I've built a very large platform for a funded project I'm the sole developer of. I have a lot of control and can do whatever I want with the project. I've taken as long as I want so I can both make it the best and master a large number of tools i had never used before. I'm basically done but I plan to refactor the project one last time to switch to a fully functional style. Not just because functions are better for testing, but because of that future developers I will have to hire will wanna be using the latest and greatest, not legacy tools. I mention those 2 extremes to highlight that there are a lot of good reasons to be using truly functional programming...So at the beginning of the project, I had decided to use redux et al while focusing on stateless components and generally master the plethora of libraries I would have to use, while deciding against the added complexity of having to master ramda and fantasy. Perhaps if the articles and docs spread across the community were in a true functional style that would be different, but they weren't (and still aren't). That said, I'm now I'm ready for that and I see the clear benefits in my codebase, regardless of whether the community has fully caught on. My overall point is: we aren't talking theoretical experiments here. I have a major code-base (60k loc) tested and functioning well that I I'm very proud of, which will benefit from being written in truly functional style for many reasons, some of which I just mentioned; I have a vision clearer each day of how to do so, and it's ultimately not a big deal for me; and it will be far easier to do now pre-launch than after.

So you also may have been gone from the fantasy land world for a while. Sanctuary has turned into a really good project. There are tools for compatible futures like fluture. And as David Chambers mentioned there's a PR sanctuary has for structurally shared sets right now!: https://github.com/sanctuary-js/sanctuary-set/pull/1

At the end of the day, aesthetics can get beat out by other priorities but I don't think that's the case here. If immutablejs was a hard priority sure, but it's looking like we may be able to build structural sharing for sanctuary. The check above PR. Maybe this is something ur interested in doing with me. I'm not sure why the guy focused on OrderedSets (clearly a need of his project), but we need non-sets first and foremost. We should talk with that guy and figure out at the very least what the plan would be.

Either way, I'm hopeful that Sanctuary may one day get structural sharing given that PR and the interest by Sanctuary's creator. So I'm considering basing my work on sanctuary in the hope that in the future I may get structural sharing under the hood. I absolutely don't wanna be married to an old oop API because of immutable. And I definitely don't want a Frankenstein project, mixing lodash, ramda and immutable. Everywhere I look I wanna see ramda and sanctuary in use. No conversions back n forth between lodash. Feel me. It's doable, it's possible, especially since I have complete control of the project.

As for what u mentioned in the other thread, maybe immutable was built using prototypes, but there's no reason structural sharing can't be built using closures to guarantee a new object is returned while making use of linked lists and more under the hood. Mori and clojurescript do it. They just don't have a fully point free API, let alone are fantasy land compatible. I think u may be prematurely considering what immutable is doing only possible under an oop interface. But enlighten me if ur sure I'm wrong.

Also can you not do that range filter take lazily with a tranducer. I know range isn't lazy, but there must be an alternative you can plug in in that case?? In short the lazy checkbox seems to be checked as well. As for observables, I get the feeling that Flyd isn't as solid and maintained as rx, so that's why I've pinpointed structural sharing and observables as the main next frontiers for functional JS.

There's a business opportunity here Chet. A year ago u and I researched all this stuff as we leveled up out of the meteor community. But now the time is arriving for the truly functional stuff. And perhaps it will only arrive if someone steps up to the plate and builds it. But basically a properly branded ramda-complete package is highly marketable and the react community will eat it up in droves. The fragmentation should be solved my friend. It shouldn't be allowed to go on. Nobody uses anything but react. In other words, we're experiencing almost no fragmentation, and that's a good thing (because it leads to growth in the ecosystem). That Angular and Vue garbage is a small percentage of developers. 90% of the articles on our JS news sites are about react. That says something, I believe that does in fact translate to usage. Maybe in India u got droves of developers using angular 1 working 100 at a time for an Indian agency that works for a big American company, but that has no correlation to the audience I'm concerned with of real startup journeyman developers like you and me. What are you using? What are you really using at work (not side projects like Elmish or Reduxish)? React. Like I thought. We are all using react. Vue--forget that, it's for children. Anyway I digress. Everyone uses redux, react, jest, etc, and it's a good thing. It helps us focus on our apps and funnels the contribution of the ecosystem to other more specific areas that need assistance.

So, everywhere there is clear winners. There's an obvious stack of clear choices. And this is good for us. The reason it's good to be such a magpie developer and stick to these tools is cuz they are the most maintained and get the most contribution. Everybody knows it, it's basically a universal law. It can be a bad thing but overall it's far more good than bad. It let's us get to work and not suffer from analysis paralysis.

Next, the time is now for true functional programming. We just witnessed the build up. The react world--which as I just said is everybody that counts--is filled with developers that think they are functionally programming because they use stateless components, but in reality aren't close without things like either or maybe and of course a point free style which relies on it. These developers are craving to level up and do functional programming right. The only problem is that ramda essentially tricks you, just as using stateless function components did before. What I mean by that is: Ramda is a half measure; you need to take a full measure and go all the way to fantasy land or u have no recourse for dealing with a nullable/maybe or either in ur code. I know I'm not no master yet, but rest assured in a few weeks time I will have eliminated every damn let in my code and reduced my code to nothing but functions. It will be the closest thing to Haskell in JavaScript one can get. I understand the tools.

My point is it clearly is the one true way--the next evolution of how react JS apps should be written. It's the epitome of testability and ur test harness is the most important thing for production projects. Basically all my decisions revolve around that as the number one priority. Above aesthetics. It just happens that we can get both a consistent elegant functional aesthetic and highly testable code through the same means. Inputs and outputs and very little in between. Is that not the dream?

I think a correctly marketed singular toolset would be adopted overnight by the react crowd. Ramda et al has not done the business aspects right. That in part is because the tool chain isn't complete. But it's also not complete because a clear agreed upon all encompassing goal has not been set, which would allow for thinking of potentially cross cutting concerns from the ground up. The differing "opinions" you mentioned are the result of it being too late in a project to handle a goal the project never had in mind from the start. A rethink can allow all for this. But that said it's looking like it's actually not missing much. Structural sharing may be the lynchpin. Being able to say we offer what immutable has but with a modern truly functional interface would make everyone drop what they r doing and come use this. Couple that with properly marketing the package like Facebook does with their documentation sites, and boom, game over. The shit is not correct currently. Look at the folktale and sanctuary sites. No offense to their creators whatsoever, but their sites are absolute shit. It doesn't make me trust their package. Folktale doesn't have any real documentation. These are missed opportunities. Hell one could just package up folktale properly with thorough documentation with examples within a react context and people would eat it up. Right now people get to fantasy land and monads and turn back around. The main reason is cuz everything after ramda looks like complete trash and underdeveloped. It's potentially a bag full of problems. It's a wasteland. To make that leap takes really investing the time in understanding Haskell essentially, at which point u can begin to trust the homegrown personal projects in JS that don't look like much but are really forged by brilliant dedicated engineers who are getting it right.

I'm just sayin brotha, u may wanna rethink ur stance you mentioned that if u want some small thing just build that small thing yourself and put up with the fragmentation, put up or shut-up. Na my friend, there are people here all spinning their wheels doing the same thing but alone. At a certain point it's a waste of energies. With a little vision and collaboration we could put this app together for the good. Like I said that may just mean properly packaging folktale or sanctuary, i.e. helping them do it. The rest may fall into place from there. ..However, that's not even really my main point. My main point is just to blow FP up for real because for us to base our projects on FP we need the ecosystem that goes along with that.

U wrote that one great article on learning fp that has over 1000 likes, so U know exactly what I'm talking about. Here's the problem holmes there are very few examples showing fantasy land motherfuckin eithers and maybes within a react component or redux reducer or action creator. People just need to see that brotha. And lots of it. Article after article showing how to do it. I know u said they aren't dependent on each other. But that's not the point and never was my point. The point is people just need to see it done to feel confident they can use fantasy land and ramda in their react/redux project. There are so few examples of this. All there is, is standalone functional code examples. I personally know I'd have a lot more confidence going down this path if I was seeing it done. I'm basically forging my own path--that's how it feels for sure--but that doesn't need to be the case. Again, seeing functional examples unrelated to a react/redux project is not the same thing; it does not compare.

So if we lay the roadmap for how it's done, voila, we've potentially done half the battle--for as you say you mentioned, can basically piece together a bunch of this stuff. And, as I said I'm gonna write a 4 part series using ramda and fantasy land in these 4 places:

1) action creators 2) reducers 3) your connect calls, e.g. Map state to props 4) the components themselves

Maybe u wanna help me with that. U and I could be what inspires everyone to complete the journey to functional programming within JavaScript. We just need to fully show them how.

Why do we wanna do this? Because it will mean sanctuary's website doesn't look like amateur hour but rather a fully maintained complete project like lodash. There's nobody here bro. The population is growing, but we are still only maybe 10% the entire react population. Probably far less. We need em here. It's like Walking Dead lol--we need people to make a strong community. It will make it so the answer isn't "go build it ur damn self." I don't wanna do that, I got a business to run. I don't wanna build anything I don't have to. And it's my belief that that is the right mentality, at least for building businesses out of software. I love learning and expanding my skills and and building open source stuff to do so, but when I do build something open source I also want it to be something the community actually needs and will provide actual value. Not just be done by Facebook the next week even better. What I'm saying is building open source packages can be dangerous waste of time for real software businesses. It should only be pursued if the ecosystem has been fully assessed and the determination is that there is no other way.

So we are missing out on contribution. The community, I would call "interesting" and "dedicated," but not vibrant and flourishing. It's meant to happen though. It's its clear destiny. I'm surprised a year later it hasn't happened yet, but we've made incremental progress. It's time to take it up notch. It may just take tipping a few things in its favor, namely a properly marketed all-encompassing package or group of pages and campaign of medium articles and helpful documentation. A little bit of marketing, unification and documentation is all that's missing. As for structural sharing, it will come at a point--as either the cherry on top or the lynchpin that blows this all up. We should do this in free time rather than sit back and watch. We could make this go way way faster, and *as a result get the missing tools that we need which will be quickly built as a consequence of everyone building the axes to mine for gold in this sector.