Procedural Programming: It's Back? It Never Went Away

what's good to start with a black screen now sometimes there is a question they've really hadn't got the lights here so I'm going to be mostly in darkness like the screen sometimes there's a question of what are my talks about it's not always obvious from the title today I chose something different it's blindingly obvious what this is about it's about procedural programming the curious thing is why am I talking about procedural programming surely it's it's gone it's dead and we should be talking about functional programming and and next generational object-oriented programming and so on because it's dead well I'm here to tell you that it's not I'm also here to tell you that it's playing an important role in a number of other paradigms and that we actually lost out an awful lot of stuff there's a lot of stuff in classic procedural programming and it's organizing model primarily structured programming that people think they know but they don't actually know okay so I want to explore that as we go through and things about me I edited this book a few years ago because I'm very much interested in code but I'm also interested in a way that people do things and the way that architectures emerge and the experience is in fact almost to the point of this talk there is this idea that patterns to quote Brian foot a blatant disregard for originality okay the whole idea is that we know stuff we know stuff already we're just not very good at remembering that we know stuff or looking around our own history to discover that most of the things that we talk about have actually been solved it's not that we all knew everything all of the time as it turns out in the heart of procedural we actually find an awful lot of stuff that people are getting very excited by these days and dates back quite away so procedural when we normally think of procedural we normally think old stuff big slabs monolithic this is a photograph I took earlier this year because my wife and I are clearly very romantic this was taken on Valentine's Day we grab the kids it's just that what should we do it's Valentine's Day let's get kind of romantic yeah let's take the kids to go and see Stonehenge they were quite impressed they'd seen photographs of it and you know they were both quite actually there are a lot bigger than we expected that you know even once you've seen the photographs now as with any presentation I'm going to have to leave some stuff out because there's a huge wealth or what I could be talking about and there is an art to leaving stuff out you may wonder where are all the tourists if you've ever has anybody actually been to Stonehenge okay where are all the tourists they're all the way over there that's the art of taking a good photograph you show the bleakness of Salisbury Plain but when people look at this stuff what do they see they see monoliths monolith oz the Greek for one stone one big stone this is what you see when you go into legacy code you see these large difficult to move stones and you theorize how was it that ancient primitive people were able to put together this code base okay how did they do this how did you get so many people to organize these monoliths and everybody these days it's like oh no I'm good we've reorganized the stones you know hey we've got microservices yeah we're good yeah let me show you microservice architecture this is what's actually happening none of this stuff is new I mean everybody's trying the same things all of the time Doug McIlroy in the 1970s writing about the UNIX philosophy captured an essence that we are trying to recapture with every passing paradigm and which started in the 1960s the UNIX philosophy write programs that do one thing and do it well write programs to work together there's two parts to it people normally remember one part yeah yeah oh I've got something doing one thing well it doesn't seem to fit with anything else let's just add some code to it that is the decay that you saw okay it has been said that every program starts rococo and then becomes rubble there's two parts to this and this is something we're gonna revisit later there is a kind of mirror here but I want to take you back to the 1960s I just referred to the 1960s there's a lot of glorious stuff that happened in the 1960s 1960s was a time of change and we think it's the time of change but there are some things in the 1960s that are still with us okay some things just don't change I've got the wrong stones they are against the odds still with us okay we have the fear of nuclear holocaust I thought that was done but no it's back it's a revival movement the idea I grew up during the Cold War and it's just like I was glad to see the back of that you know this whole imminent fear of this stuff I'm now teaching it to my kids so something I feel I can pass on and what else to the 1960s bring that we also still have me that's me okay yeah if you doubt the ear I just look at the clothes right so the 1960s what else happened in the 1960s software engineering happened in the 1960s the classic NATO conference in garmisch in 1968 now a lot of people think that this meeting was where the term software engineering was coined well clearly it wasn't because they put it you know he was already called this by the time people got there 1968 this was actually coined the term software engineer who's coined by Margaret Hamilton who wrote the who led the team that wrote the Apollo guidance software so this is all happening in the nineteen mid 1960s she wrote this and she coined the term software engineering she felt that the people that did the software we're getting looked down upon and they used a number of different language the key language they used was language called Mack the MIT algebraic compiler and it was hand compiled if you're wondering what's hand compiled mean it is exactly as it sounds human beings looking at the code because that's the only way you can trust that you're gonna get the right stuff you can't trust automation yeah we have moved on a bit since then but people would kind of take the code and turn it into and turn it into assembler and then you have people cross-checking it so that level that hasn't changed we've got into this idea that maybe you check somebody else's work so she was responsible for this 1968 was a great year because 2001 a Space Odyssey came out one of my favorite films and it anticipated the moon landings it's it was it was quite ahead of the curve now the key thing here is I want to observe is the use of typeface this is guild songs which is a beautiful typeface and very very strongly influenced he was developed within a year 1928 1927 was Futura I used to think this was guild songs but I did a quick check the Gees are different and it's logical future this is in Germany future as a German font Gil songs is a British film so the typography of the 1960s is glorious and beautiful and it's not something we should throw away there's also some wisdom in here I'm not going to say that we knew everything back in the 1960s but it turns out that more people had the right idea than we give them credit for when people think software engineering and they think this conference they think oh it's just about - it's it's all about procedural programming formal proofs and waterfowl development process Andy Kinsler the design process is an iterative one okay it's not the only point in the document that says this and so I find absolutely fascinating clearly something happened after the 1960s some people blame disco some people blame flares I don't know kids they also had great sense of humor and a great insight to go with this sense of humor there are two classes of system designers the first if given five problems will solve them one at a time the second will come back and announce that these are the real problems these are not the problems you're looking for and will eventually propose a solution to the single problem which underlies the original five this is the system type who is great during the initial stage of a design project however you better get rid of him after the first six months if you want to get a working system we also see other points here Alan Perlis the first recipient of the cheering award a software system can best be designed if the testing is interlaced with the designing instead of being used after the design now I'm gonna put some code in because we're talking 1968 here and before okay let's let's get a little bit retro one of the languages that came out around then Algol 68 was a it was a fantastic effort in terms of language design it was very much ahead of its time people said they couldn't implement it was not possible to implement it it was too big and it was too complex I've looked through the language spec it is currently smaller than the language spec for C in fact pretty much any language you care to name that you are using is larger than this okay so our sense of what is large and complex has changed but it introduced of a really important principle into the mainstream concept language design and orthogonality the idea to compose different features that everything is in some way regular it had some rather nice interesting ideas so I'm going to calculate a leap year here you could put space spaces we're not significant you know identifier so is leave here that's quite cute and we also find if you've ever wondered where the int keyword came from it was our loss sixty-eight bull ultimately our loss sixty-eight skip is basically pass in in Python but obviously we're gonna start off with a default false now I'm going to do this in a kind of a test first style because I was fascinated I wonder if I can create a simple table driven approach to just testing the leap year logic using Algol 68 it's absolutely trivial it's lovely so I got to create a proposition here leap year spec years not divisible by four not leap years and they notice what I'm doing here is I'm passing what we call a closure these days but was simply an anonymous procedure it returns void oh yes if you want to wear void came from Algol 68 in other words if you are using a program language today there is a 90% chance that you are using features that originally came from our lore 68 but I've never heard of Algol 68 you say that's great like you never heard of your great-grandfather it turns out that you still have the genetic material as do modern languages a certain art is leap year in 1967 okay so what does that look like Oh structure came from there as well so what we've got is mode it didn't like the word type so they use mode of access proposition is a name and a void returning procedure that takes no arguments so this is basically the way at the end of the 60s and then also with the Algol 68 report in 74 that was refined to allow people to actually implement it properly was the idea of this is how you do procedural programming this is the essence of procedure program it is the procedure you should be able to take procedures and pass them around okay that is fundamental to procedural programming a lot of people got very excited about higher order functions and first-class objects recently it's kind of sweet if they knew their history they might not be quite so excited so so now I can go ahead and I can do this and I can run a test against it let's test the leap here spec turns out the test function is here anything I want to point out all those of you who are using bourne shell and it's derivatives like bash if you've ever wondered about do and alt yet they come from here didn't have dot notation they used off instead but they did use square brackets for a rave then we think anything else there right so let's build this one up so here's an interesting one the whole of the body of my procedure is actually an expression I don't need to put a return in fact there is no returning Algol will discover why in a moment and I can just build this one up okay assertion at a time and it's all quite readable this all makes kind of sense equals does mean equals rather than equals equals so yeah this is quite cute this is actually surprisingly easy to write now there's a couple of other things that we can do here maybe I want to use more make this more data-driven rather than just passing in blocks of code to run I could make it more data-driven so perhaps I want to write something like this years not visible by four not leap years so with 20 17 2001 1967 and one expect false and you see this is quite nice slight change there and think types resizable arrays one thing our loss sixty-eight fortunately did not pass onto most languages is that it is one counting you can't your erase from one I'm sure this makes Americans feel very comfortable because they think that the ground floor is the first floor whereas everybody else knows that's not by one error you count from the ground floor zero one above ground two above ground three above ground this makes us very interesting international conversations sometimes I'll meet you on the first floor yeah yeah I'd never made a mistake with that one okay so this the test driver for this is a little more involved I'm not going to go through it in detail but I want to draw your attention to some of those radical features that people have thought of more recent not the fact that there's a statement there but the fact that there's declarations after statements the idea is that a declaration is his a movable thing this is ultimately made its way into C++ for which one of its progenitors was indeed Algol 68 biana was very strongly influenced by it what else can you say yeah you can declare anywhere including an if statement I've noticed some go programmers got very excited about this 1960s innovation recently basically go was invented in the 1970s every feature that go if you think go is a modern minimal language it was invented the 1970s it just took three decades for somebody to actually put a syntax to it go is effectively a procedural language we find that it is not particularly object-oriented it's not particularly functional it might use the word func but that's the influence of the 1970s it's more a case that it's more a case that it is a classically procedural language in the Algol 68 tradition including its concurrency model we'll come back to that a little bit later what else can we put it oh yes you've ever wonder where the compound assignment comes from it comes from Algol 68 although we obviously dropped the colon after awhile in line with the the equals four assignment and this whole point is that statements and expressions are interchangeable there is no concept of difference here so I can easily have an expression that is conditional that contains loops there's also a shorthand which is actually curiously enough probably slightly more elegant than the Elvis operator that we find in sea influenced languages although I still quite like the fact that we can use if and else to make it more explicit so there's a lot of stuff going on here which i think is absolutely fascinating a lot of people don't realize this is how procedural programming was supposed to evolve I'm not gonna make it claim by the way that this is when test-first development was developed that was that was the 1970s okay you know you ought to get your decades in order here that was the 1970s and the development of all a hoe Weinberger and Kernighan were the three people responsible for that we instituted a rigorous regression test for all the features walk any of the three of us who put in a new feature into the language first had to write a test for the new feature but what I am trying to make a point about here is that as in common with many ideas that become popular There is obviously an original vision that a few people share it is crystal clear it is obvious it is normally complete and fully formed we see this with microservices we see this with agile we've seen this with object orientation we're seeing the functional programming and yes also for procedural programming as well as I want to make the case here I've talked about other paradigms and I thought it's time to give procedural programming a little bit of love and to shine the light on it let's talk about testing a bit more because we can actually see a few other things here going back to the 1960s Alan Perlis also said there's no such question as testing things after the fact with simulation models but that in effect the testing and the replacement of simulations with modules that a deeper and more detail goes on with the simulation model controlling as it were the place and order in which these things aren't done if you're struggling to pass that let me just replace that with mock objects which were invented by archway tube station in London in 1999 or in 1968 at a meeting obviously they did not have the the detail or the insight to elaborate the details but the the germ of the idea was already there this idea of Perpetual elaboration I'm gonna dummy something and then elaborate it but also there's something here we're gonna talk about mock objects then perhaps we should talk about objects it turns out the psychotherapist so that here's a lot of objects psychotherapists are utterly obsessed with objects actually they're asked to be obsessed who's my experience but what I want to refer to here is we got objects we've got a stack Oh everybody loves a good stack so let's put a good stack up here the word similar simulation came into that previous thing here we go this is similar 67 code and obviously the clue to the languages age is in its number so it's 50 this year and we find a number of things here I haven't put any virtual procedures in here but virtual comes from similar this comes from similar if you're using any of those languages that use these keywords this is where it all comes from and so I've got a very simple snack here and you know we can see all the basic bits and pieces are already in place but where did Simula get its ideas from similar 67 was an extension of Algol 60 it was described by many as an improvement on many of his successes okay there are ideas in there that we can still mine but there's something in the heart of similar that goes right back to procedural thinking now this is the 1960s so what are we got we've got procedural thinking that's where that's assumed where a lot of people are still programming assembler people are not necessarily taking the Algol path because Algol was primarily European initiative but Fortran for which John Backus why he didn't exactly later apologize but you know he came up with good stuff later in his life and COBOL were driven by large companies in this case IBM and naturally grabbed the mind share but there were ideas around and not everything that was around was necessarily going to become popular at that point we see also this is the era of early Lisp the list manual was the early 60s although the languages effectively invented in the late 50s I think it's one of the best written examples of how to introduce a language because they introduced it with the implementation I thought it was absolutely brilliant because you couldn't port stuff you know there's no concept of open source or anything like that so we're going to tell you how to build a list machine whilst we teach you Lisp and it's very cool so there's a lot of stuff know so this is the 1960s what do we got we've got procedural programming we've got object-oriented programming we got functional programming yeah things have really changed in the last 50 years haven't they a slight where we've moved all this way and we are exactly back where we started well not exactly we have a better understanding we've tried stuff out but basically everything that we now do or the majority of what we now have do was already in play in some form so I mentioned earlier on that there was a kind of idea procedural programming when we think about it we think about its organizing principle this is the language of structured programming structured programming kind of kicked off in the late 60s and dominated people's thinking for their own discussions in the 1970s this is my copy of I collect old books in case you're wondering and I like photographing them as well they're a lot easier to photograph than people so this is my copy of structure program early Johann Dahl let's go Dijkstra and Tony Hall Dahl was one of the co-inventors of simular 67 and people think they understand what structured programming is but this is a collection of essays from the 1960s and early 70s when you dig into it there's some really interesting stuff some of it is a little dated some of it is still ahead of its time and some of it is oh that's where this idea came from and people often think however when they talk about structured programming they have a simplified view the structured programming is not just all about the go-to yeah this is the classic problem when an idea becomes popular it becomes simplified in some we're guns diluted every we said this whole paradigm is about that yeah I've had conversations with people about objects and they're there they're going like yeah but where's the manager object it's like no really it's not about that yeah in fact it's almost exactly not about that yeah so we end up you see it and by the way in the heart of go to there's okay that's just a coincidence actually there's a little bit more to this we'll come back to that so the thing is when people think about go to they start thinking of Dijkstra the classic letter comes the ACM once again 1968 go-to statement considered harmful and people this is the launch of what is known well this is a kind of standard phrase isn't it something considered harmful these days if you want to do anything and you want to draw attention to itself you use its standard clickbait it's just like X considered harmful okay it's just like yeah I'm gonna write a blog you know how do I write a blog introduction to something or other that's really but yeah it's really boring okay let me reframe that as something considered harmful let's find a risk yeah that suddenly you get all the you your webpage you're getting the hits now fantastic okay this is effectively what is known there was actually term for this now one of the things that one things that I do is I have a page on Facebook called word Friday where I share an unusual word every Friday and the rest of the week is linguistics and words and other stuff of interest one of the words that I came across a few years ago and put a definition up for was a snow clone so this is quite a useful word a snow clone a cliched wording used as a template typically originating in a single quote such as X considered harmful these aren't the X's you're looking for X is the new Y it's X but not as we know it next left behind is X is all the way down all your X are belong to us these are examples of snow clothes okay so we might say okay go to statement consider harmful BIOS code extra he launched a snow clone actually he didn't this is the original that he sent a case against the go-to statement it's much more modest it's much simpler it's I'm offering you something here it turns out that the editor of communications of the ACM for that issue was Nicolas birth the inventor of scale and what what birth did is he decided well these days we call it clickbait he changed it you know it's just that a case against they got no I need something snappier I need something that's going to get the hits you know people are opening up their cons of the ACM and they going to look down the pit go to state and considered harmful excellent and change that so I want to take this a little bit beyond this but as an idea this whole go to thing it still resonates this is the talent guide to design programs in 1995 they pull no punches a go to completely invalidates the high-level structure of the code there's no kind of doubt about what they think here what are they saying here a lot of people have never had the experience of working with go-to written code okay maybe if you've done some assembler you've can counter dit or maybe you've come across and fairly treacherous old see my experience was that I this is my confession to you once upon a time I programmed Fortran and all of these discussions were currents then and the use of go-to and all the rest of it and yeah goto doesn't have to be spelt go to go to can be spelt in a number of different ways when we talk about the idea of the discipline of structured programming the discipline of structured programming is the idea of a single entry into a block and a single normal exit you may exit via abnormal means but a single normal exit and people often less you talk about the multiple exit thing but they never understand what does multiple entry look like it looks like this this is known as Duff's device it is a device it is an approach to unrolling a loop it is used it was used in the early 80s I believe in some telecoms code at AT&T it is astonishing and scary I remember the first time I saw this is you know this was a real WTF moment it was just that you can do this if you want to do this in Java you can't the the language designers decided no c-sharp no you can't do this there in fact C is pretty much the only place you can do that Tom Duff captured his feelings I feel a combination of Pride and revulsion at this discovery the ability to jump into the middle of a block so actually what we've got if you've ever wondered so let's let's go back to the 1960s 1960s was was when Star Trek was first aired and Star Trek introduced to the the public the idea of teleport and always that question what happens when you teleport into something in the same place well this is what happens when you teleport a dowhile loop into a switch statements they merge in the same place ok and it's it's a horrible ghastly thing that is both revolting and elegant and probably worthy as tom duff says many people have said that the worst feature see is that switches don't break automatically before each case label of this Co forms some sort of argument in that debate but I'm not sure whether it's for or against now the point with this stuff is there's an idea when we talk about the organisation of procedural programming as a discipline of thinking as discipline of programming there is an idea here that what is a block what is a what is a statement the idea that I can substitute one thing for another is a very profound idea and it is about this ID this idea of single entry single exit is part of it so I've got a render this I'm gonna bring this one up this is I think the only piece of 21st century language we're going to actually include so this is groovy this is the leap year thing that I showed earlier on but done done in groovy now one of the things that groovy allows you to do is is say ok that last the last statement in the block doesn't actually have to have an explicit return we can basically say that the block comes to equal that last term so I can easily do that gets me they Algol 68 code that I had earlier but some people are not comfortable with this logic they'd like to see the if spelt out they don't like the hands and ORS so they need to go about it and they do this there's another way of doing it that also does ifs and returns and it looks like this one of these is structured and one of these is not one of these is elegant and one of these is popular this is the most popular one I find myself always dealing with people as out yeah yeah but eclipsed maybe do it and stuff like that and the point is that the there is a there is a qualitative difference these will actually generate the same underlying code you actually there's no this is not a question of what you're generating in terms of the code it's a jet it's to do with the model of reasoning that we bring to it and that's the different thing if we look here if I try and do the replacement I can only do it in one place for this one over here over there every branch there's a tail return every branch exclusively ends as the result of the function okay there is an exclusive path through this and it is simple in fact I'm gonna put the return back in there because that just makes it look uncomfortably irregular if we want to understand block structure and what people were actually trying to talk about it turns out that what they were talking about was the alignment of control flow and data flow now if you frame it like that you get a lot more people on board because they Collier yarn totally about the functional and that it's about the alignment of the control flow and the data flow but they didn't articulate it like that because that language or model of reasoning did not yet exist but the block idea is really important people often assume when these days which I hope we all indent our code I say I hope because I don't make that assumption I find a lot of self-taught programmers that don't use ideas do not indent their code and regard that as some personal point of style you know oh that's just the way I do it that's my style this notes unreadable and I mentioned for train earlier on I I worked on my boss's code he didn't believe in such nonsense as you know indentation you know there's an affectation as far as he was concerned when I indented his code the number of bugs I found was astonishing and frightening but let's get back to this let's understand the nature of block structure is the idea of folding concepts away it's about folding complexity it is the idea that I can take I'm gonna just fold away all of the second-level stuff I'm going to focus on the first verbal stuff so can I reason about this function and this function without on standing the content of each branch and the answer is now in one case and yes in the other on the right hand side I have something that is visually honest it says this is a function that is a four-way decision and does it look like it absolutely okay mutually exclusive parts on the left hand side I've got surprise as a mystery obviously not in a piece of code this long I'm gonna say this is a non-challenging piece of code almost anywhere you write it but it's when it gets larger that we struggle the point here is that what is going on on the left-hand side if I on the left-hand side this is either will get a return false but we've got a bunch of guard statements to check for bad cases these are not bad cases this is the definition of a leap year it's perfectly good these are not exception these are not guard clauses there's some misuse of the guard Clause idea or it's we're going to return false but we've got three optional pieces of pre-processing to do is that what we know the point here is you cannot tell unless you go into the next level the idea of a block and procedural programming is to encapsulate a bunch of stuff so you don't need to know what it does I don't need to know that there are returns in there continues in there in fact I can put anything I like in that and it won't change on this side that is the basic idea they were stroke that is what we mean by this stuff so we put the stuff back and turns out that this is this is the one that we want to focus on that's what we mean by structured programming and as they observe one of the most powerful mechanisms for program structuring is the block and procedure concept now this it turns out is where a lot of ideas stem from there's this simple idea that when we are organizing you've got messy procedural and tidy procedural the structured view was to compose any logic to describe what it is that you need to do all you need is sequence so sequential composition I have one thing and then another I need to be able to make a decision I need to select between alternatives and I need iteration if you place it eration with named abstraction you can get rid of iteration and have recursion but the idea here is the let us not assume that that is available to us secret selection iteration and this was proven to be basically all you needed and what you did is you organized your codebase according to this then over a series of procedures now if we look at a characterization of this is an architecture in in Basque clams and Casman software architecture and practice they refer to this style as main program and subroutine I've never met a programmer who has referred to this style as main program and subroutine I think sometimes I think it's a really good characterization that they describe but sometimes people struggle for names what do we call this procedural approach we could call it procedural no no no that's too obvious let's describe it by what it's know at some point we're going to have lunch oh okay does that mean first course second course and dessert no no we don't describe like that we call it lunch okay so there is a notion here that there's also the fact that people didn't think of this as a programming style because everybody was doing it this was the main stream of programming yeah if everybody's doing it you don't have a name for the style you know what what's the deal what's your programming style its programming style it's the way we program but what does have a name yes it's called programming you know what are you talking about yeah if you went to most mainstream programmers back in 70s and 80s there was no concept of alternatives here okay regardless of the naming we understand it's accurate if a little long-winded they characterize this architectural style the goal is to decompose a program into smaller pieces to help achieve modify ability yeah I'm not aware of any architectural style it doesn't have this as its mandate so this is kind of noise you know you don't get people saying we can't with a new paradigm the idea here is to cause problems for maintainability or to not allow you to decompose that's not how people do at work okay so that's a noise statement this is more meaningful this is the vision so I'm not going to say that procedural programming is what you want to do everywhere but if your problem looks like this then this is the way to start think about it the idea is that we have many paradigms because problems have many shapes a problem is decomposed hierarchically each paradigm that you encounter has a philosophy it says here is a truth that we hold for this kind of thing and this is what we're going to do we're going to decompose things hierarchically okay there you go main program subroutine that's what we're gonna do we're gonna p8 a tree of control a tree of decomposition top-down programming stepwise refinement these are all terms about how we organize this we have an objective that the code wants to achieve you can see this doesn't necessarily work for event-driven code great we've already discovered now a style that it doesn't work for but if you have an objective and you can decompose it algorithmically is quite a good one then you've got this and it goes deeper than this the structured programming school they actually there was actually a way of characterizing these things it wasn't just about throws subroutines together people came up with wonderful names for stuff there's a whole vocabulary for this this is the afferent branch the transform branch the efferent branch let me read that these are good these are good terms to throw into a conversation if you want to confuse your colleagues you know if you want to kind of you know sister oh yeah but I was looking down the the efferent branch of the code I think he means output input process output okay well we've never seen that before yeah but that's too obvious again we have to come up with names that confuse people you can't call out the input the process and the output branch because then the people know what you're talking about so what we're gonna have is the afferent transform and efferent brush yeah we're gonna raise it a bit yeah make it sound more computer science see now obviously we don't always call it you know so we see this philosophically and then we see further characterization here this tells us a little bit more about what is it that makes procedural procedural there's typically a single thread of control that will come back to haunt us and each component in the hierarchy gets this control so it's the passing of control and in the structure world we view that with respect to selection at sequence selection and iteration the passing of control optionally along with some data from its parent and passes it along to its children we have a strict stacked to plan for how control and data flow to and fro throughout the codebase through this hierarchical decomposition yes a so subroutine perhaps we don't use that term anymore as much maybe we call it procedure maybe we call it function mmm curious if I took away mutable state from procedural what would I be left with what's it called functional programming yeah if you take away the mutable state and you still have you can still pass procedures around you have higher-order procedures and now let's recall them higher-order functions and so on that's the thought ah this was all there oh that's interesting what I find interesting what validates or strengthens the paradigm is when you can arrive at its conclusions from multiple paths it's not just one way of thinking it's like you can reach a functional view of the world as you can reach an object view of the world by taking many different roads and it's just that same conclusion that validates it in that sense now of course this beauty of this hierarchy is that of course it doesn't look like this in real programs you end up with mixing of levels okay you end up with fan-in and fan-out fan-in what would we call that we call that reuse okay here's the thing I've used it in more than one place okay fan-out that's classic decomposition or approach and also we get recursion direct recursion and mutual recursion so yeah this the trees looking a bit messy and this does also tell us that there is a limitation sometimes to how we think about things as Tony Hoare observed you cannot teach beginners top-down programming because they don't know which end is up and I think that is wonderful because the idea is when I'm trying to establish what is the objective and goal of this program you know what that is non-trivial we've created whole methodologies to try and answer that question what do we mean by this / let's also have this wonderful observations everything should be built top-down except the first time I think it's a lovely way of putting it it turns out the top-down is a great way of describing something it's entirely reasonable you can actually show somebody in decompose an idea top but that may not be the same as the story that was used to create it yeah but it's a great way of describing it because people go hell yeah yeah yeah yeah why did they take so long to develop it's so obvious now they said it that's how you know you've got something really good top down is a great description model so this presents us with a bit of a challenge how shall we organize our procedures into the breech steps David Parnas 1972 what else happened in 1972 Apollo 18 never left the launch pad there was no Apollo 18 Apollo 17 was the last one and and so that's the end of the moon landing story but the beginning of modularity yeah right we proposed that one begins with a list of difficult design decisions or design decisions which are likely to change now here's an interesting question how do you know this one hasn't changed okay this is 1972 45 years ago how do you know that something is a difficult design decision well I don't know we keep spending hours discussing it there you go we can't agree on something there you go yeah the fact that you cannot agree with your colleagues about something is a really strong big arrow saying we're not sure about this it is not an opportunity for you to beat your colleague or come up with the killer answer is an opportunity to step back and go that's interesting maybe the answer is not so obvious maybe there are multiple ways maybe the way that we describe it now is good in one way but in six months the world moves on the frameworks moves on the performance requirements move on and we have to change somewhere else so let's structure our code according to this level of indecision each module is then designed designed to hide such a decision from the others and that is a kind of a classic way of thinking this was the overlay on two classic procedural programming this idea of modules and modular programming sort of came along again it did not get adopted into the mainstream as readily or as comfortable as people would have hoped and indeed the mainstay of programming in the 70s something like Fortran did eventually get modules but it wasn't until the 1990s that it did so it was never one to hurry things but one of the most common decisions that we can make concerns data structuring Barbara Liskov recipient of the cheering award in 2009 she was one of the key individuals this is 1974 key individuals and really motivating a style of programming organized around data types but not simply structured data but abstract data abstract data types defines a class of abstract objects which is completely characterized by the operations available on those objects a programmer is concerned only with the behavior which that objects exhibits but not with any details of how the behavior is achieved by means of the implementation implementation like yep there we go 1974 again what happened in 1974 the outlaw 68 report was finished again people weren't doing much interesting stuff in space on the other side of the Atlantic but the Soviet Union was doing some very interesting stuff and there's a whole lot of stuff that was going on in code this was really quite exciting now what else happened the 1970s see happened in the 1970s so it turns out you can actually mix this approach in with C so let's go back to our stack of books I'll just have it as a snack of strings let's update this to ANSI C and what I've got here is a forward declaration of a thing called a stack okay and a regularization of the name and how is that going to look well we're going to create a stack and we're going to be able to delete a stack okay notice there's no detail of what a stack looks like the idea is that I've simply said let's talk about how you work with the stack don't worry about the details this isn't a header file and here are the common operations there's going to be a stack of strings so const char star I'm going to push I'm going to pop it's a pure pop I'm not returning anything from that depth I can query that and I can also find out the top element and we're also going to allow people to link this in to and and compile this into their C++ code so we put a bit of noise in okay so what is the implementation look like I'm not going to focus on the implementation I just want to show you what it looks like there we go so here's an implementation very simple implementation of that protocol but I can also change the implementation that's implemented in C what flavor of C that is definitely C 89 it's the 89 90 depending on how you want to count yeah it's not it's not later and this is C++ so I've got exactly the same I've got exactly the same interface it passes exactly the same tests but I've not only have I got a slightly different implementation I've ended up using a different language that is what was meant by abstract data types it's that abstract you can change the language but you're still focusing on something that is how do I do this however there is a small difference between these pieces of code and it is to do with memory ownership and this is a struggle and a lot of people think okay procedural programming that means you're always going to manage your own memory these two are different the C version leaves the question of memory management's slightly open the C++ version encapsulate sit so I've talked about the 1960s I talked about 70s and Beyond I want to go back a little bit further okay Shakespeare was one of the first programmers that I know of in England and he had a bit of a problem there weren't any computers it makes it really difficult to program things when there are no computers and the Elizabeth near the the late 16th and early 17th century there was a lack of computers however Shakespeare was a big fan of the actor theory so he used actors to do this again centuries ahead of the centuries ahead of time but he had to encode his concepts and his models of programming carefully into his place and when you review his plays with this in mind you end up with a completely different world view so for example and Hamlet the tragedy of Hamlet Prince of Denmark is actually a play about memory management we can see it from one of its most famous lines to be or not to be that is the question you see Shakespeare is vexed by this question this is difficult how are we going to manage the memory now we've got a philia steps in and as tis in my memory locked and you yourself shall keep the key of it o philia a feeder is really big on malloc and free new and delete she says okay you manage your own memory you know I trust you with this one that did not work out well Hamlet's a little more you know ah you know what I think garbage collection what about that yay from the table of my memory I'll wipe away all trivial fond records okay so we see here that this has been playing people as a problem for a very long time encapsulated with non accounts today two explicit memory management versus the idea of garbage collection or something that is managed and there is a thought that sometimes people again if I said associate procedural programming with the the unmanaged approach but I'm going to say that that is purely historical or rather a one view of history Algol 68 had garbage collection Simula 67 had garbage collection these are 1960s languages and one at the time people assumed that it was only lisp had it no no garbage collection was a thing the problem is we did not have the resources available to make a good go of it for anything other than academic programming people that the point is that at that point to try and introduce this into limited memory limited processing environments was seen as a luxury if we revisit procedural programming from that point of view and we see actually yeah we could do this and we do do this because this is where it gets kind of interesting the there is idea that when we look at this there's another concept that is that is going on how old is whether why do i how old is this idea of capturing state and moving it around how old is this idea of organizing your code with units of state associated with procedures well it turns out that part of structured programming part of the procedural paradigm as it was envisaged included a rather interesting idea called hierarchical program structures a procedure which is capable of giving rise to block instances which survive its call we'll be known as a class and the instances will be known as objects of that class so there is this idea that the block and procedure concept is the powerful idea what if I were to pass to you a block that contained data and its own procedures again we can call that a closure we can call that we can say that there's a lambda nurse happening there's all kinds of stuff here that was the essence of this in fact I can even represent that in JavaScript I can say okay I'm going to create a new stack I'm gonna have a private representation it's so private you can't even reflect on it its proper private because it's a local variable items it's gonna be an array and then I'm going to return to you a collection basically of named lambdas depth top pot and push that operate on that and so what you are given is something that is truly a separation of implementation from the public face you are only presented with something through which you can name methods this is effectively a realization of that block idea this is that one of the purest forms of object orientation that you can have and we can mess about with implementation and still get get it passing the same tests now there's another thing people associate with object orientation and it's it's it's known as concatenation well it is the dessert it's called inheritance but back then it wasn't called inheritance it's called concatenation the idea that I can concatenate one block with another and that they end up with the merger of all of the procedures and all of the state together was the basis of inheritance concatenation is an operation to find between two classes a B or a class and a block you can have a free-standing block and just inherit into that block mixin style and results in the formation of a new class or block actually we can do that with the is that this idea here concatenation is a merging of attributes and composition of their actions we can actually show this if I just tweak my JavaScript code a little bit and add in the idea of a base class and add in the quality of something being stackable and then add in the idea that you add things you can catenate onto the existing base you add in new methods okay what does that look like if we do inheritance or other concatenation I'm going to take an empty object that does nothing I'm going to make it stackable so that's how I create a new stack okay let's make it clear about so we can actually clear all the elements of the stack as well what's that look like well that's clearable stackable okay so we've actually got inheritance is an act of composition okay this is a it turns out that it's a fundamental concept here and we can actually make it a true composition in the functional style with a reduction so now means inheritance is equivalent to composition which is quite cute and encapsulation is equivalent to passing a block so here's another old idea the construction principle concept hierarchies is called abstractions we concentrate on features common to many phenomena and we abstract away features too far removed from the level we're working at so here's an interesting idea this is all part of the structured programming vision of how you work with procedural programming this is the bit that people forgot it's the third part of the book the book has three parts everybody focuses on the first part which is about control flow the second part is on data structuring the third part is this okay and what we discover is that people's view of structure programming and the is the organizing discipline for procedural is incredibly narrow from a historical point of view so hang on if we're talking about concept hierarchies that leads to type hierarchies substitutability Barbara Liskov again for whom the Liskov substitution principle is named and she described this type hierarchy is composed of sub types of super types the intuitive idea of a sub type is one whose objects provide all the behavior of objects of another type plus something extra and then she characterizes this what is wanted is a property here substitution if for each object oh one of type s there at that I see it in action let's have a non duplicate top let's mix in a non duplicate top let us imagine that we have we want to make our stack so if you add in a duplicate top then it doesn't add it okay so if you add in the same element twice it says ah we're not going to have it okay so let's just add that in let's mix I'm gonna mix that in I'm gonna write simple tests here and the test is a non-empty snap becomes deeper by retaining a item as it stop we're going to create a new stack I'm gonna push build stuff and then we push 2017 we're going to push 2017 so we're gonna push 2017 twice the debt should be three the top element should be 2017 okay if I make the stack if I make a stack if I compose a clearable stackable object then this passes if I then make it a non-duplicate top this fails in other words it turns out that the Liskov substitution principle is an extension of concept hierarchies what Barbara Atlas kapha was poking us focusing on was this it's a test of a property for all programs P defined in terms of T the behavior of P is unchanged when oh one is substituted for o2 now that's not the 1960s this is the 1980s but what we see is that flowing from that original vision of we're going to organize procedures and were going to allow concatenation between blocks in a way that allows you to organize concepts based on abstraction we see all of these ideas coming together but I want to talk a little bit I want to end the talk by say okay this is all very well this is historical but what does that mean for the present tense well first of all it means that these ideas are old they are testable they've been around most of the things that you're seeing in programming languages already probably existed and that's okay let's take a different view let's understand what is the future of procedural programmed because it turns out that procedural programming is still one of the dominant approaches not always kirat applied correctly that's why people use the term procedural to mean that it's a long way of saying that when people say oh that code it's so procedural they're not saying nice things about it okay because it's been applied out of its context where it tells you that it's got a problem with context and there is a different vision I want to offer you this idea I mentioned earlier on this multi-paradigm approach the idea that procedural is perhaps very good at describing things that are small it's not always the right thing there's lots of other things that are good at describing things that are small but what you need is a separation and David galantin who was one of the key developers of the Linder system talks about coordination languages this is a from 1992 we can build a complete programming model out of two separate pieces the computation model and the coordination model and this is something that we have been moving towards and where we can see future of mixed paradigms including procedural I'm going historically we had Nicolas worth writing this is the title of a book that he wrote on structure programming algorithms plus data structures equals programs we are going to refine this coordination plus computation equals programs and we see that this idea has been around for a very long time this is the original make program on make the bank build system if you look at make make is a declarative system as observed here the make file language is similar to declarative programming its main backbone its coordination model is declarative you set an objective relationships between files and then the computation model is procedural it's regular script so in other words it acts as a framework in which to hang your scripting code and of course this can be if you've always assumed that state change was okay and sequencing was always guaranteed this is going to confuse you because if this is the imperative model that we're coming into conflict with but this vision of something bigger actually gives us a very different way of looking at things like concurrency so let's understand I mentioned earlier on there was a there was a limited there was a problem with this idea of single thread of control I want to present to you food for thought given that it's lunch food for thought this is a simple quadrant diagram that characterizes what you need how you need to think of sharing of data with respect to concurrency you your data can be mutable or immutable and you can have it shared or not shared there are four quadrants okay one of them is difficult I'm going to use I'm going to use nature's color of danger to give you a clue here okay the color of blood blood is on your code okay this is the hard bit this is this synchronization quadrant if your data is mutable and shared between threads you will have a hard time if it is immutable you will have an easy time if it is unshared you will have an easy time but when the minute you share it and change it you will have a hard time but we are drawn like moths to a flame to the top right-hand quadrant 3/4 of it looks easy ah that's too easy let's move there but why did we end up here unfortunately ended up here because of procedural because procedural procedural soft space its comfort zone is a very simple idea the world is sequential sequence selection iteration we do that that means we're on the left-hand side the decades we were on the left-hand side and it was a matter of constraint and efficiency that we're on the left-hand side and we favored the mutable model that's closest to us closest to the machine so when threads come along we find ourselves moving right words and we go from the top left to the top right which is where all the pain happens I was like David butan Hoffs observation about mutexes I've often joke that instead of picking up Dijkstra's cue acronym we should have called the basic synchronization object the bottleneck yeah I want you to think about that conversationally what you need here in this code is a bottleneck yeah it doesn't sound quite so good mutex makes it sound kind of like positive and computer sciences it's like oh we need a bottleneck here mm-hmm it's so good so we actually find the original vision computation model allows programs to build a single computational activity a single threaded step at a time computation that is the idea is what you have is little pieces of computation and then you coordinate this idea of coordination language is you know the model allows you to create a larger ensemble and one of the earliest examples we have of this dates back to 1964 Doug McIlroy again we should have some way of coupling programs like garden hoses screw in another segment when it becomes necessary to massage the data in another way this is the invention of the UNIX pipeline it took another six years to pick the character okay 1970 Ken Thompson did that but this is the basic data flow architecture this is the coordination model for eunuchs okay the classic eunuchs model is we have procedural she'll and procedural see code and then we have a coordination model that is the pipeline we can extend the pipeline we can do lots of things we can talk about pipelines as a discipline we can say what you have perhaps a number of items you can keep in there so whether it's bounded its buffered it's asynchronous so the all these ideas are fundamental a we can change the numbers you can have infinite well you can't but you know unbounded don't have unbounded probe using your code it's bad but unbounded buffered an asynchronous if you make it one it's bounded buffered in a synchronous we call that a future futures and promises come out of this model and if you make it zero you end up with the channel the default channel model of go and other languages that use this like akhom and indeed a classic coordination model this is how this was one of the ways of reasoning about all of this Tony Hoare again communicating sequential processes we take sequential processes because it turns out we're really good with sequence and we coordinate between them using channels this is 1970s okay the book was 80 but the original CSP model was 1970s people have come to the actor model which relates to this and CSP again recently this idea of paradigm mixing through coordination and computation makes sense of where procedural programming is going to be with us in years to come so on that now if you're going to use the word paradigm I always direct people to this paper this is that's a deep sound paradigms program Robert Floyd cheering Award winner in 1979 he's the guy we can blame for using the word paradigm and introducing it to software developers and his perspective was not that we should pick the best paradigm he had a very different view I believe the current state of the art of computer programming reflects inadequacies in our stalker paradigms on knowledge of existing paradigms in the way we teach programming paradigms and in the way our programming languages support will fail to support the paradigms of their user communities this was true in 1979 I want to it is still true now so that I would urge you to go back and revisit the basic ingredients of something like procedural programming or a paradigm that you learnt and rejected and forgotten decided this is ridiculous so this is an old idea this is a deep idea and this is how we're going to be taking this forward I hope that's been useful or at least provocative thank you very much

Channel: Coding Tech

Views: 150,853

Keywords: procedural programming, programming, functional programming, software development, programming paradigm

Id: eEBOvqMfPoI

Length: 62min 14sec (3734 seconds)

Published: Sat Jan 13 2018