4 ms·

> 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 ac

> 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
> So your example is meaningless pedantic pointlessness. Okay, but it is not my example. It was the example given in the very first comment. It what was asserted to have created the circular dependency. > The concept of type is a categorization. Okay, sure, but it remains that things are decidedly not categorizations. And, as before, there is no known programming language that has a concept for things. It's an interesting idea! I can see that programming languages could benefit from having such a concept. If you happen to be looking for a CS research project, this just might be it. But if you just want to write production software using existing tools you're not going to find it. > I can still hatch those eggs if I want. Your pantry has suitable environmental conditions for incubation, does it? The environment necessary for incubation is not ideal for other foods normally kept in a pantry, so this doesn't really add up. But, hell, let's pretend you do. Do you still not want some way to identify those eggs being incubated and those eggs ready to eat for others, if not yourself, looking into your pantry? > Golang takes this arbitrary choice away. Okay, but we're not even talking about Go. We are barely even talking about programming. This model of yours doesn't even fit the real world. Come back with a better model and you won't leave other humans scratching their heads and you might even find the technology won't fight you so hard at the same time.
- ninetyninenine 2y ago
  >Okay, but it is not my example. It was the example given in the very first comment. It what was asserted to have created the circular dependency. Right and I'm saying I don't like your example. I prefer my example. And any other language is ok with my example except golang. That's my entire point. That's the problem, to get rid of that dependency I have to go with your example and that's bad because I don't have the choice. >Okay, sure, but it remains that things are decidedly not categorizations. And, as before, there is no known programming language that has a concept for things. It's an interesting idea! I can see that programming languages could benefit from having such a concept. If you happen to be looking for a CS research project, this just might be it. But if you just want to write production software using existing tools you're not going to find it. You said things don't exist in programming languages and I literally gave you an example of how it does exist. When you use a type to instantiate an object you are creating a Thing. The point of what I said here is that what you said is categorically wrong and you missed it. >Your pantry has suitable environmental conditions for incubation, does it? The environment necessary for incubation is not ideal for other foods normally kept in a pantry, so this doesn't really add up. But, hell, let's pretend you do. Do you still not want some way to identify those eggs being incubated and those eggs ready to eat for others, if not yourself, looking into your pantry? Again you're just choosing arbitrary perspectives out of an infinite amount of perspectives. My perspective is another arbitrary perspective. We can model the problem however the way we want at however resolution and detail from talking about incubation in pantries. I can easily just say I can take the egg in the pantry and put it back under the chicken. There. But this is BESIDES the point. The PROBLEM, again, with golang is that whatever perspective you choose, golang says it has to fit with their rules while the rest of the world and all other languages don't SAY this AT ALL. Other languages give you freedom, go gives you arbitrary restriction. >Okay, but we're not even talking about Go. We are barely even talking about programming. This model of yours doesn't even fit the real world. Come back with a better model and you won't leave other humans scratching their heads and you might even find the technology won't fight you so hard at the same time. We are. I think your out of touch with reality. I'm literally talking about what you can't do with golang. You can't simplify the model of the world to my specific model that I originally mentioned because it causes a circular dependency. But you can in other languages. I'm not fighting technology. The only thing I'm fighting is golang. No other language makes you do this, so it's a problem with golang. Models are arbitrary choices and they are useful depending on context. For example Newtons laws of motions are actually wrong but they are still useful for modelling things so in a computer program we can still choose to use it. We don't have to use the most "correct" model involving relativity. The thing with golang is that it's doing something like this. It's saying your model and it's dependencies has to match how I see the universe. You cannot choose the model.

9rx 2y ago

> So your example is meaningless pedantic pointlessness. Okay, but it is not my example. It was the example given in the very first comment. It what was asserted to have created the circular dependency. > The concept of type is a categorization. Okay, sure, but it remains that things are decidedly not categorizations. And, as before, there is no known programming language that has a concept for things. It's an interesting idea! I can see that programming languages could benefit from having such a concept. If you happen to be looking for a CS research project, this just might be it. But if you just want to write production software using existing tools you're not going to find it. > I can still hatch those eggs if I want. Your pantry has suitable environmental conditions for incubation, does it? The environment necessary for incubation is not ideal for other foods normally kept in a pantry, so this doesn't really add up. But, hell, let's pretend you do. Do you still not want some way to identify those eggs being incubated and those eggs ready to eat for others, if not yourself, looking into your pantry? > Golang takes this arbitrary choice away. Okay, but we're not even talking about Go. We are barely even talking about programming. This model of yours doesn't even fit the real world. Come back with a better model and you won't leave other humans scratching their heads and you might even find the technology won't fight you so hard at the same time.

ninetyninenine 2y ago
>Okay, but it is not my example. It was the example given in the very first comment. It what was asserted to have created the circular dependency. Right and I'm saying I don't like your example. I prefer my example. And any other language is ok with my example except golang. That's my entire point. That's the problem, to get rid of that dependency I have to go with your example and that's bad because I don't have the choice. >Okay, sure, but it remains that things are decidedly not categorizations. And, as before, there is no known programming language that has a concept for things. It's an interesting idea! I can see that programming languages could benefit from having such a concept. If you happen to be looking for a CS research project, this just might be it. But if you just want to write production software using existing tools you're not going to find it. You said things don't exist in programming languages and I literally gave you an example of how it does exist. When you use a type to instantiate an object you are creating a Thing. The point of what I said here is that what you said is categorically wrong and you missed it. >Your pantry has suitable environmental conditions for incubation, does it? The environment necessary for incubation is not ideal for other foods normally kept in a pantry, so this doesn't really add up. But, hell, let's pretend you do. Do you still not want some way to identify those eggs being incubated and those eggs ready to eat for others, if not yourself, looking into your pantry? Again you're just choosing arbitrary perspectives out of an infinite amount of perspectives. My perspective is another arbitrary perspective. We can model the problem however the way we want at however resolution and detail from talking about incubation in pantries. I can easily just say I can take the egg in the pantry and put it back under the chicken. There. But this is BESIDES the point. The PROBLEM, again, with golang is that whatever perspective you choose, golang says it has to fit with their rules while the rest of the world and all other languages don't SAY this AT ALL. Other languages give you freedom, go gives you arbitrary restriction. >Okay, but we're not even talking about Go. We are barely even talking about programming. This model of yours doesn't even fit the real world. Come back with a better model and you won't leave other humans scratching their heads and you might even find the technology won't fight you so hard at the same time. We are. I think your out of touch with reality. I'm literally talking about what you can't do with golang. You can't simplify the model of the world to my specific model that I originally mentioned because it causes a circular dependency. But you can in other languages. I'm not fighting technology. The only thing I'm fighting is golang. No other language makes you do this, so it's a problem with golang. Models are arbitrary choices and they are useful depending on context. For example Newtons laws of motions are actually wrong but they are still useful for modelling things so in a computer program we can still choose to use it. We don't have to use the most "correct" model involving relativity. The thing with golang is that it's doing something like this. It's saying your model and it's dependencies has to match how I see the universe. You cannot choose the model.