Functional Programming in 40 Minutes • Russ Olsen • GOTO 2018 

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.

lol under rated comment

I have adopted something pretty common called disfunctional code

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

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".

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... ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-nYBW4ExtNvo.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 ☺️

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.

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.

nice profile picture

@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.

principia isnt useful math anyway

and it's outdated anyway, so unless you are a historian don't read it

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.

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.

Lisp is one of the oldest languages still in use. Developed around 1960. Very good functional features.

Functional programming IS decades old.

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.

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.

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

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.

nice profile picture

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?

Same. I came out more confused than I was going in.

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.

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 :)

Immutable data structures are a bit of a hard sell until you've worked with heavyweight business code that utilizes them. Safe concurrency primitives on the other hand, not so much. Certain approaches like software transactional memory eliminates the need for managing locks altogether.

Well, of course. That is what he explains with his "forget everything" piece.

No. To use his example, say you want to change the letter D to the letter E in an array of alphabet letters for whatever purpose. The system will then produce a copy of the whole array with that change included as a result which you then pass to whatever function needs the modified data. Then the copies are discarded, the array is reset to its original state and you will have to request the change to be made again if you want to change D to E. I think the idea is to get rid of situations where programmers use an array of values, then change the values in their code and then later on run some code on the array expecting a result based on the original value of the array but getting the result based on the modified array. Because you can't change the array via code you won't ever have to comb through lines of code to find out where the values got changed. Is it worth switching to functional programming for? I would say mostly in cases where you just cannot afford to ever have ambiguity or errors in the data you manipulate. Like A.I systems for example. If you're just making a computer game for kids then you probably don't need to bother.

@@HurricaneSA it's like riding a bike, with enforced use of safety wheels, then? In many cases I don't care about my initial array, and over writing it as I go is just more efficient. If for some reason I need to preserve it, I can do that too and create a copy instead. I really don't get the upside at all. I've watched multiple talks. I don't understand. All I take away from FP is that it deliberately removes half your tool box and puts on a safety helmet for you. But now I get to hit nails with a screwdriver, and god forbid I ever need glue, because there's none there. Is there anything beyond the enforced self-protection I'd like to use from FP? I literally don't understand why I'd ever use it. Not trying to be condescending at all here. Maybe I'm just too dumb. But I really don't see the upside. I have access to immutables outside of FP, without jumping through hoops to use a variable.

@@theral056 Yeah, I agree that it seems rather redundant. However, I suspect the benefit in this case would be more applicable to large projects where you have multiple programmers accessing the same data via different modules simultaneously. I confess though that I'm just a C# programmer so I tend to agree that it seems rather convoluted.

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.

An array accesses to an element by addition to base index and dereferencing the location to a register (about 2-3 instructions). Let's say you have an array containing 512 GBs of int values (which is a lot actually). When you have a tree you do the above process repeatedly (we can also assume that the tree structure will perform more dereferencing and arithmetic for node access, so let's say 8 instructions). 512GB = 512 * 1024 * 1024 * 1024 bytes -> /4 (size of int) -> log32 -> round up -> 8. thus at most 64 instructions. Considering there are pipelining mechanisms implemented in modern CPUs it actually takes less than that. Now think of how many cycles it is necessary to load such array into the memory, then to write it to a disk. In most optimization requiring tasks that uses arrays (games, image processing, deep learning, ) any required fetch or update is assigned to the GPU so this case that we are currently inspecting is a bit far case. Now consider this, do you prioritize more understandable, error-prone, maintainable code or optimizations that are premature %95 of the time anyway?

indexing into an array is a O(1) op only in theory. In actual execution, indexing into an array is not even the same over time, even for the same location.

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.

fp takeaway: try to minimalize making side effects

To me the Atoms solution to multi-threaded concurrent access that is presented here is a very bad design choice. First, the function g is executed twice, which means wasted processor execution time. Second and most importantly, if function f is faster than function g and is called frequently you will have a starvation issue where the thread using f runs smoothly constantly updating the Atom while the thread using g is constantly rejected and locked in a loop retrying g. I can't see why they don't use a reliable queuing mechanism that can ensure no processor time is wasted in avoidable retries and no thread is locked in an infinite retry loop. This is multi-threading basics. The "messy outside world" needs results and it needs them in a finite predictable time. Timelessness is the main issue I have with functional programming: most often, the design completely ignores the timing aspects of the program. I see functional programming as an overkill and excessively restrictive solution to the problem of correctly identifying, implementing, and documenting the code sections that need thread safety, and/or immutability. Those issues have efficient solutions in procedural programming. Not knowing or using them properly is not an excuse for trying to completely remove mutability from the programming world. Programming is the art of creating efficient tools to solve real world problems. Programs are not autonomous flawless deities that live on their own in a timeless paradise and sometimes allow mere mortals to get a glimpse at side effects of their perfect beauty.

​@@christianbarnay2499 Clojure provides for whatever paradigm works best for you. Atoms are synchronous and Agents are asynchronous. If you want a coordinated state, use agents.