Over the years, my golden rule for developing large code bases been to understand the data flow. Understand the pipeline without getting bugged down in the small logics. When you understand the data flow, then you can understand the underlying logics much easier. When a bug shows up, you can have a better understanding of where to look to resolve the bug.
I have been having this discussion for years now: don't start by modeling, start by drawing the steps of each workflow, end to end. That will give you much better insights of how should you model each step.
If you know the data flow, it's also simple to find where the bugs originate. Worst way to fix would be symptom whack-a-mole while not fixing the source.
Thanks for the game-changing concept, as I take it. "You can understand anything at one moment. you can understand everything over time. But, you cannot understand everything all at once."
This reminds me quite a bit of discussions about cloud-native architecture diagrams in which everything looks so much more complicated. In reality, while certainly systems can be overcomplicated, many of these kinds of diagrams are actually making implicit complexity explicit, which I can only see as helpful.
My focus in a project is getting the cross cutting concerns correct. It makes the code opinionated, but the predictability and adding new features is optimized. Of course sometimes it is still a gamble at the start what will be the cross-cutting concerns
Great Video Simple code (in modern C#) = Using Design Pattern's / Thinking outside of the box + Your own Class Library ( OOP + Functional Programming).
You can though, just paste the code into copilot and ask it to explain what it does. For the most part though, if the code follows standardised practices, which it should.
I'll stand with "Everything should be made as simple as possible, but not simpler.", and spin it a bit differently, "Don't concrete too late, don't abstract too soon." And keep a bearing on what the end goal is. You're right, for a game developer, that will be "frame time", everything else can be thrown at the sacrificial pit. But many a code base will live on for decades, and do you want to support (and extend) a dumpster fire for that long? While keeping a shred of sanity? If nothing else, take care of the most obvious and glaring things, and deal with minutiae as it presents.
This has been the longest training exercise I've experienced in my life. I always find myself looking for the simplest solution to solve a problem. Those problems can originate from internal or external sources but must still be dealt with strategically. I try to look a few steps into the future and ask myself, what will happen if I do it this way and 2 years from now something that this "thing" handles needs to change? Will it break it? Will it be easily extended? Will it need to be redesigned from the ground up? How do I know where to go from here? It's even crippling to a certain extent. I've been programming since the 1980s and I still have to fight the urge to "make it simple", based on a complete misunderstanding of what "simple" really is, even though I know what it is. It's really an acquired skill. Also, I'm a photographer, not a developer. Why do I torture myself like this?
I have said "Simple is hard, complex is easy". It takes more work to create a system or write code that is marked by simplicity. It is easy (and common) to create a complex system or write complex code.
Oh Zoran, I've been busy and got a month in arrears of your videos. Nevermind, I've got Christmas holiday to catch-up. I'm in embedded, you probably won't be surprised how large a modern embedded application can grow now that hardware is so powerful. Millions of lines are not uncommon. That means that us embedded coders must learn all of these modern techniques so we don't end up with a ball of mud. Times are a changing (Bob Dylan).
@@nickbarton3191 I can imagine how large modem software has become. Car software also comes to mind. On the other hand, I presume coding/decoding, routing, and other critical portions remain as optimized as ever.
@zoran-horvat Even front-end tech has changed. But most of the customer and business requests come for the backend. We have bundles of JSON for telemetry, external interfaces, remoting, and more. 8 years ago, I could see where we were headed and that the ball of mud couldn't resist the storm. So I reached out, firstly to Uncle Bob, finally I've found you. From compact framework, framework 4, dotNet Core, now .net8. And the hardware changes to suit, now targeting embedded Linux. Each version we are getting times 3 or so performance improvement. Embedded Linux is amazing, getting 3 times the performance over embedded Windows for the same platform. And the refactoring, we dropped the line count by at least 50%. So this has increased the biz opportunity no end. For a smallish company, this is transformative. Less hardware costs and off the shelf, needs fewer engineers too. I no longer fear change requests. Now I look at your code examples and I'm thinking, what else can I do to transform this code. It still has some very dark corners. More power to your elbow, just this last year you helped us a lot.
shouldn't the LoC chart have new Lines of code on the y axis? Apart from this, great video as always :) for other creators I wouldn't even bother to write, but given your quality standards I just had to ask ;)
Hello! Could you please explain how, in DDD, business entities like Customer and Courier are related to User (the actual user of the application)? Since business entities do not store authentication information and only hold data for business logic, I’m still having trouble understanding this. :(
@@deadcxlm If user represents a tenant, then I store its identity in business entities as well. If the user is not a tenant, then any associations to business entities can be modeled side by side with the entity. I don't know what the viewpoint of DDD practitioners is on that matter. I rarely listen to them. There is too much noise for my taste. Many people see DDD as a religion, and then make all kinds of random decisions they cannot explain. Tenancy is a critical element in design. It must be subject to referential consistency in my opinion, irrespective of modeling style.
@@zoran-horvat Will the ApplicationUser identifier be stored in the domain models, such as Customer and Courier? Or is it possible to link a business entity with an auth entity without a foreign key?
That is only partly true, as deadlines depend on the development team as well. Many developers believe it is the whim of a manager, but no. They accepted to deliver the impossible. I am telling this from experience, as I was also the development lead and CTO and I know pretty well how the development staff establishes scope and deadlines with stakeholders and management.
One of the core principles of organizing data is, to separate what is needed what is not (exceptions) The purpose of a model is to have a general idea of what is happening. So the more simple and organized it is, the better. That's why the model of atoms, the globe, etc. Are simple.
increasingly accurate models of physical systems such as atoms and the globe are increasingly complex, until they reach a point beyond human or computational comprehension (it's impossible to model fluids on the quantum mechanical level, since the computational complexity is way too high, for example)
@asterixgallier8102 no they aren't. But yes you can make a complex model. But the more complex your model is. The more it becomes specific to something. When something is specific it is not really a model anymore. Also Somethings cannot be modeled. Only theorize, looks for governing laws, or hypothesize. Like fluid motion? Human behaviors? Etc.
@asterixgallier8102 atom model is actually not that complex. The problem is. It is incomplete. We are getting more data. That affects our model. That's also why we have a lot of models for it in the first place. But if you look at any models of the atom, you'll see it has a history from previous models. Also there is something you need to know about models (any). Models are structured on what you are trying to study from it.
@@diadetediotedio6918 i said the "model" not the atom itself. You cannot make a very complex and specific model. Because if you do it is not a model anymore. A model needs to represent something, not be something. Also the behavior and structure of an atom can be simple or complicated depending on what you are talking about.
@@_iPilot That really depends on the project. If it is a monolithic project, then it might keep declining slowly. If the project is more of a core surrounded by a swarm of downstream components/services, then the development speed might as well grow over time or stay constant.
Doesn't blowing the code into small pieces here and there make the codebase harder to understand? Now u have to jump to so many places to understand something. Why is it not better to put related logics closer to each other? And it is probably gonna take a lot of time to refactor the code into something that looks simple
@@yoyocswpg Do you advocate for 5,000-lines-long classes? Because many things are related to many other things, and then that is what you get when you try to put them together - a 5,000-lines-lomg class. I think I was specific about that in the video.
@ I don't. But I don't advocate for one-liners or three-liners either. Some processes simply take more lines of code to implement. If a function communicates a concept, I think it is fine to have it with 100 lines of code. And I don't have to jump all over the codebase. If u hire someone new, they need to learn the existing abstractions or common classes you have created to know how to work with them. That takes a lot of time too. I mean why not just write code the way it is normally done. Creating these abstractions isn't really making anything happen.
@yoyocswpg Functions with 100 lines of code that do not require configuration and adaptation, such as deployment-based, user-based, or request-based variation, are truly rare. In most cases there will be no single block of 100 lines that does something, but a dozen of such blocks that are 90% the same in copy-and-paste manner. I am saying this from 25 years of experience in the industry.
The hard part is the 'art' of introducing types, the right amount is subjective. Superfluous types are as bad as no types and incorrect hierarchies are worse than none at all. Types are an abstraction and abstractions are never 'free'. For example, in java you can't tell mutable and immutable collections apart at an api level. Mutations just throw exceptions. Why? At the end of the day, it'd be 'expensive' to do it right. Should you have a `PositiveFloat` type? How about `PostiveFloatPrecision5Scale2` type? Well, it depends! If your problem domain really does have hard constraints on numbers that keep appearing, and/or you are making actual business decisions based on numbers fitting this definition, a type may well be warranted. Should `Speed` and `LudicrousSpeed` be interchangeable at an api level? Probably not as they impact the business of flying the ship, not just technical concerns. If you just happen to have a float in a larger immutable object, then a simple validation for the object is much more maintainable. Especially if the constraint is just a starting value and can vary thought processing as a `Float` normally would.
A random comment about simplicity and complexity I've seen in many projects over time I think most of the maintenance work done in legacy projects is really about having state and side effects* being scattered all around in all places, a terrible amount of boilerplate and code that is extremely non-local (i.e. in which you need to visit dozens of locations to understand it's behavior). In this sense I think that OOP has something to be blamed of, don't you?
@@diadetediotedio6918 OOP has been applied by millions of people and it gets expected that vast numbers did not get it right at the time of their doing. Pick any other tool or method and it will end up equally prone to errors when used by inexperienced practitioners. I am aware today of a lot of errors I made early in my career when I was given the responsibility but not the lead. I would return those designs to their maker and not approve them today. That is how it goes.
@@zoran-horvat I actually agree with you that an unexperienced developer can make a mess with any tool, absolutely. I also think that part of the blame for messy legacy codebases is putting coding in the hands of people that were not even interested in coding in the first place (but that's another discussion). What I'm saying here is that OOP is a negative factor, more than just being an innocent bystander in the hands of unexperienced developers. If you can agree that side effects make code harder to reason about and test (and judging for some videos I've seen in your channel, I think you can at least generally agree) then why not apply this to a paradigm that leads people into applying side effects all over the place when they are unexperienced? Well, this is not a completely fixed position fo mine, I'm open to change, but I my point is that OOP has at least some blame here (not that it is the root cause or something).
@@diadetediotedio6918 I generally agree. But on the other hand, a more advanced modeling method means a gross reduction in the number of programmers. The software wouldn't be written at all, then. All industries wanted their applications up and running, and so everyone who knows how to type on a keyboard wanted to be a programmer. There was a rant once, I can't remember by whom, about making programming open to everyone. We the programmers wanted it that way, so we got it. I don't have much hard feelings about it, honestly. I do get sharper, though, when I am in charge of a project.
@@zoran-horvat Oh, this is a good point. I thought on this as well, because if something has more friction to learn it would remove many codebases made by those people that are not interested in learning (and/or are scared to learn more complex paradigms like FP). So I think I can agree with you on this, OOP leads to more software being developed. More software being developer also means more mediocrity, so things kinda align in this sense. This I can't judge, I can't discuss with the market choices. In the end things like OOP are a popular choice because they are good for those kind of things (badly written or not), which is good for consumers (because they generally don't need to care about good code or bad code, or maintainable code, and companies need money so it is as it is). My point here is more a discussion not in the business side of things, but on the technical level, I think it is more productive for us to at least recognize that OOP induces some problematic behaviors (so we can lead to better business code being written by unexperienced devs by guiding them better with a more robust programming mindset), so I think it is a good think you take care on the projects you are in charge of, I tend to do the same. Anyway, I think we reached a good level of mutual understanding, thank you for the discussion, it was good.
Too many companies allow for procedural exceptions to seep into the information architecture. Streamline your organization, it's procedural makeup and your information architecture will improve significantly. In other words: stamp out the exceptions. Problem is: most companies don't even _have_ a procedural framework - or it has deteriorated in time. It's part of "how we do things here" and its foundation is within the culture. Try to automate that.
8:30 But the methods wouldn't have to merge into Book if you just make them static and use a static class that acts like a namespace for finding them, like Extension Methods. I wonder what your thoughts on this talk are, and if it's a dumb idea or not: "Solving Problems the Clojure Way - Rafal Dittwald " ua-cam.com/video/vK1DazRK_a0/v-deo.html
With methods goes the state on which they operate. While you are right that in functional programming the behavior is defined separately, you must still remember that functional programming strongly supports composition of types. In other words, you will end up with the same class diagram in FP, only calling them types rather than classes.
@@MattDog_222 Choose your words wisely. What makes it a counter-ARGUMENT? I might understand it as a counter-EXAMPLE, for instance, but hardly as an argument.
Man that class structure is insane... you have a 106 methods for a class that has like 12 fields? How did you even manage that... You factored what should have been two fields into 8 classes (no, I'm serious, look at PublicationInfo)?! You have 27 methods for an edition of a book. Here I was hoping noone actually ever does this. Then you people wonder why projects get so complex. It's because you pollute the environment the actual code that does the logic lives in.
and then your boss comes in and demands that the edition and publication date are different per publisher. And now you've ended up with a release class that becomes a wrapper for List that has 11 methods on it, out of which exactly 11 now should instead be defined on Publisher instead, and you won't refactor that, because you'd have to understand the implementation details of Book, which you won't, because that's not even the class you're dealing with at any point when doing these changes, you might not even know it exists, and also because it's the entire point of this extreme way of factoring code for you to not be bothered with "implementation details" (which in reality shape the architecture). Unavoidably later someone comes along and reimplements the exact same methods or some new ones on Publisher, that person might not know about Release and they'd be technically in the right, except now you have behavior for a single entity arbitrarily divided between two classes.
@@zoran-horvat If I'm incorrect about anything else except the obvious total coding culture crash we seem to be having here, please remind me to correct myself.
This is why I hate business software. It’s big it’s clunky, it shows the ineptness of management and the organization. Games, embedded even trading software is in everything better. It’s small lean and fast and to the point of the problem. Business software is all politics and idiotic exceptions of poor lawmaking, business decisions and ever changing processes and rules. You can never engineer properly designed systems when the foundation is shifting all the time. What we in engineering say: “you can fix stupid! You can’t engineer yourself out of quicksand”.
@ yeah it pays the bills because of the sheer stupidity and thus the ongoing changes. It’s just highly boring and demotivating compared to embedded-, system- or game software. It’s also ironic that the big money is in business software, because it requires very low skill level compared against to embedded, system or game engine development.
Writing code isn't always so simple because of object-oriented programming. Object-oriented programming does nothing but over-complicate and hide real code under layers and layers of abstraction all the while having no concern about the actual hardware that is running the software. It is needless complexity that adds needless difficulty.
@@zoran-horvat it's a fact though. OOP is inefficient in memory use CPU-use and power use. It is the reason software is so slow. The inefficiencies of OOP nullify a decade of hardware improvement.
Learn more at Brilliant brilliant.org/ZoranHorvat/
This link gives you a 30-day free trial and 20% off of an annual premium subscription.
Over the years, my golden rule for developing large code bases been to understand the data flow. Understand the pipeline without getting bugged down in the small logics. When you understand the data flow, then you can understand the underlying logics much easier. When a bug shows up, you can have a better understanding of where to look to resolve the bug.
I have been having this discussion for years now: don't start by modeling, start by drawing the steps of each workflow, end to end. That will give you much better insights of how should you model each step.
This! Code should always be written around data, not the other way around.
Event Storming approach comes into place! Use it!
If you know the data flow, it's also simple to find where the bugs originate. Worst way to fix would be symptom whack-a-mole while not fixing the source.
@@sealsharp "Symptom Wack-a-mole" is so good, I am keeping it! Thanks
Thanks for the game-changing concept, as I take it. "You can understand anything at one moment. you can understand everything over time. But, you cannot understand everything all at once."
Great video as always. Also love the diagrams/animations. Very professional and clear
This reminds me quite a bit of discussions about cloud-native architecture diagrams in which everything looks so much more complicated. In reality, while certainly systems can be overcomplicated, many of these kinds of diagrams are actually making implicit complexity explicit, which I can only see as helpful.
This is an incredibly useful video to share with other developers. Great stuff!
My focus in a project is getting the cross cutting concerns correct. It makes the code opinionated, but the predictability and adding new features is optimized. Of course sometimes it is still a gamble at the start what will be the cross-cutting concerns
Great Video
Simple code (in modern C#) = Using Design Pattern's / Thinking outside of the box + Your own Class Library ( OOP + Functional Programming).
this content most useful for startups, thank you
"You can control anything at one moment. You can control everything over time. But you cannot control everything all at once."
Now that is wisdom.
You can though, just paste the code into copilot and ask it to explain what it does. For the most part though, if the code follows standardised practices, which it should.
I'll stand with "Everything should be made as simple as possible, but not simpler.", and spin it a bit differently, "Don't concrete too late, don't abstract too soon." And keep a bearing on what the end goal is. You're right, for a game developer, that will be "frame time", everything else can be thrown at the sacrificial pit. But many a code base will live on for decades, and do you want to support (and extend) a dumpster fire for that long? While keeping a shred of sanity? If nothing else, take care of the most obvious and glaring things, and deal with minutiae as it presents.
it would be interesting to see how the repository is implemented to preserve such a class structure
🤩
@@maflend2762 There are a couple of videos where I used EF Core for that on this same object model.
This has been the longest training exercise I've experienced in my life. I always find myself looking for the simplest solution to solve a problem. Those problems can originate from internal or external sources but must still be dealt with strategically.
I try to look a few steps into the future and ask myself, what will happen if I do it this way and 2 years from now something that this "thing" handles needs to change?
Will it break it?
Will it be easily extended?
Will it need to be redesigned from the ground up?
How do I know where to go from here?
It's even crippling to a certain extent. I've been programming since the 1980s and I still have to fight the urge to "make it simple", based on a complete misunderstanding of what "simple" really is, even though I know what it is. It's really an acquired skill.
Also, I'm a photographer, not a developer. Why do I torture myself like this?
Thank you that was a great lullaby
whatever helps you sleep at night
I have said "Simple is hard, complex is easy". It takes more work to create a system or write code that is marked by simplicity. It is easy (and common) to create a complex system or write complex code.
Oh Zoran, I've been busy and got a month in arrears of your videos. Nevermind, I've got Christmas holiday to catch-up.
I'm in embedded, you probably won't be surprised how large a modern embedded application can grow now that hardware is so powerful. Millions of lines are not uncommon.
That means that us embedded coders must learn all of these modern techniques so we don't end up with a ball of mud.
Times are a changing (Bob Dylan).
@@nickbarton3191 I can imagine how large modem software has become. Car software also comes to mind. On the other hand, I presume coding/decoding, routing, and other critical portions remain as optimized as ever.
@zoran-horvat Even front-end tech has changed. But most of the customer and business requests come for the backend. We have bundles of JSON for telemetry, external interfaces, remoting, and more. 8 years ago, I could see where we were headed and that the ball of mud couldn't resist the storm. So I reached out, firstly to Uncle Bob, finally I've found you.
From compact framework, framework 4, dotNet Core, now .net8. And the hardware changes to suit, now targeting embedded Linux. Each version we are getting times 3 or so performance improvement. Embedded Linux is amazing, getting 3 times the performance over embedded Windows for the same platform.
And the refactoring, we dropped the line count by at least 50%. So this has increased the biz opportunity no end.
For a smallish company, this is transformative. Less hardware costs and off the shelf, needs fewer engineers too. I no longer fear change requests.
Now I look at your code examples and I'm thinking, what else can I do to transform this code. It still has some very dark corners.
More power to your elbow, just this last year you helped us a lot.
This video was amazing
shouldn't the LoC chart have new Lines of code on the y axis?
Apart from this, great video as always :) for other creators I wouldn't even bother to write, but given your quality standards I just had to ask ;)
@@janhendrikschreier You are right.
Hello! Could you please explain how, in DDD, business entities like Customer and Courier are related to User (the actual user of the application)? Since business entities do not store authentication information and only hold data for business logic, I’m still having trouble understanding this. :(
@@deadcxlm If user represents a tenant, then I store its identity in business entities as well. If the user is not a tenant, then any associations to business entities can be modeled side by side with the entity.
I don't know what the viewpoint of DDD practitioners is on that matter. I rarely listen to them. There is too much noise for my taste. Many people see DDD as a religion, and then make all kinds of random decisions they cannot explain. Tenancy is a critical element in design. It must be subject to referential consistency in my opinion, irrespective of modeling style.
@@zoran-horvat Will the ApplicationUser identifier be stored in the domain models, such as Customer and Courier? Or is it possible to link a business entity with an auth entity without a foreign key?
Start with good intentions. Then the deadline swoops in and it all goes as expected!
That is only partly true, as deadlines depend on the development team as well. Many developers believe it is the whim of a manager, but no. They accepted to deliver the impossible.
I am telling this from experience, as I was also the development lead and CTO and I know pretty well how the development staff establishes scope and deadlines with stakeholders and management.
Zoran which books would you suggest to be better in c#? I can say that i’m a bit better than a beginner not intermediate level yet
One of the core principles of organizing data is, to separate what is needed what is not (exceptions)
The purpose of a model is to have a general idea of what is happening.
So the more simple and organized it is, the better.
That's why the model of atoms, the globe, etc. Are simple.
increasingly accurate models of physical systems such as atoms and the globe are increasingly complex, until they reach a point beyond human or computational comprehension (it's impossible to model fluids on the quantum mechanical level, since the computational complexity is way too high, for example)
@asterixgallier8102 no they aren't. But yes you can make a complex model. But the more complex your model is. The more it becomes specific to something. When something is specific it is not really
a model anymore.
Also
Somethings cannot be modeled. Only theorize, looks for governing laws, or hypothesize.
Like fluid motion?
Human behaviors?
Etc.
@asterixgallier8102 atom model is actually not that complex.
The problem is. It is incomplete. We are getting more data. That affects our model. That's also why we have a lot of models for it in the first place.
But if you look at any models of the atom, you'll see it has a history from previous models.
Also there is something you need to know about models (any).
Models are structured on what you are trying to study from it.
@@asagiai4965
Atoms are not "simple", we have whole fields of physics just to study and model their quicks and behaviors and how they interact.
@@diadetediotedio6918 i said the "model" not the atom itself. You cannot make a very complex and specific model.
Because if you do it is not a model anymore. A model needs to represent something, not be something.
Also the behavior and structure of an atom can be simple or complicated depending on what you are talking about.
Shouldn't be the function LoC(project_age) be closer to logarifmic function? Or it represents a first derivative of that function?
@@_iPilot That really depends on the project. If it is a monolithic project, then it might keep declining slowly. If the project is more of a core surrounded by a swarm of downstream components/services, then the development speed might as well grow over time or stay constant.
I think the issue is that the y-axis should be labeled "LoC added", not just "LoC".
@@vyrp That is correct.
Great content
Doesn't blowing the code into small pieces here and there make the codebase harder to understand? Now u have to jump to so many places to understand something. Why is it not better to put related logics closer to each other? And it is probably gonna take a lot of time to refactor the code into something that looks simple
@@yoyocswpg Do you advocate for 5,000-lines-long classes? Because many things are related to many other things, and then that is what you get when you try to put them together - a 5,000-lines-lomg class. I think I was specific about that in the video.
@ I don't. But I don't advocate for one-liners or three-liners either. Some processes simply take more lines of code to implement. If a function communicates a concept, I think it is fine to have it with 100 lines of code. And I don't have to jump all over the codebase. If u hire someone new, they need to learn the existing abstractions or common classes you have created to know how to work with them. That takes a lot of time too. I mean why not just write code the way it is normally done. Creating these abstractions isn't really making anything happen.
@yoyocswpg Functions with 100 lines of code that do not require configuration and adaptation, such as deployment-based, user-based, or request-based variation, are truly rare. In most cases there will be no single block of 100 lines that does something, but a dozen of such blocks that are 90% the same in copy-and-paste manner. I am saying this from 25 years of experience in the industry.
Good one
“I didn't have time to write a short letter, so I wrote a long one instead.”
― Mark Twain
This goes for LoC too.
I once saw the database schemas for an insurance company. I'm still going to therapy. 😩
I led a development team a decade ago that developed an insurance solution. That database had over 1,000 tables.
The hard part is the 'art' of introducing types, the right amount is subjective. Superfluous types are as bad as no types and incorrect hierarchies are worse than none at all. Types are an abstraction and abstractions are never 'free'. For example, in java you can't tell mutable and immutable collections apart at an api level. Mutations just throw exceptions. Why? At the end of the day, it'd be 'expensive' to do it right.
Should you have a `PositiveFloat` type? How about `PostiveFloatPrecision5Scale2` type? Well, it depends! If your problem domain really does have hard constraints on numbers that keep appearing, and/or you are making actual business decisions based on numbers fitting this definition, a type may well be warranted. Should `Speed` and `LudicrousSpeed` be interchangeable at an api level? Probably not as they impact the business of flying the ship, not just technical concerns.
If you just happen to have a float in a larger immutable object, then a simple validation for the object is much more maintainable. Especially if the constraint is just a starting value and can vary thought processing as a `Float` normally would.
A random comment about simplicity and complexity I've seen in many projects over time
I think most of the maintenance work done in legacy projects is really about having state and side effects* being scattered all around in all places, a terrible amount of boilerplate and code that is extremely non-local (i.e. in which you need to visit dozens of locations to understand it's behavior). In this sense I think that OOP has something to be blamed of, don't you?
@@diadetediotedio6918 OOP has been applied by millions of people and it gets expected that vast numbers did not get it right at the time of their doing. Pick any other tool or method and it will end up equally prone to errors when used by inexperienced practitioners.
I am aware today of a lot of errors I made early in my career when I was given the responsibility but not the lead. I would return those designs to their maker and not approve them today. That is how it goes.
@@zoran-horvat
I actually agree with you that an unexperienced developer can make a mess with any tool, absolutely. I also think that part of the blame for messy legacy codebases is putting coding in the hands of people that were not even interested in coding in the first place (but that's another discussion).
What I'm saying here is that OOP is a negative factor, more than just being an innocent bystander in the hands of unexperienced developers. If you can agree that side effects make code harder to reason about and test (and judging for some videos I've seen in your channel, I think you can at least generally agree) then why not apply this to a paradigm that leads people into applying side effects all over the place when they are unexperienced?
Well, this is not a completely fixed position fo mine, I'm open to change, but I my point is that OOP has at least some blame here (not that it is the root cause or something).
@@diadetediotedio6918 I generally agree. But on the other hand, a more advanced modeling method means a gross reduction in the number of programmers. The software wouldn't be written at all, then.
All industries wanted their applications up and running, and so everyone who knows how to type on a keyboard wanted to be a programmer.
There was a rant once, I can't remember by whom, about making programming open to everyone. We the programmers wanted it that way, so we got it. I don't have much hard feelings about it, honestly. I do get sharper, though, when I am in charge of a project.
@@zoran-horvat
Oh, this is a good point. I thought on this as well, because if something has more friction to learn it would remove many codebases made by those people that are not interested in learning (and/or are scared to learn more complex paradigms like FP). So I think I can agree with you on this, OOP leads to more software being developed. More software being developer also means more mediocrity, so things kinda align in this sense.
This I can't judge, I can't discuss with the market choices. In the end things like OOP are a popular choice because they are good for those kind of things (badly written or not), which is good for consumers (because they generally don't need to care about good code or bad code, or maintainable code, and companies need money so it is as it is).
My point here is more a discussion not in the business side of things, but on the technical level, I think it is more productive for us to at least recognize that OOP induces some problematic behaviors (so we can lead to better business code being written by unexperienced devs by guiding them better with a more robust programming mindset), so I think it is a good think you take care on the projects you are in charge of, I tend to do the same.
Anyway, I think we reached a good level of mutual understanding, thank you for the discussion, it was good.
It's not about OOP in particular, it's about decomposition, coupling, and cohesion in general.
Too many companies allow for procedural exceptions to seep into the information architecture. Streamline your organization, it's procedural makeup and your information architecture will improve significantly. In other words: stamp out the exceptions. Problem is: most companies don't even _have_ a procedural framework - or it has deteriorated in time. It's part of "how we do things here" and its foundation is within the culture. Try to automate that.
8:30 But the methods wouldn't have to merge into Book if you just make them static and use a static class that acts like a namespace for finding them, like Extension Methods. I wonder what your thoughts on this talk are, and if it's a dumb idea or not: "Solving Problems the Clojure Way - Rafal Dittwald " ua-cam.com/video/vK1DazRK_a0/v-deo.html
With methods goes the state on which they operate. While you are right that in functional programming the behavior is defined separately, you must still remember that functional programming strongly supports composition of types.
In other words, you will end up with the same class diagram in FP, only calling them types rather than classes.
8:36 exactly classes in unreal engine 😢
I know...
counterargument: Javascript
@@MattDog_222 Choose your words wisely. What makes it a counter-ARGUMENT?
I might understand it as a counter-EXAMPLE, for instance, but hardly as an argument.
That's a single word not an argument. What's your point?
counterargument: TS
Man that class structure is insane... you have a 106 methods for a class that has like 12 fields? How did you even manage that... You factored what should have been two fields into 8 classes (no, I'm serious, look at PublicationInfo)?!
You have 27 methods for an edition of a book.
Here I was hoping noone actually ever does this. Then you people wonder why projects get so complex. It's because you pollute the environment the actual code that does the logic lives in.
@@nexovec What class hierarchy? There are no class hierarchies in that model.
and then your boss comes in and demands that the edition and publication date are different per publisher. And now you've ended up with a release class that becomes a wrapper for List that has 11 methods on it, out of which exactly 11 now should instead be defined on Publisher instead, and you won't refactor that, because you'd have to understand the implementation details of Book, which you won't, because that's not even the class you're dealing with at any point when doing these changes, you might not even know it exists, and also because it's the entire point of this extreme way of factoring code for you to not be bothered with "implementation details" (which in reality shape the architecture).
Unavoidably later someone comes along and reimplements the exact same methods or some new ones on Publisher, that person might not know about Release and they'd be technically in the right, except now you have behavior for a single entity arbitrarily divided between two classes.
@@zoran-horvat I mean the entire class structure. I edited that in so it's correct, sorry for the oversight.
@@zoran-horvat If I'm incorrect about anything else except the obvious total coding culture crash we seem to be having here, please remind me to correct myself.
@@nexovec What a pile of trash.
This is why I hate business software. It’s big it’s clunky, it shows the ineptness of management and the organization. Games, embedded even trading software is in everything better. It’s small lean and fast and to the point of the problem. Business software is all politics and idiotic exceptions of poor lawmaking, business decisions and ever changing processes and rules. You can never engineer properly designed systems when the foundation is shifting all the time. What we in engineering say: “you can fix stupid! You can’t engineer yourself out of quicksand”.
@@CallousCoder Still, it's business.
@ yeah it pays the bills because of the sheer stupidity and thus the ongoing changes. It’s just highly boring and demotivating compared to embedded-, system- or game software. It’s also ironic that the big money is in business software, because it requires very low skill level compared against to embedded, system or game engine development.
@@CallousCoder I know what you mean. Not that I am defending businesses.
OMG, there is too much inheritance for classes that have methods. Trust me, you would be better off not having it at all.
There is literally zero inheritance in the entire model. Random smearing. Tells a lot about you.
Writing code isn't always so simple because of object-oriented programming. Object-oriented programming does nothing but over-complicate and hide real code under layers and layers of abstraction all the while having no concern about the actual hardware that is running the software. It is needless complexity that adds needless difficulty.
When you begin with an overstatement, then you should not be surprised to see your logic start wandering randomly in the rest of it.
That's not OOP's fault, which is only a tool, it's a skill issue.
@krccmsitp2884 oop is not performant. It is extremely inefficient. That is a demonstrable fact
@@zoran-horvat it's a fact though. OOP is inefficient in memory use CPU-use and power use. It is the reason software is so slow. The inefficiencies of OOP nullify a decade of hardware improvement.
@@brotherpeter00 Come on man, is this really the channel for that? That story is old.