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

[a...@golang.org]

Reviewers: r, campoy,

Message:
Hello r...@golang.org, cam...@google.com (cc: golan...@googlegroups.com),

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


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

Please review this at http://codereview.appspot.com/6506073/

Affected files:
A 2012/zen.slide
A 2012/zen/.race.go.swp
A 2012/zen/hello.go
A 2012/zen/http.go
A 2012/zen/jsonformat.go
A 2012/zen/race.go

[Andrew Gerrand]

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

[r...@golang.org]

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.

http://codereview.appspot.com/6506073/

[Lucio De Re]

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.

[dsym...@golang.org]

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"

https://codereview.appspot.com/6506073/

[Rob Pike]

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

-rob

[a...@golang.org]

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.

http://codereview.appspot.com/6506073/

[a...@golang.org]

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.

http://codereview.appspot.com/6506073/

[a...@golang.org]

Hello r...@golang.org, cam...@google.com, lucio...@gmail.com,
dsym...@golang.org (cc: golan...@googlegroups.com),

Please take another look.


http://codereview.appspot.com/6506073/

[cam...@google.com]

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?

http://codereview.appspot.com/6506073/

[David Symonds]

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.

[Rob Pike]

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

[Ian Lance Taylor]

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

[Rob Pike]

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

[Rob Pike]

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

-rob

[David Symonds]

This would make a good blog post.

[mp...@golang.org]

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.

http://codereview.appspot.com/6506073/

[sam...@golang.org]

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.

http://codereview.appspot.com/6506073/

[a...@golang.org]

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"

http://codereview.appspot.com/6506073/

[a...@golang.org]

Hello r...@golang.org, cam...@google.com, lucio...@gmail.com,
dsym...@golang.org, ia...@google.com, mp...@golang.org, sam...@golang.org

[r...@golang.org]

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

http://codereview.appspot.com/6506073/

[a...@golang.org]

*** 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/

[Dave Cheney]

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