@@fullfungo because prime and that guy in that video, both who have very little knowledge of fp or engineering in general, say extremely ridiculous things like "fp has no global state". Or even better you'll hear people say things like "fp has no side effects or state and you can't do anything". As op pointed out, you always can have a global state, the point is it's not mutable.
You see... Functional programmers hate transistors. The very idea that a component within your machine can change its state depending on external factors deeply frightens them.
Currying is not partial application) It is splitting function of multiple arguments into sequence of functions of 1 argument. This is currying, meaning we don't need functions with arity greater than 1 Btw, we also don't need variables, because we can have functions with 0 arity returning constant value
@@anon_y_mousse in the real world you must prove correctness too. But of course CRUD coders won't ever get anywhere close to applications that need this kind of rigour.
@@anon_y_mousse and reducing the implementation to pure lambda (or, even better, combinatory logic) is one of the easiest ways to prove things. Luckily, nothing stops you from doing it with even a pretty heavily imperative code. But as an intermediate representation, a curried CPS is one of the most powerful and easy to reason about forms. Your source language does not really have to support currying, it's all down to intermediate representations.
@@anon_y_mousse I mean, it becomes a stylistic choice at the end of the day. You give up varargs for seamless partial application. Otherwise the curried languages, Ocaml and Haskell being maybe the most famous, have both pretty decent performance and are pretty quick to develop in.
The funny thing about LINQ is that the actual language is pointless, but the generic manipulation functions it provides for any enumerable are suuuuuuper useful.
At 12 mins. It is currying and currying is not quite the same as partial application. Currying is where multi-argument functions are instead represented as a sequence of single argument functions that return a new single argument function until all arguments are provided, then the last one returns a value. So f(a,b): -> c would instead be f(a) -> (f(b) -> c).
Yeah, I would say the use of .bind is partial application as it allows for passing multiple initial arguments and returns a new function which wants the remainder arguments.
@@Tigregalis Currying (one argument at a time) allows you to partially apply a function, which makes things a little bit easier (especially when the language supports them). For example, the function "userIdEquals" from the video, if curried, it'd be called as "userIdEquals(userId)(receipt)". This means we can then use this function partially applied as: "receipts.filter(userIdEquals(userId))", which saves as the trouble of creating an intermediate function: "receipts.filter((r)=>userIdEquals(userId,r))". In languages like JS, curried functions can be cumbersome, because each arguments has to be wrapped in parentheses. But languages like Haskell don't have this trouble: you can call the function with as many arguments as you want -- give them all and you'll get the result; provide the first few, and you'll get a partially applied function that's waiting for the rest. Hope this helps!
@@DavidAguileraMoncusi that actually does help. first time in my life i've understood the benefit, specifically using it to avoid an intermediate function
Saying functional programming “has no state” is like saying math has no numbers. There’s obvious state, you just get rid of as much mutation of state as you can. If there was no state you would have no program 😂. Like, I understand the word isn’t being used to mean EXACTLY that, but still.
For clarification on "curring" vs "partial application". They are related but distinct. While curring _yields_ a new function that implicitly _supports_ partial application, the return value of `curry(f)` is not a partially applied function. No arguments were provided yet.
also currying is a stricter subset than partial application. as currying is typically understood for use w/LC or rather single arguments in general rather than splitting the input domain N times, which currying does for N arguments
More languages than just haskell (and other 'pure' functional languages) should implement tail recursion optimization. That is a strategy that does not create a stack item for a function call when it is the last thing in the function, and is a recursive call to itself. Java for instance does not do that and the call stack for the recursion becomes too large after a few thousand. So implementing a loop the recursive way leads to trouble.
Tail call recursion optimization was one of the features that was promised in ES6 in JavaScript. But sadly only Safari implemented it... Which is surprising to say the least. Chrome, Firefox and others never really implemented it.
For curiosity about tips (16:40), in Brazil it is common that restaurants auto calculate a 10% tip. You can either pay or not pay it, but basically nobody will tip a different value
Its cool that functional programming is explained with the usecase of map, filter, sort and slice but looking at what is being done at 21:20 it feels to me like all of this should have been done on a database level in the first place. map => join | filter => where | sort => order by | slice => limit Then you don't need to fiddle around in JS and waste a bunch of time and memory doing stuff in JS which should have been done in SQL (or an appropriately designed API)
Yep! Database queries are one of my favourite examples of functional programming. I'd argue you need to be a bit careful, as they can be hard to test/verify and SQL is honestly not that great and has pretty poor IDE support, but you can get a lot done before you ever send the data out over the network.
There is state, it's just explicitly passed around instead of hidden by class variables and global mutables. I wrote this on the original, but the issue with using functional techniques in a language like JavaScript is that A) The language doesn't have tail-call optimization and therefore recursion blows up the call stack B) Sometimes, functional languages are able to support loop fusion where, in the pipeline example, all the steps happen in a single loop instead of iterating multiple times.
fwiw re: B) - you can easily build transducers in JS (or use a library), which allows you to write declarative transformations but avoid a bunch of additional loops/instances. To me one of thing I hate about FP with JS is that there isn't currying by default (again, you can supplement with libs), which makes the whole thing feel super un-ergonomic. It makes composition harder and less intuitive, which makes small, pure functions feel less valuable. FP techniques synergize in a really satisfying way, so when you have to do all this extra leg work to enact them, of course it feels like going all in on FP is a pain.
@@mixed_nuts then it doesn't. A standard without an implementation is like saying I have a PhD from MIT because I can see their outline of their PhD program online.
I am doing a lot of DSP and data processing, and I found myself drawn to the style of creating some kind of "pipeline" since it makes it really easy to understand on a high level what kind of steps a given analysis is going through (much more so than, say, a nested loop with all the interesting stuff going on in the innermost loop). Since in Rust / C++, I find myself falling back to good old procedural idioms quite often out of habit, I started to use some F# for smaller scripts and recently Advent of Code, forcing myself to embrace the functional style. On the one hand, the code turns out to be quite readable, composing functions feels good, and I have less issues bikeshedding how to organize code compared to an object oriented approach, where there are always multiple ways to split up functionality into different classes, and usually the first choice turns out to be flawed some time down the road. On the other hand, I find that the FP style has more "surface area" to learn (knowing as many algorithms / operations available for a given type of container is critical), I find it hard to reason about the performance of certain steps (compared to a procedural style where working with contiguous memory and avoiding copies already gets you quite far, and it's usually obvious when copies happen), and, most critically, the debugger seems really useless. So I'm torn. It seems a bit like sugar, some FP style in some places (mainly high-level "business logic"?) is awesome, but in the more involved interna of a codebase, I find that keeping things procedural may actually be better to stay on top of what's going on, at least based on the debugging experience I had so far. Ofc it might just be a skill issue at this point.
I agree that functional programmers are bad marketers because, somehow, they make this guy think about FP as “There Shall Be No State”. This is hilarious 😂
Prime is the best example of somebody who has no idea what he's talking about but read some very surface level things on the topic and now talks about it with authority. That's not FP's problem, it's the problem of soydevs thinking they know everything without actually studying.
Seems to me like it's more about reducing the use of state and trying to make sure its impacts are known when it does get used. I'm just starting to look into it but those are the benefits I'm seeing right out of the gate.
@@ragnarok7976 sortve but really the idea is to avoid shared mutable state so that you can achieve pure functions, which are functions that are: Total Deterministic Side-effect free This allows those functions to be referentially transparent so they can be optimized and memoized even by the compiler. This also let's to do property based tests instead of unit tests which test what these functions actually "are" instead of testing some example observations. And it essentially makes 90% of your code nearly error free so you can go focus on only the things that can cause issues instead of running up and down your code with a debugger
Yes of course there is state..it is just immutable. So once you alter it, you just get a new copy. The copy is smart though, nothing like Rust's "Clone"
I'm a hobbyist programmer and I've only got experience working with procedural and object oriented programming. This stuff is mindboggling to me. I can clearly see that it works, but I do not understand how the heck it does. It's like I've been building houses using nails and screws all my life, and then someone shows up and tells me about wood joining and shows me that you can build a whole house without any screws or nails. I can clearly see that you put a house together, but I have no idea why it's not falling apart.
IMHO, nothing beats Scott Wlaschin's conference lectures on "Domain Modeling Made Functional" and "Functional Design Patterns" for introducing functional programming in a really intuitive way.
@@mciejgda88 not yet unfortunately, but i have almost read all of the articles from Scott's blog. I want to do as an experiment the domain modelling with F# thing in a real context with domain experts
The sad thing is all these coding youtubers only understand surface level stuff about FP. It's not actually all about pure functions and such. It's all about explicitly modelling computation.
@llIlllIIlIIlllIlllIlIt has been my observation that almost all coding youtubers (who are not overtly obsessed with FP) think they understand FP after only learning: Pure functions, no side effects, const variables, recursion. I mean those are all features of FP for sure, but that is not the pull of FP. In fact many imperative languages have these features. In fact us functional programmers go out of our way to explicitly put state into our code! FP is NOT about avoiding state. The magic of FP is that a good FP language (such as Haskell) allows you to explicitly model both data and computation flow in concise and well-defined ways. I won't go into the details here, but I have heard the phrase "monads are a programmable semicolon". IMO this is rather accurate. Imagine you were writing a function in your favorite C-syntax language and you could program implicit code specific for that given function to be ran in between every expression. It's rather powerful stuff.
And the worst part in case of errors the call stack is completely useless without first (which started the whole chain and holds initial value) and the last (the reason for the error) calls.
@@fullfungo it's infinitely easier to debug and you can easily Tell when you run out of memory in a loop. because you get a Seg Fault or malloc can't get any new memory instead of Stack Overflow with the stack trace pointing to one function. Using the program stack like this is just not a good idea.
@@fullfungo And this is one reason why I love RAII, though, as the_mandrill suggested, it should probably just be called Scope-Bound Resource Management (SBRM)
Learning Haskell as basically my first language (C++ was my actual first, but I quickly grew disinterested in the language). Has caused quite an interesting learning journey.
🎯 Key Takeaways for quick navigation: 00:00 🎉 *The video starts with a discussion about functional programming and the term "functional bros."* 02:10 💡 *Functional programming emphasizes pure functions without side effects, making it elegant and predictable.* 03:44 🧐 *Functional programming eliminates mutable state and relies on functions to compose and manipulate data.* 06:04 🔄 *Recursion is discussed as a key technique in functional programming for tasks like looping.* 09:30 🤔 *The video explores currying and partial application as functional programming techniques.* 11:35 🧩 *Lambda functions are introduced as a way to create functions that carry extra data for specific conditions.* 14:58 🤓 *Functional programming methods like `filter`, `map`, and `take` are used to process data in a declarative and concise way.* 18:10 🔄 *The video demonstrates how to apply functional programming techniques to solve a problem involving restaurant receipts.* 20:18 📺 *Focus on being actively engaged when watching videos, especially if not live.* 21:26 💡 *Functional programming allows for elegant data pipelines, which are common in many programming tasks.* 23:10 🧠 *The best parts of functional programming have been incorporated into popular languages.* 24:05 🛡️ *Reducing state and using data pipelines can bring significant benefits without excessive restrictiveness.* 24:44 🚀 *Exploring multi-threading and parallelism in Rust can lead to improvements in performance.*
Could it also be the content he throws at RUclips nowadays? Reaction video after reaction video, zero original content, just him hitting space on RUclips videos every second. Like idk, dude’s free to do whatever he wants and he obviously prefers Twitch but it feels pointless to sub to him now. Such a stark contrast to the channel he’s reacting to…
Had Phil Wadler as a professor in first year Soft. Eng. and that was hands down the best, most interesting and fun course. Though everybody else seemed to hate it xD
@@mitchhudson3972 yes every single assembly-level instruction is simple by itself, but once you start combining them to actually do something noteworthy, there is a point where the simple instructions start becoming exponentially more difficult to understand than the bs, or abstractions as they're more commonly called.
@ultru3525 in no universe will a for loop be more complex or difficult to understand than a bunch of recursion. With performance at best it just ends up being the same thing and at worst blows up your stack
@@mitchhudson3972 Sure, if you ignore the entire history of formal mathematics. Why do you think ancient mathematicians defined the Fibonacci sequence using recursion instead of a for-loop? Because recursion is the mathematical approach which is modelled by human reasoning. For-loops OTOH only came into existence when we needed to translate our reasoning into something a smarter-than-average rock can work with.
Haskell Curry realized that all you need is functions with one argument, as long as you can return a function. (Moses Schoenfinkel realized it first, but you and the guy with the video would REALLY complain if you had to talk about schoenfinkeling a function.) Haskell notation is designed to make it easy to schoen...uh, curry.
Currying is taking a function that has an arity greater than 1 (n) into a group of single arity functions whose members total n. Currying will result in high order functions (but not all HOFs will require you to curry, a function with a callback for instance, can be a high order function but it is not a curry) since high order functions take a function as an argument or return a function
And here I thought he just misspelled parity... I think at the end of the day most people would rather just learn a programming language than relearn English to learn a programming style then learn a programming language to implement it in. That's probably why this stuff hasn't gained more traction.
@@D4ngeresque I can appreciate hyperbole but I think comparing learning a couple new words (which are long standing English words) to relearning English is a bit too hyperbolic for me. I thought the same thing when I first saw "arity" but I took two seconds to google it and I now I can understand any text that uses the term. 2 seconds of investment; lifetime of value. I'd also add that you will need new language for all new things you learn so this really isn't an inherent issue to FP. I'm not saying you need to learn it either just don't avoid it for arbitrary reasons like being novel to you.
No. Pure functional programming languages like "clean programming language" for example model the whole universe with no state changes (including the computer memory) - then how you run interactive programs is that both your functional program can create a new universe - then the user as a function also can create a new universe from that - then functions run over it again. You need no state this is just recursion with a completely new universe being born all the times haha. Then haskell has the other approach with monads - but I find the "Clean" approach to be theoretically cleaner indeed. Fun-fact: Clean and Haskell are nearly fully compatibly even to the syntax level and you could not tell which code is from which - despite the therory and inner workings being so different...
@@arkeynserhayn8370 What I describe is the SEMANTICS of said languages so real implementations DO totally abide that in both circumstances. Just of course - as every sensible compiler - they optimize whatever they can and whenever possible given the given circumstances when the compiler is good. Still this is the programming model that you see when you are coding. There are "not purely" functional languages, where the semantics enable more, but in case of Clean and Haskell the semantics are purely functional.
The beauty of FP is, it basically takes tons of boiler plate and turns it into many shorthands. map (+5) xs feels so readable. this is of course an incredibly basic example. Instead of having to learn/debug your coworker's boilerplate shorthand, you can just learn FP boilerplate shorthand upfront. Maybe that FP boilerplate shorthand isn't as readable as plain English. But it reduces your coworkers' boilerplate shorthand by an order of magnitude, which is almost always a win.
21:00 The standard javascript library is the problem here. These functions SHOULD accept and return iterators (where you can dump it back into an array at the end if you need to). Still, you don't really need to break up the code to debug this though. You could start by stepping through the "map", then remove that breakpoint if you are satisfied there are no bugs there, skip ahead to "filter" and so on, until you find a bug.
You don't step through the functional code with the debugger, you test the functional code with different inputs to see where it doesn't do what you wanted it to. Then you break it apart into its smaller parts to understand where you've gone wrong
Indeed! Step-by-step debugging doesn't make sense anywhere except in code executed step-by-step. For simple, pure functions you only want to see what various parts of the call tree evaluate to. More complex types would maybe warrant specialized debuggers tho.
Typical all-paradigms-are-good take. Software is remarkable among fields of engineering (civil, mechanical, electrical, etc.) in that nothing ever gets taken out. Legacy code and recalcitrance keep every approach in-play along with their defenders, the good and the bad.
Functional programming is like Sigmund Freud's work -- a handful of great ideas that are widely applicable; but if you start digging too deep, it plummets into insanity.
It's complete nonsense too since that's not how things work and the original video is mistaken on at least half of what they're saying. This is why FP gatekeeping hard is good, it keeps these soydevs out
The great thing about functional programming is that I spend less time debugging multiple issues because I have to spend more time debugging each individual issue.
FP might one day be better than procedural / OOP if colleges start teaching its concept, so the next junior seeing my (beautifully :) written functional code doesn't curse me behind my back
You could consider "bind" to be syntactic sugar (or salt in this case) for currying. Essentially you are just adding the scope of the parent function and using it within the child function. This would be exactly the same result as simply just calling the child function inside of the parent function. Using bind is also less readable and I would argue introduces the same state-like problems you are trying to avoid. That being the functions being bound together is a state in itself but that state can be set up outside the scope of the function meaning there are cases where your function could fail and you'd have no idea just by looking at the function itself, rather you'd have to probe the context of the state around the function. At that point you might as well just use the state and keep the readability. Save you typing bind constantly too 😂
I’ve just started a programming course and I’m currently making my first JavaScript project. I was worried that I didn’t have any kind of “loop” in my code. I just have functions that call each other when certain criteria is met. The first 7 mins of this video made me feel a LOT better.. am I becoming functional bro?? 😂
18:10 You can both call array.sort() to just sort it, but you can also use it in a dot-chain of functions. I call that a win. At least as long as it doesn't actually clone the thing.
Full agree on the debugging part, exactly that, remove the return at the beginning, make multiple variables and then return it is also how I debug those things.
this is not the only way (breaking statements saing stuff into variables) to debug such code (20:40 when it has pipeline of map().filter().sort().slice()), can make a function that takes an array and returns it back (while also sending the array to console.log), and just temporary wrap the portion of pipeline with that function
i really like constexpr functions. like, you reduce state by having something where the output depends only on all inputs (even for constexpr classes, since `this` is a hidden parameter) and you don't have to deal with any of the bullshit with "pure" functional programming such as not being able to mutate local variables leading to things being overly complex and leading programmers to iterate and exhaust stack space.
currying is turning f(a, b, c) into g(a)(b)(c). partial application is where you create a new function with some argument values pre-set (partially applied).
@@georgehelyar Using is second to *reasoning* about the concepts. Without the language and definitions of concepts, how do you convey the meaning and semantics?
People use these things all the time without knowing what they are called though. It's just that the names are scary to people who have not heard them before, and that makes people think FP isn't for them.
I think people missed his point. He was not advocating for architecture-wide implementation of functional programming. It's simply a tool to be used. At my company we have a mix in our codebase. We like the Functional Core/Imperative shell pattern. Sometimes. If it gets in the way, we don't use it. But when it doesn't get in the way it's really nice because you can write these complicated business functions that take input and produce output. They don't call into the database or anything else for that matter. They don't have state. This makes them very easy to unit test because you don't have to do any kind of mocking. To test it, you just call it with different inputs and test the outputs.
In Haskell, It’s not just because it’s pretty or because it’s elegant or because it’s easier to reason about once you understand it, it’s useful for making increasingly complex programs require less code to write (even under the hood) through the use of generalizations of functions on types and type classes. It’s the low cost or cost free abstractions that allow you to have automatic optimizations that the compiler can now prove using the type system that it wouldn’t be able to make without it. In some cases this even allows optimizations you wouldn’t be able to get writing well written C unless you used inline assembly. It literally lets you write more performant programs using less total code asymptotically as you scale. And imo it’s more pleasant to write. And for the record, I love C and assembly. Calling C and assembly in Haskell when generalizations don’t yet exist to get you comparable performance for that specific function is practically standard practice for a Haskell dev when performance matters.
@@tuchapoltr He's wrong about nearly everything. He's a pseudointellectual soydev who thinks he has it all figured out and hides behind animations and giant piles of his terrible code to justify anything he wants to say, which he always says with an authoritative tone like he knows the answers to things that literal geniuses still debate.
Single or, at most, double loop comprehensions are great! Any deeper and they are an interesting challenge to create but shouldn't be used in production
11:46 Yeah, it is currying, basically if you have a function that does the sum between 2 numbers, gets a number as input, that's the function that does the sum of x + 5 (assuming you passed 5 as first argument) and you specialize the function x + y with y = 5. If you pass both of them in this way (x)(y), you are actually changing both of the x and y. TECHNICALLY what he did it's called closure in python world, but it's the same principle of currying
Whenever I look at the example at 7 min I keep thinking that if there should be no state, we either have to keep copying variables, wasting a ton of clock cycles, or we do actually have the state somewhere (maybe hidden) - cause we need a reference to the array. In any case I keep thinking there must be an easier way to do the same thing.
There's only one thing I agree with in this video: functional programmers are bad at marketing. This video is a great example of that. Boom, recursion.
Funny thing, if you have account with European bank, you are not allowed to let the card out of your sight of you or authorized person when paying with CC/debit (one of those things people don't read when they sign papers) so things like this is less likely to happen.
The confusion behind currying is probably with the nomenclature, currying is the process of turning this type signature: f :: (Int, Int) -> Int Into this type signature: f :: Int -> Int -> Int
The problem with category theory is that it's so abstract and general that there's some construct in category theory that will describe what you're doing. Except, naming things for the sake of naming them gives you nothing useful.
@@isodoubIet Knowing the basics of CT can lead you to seeing your programming problems differently. I recently wanted an embedded DSL for Logic Programming (with cut!) in Python, and I implemented it in Python with a triple-barrelled continuation monad. I'm very pleased with the simplicity of the code. I ported it to C# in one evening without much prior knowledge in that language. The structure of the code made it also very easy to add tail call elimination via thunks and a trampoline.
"All partial application is currying" is false by definition. Also currying is never partial application. The only thing you wrote that is correct is saying that they are related.
@@thomassynths Currying is a function that returns a function. Partial application is a function that returns a function with some of the arguments fixed. I stand by what i wrote.
@@khatdubell Currying is a function that takes in a function with tuple arguments and turns a new function that takes unary arguments and returns successive functions. Partial application merely returns a new function with some argument values already provided. These are different things. `curry(f)` returns a function that has nothing partially applied it it. Currying is one mechanism to facilitate partial application, but it is not the only one. Mathematically, currying `(a, b)->c` is `a->(b->c)`. Notice that no partial application has yet been performed, yet the currying operation is completed once the `a->(b->c)` value is returned. Mathematically, partially applying `a` to `(a,b)->c` yields `b->c`. Notice that `patial_apply(f,a)` takes more than just the function as an input, unlike `curry`
@@thomassynths You're right of course but I'm curious why this is the topic you seem to be concerned with when nearly half of this video is incorrect information. Prime has absolutely no idea what he's talking about and the guy he's reacting to is even worse
@@AndreiGeorgescu-j9phe and other soydevs always love sh*tting on functional programming and when asked why? They don't know sh*t on how to elaborate on functional programming
I remember getting owned by reverse so hard that I memory holed what it was that I did wrong, ensuring I will eventually get owned by it again in the exact same way at some point
21:34 he claims breaking the pipeline apart is "the worse" because you can't debug one item at a time. He is strongly assuming the first item in in the iterated version would tell him what was wrong, often you have to look at the entire output to see the issue.
During uni a friend of mine who was way more advanced at coding than me showed me his self written OS's and also when he did functional programming. To this day I don't get it and I feel like ignorance is bliss.
Since using Julia I will never go back to any non functional language. No side effects is a god given right. (I’m a theoretical physicist so probably it comes naturally to me)
Yeah running map() before filter() is especially triggering, as it will run n transforms, where n is the array length, regardless of output of filter().
I don't know if it was code aesthetics intent, but seeing a simple for loop turn into that monstrosity was enough to convince me to never touch functional programming. I just want to make the thing do the thing D:
Monstrosity? You mean, "something I'm not familiar with and I'm not really willing to learn"? Even if you don't care about more advanced languages you should learn recursion, it's just the correct choice for certain algorithms.
He's got little to no idea what he's doing, frankly just like Prime. You really shouldn't be listening to these soydev youtubers and go study from an actual book/course. If you want recommendations on FP I can provide them
@@digitalspecter He's actually right though, that guy has no idea how to write FP and in actual FP code you're not writing explicit iterators...you're using implicit or internal iterators
IMHO opinion, not having state is reasonable. But carrying that over to, you cant have for loops because the iteration counter is a variable that is written to and is therefore state, is stupid. Having no state, IMHO, means that the same input will result in the same output, every time. That is it. There can be internal "states" as long as the same input will result in the same output.
I would also recommend ignoring that explanation. Local mutations and state are possible in functional languages, but you don't need them for a for loop. e.g. a local Ref can be used to achieve this in Scala, OCaml, and even Haskell Using map, filter, flatmap are preferred as you do not need to write the looping implementation where mistakes could be made, it's easier to reason about (likewise using recursion), and can take advantage of any optimisations Last time I looked map in Scala was just a classic loop in Java under the hood 😅 Trust me, 90% of the stuff I read about FP (like in JS) is not really FP. It's procedural code using FP concepts -- and there's nothing wrong with that at all
Your closing comment made me cry a little bit inside. Concurrency in Rust is hard. It took me a couple months to get used to the borrow checker when learning. Now I have a process that I’m trying to speed up with the various concurrency tricks, but nothing actually works. Everything compiles and runs and gives correct results, but everything with concurrency makes things 5 to 50 times slower. Rayon, channels, etc. nothing works. I feel like I did back before I was able to think of the borrow checker as something to work with instead of something to fight with. This is one thing that the rust book actually makes look easy, but that implementing in a real world problem gets hard.
It might be a better exercise to first implement as non blocking pool threads to discover if the problem is congruent to coroutines. I find it’s easier to move to coroutines from that.
It is false that recursion is a fancier form of iteration, because there are some functions that are only recursive and can’t be turned into an iterative. Look up the Ackermann function to see one that can only be recursive.
Every function is a pure function. You just have to conceptualize it as the new state being part of the output and the current state as being part of the input.
I find that if you code without prejudice sometimes you find yourself passing functions into other functions calling functions from inside themselves, creating pure functions and so on, theres a right situation for these things and many wrong ones
Yes, at the end of the day we all have shared global state. We call it “the database”
A database is a persistent data structure, aka immutable with history
@@AndreiGeorgescu-j9p datomic is, most databases are not.
Is this like an argument to something?
I don’t see how this is relevant.
@@fullfungo because prime and that guy in that video, both who have very little knowledge of fp or engineering in general, say extremely ridiculous things like "fp has no global state". Or even better you'll hear people say things like "fp has no side effects or state and you can't do anything".
As op pointed out, you always can have a global state, the point is it's not mutable.
functional databases I guess can work lol, always making copies
You see... Functional programmers hate transistors. The very idea that a component within your machine can change its state depending on external factors deeply frightens them.
Transistors are functional though.
Well not after I set my cpu voltage to 2v
the transistor is a function the leads are inputs
@@matt.loupe. deluded. like actually never understood how transistors are all different depending on manufacturing and environment.
There is only one solution. If there is ambiguity then that means you have not researched the problem correctly or completely.
“There shall be no state”
Didn’t know Marx wrote programming languages too, man that guy gets around
isnt that anarchy tho? Marxism loves bug government
😂😂😂
Cant forget the classics like "The conquest of Functions"
More like the subhuman Chomsky.
It would not be Marx, more like an actual anarchist like Spooner.
Currying is not partial application) It is splitting function of multiple arguments into sequence of functions of 1 argument. This is currying, meaning we don't need functions with arity greater than 1
Btw, we also don't need variables, because we can have functions with 0 arity returning constant value
Which is incredibly helpful if you're in academia and need to prove things, because your proofs become easier since it's all just unary functions.
@@anon_y_mousse
Just memoize the results and you can reuse them! :p
@@anon_y_mousse in the real world you must prove correctness too. But of course CRUD coders won't ever get anywhere close to applications that need this kind of rigour.
@@anon_y_mousse and reducing the implementation to pure lambda (or, even better, combinatory logic) is one of the easiest ways to prove things. Luckily, nothing stops you from doing it with even a pretty heavily imperative code. But as an intermediate representation, a curried CPS is one of the most powerful and easy to reason about forms. Your source language does not really have to support currying, it's all down to intermediate representations.
@@anon_y_mousse I mean, it becomes a stylistic choice at the end of the day. You give up varargs for seamless partial application. Otherwise the curried languages, Ocaml and Haskell being maybe the most famous, have both pretty decent performance and are pretty quick to develop in.
*Pets LINQ*, "See they like you, they just don't know you!"
linq is poggers
You know Erik Meijer distanced himself from functional programming including LINQ recently?
@portal_narlish3710 so what? Cat Stevens distanced himself from his old songs too, yet they're still amazing
LINQ makes my .NET job significantly more enjoyable
The funny thing about LINQ is that the actual language is pointless, but the generic manipulation functions it provides for any enumerable are suuuuuuper useful.
At 12 mins. It is currying and currying is not quite the same as partial application. Currying is where multi-argument functions are instead represented as a sequence of single argument functions that return a new single argument function until all arguments are provided, then the last one returns a value.
So f(a,b): -> c would instead be
f(a) -> (f(b) -> c).
Yeah, I would say the use of .bind is partial application as it allows for passing multiple initial arguments and returns a new function which wants the remainder arguments.
yep, thats why haskell type signatures look like:
foo :: a -> b -> a
and not something like
foo :: a, b -> a
@Satook why is this good though?
@@Tigregalis Currying (one argument at a time) allows you to partially apply a function, which makes things a little bit easier (especially when the language supports them). For example, the function "userIdEquals" from the video, if curried, it'd be called as "userIdEquals(userId)(receipt)". This means we can then use this function partially applied as: "receipts.filter(userIdEquals(userId))", which saves as the trouble of creating an intermediate function: "receipts.filter((r)=>userIdEquals(userId,r))".
In languages like JS, curried functions can be cumbersome, because each arguments has to be wrapped in parentheses. But languages like Haskell don't have this trouble: you can call the function with as many arguments as you want -- give them all and you'll get the result; provide the first few, and you'll get a partially applied function that's waiting for the rest.
Hope this helps!
@@DavidAguileraMoncusi that actually does help. first time in my life i've understood the benefit, specifically using it to avoid an intermediate function
Saying functional programming “has no state” is like saying math has no numbers. There’s obvious state, you just get rid of as much mutation of state as you can. If there was no state you would have no program 😂. Like, I understand the word isn’t being used to mean EXACTLY that, but still.
For clarification on "curring" vs "partial application". They are related but distinct. While curring _yields_ a new function that implicitly _supports_ partial application, the return value of `curry(f)` is not a partially applied function. No arguments were provided yet.
@@samuraijosh1595 That's not true. It's possible to partially apply arguments to a function without currying the function prior.
a shorthand for currying identification could be if you can do foo()()
also currying is a stricter subset than partial application. as currying is typically understood for use w/LC or rather single arguments in general rather than splitting the input domain N times, which currying does for N arguments
@@shampoablewell thass wild, i do that in JS all the time juss cause it’s more intuitive to write if returning a function is what i’m doing. neat.
More languages than just haskell (and other 'pure' functional languages) should implement tail recursion optimization. That is a strategy that does not create a stack item for a function call when it is the last thing in the function, and is a recursive call to itself.
Java for instance does not do that and the call stack for the recursion becomes too large after a few thousand. So implementing a loop the recursive way leads to trouble.
Tail call recursion optimization was one of the features that was promised in ES6 in JavaScript.
But sadly only Safari implemented it... Which is surprising to say the least. Chrome, Firefox and others never really implemented it.
Kotlin has a tailrec keyword that enforces a function is tail recursive and performs this optimization
@@awesomedavid2012 cool! Didn't know that. Maybe Java will get it in a dozen years too then 🤣
Many compiled languages already do this optimisation, though it usually isn't 100% guaranteed (as with a lot of other optimsation techniques)
F yes, tail call best call :)
This video was a classic bait and switch. The initial French kiss, followed by repeated kicks in the stomach.
Better than repeated sack taps
For curiosity about tips (16:40), in Brazil it is common that restaurants auto calculate a 10% tip. You can either pay or not pay it, but basically nobody will tip a different value
Eu nunca vi um restaurante cobrar gorjeta aqui kkkkk
É o 10% burrão @@henriqueprado9205
Its cool that functional programming is explained with the usecase of map, filter, sort and slice but looking at what is being done at 21:20 it feels to me like all of this should have been done on a database level in the first place. map => join | filter => where | sort => order by | slice => limit
Then you don't need to fiddle around in JS and waste a bunch of time and memory doing stuff in JS which should have been done in SQL (or an appropriately designed API)
Yep! Database queries are one of my favourite examples of functional programming. I'd argue you need to be a bit careful, as they can be hard to test/verify and SQL is honestly not that great and has pretty poor IDE support, but you can get a lot done before you ever send the data out over the network.
SQL is a declarative language
There is state, it's just explicitly passed around instead of hidden by class variables and global mutables.
I wrote this on the original, but the issue with using functional techniques in a language like JavaScript is that
A) The language doesn't have tail-call optimization and therefore recursion blows up the call stack
B) Sometimes, functional languages are able to support loop fusion where, in the pipeline example, all the steps happen in a single loop instead of iterating multiple times.
I always wondering how this kind of approach (the currying, multi-step-loop functions) would affect performance. Thanks for addressing this concern.
fwiw re: B) - you can easily build transducers in JS (or use a library), which allows you to write declarative transformations but avoid a bunch of additional loops/instances.
To me one of thing I hate about FP with JS is that there isn't currying by default (again, you can supplement with libs), which makes the whole thing feel super un-ergonomic. It makes composition harder and less intuitive, which makes small, pure functions feel less valuable. FP techniques synergize in a really satisfying way, so when you have to do all this extra leg work to enact them, of course it feels like going all in on FP is a pain.
The other issue is when you work in embedded and you have to modify state in place because of cpu and memory constraints.
JS(ES6) does have TCO its just that V8/Firefox doesn't support it.
@@mixed_nuts then it doesn't. A standard without an implementation is like saying I have a PhD from MIT because I can see their outline of their PhD program online.
I am doing a lot of DSP and data processing, and I found myself drawn to the style of creating some kind of "pipeline" since it makes it really easy to understand on a high level what kind of steps a given analysis is going through (much more so than, say, a nested loop with all the interesting stuff going on in the innermost loop).
Since in Rust / C++, I find myself falling back to good old procedural idioms quite often out of habit, I started to use some F# for smaller scripts and recently Advent of Code, forcing myself to embrace the functional style.
On the one hand, the code turns out to be quite readable, composing functions feels good, and I have less issues bikeshedding how to organize code compared to an object oriented approach, where there are always multiple ways to split up functionality into different classes, and usually the first choice turns out to be flawed some time down the road.
On the other hand, I find that the FP style has more "surface area" to learn (knowing as many algorithms / operations available for a given type of container is critical), I find it hard to reason about the performance of certain steps (compared to a procedural style where working with contiguous memory and avoiding copies already gets you quite far, and it's usually obvious when copies happen), and, most critically, the debugger seems really useless.
So I'm torn. It seems a bit like sugar, some FP style in some places (mainly high-level "business logic"?) is awesome, but in the more involved interna of a codebase, I find that keeping things procedural may actually be better to stay on top of what's going on, at least based on the debugging experience I had so far.
Ofc it might just be a skill issue at this point.
I agree that functional programmers are bad marketers because, somehow, they make this guy think about FP as “There Shall Be No State”. This is hilarious 😂
Prime is the best example of somebody who has no idea what he's talking about but read some very surface level things on the topic and now talks about it with authority. That's not FP's problem, it's the problem of soydevs thinking they know everything without actually studying.
Seems to me like it's more about reducing the use of state and trying to make sure its impacts are known when it does get used. I'm just starting to look into it but those are the benefits I'm seeing right out of the gate.
@@ragnarok7976 sortve but really the idea is to avoid shared mutable state so that you can achieve pure functions, which are functions that are:
Total
Deterministic
Side-effect free
This allows those functions to be referentially transparent so they can be optimized and memoized even by the compiler. This also let's to do property based tests instead of unit tests which test what these functions actually "are" instead of testing some example observations. And it essentially makes 90% of your code nearly error free so you can go focus on only the things that can cause issues instead of running up and down your code with a debugger
Yes of course there is state..it is just immutable. So once you alter it, you just get a new copy. The copy is smart though, nothing like Rust's "Clone"
@@AndreiGeorgescu-j9pAnd they are a whole lot easier to test
Functional bros don't even program... they just function.
Lol, I commented - as one of the first comments - under the original 'Dear Functional Bros': "This one is going to hit ThePrimeagen hard xD"
I'm a hobbyist programmer and I've only got experience working with procedural and object oriented programming. This stuff is mindboggling to me. I can clearly see that it works, but I do not understand how the heck it does. It's like I've been building houses using nails and screws all my life, and then someone shows up and tells me about wood joining and shows me that you can build a whole house without any screws or nails. I can clearly see that you put a house together, but I have no idea why it's not falling apart.
IMHO, nothing beats Scott Wlaschin's conference lectures on "Domain Modeling Made Functional" and "Functional Design Patterns" for introducing functional programming in a really intuitive way.
came here to say this, glad someone is also on board
Yes! Are you also one of the 5 F# programmers?
@@mciejgda88 not yet unfortunately, but i have almost read all of the articles from Scott's blog. I want to do as an experiment the domain modelling with F# thing in a real context with domain experts
I also got owned by reverse last week. Totally forgot it mutates arrays
The sad thing is all these coding youtubers only understand surface level stuff about FP. It's not actually all about pure functions and such. It's all about explicitly modelling computation.
I look forward to your youtube video expanding on these concepts
@@ericb7937 I've honestly been toying with the idea of making some tech videos on youtube. Perhaps sooner than later.
Cool story functional bro
You just gotta learn Clojure to get it
@llIlllIIlIIlllIlllIlIt has been my observation that almost all coding youtubers (who are not overtly obsessed with FP) think they understand FP after only learning: Pure functions, no side effects, const variables, recursion. I mean those are all features of FP for sure, but that is not the pull of FP. In fact many imperative languages have these features. In fact us functional programmers go out of our way to explicitly put state into our code! FP is NOT about avoiding state. The magic of FP is that a good FP language (such as Haskell) allows you to explicitly model both data and computation flow in concise and well-defined ways. I won't go into the details here, but I have heard the phrase "monads are a programmable semicolon". IMO this is rather accurate. Imagine you were writing a function in your favorite C-syntax language and you could program implicit code specific for that given function to be ran in between every expression. It's rather powerful stuff.
Recursion is a dangerous form of iteration that can overflow the stack if it's not being tail call optimised.
And the worst part in case of errors the call stack is completely useless without first (which started the whole chain and holds initial value) and the last (the reason for the error) calls.
And a loop can run out if memory if there is no garbage collection.
How is this any different?
@@fullfungo Just clean up when needed, which is easier to handle than a recursive control flow.
@@fullfungo it's infinitely easier to debug and you can easily Tell when you run out of memory in a loop. because you get a Seg Fault or malloc can't get any new memory instead of Stack Overflow with the stack trace pointing to one function. Using the program stack like this is just not a good idea.
@@fullfungo And this is one reason why I love RAII, though, as the_mandrill suggested, it should probably just be called Scope-Bound Resource Management (SBRM)
Learning Haskell as basically my first language (C++ was my actual first, but I quickly grew disinterested in the language). Has caused quite an interesting learning journey.
🎯 Key Takeaways for quick navigation:
00:00 🎉 *The video starts with a discussion about functional programming and the term "functional bros."*
02:10 💡 *Functional programming emphasizes pure functions without side effects, making it elegant and predictable.*
03:44 🧐 *Functional programming eliminates mutable state and relies on functions to compose and manipulate data.*
06:04 🔄 *Recursion is discussed as a key technique in functional programming for tasks like looping.*
09:30 🤔 *The video explores currying and partial application as functional programming techniques.*
11:35 🧩 *Lambda functions are introduced as a way to create functions that carry extra data for specific conditions.*
14:58 🤓 *Functional programming methods like `filter`, `map`, and `take` are used to process data in a declarative and concise way.*
18:10 🔄 *The video demonstrates how to apply functional programming techniques to solve a problem involving restaurant receipts.*
20:18 📺 *Focus on being actively engaged when watching videos, especially if not live.*
21:26 💡 *Functional programming allows for elegant data pipelines, which are common in many programming tasks.*
23:10 🧠 *The best parts of functional programming have been incorporated into popular languages.*
24:05 🛡️ *Reducing state and using data pipelines can bring significant benefits without excessive restrictiveness.*
24:44 🚀 *Exploring multi-threading and parallelism in Rust can lead to improvements in performance.*
23:35 I was forced to use list comprehensions at my previous job and I grew to despise them xD . Sometimes being concise is not better
Prime: never gives attention to RUclips comments doesn't put anywhere that he's doing that
Also prime: i wonder why I don't have traction on RUclips.
Well, there is "LIVE AND READ CHAT ONLY ON TWITCH" in the description of his live streams.
@Drazzz27 oh my bad didn't see that
To be fair, I see him respond to RUclips comments all the time (including myself.) Just not while live lol
Could it also be the content he throws at RUclips nowadays?
Reaction video after reaction video, zero original content, just him hitting space on RUclips videos every second. Like idk, dude’s free to do whatever he wants and he obviously prefers Twitch but it feels pointless to sub to him now. Such a stark contrast to the channel he’s reacting to…
The peak of Prime's RUclips content was when he was on paternity leave. Dude is a Netflix Engineer™️ and has a few children iirc. He's just busy
Haskell has a special place in my heart because it got me interested in programming
Damn, I can't imagine raw dogging Haskell as a first programing language. Did you major in math?
@@azmah1999 Yes and it wasn't technically my first language. That was Java but I could barely write hello world at that point.
It was my 2nd but it was also the one that got me really into programming
Had Phil Wadler as a professor in first year Soft. Eng. and that was hands down the best, most interesting and fun course. Though everybody else seemed to hate it xD
I think he's mixing up Functional Programming and Pure Functional Programming.
There is a difference.
No he doesn't. 22:50
Does Pure Functional Programming inherit from Functional Programming or the other way around? I think OOP is for your kind.
@@abuDA-bt6ei the other way around
Everybody gangsta till the recursive "iteration" blows up the stack and ravages the heap
that's what tail call optimisation is for
@@ultru3525 that's a lot of bs to simply use a branch instruction
@@mitchhudson3972 yes every single assembly-level instruction is simple by itself, but once you start combining them to actually do something noteworthy, there is a point where the simple instructions start becoming exponentially more difficult to understand than the bs, or abstractions as they're more commonly called.
@ultru3525 in no universe will a for loop be more complex or difficult to understand than a bunch of recursion. With performance at best it just ends up being the same thing and at worst blows up your stack
@@mitchhudson3972 Sure, if you ignore the entire history of formal mathematics. Why do you think ancient mathematicians defined the Fibonacci sequence using recursion instead of a for-loop? Because recursion is the mathematical approach which is modelled by human reasoning. For-loops OTOH only came into existence when we needed to translate our reasoning into something a smarter-than-average rock can work with.
Haskell Curry realized that all you need is functions with one argument, as long as you can return a function. (Moses Schoenfinkel realized it first, but you and the guy with the video would REALLY complain if you had to talk about schoenfinkeling a function.) Haskell notation is designed to make it easy to schoen...uh, curry.
On the other hand, the programming language Moses probably would be way more popular. To their chagrin!
I like my for loops and you can never take them away
Currying is taking a function that has an arity greater than 1 (n) into a group of single arity functions whose members total n.
Currying will result in high order functions (but not all HOFs will require you to curry, a function with a callback for instance, can be a high order function but it is not a curry) since high order functions take a function as an argument or return a function
Arity being the number of arguments a function takes for my Dysfunctional bros.
And here I thought he just misspelled parity... I think at the end of the day most people would rather just learn a programming language than relearn English to learn a programming style then learn a programming language to implement it in. That's probably why this stuff hasn't gained more traction.
@@D4ngeresque I can appreciate hyperbole but I think comparing learning a couple new words (which are long standing English words) to relearning English is a bit too hyperbolic for me.
I thought the same thing when I first saw "arity" but I took two seconds to google it and I now I can understand any text that uses the term. 2 seconds of investment; lifetime of value.
I'd also add that you will need new language for all new things you learn so this really isn't an inherent issue to FP.
I'm not saying you need to learn it either just don't avoid it for arbitrary reasons like being novel to you.
"No state" but you use a secret parameter that will influence the result of your nested function.. in other words : State with extra steps.
No. Pure functional programming languages like "clean programming language" for example model the whole universe with no state changes (including the computer memory) - then how you run interactive programs is that both your functional program can create a new universe - then the user as a function also can create a new universe from that - then functions run over it again.
You need no state this is just recursion with a completely new universe being born all the times haha.
Then haskell has the other approach with monads - but I find the "Clean" approach to be theoretically cleaner indeed. Fun-fact: Clean and Haskell are nearly fully compatibly even to the syntax level and you could not tell which code is from which - despite the therory and inner workings being so different...
@@u9vata
What you are describing is the theoretical underpinnings of FP, the real implementations dont abide by that.
@@arkeynserhayn8370 What I describe is the SEMANTICS of said languages so real implementations DO totally abide that in both circumstances. Just of course - as every sensible compiler - they optimize whatever they can and whenever possible given the given circumstances when the compiler is good.
Still this is the programming model that you see when you are coding. There are "not purely" functional languages, where the semantics enable more, but in case of Clean and Haskell the semantics are purely functional.
The beauty of FP is, it basically takes tons of boiler plate and turns it into many shorthands.
map (+5) xs
feels so readable.
this is of course an incredibly basic example.
Instead of having to learn/debug your coworker's boilerplate shorthand, you can just learn FP boilerplate shorthand upfront.
Maybe that FP boilerplate shorthand isn't as readable as plain English. But it reduces your coworkers' boilerplate shorthand by an order of magnitude, which is almost always a win.
21:00 The standard javascript library is the problem here. These functions SHOULD accept and return iterators (where you can dump it back into an array at the end if you need to). Still, you don't really need to break up the code to debug this though. You could start by stepping through the "map", then remove that breakpoint if you are satisfied there are no bugs there, skip ahead to "filter" and so on, until you find a bug.
Rust iterators are such a big win over the JS way map|filter|reduce or implemented
JS has a proposal to add those and many more to iterators.
You don't step through the functional code with the debugger, you test the functional code with different inputs to see where it doesn't do what you wanted it to. Then you break it apart into its smaller parts to understand where you've gone wrong
QuickCheck for Haskell is amazing for this, but there aren’t as many good analogs in other language ecosystems…
unless it's javascript or some other mutation first language cosplaying as a functional language. Then good luck with that!
@@tuchapoltr you can just use the repl. It's pretty easy to use in both haskell and JS
Indeed! Step-by-step debugging doesn't make sense anywhere except in code executed step-by-step. For simple, pure functions you only want to see what various parts of the call tree evaluate to. More complex types would maybe warrant specialized debuggers tho.
@@ryanleemartin7758 I do this in JS all the time lol
Typical all-paradigms-are-good take. Software is remarkable among fields of engineering (civil, mechanical, electrical, etc.) in that nothing ever gets taken out. Legacy code and recalcitrance keep every approach in-play along with their defenders, the good and the bad.
If you want to be a true functional programmer, you need to be born this way, because you cannot change by design.
Functional programming is like Sigmund Freud's work -- a handful of great ideas that are widely applicable; but if you start digging too deep, it plummets into insanity.
Like React
I suggest reading "The Curse of the Excluded Middle" to understand why this "using the bests parts of FP" approach eventually falls apart in practice.
Can you explain a bit?
It's complete nonsense too since that's not how things work and the original video is mistaken on at least half of what they're saying. This is why FP gatekeeping hard is good, it keeps these soydevs out
The great thing about functional programming is that I spend less time debugging multiple issues because I have to spend more time debugging each individual issue.
FP might one day be better than procedural / OOP if colleges start teaching its concept, so the next junior seeing my (beautifully :) written functional code doesn't curse me behind my back
FP has it's uses, but trying do everything in FP is like a carpenter discovering a framing hammer and using it to drive a bolt into concrete.
Hey, at Cornell they teach OCaml in a pretty fundamental course so we're a bunch of closet functional nerds wondering what to do with ourselves!
You could consider "bind" to be syntactic sugar (or salt in this case) for currying. Essentially you are just adding the scope of the parent function and using it within the child function. This would be exactly the same result as simply just calling the child function inside of the parent function. Using bind is also less readable and I would argue introduces the same state-like problems you are trying to avoid. That being the functions being bound together is a state in itself but that state can be set up outside the scope of the function meaning there are cases where your function could fail and you'd have no idea just by looking at the function itself, rather you'd have to probe the context of the state around the function. At that point you might as well just use the state and keep the readability. Save you typing bind constantly too 😂
I’ve just started a programming course and I’m currently making my first JavaScript project. I was worried that I didn’t have any kind of “loop” in my code. I just have functions that call each other when certain criteria is met. The first 7 mins of this video made me feel a LOT better.. am I becoming functional bro?? 😂
f(str)
return str + " " + f(str)
f("One of us.")
@@NeilHaskins yeah I wish I knew what that meant 😂❤️
No you are not writing useful code yet.
@@nnnik3595 oh I’m very aware that I am still at the base of mount stupid 😂
Bro discovered callback hell
The reviewed video link causes a recursion.
18:10 You can both call array.sort() to just sort it, but you can also use it in a dot-chain of functions. I call that a win. At least as long as it doesn't actually clone the thing.
6:15 the nature of javascript: you don't get error on out of index, you get error on accessing field on null.
The entire world from a human eyes is chaos...but maybe...from a god's angle...functional..
We will never know perhaps
@ 2:25 😂❤ "the concepts of a function is so pure... You have this elegant thing that takes in an input and gives you an output..."
A woman! 😂❤
Full agree on the debugging part, exactly that, remove the return at the beginning, make multiple variables and then return it is also how I debug those things.
this is not the only way (breaking statements saing stuff into variables) to debug such code (20:40 when it has pipeline of map().filter().sort().slice()), can make a function that takes an array and returns it back (while also sending the array to console.log), and just temporary wrap the portion of pipeline with that function
Changing state is how you get things done. Heard it here first.
You can hear functional programmers break when they see a break.
switch is probably the most inherently functional aspect of most programming languages (aside from functions) and that uses break.
@@valseedianyeah considering it’s pretty close to pattern matching (see Java switch expressions)
@@valseedian I mean, they can't break in the same way normal for loops work in a forEach function, only continue by doing return.
i really like constexpr functions. like, you reduce state by having something where the output depends only on all inputs (even for constexpr classes, since `this` is a hidden parameter) and you don't have to deal with any of the bullshit with "pure" functional programming such as not being able to mutate local variables leading to things being overly complex and leading programmers to iterate and exhaust stack space.
currying is turning f(a, b, c) into g(a)(b)(c). partial application is where you create a new function with some argument values pre-set (partially applied).
Do you really need to know the names of them in order to use them though? I think the video was mostly about scaring new people off.
@@georgehelyar Using is second to *reasoning* about the concepts. Without the language and definitions of concepts, how do you convey the meaning and semantics?
@@georgehelyar it’s a programming pattern and it’s good to have a consistent name for the pattern 🤷♀️
People use these things all the time without knowing what they are called though. It's just that the names are scary to people who have not heard them before, and that makes people think FP isn't for them.
I think people missed his point. He was not advocating for architecture-wide implementation of functional programming. It's simply a tool to be used. At my company we have a mix in our codebase. We like the Functional Core/Imperative shell pattern. Sometimes. If it gets in the way, we don't use it. But when it doesn't get in the way it's really nice because you can write these complicated business functions that take input and produce output. They don't call into the database or anything else for that matter. They don't have state. This makes them very easy to unit test because you don't have to do any kind of mocking. To test it, you just call it with different inputs and test the outputs.
In Haskell, It’s not just because it’s pretty or because it’s elegant or because it’s easier to reason about once you understand it, it’s useful for making increasingly complex programs require less code to write (even under the hood) through the use of generalizations of functions on types and type classes. It’s the low cost or cost free abstractions that allow you to have automatic optimizations that the compiler can now prove using the type system that it wouldn’t be able to make without it. In some cases this even allows optimizations you wouldn’t be able to get writing well written C unless you used inline assembly.
It literally lets you write more performant programs using less total code asymptotically as you scale. And imo it’s more pleasant to write. And for the record, I love C and assembly. Calling C and assembly in Haskell when generalizations don’t yet exist to get you comparable performance for that specific function is practically standard practice for a Haskell dev when performance matters.
I use to hate OOP until I saw learned how common lisp (which is supposedly a functional programming language) does OOP.
This is proof that you can meme on a shoddy "code-tuber" like the one Prime's reacting to and still learn something valuable!
I’m really sad because Code Aesthetics has some good takes and amazing animations… but sometimes, they just miss the mark.
@@tuchapoltr He's wrong about nearly everything. He's a pseudointellectual soydev who thinks he has it all figured out and hides behind animations and giant piles of his terrible code to justify anything he wants to say, which he always says with an authoritative tone like he knows the answers to things that literal geniuses still debate.
@@AndreiGeorgescu-j9p Holy shit dude calm down.
I love high order functions. And I love to use them in Go.
Technically all functions modify state because you're modifying registers
Single or, at most, double loop comprehensions are great! Any deeper and they are an interesting challenge to create but shouldn't be used in production
11:46 Yeah, it is currying, basically if you have a function that does the sum between 2 numbers, gets a number as input, that's the function that does the sum of x + 5 (assuming you passed 5 as first argument) and you specialize the function x + y with y = 5. If you pass both of them in this way (x)(y), you are actually changing both of the x and y. TECHNICALLY what he did it's called closure in python world, but it's the same principle of currying
RUclips chat the neglected children of prime's community.
Whenever I look at the example at 7 min I keep thinking that if there should be no state, we either have to keep copying variables, wasting a ton of clock cycles, or we do actually have the state somewhere (maybe hidden) - cause we need a reference to the array. In any case I keep thinking there must be an easier way to do the same thing.
This is much cleaner and readable until promise are not put into the equation, where things will start to look messy fairly quickly.
Ironically exactly when he says youtube can be a part of this video this one time, my RUclips app crashes lol
for good introductions to fp i can recommend scott wlaschin's articles and videos
List comprehensions: 5/5 😊
Nested list comprehensions: 0/5 😠
Learning F# right while getting a deeper learning of concurrency in .Net. Brain melting.
There's only one thing I agree with in this video: functional programmers are bad at marketing. This video is a great example of that. Boom, recursion.
Funny thing, if you have account with European bank, you are not allowed to let the card out of your sight of you or authorized person when paying with CC/debit (one of those things people don't read when they sign papers) so things like this is less likely to happen.
Functional bros do use HashMaps occasionally but often we use immutable maps based on binary trees.
The confusion behind currying is probably with the nomenclature, currying is the process of turning this type signature:
f :: (Int, Int) -> Int
Into this type signature:
f :: Int -> Int -> Int
@ThePrimeTime, whenever you summed up a list of numbers you did a catamorphic operation, you probably did it during the last few weeks.
This is the point though. Hearing "catamorphic operation" scares people off, and you don't really need to know the name of it in order to use it.
The problem with category theory is that it's so abstract and general that there's some construct in category theory that will describe what you're doing.
Except, naming things for the sake of naming them gives you nothing useful.
@@isodoubIet Knowing the basics of CT can lead you to seeing your programming problems differently. I recently wanted an embedded DSL for Logic Programming (with cut!) in Python, and I implemented it in Python with a triple-barrelled continuation monad. I'm very pleased with the simplicity of the code. I ported it to C# in one evening without much prior knowledge in that language. The structure of the code made it also very easy to add tail call elimination via thunks and a trampoline.
@@pillmuncher67 yeah parsing is one of those things for which functional patterns in general are very well suited
FYI the "reviewed video" link in the description links to THIS video, not the CodeAesthetic video
Currying is the transformation of a function to another which is exactly what he did.
Currying and partial application are related, but not equal.
All partial application is currying, but not all currying is partial application.
"All partial application is currying" is false by definition. Also currying is never partial application. The only thing you wrote that is correct is saying that they are related.
@@thomassynths
Currying is a function that returns a function.
Partial application is a function that returns a function with some of the arguments fixed.
I stand by what i wrote.
@@khatdubell Currying is a function that takes in a function with tuple arguments and turns a new function that takes unary arguments and returns successive functions. Partial application merely returns a new function with some argument values already provided. These are different things. `curry(f)` returns a function that has nothing partially applied it it. Currying is one mechanism to facilitate partial application, but it is not the only one.
Mathematically, currying `(a, b)->c` is `a->(b->c)`. Notice that no partial application has yet been performed, yet the currying operation is completed once the `a->(b->c)` value is returned.
Mathematically, partially applying `a` to `(a,b)->c` yields `b->c`. Notice that `patial_apply(f,a)` takes more than just the function as an input, unlike `curry`
@@thomassynths You're right of course but I'm curious why this is the topic you seem to be concerned with when nearly half of this video is incorrect information. Prime has absolutely no idea what he's talking about and the guy he's reacting to is even worse
@@AndreiGeorgescu-j9phe and other soydevs always love sh*tting on functional programming and when asked why? They don't know sh*t on how to elaborate on functional programming
MS Excell is the most popular functional programing language
I remember getting owned by reverse so hard that I memory holed what it was that I did wrong, ensuring I will eventually get owned by it again in the exact same way at some point
03:56
I wonder is "Code oriented: state is code" possible
no ifs, no loops, but instruction to replace instruction (branchless self modifying code)
You mean like Forth or Joy?
everytime I saw your yt pfp, I always thought it looks like a communist leader paintings
that was my goal
21:34 he claims breaking the pipeline apart is "the worse" because you can't debug one item at a time. He is strongly assuming the first item in in the iterated version would tell him what was wrong, often you have to look at the entire output to see the issue.
As a (semi-)functional bro, the man is absolutely correct, like 100% correct.
I watched this video a few weeks ago and just was baffled. This guy clearly doesn't understand FP at all, and that's disconcerting.
During uni a friend of mine who was way more advanced at coding than me showed me his self written OS's and also when he did functional programming. To this day I don't get it and I feel like ignorance is bliss.
Comuter crash - nasty proton flux, 100x beyond baseline. Hurts me too, not just the computer.
Since using Julia I will never go back to any non functional language. No side effects is a god given right. (I’m a theoretical physicist so probably it comes naturally to me)
Three steps to slowing down your JS by an incredible amount, step 1: map(), step 2: filter(), step 3: slice()
Yeah running map() before filter() is especially triggering, as it will run n transforms, where n is the array length, regardless of output of filter().
I don't know if it was code aesthetics intent, but seeing a simple for loop turn into that monstrosity was enough to convince me to never touch functional programming. I just want to make the thing do the thing D:
Monstrosity? You mean, "something I'm not familiar with and I'm not really willing to learn"? Even if you don't care about more advanced languages you should learn recursion, it's just the correct choice for certain algorithms.
He's got little to no idea what he's doing, frankly just like Prime. You really shouldn't be listening to these soydev youtubers and go study from an actual book/course. If you want recommendations on FP I can provide them
@@digitalspecter He's actually right though, that guy has no idea how to write FP and in actual FP code you're not writing explicit iterators...you're using implicit or internal iterators
This is why I'm learning C for the last time. Procedural Rul'z and abstraction drools
IMHO opinion, not having state is reasonable. But carrying that over to, you cant have for loops because the iteration counter is a variable that is written to and is therefore state, is stupid.
Having no state, IMHO, means that the same input will result in the same output, every time. That is it. There can be internal "states" as long as the same input will result in the same output.
I would also recommend ignoring that explanation. Local mutations and state are possible in functional languages, but you don't need them for a for loop. e.g. a local Ref can be used to achieve this in Scala, OCaml, and even Haskell
Using map, filter, flatmap are preferred as you do not need to write the looping implementation where mistakes could be made, it's easier to reason about (likewise using recursion), and can take advantage of any optimisations
Last time I looked map in Scala was just a classic loop in Java under the hood 😅
Trust me, 90% of the stuff I read about FP (like in JS) is not really FP. It's procedural code using FP concepts -- and there's nothing wrong with that at all
There are pretty much purely functional programming languages (like Flix) that allow local mutation as long as it doesn't escape the scope.
I am an OOP bro , i just used the whole project as my class and create functions for it
Your closing comment made me cry a little bit inside. Concurrency in Rust is hard. It took me a couple months to get used to the borrow checker when learning. Now I have a process that I’m trying to speed up with the various concurrency tricks, but nothing actually works. Everything compiles and runs and gives correct results, but everything with concurrency makes things 5 to 50 times slower. Rayon, channels, etc. nothing works. I feel like I did back before I was able to think of the borrow checker as something to work with instead of something to fight with. This is one thing that the rust book actually makes look easy, but that implementing in a real world problem gets hard.
It might be a better exercise to first implement as non blocking pool threads to discover if the problem is congruent to coroutines. I find it’s easier to move to coroutines from that.
just rewrite it in Go
It is false that recursion is a fancier form of iteration, because there are some functions that are only recursive and can’t be turned into an iterative. Look up the Ackermann function to see one that can only be recursive.
Recursion isn’t a fancier form of iteration but can be expressed with iteration and a stack.
Every function is a pure function. You just have to conceptualize it as the new state being part of the output and the current state as being part of the input.
I love you Pound Town MacBook Mini that's what they call meagen
Nested list comprehensions? All my homies use
I find that if you code without prejudice sometimes you find yourself passing functions into other functions calling functions from inside themselves, creating pure functions and so on, theres a right situation for these things and many wrong ones
Input and output IS state. Check mate functional bros!