The presumption that functions abstracting over expressions (that may themselves contain function appications) IS SIMPLY NOT HOW HUMANS (well except mathematicians/logicians) normally themselves "compute" what they need to do... But it maybe possible to fix this, e.g. teach recursion rather than just comprehension! Just a thort, no criticisism intended or implied... ):-) Simples
Maybe this is a skill issue, but I just don't find mathematical proofs to be convincing even if they perfectly demonstrate a principal. For example, partial application. Take a method that takes a user, pw, db and sql query and just bind the first 3 args, leaving a function that just takes the sql. I think that makes much more sense to most devs with any amount of experience vs some leetcode adjacent 'lesson'.
imo functional programming tries to solve some problems that people don't really have in practice. like making partial application into language syntax warrants a lot of implicit allocations while a more procedural builder pattern, which does not require special syntax, does not. making monads into syntax is also a strange idea, rigid interface for errors as values doesn't make them better (imo makes them worse). another FP shortcoming is the idea that most errors are type errors: in my experience most severe errors arise either in floating point computations or in side effects ordering (memory management, data racing). imo the best idea that sort of came out of FP is lisp macros, which genuinely solves some annoying problems (eg. custom utility method generation, binary embedding and pre-computed values). another good idea was async/await monads, but it's primary use is simple UI/networking (for high performance/embedded, event polling makes more sense)
The presumption that functions abstracting over expressions (that may themselves contain function appications) IS SIMPLY NOT HOW HUMANS (well except mathematicians/logicians) normally themselves "compute" what they need to do... But it maybe possible to fix this, e.g. teach recursion rather than just comprehension! Just a thort, no criticisism intended or implied... ):-) Simples
Monads? why don't you just use clojure?
Maybe this is a skill issue, but I just don't find mathematical proofs to be convincing even if they perfectly demonstrate a principal.
For example, partial application. Take a method that takes a user, pw, db and sql query and just bind the first 3 args, leaving a function that just takes the sql. I think that makes much more sense to most devs with any amount of experience vs some leetcode adjacent 'lesson'.
Types make FP harder. Better start "soft", with Python, frozen data classes and much __call__ .
I agree, but I'd suggest switching Python or JavaScript to Clojure. Functional programming (FP) isn't just about the type system.
I like Jax's numerical abilities and therefore why FP with Python.
Types make everything EASIER.
@@edgeeffect Agreed. In practice we have a type, why not share that info w/the programmer?
imo functional programming tries to solve some problems that people don't really have in practice.
like making partial application into language syntax warrants a lot of implicit allocations while a more procedural builder pattern, which does not require special syntax, does not. making monads into syntax is also a strange idea, rigid interface for errors as values doesn't make them better (imo makes them worse). another FP shortcoming is the idea that most errors are type errors: in my experience most severe errors arise either in floating point computations or in side effects ordering (memory management, data racing).
imo the best idea that sort of came out of FP is lisp macros, which genuinely solves some annoying problems (eg. custom utility method generation, binary embedding and pre-computed values). another good idea was async/await monads, but it's primary use is simple UI/networking (for high performance/embedded, event polling makes more sense)
Its not hard at all.