4 ms·

>Enjoy your scrambled bones, then, I guess. But even if you want to model the world as having only one egg type, that type decidedly does not cleanly fit into "

>Enjoy your scrambled bones, then, I guess. But even if you want to model the world as having only one egg type, that type decidedly does not cleanly fit into "animal" or "food", so your taxonomy doesn't work. scrambled bones my ass. There's no instance where that happens. I have a scramble function that takes an egg type as a parameter I don't know where you're pulling the scrambled bones from. I don't model the world that way, that's not my objective. I live on a farm, I'm just modelling things the way I modelled it on the farm. I organize my eggs into the food box and my hens into the chicken pen. I do this in the real world. I want to do the same thing in my programming and I can't. Understand? >Right, but we're talking about types, not things. Things can come in many different types. You even told us a story about how you consider eggs, which are the same thing, to be of different types, so this didn't go unnoticed by you earlier. If you make two different types, and you instantiate those two types you have two different things. I don't think you're getting it. Those two different things cannot represent the real world thing because the real world thing can hatch OR be eaten. The things you created can only do one or the other. >If you were to have a such a thing, wouldn't it go in something like "reproductive structure"? "types" is a strange fit alongside "animal" and "food". You have to do this because your Egg interface can't go into animal or food becuase it will cause a circular dependency. On my farm I don't have a bin or a box (aka type) called reproductive structure or types. I don't need to do this in the real world but I need to do this in go because Go is poorly designed. Look, I can make a folder called animals and food and I can put anything I want in those folders in other languages. In go, I can't. It's that simple. Go makes this arbitrary restriction out of nowhere and it makes things worse. You're shoehorning new nomenclature and reproductive concepts into your organizational scheme while I can run with what's done in REALITY with significantly less primitives. >Revisit the model in a way that actually reflects the real world and your circular dependencies are bound to disappear. I think you're out of touch with the real world. When you type things in the real world (aka putting things into a box or a pen) you don't care about dependencies. I don't put my eggs in the chicken pen because they came from the chickens. I put it in the food pantry. Understand? Folders are designed to do the activity I just mentioned, they are not designed to form some complicated taxonomy of unnecessary concepts.

9rx 2y ago
> I have a scramble function that takes an egg type as a parameter I don't know where you're pulling the scrambled bones from. Then you're in for an educational treat. Believe it or not, inside a "hatching egg" is a little chicken! And chickens have bones. As your scramble function accepts any type of egg, it may accept an egg that contains said bones. But it need not be that way. With consideration about your types, you can have the compiler ensure that you only allow "eating eggs" into your scramble function. Just like we normally take care in the real world to ensure the same kind of separation because most people would not be amused if their scrambled eggs contained bones. Apparently you roll the dice, but know that is unusual. > and you instantiate those two types you have two different things. I don't disagree, but I don't know of any programming language that has a concept for things. Certainly none that you would actually use for production software. Types are the pinnacle of popular computer science thus far. At some point you are going to have to accept that software and the real world aren't exactly the same. But revisit the model in a way that actually reflects the real world and your circular dependencies are bound to disappear. > I organize my eggs into the food box and my hens into the chicken pen. And the roosters? Those eggs aren't hatching otherwise... > You have to do this because your Egg interface can't go into animal or food becuase it will cause a circular dependency. But, most importantly, because it would otherwise be confusing for anyone else who has to work on the code. "Why is a chick about to leave its shell considered food? I don't know anyone who considers that to be food." is the first thing they are going to say upon encountering this codebase. Code is written for humans. Remember that. > I put it in the food pantry. You may put "eating eggs" in the pantry, but I can't imagine you put "hatching eggs" in the pantry. So why are you putting "hatching eggs" in "the food pantry" when taken to the computer? Again, this model you have doesn't even work on a human level, never mind any technical constraints when applied to software.
- ninetyninenine 2y ago
  > Then you're in for an educational treat. Believe it or not, inside a "hatching egg" is a little chicken! And chickens have bones. As your scramble function accepts any type of egg, it may accept an egg that contains said bones. Except the egg I modeled doesn’t do this and I generally don’t encounter this in the real world so I don’t have to account for it. So your example is meaningless pedantic pointlessness. > I don't disagree, but I don't know of any programming language that has a concept for things. The concept of type is a categorization. Instantiating a type is creating a thing that goes in that same category. You’re not getting it because this statement is categorically incorrect. > Types are the pinnacle of popular computer science thus far. At some point you are going to have to accept that software and the real world aren't exactly the same. Of course not. The food category and the animal category are not part of the real world. The universe doesn’t categorize things. Categories are made up bullshit by human beings. They aren’t real in any sense. You’re just not seeing this. What’s going on with golang is that it’s saying your arbitrary categorization of things IS REAL. When you don’t categorize it the go way you actually did something fundamentally wrong is what go tells you. And your issue is, you believe in this go philosophy. You think that what go tells you is real. Go says a chicken cannot go into the animal category and exist with an egg that goes into a food category. Go says if you try to model things this way something is fundamentally wrong with your understanding of categories and reality and it throws a compiler error to tell you so. The problem here is that you believe this bullshit. You think golang actually said something profound when really the designer was just an idiot. > But, most importantly, because it would otherwise be confusing for anyone else who has to work on the code. "Why is a chick about to leave its shell considered food? I don't know anyone who considers that to be food." is the first thing they are going to say upon encountering this codebase. Code is written for humans. Remember that. You’re out of touch with humans and you don’t see it. As a human I don’t think about accidentally finding chicken bones in my eggs so I categorize eggs as food and chickens as animals. What’s inhuman and overly pedantic is to consider every possible case and permutation of chickens and eggs and try to model everything in your program. How detailed do you want to go? Everything is made out of atoms so everything belongs in the same category? Be real. You are arbitrarily increasing the resolution of what is encompassed in your model to make some arbitrary and false point about domain modeling. What you’re not seeing is The model is made up by me to simplify things. In go I can’t make the model simple because I have to model things according to golang. > You may put "eating eggs" in the pantry, but I can't imagine you put "hatching eggs" in the pantry. So why are you putting "hatching eggs" in "the food pantry" when taken to the computer? Again, this model you have doesn't even work on a human level, never mind any technical constraints when applied to software. I put eggs in the pantry. I can still hatch those eggs if I want. I can eat them too. You put technical constraints on reality for no other arbitrary reason other then to satisfy gos dependency rules. In your model you restricted your abilities. I changed my mind and I want to use half of my eggs in the pantry for hatching. Your “domain modeling” doesn’t allow for this. Look this is all arbitrary bullshit. You’re just going to keep making up cases where your model is right but for every case there is also a case where mine is right and yours is wrong. This is because there’s an infinite amount of perspectives to look at this subject. How we choose to look at that subject is an arbitrary choice. You want to make two types of eggs and categorize it that way?be my fucking guest. Most people who farm don’t do it this way but go ahead. Golang takes this arbitrary choice away. It tells everyone that eggs don’t exist. It’s either a hatching egg or an eatable egg. You live in a universe of golang that tells you that this is the only fundamental way to categorize things: by a dependency tree. Because we don’t know which came first, the chicken or the egg. In your universe of golang that you live in your saying it’s a fundamental truth that we can therefore never categorize chickens as animals and eggs as food. We must destroy the concept of an egg and realize there are two types of eggs. One that is eatable food and Another that is a hatchable animal. That’s how your brain sees reality. If this is the case so be it. Can’t be fixed. I can’t change you. More likely you’re just stubborn.

9rx 2y ago

> I have a scramble function that takes an egg type as a parameter I don't know where you're pulling the scrambled bones from. Then you're in for an educational treat. Believe it or not, inside a "hatching egg" is a little chicken! And chickens have bones. As your scramble function accepts any type of egg, it may accept an egg that contains said bones. But it need not be that way. With consideration about your types, you can have the compiler ensure that you only allow "eating eggs" into your scramble function. Just like we normally take care in the real world to ensure the same kind of separation because most people would not be amused if their scrambled eggs contained bones. Apparently you roll the dice, but know that is unusual. > and you instantiate those two types you have two different things. I don't disagree, but I don't know of any programming language that has a concept for things. Certainly none that you would actually use for production software. Types are the pinnacle of popular computer science thus far. At some point you are going to have to accept that software and the real world aren't exactly the same. But revisit the model in a way that actually reflects the real world and your circular dependencies are bound to disappear. > I organize my eggs into the food box and my hens into the chicken pen. And the roosters? Those eggs aren't hatching otherwise... > You have to do this because your Egg interface can't go into animal or food becuase it will cause a circular dependency. But, most importantly, because it would otherwise be confusing for anyone else who has to work on the code. "Why is a chick about to leave its shell considered food? I don't know anyone who considers that to be food." is the first thing they are going to say upon encountering this codebase. Code is written for humans. Remember that. > I put it in the food pantry. You may put "eating eggs" in the pantry, but I can't imagine you put "hatching eggs" in the pantry. So why are you putting "hatching eggs" in "the food pantry" when taken to the computer? Again, this model you have doesn't even work on a human level, never mind any technical constraints when applied to software.

ninetyninenine 2y ago
> Then you're in for an educational treat. Believe it or not, inside a "hatching egg" is a little chicken! And chickens have bones. As your scramble function accepts any type of egg, it may accept an egg that contains said bones. Except the egg I modeled doesn’t do this and I generally don’t encounter this in the real world so I don’t have to account for it. So your example is meaningless pedantic pointlessness. > I don't disagree, but I don't know of any programming language that has a concept for things. The concept of type is a categorization. Instantiating a type is creating a thing that goes in that same category. You’re not getting it because this statement is categorically incorrect. > Types are the pinnacle of popular computer science thus far. At some point you are going to have to accept that software and the real world aren't exactly the same. Of course not. The food category and the animal category are not part of the real world. The universe doesn’t categorize things. Categories are made up bullshit by human beings. They aren’t real in any sense. You’re just not seeing this. What’s going on with golang is that it’s saying your arbitrary categorization of things IS REAL. When you don’t categorize it the go way you actually did something fundamentally wrong is what go tells you. And your issue is, you believe in this go philosophy. You think that what go tells you is real. Go says a chicken cannot go into the animal category and exist with an egg that goes into a food category. Go says if you try to model things this way something is fundamentally wrong with your understanding of categories and reality and it throws a compiler error to tell you so. The problem here is that you believe this bullshit. You think golang actually said something profound when really the designer was just an idiot. > But, most importantly, because it would otherwise be confusing for anyone else who has to work on the code. "Why is a chick about to leave its shell considered food? I don't know anyone who considers that to be food." is the first thing they are going to say upon encountering this codebase. Code is written for humans. Remember that. You’re out of touch with humans and you don’t see it. As a human I don’t think about accidentally finding chicken bones in my eggs so I categorize eggs as food and chickens as animals. What’s inhuman and overly pedantic is to consider every possible case and permutation of chickens and eggs and try to model everything in your program. How detailed do you want to go? Everything is made out of atoms so everything belongs in the same category? Be real. You are arbitrarily increasing the resolution of what is encompassed in your model to make some arbitrary and false point about domain modeling. What you’re not seeing is The model is made up by me to simplify things. In go I can’t make the model simple because I have to model things according to golang. > You may put "eating eggs" in the pantry, but I can't imagine you put "hatching eggs" in the pantry. So why are you putting "hatching eggs" in "the food pantry" when taken to the computer? Again, this model you have doesn't even work on a human level, never mind any technical constraints when applied to software. I put eggs in the pantry. I can still hatch those eggs if I want. I can eat them too. You put technical constraints on reality for no other arbitrary reason other then to satisfy gos dependency rules. In your model you restricted your abilities. I changed my mind and I want to use half of my eggs in the pantry for hatching. Your “domain modeling” doesn’t allow for this. Look this is all arbitrary bullshit. You’re just going to keep making up cases where your model is right but for every case there is also a case where mine is right and yours is wrong. This is because there’s an infinite amount of perspectives to look at this subject. How we choose to look at that subject is an arbitrary choice. You want to make two types of eggs and categorize it that way?be my fucking guest. Most people who farm don’t do it this way but go ahead. Golang takes this arbitrary choice away. It tells everyone that eggs don’t exist. It’s either a hatching egg or an eatable egg. You live in a universe of golang that tells you that this is the only fundamental way to categorize things: by a dependency tree. Because we don’t know which came first, the chicken or the egg. In your universe of golang that you live in your saying it’s a fundamental truth that we can therefore never categorize chickens as animals and eggs as food. We must destroy the concept of an egg and realize there are two types of eggs. One that is eatable food and Another that is a hatchable animal. That’s how your brain sees reality. If this is the case so be it. Can’t be fixed. I can’t change you. More likely you’re just stubborn.