Behavioral Programming: Aligning Code with How We Think - Luca Matteis - DDD Europe 2020

[Music] [Applause] great so yeah my name is Luka Mateus and first of all I wanted to say how grateful I am to be part of this conference to be talking in front of so many people that I admire and just yesterday I think and dinner I sat next to Eric Evans it just happened because it was a speaker's dinner so I was really really happy about that but so my talk is a little bit I would say different than what I've heard so far in the sense that I'm going to talk a lot about coding actually so and the main thing is so it's this paradigm is called the behavioral programming is the main thing that I'm going to talk about and I'm going to go very much in detail about how it works it's a very specific way of programming it I would say and but before I do I will actually wanted to say that's it's it's something that I I've been interested in purely because it's been a passion of mine so it's not something that was driven by maybe the my company or I've never made money off of this it's just been my pure passion for the past two years and so the subtitle of this talk is aligning code with how we think because the the paradigm is all about trying to think of programming in a different way so before it starts the the the problem that's this paradigm or this architecture is trying to solve is the idea that we've been sort of you know over the past what 50 years or more we've been invaded by software right software is ridiculous it's everywhere everywhere we have software and I think the main problem is going to come already we're seeing this obviously in an industry research everywhere we're seeing how software is really hard to understand that it's hard to change so I kind of want to concentrate on these two dimensions understanding and changing and it's a way of analogy I think that the future is gonna like we're just at the beginning and a way even though everything is pretty much automated but I think in the future we're gonna have so much more of this you know everything is gonna be driven with robotics and you know space travel whatever and I'm and the damage I have here is actually planet Earth right now with what those yellow circles are are the sort of space debris that is surrounding our orbits low-earth orbits and I was reading an article about how actually it's it's becoming it's going to become such there's gonna be so much space debris that it's going to be hard for us to actually send rockets into orbits because they're gonna eventually hit there's gonna be so many that it's gonna be impossible for us to sort of escape the earth and as a way of analogy I think who were sort of maybe reaching a point in software developments where things are so complicated to understand in terms of code that it's that it's we're hitting a similar kind of points where we either you know we do everything from scratch or we're stuck with what the mess that we have so the idea of this paradigm is again to try to make the situation better right so to understand and to change code in easy way I'm just a simple outline of the talk is so first I'm going to talk a little bit so I'm going to dive really into detail so forgive me if this is gonna be boring but I want to send a message across across as I feel very passionate about this and the second part so I'm going to kind of step away so I'm going to try to go into details of code and go a little bit upwards again abstract all the details away and think about how we think about complex systems and then we're going to see how maybe we can align the way we code with how we think and finally I'm going to end with some research because all of this is actually coming from quite respected or well-established researchers that have studied this subject so it's not just me obviously I'm actually just taking I've done pretty much nothing I'm just taking what they created and presenting its and then of course some cons because all kind of new paradigms have some cons and a little bit talk about the future I'm gonna be it's gonna be kind of a challenging discussion so okay I mean the section I'm going to dive really into details so please bear with me okay don't fall asleep but essentially behavioral programming the word behavioral stems from how we think of things like object-oriented programming for instance where even though object-oriented programming has a lot of baggage right it's it's a word that talks about a lot of things but in essence the the when we were doing object-oriented programming the main units that we use when we're programming are these objects rights and essentially one vision of one explanation of how object-oriented programming works is this fact that we have these objects and they mutate each other okay so there's some states and calling methods of another class of an instance satiric sorter and of course there's a the sort of the big brother were the yeah the big brother of object origami was which is functional programming which sort of continues on this idea but everything should be sort of functions right that so the main unit so what I want to concentrate here on is the fact that the main units of programming in one way is an object in functional programming its functions and to continue this Solarian functional programming everything it was pure and the mutations are sort of put as much as further possible away from the thing that you're building right so behavioral programming continues on this wording and and in essence forgive me for the the image that I created but in essence the main units are not functions and objects anymore even though of course you can use them but the main units so the main things you use when you're programming are its is called be threats which actually stands for behavioral threats and the research and these are much they're essentially very close to what our real-world scenarios so the things that we talk about you know when we talk about our business were when use cases you can also call them stories and here I'm depicting them as these lines because they obviously they cross these these boundaries you know whenever we talk about specific requirements or use cases it is in my opinion very common to cross boundaries between say your you know you have to okay change the authentication module and also the the the components and the UI right so these are different things that span multiple domains I would say and this is how we talk usually about requirements so I was going to say that I'm going to dive into these very very much into detail but essentially here this is a screenshot from the paper about to behavioral programming and the way that it works is essentially that's so we program using these B threads right and these are these yellow boxes here on the Left essentially all these B threads are running and parallel okay so that's one thing to remember and they can essentially do three things okay they can request for events and there's you know triggering or proposing that you want something to happen in the system then you can wait for an event so you can sort of listen to what's happening and you know in the real world or you can listen to what's happening within other B threads and finally and this is actually a crucial difference is the fact that you can block events and read and it's this idea where you can sort of stop things from happening either in the real world or another B threads so this is the general mechanism and then there's a an event selection mechanism that figures out what needs to be triggered so just to show you how this actually works the here's an example of a B thread it's never mind the language never mind the sort of syntax but what is importance and the the point that I want to make is the fact that we we are essentially using these requests waiting block so these are the main things that drive this approach okay and here we're essentially what we're doing is it's a simple function and also want you to pay attention to these sync calls because they allow other they allow B threats to sort of peek and two other B threads and figure out what's going on okay so two to go again and to deed so I'm going to try to give you a very basic example okay so let's imagine we have a simple program right and this program takes as inputs a number X okay depicted here as the constant X but it's reading the inputs and this program we want to we want to understand whether it is multiple of three okay so very basic you know never mind this is purposely simple okay just to show you did they add this example but what's happening here okay so we we read the inputs and of course if it's multiple of three we return true otherwise you return false most ago remember now imagine we want to change again this idea of trying to change the complexity stems from the fact that it's so hard to change the off to right so imagine we want to change this program what we do literally is we sorry so the new specification or the new requirements is that we want to also check whether it ends with the digit five very simple requirement very stupid requirements but just as an example so to do this of course this is the only way I you can do this change right you can you have to go in the code change that if statement you change the condition to also check put an and there and then have the function to check also whether it ends with did you find pretty straightforward right now with behavioral programming again we go back to the examples so here we're going to work with events even even the program before worked with events but again these we have these Sync calls and this is really the this the combination of these sing calls and this request wait and block is what sets this paradigm of parts from the thing I just showed you right now so we have this function and here it's an infinite loop and what happens is that here on the right we have an event trace so here essentially when we execute this program using this paradigm this yellow line is depicting the execution step so it's going to of course stop at this step in the function because it's waiting for the advance number it seems pretty clear I hope what happens is that when in the outside world or whatever we see that on events of course that matches number the number is is obviously matched and execution continues because of course we found that number and that because that number is 6 as you can see and and the parentheses it goes to the next step of the of the function in which case it enters this if branch because the mode is multiple of 3 is true and at this point again we have the same step as before this sync call and it's requesting good ok this is there's nothing surprising about this so this is I'm still not at the interesting parts so forgive me but again the the the program is simply as you can see from the trace then the input of the program was this number 6 and the output is good so I just told us that 6 is a multiple of 3 right very basic now let's go back and I'm sorry I'm done of course that goes back to the other statements so now let's imagine that as we did before with the other example let's imagine that we want to introduce a change and as before the change is with this we also want to check whether it ends with the digit 5 and so here the difference is that instead of complicating the module that we just wrote with the by adding you know the new and and in the conditional we are essentially making sure to the to the software by simply adding a new a new module okay and this new module is very similar to the one we just wrote they run in parallel but of course the only difference is that in this statement right one is checking if it's multiple three and the other one is checking whether it ends with digit five yeah nothing surprising and here I can continue the execution as before right maybe as a number four input we got five this time what happens is this yellow line is now connected and I'll show you I so again number five makes both of them run in parallel they both move through their own states you know the one on the left goes inside the else branch because five is not a multiple of three and the one on the right stays in the first if branch because it is a multiple of five okay but now the line is connected and I as I showed you before it's these sink calls allow you to pick and see what's happening and other modules and this is exactly what's going to happen here what's going to happens that they're going to all see their their sync statements so in this case one of them is requesting the one on the right is requesting good because it's in a good state for for itself the one on the left is requesting bad because it's in a bad state but because it's also blocking good as you can see here that's the important parts it's going to essentially output so the system is going to output bad ok so again sorry if I do a little bit too much into details but I think this is really important the idea here that I'm trying to portray is the fact that we were able to introduce a change to the system without complicating existing code okay so the you can imagine that one on the left was developed maybe by other teams or another person why do we have this thought and software that whenever we want to make changes we have to complicate or add things that don't really pertain to that use case right the one on the left is before I was thinking about the multiple three why do we have to complicate it with this also there the fact that it ends with five so we have this interesting separation again here I have sort of zoom out you know as a program this is a very simple example obviously well you can imagine a program being written with thousands of other modules and on the on the top I depict these modules as being sort of they kind of look like a bookshelf where you can swap them and swap in sorry swap out and swap and these these modules and they all communicate using this yellow line is invisible yeah line that is controlled by these sink calls and intuitively the system that I just described you into it's a very simple example what happens is that we can have new modules and we can sort of indirectly change how other modules work right so here's the text shows you know as goals are refined and requirements added to the program or even when bugs appear because you can even do the same trick with the bugs so rather than enhancing and often complicating existing modules we strive to add new modules that precisely address the difference or the gap between the goals and what the existing systems accomplish and I have another example but I think I want to I want to bore you to that but essentially here we I'm gonna go to the other part which is more abstract and interesting but I have a similar example so I have this program that it has the it's trying to control essentially the knobs of two like water hearts and water code and it's trying to produce water and in this program and at this state the output of the program is essentially that whenever the waters is low it's going to trigger three times hot so it's gonna release three times hot and it's going then after that is going to release a cold read three times and what I'm what I'm doing here this is the important parts is I'm adding again a new requirements a new B thread that wants to change the system and this B thread is called actually interleaved because with this a logic of sync azam and request waiting block what's important is to see the vent rates we are essentially interleaving the to add hots and that cold without having gone inside the old modules and without having to sort of complicates the way that they worked they still remain they still work as they did before so again the said year of increment allottee where we can change code without going back okay so I sorry I finished the deep dive took me almost 20 minutes but now I'm gonna sort up with this sort of intuition about how the system works with these kind of modules that weave through the program I would say so I it's interesting because this is actually this is a quote from a her al the David Harrell who's actually the rate one of the originators of this approach and he's essentially saying that in this approach the modularity is not necessarily achieved by the structure but can be done by these behaviors or in these B threads so you don't have to think of the systems behavior as being chopped up into objects or components or tasks you can kind of chop it up any way you want according to the way do you like to think about the behavior and here I'm trying to depict kind of the high-level differences of this approach where you know we may think of a system with low on the left you know with low cohesion high coupling which is something we don't want and okay the next best thing what is it is a high cohesion or low coupling obviously but this approach is really kind of I would say unrelated to this it's there's these threads right these lines where they weave into one another they overlap each other they intersect and they maybe say things that forbid other things and again this idea that certainly this idea of behavior versus structure so at the top is this behavioral system where we have sort of like a bookshelf where we can plug in new new behavior as we as we wants or as we see fits and on the bottom is how we do it nowadays you know we have these modules that create these really complex structures and we kind of have to modify these pieces and if we want to change something it's like a Lego building you have to take it apart and make sure the new pieces fit with their surroundings your surroundings so a lot more complicated so here I have just to let me drink and take a break I have just a couple of videos my friends were like you should put some of videos to not worry the audience entirely and I actually I'm pretty up-to-date with these kind of videos but because I followed this Twitter channel and I but if you if you think actually it's not the cat is ok honest you saw it I'll show you again the cat is perfectly OK but if you because they always land on their feet so it should be fine but if you if you think this video is a little bit of it if you think this video is a little bit about animal cruelty we can go the opposite direction where actually what happens here is that the sorry the dog is going against against the humans okay so um maybe now I want to back off right so I I did a little bit of deep dive so the second part of the talk is how we think about complex systems okay and I have this year just as sort of a reminder that's I think in our field sort of I'm sure there's a lot of developers here right how many how many how many people write code lift the hands so almost everybody so I actually think that coding is is not really a science so which I explained that a little bit I think it's much more I'm not I'm not saying that it says cool as I'm being an artist but it's kind of what I'm trying to say like you have essentially here I'm trying to depict it better but right so but we're essentially a craft because we're driven by emotions we're driven by people that like certain things you know I may be more into like I have you know different psychological baggage and I like to program and code in a specific way my my colleague that is reviewing my code has a total different history but and we expect sort of us to work with the same tools and paradigms I think it's a lot more like like painting in that sense where for different people specifically here I show an example right so there's so many architectures right there's so many patterns romantic so I making both their behavioral programming the thing I'm talking about just to show you okay how is this different from all the rest right it's just pick and choose whatever fits your through your character and in fact I'd argue this is what we mostly do it's very emotional right like maybe the person here on the left is more imagining they have more of a scientific backgrounds so they want to pick specific patterns or architectures that are aligned with their way of thinking and on the right man do we have a more creative person you know there's more into music and they like to read things that maybe they like you know event-driven programming or proxy or other things you know so many of them so why is this approach how does it stand out you know and so again instead of having these hours sorry these arrows in words so having all these paradigms and we have to pick and choose whatever fits are essentially our brain if you think about it or even our problem obviously but I actually think that the problem becomes secondary I usually pick and choose the paradigm based on our personal preference it's very subjective so what what if instead we do the opposite what if we just kind of think about what is the paradigm the best fits or model of thinking so we kind of find a common what is the common ground that we were all sort of our minds work like you know even if you're a creative person or attacking whatever technical person and then we kind of build it so bottom up instead of being top-down right and if you if I can give you an advice is to read this paper it's called the quest for run we're on compositional and executable and intuitive models it's an amazing read I think from 2012 again by this professor called David Harrell and a sophomore on and her L is actually the creator of state charts if anybody is interested in the charts has been in the fact of standards for the past thirty years its visual language but anyway so we have this dichotomy right so she depicts this mountain I think it's a very good analogy because so on one side on the rights we have us humans right and on the Left we have the computers right so it seems like softer well software developments is a constant effort of trying to dig this tunnel and what I mean by that or what they mean by that is this the fact that we have to sort of whenever we have to program or whenever we have to talk about computers in general we sort of have to think like the computer right we have to change our minds to think like the computer instead of so we dig the tunnel towards their direction why like why can it not be than coming towards us more because they're you know computers are intelligible systems we can make them do interesting things with the artificial intelligence they can can do more things like this okay so to to show you how we can actually so sorry again now here I'm I'm going to try to not think about how we code hmm I'm gonna try and think a little bit about how we develop systems in general or how we sorry how we think of systems without kind of even without a computer even though I'm gonna draw the analogy so to do this I'm gonna try to discuss how we develop how we would develop a tic-tac-toe game okay and on the top left I sort of depict the requirements world so these are the people that kind of are non coders you would say and then on the right implementation world and I think this is the economy of sort of you know the behavior versus structure which if you can keep an eye on what I when I talked about the B threads before there's a lot of analogies here obviously so but anyway and it's also important that I'm at the time because as things happen even in the requirements world we see if things change drastically in the implementation world and I'll show you this so we can we can say that you know for this game you know the first requirements would be to detect wins you know very simple you know when a player places places three of his or her marks and in a horizontal vertical dad and why the player wins very basic right an implementation world also please do keep an eye on the colors so they're color-coded you know we create a bunch of functions or objects or whatever as we continue with the requirements you know enforce turns of course you know the structure on the right and the implementation becomes or conflicts here it's already quite aligned you know I wouldn't say that it gets too complicated but obviously you can imagine I don't know if you can see the color if you can sorry if you can see the colors so every time we add a new requirement what happens is that maybe other section of the structure have to change obviously to sort of fit this requirements right and we end up essentially so this is the system finished we end up intuitively with really two different worlds you know on the Left we have these documents that talk freely about the system and they're quite detailed these requirements so I mean for instance the one the last one talks about how you can foil an attack you know so you prevent an X from from winning or I know from winning by pulling and putting it's in the right box but it's quite just at a glance so the first thing that comes out is that the requirements they talk about a specific thing is contained so you know start at the center is a contained piece of information whereas in the code it's lost in my opinion it's lost in the structure so for instance the the pink one the last one is we find that in the center at the bottom of the left you know at the top so imagine having to sort of figure out where that requirement how can you figure out whether a requirement is implemented in a system or an ounce I mean it would argue it's really hard nowadays right it's okay another apparent difference I would say is this idea where so the requirements are actually I would say they're quite independence and what I mean by this is again going back to the B threads every time I mention these things of you can go back to the examples I made in the beginning but the requirements on the top left they're not connected by any arrows there's no arrow aligned connecting any of them so this was when I first saw this was like yeah that's interesting right why is it that we sort of there's no code or independence so I'm gonna forget the deadline it's just to of course a visual distinction but the idea is that there's no action whereas in the implementation everything is connected and the reason it's connected is because the structure has to abide to the computer you actually mechanics in the computer work so the computer has to execute your function there is a call stack subroutines state all things that we are used to thinking as normal and they're not really a stack trace does not appear in the requirements world it's it's a relic or the historical I would say mistake obviously but you know it's it's big it's there because that's how computers work okay but it doesn't appear in the requirements and again this idea where abstraction does not imply hierarchy so we have this thought that whenever so abstraction I mean the idea of when we abstract something away so removing details to better see the large picture okay that's my definition of abstraction and again in the requirements world even though this is a pretty simple app or a simple game I would argue that there's there's no none of these views in the requirements world none of these views or the requirements there's no hierarchical connection between them so even though the for instance the the start at center circle starts Oh at center is actually quite specific and quite low level there's it's not hierarchically connected to other views okay whereas in the implementation world in the structure where we have these objects functions and code there obviously are there's there's this hierarchy and one of the most important differences I believe I hope I can explain this is this append-only idea and what I mean by this is it's quite this is quite important I think like a really so the idea is that again in the requirements world new requirements are piled a top you know there's no components interface between the requirements there's no connectivity there's no ordering they we kind of whenever we want to change the requirements so imagine imagine you have a pile of requirements on your desk right if you want to change how the system behaves you don't you kind of writes the new change that you want the system to to have and you kind of put it on top on top of the sort of you know list of the requirements that you have you don't actually go and the paper find the section change the wording but that's actually what we do in code okay so again this idea where we can on the left were adding a new requirement this is a change we want to stop the game after one pretty simple change and on the an implementation world it's quite different this this change requires us to peek and look in different modules as you can see again for another requirements and one of the last important differences I would say between these two worlds is the fact that there's this idea which I call upfront negativity okay so it's also hard to explain but imagine imagine you're able to so in the requirements world what we can do is we can say I want the to stop the game after the a win okay now the interesting thing is is that we can say this at any point of the developments we can even say this at the very beginning even before having to start even before we wrote any line of code that involves the game logic we can say okay I want the start stop the game for it so imagine this sort of this is quite interesting we cannot really do this in a code we have to again this is a saint's change or implemented in red here these red boxes if you can see them we this change cannot be up front there would be no arrows connecting these boxes or to a little bit of heart of a concept to understand but imagine we have these I can move to the next one which actually explain this a little better it's this idea of multi modality where we usually in the requirements world were able to specify what must sorry we specify what mate what may happen so what may happen in the system okay the the red ones we can enforce turns we can start at center we can see the squares taken and then and then we specify what must be done and what man must not be done so essentially specifying these two things will constrain the execution of the program and this is again going back to the block of the B thread that I showed you in the beginning and this is its shows also in the way we do requirements we first specify perhaps the constraints imagine specifying the constraints of the program and then building on top of that that's I think very powerful and again overall there's this idea of the natural programming right symptom innocence feels natural is this idea that it modules are kind of interweaved right how show you the year with these laces and another example is this you know me we might have a module doing taking care of a trip the directions another one of the day schedule and the day schedule is stopping the car it's really it's driving again but it doesn't it doesn't connect directly to the directions order interleaved in the in the same way that I showed you in the beginning with this yellow line and these sync points and again so if now we introduced the behavioral programming to the system that we just wrote we can see that these requirements as they're added there there are very much lines so this is the implementation world okay so and this is actual code that runs and works I have a at the end I have some material you can actually use it on a web page and what I like to highlight is all the things that I talked about you know the fact that they're in them in the implementation world but there's no sorry they're all independent in these units they don't there's no arrows there's no there's no really no structure actually so there's no hierarchy they were done in this append-only kind of fashion the same idea as requirements and this idea of also upfront negativity so you have a small video of the game in action and by upfront negativity here is the fact that as you can see the users placing but now they're trying to spandex of after another action and this essentially is is being enforced or blocked by this threat so there's this idea of upfront negativity so imagine implementing this in the normal way I would argue that's you cannot do this up front you have to go inside the structure figure out where they're always drawn and conditionally put maybe an if statement around it or something like this here I have another video of some temperature rising a simple UI so there's an increase of 10 times and events increase it's called 10 times and rises to hundreds there's also decrease events now let's imagine there's a new requirements the pops in and says I don't want the increase to happen immediately I want him to happen with sort of a throttle time so it kind of gradually increases in grudge so instead of going instead of going inside the code that we just wrote or even instead of knowing anything about the system I can write these these to be threads that essentially block the increase after a certain time and the effects are essentially what you want and here I have another simple video of the essentially a simple web app where you can you can see some movies and then click on them so you read the reviews all written in this kind of behavior programming fashion and what it really is interesting about this is that here you can see the trace of events that happen within the system like you know maybe the the person clicked the movie rendered in books page the movie is highlighted etc etc and what's important since is that at any time a developer can come in into this project well even knowing how it works and it can use the trace and say okay these are actually these things I don't want them to happen and I they can simply take those lists of events that they don't want to happen and they can write a B thread dedicated for that use case that actually blocks that list of events you don't have to go in the structure and figure out okay where does this do not happen whereas over okay so just to conclude I want to go kind of here again this is from the paper run where that I think is really great but if we think about how our brain works so I can read this a little bit so there is essentially no modification of existing initial memories no insertions no cut and paste only more and more experiences okay so there's no insertion no kind of paste so images seen something since heard pain felt or all amassed as new memories and are connected to existing memories in more ways than we can imagine today some of these of course explain refined correct reorganize or completely replace things that were previously experienced or seen or heard or read and how they affect the future behavior so of course it's very similar to to the things that that I've talked about rights but I think what's important here is the fact that our brain really does not have insertions and copy and cutting paste we have which is are things that we do in programming right we whenever we have to change or whenever there's a new idea we have to go in the structure cut and paste change it with something else instead our mind obviously works quite differently than dots okay so just to finish on some resources and some some thoughts and have a research section if you want to know a little bit more about this paradigm you can simply google search behavioral programming and then Harrow it's the name of the last name of the professor there's a lot of restrictions so and it's actually so this one is theoretical where they study the request weights and log model and they actually prove that it's very it's a little bit more since smaller and state space where the technical people on the right there's actually a little bit of empirical evidence which is interesting coming from software moments we don't have a lot of empirical evidence but essentially what they do is a small study with the high school people where they so high school people don't really they had they have no programming backgrounds and it compared the system with a traditional programming system and the results of course are a little bit biased because the the creator's performed but they were in favor of actually something like this behavioral programming and of course there's cons so what I did is over so I told you that this has been my passion for the past two years and I've written some articles so sorry articles some blog posts essentially and I pulled I don't know if you know this websites called hacker news so there are very valid comments when I posted these articles they commented in a very I would say realistic way and some of them are talking about how the fact you know this can be cut these all these threads all these modules together can be can they can become a big ball of mud right so it's complex and convoluted it's impossible to understand right this is a general theme how can you understand and in fact I agree with this and what I can stay here so what I'm trying to say here is that so this approach comes with some cost right for instance as I showed you in the beginning if you remember this idea of two modules being as multiple of three and ends with each of five so having these two together and the same function is very easy to understand when you're debugging but having them in different modules where it's a lot harder personally actually is very true and it is it is a con of the approach but I see this more as a trade-off so in a way it's kind of trading control flow for extensibility and at the bottom I kind of tried to depict this trade-off which I think to be honest should be applied to any kind of architecture right so this idea where all architectures work with whatever is your problem it's not I don't think it's not true because I feel like if I work for a start-up I'm developing software in a completely different fashion that if I'm working for NASA right and because it startups re experimenting you know they want to develop something quickly put it out there and let it test from the users and then kill it this room is possible if it's not working right so something like this I feel something like behavioral programming to be specific I feel as much more appropriate sin a world where there's requirements are changing constantly which feels a lot like you know startup world so it I feel it would be more appropriate to Peter to put a have it there where something like NASA as an example you know it's something rocket science if you're building software for a rover that has to go to Mars you want something maybe less that doesn't change often you need an architectural better you know connecting two dots and a little bit of words about the future and then I'm almost done but there's some other things like for if you want to get into detail about this approach so the the sink point that I've talked about in the beginning it's not just this idea of request waiting and block but it goes there going even further there's active research on this right now where they're actually using constraint solvers to figure out how to have the be threads precede their executions and this is quite interesting because what happens is that the computer is faced with most multiple possible execution paths and the way that it chooses one path instead of the others they show that it actually it involves sharing certain properties that are a little bits I would say you wonder if it's kind of like the free will of computers but and then there's also graphical languages for this actually life sequence choice you can you can so each one of these boxes these three boxes at the center is one B thread that represented visually let's say and there's other ways to combine it with this other language called state choice and I want to end I have 15 minutes but I just want to end with this idea of what I call actually this is my own nothing I'm research about this huh but this idea of what I called chat oriented programming so let's imagine that's we're developing software it's not about having to go through an artifact that we call code so every time I want to make a change to a system the always this code in the middle right we have to we actually use the piece of code when we have to open an editor open the code and the code so the changes that we make in this structure this graph represent the changes that we want the system to have right I would argue that maybe in the future possibly with something like this or they have a programming or something else who knows I'd argue that we can have we don't need this artifact anymore we can we still need the code we still need to code but our relationship with changing and also understanding the system it's not gonna be through a two-dimensional piece of code it's gonna be it's not gonna exist anymore in my opinion it's going to be much more of a chats so imagine you're the person on the left you're the programmer and on the right to have the computer so you have an interface that is much more like a discourse and I'm not talking to this course in terms of natural language processing okay not at all I'm still talking about code but you're sending the system code instead of changing a large structure and in this case for instance imagine you want to tell you know you're observing sort of on a vehicle what's happening in the softer of a vehicle and you ask you know when the driver presses the brake pedal delight should turn on and you encode this as a B thread where several B threads at the bottom you have the sync points right and then you send this to the system okay as it sort of chat message which is based on code and then the system comes back with a visual I don't know maybe a plots a live plot showing you okay these are the times that had happened that I found it happen when I did some you know when I ran the system a thousand times I found these are the points and there's red dots where it happens and you can interpret this graph as meaning something like does it also apply when the engine is off and then you say no of course through code and you can add this conversation I'm not gonna go into detail but you can say you know why didn't the brake light on go on so the only way we we currently have so you answer a question like this in my opinion is again having to go through the code that's of course we have documentation we have models we do but at the end of the day the devil is always in the details so the language the programming language is the barrier to understand what is happening within the system and why do we have to fight our way through the structure right why not have this sort of discourse where you ask okay why why did it happen okay tell me using another interface you know so this is what I envision the future to be like for software developments and I can skip this that's pretty much it this is just a final idea about our L again we're the units of specifications are not assembled in detail like resistors or chips on a computer board we're methods in an object-oriented programming language it's this interweaving of these modules that will there will be sort of the you know the actual program and I want to end again on this slide because yeah it becomes with the system in my and my opinion it becomes a little bit less blurry if you're starting to think in terms of what your use cases or your scenario do we even need this boundary is a proton across across these systems so yeah this is pretty much some further reading I wrote these three articles myself but again all the things that I I wrote are entirely based on on research done by these two professors and other actually people I think they're based in an University in Israel that's called yeah why is Munny University and yeah that's pretty much it thank you thank you for listening if you wanna if you want to have any questions I think yeah we have a few more minutes for questions so if anyone has a question we have a mic box in the room Christian we would like it than the mic box for the video can you hear me yep I was just wondering how testing paradigms change using behavioral programming sorry testing paradigm yeah just how you would go about testing your program how that would change if it would change or how it would change in this new way of thinking sure sure so I would say that testing is a little bit of difference for sure I would say that testing a module independently so the idea of unit testing is a little bit unclear because what happens is that of course once you put it in the system there could be another module that changes the way that it works because that's the idea so I would argue that actually unit tests are a little bit more blurry how to do them so that's probably one of the cons I would say but in terms of the testing in general you can still test the whole bunch of be threads and because that's your program and you can just test events as inputs and as long as the system produces outputs other events that you expect there would be serve your integration tests I would say but it's your Agri I agree with you that it's a little bit blurry how to do the unit tests sure thank you hi there um my question is is there ever been anything built that's more than trivial any program so there's Fermi per from from me personally no that's very but there is a a lot of research yes so the the preferred the team of researchers they have built a lot of the things like even low-level things like web servers hi this highly this distributed actually sorry not the Troubadour high-frequency web servers with a lot of requests coming in and entirely using this model and they have a paper that goes a lot and it shows you the code and goes into detail about the pros and cons so yeah but nots I would say maybe your question is more in industry not in I haven't seen a company use this I don't use this to work myself I just gonna ask a follow-up question sure how would you say that you deal with removal of behavior let's say we know about technical depth and we know that there's something in the model that does not fit reality anymore and you would want to get rid of it sure I understand if I watch this that you never ever remove anything it's just edition but how does that scale yeah so essentially you can think of it in two ways you can think of it either as if your model changes in the real world I would argue that it's better to make sure that your B threads are aligned to that reality however it's true that you can go ahead and change the the module in the same way that our brain works right you can go ahead and tell the system about how the new model works or they I'm sorry the new world works and you can do that without having you can also do that without having to go back and change the B threads and you can do that simply by saying okay I want to stop these things from happening sort of with I guess with the block semantics and that's gonna essentially the B threads are gonna stop working but and there's maybe and ways to optimize optimize that where they're removed from the system entirely and then your new B threads which represents your new reality we'll simply function and make the system work the way you want it but there's still the questions regarding deaths for sure thank you hey one last question maybe nope okay no one thank you thank you again [Applause] [Music]

Channel: Domain-Driven Design Europe

Views: 655

Rating: 4.7142859 out of 5

Keywords: ddd, dddeu, ddd europe, domain-driven design, software, software architecture, cqrs, event sourcing, modelling, microservices, messaging, software design, design patterns, sociotechnical

Id: 1oKzTrq0gMM

Length: 52min 23sec (3143 seconds)

Published: Wed Oct 14 2020