Functional Programming in 40 Minutes • Russ Olsen • GOTO 2018
Vložit
- čas přidán 8. 11. 2018
- This presentation was recorded at GOTO Berlin 2018. #gotocon #gotober
gotober.com
Russ Olsen - Author of Getting Clojure and Eloquent Ruby, VP at Cognitect
ABSTRACT
Functional programming has finally escaped from academia. These days developers are building real systems in functional programming languages like Clojure, Scala, Elixir and F#. Functional techniques are also seeping into more traditional languages like Java and Ruby. Unfortunately somewhere along the way functional programming has also developed a reputation for being deep and mysterious: Good programs achieve the Zen-like state of being functional which somehow involves immutability, higher order functions [...]
Download slides and read the full abstract here:
gotober.com/2018/sessions/546
RECOMMENDED BOOKS
Eric Normand • Grokking Simplicity • amzn.to/3gz7o3C
Daniel Higginbotham • Clojure for the Brave and True • amzn.to/38tZjsF
Ulisses Almeida • Learn Functional Programming with Elixir • amzn.to/389grn6
Neal Ford • Functional Thinking • amzn.to/3DdP35B Petricek & Skeet • Real-World Functional Programming • amzn.to/38diF4M
Venkat Subramaniam • Functional Programming in Java • amzn.to/2WlOXIt
Cristian Salcescu • Functional Programming in JavaScript • amzn.to/3y75jBS
Richard Feldman • Elm in Action • amzn.to/387kujI
Jeremy Fairbank • Programming Elm • amzn.to/2WhZCE8
Wolfgang Loder • Web Applications with Elm • amzn.to/3jblQ3q
/ gotober
/ gotoconference
#FunctionalProgramming #Clojure #Scala #Elixir #Fsharp
Looking for a unique learning experience?
Attend the next GOTO Conference near you! Get your ticket at gotocon.com
SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.
czcams.com/users/GotoConf... - Věda a technologie
One of the most sensible and clear explanation about Functional Programming.
And still, as a beginner, I don't take anything new from this video, that I could use..
František Heča same, but I hope I can use this video as a stepping stone into the world of FP
btw. Closures are bad/lazy programming.
@@alejandrotorres-py4wz wow so smart
@@frantisek_heca You were not the only one. I have been programming for years and still have no clue how functional programming works in reality. Pep talk rather than a true presentation of value.
I tend to use my own paradigm - a blend of ObjectOriented and functional, which others seem to refer to as 'Objectional' programming.
lol under rated comment
I have adopted something pretty common called disfunctional code
I can't get over the irony of having a talk about functional programming in a conference called "goto", the epitome of procedural thinking :D (great talk though!)
It's like having a religious meeting called 'Satan 2018'.
Your statement considered harmful.
Procedural programming is quite the opposite of "goto". Procedural programming is further development of structured programming. And the whole reason why structured programming was invented is to get rid of "goto".
@@antonkapelyushnik47 My statement is a joke, apologies if that wasn't clear
Fun fact: some functional languages compile tail recursion to goto jumps to avoid stack overflow. And to be honest, everything compiles to some form of jump somewhere down the line since everything eventually has to run on hardware.
@@ianzen pretty much - hardware inherently involves unsafe things, mutations, jumps. higher level programming is about creating abstractions over top of it, restricting us in a way that makes structuring applications simpler to reason about and protect ourselves
When I heard about Clojure for the very first time my reaction was exactly like that “ how can you build anything if you can’t change your data!?!”. I love how this speech explains that. Great one!
A note on Principia Mathmatica:
In modern mathematical language, proving 1+1=2 is WAY more compact. This is because modern mathematics is much DRYer than Russel and Whitehead. In R&W, they duplicate the 'code' defining set operations (union, intersection, etc.) as the code defining relations (all the same formulas with a friggin dot over all the symbols. Just twenty papges of repetition.) This is because the idea that a relation is a set of tuples came AFTER Principia.
A note on side-effects:
Haskell does this best. Haskell does side-effects by constructing a data structure representing side-effectful computation. Since functions are data, this data structure consists of nested functions taking values and producing side-effect representations (which recursively contain functions taking values returning side-effect representation and so on). As the runtime evaluates this side-effect representation, it progressively calls these nested functions. It's all-together very elegant, built on only one primitive: compose a side-effect with a side-effect-producing function into a new side-effect, without ever actually making anything happen.
A note on the pie chart:
96% functions means 96% code that CANNOT sneak up on you. 96% guaranteed thread-safe code. 96% trivially unit-testable code.
best comment
Thank you, this is interesting. Could you please explain how the idea of relations as sets of tuples makes 1+1=2 proof easier? And why was it so hard before?
Excellent explanation of Haskell effects without the 'M-word'. Congratulations!
Another super important thing about Principia is that Whitehead and Russell worked within the logicism program. You can very easily take natural numbers as primitive, like Brouwer does, and then 1 + 1 = 2 is pretty much true by definition
«This is because the idea that a relation is a set of tuples came AFTER Principia.»
--
That a relations CAN be represented as tuples, and ONLY when suitable (actual value, among others) !
Smarty functionals, in whatever language, would better prove the superiority by means of concrete implementations, instead of "talking the functional superiority".
"Immutability of inputs"
"Immutability of outputs"
Excel is a functional programming language.
Correct
muddi900 And a beautiful one at that. It sort of flips programming upside down. Instead of looking at the code and imagining the data being transformed at each stage, you type the code into a box, and the code disappears, and all you see is the raw data in its new, transformed state.
@@dupersuper1000 There is Jupyter, Lighttable, Spark for functional languages like Clojure, Haskell, Python, APL, etc...
czcams.com/video/nYBW4ExtNvo/video.html
What Excel is missing is the ability to name the functions you create and then reuse them (as far as I know). That feature would make VisualBasic mostly obsolete.
Im working on exactly this...getting excel type fp integrated into 5th gl server sides...its Realy exiting ☺️
he is soo genuinely happy explaining wht he knows..its inspiring
Fabulous! Clear, concise. Thank you for making the presentation. It helped me get a handle on what FP means and how it translates into the real world. Cheers!
Hands down the best introduction to functional programming on CZcams.
A key problem with adoption is that many of the prominent gurus are math-oriented computer scientists who don't understand how to communicate well with pragmatic working programmers.
Olsen gets over the key ideas here without muddying the waters with monads or functors or currying or any of the esoteric terms that are so off-putting to the newbie. He presents FP as something accessible that solves real-world problems.
But he doesn't over-promise. To hear some of the enthusiasts, FP is some kind of magic fairy dust that makes all the messiness of real development go away.
Outstanding!
Im so glad youtube algorithm re-upped this. This is one of the best fundamental talks for people who already have a programming or mathematics background or academic experience and want to make sure their next steps are chosen carefully in the world of functional programming. Considering what we learned from Russel and Godel and Cantor, this is pretty close to a fundamental talk about having a sound basis.
Thus far, this is absolutely the best video on the subject.
BTW, if you are short on time, start at 11:17, but I would just listen to the preamble anyway to give you sense (FOR ONCE!) that no, there's no magic here and you don't have to forget everything.
Such a joy to watch this. Just the array to tree concept by itself is an eye-opener.
As someone struggling to really understand functional programming, this video was quite helpful. He touches on something that still doesn't quite make sense to me. Our job is entirely side effects. We get paid to write code that does stuff, and all of that stuff involves interactions with the outside world. When I tried to learn clojure, as one example, I spent some time on it and still had no clue how to actually do anything useful. Now I'm back at it, although this time trying to learn Erlang and I have a similar problem. I learn some basics, but immutability and the lack of side effects makes it difficult for me to figure out how to get any real work done. It's truly a different way of thinking about solving problems and I haven't really got a handle on it yet.
Yeah, it really is a different way of looking at the problem which isn't intuitive if you've learned the standard imperative or OOP style.
The phrase “functional programming doesn’t have side-effects” is not exactly true. For example, those of us who work in the Haskell family of languages have just figured out how to encode side-effects in such a way that we can keep some of the composability and reasoning benefits of non-side-effecting functions in our side-effecting functions. We’ve also done it in such a way that side-effecting code cannot pollute non-side-effecting code. FP languages in general are just more careful with how they deal with side effects. This is chiefly because of the observation that side-effecting code is more challenging to compose than non-side-effecting code. And in some cases side effects make certain ways of composing things literally impossible. So any practical FP language has side-effects. They are just more careful and restrictive about side-effecting code in an effort to achieve the ability to better predict what code will do-including the side-effecting parts.
Store passing style
When given a data structure to your method, don't change the structure. Create a new one having the results of the method.
The way I understand it is the side effects are unavoidable. The point of functional programming is not to entirely eliminate them, but rather to make sure the only side effects in a program happen at very well known and well defined areas.
An absolutely amazing talk, thanks to Russ!
Another functional programming talk that's thick in theory, but thin in practice. Functional programming has its place, but it isn't the silver bullet its proponents claim. Functional programming, for instance, is great for mathematical or processing data, but falls on its face for a GUI, where the state is constantly flux. Many object-oriented languages today already have facilities for functional style programming such as C# Linq.
Now this is what i call an explanation!, thank you for aiding me in my fp journey
From the bottom of my heart
, I'd like to say "Thank you
nice profile picture
This video helped me understand what the heck functional programming actually is. The mathematics comparison is super memorable too. Amazing talk!
I learned two things from this talk: function and atom. Function responsible for what change to make. Atom responsible for making change according to the function. Atom takes care of the complexity of multiple threads, ideally implemented by the language. Developer writes simple functions with no concerns of multi thread. If this is the essence of the FP, this is the first time I get the idea of FP. Either way, I found this talk amusing.
This is an awesome talk ! You explained functional programming in a great way !
I think the moral of this story is, any paradigm taken too far leads right back to whatever you were trying to avoid in the first place, but with extra steps.
In Programming JavaScript Applications by Eric Elliot he brings up a a story from the MIT Lightweight Languages discussion list, by Anton van Straaten:
The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said “Master, I have heard that objects are a very good thing-is this true?” Qc Na looked pityingly at his student and replied, “Foolish pupil- objects are merely a poor man’s closures.”
Chastised, Anton took his leave from his master and returned to his cell, intent on study‐ ing closures. He carefully read the entire “Lambda: The Ultimate...” series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress.
On his next walk with Qc Na, Anton attempted to impress his master by saying “Master, I have diligently studied the matter, and now understand that objects are truly a poor man’s closures.” Qc Na responded by hitting Anton with his stick, saying “When will you learn? Closures are a poor man’s object.” At that moment, Anton became enlightened.
what? that doesn’t follow at all
@@user-tx4wj7qk4t No, I did.
Great Lecture.
Functional programming is growing and this was a great introduction as to why.
Thanks.
Luv and Peace.
Mentions "Principia Mathematica": Hey maybe i should read this and get my math game going
Shows pages: I want to die right now... or go work on a farm
principia isnt useful math anyway
and it's outdated anyway, so unless you are a historian don't read it
This is such a great talk. Thank you.
From a curious laymen: thank you. Truly. This is 40 minutes of clarity and honesty.
@Vendicar Kahn And by the looks of it, you spent another 40 minutes replying to all positive comments on this video. You seem like a joyful fella.
one of the best explanation of Functional programming
Answered a lot of questions, thanks for putting this out there!
Awesome talk, thank you a lot!
Wow, his passionate presentation style is a brease.
Thanks, that was a good refresh.
Thanks for this video. It's the best I've found so far on the fundamental concepts of FP. But after watching it, I realize there is nothing new under the sun, and it sounds a whole lot like what I learned decades ago from one of my old college profs... (1) Do as much as possible from a function of small size, and (2) Don't depend on global variables.
Lisp is one of the oldest languages still in use. Developed around 1960. Very good functional features.
Functional programming IS decades old.
Excellent point about 'refactoring' our ideas, instead of forgetting. Applicable to other areas of endeavor. Learn new concepts/conceptual frameworks and then, depending on your assessment, refactor what you already 'know', and see if it works.
Refactoring is nothing else than comment writing. If you refactor correctly, your code does exactly the same thing. For most developers the refactoring operation is the equivalent of the crew shuffling chairs on the sinking Titanic.
Excellent lecture. Easy language accessible even to juniors! Bravo!
Got really inspired.. Indeed a gem of a presentation! thanks!
A very neat explanation of functional programming. Some points helped me a lot
1. how to avoid the side effects? Ans: We cannot. You simply have to confine it and different languages handle it in different ways. Some examples are atoms, Agents/Actor model. Redux (a library to manage the states, mostly used with react) has similarly way of working, where you trigger the events and it will go through the pure functions (the state will be passed as param in each of the functions) and the response of these functions will mutate the state internally by library.
2. As functions do not have side effects, it helps a lot in handling threads.
what is missed in this talk is to highlight why people often talk about curry functions while explaining functional programming. Why it is so needed in functional programming?
It's not needed, it's very convenient, and comes easily with proper function types. ML family languages autocurry functions, but you can curry functions yourself in any language with higher order functions.
currying only allows you to use partial application in a way that is a little terser than lambdas. for example instead of:
increment x = add 1 x
you can write:
increment = add 1
or instead of:
users |> filter (\user -> isOlderThan 12 user)
you can do:
users |> filter (isOlderThan 12)
this is particularly convenient in function composition when you combine 3+ functions as partially applied functions in the middle of function composition are a lot more terse then lambdas
getYoungSurnames = toUpper . map surname . filter ((< 12) . age)
Vs
getYoungSurnames users = (toUpper . map (\u -> surname u) . filter (\u -> age u < 12)) users
One of best talk I have ever heard on Functional Programming...
very clear and helpful, thank you
Thanks for this one it is really helpfull
I use a mix of functional and OO. I think it's a mistake to follow a specific set of rules for programming (OO vs FP). Just write what makes sense, causes less problems and is cleaner code to maintain. For every style of programming, you'll still end up with problems, albeit different ones depending on the style.
that's why as a C# dev I'm learning F#. Seamless interaction between them are a blessing :)
@@Qrzychu92 The thing I love most about F# is that the best bits make it into C# soon afterwards.
@@Qrzychu92 I'm learning G#. Because, you know, one better... :D
If you're working on existing code, do whatever is needed/customary in that codebase is the way to go. But if you're starting on a new codebase, you better stick to one particular style, and also you should choose what language you use carefully. Many modern practices that are extremely prevalent provides the same set of benefits as OO (modularity vs encapsulation, etc.), so it's much more about the style of code you're accustomed to. Designing your code around OO, especially with multi-threading, may cause a new set of problems since they aren't designed to be deterministic. FP brings its own sets of benefits, especially in provability/testing, and also the ability to refactor code without needing to worry about correctness too much. However, you instantly lose these benefits if you mix OO with FP (introducing side effects into a pure FP environment). Hence, if correctness and testing are important for a project, it's much better to do pure FP than mix OO with FP.
The drawback of doing pure FP is that not many people are able to do pure FP, but that's not the fault of FP, but rather we are in a phase of transition and the educational infrastructure isn't here yet. FP is so fundamentally different from state-based imperative programming, which all non-FP styles assume means this transition will be difficult as we need to learn to think about computation and programming in a completely different light. It's kind of a dilemma. If you mix FP with non-FP, you'll end up not enjoying some of the key benefits of FP, and if you try pure FP, the learning curve is steep for programmers who are already accustomed to thinking under an imperative framework, and this gives it a reputation of being extremely difficult, so new-comers tend to not learn pure FP.
This content is really nice, I was wondering at the beginning on how annoying the implementation sounds but to end of the video it all falls together really nicely.
To me the perfect definition of side effect so far. Thanks for the talk.
BRILLIANT talk. much appreciated.
Experts explain hot, complex, wiered things in easy and clean manner , thanks for the great teck talk
Great lecture
Fantastic talk! Well done Russ. :-)
Best functional programming explanation
Him: I don't like the "pure function" name bcs it means other functions are bad
Also him: the nasty outside stateful world
You have 100% missed the point, I'm afraid. The whole point of f
I would call them "deterministic functions". If you use the same inputs, you'll always have the same output.
He said messy not nasty which is emtirely different.
Great talk! Although it didn’t sell me on the concept of functional programming.
First rule: Everything is immutable.
Second rule: because the first rule doesn’t really work, here are ways around the first rule.
It does work. It's about creating abstraction of immutability. If something behaves like it's immutable, then the fact that under the hood it's mutable is just an implementation details. Interface is immutable.
@@virzenvirzen1490 Also Prolog works. You define your Programm as a bunch of facts in predacte logic and then you formulate problems and prolog queries the solutions based on facts and logic predicates.
It's even more abstract than Functional programming, you don't control how the problems are solved , you just define the facts and predicates and how these are unifyable.
Yet you can still mutate state of the Programm by changing deleting or adding facts and predicates...every prolog programm is basically a self mutating database!
Mathematicians use Logic! Programmers should too!
Logic and unifications are way more powerfull and closer to real world problems than the "Linear Algebra 1" model of bijective, surjective and injective functions.
I don't get it either. I mean, I don't get the advantage at all. And this is not the first talk on FP I watched. I change states all the time, it's what's required. All I see is that being made more convoluted? Maybe I'm just too dumb for FP. I ain't no mathematician.
@@theral056 I guess it's ok. As in fp every problem is of the size of just one function.
But it's just bloody inefficient.
That is a beautiful presentation .. and literally too .. free of clutter .. just like Functional Programming ;)
Category theory is actually really interesting. We study it at our university, it gives you another taste of what's haskell about.
Since the 1980s I have been amazed at how programmers keep over complicating programming. He gave only scant evidence that this allows a programmer to solve bigger problems in the real world. My decades of coding experience have taught me that focusing on real world challenges is what pays dividends. Programmers often get caught on a treadmill of learning new techniques, yet they don't really get anywhere. Choosing the right problems to solve with your coding skills is far, far more important than your programming style or language. Your shiny new coding style will only impress other coders. Solving the right problem with less sexy skills will make you rich, however.
if I ve understood your comment correctly all you are saying is that being better at your specialisation is not important. To give an example all you are saying is the same as being the owner of a delivery service and here you are claiming that being a more effecient delivery service is not important since being the (or being better at) connecting service of seller to buyer can make you more money, aka being amazon or ebay instead of just a delivery service.
Going back at the programming and solving problems, there is a valid point that solving the right problems might earn you more money, but that's not where people specialise, the specialise in programming and are satisfied with being paid by people who specialise in figuring the right problems that need to be solved.
Some do both and some specialise and that's part of how we function.
Of course it is important to get better at what you do. But don’t assume your best course in life is to be only a programmer and to engage in greater specialization. You are ultimately a problem solver. Programming is your primary tool, but if that is your only tool then you put yourself at a great disadvantage. Understanding the problem domain is hugely important, even if you are not an expert in the exact problem being solved. For example, I would be reluctant to hire a programmer for a new space probe if the person had no knowledge or interest in space. I’ve worked with people like that before and they are ineffective problem solvers. Their programming solutions might strictly meet requirements, but they often don’t solve the underlying problems well.
"Solving the right problem with less sexy skills will make you rich" I pity whoever has to maintain your code from catching fire and making someone not rich
DuckieMcduck In my case my business owns and maintains all the code we have written for decades. For you to assume that “solving the right problems” means “making shitty code” is very immature and baseless. You are the prime example of the coder I would never hire. Realize that you are paid to solve problems efficiently. Beautiful code is a means to that end. But if all you see is code then you are too blind to be of much good.
@@Drone256 the possibility of fancy code being someone's passion hasn't crossed your mind, I love programming because of programming. It's not to make myself money or to be of good use honestly.
the beauty of this speech is (I fully agree with it) that functionality on software is frequently only a side effect for programmer;). For a geek the functional beauty and the right efficient algorithm is all but this cannot be eaten on breakfast and you can't pay your bills as well - so customer/client/buyer interests are also worth to focus on. Cheers! Excellent video!
Great Talk!
Good tutorial. I learned a lot quickly. Thanks.
Wow, I had no idea what functional programming is about. Now it's pretty clear to me. Good to hear all this from a practical point of view.
Thank you! Clojure superb!! ♥
I just wanted to write a comment this morning and this one really shows my style. So let's start with how when I first started writing comments I was told to forget everything I know about writing comments. But most people here know alot about them so I thought I just keep this default.
I like this video and how he talks. Another thing one needs is there more than one type of CZcams comments.. That said one can think of it like any other ordinary comments that has a design known well to subscribers as well as it is user friendly
Great explanation!
the intro to the functional programing really amazed me
nice profile picture
Great talk.
Now I feel hyped about it.
Very good, thanks!
While I enjoyed the video, and found it useful and interesting, It didn’t answer any questions I would have unless I already knew what functional programming was.
Same. I came out more confused than I was going in.
This is a great conference for someone who wants to say they learned about functional programming but don't actually want to learn; maybe someone who's being paid by the hour to learn about functional programming and nobody is going to check in on how much they learned at the end
When I went to college there was no undergrad computer science department. All the undergrad computer science courses were in the math department and if you wanted to concentrate in computer science, you graduated with a math degree. As such you had to take all of the required courses for a math degree in order to graduate.
This talk was super awesome.
I was a java geek, but now I love functional programming (I do elixir)
For me functional programming means...
Pure functions with no side effects
Immutable Data structures
Eazy multiple threading (bye-bye mutexes)
Thinking in terms of transformations
Testable small units
functional_programing(your_ideas) = awesome_products
I still dont understand why is there lots of buzz around FP! the core concepts that this gentle man has been using, are really normal abcs of any programming languages. in C++/C#, that I have extensively worked, you can have mutable or immutable data structures.
This really boils down to the programmer him/herself knowledge or desire really!
FP is really about adding additional restrictions to the programmer to protect them from themselves. You can write functional code in C++/C#, but a dedicated FP language prevents you from straying outside of FP.
@@michaelcarter577 Nail on the head! I thought I was going mad when I heard the explanation but it does seem to be a means of stopping you from hurting yourself. Unless you are mad too but that is fine because it means I am not alone :)
That was super interesting!
great talk, would love to hear more talks from this guy
awesome!
Came here to learn something about functional programming, out of curiosity. Gave up after 10 minutes, around the time he starts showing documentation from OOP languages and essentially says “Gosh, look at that snippet, doesn’t it sound hard?”. It’s getting frustrating that every video I watch on FP begins by trying to sell me on the idea that I should give up OOP because it’s inferior.
That isn't at all what he is saying. He is saying there are aspects of OOP that can make code convoluted and difficult to maintain and that functional programing has solutions to some of these issues. You don't have to choose between OOP and functional programming but rather choose where you want to use aspects of each. You take skills and practices from both OOP and FP to make your code as optimal as it can be.
Exactly my thoughts too! None of these so called gurus ever shows a real world business case solutions using their genius approach. They only work in simple academic scenarios, but fail dramatically for everyday work.
The most interesting part was the bridge. Because I mostly do the rest with my own Python code. But I always wondered how functional languages dealt with the "messy mutable outside world". Great explanation.
They don't. That's why they are so useless.
I just try to segregate mutability as much as possible. The moment the data comes in, it becomes immutable, and the only time it changes is as close to the "o" in "io" as possible.
I think people get a little dogmatic about it though. Being real strict about rules like that is mostly a practice in making use of fewer tools to keep things organized and simple, and as a benefit, keeping yourself sharp and able to think things through with fewer options. It's like yeah, a mechanic can make your car work with his expensive education and thousands of dollars worth of tools, but a redneck can do it with half a shoelace. Finding the balance between the two is key.
@@grawss A nice comment that made me hopeful that some cognitive recover could happen in Our Brave World Of Parrots.
Nice video. Confirmation as to why I never have really leaned toward FP languages.
fp takeaway: try to minimalize making side effects
loving that sprintt
I finally get it.. ALL variables are immutable.. even arrays etc.. now it makes sense
I really appreciate how he didn't sell it as a cure-all for all modern programming woes. So often I see a new paradigm pop up that sells itself as the perfect way to code every application ever, and it turns out to just have different hurdles than the ones it compares itself to. From that alone, I'll probably give functional programming a try some time.
Modern programming woes have nothing to do with applications. They all stem from server-centric architecture and that comes from the need of the application provider to steal your data. What can be done in a hundred lines of code on the device takes a million lines of code if it has to be executed reliably on a server. That is the only problem that modern software developers are facing.
If I summarized the point of functional programming, it comes down to functions not creating side-effects. But not in the way you might think. It isn't that the functions can't "do anything", it's that they will reliably and always do the SAME thing given the input. So you pass in the number 12, it will return 24 and that's it. It won't return 24 but also sometimes 30. Or return 24 but sometimes as an array and sometimes as a string.
The point is that you write a function that works one way, always returning the same output given the input. The input itself needs to be the proper format too, which is very useful for testing and during development. If your function receives an integer, then it would cause an error to pass in an array, or a string, or an object. And this can be easily tested and even caught in the linting phase.
So again, reliably return the same output for the same input, and no "side effects" beyond that. Nothing random, nothing out of scope, nothing changes based on some extra logic (on Tuesdays, only when it's raining, etc).
Of course I may have my definition completely wrong, but people seem to be confused, "how do we program without creating effects?" That's not the point, the point is your functions return the same output for the same input every time. Immutable data structures is kind of a 2nd issue for me. Understanding how functions should be written is what I focus on first. And really, functions can be written this way even in procedural and OO.
Superlatives deployed. Gratitude expressed. Curious aspiration ignited.
Thanks for this amazing talk, explains functional programming and software engineering concepts in simple terms. :clap:
Finally, a Functional Programming explanation that makes sense. Mr. Olsen is a great speaker.
Data Processing - calculations are important BUT most software is data processing software. With data processing, it is data structures that are hard work. Watch Grace Hopper, she is fun and explains the issue.
Awesome talk
I'm semi-tempted to see if I can rewrite the Arduino C++ code I wrote on Sunday in an FP style. Was a UI to adjust half a dozen parameters on a running process. Current code uses a lot of inheritance and is ?overengineered.
Nice explanation from an excellent speaker. I can really see how this paradigm can help with new designs. But tell me how efficient it's going to be to iterate through one of those fancy/cool tree style arrays.
@Dirk Knight Exactly my point. With the data structure described in the talk if you use those arrays you'll be getting tree style performance under the hood. Are you saying that these arrays should never be used for iteration?
@@paulchoudhury2573 Eh, I doubt it. common lisp is essentially as fast as C, and functional lisp is essentially nothing but recursion and arrays
Full circle. When I started programming, all we had was functional programming. I do 100% of my stuff with it. It's kind of like keeping your orange polyester turtleneck shirts in the closet....one day, you'll be at the edge of fashion again.
You mean procedural programming?
@@ccgarciab I think, maybe, the definition of "functional programming" is a little less intuitive to some of us that started programming in or before the mid 80s.
Never has Bertrand Russell, Lord Russell been referred to as one of „two British guys“.
36:00
'It solves the threads-issue'
Well, only if the state you wish to modify, fits in a single atom.......
In which case, most other tools can be made to work just as well.
Still:
The fact I could put on this talk, while doing something else and pick out this issue, this clearly: The praise this presentation gets, is without a doubt deserved.
The 'you could write stateless, in languages not built around it': still true.
The 'we don't deadlock, as we don't do collision-avoidance. We do collision-detection and rerun (the latter is only possible because we know we're completely stateless)': it is a choice, if you build around it probably more often than not a reasonable one. (keep your heavy functions away from your collision-prone ones)
The 'and if you make this choice, we'll do the handling for you': nice, nothing to add really (others 'can be made' to work just as well, but this work still needs to be done)
Banger would recommend
Great introduction to FP. Thank you very much.
Can't help but being a bit cynical about the whole enterprise though. FP is designed to avoid specific programmers pitfalls (that plagued OO for instance) but generates its own.
I'm sure I can find a youtube video about a new programming paradigm designed to correct the mistakes/limits of FP.
I think it is an illusion to believe we can solve the challenge of communicating solutions to problems (of increasing complexity) to each other by creating a new way to write them up in code.
Seems people are fighting about what is the best programming method. But in the end, it is really depends on your purpose and idea for an application.
I code using both OO and FP, I switch if what is better and more efficient for what needed/wanted. I have even mixed both with efficient enough flows.
Seems the most die hard people who likes a specific thing keeps push what they want to what other people want. (I am not saying the presenter is like this, I just heard someone from a Clojure talk just ranted why OO is better)
Yeah, no. You cannot convince me that APL code is different from elf magic.
Hi Russ! I liked the part where you show in the book by two English guys that it took 379 pages to prove 1 + 1 = 2.
Thanks! You aren't by any chance the David Seller I worked with seven lifetimes ago are you?
@@rokuruss6271 waiting for an update
Very nice talk...thx for this!!
At 36:19 - Are those wire-rim glasses? Looks like my phone's voicemail logo reminiscent of a cassette tape. Wait..handcuffs?? Oh - now it's a bicycle?!?
My problem with this is that real code is largely fixing data and error processing. Maybe if you are coding some back end thing that that reads perfect data from a queue and writes back to a queue you don't need to worry, but I have to check every value and either reject it or fix it.
Starting a new role using F# as the primary language. Pretty excited and completely terrified.
There is something oddly satisfying about listening to an older Jim Carrey explain functional programming.
I fooled around with Scala a little as I consider Java burden. Thanks for the high level abstraction.
try Clojure - it's a purely functional version of Lisp that compiles to JVM bytecode
My only problem (not with functional) but with how Java handles functional, is the syntax needed for VarArgs, they should have used something different than commas, by doing it, one could place VarArgs at the beginning of a method parameter, making it not only extremely easy to code, bu extremely easy to read and understand the data flow.
And when the video ends I still have the same question: what is a functional programming?
A paradigm based on functions that do not change output whenever the same input is entered, and do not cause any visible side effects
Have you watched the video of anjana vakil?
Great talk. My favourite quote: "I don't have to look through 25 pages of code trying to figure out if someone STUCK something in the middle of x" 19:00 :D