プログラミング言語との付き合い方

no extension

今朝見かけたこれ。 こういう話は好きなので便乗してみる。

ちなみに,結城浩さんの通称「デザパタ本」はずい分昔に買っている。 お世話になってます。

プログラミング言語の「母国語」

プログラミング言語との付き合い方というのはいろいろあってですね。自分の母国語という言語はある。それから現在学んでいる最中の言語というのもある。そして、仕事用の言語やら、他の人とのコミュニケーション用言語というのもある。そのあたりは、自然言語とちょっと似ている。

個人的に母国語と言えるのはアセンブラとC言語。 私の場合はコードを脳内でインストラクションに翻訳する。 手続き型の言語ならこの「翻訳」をほとんど無意識でできる1。 だから手続き型の言語であれば知らない言語でも見ればだいたい理解できる。

逆に,関数型のような非手続き型言語はあまり得意ではないのだが,簡単なものであれば手続き型に翻訳できるので,簡単なものを組み合わせて考えることで,まぁ何とか理解することはできる。

ちまりまわるつ

そういえば,竹本泉さんの作品に『ちまりまわるつ』シリーズというのがある2。 このシリーズの世界では「魔法」が科学的(?)に体系化されていて,工場で生産できるようになっている。なので,人力(?)で魔法を使う「魔法使い」は(工場で生産できない高度な魔法を使うことのできる一部の大魔法使いを除いては)古臭い職業として子供たちからは敬遠されている。 魔法使い達は能力でランク分けされていて,低ランクの魔法使いは簡単な呪文で簡単な魔法しか使えない。

でもここからが竹本泉作品らしいところで,簡単な呪文しか使えない魔法使いも呪文を組み合わせることで高度な魔法を使うことができるのだ(ただし高度な魔法は制御が難しいので,ふつうは使わせてもらえない)。 プログラムに例えるなら,高級言語で1行で書けるプログラムをアセンブラで数十ステップで書くような感じだと思えばよい。

こういう世界設定を少女漫画でさらっと描いてしまうところが竹本泉さんの凄いところである。

目的別の言語

話が逸れた。

そういうわけなので個人的に「学んでいる最中の言語」というのはない。 見て理解できるかできないか。 いや,ぺーぺーの新人の頃はアセンブラやC言語を必死こいて学んでいたが,一度基礎ができればあとは全部「応用編」なのである。 そういう意味じゃ「今現在学んでない言語なんかない」とも言えるか3 4

私は職業プログラマなので当然「仕事用の言語」というのは存在するが,「コミュニケーション用言語」というのはないな。 『数学ガール』冒頭のミルカさんの登場シーンはなかなかインパクトがあるが,あんな感じだろうか。

プログラマにとって最も信頼できる言葉は「動くコード」なので,ある意味で「仕事用の言語」が「コミュニケーション用言語」と言えるかもしれない。 ただ,職業プログラマは非プログラマとも話ができないといけない。 というか,大抵の顧客はそう。 顧客の「言語化されない意図」をいかに聞き取れるかが重要。 ホンマ「コミュニケーション用言語」なるものがあるなら欲しいよ。

あぁでも,要求開発で使う「概念モデリング」は「コミュニケーション用言語」と言えなくもない?

言語を巡る愛憎

自然言語と同じようにプログラミング言語を使う人(要はプログラマ)には、その言語に対する愛情がこもる(愛憎がこもる)。なので、エンジニアリングや効率の話題と思っているのにいつのまにか忠誠心や貢献度みたいな話になることも。

仕事でプログラミングを行う際に言語を選べることはほとんどない。 顧客が指定してくることもあるし(顧客がコード資産を持っている),プロジェクト管理者が指定してくることもある(すでにある資産を使おうとする)。 そうじゃない場合でも要求と予算と期間とプロジェクトの面子によって(つまりそれを使うメリットとか関係なしに)言語が決まってしまう。

もし,そういうのが一切ないのなら,今なら Go 言語か JavaScript/Electron がいいなぁ。 これらで十分だよね。

一時期は Ruby も好きだったが,きれいさっぱり忘れてしまった。 今では Ruby の最新バージョンがいくつかさえ知らない。 なんか Rails 以降,凄い面倒くさいイメージがあるんだよね。 ある機能を Ruby で実装した記事を見かけたら,同じ機能を他の言語でもっと簡単にできないか,つい探してしまう。 こういうのが「宗教的」って言われるんだろうな,きっと(笑)

まぁ,でも,上で書いたように仕事で言語を選べることはほとんどないので,「グダグダ言わずにコード書け」って感じだけど。

【12月21日 追記】 フィードバックで Python について言及があったので。 Python は Linux 等では実質的に(少なくとも Ruby よりは)標準言語のようになっているし,資産も豊富なのでちゃんと覚えなきゃなぁ,とは思ってる。 しかし構文にインデントが必須な言語構造はどうしても慣れない。 同じ理由で Haskell や CoffeeScript とかも馴染めない。

プログラムコードをもっと human-understandable に,という考え方は分からなくもないけど,それなら Go 言語のようにフォーマッタやドキュメントフレームワークを標準で用意するほうが賢いと思う。 私はもうプログラミングで(タブだの全角空白だのも含めた)空白文字に煩わされたくない。

とはいえ,こういうのは「慣れ」の問題なので,仕事でやれと言われれば喜んでやりますよ。

ひとつのプログラミング言語に縛られることの恐さ

一つの技術に縛られることの恐さは、エンジニアなら誰でも知っている。では一つのプログラミング言語に縛られることの恐さは知っているか。一つのプログラミング言語がパーフェクトなことはない。時代が変われば要請も変わる。リソース配分は時々刻々変わる。そんな中で何にコミットするか。

手続き型言語の弱点は「ノイマン型コンピュータ」に最適化されていることだ。

ノイマン型コンピュータの構造はプロセッサとメモリが分かれているのが特徴で5,メモリから命令を順番にプロセッサにフェッチして実行していく。

もちろん「非ノイマン型コンピュータ」というのもある。 典型的なのは,いわゆるニューロチップである。

こういうタイプのコンピュータは(ノイマン型コンピュータで言うところの)プロセッサとメモリがセットでひとつの素子になっているのが特徴で,しかも素子同士はお互いに非同期で動く。 こういうのが本気で市場に台頭してきたら私のようなロートル・エンジニアはお払い箱だ。

若い人が正しい

いつの時代でも、若い人は自由だ。何でも選べる。何でも言える。ときにはバカにされるかもしれない。わかってないよと侮られるかもしれない。でも、ほとんどの場合、若い人が正しい。

先のことは誰にもわからない。 特に今の時代は。 だから「より多くの未来を持っている人」が正しいと言える。 私のように人生の残り時間を勘定している人ではない。

願わくば「何でも選べる。何でも言える」未来を引き渡したいものである。

【おまけ】 TensorFlow に関するブックマーク

フィードバックTensorFlow について言及があったので,ついでに。

(この項は「TensorFlow に関するブックマーク」に移動しました)

参考図書

photo
数学ガール
結城 浩 (著)
SBクリエイティブ 2007-06-26 (Release 2014-03-12)
Kindle版
B00EYXMA9I (ASIN)
評価     

ミルカさんとの衝撃の encounter。数学ガールがワルツを踊る。

reviewed by Spiegel on 2014-02-14 (powered by PA-APIv5)


  1. たとえば,C言語では「ポインタ」の概念でよく躓くと言われているが,インストラクションで考えれば実にシンプル。 ↩︎

  2. 多分もう絶版。 ↩︎

  3. 評価を中断している言語はある。 Erlang とか Scala とか Haskell とか。仕事で絡むようなことがあれば是非やりたい。 ↩︎

  4. そう考えると,私にとって Go 言語はちょっと例外的かも。今のところ身近に Go 言語を使った仕事がないということもあるが,仕事抜きで完全に「遊び」でやってる。はっきり言って C/C++ や初期の Java 以来「これでなに作ろうかな」って思わせる言語に久しぶりに出会った感じ。もっとも,今は仕事が忙しすぎて全然かまってあげられないのだが orz ↩︎

  5. キャッシュやパイプライン等の話はとりあえずチャイしてね。 ↩︎