[go-nuts] Go language survey tool

2019-06-28 Thread Michael Jones
Announcing *Survey*, a general purpose utility that may be of interest to those curious about how how the Go language is used at a token level. When I posted a survey of the Go 1.13 source tree and of the Go Corpus a week ago, several people wrote and asked that I share. The program at that time

Re: [go-nuts] Go Language Survey

2019-06-12 Thread Dan Kortschak
This is interesting. I have exactly the opposite situation; up-down is much easier than significant left-right because of faulty saccades. On Wed, 2019-06-12 at 11:41 -0700, Michael Jones wrote: > Bakul, more good arguments. I have another motivation in the "?" > world that > I've not argued

Re: [go-nuts] Go Language Survey

2019-06-12 Thread 温博格
I agree that ? for simple choices is nice. But my C experience with nested ?s and with long expressions for one or both branches has not been nice. The mandatory {}s make Go's nested ifs more readable (but vertical). On Wed, Jun 12, 2019 at 2:42 PM Michael Jones wrote: > Roger, here's the same

Re: [go-nuts] Go Language Survey

2019-06-12 Thread Michael Jones
Roger, here's the same thing, but for Russ's corpus v0.01: https://gist.github.com/MichaelTJones/609589e05017da4be52bc2810e9df4e8 I've been comparing the two side by side and it's fascinating. Bakul, more good arguments. I have another motivation in the "?" world that I've not argued because it

Re: [go-nuts] Go Language Survey

2019-06-12 Thread Bakul Shah
On Jun 12, 2019, at 8:24 AM, Michael Jones wrote: > > Bakul, these are good points. > > On the second, I used to always write (C/C++): > > If (things are good) { > happy case > } else { > sad case > } > > so the nesting was that the all-good was the first code block even when >

Re: [go-nuts] Go Language Survey

2019-06-12 Thread Lucio
On Wednesday, 12 June 2019 17:25:19 UTC+2, Michael Jones wrote: > > Bakul, these are good points. > > > Nice work, Michael; nice comments, Bakul. It's nice when the philosophy behind intuition is given some solidity. I keep hoping to see more of Dijkstra's "A Discipline of Programming" leaking

Re: [go-nuts] Go Language Survey

2019-06-12 Thread roger peppe
I wonder whether the Go 1.13 code base is representative of Go in the wild. It might be interesting to see the results when run on the code in the Go corpus. https://github.com/rsc/corpus On Wed, 12 Jun 2019 at 14:08, Michael Jones wrote: > I've been working on a cascade of projects, each

Re: [go-nuts] Go Language Survey

2019-06-12 Thread Michael Jones
Bakul, these are good points. On the second, I used to always write (C/C++): If (things are good) { happy case } else { sad case } so the nesting was that the all-good was the first code block even when multiply nested and the exceptions came later. A blunt kind of literate programming

Re: [go-nuts] Go Language Survey

2019-06-12 Thread Bakul Shah
On Jun 12, 2019, at 7:36 AM, Michael Jones wrote: > > 128640 If statements, and just 8034 else, a 16:1 ratio. I'd like to > understand this better, There are two patterns that encourage this: x := v1 if someCond { x = v2 } And if someCond { return ... } The second pattern acts

Re: [go-nuts] Go Language Survey

2019-06-12 Thread Michael Jones
Yes, quite a bit there of note: More hex numbers than decimal. That was a surprise. The "0o" prefixed octal number literals just went in in the last two days. I think a gofix rewrite might be in order--it is more explicit and less vulnerable to mistake than the legacy 0377 style--despite a whole

Re: [go-nuts] Go Language Survey

2019-06-12 Thread Ian Lance Taylor
On Wed, Jun 12, 2019 at 6:08 AM Michael Jones wrote: > > I've been working on a cascade of projects, each needing the next as a part, > the most recent being rewriting text.Scanner. It was not a goal, but the > existing scanner does not do what I need (recognize Go operators, number > types,

[go-nuts] Go Language Survey

2019-06-12 Thread Michael Jones
I've been working on a cascade of projects, each needing the next as a part, the most recent being rewriting text.Scanner. It was not a goal, but the existing scanner does not do what I need (recognize Go operators, number types, and more) and my shim code was nearly as big as the standard library