kolmas.tech note

雑記と思索、偏った技術の覚え書き

大概のものは煮れば食える

食べ物

本エントリにおける私の主張は表題で言い切った。息子らが将来一人暮らしをするような時が来たら、自炊の心得として伝えたいものである。裏を返せば、煮るだけで食えないような食材には手を出すな、という事でもある。1

自炊は面倒

高校三年の末、翌四月から始める一人暮らしに向けた準備を実家にてしていた頃、簡単な料理の方法を母に仕込まれた。恥ずかしながらそれまで料理の経験はほとんど無かった。一応、定番のカレーとか味噌汁とか、鰤の切り身を買ってくれば照焼とか、位は作れるようになった。

さてその上で始めた一人暮らしであるが、真面目に自炊をしていたのは最初の一週間だけである。その一週間中に、大学の学食が平日20時まで開いている事に気付いたのだ。18時頃まで授業があればその後に学食で食べて帰り、そうでなくても、適当な時間まで図書館などで時間を潰してから学食で食べて帰る、という生活になった。また、一人暮らし開始当初は朝食を食べていたのだが、この習慣も早々になくなり、平日の食事はほぼ全て学食、という生活をしていた。

しかし学食は休日には開いていない。仕方がないので、週末は自分で作るかスーパーの惣菜か弁当2、という生活をしていた。週末一人だけで食べ切れる量を作るというのは正直面倒くさい。例えばカレーを作るにしても、そのような量では野菜やカレールーが中途半端に余る。料理慣れしておらず、律儀にレシピ分量を守って作るものだから、そういうことになる。これら中途半端に余らせた野菜は放っておくと腐るので厄介だ。カレールーにしても、開封したものをあまり長期間置いておきたくはない。そういった余り食材を良い感じに消費する料理レパートリーは、それまで料理をほぼしてこなかったズボラ大学生には備わっていない。

一人暮らしを始めて3年経った頃、諸般の事情でそれまでのアパートを引き払って新しい所に引っ越した。引越し先は、目の前にコンビニがあるのに加え、その建物自体の一階に定食屋が入っていた。こうなっては、もう週末の料理も一切しなくなった。

鍋と食材と熱源だけあれば何とかなる

数年間そんな生活をしていた折、試作ケバブのエントリでも触れたが、フィンランド・ヘルシンキに留学する機会を得た。あちらに渡る前に学生寮の手配を付けることができ、生活上の残りの不安は食事だけという状態で渡航した。寮の目の前に小さめのスーパー3があったので、初日などはそこのベーカリーのパンを食べたりしていたが、それだけという訳にはいかない。

幸い、上掲のエントリで記載したように行きつけのケバブ屋やハンバーガー屋が確立され、さらに平日昼は留学先の学食で食べるようになったので、食生活は早々に安定した。とはいえそれでも、週末の食事にはやはり困る。街に出かければ良いのだが、くたびれて出かける気力のない日もある。件のケバブ屋ですら、寮からは1.5kmくらい歩かねばならない4。しかしそれでも腹は減る、ということで何か作るかという事になる。これまた幸いなことに、ある程度の生活用品は備え付けられている学生寮で、二部屋で共同利用するキッチンに加えて、各部屋ごとに鍋とフライパン、食器があった。包丁は共同利用キッチンの備品としてあったが、隣部屋の奴の使い方があまり衛生的でなくて正直使いたくない。その視点でスーパーを見て周り、切らずに食べられそうな食材を買い込んで、鍋に放り込んで煮てみた。

初回は本当に具材のみを水から煮ただけで、あまりにも味気なかった。その反省を踏まえ、二回目はスーパーでスパイスミックスを買ってきて鍋に振り入れてから煮てみた。そうしたら食べられる味、というか十分に旨い鍋になった。この、スーパーに売っている切らずに食べられそうな具材を適当に買ってきて煮る雑多鍋は、その後も何度か作って食べた。

フィンランド留学中、スーパーで売っていたソーセージや肉団子、芽キャベツ、キノコなどをパスタと一緒にまとめてスパイスミックス振って煮ただけのもの。これで十分旨い。

この時買ったスパイスミックスは色々と使えて便利で、留学中に残った分は日本に持ち帰ってきて使い切った。

www.santamariaworld.com

確実に火を通すには煮るのが一番

フィンランド留学の頃、他に作ったものとしては、以下デイリーポータルZの記事に触発された肉の油煮がある。

dailyportalz.jp

この記事によると、油の温度は100度に留めなければならないらしいが、直火でそんな精緻な温度コントロールは私には出来ない。記事ではオーブンを使っているが、そんなものもない。しかし、100度で良いのなら、湯煎するという手が考えられる。そこで耐熱ガラスの容器を買ってきて、そこに件のスパイスミックスを振って冷蔵庫で休ませておいた豚肉の切り身十切れ近く5を放り込む。それが全て浸かるだけの大量のサラダ油を注ぎ込み、蓋して水で満たした鍋に入れる。後は水が激しく沸騰しない程度の火加減で煮続けるだけ。数時間くらい、時々様子を見つつ放置していた6だろうか。最後はガラス容器を取り出して、ある程度冷ました後で冷蔵保存。食べる時は、ガラス容器の油の海から食べる分だけの豚肉を取り出して、フライパンで軽く焼くだけ。すぐに食べられて中々旨い豚肉が出来た。

肉や魚を扱うにあたって、私のような料理初心者が恐れるのは、下手に火の通っていないものを食べて腹を下す事である。塊肉等は特に、焼くなどの調理法で良い感じかつ確実に火を通せる自信は、私には全くない7。その点、煮るという調理法は、時間さえ十分にかければ、何か特別な技能などなくても火を通せたと安心できる。煮過ぎても良くないのかもしれないが、確実に火が通ったであろうという安心には代え難い。それに、その発想で安全時間を過大に取った上掲の雑多鍋と豚油煮、どちらも結構美味しく出来ている。とにかく煮るという、確実に火を通せてしかも旨い調理法は料理初心者の味方である。

ちなみに上掲の豚油煮、湯煎後のガラス容器の中には大量の油の他に、液体全体に占める割合は2割弱程、豚肉のエキスなのか、茶色の液体が出ていた。油より重いために綺麗に層が分かれて沈んでいるこの液体、肉を全て食べた後に上層の油を廃棄して取り出してみると、豚肉からコラーゲンでも出ているのか、冷蔵されてプルプルになっていた。このプルプル豚肉エキス(?)を上掲の雑多鍋を煮る際に追加で入れてみたら、味のレベルが上がった。

雑な煮物は人を拘束しない

更に何が良いかと言えば、とにかく雑に煮るというアプローチは、人を調理作業に強く拘束しない。無論、熱源を使う以上は完全に放置する事は出来ないが、吹きこぼれないよう内容に対して十分容積の大きい鍋を使って弱火放置出来るようにすれば基本的に安全である。電熱調理器やIHならば尚安心。実際、上掲の数時間煮込んだ豚油煮、私は数時間張り付いていた訳ではなく、煮ている横でパソコン開いて全く別の作業をしていた。

一人暮らし大学生の時間は貴重なのであり、自炊ばかりに取られる訳にはいかない。その点、上掲の雑多鍋にしても豚油煮にしても、調理に拘束された時間は具材を鍋に入れて火にかける所までである。安定して煮込んでいる間は、その場を大きく離れる事は出来ないにしても、その範囲内で他の事が出来る。調理時間全体が長いのはその通りだが、実質的な拘束時間がほとんど無い事が重要である。その分、他の家事をしたり、全く関係ないことをしていたり出来る。

無論、ちゃんとした煮物を作るのであれば、具材を切って、下拵えして、目を離さず煮て、というプロセスが必要なのだと想像される。私はその類の煮物は作ったことがない。しかしここでの議論の対象はズボラ大学生の一人暮らしにおける自炊である。雑な煮物で十分なのであり、手間のかかりそうな料理などそもそもしない。そこそこ美味しく食べられるものをいかに手軽に作るか、が重要である。

尚、自炊定番の料理と言えるであろうカレーは、私の基準では雑な煮物に分類されない。あの手の粘性のある煮物は火にかけて放っておくと焦げるからである。火にかけて放っておけないものは雑ではない。基準は下げていくスタイル。

雑に煮ても旨い

そんな生活をした上で日本に帰ってきて、そしてスーパーを見て回ると、雑に煮るだけで美味しく食べられるポテンシャルに溢れていることに気づく。

肉は、牛豚であれば薄切りを、鶏であれば唐揚げ用あたりを買ってくればそのまま煮る事ができる。店によって色々な量で売られているから、適当に選んでパックの中身を全部鍋に入れてしまえば余らせることもない。業務スーパーで1kg超ほど買ってまとめて煮るなどしていた。魚も、生の切り身を買ってきてそのまま煮るのも良いし、冷凍物も扱いやすい。切らないで煮ても、食べる時に簡単に崩せるから何の問題もない。他には例えば豆腐も、パックを開けて水を捨てたら、切りもせずそのまま鍋に入れてしまえば良い。これだけで、タンパク質源はかなり幅広に押さえられる。

野菜類は流石に、包丁を使うつもりでいた方が選択肢が広がる。野菜を切るだけなら、脂っ気がないので包丁などを洗うのもそこまで手間ではない。しかし切らなくても使えるものはある。フィンランド留学時の雑多鍋によく入れていた芽キャベツなどはその例。キノコ類であれば、例えば舞茸やエリンギは手で裂けるし、椎茸は茎をもいで8傘をそのまま煮れば良い。ぶなしめじは株で買うと根本の培地を切り落とす必要があるが、カットぶなしめじを買えば袋を開けて鍋に入れるだけである。カット済みのものを買う、という観点からは、鍋用カット野菜のセットなど色々なスーパーで売っているから、買ってきてそのまま煮ればより野菜が充実する。冷凍野菜も良い。あく取りが必要な野菜の大手どころであるほうれん草や牛蒡、ブロッコリーなどは、あく取り不要の冷凍物が容易に手に入るので、それを煮ておくのが手軽である。一度だけ牛蒡の下処理を手ずからやった事があるが、あんな面倒なことはもう二度とやりたくない。

味付けについても自分で難しいことを考える必要は全くない。味の素「鍋キューブ」に代表される鍋の素を入れれば一発である。ストレートの液体鍋つゆも手軽で旨い。スーパーにて、どの味にするか難しいことを考えずに選ぶのは楽しい。そうして多めの量を作った鍋を2〜3回に分けて食べ切り、最後に残った汁に〆の麺を入れて汁も余さず食べ切る、ということをよくやっていた。そうすれば最終日は米を炊く必要すらない。行きつけの業務スーパーに売っていた以下の麺を買い込んでよく食べていた。 www.fujiwara-seimen.co.jp

肉の油煮も帰国後何度かやっている。色々なフレーバーのスパイスミックスがスーパーで売られている9ので、それだけでバリエーションが付けられる。鶏もも肉に一枚ずつスパイスミックスを馴染ませ、上掲の手順でまとめて油煮にする。食べる時は、一枚ずつ取り出して皮目を軽く焼けば、毎回ジューシーな鶏ももになる。これは妻にも好評であった。

再掲：大概のものは煮れば食える

という経験を経て、大方のよくある食材はひとまず煮ておけば食べられるな、という極致に至った。そう思っていれば、自炊に何の怖さもない。冒頭で述べた通り、息子らが自炊する必要が出てきた時には伝えておきたい事である。

  1. 炊飯器で炊ける米は例外。↩
  2. 幸い、スーパーに加えてほっともっとの店舗が徒歩圏内にあった。↩
  3. Alepaというヘルシンキ都市圏のスーパー。日本のコンビニとスーパーを足して二で割ったような広さの店だが、食料品は大抵揃う。研究室に先にいた他の留学生曰く、比較的店舗数が多く尚且つフィンランドにしては遅くまで営業しているので便利だが、その分価格帯が若干お高め、らしい。en.wikipedia.org↩
  4. バスもあったが、待ち時間を考えると徒歩とどっこいどっこい。↩
  5. 1.5〜2cm厚位の切り身で、日本だったらトンカツとかトンテキに使うような見た目の豚肉だった。フィンランドにも似たような料理があるのか？その肉が10枚近く入ったパックで売られていた。↩
  6. 隣が居ないタイミングを見計らって実施。↩
  7. ローストビーフとか出来る気しない。↩
  8. 包丁を使うつもりなら、もいだ椎茸の茎をみじん切りにして鍋に入れるとこれまた味が出て旨い。↩
  9. その様々なフレーバーの情報を判読できる、というのが大きい。フィンランド留学時代にフィンランド語の勉強はしなかったので、当時、スーパーに売られている大半のものは見た目に分かりやすいもの以外判別できなかった。↩

「自動プログラミング」というもの

プログラミング

最近の生成AIを活用したプログラミングはなかなか凄い。指示=プロンプトを出してやれば、少なくとも一定程度世の中でやられているようなプログラムならソースコードを生成してくれる。例えば先日のエントリで紹介した息子用ランダムタイマー程度なら、それなりに書いてくれただろうと思う。自動でプログラミングしてくれるとも言える。将来的にプログラマは不要になるという言説も見かける。

一応これでも一定程度のプログラミング技法を修めた人間として、プログラマ不要論には感情的な反発を覚えるのを否定できないし、一方でプログラマの仕事を一定程度代替・自動化してくれるポテンシャルは間違いなくあるとも思う。このあたりの思索をまとめてみたい。

信用はしきれない

まず第一に、巷でもよく言われる事であるが、生成AIが出力したプログラム・ソースコードを何のチェックも無しに実用することはまだできまい。ほとんどの場合において、質問者の意図に即して問題のないソースコードを出力してくれるとしても、必ずそうである保証は誰もしてくれない。保証がない以上、その出力結果を人がチェックする必要は必ずあり、そのチェック作業を行うにはソースコードを読む能力が必要である。その点で、所謂プログラマと呼ばれる職種の仕事は、低減される可能性は大いにあるが、全く無くなることはない。そもそも生成AI自体、そのプログラムは誰かが書いている訳で。

生成AI技術の進歩によってその回答の信頼性は上がってゆき、いずれはチェック無しに生成AIが出力したソースコードを活用できるようになる、と主張する向きもあるかもしれない。しかし個人的には、そもそも現在の生成AIというものの考え方の限界として、それには無茶があると考えている。例えば以下のような懸念は、生成AI技術の進歩だけでは消せないだろう。少なくとも今は、まだ。

  • 悪意に脆弱である。生成AIが出力したソースコードをチェック無しにそのまま利用する事が一般的な世界を仮定したとき、その生成AIを提供する側に悪意があれば、間違いなく出力されるソースコードにバックドアを仕込むだろう。コンピュータセキュリティにおいて性善説を唱えるのは愚かである。
  • 生成の典拠となる情報源が玉石混交である。ウェブ上には上記の件のような直接的な悪意がなくとも、古かったり解釈を誤ったりしていて今や適切でないプログラミング技法の解説が数多ある。例えば、Cで標準入力から文字列を取るのにgets関数を使う1とか、HTMLでフォントを変えるのにfont要素を使う2とか。それらが生成AIによるソースコード出力において参照される可能性を否定できない。
  • 著作権上の問題を孕む可能性がある。そもそもこの界隈、ウェブ上にある解説記事のサンプルコードを取ってきて自身のものに組み込んで使うようなことは割と行われていると思う。その場合、そこにはそうする人の意図があり、そうして良いかの判断も3ある。しかし生成AIの場合、その生成物が人の意図しない所で著作権に触れてしまう可能性はある。意図が無ければ、そこには当然判断も有り得ない。

より高次の自動化に進んだという見方

上述の通り、生成AIによるソースコード出力がプログラマの役割を完全に代替する事は無いと考えている。しかしその一方で、プログラマの業務を低減する便利ツール、という一言で片付けて良いのかというと、個人的には引っかかる所もある。これまでのプログラミング方法論のパラダイムを大きく転換するポテンシャルを持っているという見方も可能なように思う。

本エントリの表題にも挙げている「自動プログラミング」という言葉から想起されるものとしては、現在の文脈であれば、まさに本エントリの主題である生成AIによるソースコード生成があたるだろう。しかし一昔前であれば、「自動プログラミング」というのはコンパイラのことであったと聞く4。即ち、機械語ないしアセンブラを直接書くのではなく、より人にとって分かりやすい高級言語によってプログラムを記述し、そこから自動的に機械語を生成する事が、「自動プログラミング」と呼ばれたのである。その点、生成AIによるソースコード生成も構図は似ている。即ち生成AIは、高級言語よりもさらに人にとって分かりやすい自然言語を入力に取って、そこから高級言語のソースコードを自動的に生成しているのである。そのように捉えれば、自動化の段階がより高次に進んだと整理する事も出来る。

もしかするとコンパイラの登場当初は、機械語ないしアセンブラを直接書かずに済む便利なツール、程度の立ち位置だったのかもしれない。しかし今から見れば、高級言語でプログラミングするというのは至極当たり前の事である。振り返るに、コンパイラの登場はプログラミング方法論に対する一つのパラダイムシフトだったのではないかと思う。つまり、近い将来同様の構図により、生成AIがプログラミング方法論にまた一つのパラダイムシフトを齎したものとして数えられる時が来ても不思議ではない。

勿論、構図に類似性はあるとはいえど、これら二者の間には大きな隔たりもある。形式言語と違って、自然言語の解釈には曖昧性がある。また、生成AIの出力は端的に言えば既存情報源の統計上にある。これらの特徴から、生成AIによるソースコード生成は決定論的ではない。そこには上掲の問題点もある。これに対してコンパイラの挙動は決定論的、即ち、あるコンパイラに対して決まったソースコードを入力した時、得られるコンパイル結果は一定である。それ故に、コンパイラが信頼できるものであれば5、少なくとも元のソースコードの通りに動作する生成物は得られると考えて良い。これは生成AIによるソースコード生成と明確に異なる。

違いがあるからこそ、将来的にパラダイムシフトとして扱われる何かである、と言えよう。

「一から作っている」という幻想

ところで、コンパイラの黎明期には、コンパイラの生成物よりも、人が直接書いた機械語・アセンブラの方がパフォーマンスが高かったと聞く。今やコンパイラにおける自動最適化技術の発展により、下手な手書きアセンブラよりもコンパイラの生成物の方が高いパフォーマンスを得られる事も多かろう。しかし、そうでない時期は存在していた訳だ。

そのような時に保守的な向きから出てくる指摘に、やはり一からプログラムを作れなければ駄目だろう、というものがあると思う。現在の生成AIによるソースコード生成にも同じ事が当てはまろう。生成AIの出力を完全には信用出来ない以上、その内容をレビューできる必要はあって、それ即ち、そうしようと思えば自分でそれを一から作れる能力があるという事ではないかと。私も大概保守的な方で、感覚的には同じ意見である。

ただ冷静に考えてみると、「一から作れる」というのはそもそもどういう事だろうか。例えば、冒頭で例示したランダムタイマーを、私は「一から作った」と言えるのか。確かに、あれを構成しているHTML・CSS・JavaScriptは私が全て手ずから書いた6ものである。ドキュメントや関連記事を多少調べはしたが、基本的に、それらを理解・整理した上で自分で書き起こした。しかしそれだけである。画像・音声素材は自分で作ったものではない。そもそも、あのランダムタイマーの動作環境たるブラウザ自体、当然私が作った訳ではない。HTML・CSS・JavaScriptそのものの仕様もまた、当然私が定義したものではない。その点、私はウェブ標準というお釈迦様の掌の上7であれを作ったに過ぎず、その視点から見れば、とても一から作ったとは言えない。

もう一つ例として、コンパイラを考えてみよう。あるコンパイラを要する高級言語を扱う際には、明らかにそのコンパイラという掌の上でしか動けない。ではコンパイラを作れれば「一から作れる」と言えるか？コンパイラをコンパイルするための処理系は？機械語が書ければ良いのか？機械語が書けたとしても、それは動作環境のCPUアーキテクチャに依存している。ではCPUが設計できれば良いのか？だとしても、今度は物理的な意味でCPUを作らねばならない。生産工場を持っている？では次は材料を調達せねばならない、と、キリがない。この流れは極度に簡素化しているが、それですら本当の意味で何かを厳密な意味で「一から作れる」人など存在し得ない。誰もがお釈迦様の掌の上にいるのである。この文脈におけるそれは、具体的には、様々な技術、ひいては人間の相互依存によって構成される分業の社会である。当たり前の事として、社会全体の視点においてその方が効率が良い。

それを踏まえると、生成AIが出力するソースコードをレビュー出来なければならないという事は変わらないが、それを「一から作れる」事と等価とするのは傲慢なのだろう。我々に必要なのは、同じお釈迦様の掌の上にいる兄弟子、くらいのスタンスだろうか。

生成AIは「便利な道具」を脱するか

一方で、生成AIそれ自体がお釈迦様の掌であるように扱われる日が来る事も、可能性としてはあるだろうと思う。つまり、今のコンパイラのように、プログラミングにおいてほぼ盲目的に信用できる基盤的機能になるという事である。そうでない限りは、まだまだ、プログラマの仕事を軽減してくれる便利なツールの枠からは出られない。それを脱するまでには、上掲のようにまだ問題は多くあり、恐らく生成AI技術の進歩だけでは解決できない。しかしそれを乗り越えられたならば、それは正にプログラミング方法論におけるパラダイムシフトと言えよう。

コンパイラが当たり前に存在する時代にプログラミングを始めた身として、これからそのパラダイムシフトが起こるのか否かについて、興味深く見ている。

余談① ー 先輩とpow

大学学部生時代、研究室の先輩に、センサネットワーク端末のプログラムを書いている人がいた。所謂組み込み環境・マイコンのプログラミングであり、Cのソースコードを当該マイコン向けにクロスコンパイルして焼く、という事をされていた。一時期その先輩が、pow8が使えないと嘆いていた。math.h定義の数値処理用関数のライブラリをリンクすると、出力されるバイナリのサイズが大きくなりすぎて当該マイコンのメモリサイズを超えてしまうのだ。先輩は嘆きながらpow等価の関数を自前で9拵えていた。

「一から作っている」のか否か、の話題を考える時、いつもこのエピソードを思い出す。少なくとも私は、powを自作した事はない。

余談② ー 「ピタゴラ装置をじゅんびする装置」

長男も次男もNHK「ピタゴラスイッチ」が好きである。中でもやはり、特にピタゴラ装置を好む。私も好きである。

その中に、「ピタゴラ装置をじゅんびする装置」というものがある。読んで字の如く、ピタゴラ装置の構成要素を並べて準備する部分がピタゴラ装置化されている。装置を準備する装置、言い換えればプログラムを作るプログラムというメタ視点を提示する含蓄ある装置で、中々見応えがある。まさしく本エントリでも度々取り上げたコンパイラの話題にも通じる。

ただ、最初見た時の感想としては、凄いなと思いつつも、例えばドミノの部分などは事前に用意されている一式を運んできて設置するだけなんだなー、等といったことも思ったことを覚えている。しかしよく考えてみれば、我々のプログラミングだってそんなものである。これは上掲のpowの話と同根で、普段我々は、既にあるライブラリ機能を組み合わせて新しいプログラムを作っているのだ。毎回全ての機能を「一から作っている」訳ではない。そこまで含めて、改めて含蓄に富んだ装置であると思っている。

www.nhk.jp

  1. かなりシンプルに呼び出せる関数であるが、バッファオーバーランを起こす危険があるため利用すべきではない。代わりにfgetsなどを利用すべき。↩
  2. かつては良く使われたが、文書の意味構造に関係ない要素であり現行のHTML標準では廃止されている。CSSを利用すべき。ここでの「かつて」は20年とか前の話である。↩
  3. 少なくとも本来望ましい姿としては。↩
  4. 私はその時代を直接知っている訳では無く、歴史として聞いた事があるだけである。↩
  5. その信頼は、企業や、裾野の広いオープンソースコミュニティによって保たれている。↩
  6. 久しぶりにちょっと手を動かしたかったので。↩
  7. 慣用表現として使っているのであって宗教的意図はない。本エントリ中、他の箇所における同表現についても同様。↩
  8. Cの数値処理ライブラリに含まれる冪乗を計算する関数。↩
  9. その先輩が必要としていたのは、冪指数が自然数に限定される簡単な計算ではなく、有理数を冪指数に取るものであった。当然、Cの数値処理ライブラリ中のpow関数はそれもできるので、そのまま使えれば苦労はなかった訳だが。↩

人類知性とコンピュータ：SNSは人には早すぎる？

諸々の思索

チ。の感想エントリ三件目で、人類知性が技術発展や社会変革に適応していくための過渡期について言及した。過渡期においては、その発展・変革が人類に負の影響を与える事もあり得る。最近の技術発展が加速する状況において、その負の振れ幅も大きくなっていて、油断しているとふとした拍子に人類文明を滅ぼしかねない。故に、人はそうなる事を抑止する事を常に意識していなければならない。

ここでいう下手したら人類文明を滅ぼしかねない何かの一つとして、SNSが挙げられる、ということをここ最近ずっと考えている。

SNS遍歴

一応、まずはこのエントリを書いている私自身のSNS遍歴をまとめておく。意図的に距離を置いている節があるので、少なめではある。

  • mixi：最早よく覚えていないが、高校生の頃にやっていた。そこまでのめり込んでいた訳ではないが、少しは日記なども書いていたか。下記のTwitter利用開始に合わせてほとんど見ることもなくなり、具体的な時期は覚えていないが、そのうちにアカウントを消した。
  • Twitter（現X）1：2009年、大学研究室の仲間内で流行っていた所からアカウントを作る。その当時から今に至るまで、フォロー・フォロワー範囲はほぼリアル知人のみ。所謂「ツイ廃」な知人には全く及ばないが、かつては多少発信していた。ただ、そのうちに発信する事への敷居が高くなってきて億劫になり、ほぼ見るだけになる。そして今やログインすらしていない。今やこれしかコンタクト手段がない知人がいるのでアカウントを消すまではしていないが、ログインしていないのであまり意味はない。
  • Facebook：Twitterと同時期にアカウント作成。こちらも繋がっていた範囲はリアル知人のみ。Twitterと違ってこちらは当初から見るだけ。こちらもアカウントを持っておく事すら億劫に感じてきて、2022年にアカウントを消した。
  • SNSに数えられるか否かは微妙なラインだが、グループチャット系のアプリは仕事以外でもいくらか使っている。通知は全て切っており、見る頻度は極めて低い。

多分、同世代の人間の中ではSNSをほぼ使っていない方に分類されるのだろうと思う。どれも最終的に、自分の発信が周囲にどのように解釈され、良し悪し問わずどのような反応を起こしうるか、という事を考え出して面倒臭くなってきたのである。

人間、居心地良さを求めがち

少なくとも私は、心地よい対人関係の中で生きていたいと思っている。もしくは、対人関係における無用な対立を避けたい、とも言える。対立にはエネルギーが必要であるからである。勿論、社会生活を送る上でどうしても発生する対立はあり、それを否定する意図はない。私も、自身の信念がある事について対立があった時に、一方的に折れるつもりはない。これは必ずしも相手を言い負かす事を目指すものではなく、場合によっては議論を通じて自身の信念が変化し、より洗練される事も含む。そのような議論もエネルギーを要するものであるが、全て避ける事は出来ない。

ただ、社会生活上必須でないものに対してまで、そのようなエネルギーを投じようとは思わない。少なくとも私は仕事に関連してSNSを使っていたわけではないので、それらが無くても私の生活は破綻しない。そんな場で対立的な対人関係など持ちたくない。各種SNSにおける私の繋がり範囲は上述の通りリアル知人のみであり、それぞれに多様な考え方を持っている人が入り混じる場2であった。その場にあって、余暇活動であるSNSに於いてまで対人関係のエネルギーを使うのは下策である。大事な事は直接話せば良いのだし。そんな訳で、後は上述の通り、段々と発信が億劫になってSNSから遠のいていった。

私のような引き籠り的アプローチであるか否かはともかくとして、対人関係における無用な対立がない方が居心地が良い、という事それ自体については一定程度同意が得られるのではないかと思う。その上で、私のように知人に閉じた使い方ではなく、不特定多数にネットワークを広げる方向性を指向してSNSを使い始める3と、自然と、近しい信念を持つ集団のネットワークが形成される。するとその「信念」は集団の中でより増幅・先鋭化されていく。エコーチェンバー現象というやつである。 ja.wikipedia.org

敵を作ると分かりやすい

大衆を動かしたいと考える人や組織が、この特性を活用しない訳がない。さらに、この時になされがちなのが、その集団に共通の敵を定義してやる事である。何であっても、何かその集団内で共通に糾弾できる敵があるというのは、その集団に属する人にとって極めて分かりやすい。人は分かりやすいものを求める。分かりやすい結論に安住していられるのは、それもまた居心地の良いものである。また、自身の攻撃性を外に発するという事も、残念ながら多くの人にとって快感なのだと思われる。

この、敵を定義してやるという事に、さらに先述のエコーチェンバー現象による個々人の信念の増幅が合わさると極めてタチが悪い。それは人の攻撃性をも増幅する。それが集団全体として、ある種の狂信的思想にまで至ると、元々「無用な対立がない」方が良かったのが、その集団に対する敵との対立は最早無用のものではなくなってしまうのだろう。具体的な例としては、某国某氏の支持者が議事堂に突っ込んだ事件は記憶に新しい。横から見ていたら信じ難いものだが、現にそういう事は起きてしまっている。まあ、件の某国某氏は、ここまで述べた手法を良く心得ている部類であろう。 ja.wikipedia.org

議事堂に突っ込んだ人々にしても、その行為自体が触法行為である事は理解しているのだとは思う。しかしそれを上回る「彼らの」正義によってその行為が正当化されていて、それに衝き動かされているのだろう。正義というのは一義的なものではなく、個人によって、時代によって、文化によって、等々、様々に異なる。故に、正義感が対立を生む事は極自然である。しかし、上述の中でも使った言葉だが、正義感だけで実際にここまでの事をしでかしてしまうとしたら、それは最早狂信の域である。

ドラえもんの台詞、「どっちも、自分が正しいと思ってるよ。戦争なんてそんなもんだよ。」は至言と言えよう。本エントリ冒頭で触れたチ。には、第三部のヨレンタとドゥラカの対話の中で「権威の中で生じる思考停止」というフレーズが出てくる。

隠れた「民意」はろくなものではない

節題が誤解を招かないように念の為まずここで断っておくが、私に民主主義を否定する意図はない。

ここで新たに別の視点を導入したい。SNSが持つ匿名性についてである。無論、実名でSNSを利用している人もいるし、そうでないにしても、所謂一般的なSNSにおいて、真に匿名での発信は出来ない。ここでの匿名とは、発信者が自身の現実世界における社会生活と切り離された立場で発信している4状態を指すことにする。これが上述の特性に更に加わると、また更にタチの悪い事になる。

捻くれた見方かもしれないが、人間誰しも、口にはしないが気に食わない事の一つ二つあるものだと思う。人は聖人ではないのだから、これは仕方がない。その一方で、気に食わない事があれども口にしない理由は様々に考えられるが、究極的には自身の社会生活に不都合をきたすからだろう。これを書いている私もまた、社会生活の中で不満に思っている事はある。不満に思う事は自由である。ただその不満を実際に口に出したり、その原因を排除するような行動をする事は、私の中にある社会通念上の常識に反する、即ち社会生活を円滑に保つための方法論から逸脱する事であるから、しない。軋みのない社会はコモンセンスで成り立っている。

その点、匿名で発信できると思い込むと、社会のくびきから解き放たれ、何でも好きなように発信するようになりがち5であるように見える。そうすると、そのような不満の中には、案外多くの人が共通に持っているものがある事が見えてくる。そうなれば後は上述の通り、その集団の中で当該不満感情の増幅待ったなしである。不満というのは敵の定義が分かりやすいのもあって、共有されればその増幅は速かろう。そうなれば、いずれ当該不満はその集団における絶対的な思想になる。

ここで述べたような、表では言わないけれど多くの人が共通に持っている不満、というのは、ある意味で「民意」なのだろう。SNSには、この「隠れた民意」を強力に可視化する特性があるとも言える。ただそれは、可視化された「民意」としての立場を得る前の個人の思想として発信するのは憚られるようなものだった訳だ。「赤信号、みんなで渡れば怖くない」的な、ろくでもなさがある。大体、大っぴらに言えるような正当性なく敵を定義するような「民意」が望ましいものだとは思えない。最近の諸々の言説において最早陳腐な表現だが、それは社会の分断である。

英雄を危険視する

その一方で、そのような「民意」を拾う事で支持を集めるのが所謂ポピュリスト傾向のある政治家、という事である。ある意味、彼らは「民意」に忠実である。故にその集団からの支持は容易に得られる。その「民意」における敵と対峙する立場を取る彼等は、正にその集団にとって英雄と言えよう。

私は個人的な信条として、政治家にその意味での英雄性を求めてはならないと考えている。そもそも上述の通りそのような英雄は支持を集めやすいし、支持する側も英雄に縋っていればそれ以上の思考を放棄出来るから楽である。それでも、いやむしろ、それ故に、その英雄性は危険である。その傾向を持つ政治家からは距離を置くべきだ。ヒトラーが政治権力を得た背景には「民意」の支持もあった事を忘れてはならない。

その点で、元々表出しているものであろうと「隠れていた」ものであろうと、ただ唯唯諾諾と「民意」に従うだけの姿勢は政治家には望ましくないと思っている。「民意」を無視して良いという意味ではない。「民意」を踏まえながらもそれにおもねる事なく、政治意思を自ずから立てて持っているべきなのである。彼等は、「民意」をそのまま代弁する英雄ではない。そして我々は、そのような政治家連中の中から、最も望ましいと考えられる者を選挙で選ぶのである。これは政治家の側にとっても我々の側にとっても、しっかり物事を考えなければならないという点で負担は大きい。しかし、民主主義的手続きによる社会を健全に保つには必要なことと思う。

尚、余談の域ではあるが、上述と同じ考えにより「庶民感覚」なるものを政治家に求めるのも反対である。政治家というものは、一介の庶民の感覚の中で知覚できる範囲を超えて物事を考えなければならない筈である。一般的な家計の話題等で頓珍漢な事を言って批判される政治家が時々いるが、庶民感覚が無いという事で批判するのは筋違いだと思う。彼等は、様々な国民の経済状況の幅広な実態という、感覚でも何でもない純然たる事実を知らない無知、あるいは知ろうとしなかった怠慢・傲慢により非難されるべきなのだ。

万人が発信する時代にあって

最後は若干SNSの話題から逸れた。実際、このような事は、ヒトラーを例示した通り、別にSNSが登場する以前からあった事である。しかし、SNSの普及に伴いあらゆる人が気軽に発信出来るようになった事が、人の負感情をより高速に拡散・増幅し、社会の分断をより勢いづけている事は否定できまい。上掲の議事堂襲撃の事案などまさにその一例で、実際に暴力の発生まで至ってしまっている。そして、その負感情を糧に支持を伸ばす政治勢力もある。その点、SNSが直接人類文明を滅ぼす訳では無いけれども、その引き金を引きうるポテンシャルは十二分に持っていると思っている。

いつか見かけたNHKの番組の中で、誰の言葉だったか6、一人の英雄より多数の常識、なんて事を言っていた。深夜だったのでその番組を観るのは早々にやめて寝てしまったが、その言葉だけは印象に残っている。常識、という点もポイントであろう。この部分を良識や良心等の言葉で読み替えても良いと思う。周囲に迎合するでもなく、かといって自分の欲ばかりに忠実な訳でもなく、より良い世界がどうあるべきかを各人が考えるという事が求められる。

そしてこれはとても難しいのである。人は弱く、上述のように楽な方向に流されがちで、SNSはその方向性を助長する。そもそも、SNSであらゆる人が発信する情報過多の時代において、人の情報処理能力の限界なんてそんなものだろうとすら思える。安易な分断、対立に陥らずにこの情報過多の時代を進むには、人の情報処理能力なのか、リテラシーなのか、はたまた信念なのか、他の何かなのか、またはそれらの全てなのか、つまりは知性がより高次のものにならなければならないのではないか。解脱とすら言えるかもしれない。それなしには、SNSの特性は人にとって劇物ではないかと思う。

そうは言ってもSNSは既に存在していて、その存在を否定する事は出来ない。せめて、このような事を意識して使わなければなるまい。とはいえ、私とて偉そうな事を言えるような身ではない。上掲の通り、私はSNSに疲れて意図的に距離を置いている人間であるので。

  1. イーロン・マスクに対して思う事がない訳ではないが、ここではそれは意識せずただ単純に、良く使っていた時期にはまだTwitterであったのでその名称を主に、現行の名称のXを副に置いている。↩
  2. それ自体はとても良い事だった。多様な考え方のるつぼであった大学時代の人付き合いがなければ、私は今以上に偏屈な人間になっていたに違いない。↩
  3. その方が今時普通のSNSの使い方なのだろう。↩
  4. 切り離された「と思い込んでいる」立場で発信している、という方が正確か。↩
  5. ここでの論点からは外れるが、所謂バカッター騒ぎなどが象徴的である。↩
  6. 後から調べてみると、濱口雄幸元首相の言葉らしい？↩

ランダムタイマー

子育て 作ったもの

長男も次男もスマホで動画観るのが好きである。1

とは言っても、彼等が自身のスマホを持っているわけでは当然なく、妻や私のスマホで観せている形である。その場面は、概ね次の二通りである。

  • 彼等にとってとても嫌な事をしなければならない時に、暴れる彼等の気を逸らすものとして。典型例は床屋での散髪。2
  • 特に長男について、身に付けてほしい行動を強化する好子として。

ここで注目するのは後者である。スマホで動画を見る事は長男にとって強烈な好子になっている。例えばトイレで用を足すという行動について、スマホ動画を好子として用い、定着させる事が出来つつある。もっとも、ここ最近は動画見たさにさして差し迫ってもいないくせにトイレに行きたがるようになり、これはちょっと如何なものか、という節もある。ABA的手法の導入においては常に、何を強化しているのか、あるいは何を強化してしまっているのか、を意識しておく必要3があろう。望ましい行動を狙って明確に強化できる枠組みを考えなければならない。

というような問題はあるものの、それでもスマホ動画が長男にとって強い好子である事は事実なので、上手く活用できれば良いとも思う。ここで、強化のテクニックには部分強化4がある。一定程度定着してきた行動に対して、好子を与えたり与えなかったりする事で、その行動をより強固に定着させる事が出来る。人がギャンブルにハマるのと同じ理屈である。という訳で、スマホ動画による強化を部分強化にする事を考えたい。

しかし、スマホ動画の「引き」が強すぎて、対象の行動に対して全く見せないと怒り出す所がある。怒るのを宥めるために見せるというのはABA的に見て明らかに悪手である。そこで、スマホ動画を見せたり見せなかったりするという事に代わる次善として、見せる時間を明確に決めて、その上でそれをランダムにするという事を考える。療育の先生5にこのアイデアを相談してみた所、そんなに突飛な発想ではなく、海外のもので、毎回ランダムな時間を測ってくれるタイマーのアプリもあるらしい。

確かに、都度ランダムな時間をタイマーに設定するのは手間であるから、そのランダム時間を作ってくれるタイマーがあると便利そうである。ただ、上述の海外アプリは現在非公開で入手できないのだそう。となれば、作ってしまえば良い。

無ければ作れば良いじゃない

という訳で作ってみたのがこちら。ウェブブラウザ上で動作する。 kolmas-tech.github.io 極々シンプルなプログラムで恥じ入るばかりであるが、一応GitHubで公開している。そんなに分かりづらいものではないと思うが、使い方も以下で説明している。 github.com

スマホのウェブブラウザで動かす事を想定している。とはいえPCのブラウザでも同様に動作する。標準化様々である。縦画面でも動くが、基本的には横画面で使う想定。我々の現役のスマホは、それこそ動画を見せる事に使ってしまうので、このタイマーのためには使えない。そこで、2020年まで使っていたのを保管しておいた、私の一代前のスマホ=iPhone 5sを引っ張り出してきた。古すぎる端末にはセキュリティ的懸念もある6が、このタイマーにしか使わないし、使わせない。

私のiPhoneとしては二代目である懐かしの5s。電池が完全に干上がっていて再充電に時間がかかったが、このタイマーを動かすくらいなら何とかなる。

が、あまりに古すぎて最初に作った上記リンクの版は、一部7がそのまま動かなかった。そのため以下の代用版も作成。 kolmas-tech.github.io

使ってみたところ

長男の最初の反応はまずまず良好だった。元々カラフルなものが好きなので、虹色が流れる見た目になっている残り時間のバーがウケたようだ。そもそもスマホ動画を見せる時のタイマーとして作ったのだったが、最初数回は、スマホ動画すら要らずこのタイマー自体が好子になったようである。妻からは、残り時間バーに飽きてきたら他の模様を追加するのも良いのではないかとの意見があった。こちらは要望に合わせて追加実装したい。

とはいえ、流石に数回の後にはタイマーだけだと好子として働かなくなったようで、今は元の想定通りにタイマーとして妻に使ってもらっている。タイマーが鳴ったらスマホ動画が終わるということは長男も何となく分かっている8様子。今後しばらく経過観察が必要と思われる。妻からは、タイマーがあることでスマホ動画をだらだらと見せ続けてしまう事が抑止されるとの感想があった。

尚、上掲の5年ぶり復帰のiPhone 5sの電池は、このタイマーを時々使うだけであれば、二日半程度なら持続する模様。それだけ持てば上々か。

参考記事

qiita.com 我が家での実際の利用端末として想定した上掲のiPhone 5s、その頃のiOS Safariでは、脚注でも触れているdialog要素がそもそも対応外なのでどうしようもない=それ故に代替版を作成したのだが、それ以外に嵌った点として、setTimeoutやsetIntervalで仕掛けるアラーム音が鳴らないという問題があった。タイマーとしては致命的である。しかも、同じプログラムであるにも関わらずPCのブラウザやiPhone XSのiOS Safariではちゃんと鳴る。上記記事を読んで解消。

  1. 本筋に関係ないが、YouTube等の動画配信サービスにおける自動リコメンド及び自動再生機能は、こと子供が見るという点においては、悪い文化であると思う。飽きずに際限なく見続けられてしまう。また、いつの間にかよく分からない言語の歌とか聴いていて、動画を見てない時にまで、その英語ですらない謎言語で突然歌い出したりする。↩
  2. もっとも、ここ最近は長男も次男も、散髪であれば動画なしでも少しは我慢出来るようになってきた。暴れたら動画が観れるということを強化するのも良くないし、これは望ましい傾向。↩
  3. このことについては別途書きたい。↩
  4. 「間欠強化」とも言われている。「好子」も含め、この辺りの言葉遣いは今読んでいる本のものに従う。この本については別途書きたい。↩
  5. 何人かの先生に見てもらっていて、その内の一人。↩
  6. iPhone 5s対応の最新iOS=iOS 12の最新セキュリティアップデートは2年前。その点では、この5sの跡を継いで今の私の現役スマホであるiPhone XSにも、そのうち換えなければならない時期は来る。www.itmedia.co.jp↩
  7. 具体的に何が駄目だったのかというとHTMLのdialog要素。タイマーの設定画面等で使っている。iOS 15.4以降でのサポートらしい。caniuse.com↩
  8. 分かってはいそうであるが、それに納得して素直に引き下がってくれるかは別の問題。↩

どのプログラミング言語から始めるべきか

プログラミング

プログラミング未経験の妻から表題の質問を受けた。それに対する私の回答は「本質的には何でも良い」である。強いて言えば、手続き型の言語で、入門レベルの内容において所謂「おまじない」が少なく、初学者向けの資料が一定程度充実しているもの、さらには、やっていて楽しいものであれば尚良いと思う。

本質的には何でも良い

本エントリの前提として想定する初学者像、即ち上述の「プログラミング未経験の妻」の像は以下である。

  • 簡単な英語に抵抗がない。
  • キーボードは一定程度扱える。
  • コンピュータを専門として深く理解する事を求めているわけではない。
  • 今すぐ作りたいものが具体的にある訳ではない。

プログラミング遍歴のエントリ②の中でも書いたが、私は、手続き型の考え方を持つプログラミング言語であれば、大概のもの1は全く未経験のものでも少し勉強すればそれなりに書けるだろうという自信は持っている。実際に数種類のプログラミング言語を扱った事がある、というのもあるが、それらの根底に共通する基本的なプログラミング方法論をある程度は体得出来ている2事が大きいと思う。これが大切な事だと考えている。

プログラミング初学者向けに、やれ最新の言語だの流行りの開発フレームワークだの、これらをやっておけば間違いない、という言説を見かけるが、それにはあまり賛同できない。最新も流行りも常に変化し続ける世界であり、今の流行りが今後もトレンドであり続けるとは限らない。その点でも、身に付けるべきは特定のプログラミング言語やフレームワークに依存しない本質的なプログラミング方法論であり、またアルゴリズム、そしてそれらを組み立てて使いこなす思考力である。それを身に付けるために最初に触れるものが、最新のプログラミング言語やフレームワークである必要は全く無い。勿論、最新のものであってはならない訳では無い。しかし一般に、それら最新のものよりも、登場以来ある程度時間が経過しているものの方が、教材等の充実など初学者向けの教授法が確立されているとすら思う。

その点において冒頭で述べた通り何でも良いだろうと思う。また、こちらもほとんど冒頭で述べた通りではあるが、以下の特性があれば尚良いと思う。

  • 手続き型の考え方を持つ。最新や流行りを気にしないとは言っておきつつも、現在様々な場面で使われているプログラミング言語は、手続き型の考え方を持つものが多い。その考え方を押さえておけば幅広に潰しが効く。さらに、広く使われている考え方であるという点から、関数型・論理型の考え方を主軸とする言語と比べた時に資料が多いし、初学者向け教授法の確立という点でも有利と考える。大体、現行のコンピュータ自体、基本的には手続き型のアーキテクチャなのであり、その点でも自然だろう。量子コンピュータ等の話題もあるものの、少なくとも当面は現行のコンピュータアーキテクチャは利用され続けるだろう。
  • 「おまじない」が少ない。ここでいう「おまじない」は、プログラムを成立させるために最低限書かなければならないものの、その時々の理解段階ではまだ内容をしっかり説明できないものの事を指す。例えばCのint main()関数定義は動作するプログラムを成立させるのに必要だが、関数定義の説明をしないとその意味を説明できない。それ以前にintって何、の所から、初見では不明である。他には例えば、Javaのpublic static void main(String[] args)は最近はかなり略記できるらしい3が、それ以前は、このmainメソッドを包含するクラスの定義まで含めて、初学者にとっては訳の分からない「おまじない」であるに違いない。この辺りは、本質的なプログラミング方法論を順を追って理解する際の邪魔になる可能性がある。
  • 初学者向けの資料が充実している。これは先にも触れたが、初学者向けの資料が簡単に見つかる程度には浸透している方が望ましかろう。ただ、その手の資料は玉石混交であり、その中から石を退けて玉を選り抜くための審美眼は必要である。問題は、その審美眼はプログラミングを一定程度身に付けてからではないと得られない事である。にわたま。そこで、良い資料を選んだり、場合によっては自分で資料を作る事が、教導者の役割になる。
  • やっていて楽しい。何が楽しさとして刺さるかは人によって違うだろうが、楽しい方が当然モチベーションが続きやすかろう。ただ、しばらくやり続けていて初めて見えてくる楽しさもあるので、やり始めてすぐに楽しくないから乗り換える、というのはやめた方が良い。どんなプログラミング言語でも、始めてしばらくの間は覚える事ばかりの割に作れる物の範囲が狭いのであまり楽しくない4ので、取っ替え引っ替えしても効果は薄い。その点、上述の「おまじない」が少ないという事には、楽しさが見えてくるまでの負担を減らすという側面もある。

上述の望ましいと考えられる特性を踏まえると、妻の初めてのプログラミング言語として私からお勧めするのは、Python・JavaScriptあたりの、新興の言語とは言えない程度に長い実績があるスクリプト言語なのかな、という気はしてくる。プログラミング遍歴のエントリ①で触れた通り、私が初めて本格的に触ったプログラミング言語はJavaであったが、上述の特性と比して考えると踏まえるとあまりお勧めできない。

コンピュータを本業にするならCをやるべき

ここまでの初学者像は私の妻、即ちその像は上掲の通り、プログラミングに興味はありつつも、コンピュータを専門として深く理解する事を求めているわけではない、という前提に立っている。一方で、コンピュータやプログラミングをしっかり理解しようと思うなら、Cをやるべきだと思う。最初に触れるべきか否かは難しい所だが、少なくともどこかのタイミングでは必ず。

データ型、ポインタ、配列5、静的・動的メモリ割り当て、そしてそれらを使って作る事ができる様々なデータ構造、等々、コンピュータ上でどのようにデータが扱われているのかを理解するのにCほど分かりやすい言語はあるまい。例えばCにおける配列の考え方、即ち複数の同一データ型の値のためにメモリ上に連続確保された領域、からしたら、スクリプト言語等において配列と呼ばれる物は、実際には配列などではない。後者を実現するためにはどのような工夫が必要であるのか、そしてスクリプト言語等の処理系がその工夫を影でやってくれていたという事が、Cで同等機能を実装してみれば身に沁みて分かるだろう。前節にて、Cを「おまじない」が多い言語の一例として挙げたが、ことプログラム、そしてコンピュータの動きを正しく捉えようと思った時には、Cは極めて単純明快な言語である。その点においては、むしろそれを隠蔽する事でプログラムを書きやすくしている、ここでいうスクリプト言語等を含む最近の言語の方こそ、「おまじない」に満ちている。

ただし、本節冒頭でも触れたが、初学者に対する初手の選択肢にするか否かは悩ましい所である。Cをやった後で、それこそ上述の「隠蔽する」タイプの言語に進む方が、後者が何をプログラマに代わって隠蔽してくれているのか良く分かる。ただ、初学者の最初の言語と考えた時に、Cには先に述べた方の「おまじない」が多いことは否定できない。その点では、まず初手では「隠蔽する」タイプの言語で基本的なプログラミングの考え方を押さえた上で、二番手にCを入れる事で、後に述べた方の「おまじない」を解消していく、というのが落とし所だろうか。

また、ここまでの、コンピュータやプログラミングをちゃんと分かろうと思うならCをやっておけという私の主張は、アセンブラを書く人から見たら、まだまだ生ぬるいのかもしれない。アセンブラ及び機械語のレベルは、Cプログラマから見るとコンパイラによって隠蔽されている訳で。そして更に突き詰めれば、その機械語を処理するCPUの設計・構成、ということになる。どんどん深掘りしていくことで、隠蔽・抽象化のレベルはいくらでも下がっていく。

最早ここまで来ると匙加減の問題である。分かっている方がより望ましいに決まっているが、学習コストは無限に増大するので、どこかでキリを付けないといけない。実際私も、Cより下のアセンブラ・機械語とかCPU設計のような話題になると、多少の知識はあるつもりだが実践の経験は全く無い。で、匙加減の問題というある種の逃げを導入した瞬間に、私のCに関する主張もブレてくる。現在のほとんどのプログラマ6にとって、Cを学ぶという事が、その学習コストと得られる効果の釣り合いが最早取れないものであると認識されている可能性はある。それでも私は、Cを学ぶ意義はあると主張したいが。

結局何から始めるべきか

というような事を考え、結局妻への明快な回答はまだ出来ずにいる。もっとも、妻の場合に限っては、私が教えるという観点から、上述の論点に加え、私の手に馴染んでいるもの、という条件で縛ってしまえば良さそうだが。

悩みは尽きない。

  1. Brainf*ckなど、意図的に難読性を高めているようなものは厳しい。↩
  2. こういう事を自ら宣言するというのは謙虚の美徳に反するし、私より余程極めている人など当然のように居る訳で、その点でも心苦しいものがある。しかしそれでも、基本的なものは身に付いてる、くらいは言っても許されると信じたい。↩
  3. 知識として知っているが、まだ自分で試してみた事がない。最近そもそもJavaを書くことがめっきりなく、先日の自作DIがかなり久しぶりの機会だった。↩
  4. 何でもいいのでプログラムが動くという事、それだけで楽しさを見出せる人も当然いるにはいる。私自身がその口である。↩
  5. Cの文脈における配列。↩
  6. 組み込み系やカーネル周り等の場面を除く、一般的に言われるところの所謂アプリ・ソフトウェアを構築するプログラマを想定する。↩