Functional Programming for Pragmatists • Richard Feldman • GOTO 2021
Вставка
- Опубліковано 31 тра 2024
- This presentation was recorded at GOTO Copenhagen 2021. #GOTOcon #GOTOcph
gotocph.com
Richard Feldman - Functional Programming Language Expert & Author of “Elm in Action”
ABSTRACT
Do you care more about how well code works than how conceptually elegant it feels? Are you more interested in how effectively you can build and maintain software than how buzzword-compliant it is? Then this is the talk for you!
People like functional programming for different reasons. Some like it for the conceptual elegance, or the mathematical properties. Richard? He likes to build things. He likes it when the software he builds works well and is easy to maintain. For the past decade he's been using functional programming both professionally and as a hobbyist, and has found it has helped him ship higher quality software in less time than in the decade he spent writing object-oriented code before.
In this talk, he'll share the practical benefits he's enjoyed in FP, and the benefits other pragmatists [...]
TIMECODES
00:00 Intro
04:17 Outline
04:31 Scope: What is functional programming?
06:32 Performance
06:51 Scope: Pure functions
08:55 Performance: Caching
10:57 Performance: Precomputing
12:14 Performance: Parallelizing
15:00 Performance: Performance drawbacks
19:02 Development
19:32 Development: Testing
22:26 Development: Revising
25:49 Development: Debugging
31:18 Development: Development drawbacks
32:35 Ecosystem
38:09 Summary
40:15 Outro
Download slides and read the full abstract here:
gotocph.com/2021/sessions/197...
RECOMMENDED BOOKS
Richard Feldman • Elm in Action • amzn.to/387kujI
Jeremy Fairbank • Programming Elm • amzn.to/2WhZCE8
Wolfgang Loder • Web Applications with Elm • amzn.to/3jblQ3q
Cristian Salcescu • Functional Programming in JavaScript • amzn.to/3y75jBS
/ gotocon
/ goto-
/ gotoconferences
#FunctionalProgramming #FP #Elm #ElmInAction #Elmlang #Testing #Programming #ProgrammingLanguage #Immutability #PureFunctions #FunctionalLanguages #Debugging #Precomputing #Parallelizing #npm #JavaScript
Looking for a unique learning experience?
Attend the next GOTO conference near you! Get your ticket at gotopia.tech
SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.
ua-cam.com/users/GotoConf... - Наука та технологія
Richard Feldman is an excellent teacher. I always learn something from him. It's a good feeling when the light bulb lights up.
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?
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.
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.
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.
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.
Richard Feldman is the best
Another excellent talk from Richard Feldman!
37:30 is the main point. Limitation is power. Great talk.
@@peach_of_justus Ultimate power ultimately corrupts.
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
Elm sounds too good to be true. Will def. pick this up over the weekend.
Excellent talk!
he really convinced me about functional programming
Great video and speech! Thank you Richard.
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.
Fantastic talk! Hear, hear. 👏
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
I love to listen to this guy. But I should start coding
I choose functional techniques out of fear
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?
A very good talk, thank you! Concise presentation, clearly laid out thoughts.
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. ;)
Great talk and proving specially if you are a JS dev 34:40
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.
Good video !
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.
so avoid side effects and mutations makes it fp style?
@@peach_of_justus thanks
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.
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.
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.
it depends on what you do... try doing woodworking with a screw driver
Nice
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
ok
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
actually all skrew drivers are object 😁
Everything that happens is via function-calls. 😁
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.
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.