Code Aesthetic: Makes a whole video about being a "never nester" Also Code Aesthetic: 4:10 puts an entire function's logic inside an if statement instead of using a return.
Early returns are not there in most functional languages. So it's not common to use them. The same is true for local variables. Creating them usually requires a `let ... in` construct so they are also avoided
Judging from their second channel and their website, I think they've been on a journey to rediscover non-OOP and computer science since the never nester thing. Also, it's not a bad thing to change your mind.
My guess is it was just for ease of understanding. He's showing how the condition moves down to the recursive solution so any change there is not necessary for the point. Would've been nice to see him do the solution in the video and simplify it to flatten the if statement.
Lambda calculus (which most of the FP is based on) is not just about purity and statelessness of functions and converting loops to tail recursion calls. It ensures transparency of the functions. The entire tree of terms is always available. Which means, the compiler can reduce expression trees, sees data access patterns, can replace operations and data structures with more efficient ones, eliminate effectively dead code, etc., and do so across the function calls. These techniques are used even in imperative language translators (e.g. GCC and Clang), but they are tied by unpredictably mutable state.
But full immutability also makes a lot of things harder. I implemented a compiler in Haskell once. It was not fun, at all. Want to modify a syntax tree while type checking it? Have fun rebuilding the entire tree, which is both error-prone (accidentally changing left-hand side and right-hand side of binary operators or using older (not type checked) nodes) and makes code harder to understand. Or you can use the same syntax tree and make the same checks every time (like dealing with == operator for arrays differently). Or maybe there is some fancy way of doing it with a shit ton of abstraction that I couldn't figure out because I don't have a PhD in category theory and computer science. Ironically, Haskell taught me the beauty of procedural programming.
@@user-tx4wj7qk4t the comparison between mathematics and programming is weird, because they are mostly unrelated in this context. Even if you want to go along with it, mathematicians use a mix of mathematical notation and kind-of-imperative natural language, 'cause explaining everything using only maths and logic would be unreadable. Maybe functional languages are good for toy compilers (that probably use parser and lexer generators), but any serious compiler like gcc or nodejs uses procedural/imperative style, with hand written parsers. Most of the widely used languages combine procedural or imperative with other paradigms. It's weird to say that procedural style is garbage when Haskell literally reinvents it. What is a state monad? It's Haskell reinventing mutability. What is IO monad? Just statements in imperative languages. Why do you need those if functions are so good? Cause you can't program in a convenient way using only functions without adding a shit ton of abstractions and concepts.
To be fair, these optimizations also happen in imperative languages, especially if the compiler does effect analysis. Of course, guarantees are more reliable than compiler inference. This is not to say functional languages always yield inherently more performant programs, that should be left up to benchmarks in practical applications.
@@user-tx4wj7qk4t you completely missed the point about mathematics. Are math articles/books written in math notation only? No, because it's unreadable. Do teachers throw pure formulas at students? No, they explain it with words + show some formulas/definitions. At no point did I claim that mathematical language is imperative. "How to prove X? Show, this, this and that", that's pretty imperative. Whatever, this discussion is pointless, you seem to be one of those pure functional programming zealots.
@@user-tx4wj7qk4t "It definitely doesn't make things harder, that's why mathematicians use "immutability", aka real variables. No mathematician is writing "imperative" math." this is factually incorrect (and a misunderstanding of mathematics). If I define the variable x = 1 in one context, and x = 3 in another context, my x is not universally immutable; it is contextually immutable and it may be a different value in a different state. Not to mention that there is an entire category of mathematical functions that are iterative over some mutating variable en.wikipedia.org/wiki/Series_(mathematics)
I learned functional programming via F# and Clojure, and came away with a rather impure lesson: You only need a SUBSET of pure functional concepts to write great software. I've found that in most languages, you get 80% of the benefit from 20% of the tools: Referential transparency via expression-based programming; no state or local-only state (avoid global state or state passing at all costs); chained stateless transformations, via things like universal function call syntax, pipe operators, map, filter, reduce, and comprehensions; a strong preference for passing around and transforming simple data structures, such as records/structs; liberal use of tagged unions/variants to create exhaustive conditionals that make illegal states unrepresentable; and making functions short and sweet, which allows for minimal nesting and easy naming. Your program then becomes a pyramid of calls to what is essentially a DSL.
Hard agree. I’ve been all the way down the FP rabbit hole and back again. My takeaway is that the biggest bang for your buck is functional style state management. Usually there is a framework that does this for you. Use it.
Agreed, using imperative code inside the local scope of a function is a good trade off to maintain simplicity and performance, so long as your exported function maintains referential integrity
I somewhat agree. But then, what are examples of stuff you consider to be functional but out of that subset you mention? To me, you summed up what functional means, and I don't get why you would call that an "impure lesson" (other than for the local-only state). 🤔
"Your program then becomes a pyramid of calls to what is essentially a DSL." *Lisp curse intensifies* Seriously look up the lisp curse by Winestock. The problem is that in a team of 5 people, they'll be able to come up with at least 6 different DSLs for the feature set. And which one is the most correct is usually dependent on future unknown expansion of feature set.
Now I am wondering if I was hanging out with anarchists or functional programmers that one time. The state existing is antithetical to either of these groups it seems.
Recursive functions can be scary because it can lead to very long call stacks and stack overflows. I recently learned about tail calls which some languages can use to avoid this. Essentially, if the last line run in a function is another function, the rest of the resources from the completed function can be freed up. I learned about this from Lua, but it looks like there is some compiler support in C++ as well
Scheme's spec mandates that implementations guarantee tail recursion. WASM has a tail recursion extension as well. JavaScript was supposed to get guaranteed tail calls, but it was veto'd by Apple and Google IIRC. A lot of compilers (for example Rust's) will do TCO or tail call optimization, but this isn't guaranteed, so I personally find it annoying to rely on. I don't want to write higher level code and then check the assembly to see if it's actually optimized the way I want it. Of course it's basically guaranteed to be available in functional languages like Haskell, OCaml, Elixir, etc.
Even though it works, it really feels like a hack. What if the compiler accidently does not recognize this for some reason? Then you have unexpected behavior that might also be hard find out about.
@@SimonMeskens in case of Scala if you want to make sure you can use a simple annotation. If you write something wrong compiler will tell you right away
@@joranmulderij once you get used to it, it's simple enough to reason about. for example, if i want to write a non-tail recursive factorial, it will look like this: func factorial(int n) { if n
Important to note that in JavaScript, Array.sort() sorts the array in place. However, ECMAScript 2023 introduced a new non-destructive method for sorting an array, Array.toSorted(). PS. It also introduced Array.toReversed() and Array.toSpliced(), non-destructive alternatives to Array.reverse() and Array.splice().
now if only they'd give us summed, grouped, unique, and partitioned..... yes, you can do literally all of that in `reduce` but reduce is notoriously easy to write and hard to read. also, they have you put the initial value _after_ the function, which is just sacrilege.
@@Bliss467 the initial value after the function is correct because in bind-order the function is what you would bind first when specialising it under partial operation
Can we petition to introduce Array.toMapped, Array.toFiltered, etc. that mutates the original array to just really destroy the souls of new developers?
@@cadekachelmeier7251 I think those functions are both ridiculous though. Array.prototype.toMapped = function(transform){this.forEach((e,i,a,)=>{a[i]=transform(e,i,a);});}; // this just uses for each! toFiltered would either be inefficient OR take up extra memory. inefficient way: Array.prototype.toFiltered = function(condition){ // yes, this for loop is horrendous for(let i = 0, c; i < this.length; c?(i++) :(this.splice(i,1))) c=condition(this[i])); return this; }; extra memory way: Array.prototype.toFiltered = function(condition){ const f = this.filter(condition); // apply is used because ...ellipsis is slow f.unshift(0); f.unshift(this.length]); this.splice.apply(args); return this; };
This was a really good execution of a 3b1b-style "rediscovering the fundamentals from scratch" journey. Also, I have a sudden urge to take pictures of my receipts and upload them somewhere, but I'm sure it's completely unrelated
The functional emphasis on reducing state and minimising side effects also, in my opinion, greatly helps with reducing code complexity in the way described in "Philosophy of Software Development". In that book, he emphasises creating modules or functions with deep functionality, and simple interfaces. If your functions are pure and have no side effects, it simplifies the actual interface and avoids information leakage - you only have to know what the function explicitly does, what its parameters are, and what it returns. The implementation is entirely irrelevant. I've definitely edited some people's code where I've been confused by bugs, only to find that a function somewhere is sneakily mutating the state of the code when I'm not aware of it. Having a guarantee that a function doesn't do such a thing is really useful when trying to quickly understand and use a system. I think something like naming functions which are pure as this_is_a_function_P and ones which have side effects as this_is_another_function_Imp would potentially help, provided people do stick to those rules. Just my two cents!
With JavaScript, you can customize ESLint to give you errors or warnings when a function modifies its inputs. You can customize the rule to not report errors if your parameters are written with a specific pattern. I configured it so that if you intend for an input to be modified (like when using an array.forEach()), your parameter name should start with "mut_". We have eliminated non-pure functions thanks to this
that should be something that the compiler enforces, for example in swift when you want to change some value of the containing struct inside of a method, that method has to be explicitly marked with the mutating keyword, otherwise you will get an error
@@voidmind that fixes part of the problem, though it still doesn't stop you having some class method foo(int a) {b = a; self.c = 20; return b}, so doesn't guarantee pure functions as side effects are still possible. However, that sounds like a good approach to do this in a language which doesn't enforce these kinds of rules
@@LosFarmosCTL yep, or rust for example has all data as const by default, which is a much better way than the standard mutable by default approach, though I doubt many other languages will adopt it sadly
This pipeline approach is one of the things I love about Rust. In JS, the array methods operate on the entire array at each step, whereas Rust iterators work on a single item from the iterator at a time across the entire pipeline.
That's one thing I'm always a little annoyed about in JS, the functional methods are *only* defined on arrays, not iterators. Which sucks sometimes. Apparently they are in development on iterators but its not implemented everywhere, including node.js, so like... not really usable
Also, JS copies arrays in ram to work on them (which sucks even more if you chain multiple of those functions together), while Rust "resolves" your chain of functions at compile time. It's part of Rusts zero-cost abstraction philosophy. Rust is awesome.
Take note that doing FP in JS may induce a steep performance penalty, for you are allocating a new array at every chained step and copying the data. And in most cases the runtime cannot optimise this because the closures have no pureness guarantee (i.e. may have side effects). If you want the true functional experience, learn SML or Haskell. If you want the practical functional experience and still keep your sanity (i.e. the choice to opt-in/out at will), learn Rust.
I'm not sure the performance penalty is at all something to worry about in web dev with JS. What data collection are you working with on a web app directly, that is large enough for performance to take a noticeable hit? Even if we make some ridiculous large shopping cart or whatever, with 1000 of different items added, it would still take a FP approach less than the blink of an eye to process - on an old and bad PC! I think you're prematurely optimizing for something that would never be an actual measurable difference. In turn, you're losing the FP way which can be easier to reason about and way more concise. (oh yeah, I said it won't even be noticeable in an old and bad pc with an unreasonably artificial huge shopping cart. If it's a standard budget modernish laptop then it even make less sense)
Imagine if all developers thought like that, software would be even slower. I'm a huge FP fan, but I won't use it for languages that don't have compiler support to make it fast (e.g in-place opportunistic mutation). "Premature optimization".... lol, people really need to stop using that term.@@marouanelhaddad8632
As an early career developer without a CS or mathematics degree, I really appreciate how you explain things and your delivery. I would love for you to do a series of deep dives into various principles and paradigms. Whatever you do I'm sure it'll be great and I'll be here for it. Happy holidays, stay safe 🎄
One of the biggest benefits of keeping things pure is that it's easy to write unit tests. I am an "FP bro" and must say that your code was a little bit complex. I usually split the pipeline steps into variable assignments to make it more self documenting, unless its steps are very simple.
Totally! Testing is not a way to catch bugs, it's also a great way to force better code design. If something is easy to test, it's probably written pretty well. And FP is great for that since everything is simple input-output. Mocking, particularly, becomes a non-issue
@@LetsGetIntoItMedia Agree 100%. Just like Rust gives a guarantee of memory safety, pure functions give a sort of guarantee that the function does one thing only. Regardless of the logic that produces the transformation. One can even take it to the next level by writing property based tests. I find writing property test very difficult, but for the more capable and skilled programmers out there it can give extreme code coverage.
Ohhh yeah, I find property based testing really difficult in practice too. Because then it adds a bunch of complexity in generating the random inputs, and making sure that you cover all the possible edge cases. That, to me, is not worth it. I'd rather just keep functions small, and have tests be very very hardcoded. Think through your edge cases and manually write them all out. And if a production issue comes up, add that as a new unit test to catch that regression in the future. One of my teammates once said, "tests are only worth it if they save you more time/pain in bugfixes, production issues, middle-of-the-night emergencies, and reputation than the amount of work required to write them". I think property testing is over that threshold.
@@LetsGetIntoItMedia Good point. What do you feel about using a debugger? Personally, I'm so bad at programming that I actually spend 80% of the time stepping through the failing tests in the debugger until I find the root of the issue. I used to hate the debugger, but now I'm starting to become comfortable with it.
There is no other way 😁 when I was first introduced to a debugger, it blew my mind. (But I'm about to contradict myself. There are definitely other ways, and often necessary...) But that was in Java, where stack traces are much nicer. In Javascript, there are so many anonymous functions and library code that it makes it much trickier. Particularly in pipelines, since there's not an obvious place to even place a breakpoint. I end up using pipe(fn, fn, a => { debugger; return a; }, fn) a lot. The debugger is still a good tool, but Javascript makes it tricky. Next best thing is to keep trying to isolate pieces of code and run them in smaller test cases. Unit testing is key.
As someone who is trying to learn programming, and has only so far found OO educational materials, I have had a lot of trouble trying to comprehend what a functional approach would look like. I finally get it. Thank you so much! I feel like I have the power to ask better questions now, and keep moving forward.
it looks like a lot of code that noone can read. Because at the end of the day, at the level of the CPU and even before function and data is the same thing. In my opinion it is ok to concatenate functions in a left to right syntax, but having the ARGUMENT and not the result of a function be another fucntion (so kind of right to left) is just making your code unnecessarily hard to read
Monads/applicative functors are going to be the next FP feature to appear in mainstream languages I think. The usefulness of piping a transformation that can fail/have multiple outcomes is just so great compared to infinite 'if' checks, scary runtime exceptions, or unpacking multiple lists only to map over them immediately after. Kotlin already has a "access member if not null" operator, Rust is similar with its Result and Option datatypes.
I implemented Result/Option in C# using a Nick Chapsas video as reference, and they've been a godsend for cutting down on null exceptions and all the guard clauses to prevent them. If only they were built-in, I'm sure they'd be way better than what I cobbled together haha. Definitely not as nice as Rust, where they're core language featues, but way better than nullable or relying on null checks.
I really hope so! I think the Effect library will do a lot to bring those to TS in a very usable way. I was using fp-ts before, but found it clunky. Effect might make it all usable enough to actually get popular 🤞
@@TheMasonX23actually, neither Result nor Option are core language features; they're perfectly standard data types that you could implement equivalently in user code (the difference is that because they're part of the core _library_ they're ubiquitous in APIs, which wouldn't be the case for a user code version)
The timing on this video is perfect. I've been on an fp video binge the last few weeks and you have a way of visually explaining things that I've always appreciated.
This video was a really great overview! Since you're on an fp video binge, maybe you'd be interested in the series I'm starting (check out the channel page). I think there's also a lot of value to understanding some of the math concepts... NOT because smart words make you smart, but because the smart words are actually fairly simple concepts that are quite universal, so knowing them helps you see patterns in problems, which you can then solve more simply
@@kylewollman2239 lovely, thanks for watching! I hope you enjoy the rest. And please leave me any feedback on the format/pace/content, so I can tweak the series to be most fun and helpful as possible!
I love the visualisation of the functions! Btw, you would be super cool if you did a video about array programming! Like with APL or BQN etc. Those are the most aesthetic language in my opinion and it would blow a lot of peoples mind if they saw that video!
I mean he kind of set it up. We now need a video on functional combinators, monads and then we can slowly start to swallow the array pill and have our 20 lines of BQN code that form an Excel clone, a web server, the entirety of Facebook, a missile guidance system, a hospital management software and a smart thermostat all in one go.
you say that like array programming is the next step, but i have my doubts. it seems to lack the composability of functional programming by imposing more arbitrary limitations. from what i remember, there is also a lack of higher order functions in array programming
@@xybersurfer it’s funny that you say it lacks composability when that is one of the strongest features. Code_report (TH-cam channel) has some good videos showing it 😁 also comparing with Haskell. They also have operators (in APL speak) or modifiers (in BQN speak) which are sort of higher order functions, but BQN (the language I write in (I have some videos on my account if you’re interested)) also supports higher order functions in the functional sense. And the restriction (constraining to arrays) isn’t arbitrary, it gives a lot of power and expressivity exactly due to limiting the baseline to a bedrock foundation and building from there using the most flexible and essential functions and making them compostable in every way you’d want. I personally really love them, and if you get your mind into array thinking they’re super expressive, powerful and fun to work with
@@davidzwitser oh then perhaps these limitations are specific to the variant of array programming that i used. i looked at the video "I ❤ BQN and Haskell" by code_report. it's shorter than Haskell, but it looks like write-only code (similar to APL). to me it would make more sense if this form of polymorphism was added to Haskell
Thank you very much! I've only ever learned OOP, and have been struggling to properly conceptualise functional programming for months, but this video made so much sense. Ive been seeing those snippets of functional programming code at work, it is good to be able to better understand the method and thinking behind them.
The currying explanation finally made it click for me, good video mate! Also even if a FP lang is not truly "pure" having immutability and the semantics that brings, it gets a lot easier to reason about code.
That's cool and stuff, but this example only works because you only use functions that operate on lists and use fluent pattern. The good thing of functional programming is that you can pipe anything as long as output of previous matches input of the next. Absense of nulls and exceptions and adts are also nice. Monads and all that wizardry is just a consequence of using it all together
And it also works because every function being piped doesn't require any additional information beside what is in the list. As soon as you need to propagate some information, you end with a lot of useless arguments that are just being passed around. Like what if you want to know the index of filtered element in original array? You now need to create an array of pairs (index, element), and every function needs to accept that pair and propagate that index through every call. That is error-prone (what if you accidentally pass an incorrect number somewhere?) and clutters the functions (that index is not used for anything in most functions).
@@clawsie5543 you're doing it wrong. You don't need to flatten everything down to pass it along, just have that part of the chain as a closure over the original index and the code that needs to reference it, just does :shrug:
Absolutely stunning and I was quite amazed by the clarity of this video. As a total beginner to functional programming (with years of experience in OOP and recursion), I find it crispy clear with the visuals that you created. Thanks again for this work.
This is absolutely hands down the best explanation I’ve ever seen on functional programming. I’m only a few minutes in and I’m just so blown away I had to comment. Definitely the best visualization of what’s going on, this is literally so extremely helpful for understanding this concept which I’ve been struggling to start to understand. Thank you so much, you make beautiful and helpful videos!
@@user-tx4wj7qk4t Get off your high-horse, and stop spamming the same copy & pasted reply. Have fun with your pseudo-intellectual (and possibly imaginary?) job as well. Jesus...
Why didn't you start the function with `if(index >= receipts.length) return;` rather than having your whole function inside an if statement? You made an entire video about being a never nester! I expected better... otherwise great video as always tho, that one thing just really bugged
For recursion especially! If I ever write a recursive function I try my best to put the exit condition at the top (and about 100 comments warning any reader that it's a recursive function and works a bit differently 😅)
As a scientific programmer (in chemistry) who uses Julia intensively after bad experiences with C: I feel like to first order, state is the enemy of scientific programmers (more generally, when state is not relevant to a problem, it should be abstracted away as much as possible). Functional programming maps very naturally onto a lot of what we do, but a lot of the trouble people around me had was the degree to which we were taught we had to manage state when we really didn't.
The problem with functional programming in a language like JavaScript is that the JS runtime does not optimize functional techniques. Languages like F#, LISP, Scala, etc. can eliminate stack overflows and sometimes even do something called loop fusion where, in your pipeline example, all operations happen in a single loop instead of looping multiple times which is always the case in JS.
@@SogMosee What you are looking for is called an "unfold" or more generally an "anamorphism". It's type looks like: const unfold = (fn: (state: B) => [A, B] | null, initialState: B): [A] => { ... } and you would use it like: const results = unfold(nextToken => { if (!nextToken) return null; const { data, nextToken } = callApi(nextToken); return [ data, nextToken ]; }, ""); The implementation is left to the reader, turns out "unfold" is a pretty useful higher order combinator that pops up everywhere. Obviously it's not a javascript builtin and obviously we don't do promises here etc but yeah if given a toolbox of higher order functions, we usually don't need to recurse.
The song name in the outro music is called: Novembers - Just Ripe (Album is called Pour Me a Cup of That) I don't like the idea of paywalling the song names fam
@@BlackPenguins17 That's crazy. How would you know - does he show it somewhere? I cannot for the life of me see that that would be productive, vs using an animation program. I wanna learn how :)
Please make more videos!! Ive never had the nuances of programming seen explained this well and I think this is really valuable! Well done and thanks!!
Dude... your videos are just so enjoyable. Been coding professionally for over 20 years by now and still I love to watch your videos. I sometimes even learn a thing or two. Keep them coming, you are really awesome and make coding more accessible to everyone.
If you're already writing a bunch of procedural code, and using all your language features, you should already be intuitively doing all this (If you've been coding long enough anyway). I've noticed that LLMs almost never give you functional code unless you're super specific in asking for it, and even then they will often mess up, and go back to managing state. This is because most people aren't optimizing, and so most the training data isn't optimized but I digress. The video was beautiful.
Love your videos, they break down concepts very well. I’ve been doing Advent of Code in Rust and functional programming goes so well with the language. Though can’t say it’s 100% functional, too many for loops.
So I watched about 5 of your videos, and I felt myself saying to things like "don't use comments" that this guy is taking everything to the extreme. Then about a week later, I found myself really cleaning up my code using different techniques that you've discussed, especially about inverting the logic of the if statements! I understand now that having knowledge of these different styles doesn't mean you have to use it 1000% of the time, but it really helps to sprinkle it in here and there and made your code that much better! Thanks my guy, you definitely earned my sub.
This is a nice video! I'm extremely a fan of declarative paradigms, but it's quite hard to get others to understand why it's cool. Functional is just one step there. Stuff like logic programming is even more intriguing, though haven't have much opportunity to get into it yet. At least SQL is known by everyone and IMO one of the best arguments to be made for people dissing on declarative - imagine writing this complex SQL query manually! I think that should help people understand the value of declarative too.
I love declarative stuff as well. I do have to say that it is very often not the best way to solve a problem, but in cases where it does work, it is often by far the best solution.
@@joranmulderij Dunno about the domain you work it, but for me it's almost seems the best, at least as bulk of code. As video author said yeah you need to wrap it around on edge IO cases, but bulk imo very often can be done that way. At least in web dev and shell pipelines. Also a lot of times there it seems to not be the case IMO existing surrounding code is the reason why and not that it would not work. Just some imperative stuff is so proliferate that it's very hard to do work with it. Imo in future it will be declarative almost always everywhere, at its way more composable, and also giving way more leeway for compilers/systems to decide on how to execute (think SQL changing execution plans automatically based on what it knows about indexes/data stats and what not). For me it seems like a tragedy that imperative was allowed to poison software development for so long. But then, as you can see I have strong opinions :D
@@morphles The main downside to declarative programming is that it is way easier to get yourself stuck. You really need to "design" the interface. But once that is done and your use case fits tightly without what the declarative system was designed for, then the DX is amazing. I'm currently writing a declarative nodal reactive state management library with two way data flow, which would allow you to have a full-stack reactive system without getting your hands dirty with caching mechanisms etc.
in the context of software development, mutable states are allowed if they are local to the functions. And vois la, just like that, loops are back in business, and you don't need to rely on recursion you might blow up your callstack if you are looping of a large dataset
i watched this video months ago and thought the non mutable idea was pretty cool'. but i took it on board. now i never write anything thats mutable and my code is so much better for it. i still use normal for loops tho. improved my coding dramatically. thank you so much code aesthetic!
HOLY CRAP this helped me so much. I have written recursive functions and used them and even explained them in coding interviews but the way you broke it down here helped me understand even more! You lost me a little after the halfway mark but that just means I need more practice and more exposure to. Hella dope, thanks again!
TBH Functional Programming is very much a means of carrying over principles from analog data processing (such as control theory and analog computing) into the world of digital computing. Filter design, block diagrams & transfer functions, feedback & feedforward, hysteresis, etc. are all from the world that existed before digital took off.
There are actually multiple hardware description languages, used to describe circuits to imprint on a silicon die or an ASIC, that are based on functional programming or simply are functional programming languages. More traditional HDLs like Verilog and VHDL are almost _weirdly_ imperative for something intended to model essentially a pipeline of gates and circuits wired directly into other gates and circuits.
Even in academic mindset, isn’t replacing a for loop with recursion just means that we are replacing explicit state with implicit state (meaning call stack memory)?
Fantastic video! I love FP and dislike the F-Bro lingo as well. My gross oversimplification of FP to regular programmers has always come down to: 1. Write more pure functions. 2. Use more immutable variables. Nearly all the complexities of FP can be derived from making these two happen, yet MANY good, simple patterns in any language also stem from these.
Prof. who teaches Java here, and I have fallen in love with streams. Kotlin in particular has some absolutely gorgeous lambda based stuff in their stdlib.
As a JS developer, the best extract I got from functional programming is being mindful of how I funnel state changes in my code. Pure functions help a lot, as well as understanding the difference between a shallow and deep copy. And yes, I'll favour map, forEach, reduce, along with most array methods, over imperatively written loops.
Be aware that in javascript, many of these operations will have significantly higher CPU and memory overheads vs more traditional approaches, particularly with how much JS loves to mutate and copy arrays under the hood. This is not to say you shouldn't use them, composing reliable and easy-to-read functions is an extremely powerful way to write easy to parse and easy to debug code, but it should be applied carefully and checked for performance when used in performance-critical areas of code. As someone who writes a lot of performance-critical JS (irony, I know), I generally avoid them for that reason, but they have their place.
This chanel is just pure pure gold ❤️ I have exactly the same opinion about functional bros but I almost came to a point I felt bad mutating a state even though it made the code do the right thing in a clear and readable way. This video spackled joy in my heart :)
One problem with functional programming, at least in Javascript, is that the performance overhead is quite large. Constantly making new arrays and objects significantly slows down the code. Mutating objects is just so much faster, which is unfortunate, because good functional programming is so fun to write and read!
Which is why going for a language that has functional programming as a goal from the beginning is a huge advantage. Most of the overhead is mitigated by the compiler making the right decision in those cases. Like, in #fsharp, there are cases where the CLR restructures your code to be procedural imperative style, and gives you the perf benefits of that. I think Ocaml does it too.
I primarily use javascript, but this is one of the reasons I really want to use Rust. You get to do functional iterators that don't have that overhead, and it allows for mutability too.
Great video as always. I'm not a F bro, but in my classes, sometimes using map, filter, take, pipe etc.. makes my code simpler than write pure imperative code. In the next video, what about data oriented programming, it would be great seeing you explaining about some of the most famous DOD pattern, Entity Component System
Mutating state in JS is how you make things faster. It just is. The more array methods you do, the worse it gets for garbage collection because every new map() and filter() call creates a new object and copies all of the key pointers to the new array. Also recursive "data pipelines" as described are just a neat way to speedrun stack overflows and increase memory usage. In short, most of the "clean" code these days is just a direct downgrade from regular for loops.
Usually you don't actually need to have most of the code be faster. Like in this case the difference in time taken to send a web request to the users' bank for their transaction history will be thousands of times slower than the processing loop if you're running it synchronously. In a program like this, you're unlikely to run into performance problems unless you have many many users, and if you do, you should probably switch over from JS into a systems level language anyway, that is, if you can't just pay another £100 a month (a lot less than your lawyers) to increase the server size and stop the performance problems anyway.
If your expensive operation (A) takes 100ms and you reduce it to 50ms by switching to C++ or Rust, it won't matter if A gets called 1000x instead of 1x. The language won't help you from hitting some kind of limit if your code is bad. Taking functional programming to the extreme requires rerunning a lot of code because you aren't storing any of your past work. And if you are it's stuck in a closure which is more tedious to access from multiple places in your code. Functional programming has some good ideas, like avoiding side effects as much as possible, or *not* turning everything into a an abstract factory builder class. But like anything, you need to understand why you're doing the things you're doing without being ideologically attached to a narrow paradigm. Sometimes classes are a natural fit for some piece of data, sometimes you just want ephemeral functions that return and leave nothing behind. @@tupoiu
One issue is that many of the more well-known functional languages are a pain to get into. Scheme is easy to pick up at first, but it quickly becomes challenging to tackle problems that are a breeze in other languages. Haskell is wonderful, if you can ever get it to compile. Some of the newer functional languages, though, like Clojure and Elixir, make FP much easier to get into. It is probably true that the most useful languages take some functional features (e.g. Rust), but it's good to have some experience with functional programming so you know when it's useful to bust out the maps, filters, and reduces.
I've absolutely loved LINQ in C# for years, but only after learning Rust and more about FP in general, and I realize now that it was the use of higher order functions and FP paradigms that I enjoy so much. Also, I was blown away be the realization that Tasks are monads that I've been using this whole time...
I write C# in a functional style, mostly, but monads, functors etc. Aren't part of my daily vocabulary. If you want me to tell you what part of my code is what, I'm not able to do it 😂
Actually I am concerned about the tips being added afterwards. If they don't physically have my card they should no longer be able to charge it. It's a broken system.
Bad marketing for different paradigms is rampant across the programming discipline. At this point, I actively ignore its propenents until I've had a chance to learn more about it. Ironically, they suck the fun out of it for fresh newcomers.
As a person who is extremely repelled by functional programming at first glance, this video really helped me take a better look at it. Might try this programming paradigm with some of my projects.
Definitely don't do it in JavaScript like he did. Its not a functional language and doesn't fully handle the paradim. Instead use a language like Rust, everything he did here can be condensed to nearly a single line.
@@amaryllis0 the point of FP is to show what your doing over all. Quickly at a glance you can see your filtering mapping and sorting an array of data. Spreading out across multiple lines gives no advantage and ends up just being messy and more likely to loose performance gains. For instance i have a project where a user can put in a phrase and it transcribes it to a fictional language All i do is User_Input.chars().filter(|c| c.is_ascii_alphabetic() || c.is_whitespace()).collect::().to_uppercase().split_whitespace() With this you can quickly and easily see I'm going through the characters removing anything not a space or english letter and then turning it into a string then uppercasing it and splitting it by into individual words. Its quick, clean, and concise in its purpose. And i can do all of that in a single statement.
Functional programming as an all encompassing paradigm just isn't useful but that is what is frequently marketed. The whole point of most applications is to produce side effects and a programming style that excludes them is obviously not going to get the job done. But as a preferential style it is incredibly useful. Rather than writing code with no side effects, having a goal of removing all unnecessary side effects can have a huge effect on increasing the stability and readability of your code. When you isolate and tuck away all of the stateless code in your program, the actual necessary and relevant state just falls out into a few places where a previously incomprehensible code base becomes much clearer and easy to maintain.
You’re explanation with visual of currying made it make sense to make. I literally sat there dumbfounded with how powerful that is. 8:39 REALLY, really great explanation and great video. Thank you.
My gripe with pure functional progamming is understanding the state of your code (what something is and when) is a large portion of understanding how the code works too. If I run into a call stack of 15 functions it is incredibly difficult to figure out whats going on. Same with recursion, you take something as intuitive as a loop that you can see and follow (Do the thing as long as this condition is met) and you turn it into something that has no intuitive representation in the code, something more abstract and hard to understand for the human brain. There are times where both of these things are a great option, but for most things its important to know and have a state to follow
Also, if you need to maintain this code, it can be much worse than something more "old-school". Some changes might require you to completely break apart the function call stack and rebuild it from scratch. Often you actually want side effects. Anything that can be done without it, is generally quite simple code anyway. Basically static functions. And it is just harder to debug overall. Good for simple stuff, gets harder as real life issues intervene.
@@Sande24 "Some changes require you to completely break apart the function call stack and rebuild it from scratch" - this is the same in all programming. Shared mutable state (two objects that change the same value) is very hard to debug, and functional programming goes a long way towards reducing it. There are definitely some things that are conceptually easy to represent as a for loop with mutability, but often what you're doing is just a .map or could be separated into a couple of .maps and be easier to read.
Trust me, it's just as easy to follow functional code as it is for non functional code. Even trying to understand flow in recursion is not as difficult as it seems. The condition you check against is just in a different place than at the top of the loop. Try some functional languages and you'll quickly realize what I mean. If anything I find it easier to follow data through code because I specifically declare what I want my types to do, say (Int -> Int) -> Int -> Int I want a function that maps an int to an int, then applies a function to the result and another int and the result is an int. I distinctly know what type I want my function to have as an in and output. This makes it far easier to know the state of your data at all times in a chain of functions.
@@Finkelfunk I like functional code. But only when it does only a few things and then stops. I've seen plenty of complex functional code that does otherwise. If you have 10 map functions in the stack and you have to understand what is happening to the initial data, it can get overwhelming pretty fast. Passing functions as parameters is the worst - harder to see what applies to the specific data unless you go back to find the function that is passed into the call stack. And if it can be different based on a conditional, that condition might also be hidden away from the normal call stack so you dig even further. Every time you read that code, it's going to be the same kind of obscure flow that you have to look into until it be comes specific in your head. The point is that you can't read the code top-to-bottom but you now have to mentally know the order of actions and jump around different methods more. It's easy to build and easy to work on when you already know what it does, but for a first-time reader it would be a much steeper learning curve. When things get more complicated, you should look at what the drawbacks of each approach are and choose a proper one. I'd say that immutability is often something that you don't really need and removing it would make things faster. Saying it again - functional style is nice. Just don't overdo it. Every approach has a drawback and you have to choose which to use. Not only defaulting to one all the time.
@@FinkelfunkFunctional programming for a small component or service is fine. For _all_ components for a real world app with teams of developers of various backgrounds who come and go and real world deadlines where you need to add a feature "yesterday", yeah not so much. Programs that are fully functional may work for hobbyists or niche tools, but real world applications are predominantly built with OOP.
I love how Rust does it with iterators. It’s effectively a decorator pattern that results in an iterator that only does all the computations when you actually do the iteration. In this way, the collection is only iterated through once no matter how many operations you perform through it. You can map and filter and the rest several times and still only do one iteration through the collection to do all of that.
"I love how Rust does this! You see... *_proceeds to explain something literally every programming language under the sun has been doing for 20 years_* " True Rustacean moment
So why remove the for loop in the first place? I understand that it creates state in a function, but despite that the function still does not access any *external* state, so it should always return the same output for the same input. And its much less complicated than doing all of the other stuff.
Loved the visualizations! The elegance of the map/filter/reduce approach towards data pipelines is attractive, but I think it is still useful to consider the “good old” for loop - especially in performance oriented situations. The overhead from passing/calling predicates and performing additional loops can bite you when low latency is important. Though, often, there’s probably better places to optimize first. 😉
Certain things have many excited proponents that can't explain "why it's good" to anyone but each other. (Like, in my opinion: IOC, DI frameworks, fluent syntax.) I find most of these aren't worth using in pure form most of the time. However, my takeaway from functional programming class was that I felt extremely certain how my program behaves. After I got over the big mind flip! It's data processing didn't stick in my mind.
You are basically using IOC when working with frameworks. Let's say you have a game engine. Basically you just put your code in custom class and implement a couple of callback methods eg. Init() and Tick() and these methods will be called by the framework itself. It's good because you shouldn't care about who is calling these methods, what is the right order and preconditions, framework just doing it for you. Why is it good? Because you can abstract yourself from some things and focus on your features, which is basically why people use frameworks. DI containers are essentialy a mechanism for constructing your objects and providing dependencies. You can sure do that manually in composition root, where you build all your objects in specific order so all constructors can receive valid dependencies, and objects that created internally have their dependencies too, so it gets quite tedious and not very productive. With DI framework you can just define that "Foo is provided for IFoo as singleton" or "Bar is provided for IBar as new instance each time". Then if you want to add new class, you just write its code as usual, list all dependencies in constructor, then you bind it in container and it will resolve automatically providing all dependencies for you. Want to add new dependency? Just add it to constructor and it will just work. Specifically in games if you want to create new object from factory, factory don't need to know all the dependencies required for an object, DI container can provide all the dependencies for you. Isn't that good?
All of those patterns are FP in disguise. Inverson of control is just making use of higher order functions that call into your code. an interface is really just a record of closures. DI is the same as js modules, nothing new or exciting, it's just a workaround in pure OOP languages because they don't allow code outside of classes. fluent is just functors
Adding some ducking could help. Keeping the music in to get the smooth ambiance and mood, but seamlessly reducing the volume by maybe 5/6 dB whenever the voice come in. That can easily be done with most simple gate plugins.
I love monads because they are impossible to understand theoretically, but take a half second to understand what it's doing when you actually see one even if you have no clue how monads are supposed to work.
One thing that would be great to mention at the end, is that in JavaScript, all of these built-in methods evaluate eagerly. Which is fine for small, synchronous sets of data, but what happens if you'd like to read the data directly from the backend - i.e. our we don't have an complete array, but our data items are fetched asynchronously? In the example, we only want the top 10 results for our dashboard, so we could stop iterating the transactions once we've satisfied that limit. With current code, we always iterate & filter through all the results, and then discard everything that's beyond the top 10, which is not very efficient. It works with simple examples, but when you start looking at situations with thousands complex data entries, this adds up and will have performance implications - both on execution time, as well as memory usage (our runtime creates many intermediate objects/values, and the garbage collector has to work overtime). This is a situation in which libraries like RxJS and IxJS can help, as they enable you to use functional style pipelines lazily, also on asynchronous data sources. Observables are coming to JavaScript natively, so hopefully this will be easier to achieve without additional libraries.
@@shinobuoshino5066 there always is, nothing is ever completely pure. Even in synchronous loops, each iteration of the loop will change the state of various registers within the CPU - index registers are updated, comparison flags are set, and the program counter is adjusted to jump back to the start of the loop. Intermediate objects might be created and garbage collected. There's no escaping the constraints of the real world (and hardware). Whether we retrieve the data from local memory, or from a remote server only differs by the underlying complexity of the iteration's execution, and by the addition of waiting on another thing to be able to start executing the loop code again.
That's the next level of FP... it starts with pure functions and pipelines, but then introduces other types (like the scary "monad") which are off-putting words for simple concepts to solve this problem. But IMO they're worth it, because they really simplify error handling, and make it impossible to "forget" to handle errors. They bring errors into the normal flow of code, so you treat them with the care they require, rather than just slapping on some error handling after-the-fact
Well It's still fun, Monads has a type which is called Either it's basically so useful to return errors, you either take return left or right, .map, filter, etc.. works on right and mapLeft, peekleft etc.. work on the left part :)
what exceptions? errors are handled through a sum type, in Rust (which is not purely functional, but has arithmetic types with (imo) better names for some situations), this is done through Result, in haskell the standard is Either Left Right, if there's only one error case (like "the string you passed in is not a valid integer" for a parseInt) you can use Option / Maybe Type
@@LetsGetIntoItMedia does this mean that all functional pipelines must complete regardless of errors and depending on where the error occurred in the pipeline then you get a different error message / stacktrace at the end and then use an if statement to handle both success case and error case to do side effects? is that all this comes down to-the basic alternative to try catch / .then.catch?
If you're looping through a large amount of values using recursion, there's a good chance you'll run out of stack space. At least with an imperative loop, you can overwrite the state from previous iterations, thus saving stack space.
Great video building the concept from the ground up Ironically those of us that grew up with JQuery were encouraged to learn and use this from the beginning with method chaining and now it seems like users of more modern JS frameworks are rediscovering this with ES6 lol
Each masterpiece you craft unlocks doors to learning, inspiring minds to reach for their own artistry. Artful knowledge, skillfully shared, each video a masterpiece to learn from.
"There shall be no state" Enter: State Monad 😂 Btw: many functional languages have an imperative-looking way of using, applying, binding functions, which makes this not as unreadable as you make it look here. In fact, functional code is generally much easier to read than imperative or OO code, as without side effect, what you see is what you get. You can reason about code, which is much, much harder with mutable state, where you never know what can happen, as any part of your program can change the state.
Well said! I'm admittedly a big FP nerd. Sounds like you might be interested in my series! For many applications, the mental shift has been really great. I've been able to "reason about code", as you say, in ways I really couldn't before
The initial example of replacing a for loop with a function reminds me very much of how I would split loops up in JavaScript if I had to do a setTimeout between each iteration. I wasn't aware that solution was "functional programming!"
Functional bro here! Guilty as charged. You're totally right... The concepts aren't actually that complex (a Monad is basically something that has a map() and flatMap(), and you can arrive at the need for that with a few simple code examples), *but* the words can be used to gatekeep or show off your smartness Also, the focus is often elegance for elegance's sake, rather than usefulness, simplicity, composability, safety, testability, etc. Though it is, in a way, the elegant foundations in math that allow FP patterns to get so powerful Also, I do think there's value in the words. It would be extremely difficult for society to function if we never put labels on things... how could we ever succinctly talk about anything without terms for concepts? Learning the FP words are useful not because knowing definitions is useful, but because they help you see those patterns in a problem space and then go r you immediate strategies for breaking them down into smaller bits and solving them concisely
@@user-tx4wj7qk4t Lol what a big non-response from you. Not only were you unnecessarily condescending, you never even addressed what he didn't understand about monads. You never addressed the elegance for elegance's sake argument, and then spent the rest of it inflating your own self-ego about being using functional programming. Then you all wonder why people don't take functional programming seriously. @LetsGetIntoItMedia I think the responder is a perfect example of why functional programming has a hard time making traction in comparison to oop when it comes to marketing it's benefits. A lof of of the folks trying to push it, spend way more time focusing on impractical simple examples that aren't of much help to anyone building applications, and seem to just use it as a way to flex how smart or clever they are.
Hmm yeah, I had a lot of thoughts to that response (which I'm not seeing anymore here, but saw the notification). My take is that I actually agree with a lot of the points that person made, but just absolutely NOT the tone or extremity. I totally agree that engineers *should* be into math, as they are literally writing computer math. But people come from all sorts of backgrounds, and that doesn't necessarily include a love for math. It might just be a love for creating stuff from more of a design perspective, or just a plain need for a job. And that's good, because we get a variety of perspectives and experiences in the field. People often *don't* think of math as something enjoyable, or realize how much code is like math. That's not a problem, that's an *opportunity* to share a new wonderful perspective. I also agree that FP isn't as off-putting or "gatekeepy" as the stereotypes suggest, but that's because I'm a math nerd on the side. But fact of the matter is, it *is* a stereotype, which means many people think it is unapproachable, and therefore by definition it *is* unapproachable. If most people agree that a balloon is red, then it probably *is* red. There is jargon in OO as well, that's for sure. And jargon isn't a bad thing. It's a way to capture a whole concept in a single word. So if everyone agrees on its definition, it makes communication much quicker and more efficient. *But* that's why, when talking to people who don't know those words, you have to do a good job explaining them. The problem is, based on the general sentiment, that people *don't* do a good job explaining the jargon, which feels like gatekeeping. Also, re: my definition of a monad, of course it's simplified. There are monad laws and all that, but that's exactly the stuff that turns people off. The average person doesn't need to know the exact precise definition of a monad, just some practical examples of how they can help simplify problems. Whew... I wasn't sure if I wanted to respond to that message, but I decided to make my perspective known. There's an *opportunity* to make the community better by *proving those stereotypes wrong*
At first I thought functional programming would take more work to learn and implement into code than OOP, then I realized by the end I already do a lot of functional programming using the built-in functions.
Situation is currently this one: Programmers control a database via the non-functional language SQL which is translated by the database system into an operator tree, i.e. a functional program, for optimization. The database is programmed in an imperative language which the compiler translates to a functional internal register language for optimization. The result of the optimizer is written to imperative assembly language code. The CPU analyzes data dependencies and reorders instructions accordingly, that is, it would also benefit from a functional machine language. Summarized: Functional programming already reached world dominance but at all occurrences it is pretended that imperative programming would be the normal way of programming, would be machine oriented and efficient.
Haskell bro and Lambda enjoyer here: I have to admit, we _seriously_ have a problem marketing such clean and cool programming. I once showed Haskell to a friend of mine, and he was super skeptical at first. By the time I got to infinite lists, lazy evaluation and the lack of conventional if-statements he was baffled how beautiful and simple code can look and feel while being so insanely complex. Our professor from our lectures on higher concepts of programming put it best when he said that you have 3 lines of code, they compile to an entire ego shooter, and once you try and understand the code you will fail for the first 4 hours, after that it's gonna make you cry because it's the most beautiful thing you've ever seen. Never in my time working with languages like C++ have I looked back onto code I wrote so many times and thought to myself: "Damn, that's really beautiful code you wrote up there". I _seriously_ recommend anybody to try out functional programming. The borrow checker is nice, but it can't prove mathematically that the code is side effect free, no matter how hard it might try.
Maybe it's just me, but if I need 4 hours to understand 3 lines of code, those are not very good lines of code and I don't see any beauty in it. I don't understand the obsession with brevity.
@@cloogshicer The problem is not that they are brief for the sake of brevity. Obviously that was a bit sarcastic by him but at its core, he was very right. The beauty of functional code comes from it being so clever and thought out. It's not like some old 90s Java legacy code deep in the basement where you take 4 hours because you have no idea what the author even tried to do and the knowledge is lost to them and god alone. It's the way you approach a problem in an extremely smart and coherent way to condense it into such a simple expression that you first need to wrap your head around what is exactly happening under the hood. Why types line up, how functions play into one another. Those hypothetical 4 hours are mostly spent figuring why the solution works the way it does and how all those puzzle pieces click, not trying to understand the code. One upside of functional programming and lambda calculus in general is that mathematicians sure know how to make an intuitive notation readable once you know a few concepts. Practically anybody can read Haskell code (and far easier than C or Java mind you), but actually understanding _why_ certain aspects work is a whole other level. It's a lot like solving a Rubix cube, it's extremely simple to twist and turn but figuring out why a certain number of twists and turns give specific combinations is quite satisfying - and once you've solved it you appreciate its beauty. It's hard to pick a specific example here, but there is nothing quite like having an insanely precise and optimized approach to a problem which takes time to wrap your head around because the person who thought it up actually spent time and effort doing it.
@@Finkelfunk In my opinion, beautiful code is code that is easy to understand. Brevity and elegance, in my experience, doesn't serve understanding. I see code as mainly an educational tool for the next developer (or myself, in 6 months). And brevity/simplicity/elegance doesn't help with that. Otherwise, we wouldn't have textbooks, and physics students would only be handed the final equations (+ any definitions they're made up of) and left to figure out how everything works on their own. This is what functional programs are like to me.
@@cloogshicer Let me reemphasize: The code itself is not the issue. It's not obfuscated bash syntax. Like I said, I am pretty sure you'd understand Haskell code with relative ease without ever having written a single line in that language, and you'd do so much easier than in C. It's sometimes even easier to read than Python code because the notation is descriptive and simple like you'd be used to in mathematics. The code is a clear stream of functions, a into b into c into d. The syntax is very clear and descriptive, functions like "dropWhile" or "splitOn" are not exactly hard to grasp. The beauty and complexity comes because of the way people start to think about problem solving once you stop declaring 15 helper variables and push data from a into b and back. It's a different way to approach a problem which makes the solutions much more compact and efficient. As people have elegantly put it here: You are much more easily able to reason about the code, because what you see is what you get. In C this is simply not possible because of all the noise surrounding the code. You start to think way more about the flow and shape of your data and how to manipulate it in effective but concise ways. That's the beauty of FP and I seriously recommend you give it a serious go. It will only serve to make you a better programmer in the long run.
@@Finkelfunk I've written some Elm and Haskell and let me tell you, it is not easy for me personally at all. I find imperative code much easier to understand. Especially recursion is very difficult for me. And I have over 10 years of dev experience in other languages. You say that "what you see is what you get" but what I feel like a lot of FP-affine people keep forgetting is that for each function definition, you need to understand all the definitions it's composed of, and so on, recursively. For simple problems this isn't an issue, and sometimes you can skip entire parts of the tree, but most of the time you can't.
Great video, you left me wondering though about how recursion resolves these functional problems. Isn't recursion just pushing the existing work into state somewhere? Additionally I'm now curious how parallel processing works for map/reduce functions.
@@charlietian4023 No. That is a basically a strawman. In FP one would use a higher level function that does the loop. Like `map`. One would not write it recursively. That is idiotic. Recursion is applied when a problem is naturally recursive. Like processing a tree-shaped data structure.
@@KX36 they can be if you’re trying to optimize heavily or as the programs complexity grows. My point is the difference is so small that it won’t be a performance problem for most programs and you should choose the more maintainable option.
You can rest easy knowing that you wouldn't even begin to comprehend the amount of batshit certified insane optimization that is generally done in a functional programming language's compiler.
That is why tail-call optimisation is a thing. Plus, people rarely write straight recursive functions in FP - the composition of map, filter, etc. is sufficient in maybe 90% of cases - these functions are all heavily optimised.
I really enjoyed working with these functions in Angular. Mostly with rxjs though, which I find incredibly intuitive. Though I still used state everywhere, but I think just for the things that actually made sense.
![[MPD직캠] 베이비몬스터 직캠 8K 'LIKE THAT' (BABYMONSTER FanCam) | @MCOUNTDOWN_2024.6.13](http://i.ytimg.com/vi/8qa-nm9bCLs/mqdefault.jpg)
Code Aesthetic: Makes a whole video about being a "never nester"
Also Code Aesthetic: 4:10 puts an entire function's logic inside an if statement instead of using a return.
As well as multiple early returns within the if 😂
Early returns are not there in most functional languages. So it's not common to use them. The same is true for local variables. Creating them usually requires a `let ... in` construct so they are also avoided
The fact that he chained function calls after function calls... it has the same effect to the call stack as recursion does... smh right now
Judging from their second channel and their website, I think they've been on a journey to rediscover non-OOP and computer science since the never nester thing. Also, it's not a bad thing to change your mind.
My guess is it was just for ease of understanding.
He's showing how the condition moves down to the recursive solution so any change there is not necessary for the point.
Would've been nice to see him do the solution in the video and simplify it to flatten the if statement.
Lambda calculus (which most of the FP is based on) is not just about purity and statelessness of functions and converting loops to tail recursion calls. It ensures transparency of the functions. The entire tree of terms is always available. Which means, the compiler can reduce expression trees, sees data access patterns, can replace operations and data structures with more efficient ones, eliminate effectively dead code, etc., and do so across the function calls. These techniques are used even in imperative language translators (e.g. GCC and Clang), but they are tied by unpredictably mutable state.
But full immutability also makes a lot of things harder. I implemented a compiler in Haskell once. It was not fun, at all. Want to modify a syntax tree while type checking it? Have fun rebuilding the entire tree, which is both error-prone (accidentally changing left-hand side and right-hand side of binary operators or using older (not type checked) nodes) and makes code harder to understand. Or you can use the same syntax tree and make the same checks every time (like dealing with == operator for arrays differently). Or maybe there is some fancy way of doing it with a shit ton of abstraction that I couldn't figure out because I don't have a PhD in category theory and computer science. Ironically, Haskell taught me the beauty of procedural programming.
@@user-tx4wj7qk4t the comparison between mathematics and programming is weird, because they are mostly unrelated in this context. Even if you want to go along with it, mathematicians use a mix of mathematical notation and kind-of-imperative natural language, 'cause explaining everything using only maths and logic would be unreadable.
Maybe functional languages are good for toy compilers (that probably use parser and lexer generators), but any serious compiler like gcc or nodejs uses procedural/imperative style, with hand written parsers. Most of the widely used languages combine procedural or imperative with other paradigms.
It's weird to say that procedural style is garbage when Haskell literally reinvents it. What is a state monad? It's Haskell reinventing mutability. What is IO monad? Just statements in imperative languages. Why do you need those if functions are so good? Cause you can't program in a convenient way using only functions without adding a shit ton of abstractions and concepts.
To be fair, these optimizations also happen in imperative languages, especially if the compiler does effect analysis. Of course, guarantees are more reliable than compiler inference. This is not to say functional languages always yield inherently more performant programs, that should be left up to benchmarks in practical applications.
@@user-tx4wj7qk4t you completely missed the point about mathematics. Are math articles/books written in math notation only? No, because it's unreadable. Do teachers throw pure formulas at students? No, they explain it with words + show some formulas/definitions. At no point did I claim that mathematical language is imperative. "How to prove X? Show, this, this and that", that's pretty imperative. Whatever, this discussion is pointless, you seem to be one of those pure functional programming zealots.
@@user-tx4wj7qk4t "It definitely doesn't make things harder, that's why mathematicians use "immutability", aka real variables. No mathematician is writing "imperative" math."
this is factually incorrect (and a misunderstanding of mathematics). If I define the variable x = 1 in one context, and x = 3 in another context, my x is not universally immutable; it is contextually immutable and it may be a different value in a different state. Not to mention that there is an entire category of mathematical functions that are iterative over some mutating variable en.wikipedia.org/wiki/Series_(mathematics)
sorry, you got the wrong person, me and my lifestyle are DISfunctional.
Dysfunctional*
Dusfunctional*
Dizfunkshunul*
Rizzfunctional*
Deez funkshions are belong to us
I learned functional programming via F# and Clojure, and came away with a rather impure lesson: You only need a SUBSET of pure functional concepts to write great software. I've found that in most languages, you get 80% of the benefit from 20% of the tools: Referential transparency via expression-based programming; no state or local-only state (avoid global state or state passing at all costs); chained stateless transformations, via things like universal function call syntax, pipe operators, map, filter, reduce, and comprehensions; a strong preference for passing around and transforming simple data structures, such as records/structs; liberal use of tagged unions/variants to create exhaustive conditionals that make illegal states unrepresentable; and making functions short and sweet, which allows for minimal nesting and easy naming. Your program then becomes a pyramid of calls to what is essentially a DSL.
Hard agree. I’ve been all the way down the FP rabbit hole and back again. My takeaway is that the biggest bang for your buck is functional style state management. Usually there is a framework that does this for you. Use it.
Agreed, using imperative code inside the local scope of a function is a good trade off to maintain simplicity and performance, so long as your exported function maintains referential integrity
F#❤
I somewhat agree. But then, what are examples of stuff you consider to be functional but out of that subset you mention? To me, you summed up what functional means, and I don't get why you would call that an "impure lesson" (other than for the local-only state). 🤔
"Your program then becomes a pyramid of calls to what is essentially a DSL."
*Lisp curse intensifies*
Seriously look up the lisp curse by Winestock. The problem is that in a team of 5 people, they'll be able to come up with at least 6 different DSLs for the feature set. And which one is the most correct is usually dependent on future unknown expansion of feature set.
Now I am wondering if I was hanging out with anarchists or functional programmers that one time. The state existing is antithetical to either of these groups it seems.
Recursive functions can be scary because it can lead to very long call stacks and stack overflows. I recently learned about tail calls which some languages can use to avoid this. Essentially, if the last line run in a function is another function, the rest of the resources from the completed function can be freed up. I learned about this from Lua, but it looks like there is some compiler support in C++ as well
Same thing exists in Scala 😉
Scheme's spec mandates that implementations guarantee tail recursion. WASM has a tail recursion extension as well. JavaScript was supposed to get guaranteed tail calls, but it was veto'd by Apple and Google IIRC. A lot of compilers (for example Rust's) will do TCO or tail call optimization, but this isn't guaranteed, so I personally find it annoying to rely on. I don't want to write higher level code and then check the assembly to see if it's actually optimized the way I want it.
Of course it's basically guaranteed to be available in functional languages like Haskell, OCaml, Elixir, etc.
Even though it works, it really feels like a hack. What if the compiler accidently does not recognize this for some reason? Then you have unexpected behavior that might also be hard find out about.
@@SimonMeskens in case of Scala if you want to make sure you can use a simple annotation. If you write something wrong compiler will tell you right away
@@joranmulderij once you get used to it, it's simple enough to reason about. for example, if i want to write a non-tail recursive factorial, it will look like this:
func factorial(int n) {
if n
Important to note that in JavaScript, Array.sort() sorts the array in place. However, ECMAScript 2023 introduced a new non-destructive method for sorting an array, Array.toSorted().
PS. It also introduced Array.toReversed() and Array.toSpliced(), non-destructive alternatives to Array.reverse() and Array.splice().
now if only they'd give us summed, grouped, unique, and partitioned.....
yes, you can do literally all of that in `reduce` but reduce is notoriously easy to write and hard to read. also, they have you put the initial value _after_ the function, which is just sacrilege.
@@Bliss467 the initial value after the function is correct because in bind-order the function is what you would bind first when specialising it under partial operation
Can we petition to introduce Array.toMapped, Array.toFiltered, etc. that mutates the original array to just really destroy the souls of new developers?
@@cadekachelmeier7251 I think those functions are both ridiculous though.
Array.prototype.toMapped = function(transform){this.forEach((e,i,a,)=>{a[i]=transform(e,i,a);});};
// this just uses for each!
toFiltered would either be inefficient OR take up extra memory.
inefficient way:
Array.prototype.toFiltered = function(condition){
// yes, this for loop is horrendous
for(let i = 0, c; i < this.length; c?(i++) :(this.splice(i,1)))
c=condition(this[i]));
return this;
};
extra memory way:
Array.prototype.toFiltered = function(condition){
const f = this.filter(condition);
// apply is used because ...ellipsis is slow
f.unshift(0);
f.unshift(this.length]);
this.splice.apply(args);
return this;
};
@@Bliss467 Object.groupBy now exists!
This was a really good execution of a 3b1b-style "rediscovering the fundamentals from scratch" journey. Also, I have a sudden urge to take pictures of my receipts and upload them somewhere, but I'm sure it's completely unrelated
Google Opinion Rewards gives you $0.10 to $0.20 of google play credits every receipt. #sponsored
Heyy, you're that rivals of aether mod creator. I see you 👀
and he declared war on CODERIZED channel also⚔
woag
The functional emphasis on reducing state and minimising side effects also, in my opinion, greatly helps with reducing code complexity in the way described in "Philosophy of Software Development". In that book, he emphasises creating modules or functions with deep functionality, and simple interfaces. If your functions are pure and have no side effects, it simplifies the actual interface and avoids information leakage - you only have to know what the function explicitly does, what its parameters are, and what it returns. The implementation is entirely irrelevant. I've definitely edited some people's code where I've been confused by bugs, only to find that a function somewhere is sneakily mutating the state of the code when I'm not aware of it. Having a guarantee that a function doesn't do such a thing is really useful when trying to quickly understand and use a system. I think something like naming functions which are pure as this_is_a_function_P and ones which have side effects as this_is_another_function_Imp would potentially help, provided people do stick to those rules. Just my two cents!
With JavaScript, you can customize ESLint to give you errors or warnings when a function modifies its inputs. You can customize the rule to not report errors if your parameters are written with a specific pattern. I configured it so that if you intend for an input to be modified (like when using an array.forEach()), your parameter name should start with "mut_". We have eliminated non-pure functions thanks to this
that should be something that the compiler enforces, for example in swift when you want to change some value of the containing struct inside of a method, that method has to be explicitly marked with the mutating keyword, otherwise you will get an error
so you want a const guranatee? we can have that in oop too :)
@@voidmind that fixes part of the problem, though it still doesn't stop you having some class method foo(int a) {b = a; self.c = 20; return b}, so doesn't guarantee pure functions as side effects are still possible. However, that sounds like a good approach to do this in a language which doesn't enforce these kinds of rules
@@LosFarmosCTL yep, or rust for example has all data as const by default, which is a much better way than the standard mutable by default approach, though I doubt many other languages will adopt it sadly
This pipeline approach is one of the things I love about Rust. In JS, the array methods operate on the entire array at each step, whereas Rust iterators work on a single item from the iterator at a time across the entire pipeline.
That's one thing I'm always a little annoyed about in JS, the functional methods are *only* defined on arrays, not iterators. Which sucks sometimes. Apparently they are in development on iterators but its not implemented everywhere, including node.js, so like... not really usable
@@electra_ Yeah the tc39/proposal-iterator-helpers seems to be missing the implementation step. I'm really excited to get something like that in js.
C# LINQ also operates directly on the IEnumerable. So it does everything item by item instead of always processing the whole collection.
@@MegaJoka100 yep, god I love enumerables because of that lol
Also, JS copies arrays in ram to work on them (which sucks even more if you chain multiple of those functions together), while Rust "resolves" your chain of functions at compile time. It's part of Rusts zero-cost abstraction philosophy. Rust is awesome.
Take note that doing FP in JS may induce a steep performance penalty, for you are allocating a new array at every chained step and copying the data. And in most cases the runtime cannot optimise this because the closures have no pureness guarantee (i.e. may have side effects).
If you want the true functional experience, learn SML or Haskell. If you want the practical functional experience and still keep your sanity (i.e. the choice to opt-in/out at will), learn Rust.
I like rust less as its not actually functional, instead the trait system is quite good.
I'm not sure the performance penalty is at all something to worry about in web dev with JS. What data collection are you working with on a web app directly, that is large enough for performance to take a noticeable hit? Even if we make some ridiculous large shopping cart or whatever, with 1000 of different items added, it would still take a FP approach less than the blink of an eye to process - on an old and bad PC!
I think you're prematurely optimizing for something that would never be an actual measurable difference. In turn, you're losing the FP way which can be easier to reason about and way more concise.
(oh yeah, I said it won't even be noticeable in an old and bad pc with an unreasonably artificial huge shopping cart. If it's a standard budget modernish laptop then it even make less sense)
Imagine if all developers thought like that, software would be even slower. I'm a huge FP fan, but I won't use it for languages that don't have compiler support to make it fast (e.g in-place opportunistic mutation). "Premature optimization".... lol, people really need to stop using that term.@@marouanelhaddad8632
@@user-tx4wj7qk4t By what definition of sane?
You can very easily define an array mathematically, same thing with a circular buffer... @@user-tx4wj7qk4t
As an early career developer without a CS or mathematics degree, I really appreciate how you explain things and your delivery. I would love for you to do a series of deep dives into various principles and paradigms. Whatever you do I'm sure it'll be great and I'll be here for it.
Happy holidays, stay safe 🎄
One of the biggest benefits of keeping things pure is that it's easy to write unit tests.
I am an "FP bro" and must say that your code was a little bit complex. I usually split the pipeline steps into variable assignments to make it more self documenting, unless its steps are very simple.
Totally! Testing is not a way to catch bugs, it's also a great way to force better code design. If something is easy to test, it's probably written pretty well. And FP is great for that since everything is simple input-output. Mocking, particularly, becomes a non-issue
@@LetsGetIntoItMedia Agree 100%. Just like Rust gives a guarantee of memory safety, pure functions give a sort of guarantee that the function does one thing only. Regardless of the logic that produces the transformation. One can even take it to the next level by writing property based tests. I find writing property test very difficult, but for the more capable and skilled programmers out there it can give extreme code coverage.
Ohhh yeah, I find property based testing really difficult in practice too. Because then it adds a bunch of complexity in generating the random inputs, and making sure that you cover all the possible edge cases. That, to me, is not worth it. I'd rather just keep functions small, and have tests be very very hardcoded. Think through your edge cases and manually write them all out. And if a production issue comes up, add that as a new unit test to catch that regression in the future.
One of my teammates once said, "tests are only worth it if they save you more time/pain in bugfixes, production issues, middle-of-the-night emergencies, and reputation than the amount of work required to write them". I think property testing is over that threshold.
@@LetsGetIntoItMedia Good point. What do you feel about using a debugger? Personally, I'm so bad at programming that I actually spend 80% of the time stepping through the failing tests in the debugger until I find the root of the issue. I used to hate the debugger, but now I'm starting to become comfortable with it.
There is no other way 😁 when I was first introduced to a debugger, it blew my mind. (But I'm about to contradict myself. There are definitely other ways, and often necessary...)
But that was in Java, where stack traces are much nicer. In Javascript, there are so many anonymous functions and library code that it makes it much trickier. Particularly in pipelines, since there's not an obvious place to even place a breakpoint. I end up using pipe(fn, fn, a => { debugger; return a; }, fn) a lot. The debugger is still a good tool, but Javascript makes it tricky. Next best thing is to keep trying to isolate pieces of code and run them in smaller test cases. Unit testing is key.
As someone who is trying to learn programming, and has only so far found OO educational materials, I have had a lot of trouble trying to comprehend what a functional approach would look like. I finally get it. Thank you so much! I feel like I have the power to ask better questions now, and keep moving forward.
it looks like a lot of code that noone can read. Because at the end of the day, at the level of the CPU and even before function and data is the same thing.
In my opinion it is ok to concatenate functions in a left to right syntax, but having the ARGUMENT and not the result of a function be another fucntion (so kind of right to left) is just making your code unnecessarily hard to read
in fact this is why SQL can be frustrating sometimes, although CTEs help
@@lucaxtshotting2378 Ah yes because OOP is notorious for being easy to understand, and having no unintuitive egregious anti-patterns.
I recently watched a video on "hardware programming" which I now realize is just basically building functional programs into hardware.
von neumann is rolling in his grave because of you comment
Monads/applicative functors are going to be the next FP feature to appear in mainstream languages I think. The usefulness of piping a transformation that can fail/have multiple outcomes is just so great compared to infinite 'if' checks, scary runtime exceptions, or unpacking multiple lists only to map over them immediately after. Kotlin already has a "access member if not null" operator, Rust is similar with its Result and Option datatypes.
We already have flatMap in js arrays so almost there
I implemented Result/Option in C# using a Nick Chapsas video as reference, and they've been a godsend for cutting down on null exceptions and all the guard clauses to prevent them. If only they were built-in, I'm sure they'd be way better than what I cobbled together haha. Definitely not as nice as Rust, where they're core language featues, but way better than nullable or relying on null checks.
I really hope so! I think the Effect library will do a lot to bring those to TS in a very usable way. I was using fp-ts before, but found it clunky. Effect might make it all usable enough to actually get popular 🤞
@@TheMasonX23actually, neither Result nor Option are core language features; they're perfectly standard data types that you could implement equivalently in user code (the difference is that because they're part of the core _library_ they're ubiquitous in APIs, which wouldn't be the case for a user code version)
@Starwort Well, the `?` operator isn't something you could build yourself, and it makes using Result and Option *so much nicer*.
Never change, functional programmers; never change.
immutable, const
The timing on this video is perfect. I've been on an fp video binge the last few weeks and you have a way of visually explaining things that I've always appreciated.
Have you tried #fsharp?
This video was a really great overview! Since you're on an fp video binge, maybe you'd be interested in the series I'm starting (check out the channel page). I think there's also a lot of value to understanding some of the math concepts... NOT because smart words make you smart, but because the smart words are actually fairly simple concepts that are quite universal, so knowing them helps you see patterns in problems, which you can then solve more simply
@@LetsGetIntoItMediaThanks for sharing. I just watched the first video in the series and I think I'll enjoy the series and learn a lot from it.
@@kylewollman2239 lovely, thanks for watching! I hope you enjoy the rest. And please leave me any feedback on the format/pace/content, so I can tweak the series to be most fun and helpful as possible!
I love the visualisation of the functions!
Btw, you would be super cool if you did a video about array programming! Like with APL or BQN etc. Those are the most aesthetic language in my opinion and it would blow a lot of peoples mind if they saw that video!
I mean he kind of set it up. We now need a video on functional combinators, monads and then we can slowly start to swallow the array pill and have our 20 lines of BQN code that form an Excel clone, a web server, the entirety of Facebook, a missile guidance system, a hospital management software and a smart thermostat all in one go.
you say that like array programming is the next step, but i have my doubts. it seems to lack the composability of functional programming by imposing more arbitrary limitations. from what i remember, there is also a lack of higher order functions in array programming
@@xybersurfer it’s funny that you say it lacks composability when that is one of the strongest features. Code_report (TH-cam channel) has some good videos showing it 😁 also comparing with Haskell. They also have operators (in APL speak) or modifiers (in BQN speak) which are sort of higher order functions, but BQN (the language I write in (I have some videos on my account if you’re interested)) also supports higher order functions in the functional sense. And the restriction (constraining to arrays) isn’t arbitrary, it gives a lot of power and expressivity exactly due to limiting the baseline to a bedrock foundation and building from there using the most flexible and essential functions and making them compostable in every way you’d want. I personally really love them, and if you get your mind into array thinking they’re super expressive, powerful and fun to work with
@@davidzwitser oh then perhaps these limitations are specific to the variant of array programming that i used. i looked at the video "I ❤ BQN and Haskell" by code_report. it's shorter than Haskell, but it looks like write-only code (similar to APL). to me it would make more sense if this form of polymorphism was added to Haskell
Thank you very much! I've only ever learned OOP, and have been struggling to properly conceptualise functional programming for months, but this video made so much sense. Ive been seeing those snippets of functional programming code at work, it is good to be able to better understand the method and thinking behind them.
@@user-tx4wj7qk4t have you considered uploading your own video?
The currying explanation finally made it click for me, good video mate! Also even if a FP lang is not truly "pure" having immutability and the semantics that brings, it gets a lot easier to reason about code.
That's cool and stuff, but this example only works because you only use functions that operate on lists and use fluent pattern. The good thing of functional programming is that you can pipe anything as long as output of previous matches input of the next. Absense of nulls and exceptions and adts are also nice. Monads and all that wizardry is just a consequence of using it all together
And it also works because every function being piped doesn't require any additional information beside what is in the list. As soon as you need to propagate some information, you end with a lot of useless arguments that are just being passed around. Like what if you want to know the index of filtered element in original array? You now need to create an array of pairs (index, element), and every function needs to accept that pair and propagate that index through every call. That is error-prone (what if you accidentally pass an incorrect number somewhere?) and clutters the functions (that index is not used for anything in most functions).
@@clawsie5543 you're doing it wrong. You don't need to flatten everything down to pass it along, just have that part of the chain as a closure over the original index and the code that needs to reference it, just does :shrug:
Absolutely stunning and I was quite amazed by the clarity of this video. As a total beginner to functional programming (with years of experience in OOP and recursion), I find it crispy clear with the visuals that you created. Thanks again for this work.
This is absolutely hands down the best explanation I’ve ever seen on functional programming. I’m only a few minutes in and I’m just so blown away I had to comment. Definitely the best visualization of what’s going on, this is literally so extremely helpful for understanding this concept which I’ve been struggling to start to understand. Thank you so much, you make beautiful and helpful videos!
These videos are always so insanely good. Incredible channel!
@@user-tx4wj7qk4t Get off your high-horse, and stop spamming the same copy & pasted reply. Have fun with your pseudo-intellectual (and possibly imaginary?) job as well. Jesus...
Why didn't you start the function with `if(index >= receipts.length) return;` rather than having your whole function inside an if statement? You made an entire video about being a never nester! I expected better...
otherwise great video as always tho, that one thing just really bugged
Why he didn't just use a iterator for the whole thing ill never get.
In rust all of this could've been
array.iter().map().filter().sort()
Done
For recursion especially! If I ever write a recursive function I try my best to put the exit condition at the top (and about 100 comments warning any reader that it's a recursive function and works a bit differently 😅)
Nesting and also prepending the accumulator list instead of appending was something FBros wouldn't do. But this doesn't affect the point of the video.
Because he's shoehorning functional style into an imperative language. It's purely for teaching purposes.
In a real functional language you would do pattern matching on the arguments or add a guard etc that would make the if statement uncessary.
As a scientific programmer (in chemistry) who uses Julia intensively after bad experiences with C: I feel like to first order, state is the enemy of scientific programmers (more generally, when state is not relevant to a problem, it should be abstracted away as much as possible). Functional programming maps very naturally onto a lot of what we do, but a lot of the trouble people around me had was the degree to which we were taught we had to manage state when we really didn't.
The problem with functional programming in a language like JavaScript is that the JS runtime does not optimize functional techniques. Languages like F#, LISP, Scala, etc. can eliminate stack overflows and sometimes even do something called loop fusion where, in your pipeline example, all operations happen in a single loop instead of looping multiple times which is always the case in JS.
you shouldn't be recursing anyways. usually for every recursive implementation there is a less error prone higher order function
@@marusdod3685 example please. Here's a prompt: you need to keep calling a db or api until the nextToken stops coming back
@@SogMosee What you are looking for is called an "unfold" or more generally an "anamorphism". It's type looks like:
const unfold = (fn: (state: B) => [A, B] | null, initialState: B): [A] => { ... }
and you would use it like:
const results = unfold(nextToken => {
if (!nextToken) return null;
const { data, nextToken } = callApi(nextToken);
return [ data, nextToken ];
}, "");
The implementation is left to the reader, turns out "unfold" is a pretty useful higher order combinator that pops up everywhere. Obviously it's not a javascript builtin and obviously we don't do promises here etc but yeah if given a toolbox of higher order functions, we usually don't need to recurse.
And thinking about it, `unfold` is pretty similar to generators found in most programming languages, perhaps even equivalent.
The song name in the outro music is called: Novembers - Just Ripe (Album is called Pour Me a Cup of That)
I don't like the idea of paywalling the song names fam
Thanks. I'm trying to find the first song he used. No idea why it's behind a paywall on his patreon when it's not even his music.
@@DigiiFox Just shazam it brother
These animations are absolutely incredible! What software are you using to create them?
He uses a python script.
@@BlackPenguins17 That's crazy. How would you know - does he show it somewhere? I cannot for the life of me see that that would be productive, vs using an animation program. I wanna learn how :)
@@carlerikkopseng7172 I think I saw it on his patreon. I paid for a month to see the library.
This is really mind blowing! Probably the best video I’ve seen on TH-cam this year! Thank you very much for making this! ❤❤❤
Please make more videos!! Ive never had the nuances of programming seen explained this well and I think this is really valuable! Well done and thanks!!
Dude... your videos are just so enjoyable. Been coding professionally for over 20 years by now and still I love to watch your videos. I sometimes even learn a thing or two. Keep them coming, you are really awesome and make coding more accessible to everyone.
If you're already writing a bunch of procedural code, and using all your language features, you should already be intuitively doing all this (If you've been coding long enough anyway). I've noticed that LLMs almost never give you functional code unless you're super specific in asking for it, and even then they will often mess up, and go back to managing state. This is because most people aren't optimizing, and so most the training data isn't optimized but I digress. The video was beautiful.
what an interesting observation, dare I say ive noticed that shit too!
Love your videos, they break down concepts very well. I’ve been doing Advent of Code in Rust and functional programming goes so well with the language. Though can’t say it’s 100% functional, too many for loops.
So I watched about 5 of your videos, and I felt myself saying to things like "don't use comments" that this guy is taking everything to the extreme. Then about a week later, I found myself really cleaning up my code using different techniques that you've discussed, especially about inverting the logic of the if statements! I understand now that having knowledge of these different styles doesn't mean you have to use it 1000% of the time, but it really helps to sprinkle it in here and there and made your code that much better! Thanks my guy, you definitely earned my sub.
This channels has 8 videos and 300k+ subs. Shows the quality of the videos. Keep them coming please. DI was my favorite so far.
Your animation of a statefull function was a work of art!!!!
did you mean stateless instead of stateful?
@@xybersurfer no
You have no idea how excited I am when I see a new video of yours. As always, great video!
This is the best lead up to how map works I've seen, good work
This is a nice video! I'm extremely a fan of declarative paradigms, but it's quite hard to get others to understand why it's cool. Functional is just one step there. Stuff like logic programming is even more intriguing, though haven't have much opportunity to get into it yet. At least SQL is known by everyone and IMO one of the best arguments to be made for people dissing on declarative - imagine writing this complex SQL query manually! I think that should help people understand the value of declarative too.
I love declarative stuff as well. I do have to say that it is very often not the best way to solve a problem, but in cases where it does work, it is often by far the best solution.
@@joranmulderij Dunno about the domain you work it, but for me it's almost seems the best, at least as bulk of code. As video author said yeah you need to wrap it around on edge IO cases, but bulk imo very often can be done that way. At least in web dev and shell pipelines. Also a lot of times there it seems to not be the case IMO existing surrounding code is the reason why and not that it would not work. Just some imperative stuff is so proliferate that it's very hard to do work with it. Imo in future it will be declarative almost always everywhere, at its way more composable, and also giving way more leeway for compilers/systems to decide on how to execute (think SQL changing execution plans automatically based on what it knows about indexes/data stats and what not). For me it seems like a tragedy that imperative was allowed to poison software development for so long. But then, as you can see I have strong opinions :D
@@morphles The main downside to declarative programming is that it is way easier to get yourself stuck. You really need to "design" the interface. But once that is done and your use case fits tightly without what the declarative system was designed for, then the DX is amazing. I'm currently writing a declarative nodal reactive state management library with two way data flow, which would allow you to have a full-stack reactive system without getting your hands dirty with caching mechanisms etc.
in the context of software development, mutable states are allowed if they are local to the functions. And vois la, just like that, loops are back in business, and you don't need to rely on recursion you might blow up your callstack if you are looping of a large dataset
Tail-call optimisation is all you need, bro.
i watched this video months ago and thought the non mutable idea was pretty cool'. but i took it on board. now i never write anything thats mutable and my code is so much better for it. i still use normal for loops tho. improved my coding dramatically. thank you so much code aesthetic!
This video besides being so educational is quite relaxing. Glad to see you around again!
HOLY CRAP this helped me so much. I have written recursive functions and used them and even explained them in coding interviews but the way you broke it down here helped me understand even more! You lost me a little after the halfway mark but that just means I need more practice and more exposure to. Hella dope, thanks again!
TBH Functional Programming is very much a means of carrying over principles from analog data processing (such as control theory and analog computing) into the world of digital computing.
Filter design, block diagrams & transfer functions, feedback & feedforward, hysteresis, etc. are all from the world that existed before digital took off.
Good point. Explains why Gary Sussman prefers languages with a lisp.
There are actually multiple hardware description languages, used to describe circuits to imprint on a silicon die or an ASIC, that are based on functional programming or simply are functional programming languages. More traditional HDLs like Verilog and VHDL are almost _weirdly_ imperative for something intended to model essentially a pipeline of gates and circuits wired directly into other gates and circuits.
Last 1m 30s of the video was phenomenal. Loved the music and overarching summary.
Even in academic mindset, isn’t replacing a for loop with recursion just means that we are replacing explicit state with implicit state (meaning call stack memory)?
Fantastic video! I love FP and dislike the F-Bro lingo as well. My gross oversimplification of FP to regular programmers has always come down to:
1. Write more pure functions.
2. Use more immutable variables.
Nearly all the complexities of FP can be derived from making these two happen, yet MANY good, simple patterns in any language also stem from these.
Prof. who teaches Java here, and I have fallen in love with streams. Kotlin in particular has some absolutely gorgeous lambda based stuff in their stdlib.
Thank you for sharing this inspiring video, it really helps me to understand FP more deeply.
I finally get it! Explaining recursion using for loop is amazing. Thanks man 👍
As a JS developer, the best extract I got from functional programming is being mindful of how I funnel state changes in my code. Pure functions help a lot, as well as understanding the difference between a shallow and deep copy. And yes, I'll favour map, forEach, reduce, along with most array methods, over imperatively written loops.
Be aware that in javascript, many of these operations will have significantly higher CPU and memory overheads vs more traditional approaches, particularly with how much JS loves to mutate and copy arrays under the hood. This is not to say you shouldn't use them, composing reliable and easy-to-read functions is an extremely powerful way to write easy to parse and easy to debug code, but it should be applied carefully and checked for performance when used in performance-critical areas of code. As someone who writes a lot of performance-critical JS (irony, I know), I generally avoid them for that reason, but they have their place.
@@thehobojoe javascript is already slow, might as well take advantage of that to write more readable code
That segue to a "sponsor" was brilliantly done 🤣
This chanel is just pure pure gold ❤️
I have exactly the same opinion about functional bros but I almost came to a point I felt bad mutating a state even though it made the code do the right thing in a clear and readable way. This video spackled joy in my heart :)
A new video from you is like the best Christmas gift. Thank you a lot
Did you just use JavaScript for a functional programming video?
Scandalous
One problem with functional programming, at least in Javascript, is that the performance overhead is quite large. Constantly making new arrays and objects significantly slows down the code. Mutating objects is just so much faster, which is unfortunate, because good functional programming is so fun to write and read!
Which is why going for a language that has functional programming as a goal from the beginning is a huge advantage. Most of the overhead is mitigated by the compiler making the right decision in those cases. Like, in #fsharp, there are cases where the CLR restructures your code to be procedural imperative style, and gives you the perf benefits of that. I think Ocaml does it too.
I primarily use javascript, but this is one of the reasons I really want to use Rust. You get to do functional iterators that don't have that overhead, and it allows for mutability too.
Not large enough to matter
Your videos are stunning! Thank you for making these!
Great video as always. I'm not a F bro, but in my classes, sometimes using map, filter, take, pipe etc.. makes my code simpler than write pure imperative code.
In the next video, what about data oriented programming, it would be great seeing you explaining about some of the most famous DOD pattern, Entity Component System
Mutating state in JS is how you make things faster. It just is. The more array methods you do, the worse it gets for garbage collection because every new map() and filter() call creates a new object and copies all of the key pointers to the new array. Also recursive "data pipelines" as described are just a neat way to speedrun stack overflows and increase memory usage.
In short, most of the "clean" code these days is just a direct downgrade from regular for loops.
You get decent performance in functional languages, javascript is only "pretending" if you will. It is very clearly an imperative language
Usually you don't actually need to have most of the code be faster. Like in this case the difference in time taken to send a web request to the users' bank for their transaction history will be thousands of times slower than the processing loop if you're running it synchronously. In a program like this, you're unlikely to run into performance problems unless you have many many users, and if you do, you should probably switch over from JS into a systems level language anyway, that is, if you can't just pay another £100 a month (a lot less than your lawyers) to increase the server size and stop the performance problems anyway.
If your expensive operation (A) takes 100ms and you reduce it to 50ms by switching to C++ or Rust, it won't matter if A gets called 1000x instead of 1x. The language won't help you from hitting some kind of limit if your code is bad. Taking functional programming to the extreme requires rerunning a lot of code because you aren't storing any of your past work. And if you are it's stuck in a closure which is more tedious to access from multiple places in your code.
Functional programming has some good ideas, like avoiding side effects as much as possible, or *not* turning everything into a an abstract factory builder class.
But like anything, you need to understand why you're doing the things you're doing without being ideologically attached to a narrow paradigm.
Sometimes classes are a natural fit for some piece of data, sometimes you just want ephemeral functions that return and leave nothing behind. @@tupoiu
One issue is that many of the more well-known functional languages are a pain to get into. Scheme is easy to pick up at first, but it quickly becomes challenging to tackle problems that are a breeze in other languages. Haskell is wonderful, if you can ever get it to compile. Some of the newer functional languages, though, like Clojure and Elixir, make FP much easier to get into.
It is probably true that the most useful languages take some functional features (e.g. Rust), but it's good to have some experience with functional programming so you know when it's useful to bust out the maps, filters, and reduces.
I've absolutely loved LINQ in C# for years, but only after learning Rust and more about FP in general, and I realize now that it was the use of higher order functions and FP paradigms that I enjoy so much. Also, I was blown away be the realization that Tasks are monads that I've been using this whole time...
Just wanted to say, your videos are AWESOME! Keep up the good work, mate!
I write C# in a functional style, mostly, but monads, functors etc. Aren't part of my daily vocabulary. If you want me to tell you what part of my code is what, I'm not able to do it 😂
Actually I am concerned about the tips being added afterwards. If they don't physically have my card they should no longer be able to charge it. It's a broken system.
Bad marketing for different paradigms is rampant across the programming discipline. At this point, I actively ignore its propenents until I've had a chance to learn more about it. Ironically, they suck the fun out of it for fresh newcomers.
dude this is the most clean explanation of functional programming ever created.
As a person who is extremely repelled by functional programming at first glance, this video really helped me take a better look at it. Might try this programming paradigm with some of my projects.
Definitely don't do it in JavaScript like he did. Its not a functional language and doesn't fully handle the paradim. Instead use a language like Rust, everything he did here can be condensed to nearly a single line.
@@thegoldenatlas753 Why would you want to condense a bunch of distinct operations onto a single line? That's terrible code design
@@amaryllis0 the point of FP is to show what your doing over all.
Quickly at a glance you can see your filtering mapping and sorting an array of data.
Spreading out across multiple lines gives no advantage and ends up just being messy and more likely to loose performance gains.
For instance i have a project where a user can put in a phrase and it transcribes it to a fictional language
All i do is
User_Input.chars().filter(|c| c.is_ascii_alphabetic() || c.is_whitespace()).collect::().to_uppercase().split_whitespace()
With this you can quickly and easily see I'm going through the characters removing anything not a space or english letter and then turning it into a string then uppercasing it and splitting it by into individual words.
Its quick, clean, and concise in its purpose. And i can do all of that in a single statement.
@@amaryllis0 Because nobody uses rust in production, mainly bc rust devs are awful
Functional programming as an all encompassing paradigm just isn't useful but that is what is frequently marketed. The whole point of most applications is to produce side effects and a programming style that excludes them is obviously not going to get the job done. But as a preferential style it is incredibly useful. Rather than writing code with no side effects, having a goal of removing all unnecessary side effects can have a huge effect on increasing the stability and readability of your code. When you isolate and tuck away all of the stateless code in your program, the actual necessary and relevant state just falls out into a few places where a previously incomprehensible code base becomes much clearer and easy to maintain.
Excellent video, I would also have talked about fold/reduce.
Nice to see the channel keeps going.
Thanks!
You’re explanation with visual of currying made it make sense to make. I literally sat there dumbfounded with how powerful that is. 8:39
REALLY, really great explanation and great video. Thank you.
My gripe with pure functional progamming is understanding the state of your code (what something is and when) is a large portion of understanding how the code works too. If I run into a call stack of 15 functions it is incredibly difficult to figure out whats going on. Same with recursion, you take something as intuitive as a loop that you can see and follow (Do the thing as long as this condition is met) and you turn it into something that has no intuitive representation in the code, something more abstract and hard to understand for the human brain. There are times where both of these things are a great option, but for most things its important to know and have a state to follow
Also, if you need to maintain this code, it can be much worse than something more "old-school". Some changes might require you to completely break apart the function call stack and rebuild it from scratch. Often you actually want side effects. Anything that can be done without it, is generally quite simple code anyway. Basically static functions. And it is just harder to debug overall. Good for simple stuff, gets harder as real life issues intervene.
@@Sande24 "Some changes require you to completely break apart the function call stack and rebuild it from scratch" - this is the same in all programming. Shared mutable state (two objects that change the same value) is very hard to debug, and functional programming goes a long way towards reducing it. There are definitely some things that are conceptually easy to represent as a for loop with mutability, but often what you're doing is just a .map or could be separated into a couple of .maps and be easier to read.
Trust me, it's just as easy to follow functional code as it is for non functional code. Even trying to understand flow in recursion is not as difficult as it seems. The condition you check against is just in a different place than at the top of the loop. Try some functional languages and you'll quickly realize what I mean. If anything I find it easier to follow data through code because I specifically declare what I want my types to do, say
(Int -> Int) -> Int -> Int
I want a function that maps an int to an int, then applies a function to the result and another int and the result is an int. I distinctly know what type I want my function to have as an in and output. This makes it far easier to know the state of your data at all times in a chain of functions.
@@Finkelfunk I like functional code. But only when it does only a few things and then stops. I've seen plenty of complex functional code that does otherwise. If you have 10 map functions in the stack and you have to understand what is happening to the initial data, it can get overwhelming pretty fast. Passing functions as parameters is the worst - harder to see what applies to the specific data unless you go back to find the function that is passed into the call stack. And if it can be different based on a conditional, that condition might also be hidden away from the normal call stack so you dig even further. Every time you read that code, it's going to be the same kind of obscure flow that you have to look into until it be comes specific in your head.
The point is that you can't read the code top-to-bottom but you now have to mentally know the order of actions and jump around different methods more. It's easy to build and easy to work on when you already know what it does, but for a first-time reader it would be a much steeper learning curve. When things get more complicated, you should look at what the drawbacks of each approach are and choose a proper one. I'd say that immutability is often something that you don't really need and removing it would make things faster.
Saying it again - functional style is nice. Just don't overdo it. Every approach has a drawback and you have to choose which to use. Not only defaulting to one all the time.
@@FinkelfunkFunctional programming for a small component or service is fine. For _all_ components for a real world app with teams of developers of various backgrounds who come and go and real world deadlines where you need to add a feature "yesterday", yeah not so much.
Programs that are fully functional may work for hobbyists or niche tools, but real world applications are predominantly built with OOP.
I love how Rust does it with iterators. It’s effectively a decorator pattern that results in an iterator that only does all the computations when you actually do the iteration. In this way, the collection is only iterated through once no matter how many operations you perform through it. You can map and filter and the rest several times and still only do one iteration through the collection to do all of that.
This is how iterators are implemented in many languages.
"I love how Rust does this! You see... *_proceeds to explain something literally every programming language under the sun has been doing for 20 years_* "
True Rustacean moment
@@Finkelfunk I don’t think Python and JS do it this way. Every map() and filter() call iterates through and returns a new list.
@@Holobrine Yes, because Python and JavaScript are interpreted languages and lack compiler optimization to combine sets of operations for iterations.
@@Holobrine ever since python 3, python's map() returns an iter
So why remove the for loop in the first place?
I understand that it creates state in a function, but despite that the function still does not access any *external* state, so it should always return the same output for the same input. And its much less complicated than doing all of the other stuff.
Loved the visualizations! The elegance of the map/filter/reduce approach towards data pipelines is attractive, but I think it is still useful to consider the “good old” for loop - especially in performance oriented situations. The overhead from passing/calling predicates and performing additional loops can bite you when low latency is important. Though, often, there’s probably better places to optimize first. 😉
Certain things have many excited proponents that can't explain "why it's good" to anyone but each other. (Like, in my opinion: IOC, DI frameworks, fluent syntax.) I find most of these aren't worth using in pure form most of the time. However, my takeaway from functional programming class was that I felt extremely certain how my program behaves. After I got over the big mind flip! It's data processing didn't stick in my mind.
fluents are kinda crazy
Is IOC just callbacks?
You are basically using IOC when working with frameworks. Let's say you have a game engine. Basically you just put your code in custom class and implement a couple of callback methods eg. Init() and Tick() and these methods will be called by the framework itself. It's good because you shouldn't care about who is calling these methods, what is the right order and preconditions, framework just doing it for you.
Why is it good? Because you can abstract yourself from some things and focus on your features, which is basically why people use frameworks.
DI containers are essentialy a mechanism for constructing your objects and providing dependencies. You can sure do that manually in composition root, where you build all your objects in specific order so all constructors can receive valid dependencies, and objects that created internally have their dependencies too, so it gets quite tedious and not very productive.
With DI framework you can just define that "Foo is provided for IFoo as singleton" or "Bar is provided for IBar as new instance each time".
Then if you want to add new class, you just write its code as usual, list all dependencies in constructor, then you bind it in container and it will resolve automatically providing all dependencies for you. Want to add new dependency? Just add it to constructor and it will just work.
Specifically in games if you want to create new object from factory, factory don't need to know all the dependencies required for an object, DI container can provide all the dependencies for you. Isn't that good?
All of those patterns are FP in disguise.
Inverson of control is just making use of higher order functions that call into your code. an interface is really just a record of closures.
DI is the same as js modules, nothing new or exciting, it's just a workaround in pure OOP languages because they don't allow code outside of classes.
fluent is just functors
@@marusdod3685 by that logic your FP is literally procedural in disguise, because in the end it's all just data in memory and function pointers.
Nice video! I suggest keeping the background music to a minimal volume level though, it's often way too loud.
Adding some ducking could help. Keeping the music in to get the smooth ambiance and mood, but seamlessly reducing the volume by maybe 5/6 dB whenever the voice come in. That can easily be done with most simple gate plugins.
I love monads because they are impossible to understand theoretically, but take a half second to understand what it's doing when you actually see one even if you have no clue how monads are supposed to work.
One thing that would be great to mention at the end, is that in JavaScript, all of these built-in methods evaluate eagerly. Which is fine for small, synchronous sets of data, but what happens if you'd like to read the data directly from the backend - i.e. our we don't have an complete array, but our data items are fetched asynchronously? In the example, we only want the top 10 results for our dashboard, so we could stop iterating the transactions once we've satisfied that limit. With current code, we always iterate & filter through all the results, and then discard everything that's beyond the top 10, which is not very efficient. It works with simple examples, but when you start looking at situations with thousands complex data entries, this adds up and will have performance implications - both on execution time, as well as memory usage (our runtime creates many intermediate objects/values, and the garbage collector has to work overtime).
This is a situation in which libraries like RxJS and IxJS can help, as they enable you to use functional style pipelines lazily, also on asynchronous data sources. Observables are coming to JavaScript natively, so hopefully this will be easier to achieve without additional libraries.
>fetched asynchronously
are you implying there's state and side-effecty things going on in the backend?
@@shinobuoshino5066 there always is, nothing is ever completely pure. Even in synchronous loops, each iteration of the loop will change the state of various registers within the CPU - index registers are updated, comparison flags are set, and the program counter is adjusted to jump back to the start of the loop. Intermediate objects might be created and garbage collected. There's no escaping the constraints of the real world (and hardware).
Whether we retrieve the data from local memory, or from a remote server only differs by the underlying complexity of the iteration's execution, and by the addition of waiting on another thing to be able to start executing the loop code again.
It's all fun and games until you have to deal with exceptions in your functional pipeline.😅 Btw really good video
That's the next level of FP... it starts with pure functions and pipelines, but then introduces other types (like the scary "monad") which are off-putting words for simple concepts to solve this problem. But IMO they're worth it, because they really simplify error handling, and make it impossible to "forget" to handle errors. They bring errors into the normal flow of code, so you treat them with the care they require, rather than just slapping on some error handling after-the-fact
Well It's still fun, Monads has a type which is called Either it's basically so useful to return errors, you either take return left or right, .map, filter, etc.. works on right and mapLeft, peekleft etc.. work on the left part :)
what exceptions?
errors are handled through a sum type, in Rust (which is not purely functional, but has arithmetic types with (imo) better names for some situations), this is done through Result, in haskell the standard is Either Left Right, if there's only one error case (like "the string you passed in is not a valid integer" for a parseInt) you can use Option / Maybe Type
@@catgirlQueer you explained it, so that was what I was saying tho.
@@LetsGetIntoItMedia does this mean that all functional pipelines must complete regardless of errors and depending on where the error occurred in the pipeline then you get a different error message / stacktrace at the end and then use an if statement to handle both success case and error case to do side effects? is that all this comes down to-the basic alternative to try catch / .then.catch?
The man the myth the legend!
If you're looping through a large amount of values using recursion, there's a good chance you'll run out of stack space. At least with an imperative loop, you can overwrite the state from previous iterations, thus saving stack space.
Great video building the concept from the ground up
Ironically those of us that grew up with JQuery were encouraged to learn and use this from the beginning with method chaining and now it seems like users of more modern JS frameworks are rediscovering this with ES6 lol
Each masterpiece you craft unlocks doors to learning, inspiring minds to reach for their own artistry.
Artful knowledge, skillfully shared, each video a masterpiece to learn from.
doing tricks on it 💀
was this written by ai
"There shall be no state"
Enter: State Monad 😂
Btw: many functional languages have an imperative-looking way of using, applying, binding functions, which makes this not as unreadable as you make it look here. In fact, functional code is generally much easier to read than imperative or OO code, as without side effect, what you see is what you get. You can reason about code, which is much, much harder with mutable state, where you never know what can happen, as any part of your program can change the state.
Well said! I'm admittedly a big FP nerd. Sounds like you might be interested in my series! For many applications, the mental shift has been really great. I've been able to "reason about code", as you say, in ways I really couldn't before
I MISSED YOU SO MUCH!!! REVISITED YOUR CHANNEL AT LEAST TWICE A WEEK! SO GLAD TO SEE A NEW VIDEO 😢❤
The initial example of replacing a for loop with a function reminds me very much of how I would split loops up in JavaScript if I had to do a setTimeout between each iteration. I wasn't aware that solution was "functional programming!"
How do you make this animations? Are awesome! 🚀🚀
he coded the svgs by hand
Functional bro here! Guilty as charged. You're totally right...
The concepts aren't actually that complex (a Monad is basically something that has a map() and flatMap(), and you can arrive at the need for that with a few simple code examples), *but* the words can be used to gatekeep or show off your smartness
Also, the focus is often elegance for elegance's sake, rather than usefulness, simplicity, composability, safety, testability, etc. Though it is, in a way, the elegant foundations in math that allow FP patterns to get so powerful
Also, I do think there's value in the words. It would be extremely difficult for society to function if we never put labels on things... how could we ever succinctly talk about anything without terms for concepts? Learning the FP words are useful not because knowing definitions is useful, but because they help you see those patterns in a problem space and then go r you immediate strategies for breaking them down into smaller bits and solving them concisely
@@user-tx4wj7qk4t Lol what a big non-response from you. Not only were you unnecessarily condescending, you never even addressed what he didn't understand about monads. You never addressed the elegance for elegance's sake argument, and then spent the rest of it inflating your own self-ego about being using functional programming. Then you all wonder why people don't take functional programming seriously.
@LetsGetIntoItMedia I think the responder is a perfect example of why functional programming has a hard time making traction in comparison to oop when it comes to marketing it's benefits. A lof of of the folks trying to push it, spend way more time focusing on impractical simple examples that aren't of much help to anyone building applications, and seem to just use it as a way to flex how smart or clever they are.
Hmm yeah, I had a lot of thoughts to that response (which I'm not seeing anymore here, but saw the notification). My take is that I actually agree with a lot of the points that person made, but just absolutely NOT the tone or extremity.
I totally agree that engineers *should* be into math, as they are literally writing computer math. But people come from all sorts of backgrounds, and that doesn't necessarily include a love for math. It might just be a love for creating stuff from more of a design perspective, or just a plain need for a job. And that's good, because we get a variety of perspectives and experiences in the field. People often *don't* think of math as something enjoyable, or realize how much code is like math. That's not a problem, that's an *opportunity* to share a new wonderful perspective.
I also agree that FP isn't as off-putting or "gatekeepy" as the stereotypes suggest, but that's because I'm a math nerd on the side. But fact of the matter is, it *is* a stereotype, which means many people think it is unapproachable, and therefore by definition it *is* unapproachable. If most people agree that a balloon is red, then it probably *is* red.
There is jargon in OO as well, that's for sure. And jargon isn't a bad thing. It's a way to capture a whole concept in a single word. So if everyone agrees on its definition, it makes communication much quicker and more efficient. *But* that's why, when talking to people who don't know those words, you have to do a good job explaining them. The problem is, based on the general sentiment, that people *don't* do a good job explaining the jargon, which feels like gatekeeping.
Also, re: my definition of a monad, of course it's simplified. There are monad laws and all that, but that's exactly the stuff that turns people off. The average person doesn't need to know the exact precise definition of a monad, just some practical examples of how they can help simplify problems.
Whew... I wasn't sure if I wanted to respond to that message, but I decided to make my perspective known. There's an *opportunity* to make the community better by *proving those stereotypes wrong*
Big Thanks, Awesome Content... I needed this kind of explanation, so now a lot of things make sense!!
At first I thought functional programming would take more work to learn and implement into code than OOP, then I realized by the end I already do a lot of functional programming using the built-in functions.
Situation is currently this one: Programmers control a database via the non-functional language SQL which is translated by the database system into an operator tree, i.e. a functional program, for optimization. The database is programmed in an imperative language which the compiler translates to a functional internal register language for optimization. The result of the optimizer is written to imperative assembly language code. The CPU analyzes data dependencies and reorders instructions accordingly, that is, it would also benefit from a functional machine language. Summarized: Functional programming already reached world dominance but at all occurrences it is pretended that imperative programming would be the normal way of programming, would be machine oriented and efficient.
Haskell bro and Lambda enjoyer here:
I have to admit, we _seriously_ have a problem marketing such clean and cool programming.
I once showed Haskell to a friend of mine, and he was super skeptical at first. By the time I got to infinite lists, lazy evaluation and the lack of conventional if-statements he was baffled how beautiful and simple code can look and feel while being so insanely complex.
Our professor from our lectures on higher concepts of programming put it best when he said that you have 3 lines of code, they compile to an entire ego shooter, and once you try and understand the code you will fail for the first 4 hours, after that it's gonna make you cry because it's the most beautiful thing you've ever seen.
Never in my time working with languages like C++ have I looked back onto code I wrote so many times and thought to myself: "Damn, that's really beautiful code you wrote up there".
I _seriously_ recommend anybody to try out functional programming. The borrow checker is nice, but it can't prove mathematically that the code is side effect free, no matter how hard it might try.
Maybe it's just me, but if I need 4 hours to understand 3 lines of code, those are not very good lines of code and I don't see any beauty in it. I don't understand the obsession with brevity.
@@cloogshicer The problem is not that they are brief for the sake of brevity. Obviously that was a bit sarcastic by him but at its core, he was very right. The beauty of functional code comes from it being so clever and thought out. It's not like some old 90s Java legacy code deep in the basement where you take 4 hours because you have no idea what the author even tried to do and the knowledge is lost to them and god alone.
It's the way you approach a problem in an extremely smart and coherent way to condense it into such a simple expression that you first need to wrap your head around what is exactly happening under the hood. Why types line up, how functions play into one another.
Those hypothetical 4 hours are mostly spent figuring why the solution works the way it does and how all those puzzle pieces click, not trying to understand the code. One upside of functional programming and lambda calculus in general is that mathematicians sure know how to make an intuitive notation readable once you know a few concepts. Practically anybody can read Haskell code (and far easier than C or Java mind you), but actually understanding _why_ certain aspects work is a whole other level.
It's a lot like solving a Rubix cube, it's extremely simple to twist and turn but figuring out why a certain number of twists and turns give specific combinations is quite satisfying - and once you've solved it you appreciate its beauty.
It's hard to pick a specific example here, but there is nothing quite like having an insanely precise and optimized approach to a problem which takes time to wrap your head around because the person who thought it up actually spent time and effort doing it.
@@Finkelfunk In my opinion, beautiful code is code that is easy to understand. Brevity and elegance, in my experience, doesn't serve understanding. I see code as mainly an educational tool for the next developer (or myself, in 6 months). And brevity/simplicity/elegance doesn't help with that. Otherwise, we wouldn't have textbooks, and physics students would only be handed the final equations (+ any definitions they're made up of) and left to figure out how everything works on their own. This is what functional programs are like to me.
@@cloogshicer Let me reemphasize: The code itself is not the issue. It's not obfuscated bash syntax. Like I said, I am pretty sure you'd understand Haskell code with relative ease without ever having written a single line in that language, and you'd do so much easier than in C. It's sometimes even easier to read than Python code because the notation is descriptive and simple like you'd be used to in mathematics.
The code is a clear stream of functions, a into b into c into d. The syntax is very clear and descriptive, functions like "dropWhile" or "splitOn" are not exactly hard to grasp.
The beauty and complexity comes because of the way people start to think about problem solving once you stop declaring 15 helper variables and push data from a into b and back. It's a different way to approach a problem which makes the solutions much more compact and efficient. As people have elegantly put it here: You are much more easily able to reason about the code, because what you see is what you get. In C this is simply not possible because of all the noise surrounding the code.
You start to think way more about the flow and shape of your data and how to manipulate it in effective but concise ways. That's the beauty of FP and I seriously recommend you give it a serious go. It will only serve to make you a better programmer in the long run.
@@Finkelfunk I've written some Elm and Haskell and let me tell you, it is not easy for me personally at all. I find imperative code much easier to understand. Especially recursion is very difficult for me. And I have over 10 years of dev experience in other languages.
You say that "what you see is what you get" but what I feel like a lot of FP-affine people keep forgetting is that for each function definition, you need to understand all the definitions it's composed of, and so on, recursively. For simple problems this isn't an issue, and sometimes you can skip entire parts of the tree, but most of the time you can't.
Great video, you left me wondering though about how recursion resolves these functional problems. Isn't recursion just pushing the existing work into state somewhere? Additionally I'm now curious how parallel processing works for map/reduce functions.
Glad you're still posting! 😊
"functional programming bros are bad marketers" ... proceeds to rewrite a for loop as a recursive function
Isn't that the point?
@@charlietian4023 No. That is a basically a strawman. In FP one would use a higher level function that does the loop. Like `map`. One would not write it recursively. That is idiotic. Recursion is applied when a problem is naturally recursive. Like processing a tree-shaped data structure.
@@ElizaberthUndEugen I see, can you provide an example? So CA isn't the most familiar with FP either
@@charlietian4023 he goes into `map` etc. in the last third of the video.
@@ElizaberthUndEugen I'm aware how map works, but could you provide an example of how that's used instead of iteration or recursion?
replace loops with recursion... because why use a built in CPU register designed for loop counters when you can instead abuse the stack pointer.
Writing spaghetti imperative code to save 50 microseconds on your page load time. There is a time and place for every style of programming.
@@randomizednamme ?? loops are spaghetti code ??
@@KX36 they can be if you’re trying to optimize heavily or as the programs complexity grows. My point is the difference is so small that it won’t be a performance problem for most programs and you should choose the more maintainable option.
You can rest easy knowing that you wouldn't even begin to comprehend the amount of batshit certified insane optimization that is generally done in a functional programming language's compiler.
That is why tail-call optimisation is a thing. Plus, people rarely write straight recursive functions in FP - the composition of map, filter, etc. is sufficient in maybe 90% of cases - these functions are all heavily optimised.
I really enjoyed working with these functions in Angular. Mostly with rxjs though, which I find incredibly intuitive.
Though I still used state everywhere, but I think just for the things that actually made sense.
Gotta love how someone tagged the super obvious joke as a sponsorship spot in sponsorblock