プログラミング言語との付き合い方
今朝見かけたこれ。 こういう話は好きなので便乗してみる。
ちなみに,結城浩さんの通称「デザパタ本」はずい分昔に買っている。 お世話になってます。
プログラミング言語の「母国語」
個人的に母国語と言えるのはアセンブラと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 に関するブックマーク」に移動しました)
参考図書
- 数学ガール
- 結城 浩 (著)
- SBクリエイティブ 2007-06-26 (Release 2014-03-12)
- Kindle版
- B00EYXMA9I (ASIN)
- 評価
ミルカさんとの衝撃の encounter。数学ガールがワルツを踊る。
-
たとえば,C言語では「ポインタ」の概念でよく躓くと言われているが,インストラクションで考えれば実にシンプル。 ↩︎
-
多分もう絶版。 ↩︎
-
評価を中断している言語はある。 Erlang とか Scala とか Haskell とか。仕事で絡むようなことがあれば是非やりたい。 ↩︎
-
そう考えると,私にとって Go 言語はちょっと例外的かも。今のところ身近に Go 言語を使った仕事がないということもあるが,仕事抜きで完全に「遊び」でやってる。はっきり言って C/C++ や初期の Java 以来「これでなに作ろうかな」って思わせる言語に久しぶりに出会った感じ。もっとも,今は仕事が忙しすぎて全然かまってあげられないのだが orz ↩︎
-
キャッシュやパイプライン等の話はとりあえずチャイしてね。 ↩︎