2 ms·

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

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

9rx 2y ago
> When YOU instantiate the class, you are creating a THING. No. You are instantiating a type of a thing. But, in the real world, a thing can be more than one type. Often it is sufficient to approximate the real world by assuming that one thing is only one type, but as you have found out that doesn't work when your program needs to see one thing as more than one type (e.g. an egg can be both a type of animal and a type of food). A programming language that has a concept for both "things" and "types" is interesting, but no language that you would write production software in today has such a concept I'm afraid. > I'm just using models of the world to show you how stupid go is. Go has its faults. Many of them. But it lacking features to allow you to paper over stupid design decisions I'm not sure is one of them. The problem here – and the problem with a lot of Go criticisms you find here, it seems – is that you haven't fully thought through what you are trying to do. A well conceived model of the world would not leave you with a circular dependency here. But I understand the appeal of trying to take the lazy route, minimizing the model to the smallest thing that makes sense to your internal monologue. It is certainly less typing to have just one egg type that you use for every conceivable egg use, whether it contains a chick, what you scramble for breakfast, and the chocolate delivered by the Easter Bunny. The good news is that there are many languages that are chock full of features to allow you to hack that in. If Go is not the right tool for the job: Great!

9rx 2y ago

> When YOU instantiate the class, you are creating a THING. No. You are instantiating a type of a thing. But, in the real world, a thing can be more than one type. Often it is sufficient to approximate the real world by assuming that one thing is only one type, but as you have found out that doesn't work when your program needs to see one thing as more than one type (e.g. an egg can be both a type of animal and a type of food). A programming language that has a concept for both "things" and "types" is interesting, but no language that you would write production software in today has such a concept I'm afraid. > I'm just using models of the world to show you how stupid go is. Go has its faults. Many of them. But it lacking features to allow you to paper over stupid design decisions I'm not sure is one of them. The problem here – and the problem with a lot of Go criticisms you find here, it seems – is that you haven't fully thought through what you are trying to do. A well conceived model of the world would not leave you with a circular dependency here. But I understand the appeal of trying to take the lazy route, minimizing the model to the smallest thing that makes sense to your internal monologue. It is certainly less typing to have just one egg type that you use for every conceivable egg use, whether it contains a chick, what you scramble for breakfast, and the chocolate delivered by the Easter Bunny. The good news is that there are many languages that are chock full of features to allow you to hack that in. If Go is not the right tool for the job: Great!