Let’s Go Video: Simplicity in Go

This week, I picked a talk by Katherine Cox Buday, since the speaker in last week’s video referenced her (and she did quote Alan Kay in this talk). Videos in this series are added to a YouTube list over here.

It’s interesting watching a conference talk without having been embedded in the language’s community, because I’m gathering some social norms, or “knowns” that people reference off-hand. In this talk, it’s that apparently Go talks about simplicity a lot, and also that people are going to mention Rob Pike a lot.

As to the talk, Buday’s thesis is that in the argument “for simplicity,” programmers are sometimes using that excuse to shore up poor ideas that are quite in the opposite direction — examples include “Go’s simple enough, you don’t need a framework.”

She mentions Alan Kay’s talk (and in this one, I now know which talk she’s discussing, and it is on YouTube) that talks about computing being more like pop culture.

Another fallacy she’s observed in people arguing about simplicity is using the “appeal to authority” tactic, which I felt like I saw in the wild this week — this week I joined the Gophers Slack, and I saw someone respond to a question in #golang-newbies by explaining that well, Go is actually being helpful there in the message that confused them but … it was still confusing. There seems to be some underlying “if Go does things this way, it must be the way” opinions, as if programming languages can’t change, or as if there aren’t things being actively worked on and they are changing. It’s interesting to hear Buday mention this.

She references a few more talks that might be interesting to explore:

• Rob Pike, Another Go at Language Design, slides
• Rich Hickey, Simple Made Easy (I saw this at some point, and I do remember it was great)

Another issue is extrapolating answers for small projects to big ones.

I think the best quote about this was referencing Rich Hickey talking about juggling — that an average juggler can juggle 3 balls, an advanced, 12.

Compared to the complexity we can create, we’re all statistically at the same point

Rich Hickey, Simple Made Easy, referenced by Katherine Cox Buday

So it’s about being able to manage the complexity as the problem space grows, versus creating complexity yourself. That does sound like a eternal struggle, if there is one, in software engineering projects.

Overall, dug this video, and I like that it yielded many pointers to other interesting references. I’m thinking next week to pick something a bit more in the “covering a feature of Go” area.