 So new words and some new metaphors for um, oh look there my speaker notes that goes over Make that full screen and Very very nice look at that. We only wasted like five minutes which is There it is good Back on track totally so yes some new words and some new ideas about some familiar words Some new metaphors for thinking about Drupal and really systems of general A belief that Drupal's complexity can be mitigated But also, you know that doing so is really paramount to the health of the project and That doing that work reducing the complexity of Drupal is Drupal's highest calling It is the thing you should aspire to when you have mastered all of the other things and maybe before Honestly, this is this is also kind of implicitly. I mean don't have it on the slide But this is also a talk about what's killing Drupal There are a number of prominent community members who have left over the years because of the basic issues of complexity that Drupal has and My goal is to kind of try to help us get a handle on them understand them think about them better much of this talk is really happily and proudly stolen from this talk by Rich Hickey who's the creator of the language closure the talks simple made easy can just get like a show of hands Yes, he's amazing and so is closure. Thank you Steven show fans who's heard of rich Hickey or has seen this talk Cool. All right, so this talks amazing It's not redundant to see that talk after you've seen mine like the base definition of the same, but He goes some very different directions his talk basically amounts to an argument for why you should only use functional languages So that's not very useful for this crowd. So I read that today. Nevertheless, I strongly encourage you to look at that talk It is it is really really quite quite good but He starts to talk as well. I By talking about word origins so It's a metamology real quick Two words simple and easy simple Comes from the Latin simplex or simplest simplex means really like quite literally the two parts of the word mean one fold or braid It's opposite of course is complex And when we say one fold of raid this can be a little bit You know sometimes people picture something which is like folded once what this is really expressing is Unarity of of the thing so it's unfolded think about like, you know, we have duplex apartments. That means they have two levels So simplex is one Easy easy is actually a little bit harder to derive good definitions good good etymologies for I have two up here ease and ice the first is Middle English And the second is is old French both of them Have a lot of different senses to them, but the the key one Is this lack of effort idea? Characterized by by lack of effort. There's actually also another one that Hickey found which He says it's questionable. I agree. I couldn't really find a linkage But it's a Jason's which is Latin and is the root of our word adjacent and the most salient Definition out of that is to lie near so this might be a little bit of a stretch, but it works really well for the talk So I'm gonna use it the opposite of easy here is difficult. I don't really deal with difficult too much in the talk It's really much more simple and complex and easy that want to talk about so Easy again to lie near So there's something implicit in this very definition right to lie near there There needs to be something that it is near basically in agents me Many ways easy is Relative and subjective It's not something which is about the thing itself. It's about my interaction with the thing how near is The thing to me and when we talk about easy in the in the concept of of actually, you know working with software Really a lot of what we're talking about is how Near is it to my current understanding my existing skills and knowledge? How much effort is required for me to gain understanding or mastery of it or at least to be able to use it? honestly, we're pretty obsessed with with With ease as a general we see it all over the place Wissy wigg is a funny little example of this especially this nearness idea, right? Like Wissy wigg is designed around the idea that people have a picture in their mind from using Microsoft Word for however many years That's what editors are accustomed to it is near to their current experience and therefore we have a whole Practice and pattern of design that says I mean technically you could do wissy we go the ways but the conventional wissy We get it there is oriented towards Making an experience that is near to what folks who've been working in board documents are accustomed to Develop module is actually it's a very different kind of example of of nearness, but still still useful to think about So later on on the talk I'm going to talk about I'm going to mention a module that I wrote called hook a laser but When I was discussing it back in in Prague last year with some folks somebody said oh you should really make that a part of develop module and I had this like immediate knee-jerk reaction This is before I'd seen much like these talk and I didn't quite up the words to understand why I was like Revolved by the notion of putting it inside of develop But I now understand it was a Discomfort hello discomfort over the idea of it being bound up with other stuff But the reason the proposal was made in the first place is because putting it in develop makes it easy for developers Easy it is near to their sense of where they go to get tools that support them as developers They don't have to learn a new thing. They didn't have to think about a new thing. Oh, it's just packaging. It's easy I take one action and that's that's fine package managers You can think of this is like what you do, but you know your OS level you're young your app You're whatever or you know for pulling in libraries for a for a project that you're on composer Gem things like that Either way, these are these are tools which take a whole bunch of Discrete knowable actions and just bundle them up into something which is easy to do and if there's a nearness to them You could say it's near to the skill set that we have which is bumping around on our file system on the command line and running some Commands or turning it even into ui's that you can use to run these same Commands the point is it's proximal to what we already know and had experience with we don't need to know how to compile Something we just need to know how to like run the script that compiles it for us simple So I said already right simple simplex one fold or braid and this oneness idea is is really important. It's Here's some examples of of the sort of oneness that I'm talking about the idea of like One content type something having a single responsibility or role or goal. There's just one concept in player There's just one accessor dimension Here the key thing that is really patterned across all of these individual things here is that there's a lack of interleaving We don't have multiple different roles or responsibilities interleaved together when you have something that has two jobs It's sort of split brain. They're they're interleaved together. It's it's got two faces things like that Simple is not just about pure oneness though because there's also if you have a content type and you have One note of that content type you don't have much more complexity if you have one more note of that content type one instance versus five One operation versus ten like if it's a known type and having more of them doesn't really make that big of a difference That's cardinality Simplicity is not about cardinality for the most part. It's really about this interleaving idea But the most important thing here is nothing that what I have just said has anything to do with any person Observing a thing Simplicity is intrinsic and objective It is not how easy it is for me to know it or use it or whatever It is a property that exists independent of human beings even existing at all And this is really really important because this is why simplicity matters when it actually comes to building large things But he doesn't Yes, good that's sort of freaked out for a second. So here is this metaphor that I really really like complexity is braiding And then a couple more words for you complex. This is a real word again rich Hickey found this This is it's like super archaic, but it is part of this whole same, you know root series of words complex means to braid together or to make complex Decomplex is something that I like to use a lot Hickey doesn't use it so much in his talk, but it's basically the inverse to unbraid or to tease apart The really useful thing I think about this metaphor. I mean like look at those braids, right? You have six steps where you go from four discrete items into one thing You might be aware that there are four individual threads inside of this because you have some foreknowledge of but if you're just looking at this You have all this stuff bound together. You can't deal with just one thread at a time You have to deal with the entire braided bound together construct and that's the essence of What you should really be thinking about when we're talking about complexity? I want to focus on one thing, but I can't because it's Complexed with all of these other things. It's bound together And this is contrasted with composition again very literal definition Composed to place together not to bind together, but to place together figure one here up in the upper left like that's Stuff that's composed. It's placed next to one another It's not bound together. They they they you know you could still use them as a group, but It's not Complexed together The thing that I don't have on here, which I should sort of say is complexing don't do it, but it's you know Again a big difference between my talk and Hickey's version of this talk is I'm not quite so critical of complexity Maybe is as he is I think there's an awful lot more acceptable complexity out there, which I'll get to in a bit so Why does all this matter I? Mean you know we sort of know intuitively that like clearly, you know complexity is not great but I want to break that down a little bit more like how is it actually not great So this is a quote from the legendary computer scientist Ezra Dykstra Simplicity is prerequisite for reliability So Complex systems are unreliable Obviously, it's what he's saying. There are too many possible permutations too many possible different behaviors context In which they're operate things that they're sensitive to for us to be able to predict their behavior for us to be able to rely on Them and expect that they will behave in the way that we can we often even can't know what to expect to behave out of complex systems It's actually funny too to say that because that's like inherently a human observation right saying I can't rely on it Because I can't even understand all the ways that it would behave because of all the different things that it takes into consideration All the different ways that it's bound together. I can't even picture all of its inputs That's a little bit of a subjective thing But what that's really highlighting when you look at reliability in that sense is that the most important thing when it comes to Dealing with systems and managing complexity Programming in general is your ability to reason If you do not have the ability to reason about the system that you are working on you cannot change it reasoning is an absolute requirement to be able to do any sort of Even marginally complex change marginally worthwhile change to any system that you might be working on If you can't reason about it You can't work on it the amount of time it takes you to reason first reason reason about something is Directly is the direct predictor of how much time will actually take you to solve problems inside of a system Which is to say the complexity is the primary limitation on our ability to reason now it's a I Feel like one of the things we often do is We have workplaces. We have colleagues We know who of our colleagues are really really good at dealing with Hard problems complex problems and those who are maybe not so good And it's really easy to get sort of stuck up in in that and in the relative capabilities of of people And to sort of imagine that well, you know like that that complexity is manageable There's folks out there who can who can take care of it It's a really really bad mentality to take because So imagine we have three people right we have Robert who is a moderately good coder whatever deal with dealing with with complex problems We have Jamal who is like an excellent excellent coder highly capable of dealing with complex problems and then we have Pooja who is the most Ridiculously savant incredible person at dealing with complexity in the problems that she's trying to deal with That has ever been known to man. So it's like Robert Jamal and Pooja somewhere up there, right? the difference between Robert and Pooja is Completely insignificant in the face of the complexity that even a novice can create by using Tools that are already complex which is to say our ability to create complexity is completely unbounded Our ability to deal with it is very very bounded We want to think about how to build systems that can actually be used and reused and reused and rebuilt upon We need to keep in mind that we as humans are very limited in our ability to deal with complexity But unlimited in our ability to create it and in systems when you build on top of each other You inherit all of the complexity from the lower layers. It doesn't go away ever That's the other thing about simplicity Simplicity versus ease right ease goes away ease is a since it's about me and whether I've learned this or not whether I'm accustomed to it over time ease goes away simple and complex never ever go away They're intrinsic properties of the system that we built so But all this said like it is important to emphasize, you know simple and easy are both important like and They're both difficult in in in their own ways Nobody is going to use systems that are if you're pure pure simple systems Then great have fun off in the RV Tower building, you know things that nobody can ever touch or use because they're way too I conic and perfect and whatever for anybody to actually figure them out. So yes easy is important It does need to happen, but the thing is I mean I said earlier I think we're obsessed with ease right like you give me a script to do something Actually, no, I think the best one is y'all seen the shirt that says Go away or I will replace you with a very small shell script Right, I told me to get one of those shirts but Even like minor Optimizations in in my ability to do my work small scripts that I might write things like that are kids Just like it's an inordinate amount of happiness that I get out of it It's it's honestly It's stupid how like happy I am that I'm saving four seconds at a time and a couple of keystrokes, but I do I love it so Easy gets a lot of attention by default. It's sort of immediately gratifying to make something easier Simplicity not so much Simplicity is Challenging to actually chase after it requires effort and thought in a way that just optimizing what you're doing right now Can get you a long way towards easy simplicity is is much harder both are necessary so The crucial question really I think that that we need to be asking a lot of the time is Because we can go and we can learn and we should learn how to identify the complexity that we're creating But the crucial question is once we've identified the complexity we might be creating the systems that we're building Is it acceptable? What is it that's complexed together by this system that I've built does it matter? I'm gonna ever need to tear to tease those apart. Would anybody else ever need to tease them apart so The thing about this though and the reason why it's worth emphasizing simplicity is because Simple things usually can be made easy simple things often actually end up being verbose There's a there's a thing where somebody somebody looks at at something and this is one of the most common ways I think that we We confuse simplicity and ease somebody looks at at something where there's like a bunch of individual items There's a bunch of different sort of things and they seem oh, this is this is complex. No, no It's not necessarily complex if those things aren't bound together They represent distinct concepts if they are all discreet ideas by these definitions It is not actually complex it might be far from your understanding, but it's not necessarily complex the thing about simple things is Even if they have a whole bunch of individual items that you know people look at them and they get overwhelmed Simple systems can usually be made easy you can put things in front of them that make interacting with them easy It's simple that make easy the tasks of working with the system whatever it might be, but the reverse does not hold Not at all Just because something is easy doesn't mean that there's some wonderful simple system behind it easy is Relativity or experience and often what we do is we just find something which is and this is the most dangerous pattern We do this a lot in Drupal. We find something which is complicated Or a task or some set of things which is complicated and we're like oh, I'll just make it easy So, you know, we build a little layer that rolls on top of this bunch of complexity Make that easy and then oh somebody else comes along a little bit later and does it again This and we just end up building these continuously more Complex systems when we don't focus on simplicity first Now I've some very scientific graphs here. You can see they're well labeled and everything like that There is there is a place for for ease Here we have blue is because I can't figure out D3 and I'm totally a again a professional as we've been discussing Here in this talk today easy blue and symbols red So you look at this totally totally completely 100% accurate graph then You'll see there's there is this period where at the beginning of a project and think of time is basically the life cycle of a system of project whatever as it goes on Over the life cycle of the software ease becomes less and less useful your velocity decreases your ability to actually achieve Changes decreases because in the background there's a whole bunch of complexity that's been that's been built up for a purely easy system Simple on the other hand tends to be slower at the start and then over time Your velocity increases you get more accustomed to it. You've built the little appropriate easy things just for For what you need to accomplish and it's great. It becomes productive now there is a there are plenty of projects for which It falls on the left side of that connection point, right and who cares really like don't make it simple Just spit the thing out there, but for anything where we are actually trying to build a system that will last which we need to update which we need to change and Think about Drupal is I like to say that Drupal is a system for people who don't yet know what they need There's an awful awful lot of Changing that we do down the line is requirements evolved and expectations of all so we tend to have with Drupal projects That line tends to go on for a fair ways That's how good not sure how good an idea easy is and in that kind of case This is another way of looking at the same general idea though So here we have coolness of shit versus effort and skill and again simple red easy blue So easy systems like they're flashy, right, you know, you get cool shit right away That's why they're all the awesome screencasts about now, you know in four lines. We do Amazing things we build the internet there's an amazing screencast for this thing called sequel on rails Which is like five years old, but I always think of it whenever whenever I think of this they they build a search engine in Just 57,000 amazing lines of sequel and it's it's fantastic But this is a point is you know, it's flashy and it gets our attention because we like the idea of things being easy to get Started with but over time That doesn't last what what that's really saying is actually if you want to do increasingly cool shit You're gonna have trouble if your system is really really easy based It does not scale well into that simple things let you build really cool complicated things easy things don't buy in large There was another cute thing there. Yeah, well, I can't remember. Oh, right. Yes. Yes What this is really saying is that easy systems let you rise Meteorically to a level of mediocrity and then they kind of just keep you there You have to put more and more effort into accomplish anything. It's really worthwhile I'm almost done with these. I promise like general things about simple and easy. I'll get to something concrete This is Another way of looking at this really easy is about since easy is not about understanding the system It's just about, you know, producing a result of particular tasks something like that easy. Let's replication happen very readily I can go and I can do the easy thing and great I I Repreform the task that somebody else thought through already But if you want a generative system something that can really make new things you need something that is simple Which has parts which you can recombine it allows transformation And then of course because simple can often become easy simple will also enable replication just might take a little bit more work One more quote It's from another legendary computer scientist Tony whore There are two ways of constructing a software design One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated That there are no obvious deficiencies. I Love this quote. I love this quote And I mean for sort of the obvious reasons but also because it says we need to be Just remember the thing right like complexity is the enemy of reasoning Complexity is the upper bound on our reasoning What he's really saying in the second half here is that he's he's reinforcing this idea that like well I've reached my capacity to actually reason about the system. So Deficiencies are not obvious. I can't just look at it and see them I would need to go through and do a bunch of work I would need to grind away to figure out to just Decomplex the parts in order to figure out whether or not there are any deficiencies It also highlights that you don't really get As he says there are two ways of constructing a software design kind of an implied agent there You kind of have to think about wanting to do simple in the first place It's hard to walk back towards simple if that's not where you started almost to concrete I would just want to quickly relate this to some Common concepts that you probably already heard and sort of re-express them in these terms Who sort of solid object-oriented design principles, right? So this is a set of set of principles They are the single responsibility principle the open-close principle the list of substitution principle integrate or interface segregation principle and dependency inversion, but no, let's just talk about two Interface segregation is the one that says you should define interfaces for the minimum possible set of methods that define like Basically a single responsibility. It's very similar to the single responsibility principle sort of more practical That I mean if you recall on my original on my original simple slide I said one responsibility is one of the key ideas that goes into actually making something simple This is a practical application of that that says in order to make a simple system In order to do or solid says interface segregation make it simple Make the interface is simple do not complex them with other responsibilities dependency inversion says don't rely on Concretions rely on abstractions don't rely on a class rely on an interface allowed, you know Allow the implementation to be swapped out for something that says it does the same thing by its interface that That's a little bit of a different Complexing idea, but for that I kind of like the the sort of the visual of tendrils inside of my code base That when I rely on when I rely on When I write a class and invite if I make it rely on on another class another specific class and not an interface I've sort of just reached out a little tendril over to that class and grabbed onto it But by relying on an interface. I don't there is no tendril reaching out from my code It's the same sort of Complexing binding together thing and of course there's a Unix philosophy to small pieces loosely coupled I have a little thing that does just one thing and then if I need to send it to another thing That's fine. I pipe it together and it's just a sort of series of things That instead of being complected together Sort of below the hood you just get the small parts and you can complex them for your purposes Just the one time and or do in order to accomplish your goal It works quite well now. I put dry up here That's don't repeat yourself and code code reuse because I think it's actually an interesting red herring It's one of the problems you've seen in your core But the notion of dry that you should reuse code as much as you can If you don't apply that idea with care, then you'll end up reusing code You'll end up refactoring that underlying code a little bit and suddenly its Responsibility is going to start to drift if you are not really rigorous about what this code does Then you'd be like I don't want to write another thing I'll just tweak this a little bit now all of a sudden this thing has two faces and then four and then 12 and then Whatever Be careful with dry It's way better because again as I said before like simple sometimes quite verbose Just because you have a lot of code that is maybe a little bit different They are serving really different responsibilities if it is simpler if it is uncompleted to keep them separate and have a little bit Of code repeating do it much better decision ever a little Tenderly thing so alright, we're gonna get a little bit more concrete now finally and this is where I like really diverge from from Hickey like I said he makes whole argument is is Simplicity in the inputs and Well, I'll I'll I'll thanks amateur for this He's not he's not incorrect like Inside of this very useful way of looking at complexity Yeah, if you have simpler inputs, then you're gonna have a system that's gonna scale, you know much better into In the sorts of complex projects you might want to do and like heat that he hates things like variables We couldn't really have a useful conversation about that, but they're mutable state. We'll talk about that in a second So instead, you know, I'm gonna focus on things that are a little bit More practical and useful for Drupal challenge with that though Of course is that Drupal is already so Complexed together so many different ways that hey surprise surprise and to talk about complexity It's hard to find an example of complexity. That's not so complex that you can't put it on a screen and talk about it Yeah Sort of a catch-22 there, but I have a couple I would also love folks afterwards like I would like to continue giving this talk and I would like to improve it quite a bit So folks have examples of like things that are stuck together and you know this when you go in and you know I want to just work on this thing and then you find yourself Well, I can't do that because I have to do this because they're stuck together And then I can't do that because I have to do this because they're stuck together the expression for that By the way is shaving the yak You go and and in order to do the thing that I want to do I have to shave this yak first. Well, right That's when things are complex together So right if y'all have examples of things in Drupal that you run across that are complex together Please give them to me perhaps I'll have them to this already too long talk so Off you go. I want to sort of start out with an easy one and talk about global variables We all know the global variables are bad. Yes. Yes, not your head. Yes. Good excellent global variables are bad, right? Full agreement Global variables complect your code with all other code in your PHP process Marc Sahnbaum gave me a quote from he didn't remember where yesterday about this which is to say that basically every global variable that you have is an implicit argument to every function in your entire code base so, you know, if you wouldn't write functions with 10 or 15 or 20 arguments that you don't ever use why would you use global variables? I totally should have a little visual visual of that of like parameter list just going off the right side of the screen because yeah That's what a global variable is. It's available to every function. It's essentially an argument to every function Interestingly though, even though they are a complector. They're definitely a complector. They bind all your code together They're actually I think in practice They end up being a little bit less risky because the failures kind of tend to be obvious like when somebody messes with When somebody messes with a global variable The things that are dependent on a tend to sort of Tend to tend to fail quickly and obviously so we notice them fast, which means they're sort of not as not as risky overall They're really really wicked easy to use I think which is obviously why we end up using them and in a very small application where there's not even that much difference between The global scope and like your local scopes. It's not that big of a deal But of course, they're hell for testing. You can't really swap them out PHP's deficiencies being what they are you can't like easily spun up other processes or control them or manage them You can't mock them out or anything like that. They're just global. They're there in PHP. So can't really work with them The real issue with them though, like I said, I was gonna talk about state They are a more general problem of state and truthfully a lot of Drupal's problems actually come down to problems of state If you don't like thinking about state, I'm sorry I don't really like thinking about it easier because it hurts because state is terrible and state complex everything state in general variables they complex value with time what that means is You have a variable. It has some value and at any point during Serving a Drupal request that value can change When there is only one possible value that can be there you're uncomplexed with time It doesn't matter what time it is. It's always just that one value But if it's variable if it can change if it does change that it means there's a whole bunch of different states that that variable can be in over the course of the request and If your code checks it at one time then maybe it's this value and it checks it at a different time Maybe it's this other value. Does it expect that it changed? Maybe maybe maybe it should change over time Which means now you have to write an if statement inside of your code to see well If it's this kind of thing then I do this and if it's that kind of thing and I do that and then maybe So there's a third state maybe a fourth or fifth and your stuff just starts getting longer and everybody else starts Yeah, this is what state complex with time means when it has multiple different states that it can be in you incur more Responsibility you have to handle every one of those states for your code to really be correct and safe It weaves into everything that touches it everything that touches state and any anything that can be mutated has to To be fully correct, which is often more than we really need to to aspire to It needs to handle all the different possible states that things can be in I don't have a slide for this, but I'll quickly say One of the things I was considering putting in is if you have setters on classes the expectation being that the class gets created and Then you'll pass in some additional value set our injection I'm gonna pass in some additional value you're mutating that object states And if it's a really important thing that that like object needs in order to do its in order to do its primary Work then that object actually has at least two states in which it's in it has I've been created I'm actually ready to do my work and if the responsibility for Doing that for working with that as external then now your code has you've incurred additional responsibility in your external code I have to have the thing and then set the thing at a separate time and Inside of the class you have to as soon as you introduce the possibility The the possibility at all that there could be a state in which he doesn't have like a required service that it needs To do its work you have to wrap everything in if statements. Do I have my service injected? Is it here? Is it there if you add two of those or three of those you just everything explodes State cannot be mitigated by modularization. You can't interface away or design away these sorts of state problems This is part of the reason that they're so tricky So I heard this thing And I hear this and I hear this a lot and you know you think about with this with global variables Right because in fact actually I wager that some of you may sort of even thought this about global variables He's being ridiculous like who's gonna go in and change a global variable. Yeah Stop saying this Stop it. I heard this couple times yesterday. Maybe we want to tear my hair out. I say it to be clear I'm not really saying like you're all bad and I'm good No, no, no, like we say this way too much as long as no one does something stupid It'll all be all right. Nobody will touch that global. It'll be fine. Yeah, you know Yeah, that's not a strategy for software design if you didn't know that already I Obviously at a certain level like you can't You can't prevent people from doing something really stupid, but we need to like we need to walk back the level Of the stupidity that we're talking about like I would really like this to be well It works as long as As long as the person tries to run it on a computer or not a plate of spaghetti like that's that's a much Appropriate level to be having this discussion then oh it works as long as you implement these three separate hooks in these different places And toggle these configuration values correctly that I haven't really documented like oh, all right. Thanks. That's that's awesome We need to be we need to be aiming for plate of spaghetti much more than undocumented array configuration options This is also to say and I think this this gets you right like just the first part of this is important, too And I haven't sliced it off, but like it works right Stepping back for a moment. This whole talk is not about whether or not something works Not the topic here. You can make something work whether it's simple or easy This is about the cost of complexity and the dangerous thing with it works is I mean, yeah We'll keep on pal along in the direction that we've been doing where things just get more and more complicated And we don't ever really paid on the debt and just gets worse and worse and worse So be careful if it works and definitely be careful of it works as long as no one does something stupid It's a good sign that you should be tightening up your API support All right config entities harder now There's a lot here But config entities complex together the notions of config and entities and plugins and if y'all are not familiar with these This is Drupal 8 config entities. So I'm going to give you some sort of quick definitions, right? Entity Drupal's fundamental data building block the basis for attaching fields for typing and and insensing of data Config key-value pairs or sets of key-value pairs representing configuration that can be moved between Drupal instances by a known procedure and plugin Collection of logic typically represented as a class that solves a particular well-defined logical problem These three concepts config entities bundle them all together Now it's not necessarily all bad that they're all complexed together And this is actually an interesting case because this is one where when config entities were originally created two years ago something like that They were a lot worse. We've done an awful lot to actually Decomplex them by by narrowing out a lot of the interfaces and granularizing Granularizing some things but for starters We have these complexed interfaces here. So we have our config entity base our base class Which extends entity basic entity and it implements config entity interface All right, so then there's also config entity interface which extends entity interface This is the the conflicting at the interface level that says Config our types of config entities are types of entities now to be clear Sorry, the reason that we went with config entities is basically we needed to be able to create instance configuration not just what is like, you know the I don't know the Base URL for the entire site, but hey I've got you know a bunch of different views and I want to be able to I need instance config for each of them They need their own little bits of config So we said hey entities have instances and a couple of other nice methods. Let's pull them in Ignoring the large segments of the interface that were not actually relevant to the problem space of config The other piece of this then and and this is actually not config entities at all This is entities and plugins were collected long before config up like that with entities and then we just had a giant incestuous nightmare But any manager is a type of plug-in manager. We use the plug-in system in order to discover and locate in order to discover and locate any types and That's its own little bit of fun too because the plug-in system has like the notion of discovery and Hmm that I came discovery and factory and something else. What else? There you go Yeah, mappers great So but it has a couple discreet ideas in it And we wanted discovery so we took all of them Because they're complexed together And you're in choice whole thing got to take the whole thing But the problem that I really have now a days it used to be a lot worse with with With config and entities a manumit 545. All right. We're gonna zoom along a little bit problem that I really had with with config entities was There they're not content like there's a whole bunch of methods related to being contents That were on the original entity interface a lot of those Definitely not all but a lot of them have been moved down to to a content interface Which is what I said we've we've decomplected those things. We've made a sort of more basic concept of an entity But there are still these two pinky little methods on here bundle and URL that are on entity interface, which means that all config entities have to implement those those Those methods a bundle is for fields. It's declaring the field attachment points are relevant for config One could make the argument of course that well it might be convenience To put config to put fields on config at some point and my response would be no get out Like this is why we define separate responsibilities. I don't care if it's convenient like it violates the domain It's not simple. It binds crap together Don't do it find another way of combining other simple tools or more broken down pieces to achieve that goal but just because This system solves 30% of your problem doesn't mean it's okay to ignore the 70% that is irrelevant to what you're actually trying to do URL Is also in its own way interesting. I don't necessarily buy that config should have a Well, it says there is exactly one URL for which Exactly when you are all at which you configure this bit of this this this bit of config I don't buy that that doesn't make sense to me that config should only ever have one place that it's configured like it means that I By giving it a URL it forces me to have each and every bit of config be its own atomic thing I can't recombine them necessarily. I can't Build a system underneath whereby will you just use this config entity as sort of a storage bit for a broader set of config things that you know can work in different places which is actually a system that I've tried to build So there's that it's also doesn't allow for the possibility that no I actually don't want you to provide any UI at all Why should there have to be a URL and of course the response there is well It still works if you know you don't implement the methods, but like I said it works is not a software design principle Not a software design principle It doesn't belong there If it adds the method if to have the method there sends the signal I do this I can do this and just because it doesn't do it doesn't mean that it's okay that you have the signal out There in the first place out of all all right Complexed layers also is a different problem with with config entities So config is its own discrete system and as it was originally designed It sort of sits you know down at the bottom and does it's config thing it doesn't really reach into or need to touch any other Any other systems and in good software design we build in layers It's how it works so config could be down here at the bottom and then ideally we would have built config entities on top problem is at Import time import is what happens when you have when you are importing config you Put some new config in place and you want to import it into your system. So it's actively used by your new Drupal site That is one place where we can collect the layers we bust between the layers the config system Which should be able to sit down here and pay no attention whatsoever to the layer on top Which is the config entity system because a simpler more basic system with a more narrow set of requirements at Import time it has to call the entity system and say well I've got a bunch of entities and you go off and you process your thing you've collected the layers together They're no longer isolated config is now conscious of the layer above it. It's less than useful. It's dangerous Increases risk so All right, this is how you know that I'm serious is I'm going after the thing that actually got me recognition in Drupal in the first place panels How many use panels? How many hate panels that was actually a fairly fairly easy inversion there like we had, you know, yeah All right, so panels it complex your information architecture with presentation incorrectly By that I mean well, so okay one of the things that that Panels is basic Internals say I have a display object right and whenever you go and you do your drag-and-drop be creative thing with Panels whether it's like paid manager or panelizer or anything like that you're creating a display object It's got a bunch of pains in it. That's how it works thing is that It's a it's a very nice It's very sort of nice very isolated sort of share nothing approach to things, but that doesn't actually model the way that It doesn't model the way that Websites really work correctly like you have elements that you want to share across discreet systems So panelist's response to this is we're just going to figure out basically everything at like an outer routing layer And then have a share nothing approach once we get to the elements of display The proper approach is you know what there's shared stuff that appears in multiple different places and I want to deal with some things that at the level of picking which panel I use and then some other things At the level of here's a shared bit that exists between a bunch of different panels So if anybody has ever had the situation where you have like, you know 20 different panels configured inside a page manager with variants that are just like differentiating on one teensy little condition and you have One little thing that varies between the panels and now all of a sudden you're in maintainer hell and clickitis craziness because To update, you know the full set with one little change You have to do it 20 times over and then you you know slit your own wrists. Yeah, that's because the model's wrong That's because it complex the wrong things together Now interestingly panels internally is actually more composed than it is complexed It is things placed together. It has a bunch of discreet individual plug-in bits which each have a discreet responsibility and They do their own thing and there's a bunch of layers to it And it's actually it's pretty good about about keeping those things separate problem is it's an array-oriented API So it's only sort of a pseudo API and There's enough pieces to it that it's really just sort of overwhelming. We don't document it very well, too So it is to say it's sort of really never been made easy But when it comes to the interface, which is a lot of what really just you know blows people up about it reasonably so It commits this this interface send which is One of the other things to be careful of great You're totally convinced when I talk you want to go off and build simple systems now You go when you build a simple system in Drupal, which means you you know drive all the configuration to the interface Oh, yeah, well the panel's cockpit is because it commits the sin of Instead of building an interface that imparts knowledge about how the system works It builds an interface which requires knowledge about how the system works There's a bunch of implicit context that goes into how panels is operating and what it's changing and what things it's working with Which isn't really expressed It just sort of expects you to know and the options that you're given only makes sense if you already have that knowledge that is Really the internals and this is why I have this last line this the internals are complexed with configuration UIs But only partially so it's like I'll just pop up configuration options, but I won't Truly really explain like the context into which they fit which then goes back to well You only actually a part of the picture which makes it very very difficult to learn and reason about the system These are my ultimate nemesis altar hooks. Oh God, I hate these so much Ah Complex logic through shared state. We already talked about state, but you know all sorts of just Slightly better version of a global variable something like that, you know Yeah, let's pass this around and everybody can change it Traditionally these have been an escape hatch But in practice it kind of amounts to runtime configuration I'm gonna change this array and then another system where the all the logic actually lives is gonna behave differently It's a very weird kind of declarative oriented programming thing inside of an imperative Program, I also oh I had something that I used to say about this. It's like Drupal's um Drupal's like a shitty version of Lisp without any of the proper primitives list where you can manipulate the structure of the program you basically work by By changing the structure of the program from the program is this very sort of meta thing well Drupal's like that Except it's a raise so it's terrible because you have none of the actual tools that you need to be able to work effectively in a system like that Alter hooks wreak havoc on artifacts stability. I didn't talk about construct versus artifact. Well Easy is what you use right thing that you interact with goes away. The artifact is what you build. It is the software that runs Alter hooks make the permutation space of the different ways the artifact can be just explode like crazy crazy crazy crazy and Because there are all these different states that it can be in you can't necessarily reason about How the things gonna behave it'll probably be this way except for this line of code that all of a sudden was activated because it was the 7th Tuesday of Some made up month and you're in Tanzania or something like that. You don't know like Again these things might seem like remote possibilities, but the risk is introduced because there are possibilities not because somebody actually did So solutions quickly two basic ideas. I want us to decomplect and the other is to simplify so I am drawing lines between these because I think it's One could really make an argument that they mean the same thing But I like the idea of having the two separate ones that we can actually talk about doing two separate types of work Decomplexing for me. You're teasing apart these complex artifacts You're not actually like changing the code But again, you know the conflicting thing I make a braid and I have to deal with the whole thing And I didn't even really know what the inputs to it work So decomplecting is the action of taking that artifact that braid and teasing out the individual parts and Showing what the individual parts are. It's crucial information Which again if our goal is to be able to reason about a system Then having that information brought to us by something that decomplects a complex artifact is Massively useful massively useful. It amplifies our ability to reason about a system Simplifying on the other hand is basically making new simpler artifacts say nope. I'm not I'm not gonna work with that I'm gonna like turn that whole thing off or I'm gonna swap it out for something else, which is just intrinsically simpler So I have two things that are both decomplectors. I mentioned before I have this hook-a-lyzer project I wrote this last year. This is actually like it's really cool Obviously, I mean, you know, obviously I'm gonna say that but what hook-a-lyzer does is it takes over the module handler Which is the thing that actually like all Drupal altars run through and it inspects data as it goes through the altar So whenever you call an altar if you have hook-a-lyzer installed it's taken over the module handler and it snapshots the state of the data before every before and after every single Implementation of the altar and it provides diffs so you can actually see which Implementation is making changes to exactly which parts of the altar structure It is actually like maybe the most literal definition of decomplecting that I can think Ordinarily with altars. Has anybody ever actually tried to like go through and debug Which altar a change is coming from? Yeah, it's a nightmare, right? Like They're just aren't tools for that. It doesn't matter if you're in your debugger like great, you know You have your debugger. I'm gonna just dump out a 14-depth array and then put that in the text file and then the next iteration through I'll do it again And then I'll like run a diff between the two files That's kind of the most effective means that I've been able to come up with for for something like that. It's terrible So hook-a-lyzer does like I said, it actually just does that for you and then it dumps the output to To the UI This was super fun Turns out that in Drupal 8 core we have recursive structures which print R can't handle I blew four gigs of memory trying to print our certain structures that That we passed the Drupal altar and so the fun part was I wrote an engine in in PHP Which actually does the snapshotting in the diffing and somehow I still not sure why print R can handle them, but Captures those correctly, so it tells you here's what the changes are This I would love help on this I being as we demonstrated early terrible with HTML and like all real computer things It needs help actually building the visual front-end for it like I've built the engine I need to take the output data and you know printed out nice to the page love help on that collaboration testing this is Much more an ascent idea, but again, it's focused on the hook system So you know right now Whenever you write a simple test you say here the modules that I want you to have enabled and as soon as you write That line you have rendered that test Absolutely fucking useless for any real site Because hey those aren't the modules that I have enabled and since we have a wonderfully Complexed system it means that you're not actually testing the real system that you have in production So that of course then also means that if you're going to write simple tests for your for your production system And you have you know set of modules enabled that as it's gross. They're very brittle So the idea behind collaboration testing is hey, let's like let's look at the point of complexity Let's look at the point of entanglement where the collaboration occurs when mostly for the most part hopes or events are fired and Different actors come into the system unaware that they're there different modules come into the system unaware that the others are there and start Doing things and give them an opportunity inside of this this collaboration testing framework to basically we set up a like a Collaboration test that captures something like you know, what was it when I was doing? Look for Malta or something A discreet event that occurs that multiple actors might be participating on It gives them the opportunity to first it you know runs the event In a mocked-up way and then it gives all the actors the opportunity to say is the system correct at the end of this event Now it's hard to get something which is like pure red-green pass fail out of this sort of a system But the thing that's powerful about this is like if we could actually make this work we could First of all we would be Documenting in a much more proper way like what our modules expect the state of the system to be In a very practical way not in you know read me somewhere, but in something that you can make the computer go do for you But also it would allow for us to write tests in contrib which actually deliver value to real running sites You write a you participate in the collaboration test you you write some collaboration tests As part of a contrib module and then when it's actually you know put down in the someone's site everybody else who's participating in that same Collaboration test they all get run collectively as the whole point Collaboration test involves all the modules that you currently have working on a particular collaboration point Everybody gets to check and verify and see if the state of the system is correct at the end of that It would be pretty great. We would actually get reusability out of our tests for the first time in ever The other option simplification almost done This is harder and honestly, it's way easier to do in in core than contrib of course Although with the advent of the ability to basically change anything you want thanks to symphony and its services You can you can pull out a lot of stuff in in eight but I don't have any like specific pointers that I can send people towards The other pointer on the decomplecting front is I think it'd be interesting for somebody to write Not not a there's two types of complexity that are typically talked about there's n-path complexity and cyclomatic complexity I don't want to get into what those are exactly But I think it would be interesting for someone to write a complexity path analyzer that is specifically oriented towards determining the number of pads Determining the number of pads based on like again the currently enabled set of modules and very focused on the hook system because that's Groupal's basic interaction mechanism. It's where a lot of our complexity comes from in practice So for simplification It's way easier to do in core than contrib If you're gonna do it Then well if you're gonna build a new system try to really only build on components that you understand Try to build on components where you understand how they work not how to use them how to use them is about easy How they work is about simple simple is how you know whether or not it's something you should build on or not Remember if you build on it, you take all of its complexity and make it your own In general focus on swapping over altering We are so obsessed with the altar pattern because hey, I just write one line It makes works the way that I wanted to That we forget that it's a perfectly valid way. It's perfectly valid to use Instead of changing the way that this thing works I'm instead going to just put in my own version of how it works. It's much more explicit way of operating It's much clearer to everybody else in the system All right quick recap simple and easy very different both important Simplicity can enable easy, but not vice versa easy has nothing to do with making with whether or not something simple Simple as generative easy is a dead end. You get what you designed for and really not a lot more Drupal desperately desperately needs more simple systems and simplicity oriented people So that end I have this little thought right like I guess you can't read this folks in the Drupal learning curve before yeah So this is this thing Dries published this original one a long long time ago. It must have been at least five years ago There have since been some sort of other versions of it done, but up at the top there Up at the top actually says I'm a chicks or unconed Probably a very small percentage of people even know who one cone is at this point But I think actually the way that I look at this It's a little bit better to say at the very very top The most important thing that you can do once you've mastered all the other skills once you figured out all the other things once you actually Understand some piece of how Drupal works the highest Calling in Drupal is reducing complexity Decomplexing simplifying whichever one it is that is your job if you are adding features to Drupal when you have Enough understanding of how the system works to be able to make it simpler You're not helping Drupal can make features all day long Make it simpler that is what is slow That's why we have these long long release cycles because we can't solve problems effectively because we've made such a giant Complexed mess figure out a part of it figure out how to make that part of the system simpler defend it Stake your territory out. I mean, you know, I sort of think of it almost like Build a little castle and just make sure that everybody only comes into the front door Everybody running every which way to everybody else's thing is part of the problem. So pick out your spot Find that become a simplifier. It is the best thing you can do for the project in the long run I'm hoping that maybe this talk will help promote the idea that that's a type of person that we should value and hoist up That's it questions Mike is in the middle. Thank you for staying long. I realize this is You referenced rich Hickey at the beginning. Yeah, and but you sort of passed on the idea of functional programming as a solution What about immutable data which seemed to go a long way? I love immutable data, and I actually love functional programming I didn't mean to pass on the idea of it as a reasonable solution, but it's not gonna help Drupal I mean like the The discussions that you have around persistent data structures and controlling things like that. Well, I mean actually, you know I'll say a little thing here. Can I do this effectively? So I have a little library that prozone that was up there Yeah, I got drunk one night and probably and did copyright infringement But so I wrote this little library which is it's super small It's a little composure library, which basically just lets you manage object state You can freeze objects and you can lock and unlock them There are things there are small steps that we could take towards actually like achieving Immutability, but frankly, it's not like it's not a language feature that there's really much support for and PHP is not fast enough to write like PHP is not fast enough to put our base data structures of which there are so many My gut tells me PHP is not fast enough to put those inside of those sorts of abstractions that we would need in order to do a persistent data structure different from immutable Which is where we would get a lot of the sort of value that that they talk about persistent data structures are wicked cool But it's just not really feasible. I think in our in our environment Other questions Hi Enjoy your talk. I like they especially like the sort of philosophical thinking about easy and simple which I haven't done in a lot of ways I was wondering if You think maybe there is an inherent complexity to something like Drupal where it's kind of trying to be all things to all people Right, like you said, you know people don't necessarily know that they're what they're gonna do with it so if that is In a way, maybe a pessimistically speaking an impossible obstacle to simplifying it and also Sort of two-parter if the sort of if there's an acceleration to the complexity Like you said, it's really hard to walk backwards towards simple So it's more and more people will collaborate as it gets bigger and bigger Complexity is just spreading out like a glass of water. You toss on the floor or something What do you think? Yeah, what do you think about those? What was the first one again real quick just inherently complex right so I think it's actually funny because As I've started thinking more and more in this kind of direction like I Think actually It should be the opposite right like if you want to be all things to all people you have a much stronger requirement to be simple It's kind of the thing like you know easy doesn't recombine simple does so if you want to be that thing You should have it you should but you need to reach a much much higher standard in terms of achieving simplicity So I don't know that it's like I Think a lot of the issue actually has to do with layering Oh, there was a there was a thought I wanted to put in there But I think individually folks need to decide At any given time and any code that you're writing needs to be one of the other make it simple or make it easy But if you are building something which you expect to be reused and recombined Fuck easy. Stop it. No, like seriously. Just don't don't do that Like take your time make it simple find someone else who wants to use it and have them work on the easy part of it Honestly simple and easy. It's kind of hard to hold both in your head at the same time and Given external stimulus, it's really easy to fall off in the easy direction. So I Don't know. I don't I don't think it's inevitable that it has to be complex I certainly it is with where we are right now The only other thing I can say there is it's it's interesting to note how most of the systems that we have in Drupal We've have had in Drupal That continue to exist in eight. I would say are not substantially Less complex. They are at least as if not more complex by these definitions then Then they were before but some of the new systems we've built like confeg Are relatively isolated. I have my assets patch, which if ever gets done is just like there's like a Tiny entrance way through which stuff comes and then there's this big old domain that works in a very very specific tightly bound way It's its own discreet subsystem. Like I said, I built a castle and I let people in the front door and you are not getting in any other way so I don't know there's steps we can take but It's it's gonna be hard like Don't reuse stuff Maybe that's the best thing to do. You want if you want to have a data object, you know It's like make some simple value objects. Don't use the entity system. Maybe I should say that sure That's it. Did you think I'm not sure if I got this part of the answer But you think there's accelerating complexity like are we or maybe another way of saying is are we going in the wrong direction that we can't? Yeah, probably Frankly, yeah, probably there's I think there's just such especially now it's very difficult to get patches in and I don't know I'm not here. I won't say accelerating what I will say is that I think we have really the wrong values when it comes to Evaluating the utility that a that a patch brings to the system and the wrong expectations around how we should be looking at patches At changes that we make so that probably enables the possibility of acceleration I don't feel like I have enough information to say accelerating, but I feel like I have enough information to say that Thanks. Yep So at some point we want to create Unpredictable systems things where we can't just look at them and say well anything a user does I can predict what will happen? So does that mean that we have to have complexity somewhere or if we have sufficiently many layers each one of which is Isolated and understandable Is that enough my I mean my general thinking is like no we can never anticipate all the things that the users will do but it's really about like a Simple system says here are some basic concepts. We don't string them together You know, we let you string them together. It's implicit in the inputs and complexity in the patterns. So The sort of holy grailish thing that I that I think about is you you build a simple first you have sort of Tomic interfaces if you must build UIs for them And then you focus on all right I have this use case in this use case in this use case and I'm gonna I'm gonna stitch together UI that solves this one And then solves that one and then solves that one but The most risky thing that we have is is basically like we We have interfaces which complex together Wanting to like allow people to to recombine bunches of different parts But also like you know very linear wizarding configuration types of things Those are very different types of tasks I have multiple discrete parts of the system that I'm trying to configure to make interact all nicely And then I have a linear wizard to solve a single problem like I would prefer a little bit less of the former I think and a little bit more of the latter and Drive the responsibility for doing the former further down into code into things which you actually have to touch code in order to do For better or worse Yeah Thanks. Yep So I'm gonna ask you if you have a better answer to Horizontal extensibility Then the altars that you've been railing against for oh so long Right, so I think one of the things that gives Drupal a lot of power is that you don't take a basic node form and Say now I'm going to take that node form and I'm going to extend that node form class right in an imaginary other version of Drupal and Tack on a sign-on sheet right a sign-in sheet for an event. Let's say or Take it and and extend it sort of in a traditional OOA and say now I'm going to add Product add to cart button Back to that sort of combinatorial thing that you were talking about we give you the ability to say you can do both Because it's a hook form altar, so both can reach in muck with that data structure in ways that none of the other modules expected and One module can take the node form and add a sign on like a Sign-up another one can add the add to cart and yet still another one can make those two pieces interact So that you can't do one without the other Yep, I think that's a lot of what's given Drupal its legs over the last ten years and I think it's a piece that has made it almost impossible for us to do meaningful combinatorial testing because While you can say yeah, I can make sure that I still have my thing on the sheet and it can be filled out It's much harder to say oh and I Understand that I now shouldn't be able to do that because some other module is tying me to something else And there's there's other things that I wasn't aware of that now are required for me to work properly That's actually the purpose of the collaboration testing like it's perfectly fine that people should write in those expectations This is how I expect it to work and if some other module alters it like that's useful information And then this is this is why I said that they're not necessarily something which are really really amenable to simple right-green pass Like the information that comes back that says This module has had its expectation violated isn't necessarily a reason that you don't deploy But it's something that you who want to be able to reason about your system should want to know Interesting, and do you have any better solutions to the horizontal thing? Yeah, you know we've talked about this before quite a bit and So I've been writing a new graph library, and I'm really annoyed because in the basic the basic set of axes that I've set up I have one four dimensional axis one One one four element axis one three element axis two two element axes So that's two times two times three times four 48 possibilities 48 possible permutations of ways that I you know have to implement a graph It's annoying sucks. Sometimes simple is more verbose Suck it up Now hear what you're saying like wait wait So you're telling me that the answer to horizontal scalability is just to think about configuration in an n-dimensional space Yes, that's and that's gonna make it all much more simple. No What I'm saying is that there are times when It's not a clear-cut answer either way There are times when saying no these really are like separate things and I'm going to do them separately And I'm going to force that they are separate and this is what I was saying about like dry Not always the best thing to follow just dried number of lines of code You have to write in order to accomplish something not the best measure of whether it's doing healthy things to your system or not So yes, there is enormous convenience that comes out of these alters. There's no question about that I don't have a clear place to draw the line And and I also wouldn't really dispute your basic point that that's probably where a lot of Drupal's utility has come in Or Drupal's adoption has come in from is you have this one thing that you can do Which might have really nasty effects in terms of how it complex the system, but it solves your one problem real good and it works so I Don't know where the line is Where the appropriate point to draw it and say you know what we're gonna we're gonna factor this into an n-dimensional problem space And let there be some code reuse and not allow altering and force people to swap or say yeah, it's still fine to stick with the alters I don't have a clear like it's case-by-case basis What I do know the only thing I feel like can clears clearly say about it is that we are so so stuck to the idea of It has to be easy that we can't make decisions that push us even a little bit in the simple direction because oh well If I don't have one alter for that then nobody's gonna use that and remember and to which I say suck it out And it does feel like we're starting to suffocate under the Interdependencies and interconnectedness that makes it impossible to do testing or anything right which is which is the point It's that you know You don't necessarily have to take this approach right from the beginning when you build something But we are now suffocating That's the cost of the complexity that we built by using these sorts of patterns Just to continue that discussion for just a second like Form altar like we probably won't be able to get away from that anytime soon because of the utilities talking about but like Altering the module list during runtime Like we can do that. There's a hook fire right like why that doesn't really make sense Okay, so hook module implements alter. That's a great one. Yeah, so things like that. Those are Valid complexity that we might actually look at and we can define a better way of doing it in the space to Solve it in I Wait until there weren't any more questions We're good. Okay. I got it. I have to ask you said that you know mentioned that Plugins in their interfaces. Would you not say that the plug-in interfaces are simple? Kind of a troll since you did sign off on that. I did it's true. I did Well, here's the thing it's all question of degree right and what's acceptable complexity I don't think one that we name different parts of them There are three interfaces which comprise the plug-in manager interface clearly. That's three different things complexed together Maybe that's acceptable complexity. That's why I had that slide on the other question. The upper question is what is acceptable complexity? Those were three things which I Think I think actually the interesting thing about the config in the entity discussion with with plugins is Yeah, and he's wanted discovery and They got plugins could we have done it where discovery was its own thing? And that's what they got and they didn't have to get the rest of it Maybe it is its own interface, right? It is its own interface, but they ended up using the whole thing They did that and I'll say why this actually was something you hinted on It's because they wanted the The complexity that was embedded in the base class The in the in the manager and the manager base class, right? They wanted a factory like ish behavior right and things like caching that were embedded into the base class and things like that They wanted to reuse those implementations because they weren't implemented in the interface Yeah, and it's it's The point if it wasn't to say it's it's good or bad necessarily a lot of the point of this is like really we just need to remember and understand When we have separate systems that have separate goals which have been collected together like we inherit that complexity Yeah, I don't have a clear answer that like you know do we use derivatives at all for entities? How do we actually do is that is that the entire way that they're done is through derivatives? I could suspect possibly probably no I think oh, no, we don't discover in the annotations. Yeah, I think actually most entities uses plugins and kind of weird ways for loading like Storage classes and things like that. So I don't think it uses it for things like that Yeah, and I remember some it's been a little while now, but I remember some weird annoyances with trying to inject stuff I know but yes, so but there you go like it uses it in weird ways That's another one of those Sentences like it works as long as nobody does anything stupid which you beat me to it. What's that? You beat me to saying it works as long as nobody doesn't think there you go. So Yeah, like I would I would love to see us I Would love to see more ordinary people defending little fiefdoms where they have As much as that's sort of been a thing that's frowned on like I think we could use more of it I think we could say you know what no, no, this is what it does All that it does we're not gonna bind it up in a bunch of other stuff. This part is done So, yeah, I'll make one more like The the example you use early on where you said you need to implement these three hooks and then change these three That's basically a description of the entity system in seven and the current input is the current any system is actually a lot less Complex even if it is very complex Yeah, yeah, I mean we've we've made Well by by the definition of there by what by what sense of Complex and in what way can you even example of two considerations that have been released from each other from seven to eight? I'm not all that familiar with seven, but The hooks aren't in like five different places you implement a class. It's cohesive. There's an interface that's clearly defined so there's There's there is a lot of that complexity that's come through but a lot of it's been identified and kind of simplified out and That's made it easier Maybe there's a lot of people that seems things maybe well, you know, and that's the thing like it's the the I've actually been reflecting a fair bit on the light I have to implement hooks in three different places or something like that question, right? It's actually a funny one I don't think it has anything to do with complexity at all for an info hook like it's annoying. It's not easy I'm not sure it actually increases complexity to have multiple different info hooks by this definition And you know, I'm not saying this is the only way that you guys should ever talk about complexity ever again But I think that there is I think there is more utility and a specific precise definition of what it is when you can talk about two orthogonal concerns being Braided together. I think it it tells us something more useful because otherwise saying that's complex is basically just like fuck You have to deal with this. It's it's not a it's not a productive statement, but when you say this is what complex means It becomes incumbent upon you to actually specifically itemize How the things are bound together and that leads pretty directly to questions about well, should they be why is that? Is that okay? Can we disentangle a little bit? Can we compose instead of complex like? Yeah, anybody else? Cool. Thank y'all for coming and continuing to hang out for the whole discussion