Immutability - Computerphile

today i wanted to talk about a property of functional programming called immutability and how immutability helps affect concurrency models and you know the advantages and disadvantages of having immutable states you know so they should be used in some areas and not used in others if you remember when you were back in school they used to go in and teach you the equations say y is equal to x squared minus 1. you did your calculation and then you figured out what y was and that worked fine until they started teaching you to program all of a sudden when they were teaching you to program what you got was x is equal to x squared minus one and all of a sudden they introduced mutability into the whole equation where you had values but then you went in and changed the values this started causing kind of confusion and because it's wrong it kind of defies the laws of mathematics this is wrong you know it shouldn't be that way even when you program you should have you know y is equal to x squared minus one and this is an example of an immutable state so mutability that's the idea of something can change right so x is something and then it can become something else that is correct so uh mutability what you do is uh you change some parts of it and you retain some common bits so you know that's mutability you you basically the value changes or some parts of that value change immutability basically you share what you can and copy what you can't that's a way of seeing it let's look at how immutability and mutability affect your concurrency models concurrently programming is when you have processes as your main building block of your system and concurrence itself you know what you do is you they don't have to run at the same time but you model it that way so they could inferiorly be running at the same time and it's an easier way to reason and an easier way to code and program and and this goes in contrast to parallelism where you actually have processes which are running at the same time so see it as a subset you know cc concurrency as a subset of parallelism so there are two ways of you know doing concurrency one is based on mutable state where we've got processes and processes usually threads when it comes to mutable state will go in and share memory so that means any thread you know which has access to the shared memory can go in and edit it and this is where you program with locks you program with semaphores and the likes then you've got notion memory so you've got concurrency models with immutable state and in those cases you've got processes and processes do not share memory but they communicate with each other through message passing so they communicate with each other by copying the data from one process to the other and so now they'll each have their own copy and you know they're able to do whatever they want with it so you know the only entity the only item which is allowed to mutate the process state is the process itself if we're dealing with a mutable state um you've got a thread or a process running in a critical section so basically writing to the shared memory what happens if something goes wrong so what happens if the process terminates what you need to do is you need to go and terminate all of the threads which have access to the shared memory because you do not know you know what state the process which terminated left the shared memory in and it could you know potentially be corrupt so you basically lose everything in there in a mutable state what happens if a process you know state gets corrupted or crashes or something goes wrong with it is that you just lose the state of that particular process which was corrupt in the first place all other processes are not affected by it because they'll have their own copy of the data hopefully not corrupted and you know continue executing so it's a way of isolating failure your second problem with mutable state is you know where do you locate your data you've got shared memory where do you locate it so you've got a process running in nottingham and you've got one process running in london and they need to share memory where you place your shared memory it becomes a bit hard versus immutable state where you've got nottingham and you've got london you don't share memory you copy the state so they'll each have their own copy of the data and you can execute yeah without so so so you you're avoiding problems of locality here assume you figure out with your mutable state between nottingham and london you'll place your shared memory in leicester what happens all of a sudden when the network goes down between them you know because here in the middle you've got your shared data all of a sudden you can't accept it and there's one thing you need to be aware when you're programming in life there are three certainties one is taxes death and network partitions so you can be sure that you know if you've got a network something will go wrong with it versus immutable state you've got a copy nottingham you've got a copy in london so even if the network goes down they'll each have their own copy of the data to continue running and what you need to do is when the network does come back up you will have to go in and synchronize the data again and there are many tools distributed databases and techniques to do that it's very clear that if you're dealing with mutable state the mutability will work but it will work only if you're running your threads on a single machine so without a network and assuming nothing goes wrong and there are many many use cases where you need that approach especially those use cases where copying memory is not efficient you know where your computations have been extremely fast so it's not a question of you know one or the other it's a question very much of using the right tool for the job and yeah it's not always mutable state and it's not always a mutable state you know these these are the science decisions you need to make when you go along there's some examples of where you might choose a mutable state most likely i mean you would use a mutable state where say in the finance space where you're doing algorithmic trading computation time is critical and complex as well where if something crashes and go wrong you just don't do the trade but if you do get your results you know you need to be fast and you you know get you know execute that trade as quickly as possible so as as an example or your rendering of graphics for example or you know where you might want to split it up but uh you know do do as much as you want as much as possible in parallel so it's time critical basically time critical applications absolutely which can run on a single machine and don't need to be distributed so let's step back a second uh you know i've been using the terms mutable state and immutable state you probably recognize them with the no shared memory approach versus the shared memory approach and i think a very common shared memory approach is for for example java which is fred's and the threads will go in and share the memory and what i'm seeing happening a lot out there though is applying uh techniques from immutable state to processes and threads with mutable state so what happens is that you you only allow the thread you know which owns the data to go in and mutate it and yeah and that resolves and addresses a lot of the issues you know we've discussed now so you know it's again you're very much the right tool for the job so if you look at modern architectures today i mean everything from embedded devices to super computers they are based on you know heterogeneous multi-core architectures and most of them are you know by nature distributed so you know i think you know what we've been looking at today is basically the future of programming uh you know future programming languages will be concurrent they have to be concurrent and they'll have a concurrency model based on immutable state so you know immutable state you know being uh one of the properties they've inherited from functional programming languages you might not be using functional programming languages on a day-to-day basis but using you know the paradigms and the principles and adopting them with your main mainstream technologies will make you much better programmer and they'll make you much more efficient and productive earlier on we mentioned though that immutability there was a speed penalty right so how do we address that so with immutability indeed you have a speed penalty but you know the speed penalty becomes even more serious when you start looking at amdahl's law um every one and a half years until the mid-2000s uh chips were getting you know becoming twice as fast uh then amdahl's law you know because of ambassador they've hit the limit and now you need to deal you know you gain speed through multi-core and with multi-core programming you need a different approach and what you do is you start parallelizing your computations so you know desktops will very soon have 64 cores you know we'll be seeing uh machines with a million cores within their lifetimes you know you start utilizing instead of you're making one a single threaded program which runs extremely fast you now start parallelizing your programs and so you start breaking up your computations into many smaller computations and this you know the only way to do that is uh concurrency rented programming with uh immutable states with a concurrency model based on immutable state uh yeah that you you seem to have uh yeah you've seen scenes have been hung by your own what was it called busted yes

Channel: Computerphile

Views: 96,875

Keywords: computers, computerphile, computer, science, Erlang, Erlang Solutions, Francesco Cesarini, University of Nottingham, Functional Programming, FP, Mutable, Immutable

Id: 8Sf6ToPNiA4

Length: 10min 5sec (605 seconds)

Published: Wed Dec 04 2019