>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.
And I don't like road bridges made of concrete and steel, preferring popsicle sticks. But engineering is not driven by feelings, so this is irrelevant.
> When you use a type to instantiate an object you are creating a Thing.
No, like you said earlier, you are creating a classification. The thing being classified isn't expressible. The languages we have are too limited for that. As a workaround we carry an implied assumption that underneath a classification lies a thing, but as you are finding out that quickly breaks down when there is not a clean association between the thing and the classification.
I like what you are thinking, though. I can see how our programming languages could be a lot better if there was such expressibility. But what that looks like is an unsolved computer science problem, I'm afraid.
> We are
No. Definitely not. We touched on it briefly at the beginning, which is perhaps what is confusing you, but we long moved past that to discuss how one might model the world, namely with expression in natural language, but to a lesser extent all programming languages.
> No other language makes you do this, so it's a problem with golang.
English also makes you do this. Failure to will result in an "aktshually, ..." error.
>And I don't like road bridges made of concrete and steel, preferring popsicle sticks. But engineering is not driven by feelings, so this is irrelevant.
The issue is you think I'm saying it has to be made out of popsicle sticks. I'm saying it you can use wood or steel and your saying something along the lines of ONLY use steel. Steel is the only way! That's go.
You're just going off into complete fantasy land thinking that my examples don't work. My examples work. Your examples also work. But my examples are MORE intuitive and simple. Your examples are convoluted and strange.
>No, like you said earlier, you are creating a classification. The thing being classified isn't expressible. The languages we have are too limited for that. As a workaround we carry an implied assumption that underneath a classification lies a thing, but as you are finding out that quickly breaks down when there is not a clean association between the thing and the classification.
When YOU instantiate the class, you are creating a THING. The instantiation is an expression of THAT thing.
Maybe you're referring to a type so narrow that it can only contain One thing? I believe TS has some ability to do this and Idris as well. Basically dependently typed languages allow this.
>I like what you are thinking, though. I can see how our programming languages could be a lot better if there was such expressibility. But what that looks like is an unsolved computer science problem, I'm afraid.
I don't think you have a clue about what you're talking about.
>No. Definitely not. We touched on it briefly at the beginning, which is perhaps what is confusing you, but we long moved past that to discuss how one might model the world, namely with expression in natural language, but to a lesser extent all programming languages.
No you moved on. I stayed on topic. I'm just using models of the world to show you how stupid go is. There are certain models of the world Go can't handle. That's all I'm doing. But I guess the details are getting too complicated for you that you inadverdantly lost track and moved on.
>English also makes you do this. Failure to will result in an "aktshually, ..." error.
Is this supposed to be a joke? English supports circular dependencies. Your equivalent of an error in english is a grammar error. Circular dependencies don't trigger a grammar error.
If you're trying to make a joke it's not even funny.
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.