OO Considered Harmful with Phil Nash

okay so welcome back everyone uh and we’re gonna jump straight in so we now have jetbrains developer advocate phil nash he’s going to be talking to us about oh considered harmful or what was the other one we said oh harmful that was it oh consider harmful so away okay thanks alex and hello everyone let me just uh share my screen okay hopefully you’re seeing that there because i can’t see that anymore and now you should be seeing my first slide great thanks for that okay so oh considered harmful actually before we get to that just one disclaimer um i’ve been doing uh videos for jetbrains all week um my voice is going a bit i wish i seemed to lose my voice quite easily which is a bit of a problem considering that’s a big part of my job but to try and remedy it i’ve been having a bit of extra alcohol and it’s like this narrow window between it starting to have a positive effect on my voice and then having a negative effect on everything else i think i’m just in that window now but if i decline through the talk now you know why we’ll do so talking of things considered harmful i will consider harmful i shall get to that title in a moment um alex has introduced me already as developer advocate jetbrains um i also run a conference a podcast and a meetup and loads of other things but you can catch me on twitter feel underscore nash uh back to the title i won’t consider it harmful sounds familiar so you could probably think of it as a meme or um uh click bait maybe but before we had those things uh we had this idea of like patterns of titles where you just replace some some key words in them we call them snow clones they’ve been around for a long time and even this particular one is probably older than you think uh certainly was in use in the 40s amongst journalistic circles we got to hear of it more in software development circles in the 60s and so you’re probably thinking of go to considered harmful where this all came from just conveniently you just have to stop in those two extra letters there actually more accurately it’s go to statement considered harmful this is actually the the title of a letter sent by uh edgar dexter in 1968 to the um communications of the acm interestingly enough it wasn’t actually the title that dijkstra submitted the letter with he originally called it a case against the go-to statement and it was the acm editor nicholas worth that changed it to what we now think of as a slow clone or a meme statement considered harmful just to get a bit more more readers and it really works i mean everyone knows this article what is letter what do they uh actually normally at this point i will ask the audience if they actually read this this letter and the last couple of times i did it i’ve got a response of about i don’t know 75 percent or more uh say they’ve never read it five percent so they actually read it and remember it and the rest so maybe they read it at some point um it’s a bit of a shame really because it’s a really good article and it’s not that long over i mean here it is go to the other screen there we go so this is about half of it um so it doesn’t take that long to read it’s quite accessible there’s a few bits in there about text indexes that take a little bit of thinking around it just really like your mental position of your process through through the code once you get that it will make sense but there there is one claim in there that really stood out up to me so i’m gonna just focus in on that a bit and read that um he says especially the second of his two remarks my second remark is that our intellectual powers are rather geared to master static relations and our powers to visualize processes evolving in time are relatively poorly developed interesting wording it goes on for that reason we should do as wise programmers aware of their limitations are utmost to shorten the conceptual gap between the static program and the dynamic process to make the correspondence between the program spread out in text space and the process spread out in time as trivial as possible that’s a really really interesting choice of words there and i think you can actually read it a few different ways now bearing in mind in the context here he’s leading up to making his case against go to and we think of that as a bit of a relic from the past nobody really uses go-to’s anymore

except when they do and it was really part of his big push towards structured programming at the time and now we think of structured programming itself is a bit passe we’ve moved on to object-oriented programming this is the mainstream now which sort of subsumes structured programming so we don’t really need to worry about that anymore or do we in fact there was a talk a year or so ago by copenhagen called the forgotten art of structured programming it’s a great talk uh if you haven’t seen that i encourage you to watch it there’s actually a reasonably good chance you have seen it because last time i checked which was this morning on youtube it had 163 000 views which if you ever look at the view counts for the technical talks from technical conferences um particularly c plus conferences which this was that’s a really high view count there’s only a few people that ever get that so somehow this got caught up in the the youtube um algorithm uh so lots of people have seen this but if you haven’t do check it out it’s a really great talk you make some really good points in there in uh a way that only kevin can do and uh i have a bit of a confession to make here because when i was originally researching this talk i’ve done a few times now when i was originally researching it i knew that i was going to make references to one or two of kevin’s talks he’d done a number of great talks but as i got into my research i realized that like every point i wanted to cover kev known how to talk for it it’s like he’d always got there first and it was a bit like that south park episode where they found that no matter what they did the simpsons had already already done it first but in this case it was kevlian heavenly kevin henny already did it so this is actually good news because this talk is very sort of high level concentrating on the philosophy and how all these things linked together but i’m going to touch on lots of very deep topics which i’m not going to be able to cover in any depth at all especially in the time i have here so what i’ve done is i’ve put all the references and links to lots of other talks and blog posts and articles lots of kelvin headings talks into a page that i put up on website and i’m going to give you a link at the end so watch out for that so that now gives me permission to just skim on the details so you have been warned let’s actually get back to cover what is o or is it well we know it stands for object orientation but what actually is that and you may think you know and in fact you probably do but there’s not like a single definition of what object orientation really is and it’s evolved over time so what we should really do is go back to the origin where did it all come from and most people agree that o.o really got started with the similar language back in the early 60s similar one came out what’s interesting and slightly less well known is that there were two versions of the first similar language well there was the very original similar one we now call it and then there was a revision in 67 so similar 67 there were later revisions as well but these two languages are so different that it’s worth thinking of them as completely different languages when we talk of similar as being the first ooo language which i’m really talking about similar 67 not similar one but similar one did actually started all off and this is part of its untold story i think so similar one came out in 1965 and it had one big concept in it that itself evolved over time but came to be called a process the process in similar one is basically a function that has three points to it a run a suspend and a resume you may find that familiar if you’ve done any programming with co-routines in one language or another it’s basically what this is a similar one process is like a co-routine you can run it you can suspend it you can resume it they can’t run concurrently you can have many processes in flights at once but when you suspend one you do that by running or resuming another one so that they’re running a bit at a time so they do cooperatively multitask if you like but there’s only a single thread of execution without very much like code readings what’s interesting is that when they came to revise this in similar 67 the language became so successful that it moved out of what was essentially a research phase into the mainstream and so they decided to generalize this idea of a process into something that they called the class sounds familiar in fact we go back to to this i’m quite finished talking about processes

what’s really interesting about the process here is because it is just a single function how do we get object orientation out of that how does that evolve into what we now think of as a class well if you think of co-routines curatings have state the state is what’s local to the function so local variables in a function become effectively member variables of some object that’s running the code routine which is often how they’re implemented that also gives you a form of encapsulation because anything outside of that function doesn’t have access to those internal memory variables or local variables just as they don’t have access to local variables in a function now in other languages so you’ve got uh an object there you’ve got encapsulation you’re already starting to see the seeds of object orientation so what was the process in whoops what did that happen press everything this wrap with that yeah see if i can speed through that okay there we go so back to here so how did that process in similar one evolve into a class in similar 67 in fact in similar 67 you still had processes um but they were just a type of class they were very much pushed to the the sidelines in simulator 67 the class was really the focus and classes and similar 67 start to look a lot more familiar a class can have subclasses so derived on child classes they can have variables member variables or fields procedures or methods and virtuals so a form of polymorphism you can call a method on a base class and have an implementation on a derived or subclass called so again very familiar what it didn’t have at this level was encapsulation at least not in similar 67. apparently a later version of similar did include hidden protected which is what we now think of as private but that came later at this point even was public it’s interesting that in a way similar went backwards on this because similar one had encapsulation but at 67 the first real object-oriented language didn’t have encapsulation but in all other respects it looks very familiar as a no language here’s an example that i pulled off of the internet there’s a link at the bottom there should be my references at the end if you want to look it up um so i’ve never written a line of similar so i trust that this is correct but it looks very familiar you’ve got a dog class in fact i like the way that similar does inheritance you put the uh the base class name before the keyword class if you look in the middle there so dog class chowa so quite a nice way of doing it the um methods suggest procedures and uh you declare virtual is up front it seems like a bit of a verbose way of doing uh virtuals but the the comment there does suggest that they may be specific to the the sim or kim compiler which i think is part of still part of gcc actually it’s a front end so that may not be part of simula itself but let’s not get bogged down with the details it’s not talk about similar i just wanted to show you how we got the roots of our own so we have polymorphism we have inheritance but we don’t have encapsulation now similar is part of a family tree so similar itself was a strict superset of algol which came before it um in fact it’s so strict that the first version of similar started off as just a macro front-end for algol and later they had to branch it and write its own compiler uh because they wanted to add some extra complexities but to all intents and purposes you could write um completely uh valid algorithm in similar so a direct descendant but there’s another line of algol that was of note through cpl bcpl and b which we don’t hear of too much these days except as direct um successes to our predecessors to c saves the next important language in that line of the tree so not picking up any ooo features just carrying on the um standard procedural features of algol but then they converged again with c plus plus so c plus plus got its basic syntax from c but it’s oo ideas from similar and merged them into a single language now when i originally gave this talk it was to a c plus plus audience

so we sort of stopped here but obviously there are other languages that have followed on in the c plus plus tradition uh particularly java c sharp and then other more recent languages as well i have their roots here but i think it’s fair to say this is a fairly um good idea of the important early our languages and their influences there’s a couple more i want to throw in there also derived from similar we have small talk which goes off in a different direction and i4 which goes off in yet another different direction these are all oo languages but they do that very differently and it can actually be quite interesting to see what ways they do them differently and why we’ll look at that in a moment but also interesting there’s another convergence here objective c was a version of c which grafted on elements of small talk the oo parts a small talk on top of c a strict superset of c again very different take two c plus plus and almost a forgotten language until apple brought it back to the limelight in the early 2000s so we’re going to consider that as well what i want to do now is to stack these languages up and i’m going to consider for these purposes small talk and objective c is essentially the same and just look at some of the own features and how they’re implemented so quite the basic ones classes inheritance polymorphism they all have those features some differences in the way they implement inheritance so similar small talk objectives say they all have single inheritance only whereas eiffel and c plus plus have multiple inheritance now after i’d originally done this slide i realized that what i hadn’t done is distinguish between implementation inheritance and interface inheritance or interface implementing because they’re often conflated particularly in c plus plus um they’re actually quite different often languages will have single implementation inheritance but multiple um interface inheritance uh that’s probably the best way but if one form or another all these languages support it uh let me come to encapsulation it says similar didn’t really support encapsulation except version one in that very limited form and then later i think similar 87 did have it but then the small talk line an eiffel had an additional idea which is not really found in the other languages and for many purists this is considered maybe the the primary feature of object orientation that everything is an object even classes are objects and you can instantiate an instance of a class type as as well as the class itself and do things with it pass it around it’s an interesting idea it has some interesting consequences and particularly leads to the next feature that’s unique to those languages not unique but unique in the context of these languages we’re considering and that’s message passing this is interesting because this is actually how these languages implement polymorphism it’s very different to the way c plus plus and c plus plus derived languages implement it much closer to um what a dynamic language would do so it’s worth just considering that for a moment just to illustrate what i mean to talk about virtual dispatch like c plus plus java c sharp those sort of languages if you have an object has a method and you want to call it you get a pointer to a function and you take a pointer to the object itself the uh this pointer that you pass as a hidden parameter and you also for virtual dispatch have to look up in a v table what the actual method is because your pointer is only to the bottom of a v table or virtual table that will then tell you what the ultimate method to call is so you have a couple of indirections and a couple of extra pointers to to pass in it’s not too bad but there’s a bit of overhead and a bit of jumping around which is not particularly cash friendly so there are some drawbacks to this message passing starts off looking very similar you have an object you want to call a method on it what you actually do is you pass a message to the object to say i want to call this method with these arguments the syntax may look very similar but that’s what it’s doing and the object itself gets a chance to say

hmm what do i want to do do with this by default it’s going to call the names method and similarly it’s going to pass in that pointer to self in this case so the end result looks very similar on the default path but you get lots of extra opportunities this way just to summarize them so it’s very late binding so the object actually has a chance to change what’s going to get called at the last second and it supports what in objective c is called method swizzling languages like javascript and ruby call it monkey patching so this ability to change what methods actually get called when you call a particular method by name so you can get it to call something else instead similarly you have runtime delegation patterns one good example of that is when you construct a uh so in objective c if you create a string the constructor or initializer for the string will actually look at the string itself and decide what the best implementation is going to be to implement that string whether it has unicode characters whether it’s short or long whether it’s going to be long lived and it will actually create a different instance and then patch that in to the object that you get back like i said it’s a very powerful form of polymorphism even on construction it’s also easy to mock so mocking as in the the testing approach where you say well this this function needs object a but i want to give it my own version of object a that behaves in a in a different way that i can test on very easily very easy to do in a language with message passing much harder to do in a language with virtual dispatcher but virtual dispatch has its uh pluses as well it may be more efficient i’ll just say there’s there can be some problems with there and i mentioned things like cash locality which are much more of a problem now than they were back when these things were getting started and that’s the problem these things change over time when decisions on using virtual dispatch were made that may have been the more efficient way to do it these days it’s much less clear and in objective c i know that they’ve been optimizing that message passing interface to the point that the default path is typically about the same overhead as virtual dispatch but with all the extra capabilities that gives them so the efficiency argument may not hold up too much you may also get stronger type checking because i say message passing is much more like a dynamic language but again in objective c you get the best of both worlds because it still checks your calls against an interface type it just gives you a warning rather than a hard error so you get most of the same benefits as well as the extra flexibility so not looking too good for virtual dispatch based languages when it comes to polymorphism but wait there’s more there are other ways to implement polymorphism type eurasia is another one now i don’t know whether this as a concept or as a term is very widely known outside of c plus plus circles but certainly that’s where i know it from mostly because it’s a very low level way to eke out extra performance from uh polymorphism which means be less of an issue in other languages i won’t go into in detail just to point out some of the the benefits it’s uh it’s non-intrusive in a way that with um with virtual uh virtual method based inheritance you have to encode in your type hierarchy that this is a polymorphic hierarchy type erasure gives you those benefits without having to do that it’s definitely higher performance because it gives you more optimization opportunities it’s compatible with value types so again rather than with a uh virtual method based polymorphic object you’re typically putting things on the heap uh when you’re copying you’re copying references or pointers uh they don’t look like look or work like values whereas type arranger gives you value type objects we’ll talk a bit more about that in a moment and it supports something called concept mapping which again i’m not going to get into too much but this is something that swift actually has as well just built into the language and lets you map a method you call to the method that’s actually implementing it which may be a different method with different arguments so very similar to the delegation patterns in something like objective c type erasure can give you that as well so in most ways type erasure is better than virtual dispatch if the language implements it as a first class part of the language that’s great if not there’s going to be

some syntactic overhead even that’s not the end of it some types are another very popular way of implementing polymorphism you say plus plus there’s a stud variant swift and rust and many other modern languages implement them as a form of enums so if you’ve not actually come across some types yet you can think of them as like enums where each value in the enum can have additional state depending on which value it is it can have a different layout different structure this is a really powerful way of doing what we might call closed form polymorphism where you know all of the the types it might be up front as opposed to the open form of polymorphism that virtual dispatch gives you uh even kotlin has it with uh cell class hierarchies and pro probably the most common form of some types you might see in different languages are optional something which either has no value at all or has the value you actually wanted but you can also have more complex versions what we call discriminated unions so these are like those those enums we talked about they could be one of several different types so some types are a useful alternative to the other films of polymorphism we’ve talked about they have their own strengths the others have their own strengths we can’t definitively say one is better than the other so ideally you want a language that supports multiple forms of polymorphism just for completeness more of a c plus thing but things like templates and concepts are another form of polymorphism in this case compile time rather than runtime the point is there are many different types of polymorphism most of them are not associated with our languages polymorphism is a powerful concept and approach to programming in its own right and the forms most commonly associated with lo it turns out are probably the least capable forms of polymorphism uh rich hickey who created the the closure language he likes to talk about polymorphism a la cut which uh which close closure implements this is just saying well but we implement all these different types of polymorphism you pick the one that’s right for what you need it for most demo languages don’t do that you get what you’re given all the trade-offs are baked in that can be a bit of a problem so polymorph isn’t good io’s version of it not so good what about encapsulation though that’s got to be the killer feature of oh everyone agrees encapsulation is a good thing but remember that the very first version of simula had perhaps a very basic form of encapsulation but otherwise didn’t really have encapsulation in the form that we know it today we still consider that the first ooo language that’s not really essential to owe but it is nonetheless definitely a valuable feature just to be clear what we’re talking about here is the ability to hide or make inaccessible uh parts of your your state so that um you can only modify it or access it from inside your class but i want to draw your attention back to dijkstra’s original statement that we looked at right at the start where he said that in his second remark our intellectual powers are rather geared to mastering static relations and our powers to visualize processes evolving in time are relatively poorly developed and then he talks about shortening the conceptual gap between the static program and the dynamic processes i don’t know but when i first read that i wasn’t thinking about go-to’s what it made me think of was mutability mutability is probably the number one thing that makes the conceptual gap between the static program as you’ve written it and the dynamic process as it runs different things when things are immutable they tend to stay the same that’s literally what it means but we were talking about encapsulation what’s this got to do with that well consider this date class very briefly since a plus plus but it should be easy to follow yeah the year month and a date you have a constructor constructor that takes those in but also does some validation and then you have these things down here methods that we might call accessors or getters and why do we have those there we have those errors so that we don’t expose the underlying member variables to the outside world

and we do that so that we can maintain the invariant that we establish in the constructor once constructed this data is always valid we don’t want to break that by letting anyone just change the internal representation so in this case we’re just giving read-only access if we wanted to provide the ability to set those individually we might have additional validation in there we could do that as well now if you made that states public instead then that invariant wouldn’t be enforced but if you also made those values immutable for const that problem goes away because now once the data is constructed it can never change and that’s usually what you want now it’s only part of the value of encapsulation it also gives you a level of abstraction so you can change the internal representation without changing the interface to the outside world but definitely half of the points of encapsulation and i’d say the more important half goes away when you make things immutable so that’s interesting now i’m going to rush through a bit because i think i’m actually out of time um i wanted to talk very briefly about a an immutable string class that i’ve talked about in another talk there will be references at the end and the point of this is to come to this slide where we actually split this string class into two parts an immutable string and then a separate type called a string builder which lets you mutate the string by having those in separate types the mutable string always gets the benefits of all those invariants but we move that implementation to a builder type in order to mutate it when we need to so we’re using the type system to maintain our invariance just get limited we’ll just limit the scope of that mutability so we don’t have time to go into that in more detail now if you do want to find out more about these things there’s another toolkit i’d recommend as well also linked in the references at the end um which actually talks about value oriented design in an object oriented system so just to sum up very quickly how can we get the best of both worlds or the best of all worlds uh my recommendation and having to skimp on the reasons why unfortunately but just to sum up at the low level down at the nuts and bolts the algorithms i prefer immutable value types and that implies working with persistent data structures again another big topic we won’t get into magnetic operations yes i said the monad word you don’t have to understand monets at a mathematical level to appreciate the value of the operations builder types like the string builder we just talked about functionally composable algorithms a lot of functional stuff here and that’s no coincidence i’m quite big on functional programming at this level but then at a high level i think this is where oo principles are much more applicable components with encapsulated state maybe even going further with active objects actors even co-routines which in a way they’re all the same thing so going back right back to singular one at this high level this is probably where oo shines and with that i think i’m going to have to finish leave you with that link to the references on my site levelofindirection.com slash refs slash oo dash harmful.html i’ll try and place that into the chat but if you have trouble remembering levellivindirection.com i also have extra level of indirection.com that redirects there so that should help and i’m going to come out of here and ah it’s over there stop my screen share and pass it back thank you very much thank you um does anyone have any questions no oh wow okay uh yeah thank you for posting the um the link in the chat as well uh i think i’m stuck on here right now i can’t hear us let’s talk about him nope can you hear us now first time my airpods have actually died while i’ve been using them sorry about that

that’s okay that’s the joy of doing things online you have to try everything out and have it recorded um okay well i think we’ll finish it better uh thank you i’ve ever really i need to get a laugh track left right all right um so thank you everyone uh just do a quick outro thing uh thank you to our speakers victoria vikrants every time rebecca vickery and phil nash uh to all of you um yeah um so our next one so this is obviously last one of 2020 uh so our next one will be on thursday the 7th of january and our talks are going to be access denied disabled guide to accessibility accessibility online by lily deadman which i’ve seen her do this talk some another thing and she it’s amazing so definitely worth if you if you work with web it’s really useful um and then we’re also going to have an introduction to behavioural data collection by steve steve cobin smith who i think ever talked for us earlier in the year or last year um yeah that should that’s everything could i just uh interject oh yeah uh because i did talk to you on twitter about um offering to use remo yes after this um so just to let everyone else know remo is a it’s another video conferencing tool that’s particularly good for little group chats so i’ve found it’s really great for socializing at conferences and other meetups so actually set up a session that we could jump into after this if you want to carry on the discussion thank you i’m just gonna close the video now one sec