『プログラミング言語Go』刊行記念イベント「Goの設計思想を読み解く～実際の開発に活かすために」

7月6日にジュンク堂にて行われた『プログラミング言語Go』刊行記念イベント「Goの設計思想を読み解く～実際の開発に活かすために」で プログラミング言語Goの訳者である柴田さんと対談してきました。

トークセッションということで特にプレゼン資料的なものはないのですが、sliceの比較や、goroutine IDをあえて提供しないあたりにGoの設計思想であるSimplicity（簡潔性）が色濃くでているとかいう話をしました。 実際の開発に活かすには、Goでは具象型(concrete type)でAPIをきちんと考えて設計して、必要なところでinterface型を提供するようにしたほうがいいということを説明しました。特にJavaとかを書いている人とかは まずinterfaceを定義しようとすることが多いのでそれはやめたほうがいいと思います。interface型を先に定義するのはpremature abstraction（早すぎる抽象化）に陥りやすいです。

Goでは言語がシンプルな分、プログラマがしっかり設計し、きちんとコードを書くことが求められます。例えばGoプログラマは複雑な型であってもゼロ値が有効な値になるように設計する努力する必要があります。 また、エラー処理に関しても、Goではしっかり設計することが求められます。

できるだけシンプルな具象型をinterfaceを介してうまく組み上げていくことで、複雑な処理をするプログラムを開発していくかんじになります。 最初はどう組み合わせばいいかわかりにくいですが、うまく組み合わせることができるようになってくると、読みやすいGoのコードになっていくと思います。

Go Conference 2014 autumn

11月30日はGo Conference 2014 autumnに参加してきました。
@yamotongpooさんに11月はじめくらいに、「今度はRob Pike氏をよびますよ」と聞いて すごいと思っていたら、すぐあとくらいに@tenntennさんから、「キーノートを2本立てにして、片方を日本の方にということで キーノートおねがいします」という依頼がきて、Rob Pike氏と並んでキーノートなんかできるかなとややたじろぎましたが、こういうのは断るよりやっておいたほうがいい経験に なるだろうと思って具体的な内容を考えるのは後回しにして引き受けました。*1
「日本にフォーカスした話や日本のユーザがこれからGoをやっていこう！となるような内容がよいかなと思います」とのことだったので、どんな内容にするかしばらく考えていたのですが、 ふとblogを見直すとちょうど一年位前にGo Readability Approverになっていたので GoのReadabilityについて話すことにしました。Rob Pike氏はタイミング的にGo 1.4の話あたりをするんじゃないかと思っていたんです。
１年の間にレビューしたCLを見なおして、どういうコードにどういうコメントつけたのかを集めて整理しなおすだけで結構大変でした。実際多かったのは「need package comment (or doc comment)」 「error string should not be capitalized」あたりです。
CL見直して集めるのもかなり時間がかかりましたが、プレゼンで紹介しやすい短めのコードでポイントを説明できそうなやつを選ぶのもまたかなり大変でした。その後、見なおしてみたら多すぎたので講演時間におさまるようにだいぶ削りました。 実際のCLそのままはオープンソースでもないのでさすがによくなさそうだろうと思ったので、プレゼンで紹介したコードは実際のコードを元にした改変バージョンにしてあります。
タイトルは「Go Readability」にしていたのですが、当日朝会場に向かう途中にふと「郷に入っては郷に従え」がうかんできたのでした。クロージングのメッセージにしようかなと最初思いましたが、結局タイトルにすることにしました。
Rob Pike氏は予想とちがって「Simplicity is Complicated」でReadabilityとかが超大事みたいな話になっていたので、Go Readabilityの話ができたのはよかったと思います。

Goに入ってはGoに従え
-- Gopher by Renée French, and tenntenn

Goでは変数名が短くてすむ場合は短いほうがいいとされていて、これが他の言語から来た人の反発を招きやすいようですね。 でも数学で数式とか変数名はほとんど一文字なわけで、コンテキストがちゃんとわかっているのなら短くてもわかりやすいです。むしろ長いと読みにくくなりそう。

-coefficentOfLinearTeam ± sqrt(coefficientOfLinearTerm*coefficientOfLinearTerm - 4*coefficientOfSquareTerm*constantTerm) / (2*coefficientOfSquareTerm)

とか。

今回のGoConの発表はGoをproductionに使ってみた系の話が多くてだいぶ普及してきたなぁと感じました。

懇親会では@jxck_さんのコードをレビューしてたんですが、Rob Pike先生から、よりエレガントなコードの手ほどきをしてもらっていました。いいコードを書くにはまだまだ修行が必要です。

後日、officeでRob Pike氏に「よいプレゼンだったから英語にも訳してよ」とリクエストされたので英語版: When in Go, do as Gophers doも作りました。 Rob Pike氏に英語のreviewもしてもらってあります。

We talk about readability all the time, but this is the first public talk I've seen explicitly on the topic and it explains things well. The examples are really good.

とのお言葉をいただきました!


*1情熱プログラマにも「39: 業界で名前を売ろう Let Your Voice Be Heard」に ”名前を売り出すときに一番大事なことは、時期尚早かなと思うくらいでスタートすることだ。たいていの人は自分を売り込むときに消極的になる。君は教えるべきものを持っている。もう準備万端だと感じることは 決してない。この瞬間に始めてもいいくらいだ。"と書かれていたのを実践してみました。

Go Conference 2013 Spring

Go Conference 2013 Springに参加してきました。

ハンズオンの時間は、放置していたcode.google.com/p/go.net/websocketをいじってました。

プレゼンは「「なぜGoなのか」というところを話してほしい」ということだったので、言語機能の説明よりもどのあたりがいいかを説明してみることにしました。

「最初はキモッって思うかもしれないけど、そのうちかわいく見えてきますよ」というかんじが伝えられたでしょうか。 なんでGoをつかうとうれしいかは、大規模なチームの中で大規模なコードをいじらないとなかなかピンとこないかもしれません。

印象としてはこんなかんじかなー

C

知っている技術者は多い。OOをやるにはめんどい(glibみたいになっていく?)。大規模になってくるとclassとかnamespaceとかないとつらいかんじ

C++

知っている技術者はそこそこ多い。大規模なプロダクトができる(googleのサーバーとかChromeとか)がビルド時間がとてつもなく長くなっていって開発するのがつらい。C++11以前だと(autoとかないと)書くのもめんどいときが多い。

Java

知っている技術者はそこそこ多い。(IDEとかの助けがないと)書くのがめんどい。大規模になってくるとIDEではつらい。JavaにかぎらずJVMベースの言語はJVMのチューニングとかがたいへんぽい。

Python

知っている技術者はそこそこ多い。ちょっとしたプログラムだと簡単。規模がおおきくなってくると詳細をつかむのがむずかしくなってくる(この変数はどういう値(どのclassのobject)になりうるのか? 別のclassのobjectをわたしてもいいのか? とか)。そのうち滅多に通らないコードパスでruntimeエラーで死んで悲しくなる。(つまらないtypoとかだとさらに悲しい)

Ruby

Pythonと似たかんじ。Domain Specific Languageにされてしまったりもするが、そうなるとその方言もしらないと読むのもつらい

JavaScript

表層をしっている技術者は多いが、ディープなところになるとむずかしすぎし、そういうところで問題がおきると調べるのがむずかしい。大規模になるとClosure Compilerとかの annotationしておかないとつらくなってくる。

ErlangとかHaskellとか

Cプログラマにとっては学習コストがたかそう。

Goだとimplicitなことが少ないのでコードを読む負担がすくないのがいいと思います。型が省略されてるのもその式の型を把握するのは難しくないですし(深い推論とかしてないので)。 より詳しくはRob Pike先生のGo at Google: Language Design in the Service of Software Engineering (slides)を読むとよいかと思います。 talks.golang.orgには他にもgo teamのプレゼンがいろいろ置いてあるので見てみることをおすすめします。

発表の資料はhttp://ukai-go-talks.appspot.com/2013/gocon.slide#1に置いてみました。せっかくなのでhttps://code.google.com/p/go.talksをつかってみました。これsyntaxがこんなかんじで、昔のMagicPointを思いだしたりしました…。表現力とかはたいしたことないですが、local版だとplay.golang.orgみたいにcodeの実行ができるので、Go言語のプレゼンをするのには便利です。