Einstein never said or wrote that not even in German. This is an idea as old as the early 19th Century. "95% of quotes atributed to me are false" Albert Einstein
@@Undercover_Femboy This quote is common at movies for a long time (it became a platitude already). So it does not surprise me if it appeared in Far Cry. But Far Cry attributes it to Einstein?
yep, its a good way of controlling systems. you put the state in the outside world, and then you can only deal with pure functions and transitions of state.
Pure functions are generally easier for compilers to optimize, too. But only if the compiler can be sure the function is pure. Thus, it's a good idea to decorate your functions with "pure". This helps developers reading the code too, as they can quickly understand whether they have to worry about side effects or not.
Expressing IO as pure values just pushes a lot of the burden to the runtime / compiler. The advantages can be huge! An intelligent compiler / runtime can decide the best strategy for executing it (concurrent / parallel / ...) and you don't have to pollute your logic with those semantics.
there are a lot of practical problems around pure functions. 1. most functions are impure, and even math functions are often impure (eg in-place functions, functions that emit soft errors). 2. function can be pure while parts of it are not (caching, local io buffers, in-place operations). 3. concept of pure function kind of overlooks memory allocation, which is the largest optimization target and also completely impure. i think functional programming focuses too much on pure functions, while effect types and performance are shoved aside. this is why overwhelming majority of critical software is written in procedural languages if not assembly. another downside to pure function concept is that if you add one call to a logger in one place, suddenly 10 functions can become impure. if compiler understands purity and effect types, but cannot parametrize over them/derive them, you'll spend half the time figuring out what effects should function have on a mid-sized project (kind of what happens in Rust with type parameter bounds and lifetimes). imo, there is a limit to how useful the type information can be and this limit is fairly low, while type information is potentially infinite (array dimension sizes, numeric ranges, predicates, etc can be used to augment type information).
@@Daniel_Zhu_a6f "most functions are impure". I know of many projects where this isn't true. Also, even in a project where it is true I'd argue there is probably a lot to be gained by separating the pure parts into their own functions. Having a function that could be pure aside from allocations should be rewritten. The caller should be responsible for managing the memory. Your argument about logging is of no practical significance. I've never seen a case where logging couldn't be achieved elsewhere, and likely better for it. I have no idea where you got your ideas about types. They are popular for a reason.
@@tolkienfan1972 i didn't say that types are useless. basic data types (primitives, enums, structs, unions, typed arrays) are very useful, but some languages go much further than that, and i'm not convinced that those extra types do anything good. "logging can be done elsewhere" -- in principle that's correct, in fact, most impure stuff (except maybe time queries) can be pushed to main function or thread main. however, it doesn't seem like a lot of people write code that way (outside of purely functional languages, obviously). i surely won't write it that way, bc it seems like a useless complication. you say that you know many projects with mostly pure functions -- could you share a couple?
@@Daniel_Zhu_a6f they're internal. But generally math libraries and the like are almost entirely pure. I think beginners should be taught from the beginning to think this way. Knowing the function calls you're looking at are all pure helps immensely reduce cognitive load. You can immediately rule out whole classes if bugs.
Cool video! I think there's a few aspects touched on that are interesting to be discussed: 1. Working with pure functions involved additional complexity and indirection (can get annoying after a few layers) 2. The more explicit (and more) the parameters the more pain to write and read the function call 3. Monkey patching (e.g making the datetime.now return an instrumented value) or something like an optional injected_date parameter which overrides the value (this is similar to how PCBs have test pads at various places to inject/read values) I'll add that for 2. I've noticed that when writing state machines, the code is so small and neat! (at the expense of state complexity/management, timelines etc.). Every function call (action/state transition) is just the name of the intention, everything else is inferred contextually. It's so freeing to say just "I want a pizza" and your favourite one to be delivered.
1. I'm all in to invest in that additional complexity because I know it has a huge ROI. 2. While I understand the sentiment, I do believe that with good data modelling, it'll be fine. I should be able to support the argument given a code sample. 3. I don't understand the point, please clarify if so. That operation has to happen somewhere, but it's better to be isolated where it just passes down what it read into a pure function which does not need to know about monkey patching. The "I want a pizza" reminds me of this paragraph I had written which didn't make it to the video: I give you an A, you give me back a B, that's it. When it's like, "I give you an A, you give me a B because it's Tuesday. I give you an A, you give me an X because a database entry was modified. I give you an A, but you give me nothing because there is no internet," it's annoying.
@@theteachr Thanks for the reply, I totally understand your view, just thought they'd be interesting to mention in a future video. There is this spectrum of { full modular, minimize state 1 function monolith, maximize state } onto which codebases can be put and I find both ends painful to work with, it's interesting to see where the sweetspot is depending on the use case. For 3., yes in theory breaking a function down into deterministic and non-deterministic blocks and extracting the deterministic parts to be unit tested is very nice, but sometimes the non-deterministic part is in some nested control flow and not so obvious to extract; there's also cases where a refactor to pure functions is too costly or unfeasible (e.g. testing a 3rd-party library) and more blackboxy methods like moneky patching, e2e tests in deterministic environments, etc. are more useful
An interesting parallel with digital circuits would be circuits that are "pure", aka, they have an equation and inputs and outputs, for ex, an AND gate, and circuits with feedback, a Flip-Flop, which is what basically creates mutable state in computers. Academics got too rung up on purity, and having no side-effects, but in the real world, everything has side effects. That's why quantum physics is hard to understand, you measure something, you change it, nothing is pure like in mathematics. Mathematical functions are missing state, that's more of a problem of mathematics not being able to deal with discontinuous functions. Its ironic you can approach discontinuous functions by using computation and "brute force", that's called discrete analysis. Linear algebra is much more useful than calculus. Maybe that's why physics is so hard, we need to learn through simulation instead of declaration, maybe that's why mathematics is both incomplete and/or inconsistent, you need to have state. Ironically Tensors kind of represent state indirectly because they can have arbitrary dimension, you represent state by the way you array the internal matrices in a Tensor, they go around the scenery path instead of having "mutable functions" to simplify things (ends up making them way complex, Tensors are just "struct types" for us programmers) But I digress.
about that quote in the beginning imagine you are practicing any skill in other words, doing something over and over and expecting to improve will you call that insanity?
No, you’re expecting the same result: Improvement. More technically, you wouldn’t be doing the same thing either. Every time you do it again, your previous doing would have changed you.
@@theteachr i see your point but still there are many things where our effort is not the only factor and trying again and again is not insanity i do not completely agree with that quote
this bread analogy is exactly what I thought as soon as I've heard about FP there's nothing bad about having impurity in your 'main' function or your first layer of the programm, but as soon as you get out of there you should use pure functions.
I think the food analogy is great because people who worry about separating functions that are pure and impure are like people who must keep different foods separated on their plate and not touching. Same goes for most programming paradigms actually. What actually matters the most is does it taste good, there are too many things to consider when plating up that it will decrease the time you spend actually considering the result you are trying to achieve.
what i've discovered recently for myself are pure-impure functions. they have a pure function at the core, but have optional /flag arguments that make them read data from files or save results to files or log loop progress, etc. this makes function composable and testable while keeping the brevity and locality of behavior that we like about effectful functions. eg the code at 2:20 could be rewritten to accept time as an optional parameter. then the function would be pure if time is passed and would infer system time if null pointer is passed in place of time.
While I don't completely dismiss this idea, every flag results in a branch, doubling the number of valid paths, which would bother me. I can understand if it's small piece of code, but I would still prefer the decorator. Pure function is completely pure and the impure counterpart just wraps over it with side effects and / or reading external sources.
@@theteachr i'm not sure what you mean by a "decorator". if it's just a function that provides additional pre/post processing of arguments/return values of a target function, then i don't see much difference between these approaches. if it's something like python decorators or "design patterns"TM decorators, then i don't like them. i find them very cumbersome and not suitable for most tasks. if it's something along the lines of lisp-style macros, or some other code generation technique, then it's a total overkill for 99% of tasks.
Hmm, this idea might be formalizable into some kind of polymorphism around the effect system. Oh wait… Isn't this what Idris does already? Also, free monads are a very similar concept.
or you can just wrap your impure function around the pure one as shown in the video. this is better, as you don't muck up your api with the optional parameter. also because the pure function is testable, and the impure function is almost trivial because it is just thin glue around the pure function, so it is near trivial. it makes ci and tdd easy.
f is not impure, but you did point out the incorrect thing I said. I meant to say, "pure functions are idempotent." But that's wrong. Pure functions need not be idempotent. Thanks for bringing this up.
I gained valuable insights from this video. I've been using the "sandwich pattern" a lot but didn't know it can be called that way. Also more recently I'm having issues about what to name and where to place those "filling" pure functions. I tend to place them in utils even when they're really only used for a specific place lol Also I guess the sandwich pattern can be hard to apply to e.g. DB calls when you can integrate a lot of the filling into the query, e.g. sorting, filtering, transformations
Isn’t everything a utility? Shouldn’t they all go in utils? Utils is a smell. The filling pure functions should have a name and place inside the core. All side effect-y things can go into an IO namespace. From what I read, you are giving less importance to the filling.
Good thought invoking video! Pure functions aid a lot is composibility and security as well. I guess effects would really depend on the context(the environment your computation interacts with). For example simple cli tools like cat, wc, grep can be seen as pure functions, given a same file produces the same output file which further can be composed. (Which really made UNIX successful), or relational operators in databases. The only place i can think of , where we woudnt need pure functions in our application(core) itself would be some cryptographic tool, that generates a different hash for the same input or a random number generator, but there may be more.
RNGs can be pure (I think). You give the same seed, they give the same number alongside a new RNG with its state updated. The source of the seed is what's random. Like one of the lava lamps in the Cloudflare hall. The image of the lamp is the seed. But given the same image, the RNG should be able to produce the same number. Practically, the image is always different, so the number will always be different.
Essentially, in a simple case when equality is defined over the argument type, a function is pure if it can be replaced by an associative array (possibly of an infinite size). Also a function is side-effect free when it's impossible to tell `let b = (f a, f a) in b` from `let b = f a in (b, b)` both executed eagerly.
The problem of this is every function is impure. Any boolean check any math operation any string manipulation or check. Are all functions imported implicitly by your function. This logical inconsistency has always made fp feel a lot like a shady salesman talking about ideals while they are technically impossible to do, ever. I think you did a good job of stating a good middle ground. Fp still has this issue of no true scotsman while all pretending it is possible and the way to do things.
I like the take. But what matters is whether the properties are held. Checking a bool maybe impure, but does it ever behave non deterministically? If it does, we have a more serious problem. A function when executed by a run time might (more that it will) have a side effect but can still be pure given that that side effect is not affecting your program's behavior. As long as the properties are held, you're objectively in a better position to reason about your program. And that's what FP tries to maximize.
@@shadow-ht5gk A pure function can call another pure function without losing purity. It will still be deterministic and doing no side effects. You can chain a bunch of pure functions into another pure function when you see the same chain of calls being made in more than a few places.
@@theteachr the properties aren't held, they aren't real. Your function tries to allocate a string and runs out of memory and needs to somehow stat alive, of course that's impure. Your thread does a calculation and gets shut down in the middle of it and needs to restart and continue correctly - if you actually believe it's pure it should be impossible. In reality these are also possibilities that you are faced with among many others. This purity business is more like something we play with and imagine to improve our code and that's fine because it can help, but we shouldn't forget that all of that is fake and made up by us to help us think in a particular way about things as opposed to describing actual things.
The thing that I want to say: my English language is not good enough to understand the concept of the video, also the voice is too low... But let the video alone and... Welcome back man!!
الله يحميك ❤. بحكي كيف بالبرمجة، استعمال عمليات مثل الرياضيه (بترجع نتيجة وما بتاثر على المعطى) اسهل من عمليات اللي بتغير حالة اشي مثل تغير قيمة بالذاكرة ترسل رسالة على الانترنت
I was left with some doubt. Is it possible to write, for example, a GUI library, a memory allocator, or a caching system in a pure functional way? Or is it that there exists software that can only be written as mostly impure?
Someone *has* to do the side effects. Even if you're writing a memory allocator, you can express its behaviour in a pure functional way. The act of doing / inserting the side effects will be the responsibility of runtime / compiler. The goal is to maximise describing the what over how.
basically, you write as much as possible to be pure, and then a thin veneer of small and simple impure functions. this also has the benefit that it makes changing the ui code easy. so you develop the pure functions in the library, add thin impure functions at the edge, then you can turn it into a cli tool to exercise the parameters, have a separate thin web ui for headless use, and a gui for desktop use. this is why people who do ci and tdd have implausibly high code coverage, because it is mainly pure functions.
You need to name your function such that it's immediately obvious when something mutates and you need to be very consistent with that. Scheme programmers often append ! to their function names which mutate state. Adding commentary is another thing that lazy programmers don't do which makes code harder to reason about.
If you have to comment your code to be understood then it is almost always poorly written. Using named variables and functions and defensive programming goes a long way in making code more readable.
Async is pretty much solved by having virtual threads that eliminate the need for red/blue functions and disjointed mutually incompatible code. It's only a matter of having a GC that makes this possible and a language that supports them
But that means all impurities need be factored out and above, well outside the place where they logically belong. And also you lose passing by reference, even logging a debug value would be impossible
And also pure function doesnt do anything observable, but you need to do something, hence you will always need impurities and propagating them upward into your main is nuts
There's no impurities that "logically belong" in the core logic of your program, aside from those meant to expose the program itself (i.e. logging). Almost all programs consist of three phases: 1. Read input. 2. Operate on input. 3. Output result. Stage 2 is essentially the whole program, and can easily be pure. 1 and 3 need to be impure, but are also very small. That structure is the "sandwich" approach mentioned in the video. "Propagating impurities into your main" is just using return values. You compute the thing, and then you return it. That's how all modern languages work. Pass-by-ref is just an implementation detail. Pass-by-const-ref is semantically identical to pass-by-value, and pass-by-mutable-ref is equivalent to pass-by-value + assignment. For example, you can use both of them in rust while still keeping your functions pure.
If a function mutates a reference passed to it, isn't it still simply testable by calling it on a copy of a value and comparing the mutated 'side effect' with the original value? You could just as easily annotate that the mutation only occurs on the data referenced and effectively treat it as a return value for the sake of testing. It seems to me like returning data is just as much of a "side effect" as mutating a clearly defined segment of data.
It's just a lot more to think about when you find such a reference being passed around with mutation. You'd have to keep a look out for where it's being passed and whether it gets mutated in that place. Values are much easier to reason about. They just can't change. No matter where or how you pass them. Any change is reflected by a new value. A smart compiler can see when the old value is not used after and just do an in place mutation.
5:56 Correction: No! Not all pure functions are idempotent. A function need not be idempotent to be pure.
Einstein never said or wrote that not even in German. This is an idea as old as the early 19th Century.
"95% of quotes atributed to me are false"
Albert Einstein
"Don't believe everything you read on the internet" -Abraham Lincoln
"You should definitely trust everything on the internet" - Sun Tzu, Art of War
If I remember correctly, didn't the quote get famous (and possibly originated from) because of Far Cry 3
@@Undercover_Femboy This quote is common at movies for a long time (it became a platitude already). So it does not surprise me if it appeared in Far Cry.
But Far Cry attributes it to Einstein?
7:06 This pattern is also known as "Functional Core, Imperative Shell".
yep, its a good way of controlling systems. you put the state in the outside world, and then you can only deal with pure functions and transitions of state.
i couldn't help but laugh my ass off when you suggested running the greet function in the morning to test if it says good morning 😆
Functional programmers in shambles after seeing the thumbnail
I think they’re well aware of it.
Brilliant video with great examples. I also love how clean the code graphics look😋
Pure functions are generally easier for compilers to optimize, too. But only if the compiler can be sure the function is pure. Thus, it's a good idea to decorate your functions with "pure". This helps developers reading the code too, as they can quickly understand whether they have to worry about side effects or not.
Expressing IO as pure values just pushes a lot of the burden to the runtime / compiler. The advantages can be huge! An intelligent compiler / runtime can decide the best strategy for executing it (concurrent / parallel / ...) and you don't have to pollute your logic with those semantics.
there are a lot of practical problems around pure functions.
1. most functions are impure, and even math functions are often impure (eg in-place functions, functions that emit soft errors).
2. function can be pure while parts of it are not (caching, local io buffers, in-place operations).
3. concept of pure function kind of overlooks memory allocation, which is the largest optimization target and also completely impure.
i think functional programming focuses too much on pure functions, while effect types and performance are shoved aside. this is why overwhelming majority of critical software is written in procedural languages if not assembly.
another downside to pure function concept is that if you add one call to a logger in one place, suddenly 10 functions can become impure. if compiler understands purity and effect types, but cannot parametrize over them/derive them, you'll spend half the time figuring out what effects should function have on a mid-sized project (kind of what happens in Rust with type parameter bounds and lifetimes).
imo, there is a limit to how useful the type information can be and this limit is fairly low, while type information is potentially infinite (array dimension sizes, numeric ranges, predicates, etc can be used to augment type information).
@@Daniel_Zhu_a6f "most functions are impure". I know of many projects where this isn't true. Also, even in a project where it is true I'd argue there is probably a lot to be gained by separating the pure parts into their own functions. Having a function that could be pure aside from allocations should be rewritten. The caller should be responsible for managing the memory. Your argument about logging is of no practical significance. I've never seen a case where logging couldn't be achieved elsewhere, and likely better for it. I have no idea where you got your ideas about types. They are popular for a reason.
@@tolkienfan1972 i didn't say that types are useless. basic data types (primitives, enums, structs, unions, typed arrays) are very useful, but some languages go much further than that, and i'm not convinced that those extra types do anything good.
"logging can be done elsewhere" -- in principle that's correct, in fact, most impure stuff (except maybe time queries) can be pushed to main function or thread main. however, it doesn't seem like a lot of people write code that way (outside of purely functional languages, obviously). i surely won't write it that way, bc it seems like a useless complication.
you say that you know many projects with mostly pure functions -- could you share a couple?
@@Daniel_Zhu_a6f they're internal. But generally math libraries and the like are almost entirely pure. I think beginners should be taught from the beginning to think this way. Knowing the function calls you're looking at are all pure helps immensely reduce cognitive load. You can immediately rule out whole classes if bugs.
Cool video! I think there's a few aspects touched on that are interesting to be discussed:
1. Working with pure functions involved additional complexity and indirection (can get annoying after a few layers)
2. The more explicit (and more) the parameters the more pain to write and read the function call
3. Monkey patching (e.g making the datetime.now return an instrumented value) or something like an optional injected_date parameter which overrides the value (this is similar to how PCBs have test pads at various places to inject/read values)
I'll add that for 2. I've noticed that when writing state machines, the code is so small and neat! (at the expense of state complexity/management, timelines etc.). Every function call (action/state transition) is just the name of the intention, everything else is inferred contextually. It's so freeing to say just "I want a pizza" and your favourite one to be delivered.
1. I'm all in to invest in that additional complexity because I know it has a huge ROI.
2. While I understand the sentiment, I do believe that with good data modelling, it'll be fine. I should be able to support the argument given a code sample.
3. I don't understand the point, please clarify if so. That operation has to happen somewhere, but it's better to be isolated where it just passes down what it read into a pure function which does not need to know about monkey patching.
The "I want a pizza" reminds me of this paragraph I had written which didn't make it to the video:
I give you an A, you give me back a B, that's it. When it's like, "I give you an A, you give me a B because it's Tuesday. I give you an A, you give me an X because a database entry was modified. I give you an A, but you give me nothing because there is no internet," it's annoying.
@@theteachr Thanks for the reply, I totally understand your view, just thought they'd be interesting to mention in a future video.
There is this spectrum of { full modular, minimize state 1 function monolith, maximize state } onto which codebases can be put and I find both ends painful to work with, it's interesting to see where the sweetspot is depending on the use case.
For 3., yes in theory breaking a function down into deterministic and non-deterministic blocks and extracting the deterministic parts to be unit tested is very nice, but sometimes the non-deterministic part is in some nested control flow and not so obvious to extract; there's also cases where a refactor to pure functions is too costly or unfeasible (e.g. testing a 3rd-party library) and more blackboxy methods like moneky patching, e2e tests in deterministic environments, etc. are more useful
An interesting parallel with digital circuits would be circuits that are "pure", aka, they have an equation and inputs and outputs, for ex, an AND gate, and circuits with feedback, a Flip-Flop, which is what basically creates mutable state in computers.
Academics got too rung up on purity, and having no side-effects, but in the real world, everything has side effects. That's why quantum physics is hard to understand, you measure something, you change it, nothing is pure like in mathematics.
Mathematical functions are missing state, that's more of a problem of mathematics not being able to deal with discontinuous functions. Its ironic you can approach discontinuous functions by using computation and "brute force", that's called discrete analysis.
Linear algebra is much more useful than calculus. Maybe that's why physics is so hard, we need to learn through simulation instead of declaration, maybe that's why mathematics is both incomplete and/or inconsistent, you need to have state.
Ironically Tensors kind of represent state indirectly because they can have arbitrary dimension, you represent state by the way you array the internal matrices in a Tensor, they go around the scenery path instead of having "mutable functions" to simplify things (ends up making them way complex, Tensors are just "struct types" for us programmers)
But I digress.
passing multiple related parameters is done by passing a struct. it is literally in the language to facilitate information hiding.
about that quote in the beginning
imagine you are practicing any skill
in other words, doing something over and over and expecting to improve
will you call that insanity?
No, you’re expecting the same result: Improvement. More technically, you wouldn’t be doing the same thing either. Every time you do it again, your previous doing would have changed you.
@@theteachr i see your point
but still
there are many things where our effort is not the only factor and trying again and again is not insanity
i do not completely agree with that quote
this bread analogy is exactly what I thought as soon as I've heard about FP
there's nothing bad about having impurity in your 'main' function or your first layer of the programm, but as soon as you get out of there you should use pure functions.
I think the food analogy is great because people who worry about separating functions that are pure and impure are like people who must keep different foods separated on their plate and not touching. Same goes for most programming paradigms actually. What actually matters the most is does it taste good, there are too many things to consider when plating up that it will decrease the time you spend actually considering the result you are trying to achieve.
Insightful and well articulated. Thanks👏👏
5:36 iconic line
what i've discovered recently for myself are pure-impure functions. they have a pure function at the core, but have optional /flag arguments that make them read data from files or save results to files or log loop progress, etc. this makes function composable and testable while keeping the brevity and locality of behavior that we like about effectful functions.
eg the code at 2:20 could be rewritten to accept time as an optional parameter. then the function would be pure if time is passed and would infer system time if null pointer is passed in place of time.
While I don't completely dismiss this idea, every flag results in a branch, doubling the number of valid paths, which would bother me. I can understand if it's small piece of code, but I would still prefer the decorator. Pure function is completely pure and the impure counterpart just wraps over it with side effects and / or reading external sources.
@@theteachr i'm not sure what you mean by a "decorator". if it's just a function that provides additional pre/post processing of arguments/return values of a target function, then i don't see much difference between these approaches.
if it's something like python decorators or "design patterns"TM decorators, then i don't like them. i find them very cumbersome and not suitable for most tasks.
if it's something along the lines of lisp-style macros, or some other code generation technique, then it's a total overkill for 99% of tasks.
Hmm, this idea might be formalizable into some kind of polymorphism around the effect system.
Oh wait… Isn't this what Idris does already? Also, free monads are a very similar concept.
or you can just wrap your impure function around the pure one as shown in the video.
this is better, as you don't muck up your api with the optional parameter. also because the pure function is testable, and the impure function is almost trivial because it is just thin glue around the pure function, so it is near trivial. it makes ci and tdd easy.
I don’t get why all impure function are idempotent bij nature… Take f x = x + 1. Then f(1) != f(f(1)). What makes f impure?
f is not impure, but you did point out the incorrect thing I said. I meant to say, "pure functions are idempotent." But that's wrong. Pure functions need not be idempotent. Thanks for bringing this up.
I gained valuable insights from this video. I've been using the "sandwich pattern" a lot but didn't know it can be called that way. Also more recently I'm having issues about what to name and where to place those "filling" pure functions. I tend to place them in utils even when they're really only used for a specific place lol
Also I guess the sandwich pattern can be hard to apply to e.g. DB calls when you can integrate a lot of the filling into the query, e.g. sorting, filtering, transformations
Isn’t everything a utility? Shouldn’t they all go in utils?
Utils is a smell. The filling pure functions should have a name and place inside the core. All side effect-y things can go into an IO namespace. From what I read, you are giving less importance to the filling.
Our man is back!
Good thought invoking video! Pure functions aid a lot is composibility and security as well.
I guess effects would really depend on the context(the environment your computation interacts with). For example simple cli tools like cat, wc, grep can be seen as pure functions, given a same file produces the same output file which further can be composed. (Which really made UNIX successful), or relational operators in databases.
The only place i can think of , where we woudnt need pure functions in our application(core) itself would be some cryptographic tool, that generates a different hash for the same input or a random number generator, but there may be more.
RNGs can be pure (I think). You give the same seed, they give the same number alongside a new RNG with its state updated. The source of the seed is what's random. Like one of the lava lamps in the Cloudflare hall. The image of the lamp is the seed. But given the same image, the RNG should be able to produce the same number. Practically, the image is always different, so the number will always be different.
The best thing i got to know from the video is that "Burgers are Sandwiches"
Burgers are sandwiches but sandwiches are not burgers.
Keep up the good work!
Essentially, in a simple case when equality is defined over the argument type, a function is pure if it can be replaced by an associative array (possibly of an infinite size). Also a function is side-effect free when it's impossible to tell `let b = (f a, f a) in b` from `let b = f a in (b, b)` both executed eagerly.
This is getting into referential transparency.
@@theteachr yes, it also touches functional extensionality
Your videos look so clean! What do you use/do to make them look as good as they do?
theteachr.github.io
Also attributed to A. Einstein: to produce yet another video about pure functions and expecting a different outcome...
grep is a pure function.
Everything is pure in an immutable context.
How do you make these videos! They seem wonderful! Is it some powerpoint morph magics? Or is it motion canvas
Keynote Magic Move >>> PowerPoint Morph
Vaas Montenegro*
Gonna go do this to test my untested js
What is that font? It's so good. Can you link to me?
Rec Mono Semicasual
Nice to have you back!
The real slim shady’s back again
The problem of this is every function is impure. Any boolean check any math operation any string manipulation or check. Are all functions imported implicitly by your function.
This logical inconsistency has always made fp feel a lot like a shady salesman talking about ideals while they are technically impossible to do, ever.
I think you did a good job of stating a good middle ground.
Fp still has this issue of no true scotsman while all pretending it is possible and the way to do things.
Fair point, I guess to make it truly pure it needs to pass definitions for any operators/functions that are used in the function as arguments.
I like the take. But what matters is whether the properties are held. Checking a bool maybe impure, but does it ever behave non deterministically? If it does, we have a more serious problem. A function when executed by a run time might (more that it will) have a side effect but can still be pure given that that side effect is not affecting your program's behavior. As long as the properties are held, you're objectively in a better position to reason about your program. And that's what FP tries to maximize.
@@shadow-ht5gk A pure function can call another pure function without losing purity. It will still be deterministic and doing no side effects. You can chain a bunch of pure functions into another pure function when you see the same chain of calls being made in more than a few places.
@@theteachr the properties aren't held, they aren't real. Your function tries to allocate a string and runs out of memory and needs to somehow stat alive, of course that's impure. Your thread does a calculation and gets shut down in the middle of it and needs to restart and continue correctly - if you actually believe it's pure it should be impossible. In reality these are also possibilities that you are faced with among many others. This purity business is more like something we play with and imagine to improve our code and that's fine because it can help, but we shouldn't forget that all of that is fake and made up by us to help us think in a particular way about things as opposed to describing actual things.
The thing that I want to say: my English language is not good enough to understand the concept of the video, also the voice is too low... But let the video alone and...
Welcome back man!!
الله يحميك ❤. بحكي كيف بالبرمجة، استعمال عمليات مثل الرياضيه (بترجع نتيجة وما بتاثر على المعطى) اسهل من عمليات اللي بتغير حالة اشي مثل تغير قيمة بالذاكرة ترسل رسالة على الانترنت
@@salim444 سلمت وغنمت يا رب، شكراً.
انا لسا قايم أصلي، رح ادعي لك كشكر على حسن لطفك. 🌹
Very informative, Good job.
I was left with some doubt. Is it possible to write, for example, a GUI library, a memory allocator, or a caching system in a pure functional way? Or is it that there exists software that can only be written as mostly impure?
Someone *has* to do the side effects. Even if you're writing a memory allocator, you can express its behaviour in a pure functional way. The act of doing / inserting the side effects will be the responsibility of runtime / compiler. The goal is to maximise describing the what over how.
basically, you write as much as possible to be pure, and then a thin veneer of small and simple impure functions.
this also has the benefit that it makes changing the ui code easy. so you develop the pure functions in the library, add thin impure functions at the edge, then you can turn it into a cli tool to exercise the parameters, have a separate thin web ui for headless use, and a gui for desktop use. this is why people who do ci and tdd have implausibly high code coverage, because it is mainly pure functions.
Great video! Make more
are you pure programmer or you use js on side?
Very good
You need to name your function such that it's immediately obvious when something mutates and you need to be very consistent with that. Scheme programmers often append ! to their function names which mutate state. Adding commentary is another thing that lazy programmers don't do which makes code harder to reason about.
Even Ruby does !
If you have to comment your code to be understood then it is almost always poorly written. Using named variables and functions and defensive programming goes a long way in making code more readable.
@@ImperiumLibertas On occasion you need the "why" of what you're doing. Good comments add context, not restate the what.
Nice
if only you pure function people have put so much effort into sync/async functions...
Because doing so would make them impure.
Async is pretty much solved by having virtual threads that eliminate the need for red/blue functions and disjointed mutually incompatible code. It's only a matter of having a GC that makes this possible and a language that supports them
@@NJ-wb1cz functional programming is exactly the kind of a thing that would make async functions achievable without coloring or even runtime
@@sunofabeach9424 I'm not talking about ifs or woulds, I'm talking about java that already has async without color functions or async/await
@@sunofabeach9424 can you provide an example where this is implemented?
But that means all impurities need be factored out and above, well outside the place where they logically belong. And also you lose passing by reference, even logging a debug value would be impossible
And also pure function doesnt do anything observable, but you need to do something, hence you will always need impurities and propagating them upward into your main is nuts
There's no impurities that "logically belong" in the core logic of your program, aside from those meant to expose the program itself (i.e. logging).
Almost all programs consist of three phases:
1. Read input.
2. Operate on input.
3. Output result.
Stage 2 is essentially the whole program, and can easily be pure. 1 and 3 need to be impure, but are also very small. That structure is the "sandwich" approach mentioned in the video.
"Propagating impurities into your main" is just using return values. You compute the thing, and then you return it. That's how all modern languages work.
Pass-by-ref is just an implementation detail. Pass-by-const-ref is semantically identical to pass-by-value, and pass-by-mutable-ref is equivalent to pass-by-value + assignment. For example, you can use both of them in rust while still keeping your functions pure.
You feel the need to log a debug value because you can't reason about your program without running it.
@@SMorales851 Thank you for the explanation!
if you need debug values, just run the process in a debugger
1 That is not how a definition works
2 Albert Einstein never said that
There are no impure functions, those are called procedures. its all the fault of the languages derived from C
C has nothing to do with this. This is a nomenclature problem that existed since algol. function vs procedure vs subroutine vs method
also, you could still have an impure function, as long as it is indeterministic.
Bro really quoted vaas and expected me not to notice
If a function mutates a reference passed to it, isn't it still simply testable by calling it on a copy of a value and comparing the mutated 'side effect' with the original value? You could just as easily annotate that the mutation only occurs on the data referenced and effectively treat it as a return value for the sake of testing. It seems to me like returning data is just as much of a "side effect" as mutating a clearly defined segment of data.
It's just a lot more to think about when you find such a reference being passed around with mutation. You'd have to keep a look out for where it's being passed and whether it gets mutated in that place. Values are much easier to reason about. They just can't change. No matter where or how you pass them. Any change is reflected by a new value. A smart compiler can see when the old value is not used after and just do an in place mutation.
clickbait
no its not
I love that FP don't think we can determine that the sun will come up tomorrow. Times isn't that scary lol