[go-nuts] Go language survey tool

[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
was just part of my test suite for a lexer so it was far from ready to
share; it's now ready and available:

https://github.com/MichaelTJones/survey

When you get that it will also get (or you will need to get)

https://github.com/MichaelTJones/lex

which is much like scanner but knows about Go operators and is careful to
note details of what it parses (not "number" but "number/of the legacy
octal form"). I'm still working on that but it suffices for the needs of
survey.

Hope it is helpful to you.

-- 

*Michael T. jonesmichael.jo...@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/CALoEmQyHjc3tG0deRNAUmWpAGL4pyq1D5RocdUjd2E4JMToFQQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go Language Survey

[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 because it is personal/not general, but a decade ago
> I had
> two detached retinas, surgeries, and imperfect recovery. Part of my
> vision
> that I lost is just below the center...maybe -15 degrees to -40
> degrees.
> The brain knows when I want to see things things there and moves the
> eyes
> around to gather that part of the visual field. This "hunting" is
> tiring of
> the muscles and causes issues. left-to-right density is easy for me,
> vertical is very bad. Your:
> 
> x := b? 2 : 1
> 
> is instantaneous, a sight read; while the:
> 
> var x int
> if b {
>   x = 2
> } else {
>   x = 1
> }
> 
> and
> 
> x := 1
> if b {
>   x = 2
> }
> 
> ...feel like climbing Everest. It is hard to explain the difficulty.
> Fortunately it is not a widespread problem. Certainly not Go's
> problem, but
> I'd pay double for a "wide" mode where gofmt tolerated "var x int; if
> b { x
> = 2 } else { x = 1 }". In fact, now that i've just seen this, I am
> going to
> make a local version and hook it to vs code. Why did I not think of
> this
> before! Wow.

-- 
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/e256bf8c6f380acf4999385f4d1e557f1f201d6b.camel%40kortschak.io.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go Language Survey

[温博格]

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 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 is personal/not general, but a decade ago I
> had two detached retinas, surgeries, and imperfect recovery. Part of my
> vision that I lost is just below the center...maybe -15 degrees to -40
> degrees. The brain knows when I want to see things things there and moves
> the eyes around to gather that part of the visual field. This "hunting" is
> tiring of the muscles and causes issues. left-to-right density is easy for
> me, vertical is very bad. Your:
>
> x := b? 2 : 1
>
> is instantaneous, a sight read; while the:
>
> var x int
> if b {
>   x = 2
> } else {
>   x = 1
> }
>
> and
>
> x := 1
> if b {
>   x = 2
> }
>
> ...feel like climbing Everest. It is hard to explain the difficulty.
> Fortunately it is not a widespread problem. Certainly not Go's problem, but
> I'd pay double for a "wide" mode where gofmt tolerated "var x int; if b { x
> = 2 } else { x = 1 }". In fact, now that i've just seen this, I am going
> to make a local version and hook it to vs code. Why did I not think of this
> before! Wow.
>
> On Wed, Jun 12, 2019 at 9:24 AM Bakul Shah  wrote:
>
>> 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
>> multiply nested and the exceptions came later. A blunt kind of literate
>> programming that wants to talk about the 99% case first and the weird
>> things later. In Go I've converted to talk about problems all the way to
>> the bitter end and then when you run out of problems, do the job. Now that
>> you point it out, "else" falls by the wayside in this situation because it
>> is else when you did not return already. Each Go-style if-err-die "clause"
>> is consuming an else. Thank you. I had not thought of it so clearly.
>>
>> It's just a different style. Here you are chopping off "sad cases" until
>> you are left with the big fat happy case! And by returning ASAP for the
>> sad cases, you reduce indentation quite a bit, which helps readability.
>>
>> >
>> > The first is a good point too. The debate about the ternary operator
>> might be better viewed as a completion of short variable declaration. Block
>> scope means is not possible to write...
>> >
>> > if b {
>> > x := 1
>> > } else {
>> > x := 2
>> > }
>> > :
>> > use X
>> >
>> > ...so the benefits of short variable declaration are lost to a choice
>> between redundancy as you show:
>> >
>> > x := 1
>> > if b {
>> > x = 2
>> > }
>> >
>> > which hides the intent -- the if b is the intent and that's not evident
>> from x := 1. The intent is "x := either 1 or 2 depending" and that is well
>> expressible only when the := is in the outer scope and the "1 or 2" are
>> expressions from an inner one being transported across the lexical boundary
>> by an operator -- the "depending" operator whatever its name or form might
>> be.
>>
>> You can almost speed-read straight line code but as soon as you
>> encounter if or switch (or other control flow changing part) you
>> have to stop and regroup. This is why (for me)
>>
>> x := b? 2 : 1
>>
>> is far easier to read than either
>>
>> var x int
>> if b {
>>   x = 2
>> } else {
>>   x = 1
>> }
>>
>> or worse,
>>
>> x := 1
>> if b {
>>   x = 2
>> }
>>
>>
>> > x := {1,2}[b]
>>
>> This requires evaluating both alternatives. This may not
>> even be possible:
>>
>> x := p == nil? 10 : p.val
>>
>> or may had extra side-effects:
>>
>> x := {f1(), f2()}[b]
>>
>> This can also a problem with
>>
>> x := f1()
>> if b { x = f2() }
>>
>>
>>
>>
>
> --
>
> *Michael T. jonesmichael.jo...@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/CALoEmQw10H-t1GdVG_PDxiPVtaUGJ3uvsBUXyt6adMiPOAAnow%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google 

Re: [go-nuts] Go Language Survey

[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 is personal/not general, but a decade ago I had
two detached retinas, surgeries, and imperfect recovery. Part of my vision
that I lost is just below the center...maybe -15 degrees to -40 degrees.
The brain knows when I want to see things things there and moves the eyes
around to gather that part of the visual field. This "hunting" is tiring of
the muscles and causes issues. left-to-right density is easy for me,
vertical is very bad. Your:

x := b? 2 : 1

is instantaneous, a sight read; while the:

var x int
if b {
  x = 2
} else {
  x = 1
}

and

x := 1
if b {
  x = 2
}

...feel like climbing Everest. It is hard to explain the difficulty.
Fortunately it is not a widespread problem. Certainly not Go's problem, but
I'd pay double for a "wide" mode where gofmt tolerated "var x int; if b { x
= 2 } else { x = 1 }". In fact, now that i've just seen this, I am going to
make a local version and hook it to vs code. Why did I not think of this
before! Wow.

On Wed, Jun 12, 2019 at 9:24 AM Bakul Shah  wrote:

> 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
> multiply nested and the exceptions came later. A blunt kind of literate
> programming that wants to talk about the 99% case first and the weird
> things later. In Go I've converted to talk about problems all the way to
> the bitter end and then when you run out of problems, do the job. Now that
> you point it out, "else" falls by the wayside in this situation because it
> is else when you did not return already. Each Go-style if-err-die "clause"
> is consuming an else. Thank you. I had not thought of it so clearly.
>
> It's just a different style. Here you are chopping off "sad cases" until
> you are left with the big fat happy case! And by returning ASAP for the
> sad cases, you reduce indentation quite a bit, which helps readability.
>
> >
> > The first is a good point too. The debate about the ternary operator
> might be better viewed as a completion of short variable declaration. Block
> scope means is not possible to write...
> >
> > if b {
> > x := 1
> > } else {
> > x := 2
> > }
> > :
> > use X
> >
> > ...so the benefits of short variable declaration are lost to a choice
> between redundancy as you show:
> >
> > x := 1
> > if b {
> > x = 2
> > }
> >
> > which hides the intent -- the if b is the intent and that's not evident
> from x := 1. The intent is "x := either 1 or 2 depending" and that is well
> expressible only when the := is in the outer scope and the "1 or 2" are
> expressions from an inner one being transported across the lexical boundary
> by an operator -- the "depending" operator whatever its name or form might
> be.
>
> You can almost speed-read straight line code but as soon as you
> encounter if or switch (or other control flow changing part) you
> have to stop and regroup. This is why (for me)
>
> x := b? 2 : 1
>
> is far easier to read than either
>
> var x int
> if b {
>   x = 2
> } else {
>   x = 1
> }
>
> or worse,
>
> x := 1
> if b {
>   x = 2
> }
>
>
> > x := {1,2}[b]
>
> This requires evaluating both alternatives. This may not
> even be possible:
>
> x := p == nil? 10 : p.val
>
> or may had extra side-effects:
>
> x := {f1(), f2()}[b]
>
> This can also a problem with
>
> x := f1()
> if b { x = f2() }
>
>
>
>

-- 

*Michael T. jonesmichael.jo...@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/CALoEmQw10H-t1GdVG_PDxiPVtaUGJ3uvsBUXyt6adMiPOAAnow%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go Language Survey

[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 
> multiply nested and the exceptions came later. A blunt kind of literate 
> programming that wants to talk about the 99% case first and the weird things 
> later. In Go I've converted to talk about problems all the way to the bitter 
> end and then when you run out of problems, do the job. Now that you point it 
> out, "else" falls by the wayside in this situation because it is else when 
> you did not return already. Each Go-style if-err-die "clause" is consuming an 
> else. Thank you. I had not thought of it so clearly.

It's just a different style. Here you are chopping off "sad cases" until
you are left with the big fat happy case! And by returning ASAP for the
sad cases, you reduce indentation quite a bit, which helps readability.

> 
> The first is a good point too. The debate about the ternary operator might be 
> better viewed as a completion of short variable declaration. Block scope 
> means is not possible to write...
> 
> if b {
> x := 1
> } else {
> x := 2
> }
> :
> use X
> 
> ...so the benefits of short variable declaration are lost to a choice between 
> redundancy as you show:
> 
> x := 1
> if b {
> x = 2
> }
> 
> which hides the intent -- the if b is the intent and that's not evident from 
> x := 1. The intent is "x := either 1 or 2 depending" and that is well 
> expressible only when the := is in the outer scope and the "1 or 2" are 
> expressions from an inner one being transported across the lexical boundary 
> by an operator -- the "depending" operator whatever its name or form might be.

You can almost speed-read straight line code but as soon as you
encounter if or switch (or other control flow changing part) you
have to stop and regroup. This is why (for me)

x := b? 2 : 1

is far easier to read than either

var x int
if b {
  x = 2
} else {
  x = 1
}

or worse,

x := 1
if b {
  x = 2
}


> x := {1,2}[b]

This requires evaluating both alternatives. This may not
even be possible:

x := p == nil? 10 : p.val

or may had extra side-effects:

x := {f1(), f2()}[b]

This can also a problem with

x := f1()
if b { x = f2() }



-- 
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/94BE2E16-59A0-4984-8D47-E2D3B28E6C98%40bitblocks.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go Language Survey

[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 
into the Go psyche, but there have been a few too many diversions that may 
never be reversed.

Personally, I see exactly zero benefit in x++ or x--, now that these are 
more clearly represented as x += 1 and x -= 1. I have discarded them from 
my idioms. But that's just me. I'm hoping no one will find it necessary to 
edit my code to correct this :-).

Lucio.

-- 
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/caf98fc1-b371-4b6a-baef-62cf078d6a9c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go Language Survey

[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 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 scanner itself, so I just sat down an rewrote it cleanly.
>
> To test beyond hand-crafted edge cases it seemed good to try it against a
> large body of Go code. I chose the Go 1.13 code base, and because the
> results are interesting on their own beyond my purpose of code testing, I
> thought to share what I've noticed as a Github Gist on the subject of the
> "Go Popularity Contest"—what are the most used types, most referenced
> packages, most and least popular operators, etc. The data are interesting,
> but I'll let it speak for itself. Find it here:
>
> https://gist.github.com/MichaelTJones/ca0fd339401ebbe79b9cbb5044afcfe2
>
> Michael
>
> P.S. Generated by go test. I just cut off the "passed" line and posted it.
> ;-)
>
> --
>
> *Michael T. jonesmichael.jo...@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/CALoEmQzK3v4V%2BRYWZorfX0Nst%2BOXwzP9e51mCDm2ri-4jfzXyA%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAJhgachZMnWJYv2Qe33rWTpQZJsgz6r3un1Dq2vcv2Pz_ENNFA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go Language Survey

[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 that wants to talk about the 99% case first and the weird
things later. In Go I've converted to talk about problems all the way to
the bitter end and then when you run out of problems, do the job. Now that
you point it out, "else" falls by the wayside in this situation because it
is else when you did not return already. Each Go-style if-err-die "clause"
is consuming an else. Thank you. I had not thought of it so clearly.

The first is a good point too. The debate about the ternary operator might
be better viewed as a *completion* of short variable declaration. Block
scope means is not possible to write...

if b {
x := 1
} else {
x := 2
}
:
use X

...so the benefits of short variable declaration are lost to a choice
between redundancy as you show:

x := 1
if b {
x = 2
}

which hides the intent -- the if b is the intent and that's not evident
from x := 1. The intent is "x := either 1 or 2 depending" and that is well
expressible only when the := is in the outer scope and the "1 or 2" are
expressions from an inner one being transported across the lexical boundary
by an operator -- the "depending" operator whatever its name or form might
be.

The pro-? forces might better petition under the "make short assignments
complete" banner.

x := if b {1} else {2}
x := switch b {case true: 1; case false: 2}
x := b ? 1 : 2

or, my dream scenario, which is just a dream because of too many moving
parts to sell all at once:

allow bool to int/uint casting with obvious meaning T=>1, F=>0
allow "implicit" types in literal definitions like this:

x := {1,2}[int(b)]

...or even if one could dare hope for automatic coercion of the harmless
bool...

x := {1,2}[b]

as in

workers := {runtime.NumCPU(),1}[*ParallelMode]

...oh to dream.



On Wed, Jun 12, 2019 at 7:56 AM Bakul Shah  wrote:

> 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 sort of as a filter. Which is useful (fewer
> choices left).
>
> The first pattern is due to a lack of C’s ?: construct. [In light of that
> it is amusing to see try as a “function” being proposed that even does a
> conditional return!]
>


-- 

*Michael T. jonesmichael.jo...@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/CALoEmQw5xCLMFj2k9exBBuvr0SBL2zifZoUER0tmiViyGWJt0A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go Language Survey

[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 sort of as a filter. Which is useful (fewer choices 
left).

The first pattern is due to a lack of C’s ?: construct. [In light of that it is 
amusing to see try as a “function” being proposed that even does a conditional 
return!]

-- 
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/44D09A2F-CCC7-492D-B06C-6D870E225283%40bitblocks.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go Language Survey

[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 career of
the other from the PDP-8 onward.

128640 If statements, and just 8034 else, a 16:1 ratio. I'd like to
understand this better, but my test is just a lexer and not a parser so I
don't have much context to draw conclusions about this specifically.
However it seems such a huge ratio that switch must be carrying the load.
There are 5024 switch statements and 24903 cases, so that's "4 virtual
elses" per switch in some broad sense.

Type is well used. 2x as much as struct, so even if half are "type X struct
{...}" the other half are not.

The import frequency is not interpretable beyond "every package imports
something" because of the inner list in imports as typically written and
that's available to a parser but not at the lexical level. I could hack it
to look at lines between the parens after import, but that's beyond the
"test the lexer" goal.

The default to switch ratio is high, and there is at most one per, so this
means 60% of switch statements have a default, or by extension, express
if-then-else if-else-if-else logic with a final clauseless else.

Few fallthrough statements and that's natural. There were few cases outside
Duff's Device where C/C++ code is allowed to fall through by default.
[Having just written a lexer, I can share that would I think be much better
than the switch's fallthrough would be a way to say, "now that I'm in this
case, I've changed my mind and want to PROCEED with the case testing
starting with the next case." That would be swell and there is no way to do
it.)

Byte by that name is quite popular compared to its other identity, uint8.
[Opinion: never have been comfortable about this one. There are no living
machines with non 8-bit bytes, so the generality of "byte is the natural
size for a byte" is a stretch here, as would be 1 for the size of a bit.]

Using true is almost 3x false. I wonder if that is natural or if the
default value of zero/false is behind it.

Lots of panics and not many recovers.

Operators are interesting. nearly 2.5x the != than ==. Perhaps "err != nil"
is the story. A lot more < than >, which is curious...presumably from for
loops, but can't tell at the token level. Way more left shifts than right.
Not true in my own code, so interesting. Some disjunctive/conjunctive
dissonance: 3x the && as ||. 7 x the ++ as --. I guess people like to count
up, even when counting down has the advantage of the expensive load being
done once and the test being against zero. 5x += than -=, surprising.
Pretty low incidence of &^ and &^=, not true in my code at all, so I
suppose the BIC "Bit Clear" of PDP-11 is not a meme. That's surprising to
me: a|=b, sets the b bits in a, a&^b, clears the b bits in a. They are a
team, yet | is  50x the usage of &^. Maybe because C did not have it and
C++ copied and Java copied and people have not understood? These should be
peers. /= is not popular, and %= even less so. I use them both but I may be
the only one (there is some code like this in Big from way back.)

External references shows that the Go team writes lots of tests, and that
unsafe is wildly popular.

The most popular character constant is '0' 3x '9' so it's not all ('0' <=
ch && ch <= '9') ... there are some extra '0's in there.

On Wed, Jun 12, 2019 at 6:49 AM Ian Lance Taylor  wrote:

> 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, and more) and my shim code was nearly as big as the standard
> library scanner itself, so I just sat down an rewrote it cleanly.
> >
> > To test beyond hand-crafted edge cases it seemed good to try it against
> a large body of Go code. I chose the Go 1.13 code base, and because the
> results are interesting on their own beyond my purpose of code testing, I
> thought to share what I've noticed as a Github Gist on the subject of the
> "Go Popularity Contest"—what are the most used types, most referenced
> packages, most and least popular operators, etc. The data are interesting,
> but I'll let it speak for itself. Find it here:
> >
> > https://gist.github.com/MichaelTJones/ca0fd339401ebbe79b9cbb5044afcfe2
>
> Pretty interesting.  Thanks.
>
> I note that "goto" is more common than "select".  That has to be an
> artifact of the code base.
>
> Ian
>


-- 

*Michael T. jonesmichael.jo...@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 

Re: [go-nuts] Go Language Survey

[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, and more) and my shim code was nearly as big as the standard library 
> scanner itself, so I just sat down an rewrote it cleanly.
>
> To test beyond hand-crafted edge cases it seemed good to try it against a 
> large body of Go code. I chose the Go 1.13 code base, and because the results 
> are interesting on their own beyond my purpose of code testing, I thought to 
> share what I've noticed as a Github Gist on the subject of the "Go Popularity 
> Contest"—what are the most used types, most referenced packages, most and 
> least popular operators, etc. The data are interesting, but I'll let it speak 
> for itself. Find it here:
>
> https://gist.github.com/MichaelTJones/ca0fd339401ebbe79b9cbb5044afcfe2

Pretty interesting.  Thanks.

I note that "goto" is more common than "select".  That has to be an
artifact of the code base.

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/CAOyqgcUF%2BPLhiA5Fs4fmrL-PCreq9NVt6YzO1O-Sc9CO7Y6h6g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Go Language Survey

[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 scanner itself, so I just sat down an rewrote it cleanly.

To test beyond hand-crafted edge cases it seemed good to try it against a
large body of Go code. I chose the Go 1.13 code base, and because the
results are interesting on their own beyond my purpose of code testing, I
thought to share what I've noticed as a Github Gist on the subject of the
"Go Popularity Contest"—what are the most used types, most referenced
packages, most and least popular operators, etc. The data are interesting,
but I'll let it speak for itself. Find it here:

https://gist.github.com/MichaelTJones/ca0fd339401ebbe79b9cbb5044afcfe2

Michael

P.S. Generated by go test. I just cut off the "passed" line and posted it.
;-)

-- 

*Michael T. jonesmichael.jo...@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/CALoEmQzK3v4V%2BRYWZorfX0Nst%2BOXwzP9e51mCDm2ri-4jfzXyA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.