FTR I have been using Go for 10 years and I certainly *have* read the spec - a lot, as you're well aware. I still occasionally make this mistake. Being able to explain *why* code is buggy doesn't prevent me from introducing a specific bug.
On Tue, Apr 11, 2023, 10:54 Axel Wagner <axel.wagner...@googlemail.com> wrote: > > > On Tue, Apr 11, 2023, 09:15 Jan Mercl <0xj...@gmail.com> wrote: > >> Resending to the mailing list as that was my intention but I errored >> again. Did the gmail UI changed again? >> >> ---------- Forwarded message --------- >> From: Jan Mercl <0xj...@gmail.com> >> Date: Tue, Apr 11, 2023 at 9:11 AM >> Subject: Re: [go-nuts] Redfining loop variable semantics - what's the >> plan? >> To: Axel Wagner <axel.wagner...@googlemail.com> >> >> >> On Tue, Apr 11, 2023 at 7:46 AM 'Axel Wagner' via golang-nuts >> <golang-nuts@googlegroups.com> wrote: >> >> > You shouldn't *have* to read the language spec to understand what Go >> code does. >> >> This is the most strange claim I have read about Go ever. >> >> You *must* read the language spec to understand what any programming >> language does. You *cannot* just guess because "other languages" do >> somethíng or use similar approaches and then be surprised you have >> guessed wrong. And as can be seen often, blame the language designers >> they didn't meet your unfounded expectations. >> > > I disagree strongly. I've never read *any* language spec but the Go one, > yet I can read most programs in many programming languages just fine. And I > don't think that's at all uncommon. I know people who have been writing and > maintaining widely used C software for 20 years or so, who I'm fairly > certain habe never read the C spec (and I don't know many people who have). > Really, Go is kind of an outlier for even *having* an approachable spec - > again a sentiment I've heard a lot. > > I would expect any programmer who did the Go tour to be able to > productively contribute to existing Go projects. Again, this is a strength > and IMO explicit design goal of Go, to be easy to pick up and use > productively. > > The spec exists to be able to disambiguate edge cases and answer questions > about *why* a certain program behaves the way it does when you don't > understand the behavior. Not to be a prerequisite to use the language. > > I strongly believe none of this is controversial. > > > >> What bothers me personally about the proposal and why I think it's a >> bad idea: The semantics will be defined by metadata. Any Go code >> snippet with such a loop, existing or future, all over the >> Internet/books/blogs, ... will become ambiguous in what it does >> without those metadata, which are not usually/always available >> alongside. You can say "other languages have that problem as well, see >> the different C, Perl, Python, you name it... versions". And you would >> be right. The point is that the Go 1 compatibility promise gave us the >> nice property of Go not suffering from such problems. >> >> I oppose the idea of introducing such a problem into the language >> voluntarily, 10+ years later. >> >> Maybe it would be better to bite the bullet, introduce Go 2 and >> embrace the shizma. /s >> >> -- >> 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/CAA40n-UQaK1dBvo-690Z1VZDZ%2B%2BKL7gQGWi5Mq3G4x4mrxZuyg%40mail.gmail.com >> . >> > -- 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/CAEkBMfHNsCaiVmJ0FD9t5WTY%3D5L%3DCwM64JAdNER7DufL4W7YCw%40mail.gmail.com.
