Dear Functional Bros

[WolfireGaming]

"There Shall Be No State"

Anarchists 🤝Functional programmers

[NihongoWakannai]

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.

[nERVEcenter]

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.

[InconspicuousChap]

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.

[theslightlyhillyrider]

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!

[garretoconnor]

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().

[fiddytroisvis]

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 🎄

[joelbarr]

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

[connerjones]

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.

[muno]

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

[zactron]

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.

[TheSast]

sorry, you got the wrong person, me and my lifestyle are DISfunctional.

[kylewollman]

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.

[davidzwitser]

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!

[atijohn]

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.

[starTitan]

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.

[scheimong]

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.

[brainandforce]

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.

[vivekt]

Hey what happened to the channel, I am not seeing amy new videos anymore..😢

[morphles]

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.