On Thu, May 5, 2022 at 10:32 AM Will Faught <will.fau...@gmail.com> wrote: > > I think what you've put forth as counter arguments are instead principles, > like "simplicity is good," "complexity is bad," "changes have cost," and so > on. Principles aren't themselves arguments, so they can't be used as premises > in an argument.
We are evidently completely failing to communicate. I'm sorry, but I don't see any point in continuing to engage in this discussion. > In my humble opinion, I've seen the Go Team often use vague rationale. In my > humble opinion, it's why they were so wrong for over a decade about generics, > despite many, many people making the argument for adding generics over that > time. Even when generics were added, the Go Team only did it (according to > their statements that I've seen regarding this) due to a poll, not because of > any rational conclusion. It's a blind spot. I say this with love, because I > want Go to be the best it can be, and I support the Go Team's efforts to make > it so, but I believe the best way to get there is by the adversarial process > of argumentation, a battle of ideas, just like what is used in the U.S. > justice system to determine truth. In order for that to work, we have to have > a fair "fight," using arguments that can be deconstructed and judged/weighed > concretely. I'm sorry, but your comments about why generics were added to Go are incorrect. > If we can't agree on this, then there isn't any utility in debate. If you're > not interested in debate, then ultimately that's fine, but please make that > clear up front. The Go proposal process now specifies that proposals should > start as golang-nuts discussions, so that's why I'm here. This isn't intended > to be a casual discussion thread. > > All that said, assuming you agree, what is your full counter argument, or set > of counter arguments, to my initial argument for slice and map comparisons, > shaped by the principles you've listed? It doesn't need to be in a rigid > numbered list format, but it should be obvious how your counter arguments > could logically fit into that format. I and others have already presented the counter-arguments. Somebody also pointed to an earlier discussion thread which made the same counter-arguments. The fact that you don't agree with those counter-arguments does not mean that they haven't been presented. Language design is not a matter of precise arguments. It is a matter of weighing costs and benefits. If there were precise arguments for language design, we would all be using the same language (or perhaps one dynamically typed language, one statically typed language, etc.). In my opinion, the benefits of permitting slice and map comparisons in Go do not outweigh the costs. Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVuP_wxtiVmh2sUonuf1kwmTQdrSx71bzavToauUnSbpA%40mail.gmail.com.
