2017/08/21

LLイベント2017の「第2プログラミング言語鑑定団」で鹿野が話したことまとめ

プログラミング好きにもいろいろあって、仕事で使ってる道具をもっと知りたいという人もいれば、自分が使ったことない道具の話を知りたいという人もいれば、道具はなんでもいいから面白い話がしたいという人もいます。 久しぶりに参加したLLイベントは、そんな多様なプログラミング好きが「全員がアウェーな立場」で交流するという、貴重で面白い機会でした。 実際、「LL」の1つめのLには去年までは「Lightweight」という意味があり、その単語が示す特徴をもった言語のイベントのようにどうしても見えてたんですが、今年からはそういう区切りも公けになくし、Lは「Learn」の意味になったとのことです。

そのLLイベント2017で、「第2プログラミング言語鑑定団」というセッションに出させてもらいました。 司会の小山さんが「Teratail, Yahoo知恵袋などから、それらしい質問をかき集めてマージ」した6パターンの「次に学ぶ言語は何がいい?」に対し、鑑定団の一人としてお勧め言語を紹介せよというのがミッションでした。 ぼく以外の鑑定団のメンバーは、ささけんさん高野さん高橋さん。一癖あるすごいITエンジニアばっかりだー。このメンバーが集まるというだけで、LLイベントすごいって気持ちになりました。

いっぽう、ぼく自身はただの書籍編集者です。 自分の仕事に必要な道具を作ったり環境を整えたりはするけどエンジニアというわけではないし、プログラミングは好きで勉強はするけど研究者ではないし、 本職ではない人間になんという無茶ぶりかと思って最初は躊躇したのですが、たぶん、この記事を書かせてもらったことをきっかけに声をかけてもらえたんだろうなあ。

employment.en-japan.com

なお、上記の記事は「ElixirとRustとHaskellにちょっと興味がある人向けの紹介記事を各界の第一人者に書いてもらおう」という企画の前フリなので、そういう目線でやさしい気持ちで読んでもらうと幸いです。 ElixirRustはすでに公開中。今月中にHaskellも公開される予定です(宣伝)。

ほかの鑑定団の回答

そもそもブログで自分の回答を書くつもりはなかったんですが、ささけんさんがさっくりと自分の回答をまとめて公開したので、まとめざるを得なくなった。

[高野さんと高橋さんが何か公開されたらリンクはる予定地]

鹿野はどんな言語を勧めたか

想定質問は事前に見せてもらってたのですが、じゃあその質問に対して何を答えることが求められてるんだろうというのは、正直なところ当日になってもわからなくて、会場に着くまでは「ちょっとまずいかもなあ」と暗い気持ちでいました。 で、それを一緒に来ていた同僚に愚痴ったところ、「お勧め本を紹介したらいいじゃん」という画期的な入れ知恵をしてもらい、その路線でいくことに決めたのでした。

質問1

文系の大学4年生のときにプログラミングが好きになり、独学で C と Java の初歩を学びました。卒業後Web 制作会社に入社し、HTML, CSS,JavaScript を習得しました。Web周辺だけでは将来が不安なので、次に何を学ぶべきか考えています。アドバイスをいただけないでしょうか。

この質問を最初にみたときは「知らんがな」という思いしか去来せず、サイコロでも投げて決めろと言いたかったのですが、言語じゃなくて書籍であれば紹介すべきものがすぐに思いつきました。 五十嵐先生の『プログラミング in OCaml』です。なので、回答は「OCaml」にしました。

あらかじめ断っておくと、ぼくはOCamlを実用してるわけではありません。 OCamlのコードをいじったのは、『型システム入門』を作ったとき、OCamlで書かれた原著者ビルド環境を日本語pLaTeX向けに改修したときくらいです。 ですが、この本は、OCamlを使うつもりがとくにない人でも、独力でプログラミングを学んできたような人であれば、読むといいことがたくさん書いてあると思っています。 具体的には、OCamlというプログラミング言語でのプログラムの書き方だけでなく、どうしてそういう機構になっているのかがいちいち詳しく解説されており、プログラミング言語の理論についても味見できるようになっています。 この質問者はWeb周辺の技術を追いかける以外の勉強をしたいようだし、そういう意味でもぴったりではないかと思いました。

質問2

文系大学に通う学生ですが、昔からゲームが好きで、将来はゲームクリエイターになりたいと考えています。そうはいってもプログラミングはまだできないし、特筆したスキルもありません。ゲームクリエイターに関する書籍を読んで、将来こんなゲームを作りたいと夢を膨らませています。私がゲーム開発者になるためにはどの言語から学ぶのがよいでしょうか?

ゲーム作りたいといってる時点で、プログラミング言語を選んでる場合じゃなく、むしろどのゲームエンジンを使ってみればいいかという話なんですよね。 なので、回答は「Unity」か「Unreal Engine」にしました。

書籍として紹介したのは、『Unreal Engine 4で極めるゲーム開発』です。無責任にも自分では読んでないんですが、渋川さんが激烈に勧めているので間違いないでしょう。

質問3

Web制作会社でサーバサイドを開発しているソフトウェアエンジニアです。現在使っているプログラミング言語はRubyでフレームワークはRailsです。最近世の中でAIや機械学習がブームになっていて、私もそちら方面のスキルを磨いてより高度な作業をできるようになりたいと考えています。AIや機械学習を使いこなすのに最適なプログラミング言語は何でしょうか?

機械学習で縛られてる設問なので、Pythonからは逃げられないような気がします。ということで、回答としては「Python」。

でも、たぶんPythonを学べばどうなるものでもなく、線形代数なんかを地道に復習したほうがいいような気もします。 そのへんからかみ砕いて解説されているという点で、書籍は『ゼロから作るDeep Learning』をお勧めにしました。

質問4

SIerとして大手案件の2次下請けを仕事にしています。主に使っている言語はJavaでフレームワークはStrutsです。噂ではStrutsにもSIerにも未来はもう無いそうで、転職して他の仕事もできるようになりたいのですが、これまでJavaしか使ったことがないのでどうしたら良いか分かりません。これから学ぶのならば、なるべく長く役に立つ技術が良いと思うのですが、何がよいでしょうか。

「長く役に立つ」といったら、これまで長く使われてきた実績があり、これからもそう簡単に消えることはないであろう言語しかないだろうということで、「Common Lisp」か「Haskell」と回答しました。

書籍はそれぞれ『実践Common Lisp』と『すごいHaskell』を紹介。このへんは我田引水させてもらいました。

質問5

プログラミング初心者です。Webサイト作成のためにPHPの学習中ですが、他の言語にも興味があります。しかしなかなか難しいのもあって効率的なプログラミング学習法はないかと頭を悩ませているところです。そこで、おもしろそうと興味を持てば学習がはかどるのではと考えました。面白いプログラミング言語とその理由を教えてください。

面白いプログラミング言語といったら、とりあえずこれを押さえておけということで、「Brainfuck」です。 とはいえ、Brainfuckでプログラムを書くんじゃなく、好きな言語でBrainfuckを作ってみたらという提案をしました。 やっぱり、プログラミング言語ってこういうことなんだという実感を得るには、なんでもいいから作ってみるのがいちばんで、そのためにもBrainfuckの実装には一度は挑戦してみると楽しいと思います。

というわけで、お勧めした書籍は『Rubyで作る奇妙なプログラミング言語』。

質問6

インフラ運用エンジニアをしています。使える言語はシェルです。仕事ではたくさんのOSSを使用していますが、これらは書かれている言語がC,PHP,Python,Ruby,Node.js,Javaなど多岐にわたります。最近は自動化がブームですが、OSSを使って自動化をやっていくために、どのような言語を学ぶのがよいでしょうか。

OSSのツールを利用していくのに知っておいたほうがいい言語で、質問に出ていないものといって思いつくものは、「Go」しかありませんでした。 というわけで書籍としては『プログラミング言語Go』です。

いま思い返すとPerlとかLuaという選択肢もありえましたが、やっぱりあの場でお勧めする言語としてはGoしかありませんでした。 なぜなら、Goはラムダノートから近日中に新刊が出る予定だからです。 アスキーjpで連載していた「Goならわかるシステムプログラミング」の書籍化です! 昨日のLLイベントでも「低レイヤをかじることの重要性」は何度か強調されていて、そのたびにCやアセンブラというキーワードが出ててましたが、いまならそれこそGoで楽に学べます。 そういう趣旨で好評の連載に、著者の渋川さんが少し話を追加して、10月くらいに出せるように頑張って制作中。お楽しみに(宣伝)。

質問7(会場からの飛び入り質問)

小学三年生の息子がプログラミングをはじめるのに、Scratchのほかにどんな選択肢がありますか?

小学生にプログラミングを教えるときって、ビジュアル言語じゃない形でコンピュータの開発環境に触れる機会も必要だと思ってるんですよね。 かといって、汎用言語はそこそこ覚えないといけないことが多くてつらい。 そこで、覚えることが最小限で、コンピュータの生っぽいところを意識できる言語があればいいんですが、その条件を満たす言語はSchemeくらいしかありませんよね(異論は認める)。 というわけで「Scheme」をお勧めしました。

参考書籍はもちろん『計算機システムの構造と解釈』です(いまおもうと『Scheme手習い』という手もあった)。

2017/06/21

編集というサービスの内容(技術書編)

技術書の編集者が原稿に対して何を提供するものなのか、整理してみた。順番には意味があります。

  1. 原稿をDTP担当者が作業できるデータにする
  2. 誤字脱字、非標準的な表記を直す
  3. 表記を統一する
  4. 文法の間違い、不適切な言い回しを直す
  5. 構成の不備、内容の間違いを指摘する
  6. 構成の不備、内容の間違いを直す
  7. 冗長な内容、文脈から外れる記述を欄外に追い出したり、段落構成を手直ししたりする
  8. 段落や文を、文脈に合わせた相に書き直す
  9. 行間をうめる
  10. 解説画像やイラスト、索引などのメタ情報を作る
  11. 原稿を書く
  12. 【番外】企画する

どこまでやってほしいか、できるか、追加料金がいくら必要なのかというのを、著者・版元編集者・下請け編集者の間ではっきりさせると、みんなが幸せになる気がする。(だいたい編集外注するときって「編集作業一式」の「ページあたりの単価」になりがちで、しかしその「一式」には上記のような幅があるわけだから、人によって高いとか安いとか感じ方がいろいろ変わってしまうよね……。)

本として書店に並ぶまでに必要な作業は上記のほかにもいっぱいあり(装幀の企画と手配、権利、印刷製本、流通に関連するいろいろな仕事などなど)、上記に挙げた編集業務を担当編集者がぜんぶやるべきという話ではないはず。

たとえば、上記のうち5までは担当編集者が直接やるけど、残りは外部の査読者だったり編集者だったりを雇うことにするとか、あるいは、そこは著者の仕事であると最初から割り切る(ということを著者との間で同意しておく)ほうが、結果的に読者が手にする本にとって最善というケースもあるかもしれない。

なお、弊社では上記のすべてに対応した編集業務の受注が可能です。お気軽にご相談ください。