I think that your original interpretation of TL's questions is the correct one, and the one that I read when I read all of this posts. I don't think that it's a fair characterisation that he is asking about possibility rather that design, even in the post that this was a reply to.
I can understand his position entirely, and his frustration that might lead to the epic threads that we see here. When I was starting to use Go, I often asked questions about the motivation/reason behind prohibitions or approaches in Go to be answered, extremely frustrating, by references to the spec (I find understanding things unless I know why they are the way they are - see Katrina Owen's great discussion about knowledge construction and its graphical basis in "Mind the Gap" for why rationale facilitates knowledge graph growth). This has improved here, in that people now more often answer with design justifications, though still there is a cultural habit or responding with essentially that it is "because". This would have been a significantly shorter thread if there had been a clear explanation of the motivation behind slice conversion restrictions early. This could have been after about the second (certainly by fourth) post from TL where it became clear that he was asking about motivation rather than mechanics (the initial post was ambiguous). Dan On Sat, 2016-08-27 at 09:56 -0700, Michael Jones wrote: > TL, I have been confused by this thread, your similar questions, and > in fact, most of your emails—until now. > > > > When you write ‘Why can’t X’ as you often do, I have presumed that > this was a casual and imprecise form of expressing the question “what > is the reason why a different path was chosen.” Now, based on this, I > see it differently. I think you mean it literally. I imagine myself > walking beside you and you saying, “Why can’t trees be blue? Why can’t > dogs have square heads? Why can’t cars have windows in the tires? Why > don’t cats and pigs swim?” Which is to say, it seems that you are > writing email as a way to share a stream of consciousness that every > aspect of reality—every choice, decision, evolutionary outcome, taste, > desire—could in fact be different in some other place or time or > circumstance. > > > > Now that the question unfolds as “Why is it not possible that X” (as > you wrote from the start) then the answer to your emails is, “It is > possible,” possible as in, “in a different language, with a different > goal, on a hypothetical computer, if the most common programmer errors > were not as they are, etc.” In engineering, nearly everything is > possible. Not all of the possibilities are good, wise, or desirable > though, so I think many here thought these other attributes were > implied as part of your question. I did before but now do not. > > > > In your spirit of “Why can’t” as in “prove that it is impossible” (of > course such proofs are impossible), I offer examples of the uncommon > but possible. > > > > > > > > A different question, “Why is X disallowed in Go,” is actually much > more educational. The example below, that was given you by amkguo, is > the example that I thought of right at first—not about “why can’t > bytes be interchangeable” but “why are Types treated as separate > species.” This is a great topic. Because of huge human experience that > mixing types by concept (adding two kinds of temperature or mass) > results in unfortunate outcomes (many!) and similar experience in > debugging as the result of many languages, C and C++ among them, doing > natural-seeming invisible coercion between types. Type coercion in > specific and invisible actions generally are a trouble area in > large-scale software development. This is why the Go team (superstars > with UNIX, C, major Gnu C/C++ implementation, Plan 9, Inferno, and > maybe more importantly, careful study of common software development > problems by 10,000+ programmers Google) disallowed it during the > design of Go and instead require explicit casts (as in “var a int = 3; > b := float64(a)”), why they treat Types as non-mixing species, and why > the affordances around this are very limited. > > > > I gave a talk in Madrid about Go as a software engineering approach > assisted by a computer language. This seems a nice educational way to > avoid many of the “but C allows …” or “it should be technically > possible to…” confusions. > > > > Michael -- Omnes mundum facimus. Dan Kortschak <dan.kortsc...@adelaide.edu.au> F9B3 3810 C4DD E214 347C B8DA D879 B7A7 EECC 5A40 10C7 EEF4 A467 89C9 CA00 70DF C18F 3421 A744 607C -- 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. For more options, visit https://groups.google.com/d/optout.
