hirax.net::Keywords::「プログラミング」のブログ

■A全判 = A1判( 約60センチメートル × 約84センチメートル )の世界一広い!?迷路（PDF）　

　「迷路」を作り・描き出すRubyスクリプトを書いてみました。手作業無しに迷路を自動作成することができるコードを書いたので、勢い余って「A全判 = A1判( 約60センチメートル × 約84センチメートル )の世界一だだっ広い!?迷路（PDF 6.5MB）」を作ってみました。

　そのサムネイル画像（サムネイル画像のリンク先はPDFファイル）が下の迷路です。下の画像では、均一なハーフトーン画像に見えるかもしれませんが、実は巨大な迷路です。その巨大迷路を拡大して眺めてみれば、「左下」と「右上」に、それぞれ「入口」と「出口」があることもわかるかもしれません。この迷路（464x323ユニットもあります）を、左下（入り口）から右上（左上）まで抜けるには、どんな迷路上級者でも丸一日以上かかるのではないでしょうか。

　さて、「手作業無しに、プログラマブルに迷路を自動作成することができる」コードを書いたにしても、その迷路が果たして使いものになるか・どの程度のものなのか…という確認作業は「とても手作業ではできない」ということに今更ながらに気づかされました。巨大迷路をプログラムで作り出すのは一瞬ですが、その巨大迷路がまともなものであるかどうかを確認するのは、ちょっと面倒そうです。

　迷路のテスト・評価を手動でできないのなら自動でやろう！ということになるわけですが、さてさて「迷路生成プログラムの品質を評価するテストコード」は一体どのように書けば良いのでしょうか？

■C++の「i++ と ++i の違い」とExcelの「i++ と ++i の違い」　

　ビール瓶を開けながら「プログラミング言語」の話題をしました。プログラミング…と言っても、思い切り（プログラミング言語的には）低レベルな話ばかりです。ここで言う「低レベル」というのは、ハードウェアに近いとかそういう意味の「低レベル」ではありません。

　たとえば、「C++で書くけど、ほぼFORTRANなんだよね〜」という「一体どんなC++だぁ？」というツッコミをしたくなるコード論であったり、「それって、必ず７文字のインデントを入れてからC++のコードを書くってことですか？」というこれまた低次元な「インデント論」だったりしたのです。

　そんな中、「（C++なら）とりあえず、a++とは書かずに、++aと書きますよね」という話になりました(参考：C++のi++ と ++i の違い)。そして、さらに、「（C++ではなくて）C言語のi++ と ++i の違い」みたいなことをMicrosoft Excelでも気にすることがあるか？という話題になりました。話題が脈絡無くサブルーチンに"GOTO"するのは、それは単にアルコール１００％の酔っぱらいだから、です。

　「C言語のi++ と ++i の違い」みたいなことがMicrosoft Excelでもあるか？気にするか？というと、その答えはもちろん「YES」です。…なぜかといえば、たとえば、A1,B1,C1という３つのセルがあった時、それらの各セルに対して、
A1=B1
B1=B1+1
C1=B1
という式を設定する場合など、（自分自身のセルを参照する）循環参照になっているために、その際の計算順序は単純にZの法則にしたがって左→右・上→下の順番で行われるために、計算結果は
　A1,B1,C1=1,2,2
となるからです。A1とC1は、同じ式がセルに入力されていても、実は違う値（タイミング）のB1を参照するがために、違う値になるのです。…それは少しばかり「（C言語の）++iとi++の違い」に似ています。

　C++という言語名は「C＋＋って、（＋＋Cじゃないから）使う時は（前の値と同じというわけで）Cに過ぎないよね？」といった冗談をよく聞いたような気がします。それぞれの言語が抱える「（ちょっと意外にも感じる）++iとi++の違い」にはどんなものがあるのでしょうか？そしてまた、Microsoft Excel で++aとa++の違いを気にする人は、一体どのくらいいるものでしょうか？

■未来に生き残る職業は「プログラミング言語・環境開発者」と「ニッチで・けれど高価なものを作る人」　

　お手軽に使うことができ・それでいて高機能なスクリプト言語を使うようになった頃から、少し「難しいな」と思う感じる状況が増え始めました。

　たとえば、何かのデータ処理や解析を人に依頼しようとした時、その「したいこと」を説明するには「処理作業を書く」のが一番楽で…けれど、その処理作業を書いてしまったなら（その作業を人にお願いするまでもなく）「体力溢れるコンピュータが（やりたい）実作業をしてくれる」ので、そもそも人に頼む作業とやらが目の前から消え失せてしまうのです。

　自分で翔べない人間はコンピュータに仕事を奪われる。

グライダー能力

　今日、ふと、未来に生き残る職業は「プログラミング言語・環境開発者」と「ニッチで・けれど高価なものを作る人」だけかもしれない…と考えました。

　「ニッチで・けれど高価なものを作る人」が残る…というのは、ニッチなもの、少数しか必要とされないものを作るには「機械」「自動化される何か」より「人」の方がコストが安いので、未来もきっと残るだろう…という理由です。

　そして、「プログラミング言語・環境開発者」が生き残るだろう…というのは、以前川合史郎さんが書かれたことに、少しだけ似ています。

　自分の子供の世代になると、「プログラムが書ける」というのは「文章が書ける」のと 同じくらいの基本的なリテラシーになるんじゃないかと思う。その時の「プログラミング」 は今より広い概念だろうけれど。

広義のプログラミング

　そんなことを考えたのは、MATLAB EXPO で丸山宏さんの講演を聴いたからです。丸山さんが話す「大規模データ解析」の話を聴きながら、たとえば「流行を感じつつ番組企画や雑誌特集記事を考えるという作業や、経験に沿って故障原因を探っていく保守作業や、人の動きを読み営業計画を立てる事業作成、はたまた誰かの指示に従ってプログラムを書く…といった色々な仕事・作業」は、未来には「マシン」にとってかわられているだろう…と感じたことがきっかけです。

　ここで言う「マシン」は、「調べる」「知る」「行う」作業を指し示す「何か」により作り出され・動く「何か」、です。「マシン」は「（後者の）何か」で、そして、「プログラミング言語・環境」が「（前者の）何か」です。

　近い…といっても二十年くらい先の未来、大量に作る物は（それが日常生活で消費する物品でもメディアでも）、それらは人ではない「マシン」が作り出し、人は「ニッチで・けれど高価なもの」だけを作っているのかもしれないと、ふと考えました。けれど、そんな「マス」と「ニッチ」のバランスでは、人の世界は成り立ちそうにもないな…と思います。

　そんなことを考えたのは、MATLAB EXPOという「プログラミング・処理環境」のベンダーが主催する「場所」でした。

　人間は、決してあきらめてはならない。

「ロボット (R.U.R)」　カレル・チャペック

■Software Design 12月号「物理と数学、そしてプログラミング」　

　今週末に発売された Software Design 12月号 に、「第１特集 ITエンジニアと数学」中の４時限目（「物理と数学、そしてプログラミング」）として、駄文を書かせて頂きました。 記事書きのために書いたサンプル Jupyter ノートブックは、ここに置いておきます。

　世界を方程式で表して、何が起きるかを計算する物理（科学）計算プログラム…言葉だけ眺めると、一見とても難しく思えます。けれど、実は「わりと簡単なのにとても楽しい」ものです。…それが少しでも伝わって、あなたの口癖が（ガリレオ湯川先生みたいな）こんなフレーズになれば幸いです。
「なるほど、実に面白い」

■スマホを使ったプログラミングで 3 次元顕微鏡を作ってみよう!　

　7月18日発売の「Software Design 8月号」に「スマホを使ったプログラミングで 3 次元顕微鏡を作ってみよう!」という記事を書きました。記事の内容は、200円くらいで買うことができるAlliexpressのスマホ顕微鏡ユニットを使い、ほんの少しのプログラミングをして、立体形状と色を計測できる便利ツールを自作してみよう！というものです。

　…今の時代に誰もが手にする「スマホ」というコンピュータは、計算性能も高くさまざまな搭載センサも搭載し、昔の「マイコン・パソコン」世代からしてみると、「これでプログラミングしないともったいない！」と強く感じてしまう今日この頃です。