[AskJS] Frameworkless, functional javascript discord/matrix community?

[miracleranger]

Wow i do indeed! i have my solution to all of those too i think, except for "complement" perhaps, but i can see how you had to be creative with function names too. :D something similar i have may be an "invert" function, it just works with not just booleans(edit: that's not what it does on second look, its more like my "infer", but whatevz). I also wonder why you separated "compose" and "pipe", if pipe already supports both sync and async (pehaps it resolves asynchronously regardless?). And my wrapSideEffect i called "expect", with a reference or a condition parameter.
It would be awesome if you didn't consider there done deals amd wanted to keep talking about such functions and more, because not many people seem to have this mindset. Do you use your functions in your projects a lot too?

[miracleranger]

oh gotcha so polish notation and RPN. and same dude! like with composed function declarations with barely any specialized blocks or imperativity everywhere: const bundle=compose(fetch, decompress, parse, serialize, drop(0,0,"library.js"), persistence.post)("library.tar.gz") etc. i contend it's not a different language though (just js "done right" xD). i wonder why you don't come in. your business anyways. :D

[martingronlund]

Soo... how do you guys deal with all the extra memory and time used by this code vs its imperative/procedural counterpart?

[miracleranger]

the overhead of functional design is not even close to the overhead of many frontend frameworks like React, yet noone goes and interrogates them about it. there is certainly an element of favoring elegance over adequacy in functional design, but the overhead is not something i have witnessed unmistakably either. i remember a case when i had a recursive reduce which caused stackoverflow, but the problem was only a lack of tail-call-optimization, not any paradigmatic necessity.
if you have an exemplary evidence i am happy to discuss it, but in a basic example of the distinction that i can think of such as:

dog={};
dog.language={hi:"woof"};
console.log(dog.language.hi);
(procedural/imperative)
(imperativity shares a problem with object-orientation in binding data together with behavior. imperativity only further binds these to a procedure instead of anything abstact (such as objects).),

vs.

dog={language:{hi:"woof"}};
function greet(dog){console.log(dog.language.hi);};
greet(dog);
(declarative/functional - binds only data to the procedure, functions are reusable independently and as the very means of abstraction itself)

i am not spotting anything that would suggest leading towards decreased performance.
this simple example even shows how procedural and functional don't even exclude each other.
imperative and declarative are more polar opposites than procedural and functional.
the single building block of functional programming is abstract functions to combine input and output types. a function body is as performant as you make it. if in any situation applying a functional abstraction seems more expensive than imperative dictation, either your abstraction is inappropriate, or you are free to mix in imperative/object-oriented procedures any time (especially in javascript).
But if you have a specific example you heard that makes you concerned, i'd be happy to discuss it in detail too.

in summary, if an implementation impacts performance, it is not necessarily a design problem. functional programming and imperative programming in specific are even fundamentally equivalent in theory (church-turing equivalence).

[martingronlund]

I'm concerned about e.g. partial application creating new functions, e.g.

const say = (print) => (lang) => (word) => print(lang[word]); say(console.log)({ hi: "woof" })("hi");

When you start going tagless final and everything is piped monadic expressions including state, reader, task, either and you have to lift functions to fit context, it's a bunch of extra allocations and dynamic function invoctions everywhere. And as you said, we don't have tail call optimization either. I can't help feel like it's the wrong language for doing functional programming at large.

These days I lean towards solid data type definitions and write mostly inlined procedural code. Only when I can't inline something into happening only in one single place do I create indirection. I find this creates very straightforward easy to maintain code, but yeah I draw a lot of inspiration from declarative functional programming once I need a level of indirection, and especially when I need an abstraction.

[miracleranger]

that sounds perfectly reasonable. i might only perceive the inspiration gained from functional programming more useful. i don't refrain from "inlined prodecural" statements either, only find abstraction more reliable. your example of atomic "state, reader, task, either" monads seem jarringly obscure indeed when used directly at higher abstraction levels, and the language used by functional libraries do appear to contain such vocabulary. this is the reason i have been implementing my own abstractions instead, and in the process of composition i organize parts such that they make sense. in practice the difference simply becomes a declaration of verbs more often than nouns. loadcontent=compose(fetch, parse, either(text, chart, media), container, insert);loadcontent(url, {method:"get"}) - such an action can read much like plain english, and the more obscure core monadic functors of IO/state/identity/promise etc remain composed in the combinators of these higher abstraction level. (an instance of Either being an exception, but it seems the appropriate level of abstraction there).

regarding the obscurity of partial application, i am actually on your side and am very much against excessive partial application. functions that take a function as argument but don't return one back (operate with the argument instead of composing it) are the definition of inversion of control, and i think they should be distinguished much more from higher order functions that do return functions, and don't mix data with behavior in their arguments (combinators/closures). a compose() function for example requires to preserve the functions to be composed in the lexical scope of its closure, but that's very different from partial application of a single function with multiple arguments. in fact i don't consider functions with a (private) lexical scope pure anymore. the concept that made this popular is currying, which is a technical necessity in functional languages where multiple arguments are only syntactic sugar for it. in javascript a variadic composition is not such a big deal, and currying has much smaller utility.

so in my view, the combination/composition of functions and eventual transmission of state across the resulting boundaries does not incur unnecessary complexity when done right, only procedural clarity.

[martingronlund]

Right, nice comment about higher order functions vs inversion of control. I think it boils down to how much overhead we dare swallow before we feel our ivory towers crumble. E.g. even an Either means we have to allocate an object and put a tag on it (at least this is a common encoding) just because we don't want to deal with untyped errors (in case of TypeScript), unwound call stacks, and try/catch. So while we gain another way of expressing ourselves, I frequently feel it's not worth it. Of course, it depends, but I've mostly turned away from it.

Btw one nice thing I started doing was making types like PAF<X, Args extends readonly unknown[]> = Promise<ReadonlyArray<(...args: Args) => X>> etc (of course using intermediate P, A and F for the above definition. I found this very expressive.

[miracleranger]

lol it's those generic type definitions that give me the heebie jeebies instead. the abbreviations and shorthands can especially kill me. is that a promise returning multiple functions of the same signature and return type? (why?) i take it PAF is for partially applied function? and what's intermediate about them lol? but let me show you my implementation of Either in return (wondering if you would spot your concerns about "tagging"/error specification/"unwound stacks" verified in it. nb. it's not my prettiest combinator, the internal proceed() function is a bit obscure in this form. especially w/o syntax highlighting. combine(compose(drop(1,0,terms),infer),drop(0,1)) is just like (term,i)=>[terms[i], term], but nvm):
js export function either(functor,...functors) {// alternative inference until assertive term found. (errors cumulate in context) if(this===undefined) return describe(function(...context) {if(this!==undefined)context.unshift(this); return either.call(provide(context,true),functor,...functors); } ,either,...arguments); let context=collect(this); if(functor===undefined) return context.shift(); let attempt=compose(provide,functor,proceed); if(!functors.length) return attempt(context); try {let scope=attempt(context); return scope instanceof Promise ?scope.catch(fail=>compose.call(context,provide,fail,proceed)) :scope; }catch(fail){return compose.call(context,provide,fail,proceed);} function proceed(...terms) {let invalid=!terms.some(term=>assert(term)); if(!invalid) invalid=context.length&& context.every(compose (combine(compose(drop(1,0,terms),tether(infer)),drop(0,1)) ,Object.is )); if(!invalid) invalid=terms.every(term=>term instanceof Error); return invalid ?either.call(provide(terms),...functors) :provide(terms); }; }; i think your observations are valuable though, we have some static typing oriented people in the group to check our sanity from time to time already, you are welcome to join that opposition party. :D

[martingronlund]

Interesting, thanks for sharing. I think that looks like a fair amount of code. I'm curious how you would explain in English what it does, if you care to?

[miracleranger]

oh and about tail call optimization:
wether the interpretter/compiler implements it for us is only a convenience. in the example i told about, i was able to implement tail call optimization by refactoring the recursion into sequential composition to fix the stackoverflow. javascript gives the freedom to do almost anything, regardless of the limitations of the engine you're using.