The Forgotten Art of Structured Programming - Kevlin Henney [C++ on Sea 2019]

so what we're here to talk about this is a Jackson Pollock picture it's here just because it's here because one of the most intriguing things about Jackson Pollock's artwork somebody actually sat down and studied it it turns out that it is fractal it is scale free which is quite impressive given that he did it by did it by hand it's not just random splashes it's scale free which has everything to do with software software is effectively scale free you make big bits of software out of small pieces of software you make those out of small pieces of software and so you know Turtles all the way down and what's important about that is that this structure this concept of structure is very different to our normal physical relationship to structure physical relationships structure you build buildings not out of smaller buildings but out of bricks and you don't build big bricks out of smaller bricks that's not how it works so in the real world many of our structures are you change the scale you change the medium you change the rules but that's actually not the way that it works in code so what I'm going to talk about is that's the trolling version of the title the full version of the title is this and so in order to understand what structured programming is why is doing structured programming in C++ conference because we'll find out why and because we're talking about art the you know I've so this is this is where I get to introduce myself you know the you know parents gave me an Internet unique name do this for your kids this is very wise it worked for mine so that took a while so I started taking pictures mostly in airports of public software failures and computer failures in general based on the observe a as software developers we are responsible for most of the installation art on the planet okay so your guerilla installation art sometimes we do private viewings in your own and you're on your own machine this is PowerPoint 10 or so years ago about to lose my work at this you know here's the C++ reference oh look pure virtual function core how do you get one of those ah well there's a couple of ways that you can get that it means that something was not code reviewed so somewhere in the chain of destruction most typically a virtual function was called and ultimately into an abstract base class and that kind of suggests that there was a missing review well there was a missing piece of static analysis we'll come back to static analysis later it also tells you a great deal about the architecture it's one of the things I'm most fascinated by in terms of failure it tells you about the structure this is PowerPoint about crash and yet it's in visual C++ and yet the program that's blamed is Internet Explorer honestly I don't run it the only reason I ever run it is to install a web browser but it shows you the dependency structure it also tells you why the memory consumption is so large it's a classic unstructured piece of code okay there is no there's a very weak philosophy we need the HTML rendering engine you reach for the you reach for the banana you get the gorilla yeah the HTML rendering engine is it a separate DLL oh no it isn't it's attached to everything else so in failure software reveals its structure Oh visual studio again interesting interesting interesting that's a hell of a license disappointing me disappointingly I did actually have to pay for it the following year so and the point is you're looking at that and you to other users this is just an arbitrary number you can't help myself you know what it is you're looking at about you know exactly what it is you see this and you understand so software in its structure when you use car like taking something you drop it and those fracture lines those weakness lines they fish around and they tell you something about the way that it was built anyway it's got to the point where people actually send me this stuff I don't need to do this anymore so from Canada we have you can see the PHP object model there it is laid out for you and it's people got to the point now that I am now a word I saw a Kevin henny screen it's now apparently got an entry on urban dictionary and stuff like that so people tweet me this stuff so that's it's got a little bit recursive this was agile in the city in Bristol year and a half ago two years ago so John Clapham said Kevin I've just spotted a Kevin in any screen I want to take a picture of you in front of it and then I'm going to tweet it and then you can retweet it and yeah so we did it the following year as well and then we've got this cable Inception here at another conference now it's not really about this so I'm gonna come back to failure I seem to be drawn to it but here well we need to take a bit of time travel and it turns out that failure is the way we shall travel through time because I'm gonna take you back to the 60s thanks to Facebook ok again you're looking at they go I know what causes that you can't help yourself everybody else is going 31st December that's 1969 that's completely arbitrary you're going ok that's the beginning of time and back a bit maybe there's a timezone error maybe there's just like you know something happened there and you're sitting there going what is the problem anyway it was all a big lie they they didn't improve Facebook so ok back to the 1960s what was happening Oh 50 years this year wonderful staff Margaret Hamilton she basically saved the day the 1202 era if you're not sure about 1202 here come and ask me fault-tolerance software she also happened to be responsible so she worked on the Apollo guidance computer she also had to be responsible for inventing the word the term software engineering which also triggered this conference lots of exciting stuff happening here as we open today with the opening of 2001 a Space Odyssey well you might say it's more classical than that but I don't that piece of music was written for 2001 a space it just took a while for it to find its medium possibly one of my favorite films of all time excellent typography as well good use of gills songs so other things were happening great music it was a time of revolution Paris riots we had the Prague uprising and then we had structured programming the programming revolution in fact one of my first points of contact when I started working in the 80s after university that my boss had all of his books was a collection of papers from the 60s and 70s called writings of the revolution it's just like yeah you pray and you felt you wanted just like yeah this is it how to make for train exciting oh yes and just in case you were wondering whether you wanted to break at this point we'll be talking about break and we will be talking about for tre um so let's talk about this guy Robert Floyd 1979 he received he received the cheering award and he published and his talk his acceptance speech paradigms of programming he's the guy we have to blame for introducing the word paradigms into software development it was being used elsewhere as a word but it's his fault however it's our fault for not reading his paper because he actually had some very different things to say than the normal paradigm discussions and we're gonna come back to Robert Floyd a bit later as well but he opens when he talks about paradigms of program he starts this is a familiar example of a paradigm of programming is the technique of structured programming which appears to be the dominant paradigm in most current treatments of programming methodology so we're here in kind of peak 70s and the problem is somehow for a lot of people when they hear structured programming what they think is oh that was all about not programming with a go-to wasn't it like that was the whole basis of all of the theory and all of the disk it's just that well that's certainly a part of it but they might have been a little bit more to the story than this but if we go back to the 60s here we are 1968 communications of the ACM probably was Faye as letters ever written to it go to statement considered harmful Edsger Dijkstra really helped put his thoughts out there and that is the that he basically or rather this letter can be seen as one of the sort of moments where the idea got out that there might be a better way that perhaps there were different levels of programming in different levels importantly of reasoning a lot of people who were getting into software development we're doing so through different professions and this is still true today but the notion of a software professional was not really a thing back then so there is this idea that many people were approaching it from the machine upwards and those people have been at the upwards bit for a while have been saying oh no no we don't have to we don't have to be down there and have features we don't have to have jump statements dictate the model of our language we can have richer concepts we can have types we can have other than word and so on so there's this idea of taking it a bit further now it also happens that go-to statement considered harmful is one of those phrases that people now use is kind of like a standard blog thing X considered harmful so one of my interest is words and language and I run a page on Facebook which has not been approved but I collect various words and one of the words that I profiled and showcased a few years ago snow clone cliched wording used as a template yes there are template phrases there are templates in the English language the rules are a lot easier in case you're wondering although occasionally if you are not a first language speaker you will need deduction guides so what we've got here is the snow clone is a something that typically originates in a single quote X considered harmful these aren't the X's you're looking for X is the new Y it's exponent as we know it no X left behind its X's all the way down and your ex are belong to us however it turns out Dijkstra wasn't responsible for that Dijkstra is meticulous in keeping and publishing later all of his writings his original version was a case against the go-to statement and it actually turns out that it was Nicholas Burke the inventor of Pascal who was the editor of cons at the ACM at the time who changed the title so this is basically 1960s clickbait go-to statement considered harmful you won't believe what happened to this code when a go-to was inserted I need to find out we've come back to worth a bit later now the thing is a case against the go-to statement that's all very nice in 68 it turns out it's all very very 21st century if you want a really good case against the go-to statement let's talk about go to fail ok apples little flirtation with the SSH should a couple a few years ago so yeah that was a little bit of it SSL so I was gonna stick confused go-to fail go to fail go to fail go to fat ah oh that didn't work out turns out that was quite expensive now a number of people look at this and they respond what I'm fine fascinating is their responses some people go well that's just how you do it and see I was a C programmer that is absolutely not how we did it not at all in the 80s in the early 90s you're doing this your colleagues are looking at you going like what we didn't have WTF at that point but pretty much it would have inspired us to say that no that's not how you did it secondly sometimes we go isn't this why you could put curly braces around and then they don't come up with all kinds of stuff and it's like honestly no first thing let's talk about tools if you are producing secure SSL code is secure allegedly if you're producing secure code how do you know it's secure because I wrote it I don't think so you need another objective source of reality okay static analysis tools they're great they don't let you get away with this stuff high warning levels all the rest of it so that's a dead problem no this is another crazy idea that seems to have taken taken hold and testings that's the engineering rigor of software engineering ok test stuff and this is an important point because a number of people then say well you can't test that because it's all the C code and it's all very low-level and it wasn't written to be tested and I love it when people lay down the challenge like that because somebody comes along and does it now this is Mike bland former Googler brilliant brilliant piece on things like heartbleed things like go to fail and things like testing culture it's really interesting read and I'm sure you've got long builds at work there you go here's something for those I said these bugs are is instructive as they were devastating they were rooted in the same program of optimism overconfidence and haste that strike projects of all sizes and domains this is the deep truth here and they aroused my passion because I've seen and lived the benefits of unit testing we'll come back to unit testing a bit later and it compels me to reflect on how your testing approaches could prevent DEET defects that's high impact and high profile as the SSL bugs so we already see that these little slip-ups we have a language and a language family that supports certain kinds of slip-ups more easily than others but hasn't that's popping down to their age they have these various features so I'm going to go back a little bit further on from the 96 you put it into the 1970s some knr see I'm going to pick a a nice simple problem one that I normally pick on because it's got just enough control flow and people always feel that if nothing else they learned something during the talk like what the proper Gregorian leap year rule is and so therefore and if you want to have an argument you'll have a discussion about the correct base point it is not 1752 okay that is not correct okay if you private your hard code 1752 have a word with me afterwards if you don't know what I'm talking about that brilliant I don't want to infect you with bad knowledge so here we go we're going back to the 70s so I'm offering you six character external identifier is leap okay you don't get the full is leap year with underscores and here's how one would express it was his so knr see this is how you'd figure out the leap year rule okay now some people would write it like that I personally would write it like that some people would say now I'm gonna write it like that going oh yes it doesn't have billions don't worry we're gonna see true and false in a minute and you'll regret thinking that so some people will write it like this some people all say oh he's put curly brackets around everything the only yeah but a blank line between different like yeah okay now if you've been paid by the line of code this is awesome okay you've just taken something this is actually a very simple piece of logic although sometimes confusing and really expanded it now so some people discover that other people go wait a minute isn't there a thing called an else yeah it turns out that with else you didn't need most of that noise anyway because your compiler will cache this stuff so we've seen a couple of different ways of doing this some people will come at this and because perhaps they've come from the idea of you know a more electrical engineering and maybe I am dissing electrical engineers a little bit that's that's fine I mean they deserve it and it's just like yeah I'll just put a jump lead from here to here and there's gonna that go-to is really powerful and they'll be somebody that says it's efficient there's always somebody there if somebody says it's efficient and it's just that okay so later I was saying like this see I told you see true or false yeah she know how much fun it was writing this it's really there's a kind of like perverse pleasure you're sitting there going like like okay you know are they videoing this now they're not excellent so therefore it and get awake that so that they reserved there was a notion here of D factoring it's quite joyous sometimes now we haven't D factored enough because then you get people well you know you can get rid of all of that and just you know use that which I still find in C++ code I'm fact I pointed that one out to somebody just a few weeks ago really but then you've got other people don't like no no we can take advantage of the fact that some of these are actually the same we can reuse code that I'm really proud of yeah exactly yeah so you see the groans tell me you're awake which is really good okay but if you really want to get into this style ice I promised Fortran and it turns out this is confession moment I was a Fortran programmer I was a richly painted write fortune when I left University because I've got a physics degree and apparently that's all we're good for it's you know yeah they can write Fortran no physicists cannot write for trap it is a myth okay they can get they can sneak code past a Fortran compiler that's different so let us use this style and really go to town on it so this is how a Fortran programmer might go about this the same six counter limit by the way on externs apparently all this is logical this is goat but Fortran carts from an era when integers were integers and not it's okay so you know you get a little bit more for your money actually no it's still word size so you don't get much more at all so you get that and P and you don't get nice helpful label names you've got numbers now there's something interesting here if you're not familiar with this language which I'm really hoping most of you aren't but there's a there's a name there is leap I'm actually assigning to the function name some of you go oh yeah that's how a lot of languages used to do it and then there's return statement here now that return statement kind of interesting because that return statement is not returning a value okay this is a this this is you know we're gonna see this kind of important later and then you got end at the end so return is just control returning the control flow we've already assigned we bound a return value to this but it turns out that it's not just the curly bracket languages that create their own little idioms and cultures and weird habits oh no they're the Fortran programs I work with it's like oh well wait a minute we should make it symmetric we should put return there in fact honestly I work with the guy said oh you need to put return before end that's why they said well because you don't know if the compilers going to put put put the right code it otherwise to actually pop the stack and it's just like I'm pretty sure it knows what end means pretty sure that they thought of this one and then you create these rituals and they get they you know we should have a single return point yeah we're gonna come to that one sound a single Recep okay we'll just jump to it no no really and then you end up with this so we should do that and then my favorite is this this was the house style continue does not mean continue in the sense that you might be experiencing continued means now on that's a dead statement so now we're gonna jump to an exit and this was the kind of light this was the fade-out to almost every single function in the Fortran code base it was just that's just and honestly with those fade outs you know what the rate you know what the radio hosts do they just cut them really that just needs to be cut so you'd end up with stuff like this now that was kind of Fortran 66 fortunately most of the stuff I did was Fortran 77 and extended fortran 77 fortran 77 had the luxury of having an else yeah we have we had kind of stuff like this yes okay now this is the interesting bit you can now actually perceive structure you've now got a backbone people started doing indentation my boss was a little slow on the whole indentation thing I remember indenting some of his code and the number of bugs I found was quite impressive yes sir but it was just that he didn't believe in indentation that's I I don't believe in father Christmas but that's not quite as critical okay this is a different kind of belief now what I want to point out to you is the nesting structure the nesting structure here in fact let's use the word structure that's why it's called structure programming this is what people were trying to do wasn't just a rant against the go-to it was to try and give a sense of structure where you would otherwise have only spaghetti and this idea of the visual structure corresponding to something meaningful will have the decisions here as a function move in one will have the decisions that forms the spine of this and then there is a consequence to the decisions and that's one level further in you now contract fishel e but also syntactically the what the level of interest that you trusted at its own other was to code is a two-dimensional structure where we often think of it's linear it's very to dimension in the way that humans approach the kind of the myth of free format languages is that code is a one-dimensional structure actually it really is a two-dimensional structure how you navigate it how you actually read code is not only a linear way so this second dimension turns out to be quite important but it's not just a vague idea it tries to reflect the higher-level structure now how urgent Townsend guides of designing programs pulled no punches on this one is it a go to completely invalidates the high-level structure of the code that's what they were talking about when they said this the high-level structure suddenly you're having to put a jump lead from one place to another now a lot of people go well yeah yeah sure but we don't really need that anymore the whole the whole go-to thing was about having a single entry point in a single exit point and and you know we don't really need to be bound by that well before we go any further with this I just like to point out that people are very blind to the multiple entry point thing do you often think that's not worth discussing it is what's this called - device yes if you've ever wondered what happens when you teleport into another physical object occasionally science fiction films and books will deal with the fact that the two objects suddenly in the same place what happens when they occupy the same physical space well we have a kind of answer here by teleporting a while loop into a switch statement yeah we got to do while there and we got the switch statement cohabiting and a lot of people go is that possible before asking should that be possible and well we've got we see a loop unrolling here okay and the loop on this is in telecoms code and you want telecoms code to be fast and we had not yet here let's say the modern era which I'm going to say kind of mid 80s onwards in terms of hardware and the compilers that we're getting for them there was this notion that actually you're better off unrolling the stuff by hand if you are copying chunks of eight bytes this is everything works the problem is that it might not be act multiple of eight so therefore how do you deal with the initial offset well this is how you deal with it I think this goes back to the art question we open with Tom Duff on this I feel a combination of Pride and revulsion at this discovery and he says many people have said the worst feature see is that switches don't break automatically before each case label this code forms some sort of argument in that debate but I'm not sure whether it's for or against so this is just a reminder and this is just a reminder that multiple entry blocks do exist and you can do them you don't need the word go-to to do it you can do some other strange choreography in this and it's notable that pretty much every other language the switch statement is a flawed Beast but every other languages it's picked up this flawed basis at least try to kind of like tame it a little bit and has not allowed this kind of behavior but yeah break has many stories behind it but that's we'll get to the breaking in loops but you know often people end up sort of ultimately citing some AT&T code this is cited in peter van der Linde in his book on expert c programming and this is a really interesting thing because this actually took down the telephone network 1994 about a hundred and fifty million subscribers in North America on a Monday if I recall correctly during the day this was a time when people actually use telephones to do business so this is quite significant it cost quite a lot of money they AT&T basically blew there as it were their mean time between failure budget for the next few millennia on that um so there's a break statement here okay this break statement here is is supposed to in the programmers head and this actually tells you about the cognitive load in the program's head they meant to go here because they're thinking curly brackets but actually what it does is it goes here past the initialize pointer thing so you have uninitialized pointers which takes down the server which starts up again and says oh that was bad and tells other servers about this which causes them to go down and gets beautiful wave of failure spreading out across the North the eastern seaboard so yeah so that's so we were presented with a problem that break there's break and there's break so I wanna separate these two there's break and switch statements which is just an absolute nightmare and then there's your other break the one that you find in the one that you find in loops and that worth that's worth talking about briefly although when I was putting this up I was thinking break break you know this is kind of like the you know this is where you need to be careful yes exactly you've done it that was really good I mean you know I said well done no it's just like you sit next to him on an aircraft he's safe you know but here we are in in in C++ where we actually make a distinction and we got brace brace so the other creatures in here don't already know talk about break I'll come back to break a bit later I'm really not going to talk about continue because honestly continue just write the damn code don't continue don't confuse your reader I was delighted to see about what was it about 20 years ago PJ plow go gave a talk on coding subsets and he said you know he hadn't used to continue since about the nineteen seventies and I was pretty good yeah because I can't remember the last time I used to continue other than demonstrate how not to use a continue but I do want to talk about our friend returned because it turns out that it's a piece of advice that we sometimes pick up and we need to be very careful with it and that all we react to that a function should only have a single return the problem is that that advice kind of applies to Fortran it doesn't really apply to the languages that we're talking about it doesn't apply to the c++ --is the C's or indeed any of the curly braket languages because it turns out that there's not one we kind of return has a tool or two sides to it return violates the single responsibility principle return does two things and this is where we need to be very careful because what we've ended up with is legacy advice but the world has moved around us return binds a value to the result of a function return changes the control though these are two different jobs the problem is that the advice has got parroted as a simple statement and we with that and the languages have changed around us so to get a sense of this go back to the Fortran it's all right I'll spay the fork we're going to be done with Fortran in a bit I've got other scary code so we get this we've got the structure there I'll present you with an alternative here if you want here we actually see the two different roles here bind a return value return and return from this now obviously this is so common that it gets shortcut to a single construct this turns out to be surprisingly convenient but that is not a foregone conclusion in language design languages we're exploring a very different space in the 60s and 70s before people started setting on this as an approach but what is interesting about this having separated out two roles is to look at how we approach the code I can't actually understand it like this anymore in order to understand the backbone of the function I actually have to get inside the ribcage I have to go in there and say all right in other words I cannot close those bits off and say they're not important because it turns out to have a very fundamental shift in what's going on now if I introduce an else then it turns out that I can reason about it like this and it also turns out that returns are redundant and I can get rid of them but this is a simple transformation to sort of characterize what people were talking about it means therefore that some of the ways that we perceive our advice need to be revisited in terms of what we consider structured and not structured now I'm going to shift to I'm going to shift to groovy because one it's got curly brackets and I thought you know there's only so much Fortran you guys are prepared to tolerate but the reason I've shifted to groovy here is because I can do this it's got an interesting feature and allows me to show the two different two different styles quite clearly there's a fairly conventional return statement and there's this one the last statement executed within a function its value becomes the result of the function and then was we can actually write stuff and it's the last statement the counts and that will be returned so a number of languages have this as a feature but this one allows us to go in here and we've got this version okay if else--if else--if and we got this version which short-circuits now one of these is structured and one of these is not I would get you to point to them but it's too narrow space so I'm going to exaggerate the pointer effect if you think that one structured I want you to point over there if you think one on the right is structured then I want you to point over there go doing pretty well excellent there's a little bit of confusion some people out for both schrödinger's yep yeah yeah I've seen pointers like that before now what is interesting here is that although the one on the right is a style I find increasingly popular and actually the Java people have been really responsible for this one yeah it's one of those things I just remind you if you're going to use tools remember to configure them yeah don't take the defaults okay the defaults with somebody's preference okay and they probably just did it at the last minute um so here we go if we actually do this and we transform this what we actually see is that no return statements are required on the left-hand side it's pure flow on the right-hand side I require short-circuiting control flow therefore I cannot reason if I actually drop this too if I drop out the nested stuff I cannot properly reason about the one on the right without going inside the block that's what the block structured the whole block structured narrative the whole structured thing was about was actually about being able to do this kind of like perfect nesting so it turns out that it's our friend over there qualifies as structured it's not that the one on the right doesn't do it it's not that the code will actually be any different this is the intriguing thing it's the generated code will be pretty much the same although funny enough I've or the most interesting experiences ever had with somebody describing something reading out some code and they read out something equivalent on the right and they read out and else it was actually fascinating listening to them talk said otherwise or else as they were going down because code is a two-dimensional structure they needed to anchor it in their serial communication which is very one-dimensional now this is kind of interesting because it's also we flipped language again this language is Algol 68 Algol 68 doesn't have a return statement our 68 also has last executed expression yields the value of the procedure it also has some other nice things you can put you know the spaces aren't significant in names you may also notice that those crazy cats are using int not integer and bool and crazy ideas like that so this is a this and you may notice the F and fee and Elif turns out at Algol 68 is responsible for lots of stuff that you didn't know about Algol 68 introduced int introduced this whole if fee structure this LF structure it had a number of different features including procedures that were anonymous and could be used inside an expression and passed around let me just rename that lambda and you suddenly feel comfortable until you realize that C++ got them in 2011 and we're talking about 1968 here so llego language it's also the language responsible for all of these abbreviations they did not exist in other languages until about 68 all of these terms they come from 68 now there's another interesting thing about the example I just showed you and the the Algol 68 example and the groovy example is this is Haskell it also turns out that this is identical the the conclusion that we're drawing a very very there are some distinctions clearly between functional programming and procedural programming but it turns out that we arrive at the same answer because it is reducible to an expression there's no short-circuiting there ah this is stuff that people this is the old naming naming of the function approach this is Pascal now here's an interesting one so this is go which has been described as a very opinionated language in terms of its style and its design decisions many which I find incredibly easy to disagree with but one of the interesting things that it has so we've got the kind of familiar structure of the return there but you can do this as well I can actually name a return value for reasons best known to themselves you need and what's called a naked return at the end I have no again this actually just sounds like the Fortran example just gone horribly wrong it's like won't it know when it's reached the end it's just like no really it will you know so so but the point here is I'm able to name a return type and then show you that that flow works very simply it's a very simple idea what we're talking about here is nesting and flow now that nesting and flow can be demonstrated in a number of different cases which means obviously it's time to take a break from leap years and go to some serious hard problems like fizz bus and the Wikipedia page you stay they've updated the Wikipedia page but it's not as good as it used to be it still says it's a group word game for children to teach them about division which is honestly news to me and there's a description here of the rules basically the things that are of interest any number divisible by three is replaced by fears any number divisible by 5 but buzzed of his blog both this bus okay and all the other numbers remain unchanged so you go around is a drinking game it makes an awful lot more sense however one of my one of my favorite pieces about this observation was that whoever wrote this managed to sneak in the word thence forth which I you know all credit to them that's an archaic word that hasn't really been used in English since the 18th century so you know it's that those little Easter eggs are worth are worth it anyway it says adults may play fist buzzers are drinking and we're making mistake these the player having to make a drinking Veloz food which makes perfect sense the bit I loved is that it says citation needed no it's just like really honestly that I don't think you need a citation it's also been used as an interview screening device and people approach it in a very simple way it's kind of good fun there's also the other observation that perhaps people do this because they're not entirely sure how to sort a binary array without getting a binary search and rate without without getting it off by one error but if you go about it typically when you first sit down there's one of two typical ways that you're gonna do it so I'm gonna do a using namespace standard off the top and people generally hit on one of two approaches they will end up with what we might call the accumulator approach first of all I start with an empty bucket that's result and then I'm gonna add fears and/or buzz and that you know there's that moment of delight where you realize you never have to handle the divisible by both case because it falls out for free you go awesome however you do have to say oh I need another check because it might it might be a number the other one is where you do the check twice but you never check you end up checking divisibility by three and five twice which I've rolled into fifteen there but you only ever take one pass strictly so here's the question which one of these is structured and which one of these is not structured same same game go cut out shares just kidding they're both structured they both satisfy this their difference is actually that the one on the right is functional because it can be reduced to an expression okay so in other words I do want to highlight that not everything that is still there is clearly some kind of overlap in terms you actually find there's a lot of overlap and in terms of the ethos and the idea is particularly when people talk about data flow and control flow and binding them together there's a lot of overlap between what we will consider structure program what we consider function program but they are non identical both of those are actually structured but this is reducible to a single expression and therefore is functional however we're gonna have a bit of fun because obviously the code so far is not stretched well it might have repelled you and you might have found it repugnant and disgusting and all kinds of things so I've got an emotional response for me I think that's good but I obviously need to do something to keep you awake and this magnificently crazy paper amateur pirogue fizzbuzz in Haskell by embedding a domain-specific language the default action is executed only if some previous actions were not executed now we can get a little bit crazy let's go back into C++ is how high I think I can get this down to just a couple of lines and you feel really good about that but actually even here you're still checking things twice okay you still have to do a composition and then a check you always have to do a check you either have to check that something is divisible by three or five twice checking it divisible by 15 is exactly that or you have to do everything but then just check whether or not anything happened check if the result is empty so he sets out to do so we asked if we can accomplish this without having to check the conditions of the previous actions twice in other words if we can make the control flow follow the information flow without losing modularity and it goes a little bit crazy from there so he does all of this in Haskell so I sat down and probably had a go at it in the number of languages to make sure I understood it and I had to go in Python in groovy in Java and c-sharp and C++ and so walking through it here's how we're gonna go about it we're gonna have a face function then a lambda it and what it's going to do is it's going to take a function and then what we're gonna do is we're going to return a function dependent on whether or not it's divisible by three if it is divisible by 3 then we will return a function a lambda that returns Fears plus the function that was passed in of blank or will just return the function and then we'll have a bus as well which kind of does the same thing we'll have an ID which returns itself and then we'll compose it rather elegantly in a sort of a small swarm of Lisp like parentheses at the end and what you've got here is function composition so what we're going to do is gonna take it the ID we're going to push it into the buzz the buzz thing is going to then push into a fizz and then we're going to apply the result of that to two string and tada there's no checking twice and it all works I have the test for it but then you realize there's duplicate code and should do something about there so then by the way we're completely ignoring all of Kate's guidelines from the opening one letter days but I'm actually taking this from the original paper so I'm not making it more obscure no actually it was in high school I am making more obscure by putting into C++ so we can actually reduce it down I can almost get away with out types but to make it a little bit easier on the eye bind it's a little bit better than lambdas in this case and so then suddenly you've got this so you can kind of sit there and be satisfied that you've written something that none of your colleagues will ever understand again in fact one of your colleagues is you future you your future you self will come back to this and go oh my god I wrote that in the bar after that bloody C++ LC conference where yeah okay now the point here is yeah you can take this a little bit too far but the point here is with the functional stuff you often will take this compositional model in a slightly different direction slightly different massively different direction to what you would then have done with the structured programming aspect so they do share this kind of column base and I think I will explore a little bit of that here so that's a beautiful piece of art so let's again have a look at something else that in terms of structure and visibility I've got well does anybody got a bucket for guy here I think he's gonna throw I think it's yeah I know is you know so so realloc is one of those masterpieces of unco he Civ design you tell people you know you say Oh what was it do well it reallocates you something that was allocated by Malecha tree allocates it to a new size except if you pass in a null pointer it behaves like malloc and if you pass in a size of zero it behaves like free just in case you're wondering this was the C committee tidying things up react used to actually be a lot nicer pre C standardization and there were a number of different fallacies one of which is you can't have a zero sized object well that's not necessarily a fallacy it's just that they misunderstood have requiring allocation of an object of zero size does not mean you have a zero sized object it just means you can dereference zero bites from it that's a completely different statement there is a fundamental difference between an empty glass and a thing that is not a glass when you understand that you will have a moment of enlightenment and realize this is a sucky design however somebody has to implement it so we'll have a bit of a go at doing that and this is actually something that appeared in an article a few years ago it was C++ kind of implementing this just showing the general outline now what is interesting here is that this is one of those pieces of code that requires you to read from the top all the way down to the bottom it's not that you can't do that in fact this is one of the key things when people talk about readability reading is a thing that you practice is not a natural thing those of you who've had kids or nieces and nephews will realize that there is a process here it's surprisingly unnatural for human beings to be able to do this to be able to read code is even less natural so therefore you learn a set of skills and it's about practice if you practice one thing you'll get good at it our point is what do we want from the code now this one uses a mix of different styles but mostly it's early return with no else's we have to read the whole to understand the whole you basically you're running as a program counter so we have a linear understanding which is pretty much what's actually going on down there but if we rework it we end up with something and there are the three factions of this but this was the one I had available with something that actually shows those three distinct personalities react react has three different personalities that's not visible here but it is visible here one two three you can actually see in the backbone of the function okay Here I am behaving like malloc here I am behaving like free and Here I am doing what's in my proper job description okay so you have that but point here it's not that the code we generate will be any different or significantly different it's more that this allows us to illustrate the block structuring the nesting that I verbalized early on which is a lot easier these days to see when people have actual folding editors as a normal thing I used to have to tell people what a folding editor was before allowing them to visualize it but these days it's a lot easier but here we have this idea of understanding the blocks what is this notion of block structure programming and how is allowing us to navigate so there's this idea that the level of interest the further aware further in you go the less interested you you should have to be in order to understand the whole so I get rid of everything and resize it there's also another property here and one of those fundamental properties is the ability to refactor something and it turns out that that is one of the characteristics of block structured programming which i think is quite impressive because refactoring didn't really come about until Bill Updike's PhD in the late 80s and early 90s and Bill Updike was interested in refactoring C++ very specifically so the term really wasn't around but block structured code has this property when we're talking about the block structure where we we've been thinking about this idea that you have a simple flow you just have data flow going across it that's all you have to do the minute you put a break a return or anything else in there you disrupt that you have to do something extra typically add state it also helps highlight a common misunderstanding that I see every now and then will say oh yeah but what about throw you know throw is like the ultimate go-to and I would say whenever people sort of say that I kind of think yeah I do don't know about go to well you don't know about throw well quite possibly both because go-to is bound to a scope a label is the only function level thing that exists everything else is block scope it's the only function level thing that truly exists what is interesting here is that throw respects this if I put a go-to in there if I put a return if I put any of the other constructs in there they are bound to the syntax throw is not bound to the syntax throw actually is invariant under refactoring it actually respects block structure whatever else its faults might be it does do the right thing in this case so we can take that one out the cons it actually does the right thing you keep refactoring and the same thing will happen now this kind of model of thinking explains a lot of so this is my copy of structure programming really it's a collection of essays by really you hand are Eska Dijkstra and Tony Hawk came out in 72 and it kind of explains the kind of thinking that they're talking about when they say stuff like this one of the most powerful mechanisms for program structuring is the block and procedure concept the idea that you can take a block and name it it's pretty powerful okay and often we offer people similar advice whenever you see large sections of code with a comment on the top next to another large section of code with the comment on the top you say you know that comment that pol big block of code that wants to be a function and that that is its name or at least the first draft of a name you've given it but they go a little bit further with this and I'm gonna go even further back in time what you're looking at here is code from a language as you can tell is typographically interesting as well as type of graphically challenging especially for the time that was invented this was invent this is the language plan Cal cool it was developed by Conrad Sousa in 1948 and as you can tell this is kind of like this this is block structure before block structure okay the reason this language didn't catch on should probably become apparent you know if you're thinking teletype you're not going to get this and it's a shame that the ideas and a number of people observed during the development of Algol 58 Algol 60 and onwards but it's a shame more people weren't aware of this because it had a number of ideas so first of all the stuff at the top is what we call a signature these days Ord stands for ordinal this is a sorting routine this is actually bubble sort I went through it and it's a bubble sort which is fine it's 1948 you know it was give me another 10 years or so before Tony Hall came up with quick sauce so I think that they're forgiven for this it's very elegant input/output perfect block structure these are blocks w the very and so you've got a bit of interesting stuff there there's an array of things that comes in there is different sizes and that transforms to an array of things that become the output so it's a pure dataflow language as well nice one Susur the W's here that's a while loop but W is not while it's V the hole and repeat and then there's no if but rather there's condition blocks and you can kind of see that what you've got here is there's a condition there and then there's the not of the condition else had not been invented else would not be invented for another 12 years imagine a world with that else okay but there's the idea of the condition and the NOC condition and then everything else follows and you have this very elegant thing but despite all of this guess what there's a break and I don't know what Sousa was thinking it's just like yeah yeah I'm German sod this I'm gonna use a French word actually there is a there's probably a precedent for this is that a lot of films a lot of silent films used to end far regardless of the language they came from until Hollywood took over but that was service there and put the end there so we actually see this idea you can actually see the origins of this kind of idea of nesting things so you can reason about them very thoroughly goes back a long way and what we have is the idea that and what as it is expressed that programs can be expressed using only a combination of sequence selection and iteration that's it that's all these the only constructs you need this is slightly different to something like functional programming which actually basically says you need selection batty you don't need iteration you need an ability to do recursion but that's it that's all you need very different kind of proposition that this was the kind of like the sort of the three founding pillars if you like and we even end up with this a large scale we'd be looking at small pieces of code here but let's talk about this in terms of architectural style I don't want to find fascinating is that sometimes you've got to be a little bit careful when you let academics loose so here's the book software architectural practice bass Clemson Casman they are kind of the software engineering Institute at Carnegie Mellon and software engineering the sei did a lot of work in the late 80s and 90s on trying to put software architecture together as a first-class discipline and one things they thought they'd do is catalog a number of existing architectural styles we can actually see there's an overlap and the convergence with what was going on the patents community at the time as well however their kate said naming is hard yeah these guys weren't faced with procedural programming what should we call it I don't know yeah the other folks are calling it procedural we tell you what why don't we describe it by its structure what you mean procedural you mean structured no by looking at its structure and saying that's the main program and those are the subroutines so what name are you suggesting main program and subroutine okay we'll go with that one ah terrible name although clearly very very accurate tediously so and they characterized ins they said the goal is to decompose a program into smaller pieces to help achieve modify ability mmm that doesn't really get to the heart of the paradigm in fact it's very difficult to find any positive paradigm that does not have this as its opening statement yeah this is oh yeah you know it's just kids all right know what our goal is to just mash things up together so we have no idea what we're going to do and so that we can't change it you know it's a what your what the distinction between one paradigm and another is the philosophy that you take in what way will we decompose this what what is our backbone here and it turns out that the backbone for procedural programs and what gives rise to structured programming is control flow we are going to organize things with respect to control flow there may be data but control flow is our dominant axis whereas if you look at relational modeling it says the world is made of data that can have network connections and we will organize around a reduction of duplication it gives you third normal form and all this kind of stuff so you end up with these different philosophies and unless your job is to actually say our this is the this is the keep your job paradigm in which case the goal is to just modify ability and reduce comprehension then pretty much everything's going to start with this that's more interesting a program is decomposed hierarchically this is this gets us to structure programming to top-down this gets us to all of these things that we now associate with it we have lots of choices hierarchical is only one of them so the philosophy here is hierarchy and we see there you go main program subroutine ok it kind of looks like that that's this kind of simple way of looking at it well that's great and we end up with there's actually a structural way to look at this a classic structured program look like this so it tells you a little bit about the the larger scale architecture of this afferent branch transfer ranch effort bunch these these are great terms it's probably one wide this terminology didn't catch on but - it's a great one to just drop in in a conversation because people get it ceiling I want the hell yeah people often confuse afferent and efferent and you know and there's always somebody that effluent it's like no no no no that's just programming so you actually have the idea of input process output okay we are drawing in performing work on this and then output so this is a very classic algorithmic structure so there's this observation there's typically a single thread of control we shall come back to threads of control but that single thread is quite important typically what happens in the a typical situation it's not good I'll give you a heads up on that one each component in the hierarchy gets this control option along with some data from its parent passes along to his children so you can see the philosophy of this is organized around control flows is organized about we take a route task the world's definable in tasks and then we break those down okay and there's a simple mod of decomposition this also tells you the boundaries of the technique perhaps you can't do it for everything that's fine you know it's be very suspicious of anybody that tells you that they have found the one true answer to programming so we have this now it turns out you can start messing about with the names obviously that their terminology of subroutine that's terminology was used in a number of languages honestly in a toss-up between VB and Fortran I'm hard-pressed to say which one I'm going to back procedure ah procedure I don't see is quite good I'm Algol 68 it's quite a quite a nice language and then function which is one we're all familiar with what's interesting here is that you actually find as I said this same philosophy at the base of functional programming at the base I'm going to say diverges they have other other aspects but you actually find there's a significant crossover at the level we've been considering now of course I've given you a tidy view of the world ask me a tiny little fiction because yeah you know we mix levels and there's recursion except in Fortran so there is a notion here that you cannot get a perfect tree but it is tree like enough blocks will form a perfect tree if you need to use a block again outside of the tree you have a number of choices either you copy and paste ck to talk for why you don't want to do that or you say I give it a name you pull it out easily and you're able to and that block structure allows you to ease into that idea where you've now got something that is a something that is cyclic and direct it now when we talk about top-down programming there's this lovely quote from ale and perlis first recipient of the cheering order everything should be built top-down except the first time what he's saying here is quite an interesting one and something I found very useful many years ago is that sometimes when you are trying to build something if you're focusing on algorithms and fire I remember reading a Stepanov piece about this and Stefan off kind of looked like he was saying kind of like yeah yeah you can do this top-down he wasn't using exactly those words it's just that no that's not how it happens well maybe it does and you know but I'm not you know I'm not retired Russian mathematician maybe that's different it's just the notion is that normally what we find is that top-down is a brilliant way of describing a thing that exists because it allows us to think about it and understand it but that may not be its origin story the origin story of these things is often a lot Messier so in other words it's a great way to then do it afterwards or to describe it to somebody hey what does this code do let me tell you a story no don't let me just show you the structure so top-down is a great way of communicating but it might not be the best way of discovering it's also not it's also kind of a tricky thing it's Tony Hoare observed you cannot teach beginners top-down program so they don't know which end is up careful reminder that when we talk about it this very abstract world of programming we use a lot of physical metaphors which are unnatural we talk about level of abstraction higher level lower level what there is no system of gravity in your code if they were us a lot of it would fall to the bottom let's be very clear okay there's no system of gravity you can turn it upside down it looks just the same fact there might be an improvement in single agency cases but the point there is that we use these physical metaphors because that's how we think and so therefore we apply a physical concept but if that doesn't mean that other people are in on the metaphor in the beginning they don't it's not natural to them yet that's a learnt thing so you know there's this notion that where we have these hierarchies we have trees but of course in software we have a slightly different take on trees you know for us it's entirely obvious that the leaves are at the bottom I mean you know really that's one of those things I remember explained to my kids and they're kind of looking at me going it's one of those things of like is this dad just taking the piss or is this actually a real thing in computing you know it's I know really the roots are at the top and the believes that there is you guys you know she's sitting there going I don't go near that profession so yeah we have this idea that these hierarchies are comfortable for us to thinking and so therefore we should favor them where possible and this idea of respecting that because they have these wonderful properties properties of reasoning but also these properties of transformation and so you might be better familiar with thriller and things like that but in Michael Jackson's kind of requirements engineering face he produced some real gems starting in the 1970s the work he was doing in conjunction with the Jackson 5 was JSP Jackson structured programming and his was an ocean of very much how do we decompose a business process across hierarchies and where the exceptions that we need with respect to the hierarchies in the 1980s became your solo career before his main solo career he was exploring Jackson's system design which was very much a case of intercommunicating entities communicating sequential processes as it were each one of which had a sequential lifecycle model a state model and then 90s onwards really exploring the stuff in terms of soft required specifications a very very dull title for a truly wonderful book the subtitle gives you an indication that this might be something else going on here Alexa can have practice principles and prejudices it is alphabetically-ordered it is about 75 essays ranging between half a page in four pages on stuff to do with software requirements and thinking he's got all kinds of stuff in there it's quite a lovely read and the book begins with our bora site which is not a common english word even if English is not your first language you sitting they go out I had no idea that word existed trust me along with the first first language speakers going yeah I'm not familiar with that the murder of trees the victims of our bora side of the descriptive tree structures that are so often found its software holding together many individual elements in one coherent immediately understandable harmony software development should not be a trade of constructing difficulty from simplicity honestly I can just stop the talk right there but you know there's there's a certain notion quite the contrary so where there are trees to be shown you should show them and refrain from turning the relationships they describe into a puzzle his concern is where we can found both data structures and control flow structures and start saying well it's kind of I'll forget that that just add this little workaround and it's just I don't know what is the description but as we've discovered finding that description it's not always easy the first time you do it it's not always obvious sometimes it has to be your second or third time through it we operate in a state of constant surprise and that's okay you're discovering something and how to describe something and then you come back oh I've got a better way of looking at this often that's a bit simpler can it cooks down nicely and becomes more composable so our Bora side then is using a smaller description span when a larger one would be better and often we kind of think of our functions they it's it's kind of good every now and then to remind ourselves of what a function is supposed to be as opposed to the way that when people sort of say I have this mm line function it's just thanks thing I that's probably not a function it's probably a large population of functions okay there's nothing else going on there there's this idea of how would you decompose that what are the decompositions there this and then you look at it and it's made up all these funny small little bits and pieces that are kind of stitched together and sort of a Frankenstein's monster so there's this idea of trying to understand can this be arranged in this structure of the word we're looking at now it gets a little more interesting when we go back to this and realize that they weren't just talking about the general idea of procedures and blocks as you might understand them this quote is from the section of the book by you Lee you hand dial and Tony Hoare hierarchical program structures it's the last section in the book which means that nobody will ever remember it and it's also the one that is least applicable to most programming languages at the time they talk about hierarchical not just data structures but they go way beyond that and what they what they observe and let's just put up a little piece of code here this is sort of it what I've got is an array of books I've got some kind of count I'll initialize the count to zero and then I'm gonna have this with any like you're going oh it's stack yes the most over specified data structure in the whole of computer science and you've got procedures here now this is a reminder than the alcohol family of languages you could nest procedures or functions inside blocks and that's not something that carried through to the C family of languages as a whole you can kind of fake this one up and C++ these days with lambdas but normally the idea is your top level structures functions a top level there's no concept of a nested function two classes which have slightly different semantics we can have nested everything else I can have a block of code that has variables state of its own and then its own nested control structures which could contain blocks and so on and so on you have that kind of approach but here you can have blocks between that begin and end I can put my own blocks in so I've created a stack now what they what they're observation was was fundamental a procedure which is capable of giving rise to block instances which survive its call will be known as a class and the instances will be known as objects of that class hmm you mean like this so if you've ever wondered where the idea of classes came from it's here this is it's this this is similar 67 which is an extension of Algol 60 and it's also one of the languages along with Algol 68 that massively influenced biana in terms of his way of thinking about development but what we've done here is we've taken a block of code with a recognition that normally when you call when you call into a function when you call into a procedure there's a stack frame you push the variables on to the stack they live as long as that you leave the block and they go away but what if that block stuck around one of that block didn't go away with the stack discipline could have an arbitrary life say on the heap and what if you gave that block a name ah now it gets interesting and there's this idea of you have the block it has extra life the block does the block having it it has state it also has procedures ah these are your member functions and it also has initialization code okay that is your constructor there's a whole bunch of other stuff in simulus 67 to allow you to do other things and there's co-routines I hear that C++ is kind of thinking about catching up with the languages of the 1960's we're doing okay so there's a whole lot of stuff here but this is this idea that a block given an extra lease of life outside its normal stank discipline is a form of structure now what is it so this is fascinating is what we're actually saying here is a deeper message that is reflected in we Cook's paper from 2008 the anything that captures closure is the basis of object orientation anything that captures this kind of state and he makes the observation lambda calculus was the first oo language which puts it around 1932 which means that I'm going to do something quite horrible here I'm going to use some JavaScript as we looked enough we've we've looked into programming languages so I think it's time for a break so there's an interesting idea here because what we're actually saying is that object orientation was a part of structured programming in the original vision this is kind of interesting because I can only gets left out the story there's a very simple reason it gets left out story it's the hard beer the back of the book it's the hard bit that you couldn't fake up in other languages there are three main sections to the book one is on control flow one is on data structuring now if you're a Fortran programmer you're already lost at that bit and the third bit is on all this stuff which we're going and what the hell is this 1972 what have these guys been smoking okay so there's a notion here that because but think about it from another point of view it was not unstructured what they were doing was giving structure and they built it out of the very simple idea of the block so what I'm going to say is it very simple a simplified object model I'm gonna have a new stack I'm going to create it's it's just a it's a do everything with Landers we've got an empty list and then we're gonna return basically a Cartesian product basically a collection of stuff four things death pot and push that are bound to lambdas and this is interesting because when you return it what I'm doing is I'm giving you a four named methods I'm not giving you any state it's the ultimate in private state because it's the state is actually part of the function it's a it's a block that's been given extra life and I'm just going to offer you methods this is more private than private okay and so then I'm offering you this and it captures this idea that we talked about and I can change the implementation with effectively the same behavior I can count the I can push to the front or the back of the stack and end up with the same implementation now that's kind of an interesting for a pure object model based on functions so let's explore a little bit L a little bit more about what else is involved in this vision of structured programming beyond the simple control flow view of the world concatenation is an operation defined between two classes a and B or a Class A and a block C in other words you could have this is inheritance and wasn't called inheritance originally it's called class concatenation if you think about it that makes a certain amount of sense the derived class base class yeah I'm gonna take everything you've got and concatenate these extra stuff okay but you could do it with arbitrary blocks so it's kind of interesting that simular actually had fewer rules but was more expressive than C++ in this respect by a very long way you cannot have a block of code arbitrarily inherit a class and please don't put that into C++ 23 of any members of the committee are in the room I'm saying it would have been nice but we are way past that now so we've got concatenation incantation consists in the merging the attributes of both components in the composition of their actions and actually we can kind of fake this work quite nicely by shifting this to a mixing style and basically saying give me a base object and then I will add these behaviors to it okay I will add depths top pot and push and so in other words I'm going to have a stackable capability and so now I can have my stack is it's a stackable I'll start with an empty object it has no capabilities at all pass it in please add stacking and then it gets a bit more fun when you realize you can add other things you can make everything a composition so terrible oh yeah okay we'll do that so a new stack is clearable and stackable it's that kind of crazy compositional thing I was doing with the lambdas earlier that wasn't completely gratuitous although our bit was partly gratuitous but here we have this compositional idea so what just to clarify we're building up an object model by borrowing functional ideas and using them in JavaScript to explain the history of C++ from the 1960s and you're doing this sober so credit to you credit to you okay so I'm going to make that a little easier we're gonna create an inheritance and multiple inheritance operators shoot me now call Campo so this is function composition it's just a reduce and so all of that advice about how do you create how do you create a good inheritance hierarchy I know let's reuse stuff no no no but that's what people have always been doing well they had this crazy idea back in the 70s construction principle involved is best called abstraction we concentrate on features common to many phenomenon we abstract away features too far removed from the conceptual level at which we're working I'm a path so I'm pretty well nail there had some really bad examples in the book as well but we'll give him that and this takes us back in you know going back to the 80s now we'll move moving forward to the eighties this whole idea of conceptual hierarchy and relationships of hierarchies takes us to Barbara Liskov and her 1987 oops the paper date abstraction hierarchy now quick show of hands let's go substitution principle okay right so for those of you who have not come across that Liskov substitution principle we're gonna see it very briefly asked about in the bar Barbara Liskov said a type pirate yes and she got the cheering award of witchery award spotting we might as well do it properly I think it's 2008 for her working language design work on the languages that she worked on date abstract data types but also gave us the exception handling model or the originator of the exception handing model that is more familiar to us now a type hierarchy is composed of subtypes and super types the insure ative idea of a subtype is one whose objects provide all behavior of objects of another type the super type the base type plus something extra and then all gets a bit formal what is wanted here is something like the following substitution property if for each object oh one of type s there is an object o - it's the points like this you kind of think actually the formal notation would have been easier Oh - of type T such that all programs P defined in terms of T the behavior appears unchanged when oh okay this is the paragraph people normally quote when they say this is substitution okay the substitutability property that you want for a derived class with respect to a base class okay basically you use a derive where a base was expected and it does not break the universe is the simple interpretation and that's what they were talking about in conceptual hierarchies and it turns out that of all the solid principles which Liskov is one of so of all of all of those this one is the one that you can actually test so I'm going to add in here an additional mixing non-duplicate top so nose if you try and push something that's already there on the top then it gets ignored okay so now then it creates some simple tests an on entry stat becomes deeper by retaining a pushed item at its top and so c++ on c push 2019 pushed we okay so we've got all of that and then we assert stack step its depth is three and the top is 2019 okay so when we run it against clearable and stackable then it passes it's green when we try and add non-duplicate top it fails so what we've out so in other words the depth is now two because we've tried to add the same thing twice the depth is now two therefore it is not substitutable the idea of substitutability is that you can partly pass the same tests it is pretty much straight out of what this goth was saying however there is a notion there's a small fly in the ointment here is that this cop wasn't actually talking about inheritance she was actually talking about abstract data types and they're not quite the same the behavior of P is unchanged if your program has a change of behavior because you switched out to write a base class for a derived class then strictly speaking it doesn't satisfy LSP which means that most of the examples in the book in books that demonstrate LSP are wrong because they do things like wow we'll just do what the program did before and then add logging I'm sorry your program now has different behavior yeah so it's this is this is hardcore strict LSP anyway that does give us the sense that whichever way we look at it whether we looked at it as strict LSP or softer LSP as we might want it more widely understand it our goal with all of the stuff we've looked at so far is that our code should be reasonable that's it all this and it should just be reasonable okay well quick explanation reasonable in English has two meanings one of which has got completely swamped by the other one and particularly if you are in England people use the word reasonable perhaps a little bit too often I do a reasonable that's just being kind of nice yeah did you have a good time yeah it's reasonable it's okay you're not over committing yeah reasonable is yeah all right but yeah look great I'm too bad tolerable there's lots of words you can sit there and have a competition trying to find synonyms for it however its root we do want that in code but we also want the other one reasonable is something that you can reason about and that is the basis for all of this stuff when people have got interested in this idea of structured program and why people push different paradigms in many cases well sometimes people push a bit different paradigms because it's fun but in many other cases people have a different motive they are trying to reason about the code they have got a mental they're trying to establish a mental model through which they can work so they can think about it and we have many ways of reasoning and there's quite a nice one you he'll put this one in gave me this one for 97 things every program every programmer should know I'm coding with reason and he talks about this idea of semi formal reasoning he says you don't need to do a proof but try to do things that allow you to be comfortable with the pieces of your code look at the code and go yeah I can I'm comfortable that this makes sense I can reason through it so kind of semi formal most of it involves breaking things down into small pieces he makes very clear points about a number of things one of which is our old friend the go to avoid using go-to statements as they make remote sections highly it's independent what I find interesting here is that he hits it right on the nail in terms of the language people often forget I'll go to is just a control flows constructor you know old-timers always complain about it actually let's reframe this in terms of the language of dependencies dependencies are the thing things that are hard to grasp the larger project the more dependencies you have your job part of your job is to organize and manage them to give them some kind of coherent story so that you can reason through them and what we're saying is there are a number of things that mess with our understanding and dependencies that just go across all over the place those we struggle with we slow down we're more to make mistakes when we encounter those they work against the things that we're good at which is kind of clustering things that are together and reasoning through them avoid using modifiable global variables since they make all sections that use them dependent in other words rather than just ranting about the stuff he's actually giving you a very simple reason it's about dependencies that you can't manage that's the bit that makes it hard we've seen that tests give us another way of reasoning through things they give you a certain confidence um tests also have a particular narrative many tests follow sometimes people refer to as the three A's arranged act assert structure I tend to prefer the BDD given when then structure it's the same thing but it more clearly highlights the story aspect Jason Gorman made this nice observation few years back fun fact given when then is what we call a triple last tell you her again that's a that's a triple as it's written now back in 1969 it was the base it was the it was this paper an axiomatic basis for computer programming which followed in the work of robert floyd who we mentioned earlier on this goal was to try and as was written then basically say the assertion P is true before initiation of a program Q then the assertion I'll be true on its completion what we see here this if you come across contracts this is where it all originated but what we see here is that in all of these cases what you're trying to do is get a block although he uses the term program often people did generally and talking about these things a block when you have a block you can reason about it as long as it has very simple if you can guarantee the data flow then life is easy you start on the left-hand side just make sure everything's good move through to the right-hand side if Q is working then you should get the condition the post condition R and so all of this is in service of a very similar aim the ability to reason about different levels of formality now we saw this before as you are well aware there are limits to what we can express with this conveniently perhaps best summarized by this tweet from Lando Calrissian you throw concurrency into the mixer suddenly we're a little bit lost because everything was based on sequence selection iteration what story with this do we have a structure for this what did procedural programming him to say about this well it turns out it didn't have an awful lot to say although Dijkstra was working on this yeah this is the origin of the word mutex by the way I found it it took me ages to find it but I actually found it I knew he coined it but it was it was he never formalized it's a type it was just a variable for variable name for a semaphore we shall use the binary semaphore mutex only for the purpose just described we aim to make the critical sections government X rather short and we won't shader to some critical section is shorter than necessary 1960s advice I really wish some people would still attend - it's just that well you know we make this you know if we lock this then we should be okay at this point and David Bruton Hoff who who wrote the book on pthreads and I've often joked that instead of picking up Dijkstra's cute acronym we should have called the basic synchronization object the bottleneck you know that would change the nature of our conversation you know it's just like I think the code needs a bottleneck right here uh-oh you know that doesn't sound quite as good whereas mutex has a kind of like funky kind of techno kind of oh dear now the point here is what we see what we see here is that this is a very low-level construct compared to all the other stuff that's going on this beautiful block structure and stuff like that this is very raw this is very primitive you know got 68 they had this kind of stuff semaphores it's just hard it just feels out of step for missus hadn't yet caught up wonderful talk by Brett Victor on the future programming he gave the talking 2013 but it was as if he was in 1973 it's threads and locks they're kind of a dead end right so I think if we're still using threads and locks in 2013 we should just like pack up and go home because we've clearly fails an engineering field how are we doing it's 2019 okay so there's a point here that our challenge is that when we look across the landscape we can share or not share our data shared data run should our data can be mutable or immutable and it turns out the there's one really bad quadrant here I've used nature's color of danger to give you a hint now you might observe that in the far east red is often a color of celebration that is also true for consultants this is the synchronization quadrant it hurts here 3/4 the diagram is good but this is just the wrong place this is the procedural comfort zone this is where all structure program and grow up over here mutable data that is unshared that is its strength it's a comfort zone this is its discomfort zone this is absolutely you should not be adding threads to procedurally style code because it's just not the right thing for it I mean it's kind of like running a three-legged marathon it's like it's impressive if you can do it but you've got a few things missing up here if you're doing it ok and I hope you're getting a good amount of money for charity but honestly it's not a way to develop commercial software that is just not the quadrant we want to be in so structure programming didn't originally have a direct answer to this or did it well it was kind of heading there but we ended we ended up getting a sidelight there is an idea of a very simple idea of coordination a coordination language and we can build a complete model out of two separate pieces the computation model and the coordination model that's kind of interesting computation what that means like algorithms and stuff coordination how we bind these together what we're gonna do is we can take concurrency out of the picture this is the direction we were heading that's Nicolas worth but algorithms plus data structure equals programs what we're getting is this idea of coordination plus computation equals programs it's a slightly different take what we're doing here is we're saying that coordination is actually separate and that concept of little pieces of very nicely threaded code single threaded code little bubble it does its job communicates with other things no shared mutable state communicating through queues or other other constructs that was where we were headed and indeed we have a number of different ideas that sort of rather nicely expressed if we go back to 1964 Doug McIlroy observed in a memo we should have some ways with coupling programs like garden hoses screw in another segment when it becomes necessary to massage data in another way and this is the way of i/o also this was the invention of the UNIX pipe before there was a UNIX and in fact before anybody found the pipe symbol it was about six years to find the pipe symbol Ken Thompson found it on the keyboard I said right we're gonna do it we're gonna do it everybody else is vexing over the syntax they should use but if you look here there's this idea that the pipes are the coordination model for UNIX classically sequential programs this is how you express concurrency okay so there you go io and simple idea you can build everything out of this stuff okay you can have a buffer I can have a queue it's bounded it's buffered asynchronous communication don't use infinity it turns out you run out of memory before that do bound your queues otherwise you'll get interesting log messages when things go wrong but it gets more interesting when we look at these limiting cases N equals 1 why would I have a producer-consumer arrangement with a one space queue let me rename it for you that's the future the other side of it is a promise we keep inventing terminology for these turns out there's only a handful of ideas you ever need to know if you know a triple even you know nesting and you know all the behaviors of a queue character you say oh I can build everything this is much better than something like a mutex and if you do need actual synchronization it turns out the limiting case of zero is also useful this is the default model for channels and go an empty zero how can you have a queue of zero it just means you have a rendezvous you have to both be there at the same time it's synchronous and this is the model that Tony Hall was looking at the end of the 70s is this idea of can we take structured programming principles in one sense and express them very functional way that he did it there that was kind of again it was this nesting and compositional approach the same philosophy all the way through all the way through from there to there with that I think that lends some weight to TS Eliot's observation we shall not cease from exploration at the end of all our exploring will be to arrive where we started and know the place for the first time so I hope that's been thought-provoking and lunch inspiring I'm around for the whole the conference if you have any questions thank you very much [Applause] you

Channel: cpponsea

Views: 187,663

Keywords: c++, C++ on Sea, cpponsea, Folkestone, C++ Conference, Conference, Programming, C++ on Sea 2019, c++ tutorial, c++ programming, computer science (field), Structured Programming, The Forgotten Art of Structured Programming, The Forgotten Art of Structured Programming - Kevlin Henney, Kevlin Henney, Kevlin Henney c++, Kevlin Henney 2019, Go To Statement Considered Harmful, block-structured code, object orientation

Id: SFv8Wm2HdNM

Length: 89min 27sec (5367 seconds)

Published: Fri Feb 15 2019

Reddit Comments

[u/victotronics]

I love the guy for keeping the name of Algol68 in the public consciousness. Two-level grammars rule!

[u/Moon4u]

I don't mean to offend anyone, but this is an awful talk. It is most clear in the realloc example. The changed version is much worse than the original one. The original one will let you know right away that the function path ends when you enter one of these if blocks. You don't have to wonder whether the function does some additional changes to the return value - the execution is done at that point and you can continue reading the code, leaving more mental space for understanding the rest of the code.

On another note, if the size of the 'structured' realloc function grew, the chance for an error will also increase due to the increased chance of someone writing code that affects the return statement outside the if-chain and that would end up affecting the rest of your return statements.

Also, the guy claims that the 'structured' variant of the function will be more refactor-able, but in reality, both are equally refactor-able.

The two code functions are equivalent therefore which one you will use is up to you.

I think that the guy is promoting a coding style that he is used to, which in return is based on his original experience with a language that is no longer in heavy use. I don't see any benefit from this coding style, at all.

What's, even more, is that it doesn't really matter. If you are working for a good company these types of semantics will be covered in some coding guidelines and you will not even have the choice of whether to use this particular style or not.

TL;DR: If you have not yet watched the talk - Don't. There isn't anything in there that is worth an hour and half of your time. Just some guy promoting his old coding style and garnishing it with quotes from a lot of books that have little to nothing to do with the subject.

[u/[deleted]]

Great talk!