code review 6506073: go.talks: add Go and the Zen of Python talk

go.talks: add Go and the Zen of Python talk

[adg, 2012-09-05 12:54:31]

Hello r@golang.org, campoy@google.com (cc: golang-dev@googlegroups.com),

I'd like you to review this change to
https://code.google.com/p/go.talks

[adg, 2012-09-05 12:59:02]

This wasn't intended for golang-dev, but if anyone wants to review it
go ahead. :-)

[r, 2012-09-05 13:17:33]

http://codereview.appspot.com/6506073/diff/2002/2012/zen.slide
File 2012/zen.slide (right):

http://codereview.appspot.com/6506073/diff/2002/2012/zen.slide#newcode162
2012/zen.slide:162: func (s Scalar) Abs() float64 {
making the point aside, why not return Scalar?
also this is a weak example because in every other language abs would just work.
can we come up with a better one?

this is ok and feel free to leave it as is, i'm just musing

http://codereview.appspot.com/6506073/diff/2002/2012/zen.slide#newcode195
2012/zen.slide:195: c, err := rpc.Dial("tcp", addr)
s/c/client/

http://codereview.appspot.com/6506073/diff/2002/2012/zen.slide#newcode199
2012/zen.slide:199: return &Client{client: c}
return &Client{client}

simpler and maybe better for the audience?

http://codereview.appspot.com/6506073/diff/2002/2012/zen.slide#newcode237
2012/zen.slide:237: - No implicit conversions
s/conversions/numeric &/
i'm starting to get pedantic about this one

http://codereview.appspot.com/6506073/diff/2002/2012/zen.slide#newcode238
2012/zen.slide:238: - Go data structures define memory layout (no hidden costs)
well.... what's a string? a slice? a map?

http://codereview.appspot.com/6506073/diff/2002/2012/zen.slide#newcode272
2012/zen.slide:272: - Packages share one name space across multiple files
package name space is flat too

http://codereview.appspot.com/6506073/diff/2002/2012/zen.slide#newcode287
2012/zen.slide:287: Go has a some built in generic data structures:
s/built in/built-in/

http://codereview.appspot.com/6506073/diff/2002/2012/zen.slide#newcode303
2012/zen.slide:303: - Many other language design decisions were made in the name
of readability.
export e.g.

[lucio, 2012-09-05 13:24:21]

On 9/5/12, r@golang.org <r@golang.org> wrote:
>
> http://codereview.appspot.com/6506073/diff/2002/2012/zen.slide#newcode287
> 2012/zen.slide:287: Go has a some built in generic data structures:
> s/built in/built-in/
>
Surely "Go has *a* some built-in..(my emphasis)" does not want the "a" at all?

Lucio.

[dsymonds, 2012-09-05 13:25:59]

https://codereview.appspot.com/6506073/diff/2002/2012/zen.slide
File 2012/zen.slide (right):

https://codereview.appspot.com/6506073/diff/2002/2012/zen.slide#newcode162
2012/zen.slide:162: func (s Scalar) Abs() float64 {
On 2012/09/05 13:17:33, r wrote:
> making the point aside, why not return Scalar?
> also this is a weak example because in every other language abs would just
work.
> can we come up with a better one?
> 
> this is ok and feel free to leave it as is, i'm just musing

"Len() int" might be a reasonable substitute. Or "Norm() float64" if you wanted
to stick with geometry/maths.

https://codereview.appspot.com/6506073/diff/2002/2012/zen.slide#newcode172
2012/zen.slide:172: Interfaces are just methods (no data)
Calling out the duck typing implication here might be good for a Python
audience.

https://codereview.appspot.com/6506073/diff/2002/2012/zen.slide#newcode209
2012/zen.slide:209: type Foo struct { // expored type
"exported"

[r, 2012-09-05 13:29:06]

Go does not have duck typing. Stop saying that it does.

-rob

[adg, 2012-09-05 13:31:42]

http://codereview.appspot.com/6506073/diff/2002/2012/zen.slide
File 2012/zen.slide (right):

http://codereview.appspot.com/6506073/diff/2002/2012/zen.slide#newcode162
2012/zen.slide:162: func (s Scalar) Abs() float64 {
On 2012/09/05 13:17:33, r wrote:
> making the point aside, why not return Scalar?
> also this is a weak example because in every other language abs would just
work.
> can we come up with a better one?

A good point. I'll sleep on it.

http://codereview.appspot.com/6506073/diff/2002/2012/zen.slide#newcode195
2012/zen.slide:195: c, err := rpc.Dial("tcp", addr)
On 2012/09/05 13:17:33, r wrote:
> s/c/client/

Done.

http://codereview.appspot.com/6506073/diff/2002/2012/zen.slide#newcode199
2012/zen.slide:199: return &Client{client: c}
On 2012/09/05 13:17:33, r wrote:
> return &Client{client}
> 
> simpler and maybe better for the audience?

Done.

http://codereview.appspot.com/6506073/diff/2002/2012/zen.slide#newcode237
2012/zen.slide:237: - No implicit conversions
On 2012/09/05 13:17:33, r wrote:
> s/conversions/numeric &/
> i'm starting to get pedantic about this one

Hang on - we don't permit explicit string->[]byte conversions either. The only
implicit conversions we allow are from untyped constants, or into/between
interface values. Or am I missing something?

http://codereview.appspot.com/6506073/diff/2002/2012/zen.slide#newcode238
2012/zen.slide:238: - Go data structures define memory layout (no hidden costs)
On 2012/09/05 13:17:33, r wrote:
> well.... what's a string? a slice? a map?

well, slices and strings have well-defined properties. maps not so much...
perhaps it could have a footnote?

http://codereview.appspot.com/6506073/diff/2002/2012/zen.slide#newcode272
2012/zen.slide:272: - Packages share one name space across multiple files
On 2012/09/05 13:17:33, r wrote:
> package name space is flat too

Done.

http://codereview.appspot.com/6506073/diff/2002/2012/zen.slide#newcode287
2012/zen.slide:287: Go has a some built in generic data structures:
On 2012/09/05 13:17:33, r wrote:
> s/built in/built-in/

Done.

http://codereview.appspot.com/6506073/diff/2002/2012/zen.slide#newcode303
2012/zen.slide:303: - Many other language design decisions were made in the name
of readability.
On 2012/09/05 13:17:33, r wrote:
> export e.g.

Done.

[campoy, 2012-09-05 13:32:51]

http://codereview.appspot.com/6506073/diff/2002/2012/zen.slide
File 2012/zen.slide (right):

http://codereview.appspot.com/6506073/diff/2002/2012/zen.slide#newcode147
2012/zen.slide:147: type Vector struct {
Why Vector and not Point2D?
Calling this a vector is ... mathematically correct, though.

http://codereview.appspot.com/6506073/diff/2002/2012/zen.slide#newcode209
2012/zen.slide:209: type Foo struct { // expored type
s/expored/exported/

http://codereview.appspot.com/6506073/diff/2002/2012/zen.slide#newcode238
2012/zen.slide:238: - Go data structures define memory layout (no hidden costs)
s/data structures/structs/

I got this question in Zurich: When you say there's no hidden allocations, what
about maps and slices?

[adg, 2012-09-05 13:34:20]

Who knew that 11pm australian time was the best time to send out a CL?

http://codereview.appspot.com/6506073/diff/2002/2012/zen.slide
File 2012/zen.slide (right):

http://codereview.appspot.com/6506073/diff/2002/2012/zen.slide#newcode172
2012/zen.slide:172: Interfaces are just methods (no data)
On 2012/09/05 13:25:59, dsymonds wrote:
> Calling out the duck typing implication here might be good for a Python
> audience.

it's structural typing you insensitive clod!

http://codereview.appspot.com/6506073/diff/2002/2012/zen.slide#newcode209
2012/zen.slide:209: type Foo struct { // expored type
On 2012/09/05 13:25:59, dsymonds wrote:
> "exported"

Done.

http://codereview.appspot.com/6506073/diff/2002/2012/zen.slide#newcode209
2012/zen.slide:209: type Foo struct { // expored type
On 2012/09/05 13:32:52, campoy wrote:
> s/expored/exported/

Done.

http://codereview.appspot.com/6506073/diff/2002/2012/zen.slide#newcode238
2012/zen.slide:238: - Go data structures define memory layout (no hidden costs)
On 2012/09/05 13:32:52, campoy wrote:
> s/data structures/structs/
> 
> I got this question in Zurich: When you say there's no hidden allocations,
what
> about maps and slices? 

Done.

[adg, 2012-09-05 13:34:37]

Hello r@golang.org, campoy@google.com, lucio.dere@gmail.com, dsymonds@golang.org
(cc: golang-dev@googlegroups.com),

Please take another look.

[dsymonds, 2012-09-05 13:45:26]

On Wed, Sep 5, 2012 at 11:29 PM, Rob Pike <r@golang.org> wrote:

> Go does not have duck typing. Stop saying that it does.

You should post something to golang-dev. Lots of people think it does,
and I can't see from the Wikipedia page on duck typing how it doesn't.

[r, 2012-09-05 13:48:42]

The statement that Go has no implicit conversions is just wrong.
Interface conversion can be done implicitly under assignment.

  var a InterfaceType = valueImplementingInterface

That becomes even more implicit when passing
valueImplementingInterface as an argument to a function that accepts
InterfaceType. Every call to Println uses this form of implicit
conversion.

I use the phrase that Go has no implicit numeric conversions because
that is true. It doesn't cover all the forbidden cases but it covers
the most important ones.

-rob

[iant2, 2012-09-05 13:54:37]

On Wed, Sep 5, 2012 at 6:45 AM, David Symonds <dsymonds@golang.org> wrote:
> On Wed, Sep 5, 2012 at 11:29 PM, Rob Pike <r@golang.org> wrote:
>
>> Go does not have duck typing. Stop saying that it does.
>
> You should post something to golang-dev. Lots of people think it does,
> and I can't see from the Wikipedia page on duck typing how it doesn't.

Technically speaking, Go has a form of structural typing.  Duck typing
implies that the characteristics of the type are checked dynamically
when used, and that is not what happens in Go.  In Go the
characteristics are checked when assigning to an interface type.

Ian

[r, 2012-09-05 13:55:34]

The very existence of interface types make it not duck typing. Static
checking is done to guarantee interface satisfaction. Duck typing is
purely dynamic.

Here it is, right out of Wikipedia:

Structural type systems

Duck typing is similar to but distinct from structural typing.
Structural typing is a static typing system that determines type
compatibility and equivalence by a type's structure, whereas duck
typing is dynamic and determines type compatibility by only that part
of a type's structure that is accessed during run time.

The OCaml, Scala, and Go languages use structural type systems.

-rob

[r, 2012-09-05 14:05:12]

To put it as simply as I can: If Go had duck typing, it wouldn't need
interface types.

-rob

[dsymonds, 2012-09-05 14:37:05]

This would make a good blog post.

[mpvl, 2012-09-05 14:53:33]

http://codereview.appspot.com/6506073/diff/2005/2012/zen.slide
File 2012/zen.slide (right):

http://codereview.appspot.com/6506073/diff/2005/2012/zen.slide#newcode174
2012/zen.slide:174: Interfaces are implicit (no `implements` declaration)
But the Zen of Python says: "Explicit is better than implicit."  Maybe explain
why implicit is good here.

http://codereview.appspot.com/6506073/diff/2005/2012/zen.slide#newcode235
2012/zen.slide:235: - Explicit error handling (no exceptions)
But, this makes it easier to violate: "Errors should never pass silently." 
Perhaps say something about this.

[Sameer Ajmani, 2012-09-05 15:41:34]

http://codereview.appspot.com/6506073/diff/2005/2012/zen.slide
File 2012/zen.slide (right):

http://codereview.appspot.com/6506073/diff/2005/2012/zen.slide#newcode191
2012/zen.slide:191: client *rpc.Client
Too many things called "client" here.

Replace the outer client with some application-level concept like FileSystem or
Database, perhaps.

http://codereview.appspot.com/6506073/diff/2005/2012/zen.slide#newcode215
2012/zen.slide:215: func (f Foo) quux() {} // private method
"private" is misleading, since in Go this really means "package visibility". 
Howabout:
  // unexported method (visible within package foo)
And add a package foo statement at the top.

http://codereview.appspot.com/6506073/diff/2005/2012/zen.slide#newcode229
2012/zen.slide:229: - No generators
but embedding+interfaces cover most uses of inheritance and make it easy to
create decorators

(and channels support generators and iterators but we don't encourage that, so
best not to mention it...)

http://codereview.appspot.com/6506073/diff/2005/2012/zen.slide#newcode300
2012/zen.slide:300: - The `gofmt` tool enforces "one true style." (No more
arguments.)
formatting != style.  There are still arguments, but fewer dumb ones.

[adg, 2012-09-05 22:20:12]

http://codereview.appspot.com/6506073/diff/2005/2012/zen.slide
File 2012/zen.slide (right):

http://codereview.appspot.com/6506073/diff/2005/2012/zen.slide#newcode174
2012/zen.slide:174: Interfaces are implicit (no `implements` declaration)
On 2012/09/05 14:53:33, mpvl wrote:
> But the Zen of Python says: "Explicit is better than implicit."  Maybe explain
> why implicit is good here.

I will, in person, but I don't want to clutter the slide.

http://codereview.appspot.com/6506073/diff/2005/2012/zen.slide#newcode191
2012/zen.slide:191: client *rpc.Client
On 2012/09/05 15:41:34, Sameer Ajmani wrote:
> Too many things called "client" here.
> 
> Replace the outer client with some application-level concept like FileSystem
or
> Database, perhaps.

Done.

http://codereview.appspot.com/6506073/diff/2005/2012/zen.slide#newcode215
2012/zen.slide:215: func (f Foo) quux() {} // private method
On 2012/09/05 15:41:34, Sameer Ajmani wrote:
> "private" is misleading, since in Go this really means "package visibility". 
> Howabout:
>   // unexported method (visible within package foo)
> And add a package foo statement at the top.

Done.

http://codereview.appspot.com/6506073/diff/2005/2012/zen.slide#newcode229
2012/zen.slide:229: - No generators
On 2012/09/05 15:41:34, Sameer Ajmani wrote:
> but embedding+interfaces cover most uses of inheritance and make it easy to
> create decorators
> 
> (and channels support generators and iterators but we don't encourage that, so
> best not to mention it...)

Done.

http://codereview.appspot.com/6506073/diff/2005/2012/zen.slide#newcode235
2012/zen.slide:235: - Explicit error handling (no exceptions)
On 2012/09/05 14:53:33, mpvl wrote:
> But, this makes it easier to violate: "Errors should never pass silently." 
> Perhaps say something about this.

I will. But I don't want to get bogged down in nitpicky stuff related to the zen
of python. It's already a contradictory and kinda solly document. It's just a
basis from which to familiarize python programmers.

http://codereview.appspot.com/6506073/diff/2005/2012/zen.slide#newcode300
2012/zen.slide:300: - The `gofmt` tool enforces "one true style." (No more
arguments.)
On 2012/09/05 15:41:34, Sameer Ajmani wrote:
> formatting != style.  There are still arguments, but fewer dumb ones.
changed it do "no more stupid arguments"

[adg, 2012-09-05 22:20:31]

Hello r@golang.org, campoy@google.com, lucio.dere@gmail.com,
dsymonds@golang.org, iant@google.com, mpvl@golang.org, sameer@golang.org (cc:
golang-dev@googlegroups.com),

Please take another look.

[r, 2012-09-05 22:42:21]

LGTM

http://codereview.appspot.com/6506073/diff/12001/2012/zen.slide
File 2012/zen.slide (right):

http://codereview.appspot.com/6506073/diff/12001/2012/zen.slide#newcode123
2012/zen.slide:123: * Go is zenlike
Zenlike

[adg, 2012-09-06 01:00:22]

*** Submitted as
http://code.google.com/p/go/source/detail?r=919f8129211b&repo=talks ***

go.talks: add Go and the Zen of Python talk

R=r, campoy, lucio.dere, dsymonds, iant, mpvl, sameer
CC=golang-dev
http://codereview.appspot.com/6506073

[dave_cheney.net, 2012-09-06 02:33:03]

This is great! I'm uninstalling Libreoffice right now!

On Thu, Sep 6, 2012 at 11:00 AM,  <adg@golang.org> wrote:
> *** Submitted as
> http://code.google.com/p/go/source/detail?r=919f8129211b&repo=talks ***
>
>
> go.talks: add Go and the Zen of Python talk
>
> R=r, campoy, lucio.dere, dsymonds, iant, mpvl, sameer
> CC=golang-dev
> http://codereview.appspot.com/6506073
>
>
> http://codereview.appspot.com/6506073/