5 ms·

What exactly does "cheating" mean, and why doesn't it count if it solves a problem? With generics, the compiler will internally generate type-specific implement

What exactly does "cheating" mean, and why doesn't it count if it solves a problem? With generics, the compiler will internally generate type-specific implementations for each instantation, so the end result is the same. I'm not arguing against generics at all (I wish Go had it), but I'm also not sympathizing with this response.

logicallee 9y ago
It's not cheating, but you haven't rolled your own container: because in the end you don't have one. Let's make an analogy. Suppose a language didn't have tail recursion, but by using goto you could "roll your own." So we're on the same page, right? you get what I'm saying, and how rolling your own might look and work, right? Now suppose I said that without goto, it is literally impossible to roll your own tail recursion. (ignore whether this is true it's just an analogy.) You are saying, no it's not: you can patch the generated executable, so as long as it is possible to patch executables using go (i.e. if it can read and write binary files), then you can roll your own tail recursion even without goto, through binary patching post compilation. It might just be tedious or special-cased to one specific file but you can do it (you're saying) See the difference? It's not that patching an executable is "cheating." It's just that it's outside of the definition of rolling your own tail recursion. Likewise it's not that source code generation is "cheating." It's just outside the definition of rolling your own container. it's simply not what rolling your own means. after you've done it, you don't have a container. my analogy is a bit leaky but I think it gives insight, and I hope you see what I mean.
- lobster_johnson 9y ago
  I don't understand your analogy at all, but I believe the principal difference is that a code-generated container is a final, closed thing — it is not, for example, composable at compile time, so it doesn't fit into a larger type ecosystem. For example, you could write a Vec<T> and instantiate it for Vec<string>, which is fine, but then a different package may want to declare func sort<T>(values Vec<T>). Maybe one is an app and the other is a library. How do you now fit the two together? If the tool is smart enough and both of them are generated at the same time using the same tool and module files, it might work, but I don't think there's anything like this for Go right now, and either way, you have the "same tool" problem.
  - logicallee 9y ago
    Exactly! Which is why currently in Go rolling a container is "impossible." (it requires templates, as you showed with your Vec amd sort examples....something missing from the language.). It's very clear.
- deleted 9y ago
  [deleted]
coldtea 9y ago
>What exactly does "cheating" mean, and why doesn't it count if it solves a problem? It means it's a hackish kludge that's only a solution for the non-discerning programmer. Not everything that takes care of a problem is a proper solution.
albinofrenchy 9y ago
You might as well claim C has garbage collection since there are libraries for it. It's a hack. Might as well claim no language benefits from generics since you can always code gen. For practical issues you have things like compile time, extra tool dependencies and up front setup time to enable a given type. It makes c++ templates look down right elegant in comparison.
- lobster_johnson 9y ago
  A more appropriate analogy would be generating C code when developing apps in C. Which people do.
  - albinofrenchy 9y ago
    Yes, people absolutely use code generators with C. But they do this because of deficiencies in the language, and everyone basically agrees that C is the lowest common denominator in terms of languages -- it's portable assembly essentially. Go missing generics except for built-in containers; and then not having anything but the bare minimum for those built-ins is a critical defect of the language. The fact that you can work around that defect doesn't make it any less of a defect.
    - lobster_johnson 9y ago
      Sure, but it ain't cheating. I was specifically addressing that code generation is a practical solution to a missing feature in the language.
- deleted 9y ago
  [deleted]

logicallee 9y ago

It's not cheating, but you haven't rolled your own container: because in the end you don't have one. Let's make an analogy. Suppose a language didn't have tail recursion, but by using goto you could "roll your own." So we're on the same page, right? you get what I'm saying, and how rolling your own might look and work, right? Now suppose I said that without goto, it is literally impossible to roll your own tail recursion. (ignore whether this is true it's just an analogy.) You are saying, no it's not: you can patch the generated executable, so as long as it is possible to patch executables using go (i.e. if it can read and write binary files), then you can roll your own tail recursion even without goto, through binary patching post compilation. It might just be tedious or special-cased to one specific file but you can do it (you're saying) See the difference? It's not that patching an executable is "cheating." It's just that it's outside of the definition of rolling your own tail recursion. Likewise it's not that source code generation is "cheating." It's just outside the definition of rolling your own container. it's simply not what rolling your own means. after you've done it, you don't have a container. my analogy is a bit leaky but I think it gives insight, and I hope you see what I mean.

lobster_johnson 9y ago
I don't understand your analogy at all, but I believe the principal difference is that a code-generated container is a final, closed thing — it is not, for example, composable at compile time, so it doesn't fit into a larger type ecosystem. For example, you could write a Vec<T> and instantiate it for Vec<string>, which is fine, but then a different package may want to declare func sort<T>(values Vec<T>). Maybe one is an app and the other is a library. How do you now fit the two together? If the tool is smart enough and both of them are generated at the same time using the same tool and module files, it might work, but I don't think there's anything like this for Go right now, and either way, you have the "same tool" problem.
- logicallee 9y ago
  Exactly! Which is why currently in Go rolling a container is "impossible." (it requires templates, as you showed with your Vec amd sort examples....something missing from the language.). It's very clear.
deleted 9y ago
[deleted]

coldtea 9y ago

>What exactly does "cheating" mean, and why doesn't it count if it solves a problem? It means it's a hackish kludge that's only a solution for the non-discerning programmer. Not everything that takes care of a problem is a proper solution.

albinofrenchy 9y ago

You might as well claim C has garbage collection since there are libraries for it. It's a hack. Might as well claim no language benefits from generics since you can always code gen. For practical issues you have things like compile time, extra tool dependencies and up front setup time to enable a given type. It makes c++ templates look down right elegant in comparison.

lobster_johnson 9y ago
A more appropriate analogy would be generating C code when developing apps in C. Which people do.
- albinofrenchy 9y ago
  Yes, people absolutely use code generators with C. But they do this because of deficiencies in the language, and everyone basically agrees that C is the lowest common denominator in terms of languages -- it's portable assembly essentially. Go missing generics except for built-in containers; and then not having anything but the bare minimum for those built-ins is a critical defect of the language. The fact that you can work around that defect doesn't make it any less of a defect.
  - lobster_johnson 9y ago
    Sure, but it ain't cheating. I was specifically addressing that code generation is a practical solution to a missing feature in the language.
deleted 9y ago
[deleted]