Looking for books & other references mentioned in this video? Check out the video description for all the links! Want early access to videos & exclusive perks? Join our channel membership today: th-cam.com/channels/s_tLP3AiwYKwdUHpltJPuA.htmljoin Question for you: What’s your biggest takeaway from this video? Let us know in the comments! ⬇
Excellent summary of the merits of functional programming for the pragmatist. I wish this wisdom replaced the conventional wisdom of Uncle Bob's Clean Code, which is filled with counterexamples. That text seems to revel in solving a problem with the most mutations.
Inspiring talk. In my opinion the whole industry needs this kind of pragmatic and moderated approach in explaining the value and benefits of FP, instead of fideistic battles.
The point is that, in general, people don't want to get out of their comfort zone and embrace OOP with blind faith. Many don't even care about improving. It's a matter of attitude towards continuous improvement.
One benefit that I would love to see a language add: In pure functional languages you can automatically skip computations that do not lead to any effect. You can treat the entire program as a directed graph where the function calls are nodes and the edges are values. Any node that does not have path to a task (something that produces user-visible output) can be removed from the graph without affecting the program
The key here, I think, is the part about dependencies. Either they are implicit (which might bite us back), or we make them explicit but introduce verbosity instead (which can lead to confusion). So it is a tradeoff, as usual. We can sort of circumvent it by making PL itself bear the burden of providing developers with explicit and clear abstractions for dependency management (like algebraic effects and *not* like Haskell's do-notation). But this means that either 1) developer must spend more time learning the language which is sort of okaish or 2) PL developers need to spend more time designing the language.
In addition to what I said before, if we rely on PL for abstractions to manage implicit dependencies, we'd better have a way to quickly adapt or change the language to match the task. There can be no universal functional PL of course, so isn't it better to have a way to quickly design one for the task at hand? So far I haven't found anything like that. Racket sort of tries to do this with language-driven development but I don't think it worked out well. We need better tools. Like LLVM but for FP, or multi-stage programming with multilayer macro system to modify the language. And better IDEs for all of that, of course. Unfortunately, there's very little research going on in this area. A pity, I blame LLMs for drawing postgrad attention in the wrong direction.
What this guy does would definitely be the next big thing for the evolution of the developer society if they listen. Sadly, today's developers are more attracted to all those shiny new JS frameworks that are garbage in reality.
I think it's hard for an imperative programmer like me to get their head around it. For example, the discussion of promises in JavaScript vs tasks in Elm. With JS you're telling the computer what to do, with Elm you're describing what you want done and the computer figures out how to do it later. I had to sleep on it before I understood what he was saying. It's a shift busy developers don't have time to make, but I agree, they should take the time to understand it.
@@gimlam5909 Svelte is a framework that compiles to JS in order to gain performance and a more comfortable syntax. Elm has already been doing that for years. If you put some time on it, i promise you it'll be worth it
@@MeNumber47Elm is great but it has a steeper learning curve, unusual syntax and requires accepting mental paradigm shift. Who was "compiling to JS first" is not a settling point at all. ;)
This is a great nuance knowing you have functional AND imperative stuff in your toolbox as you'd default to functional programming for the very reasons he discussed. Nice talk!
how about integration tests? unless your program does not interact with any external dependency they will still be flaky as it depends on the actual behavior of other things outside your function, right?
is managed effect just like a thunk (wrapper fn) scheduled by main function? At 21:48, when Richard talked about simulation, it sounds like a stubbing in oop.
Switched to functional programming because of the time you waste on debugging and side effects. In imperative 95% debugging 5% typing your dream code, in functional 95% typing dream code 5% debugging. 🤭♥ I recall trying to use C# as a pure functional style but it never truly worked, the same story as he had with JS. It's just doesn't work. C# has matured a lot and took a lot of ideas from functional paradigm but you still wasting a lot of time on trivial things that can easily brake everything, in functional language they just don't exist. As the guy said - you just don't think about those things any more.
About global variables, it's only accessible to functions in files that are linked to the file containing the global variable, not all functions in the program.
I think you know this, Richard, and probably just want to avoid introducing too much terminology into the talk. But I just wanted to point out that at 28:49, technically, if the function has side effects, it isn't "pure", it is "idempotent" though, which I believe is what you meant.
I don't think that is accurate. You can always memoize per thread or have a thread safe map that is depended on for memoization. It should just a be a question of how it is supported/implemented by the language.
@@Cookipolation memoization is essentially always impure. For it to be used in a pure functional language, it generally requires language level support.
It's the most stable language I know and a delight to work on. You'll love yourself for chosing Elm today in 10 years when you'll want/need to refactor your app. The fact that it hasn't had an update in 3 years is just how stable it is. There have been no updates, because the language just doesn't need it.
Cool, but then how to write to or read from a database? These principles work as long as your code is isolated from the outside world, but such code is useless. How to use this style for real world applications where database access is required too?
I believe the "IO monad" is what is used for overall side effects of the program in pure FP. Essentially, your main function gets an instance of this IO monad and must return it at the end. Every impure operation is then modeled as a function that takes it as one of its arguments and return its replacement at the end. Essentially, it represents the state of the universe. An impure operation consumes it, and returns the new state, which is different, so using the returned value again cannot just use the previous cached result. All sorts of input-output tasks, including database interactions, must thus be implemented over the IO monad in a pure functional language
@@kamertonaudiophileplayer847 it just takes an extra loop of tasks. First run a task to get the seed(time or whatever) from that point on, anything that needs randomness just depends on that initial input and what is derived from it. So it is pure, but an input is random, leading to random outputs.
Even the title is FALSE: pragmatic programmer would rather use a combination of tools not just FP. There is no such program that would prefer to be written in one paradigm.
Richard Feldman even admits that FP is not appropriate for all domains. He said that FP is good when you are far away from bare metal and you are't super concerned with performance (unless you use Roc or some other high performance FP). He said that if you do low level, then it is more fitting to be imperative because the CPU is super imperative. So no, you don't know what the fuck you are talking about with your comment. Actually watch Richard Feldman's videos before spewing this toxicity.
![กี่หมื่นฟ้า | Your Sky Series EP.1 [1/4]](http://i.ytimg.com/vi/vLGjxFL6U_I/mqdefault.jpg)
Looking for books & other references mentioned in this video?
Check out the video description for all the links!
Want early access to videos & exclusive perks?
Join our channel membership today: th-cam.com/channels/s_tLP3AiwYKwdUHpltJPuA.htmljoin
Question for you: What’s your biggest takeaway from this video? Let us know in the comments! ⬇
Richard Feldman is an excellent teacher. I always learn something from him. It's a good feeling when the light bulb lights up.
Clear, concise, and to the point. Nice how it shows the pragmatic utility using code snippets.
Excellent summary of the merits of functional programming for the pragmatist.
I wish this wisdom replaced the conventional wisdom of Uncle Bob's Clean Code, which is filled with counterexamples. That text seems to revel in solving a problem with the most mutations.
18:00 "It's just the thing that would be coming out of the look-up table is a task". That's eye-opening for me, thank you.
Inspiring talk. In my opinion the whole industry needs this kind of pragmatic and moderated approach in explaining the value and benefits of FP, instead of fideistic battles.
The point is that, in general, people don't want to get out of their comfort zone and embrace OOP with blind faith. Many don't even care about improving. It's a matter of attitude towards continuous improvement.
Love the fact that the most replayed sections are about the drawbacks
How do you see which sections are played the most?
So the whole thing?
Elm sounds too good to be true. Will def. pick this up over the weekend.
37:30 is the main point. Limitation is power. Great talk.
@@indicted_ham_sandwich Ultimate power ultimately corrupts.
I choose functional techniques out of fear
Richard Feldman is the best
One benefit that I would love to see a language add: In pure functional languages you can automatically skip computations that do not lead to any effect. You can treat the entire program as a directed graph where the function calls are nodes and the edges are values. Any node that does not have path to a task (something that produces user-visible output) can be removed from the graph without affecting the program
This already exist, it's called lazy evaluation
The key here, I think, is the part about dependencies. Either they are implicit (which might bite us back), or we make them explicit but introduce verbosity instead (which can lead to confusion). So it is a tradeoff, as usual. We can sort of circumvent it by making PL itself bear the burden of providing developers with explicit and clear abstractions for dependency management (like algebraic effects and *not* like Haskell's do-notation). But this means that either 1) developer must spend more time learning the language which is sort of okaish or 2) PL developers need to spend more time designing the language.
In addition to what I said before, if we rely on PL for abstractions to manage implicit dependencies, we'd better have a way to quickly adapt or change the language to match the task. There can be no universal functional PL of course, so isn't it better to have a way to quickly design one for the task at hand? So far I haven't found anything like that. Racket sort of tries to do this with language-driven development but I don't think it worked out well. We need better tools. Like LLVM but for FP, or multi-stage programming with multilayer macro system to modify the language. And better IDEs for all of that, of course. Unfortunately, there's very little research going on in this area. A pity, I blame LLMs for drawing postgrad attention in the wrong direction.
What this guy does would definitely be the next big thing for the evolution of the developer society if they listen. Sadly, today's developers are more attracted to all those shiny new JS frameworks that are garbage in reality.
I think it's hard for an imperative programmer like me to get their head around it. For example, the discussion of promises in JavaScript vs tasks in Elm. With JS you're telling the computer what to do, with Elm you're describing what you want done and the computer figures out how to do it later. I had to sleep on it before I understood what he was saying. It's a shift busy developers don't have time to make, but I agree, they should take the time to understand it.
Conversely, the shiniest, newest framework might actually be the only suckless js framework so far - Svelte.
@@gimlam5909 Svelte is a framework that compiles to JS in order to gain performance and a more comfortable syntax. Elm has already been doing that for years. If you put some time on it, i promise you it'll be worth it
@@MeNumber47Elm is great but it has a steeper learning curve, unusual syntax and requires accepting mental paradigm shift. Who was "compiling to JS first" is not a settling point at all. ;)
he really convinced me about functional programming
Another excellent talk from Richard Feldman!
I love to listen to this guy. But I should start coding
Great video and speech! Thank you Richard.
Excellent talk!
This is a great nuance knowing you have functional AND imperative stuff in your toolbox as you'd default to functional programming for the very reasons he discussed. Nice talk!
MementosJhgjbyb
Fantastic talk! Hear, hear. 👏
how about integration tests? unless your program does not interact with any external dependency they will still be flaky as it depends on the actual behavior of other things outside your function, right?
is managed effect just like a thunk (wrapper fn) scheduled by main function? At 21:48, when Richard talked about simulation, it sounds like a stubbing in oop.
A very good talk, thank you! Concise presentation, clearly laid out thoughts.
Great talk and proving specially if you are a JS dev 34:40
Switched to functional programming because of the time you waste on debugging and side effects. In imperative 95% debugging 5% typing your dream code, in functional 95% typing dream code 5% debugging. 🤭♥
I recall trying to use C# as a pure functional style but it never truly worked, the same story as he had with JS. It's just doesn't work. C# has matured a lot and took a lot of ideas from functional paradigm but you still wasting a lot of time on trivial things that can easily brake everything, in functional language they just don't exist. As the guy said - you just don't think about those things any more.
About global variables, it's only accessible to functions in files that are linked to the file containing the global variable, not all functions in the program.
I think you know this, Richard, and probably just want to avoid introducing too much terminology into the talk. But I just wanted to point out that at 28:49, technically, if the function has side effects, it isn't "pure", it is "idempotent" though, which I believe is what you meant.
Good video !
so avoid side effects and mutations makes it fp style?
@@indicted_ham_sandwich thanks
Memoization and parallelization can't quite be simultaneous features of thread safe pure functions :)
I don't think that is accurate. You can always memoize per thread or have a thread safe map that is depended on for memoization. It should just a be a question of how it is supported/implemented by the language.
@@brendanhansknecht4650 you're proposing impure solutions
@@Cookipolation memoization is essentially always impure. For it to be used in a pure functional language, it generally requires language level support.
@@brendanhansknecht4650 exactly
That doesn't add any value to comment on. All pure languages eventually compile to impure constructs. Modern hardware is innately impure.
Is it safe to use Elm as it is not stable yet?
It is, the version number doesn't reflect it. But at this point it hasn't changed significantly for some years and won't according to the author.
It's the most stable language I know and a delight to work on. You'll love yourself for chosing Elm today in 10 years when you'll want/need to refactor your app. The fact that it hasn't had an update in 3 years is just how stable it is. There have been no updates, because the language just doesn't need it.
it depends on what you do... try doing woodworking with a screw driver
Nice
Errr.. FUNCTIONS ABSTRACT OVER EXPRESSIONS. End of briefest possible explantion! Simples... (:-)
Cool, but then how to write to or read from a database? These principles work as long as your code is isolated from the outside world, but such code is useless. How to use this style for real world applications where database access is required too?
I believe the "IO monad" is what is used for overall side effects of the program in pure FP. Essentially, your main function gets an instance of this IO monad and must return it at the end. Every impure operation is then modeled as a function that takes it as one of its arguments and return its replacement at the end. Essentially, it represents the state of the universe. An impure operation consumes it, and returns the new state, which is different, so using the returned value again cannot just use the previous cached result. All sorts of input-output tasks, including database interactions, must thus be implemented over the IO monad in a pure functional language
const int global1;
What's up with Elm? Is it dead?
More Stable than ever. Still widely used. Give it shot if you get a chance. The more time you put into it, the more it gives back
It is too bad, no way to generate a unique id using a pure function.
Incorrect. You could, e.g. make the seed of the PRNG a parameter to the generator-function.
The way RNG is used in pure langs is you pass a seed in and get the result and new seed to use next time back.
@ So a pure function can return a different result for the same request parameter, you need somehow to deliver that to not very smart viewers.
@@kamertonaudiophileplayer847 it just takes an extra loop of tasks. First run a task to get the seed(time or whatever) from that point on, anything that needs randomness just depends on that initial input and what is derived from it. So it is pure, but an input is random, leading to random outputs.
@@kamertonaudiophileplayer847 the same seed will always return the same value in a pure language.
What’s the hurry? Please talk slower. I quit watching because it makes me uneasy.
Even the title is FALSE: pragmatic programmer would rather use a combination of tools not just FP. There is no such program that would prefer to be written in one paradigm.
chill
@@VeejayRampay aight, aight.
Richard Feldman even admits that FP is not appropriate for all domains. He said that FP is good when you are far away from bare metal and you are't super concerned with performance (unless you use Roc or some other high performance FP).
He said that if you do low level, then it is more fitting to be imperative because the CPU is super imperative.
So no, you don't know what the fuck you are talking about with your comment. Actually watch Richard Feldman's videos before spewing this toxicity.
@@Nellak2011
Content: fine
Title: wrong; clickbaity
capiche!
That makes as much sense as saying that a pragmatic programmer would sometimes prefer Assembly.
Great video and speech! Thank you Richard.