メモ。
「うちの会社が儲からない理由(ワケ)」という書籍がファミマにあった。
……アントレックスという会社が発行しているISBNレス本なので、書籍流通経由では買えないのだけれど。
内容は、単純に「貸借対照表」「損益計算書」「キャッシュフロー計算書」と、それに絡む数字の集合について「単純化して解りやすく説明しよう」というもの。
普通は「入社時研修での講習時間中に習うこと」ばかりなのだけれど、「入社時研修の内容を忘れてしまった」とか「入社時研修の予習をしておきたい」という向きには良いかもしれない。
190ページもある割には文字が大きく、はっきり言って「内容はスッカスカ」。
とはいえ、表題に掲げられた問題意識に絡む基礎知識を再学習しようとするにはちょうどいい分量だったりする(→より詳しく調べるために必要な「基礎知識」としては十分役に立つ)ところは良いかも。
説明方法が工夫されているから、「わかっていない人向けに説明したいのだけれど、自分自身も説明できるほどには噛み砕いた理解をしていない」という場合には、本書が「うまい説明方法」を提供してくれそうな気がする。
……キー配列の練習方法についても、これぐらい単純化して説明できればいいのだけれど……増田式よりも単純化した説明というのは、なかなか難しいのかも。
相変わらず飛鳥スレッドはぴたりと美味しいところを突いてくるなぁ……と思う。
http://pc9.2ch.net/test/read.cgi/pc/1111550971/829-833
長い＆ピンボケなレスなので、直接レスできそうにありません……というわけで、日記から失礼します。
>>829さんの「ズボラ＝正しい」説は、2007年の現段階で「総意を得るに至っている」かどうかはまだ微妙かも……生産業務系では半ば常識化*1していても、事務業務系で常識化しているという話はまだ聞いたことがない(いや、単に私が知らないだけかも？)ですので。
創作文記述用キー配列を設計する上での肝は【「使いやすい」配列を作ろうとする→「打ちやすい」手になるよう設計する→「結果として」楽に叩ける方法を取れば、それがほぼ正解となる】なので、【その配列が「楽であること」を目指して設計された配列である】場合であって、なおかつ【その配列が含む仕掛けを、利用者自身が快適だと感じる】場合には、「ズボラ＝正しい」がほぼ成立するはずです。
この方向性をとる場合には【機械的に配列を設計するだけでは、どこかに必ず矛盾が生じる】ので、結局人力設計や人力評価に頼るしかない……とすると、飛鳥がそれを満たしている可能性は(75人月かけて設計しているだけあって)十分にあるのではないかな、と。
>>833さんの「【自己の感覚】と【配列】との整合性でモメている」という点、激しく同意です……。
どの配列も「良いと思った方向性で配列を設計し、そこからさらに良いと思えるように配列を組み替えていき……」とやって「膨大な検索木から枝を徐々に切り落としていく」過程を経るはずなので、枝を切っていく過程が異なれば、結果としてできる「仕上がり配列」は異なってくるはずです。
漫画家すがやみつるさんのような例*2はある意味極端としても、たとえば小指伸領域の問題一つを見ても「積極的に使うべき*3」という考え方もあれば「なるべく使うべきではない*4」という考え方もあるし……と、個々人の事情に応じて色々あると思われます。
現実的な問題として【全員がローマ字入力一つさえ覚えておけば、誰もが幸せになれる！】などという盲信論*5は既に破綻しているだけに、あとは「各自にとっての理想の配列」を作成するなり探すなりすれば、それでよいのではないか……と考えています。
【GNU Visceral C Compiler(GVCC)】の提案……というか、ハンドコーディングによるプログラミングの「無理・無駄・ムラ」ってなんだろうか？ということについて思考してみるテスト。
今日のscim_anthy_nicola.cpp……に関連して。
ええと……cvsから拾ってきたscim_anthy_nicola.cppの1.34にて、なぜか「同じ関数」が2つあるような……。
それと、これは泣き言のほうなのだけれど……「#include」って「そのファイルに対してincludeする」ということで親ファイルには定義されているけど、定義「される側」にはこういう情報が書いてないんですね……当たり前なのだけれど。
【このファイルからincludeされています】というコメント、(プロジェクト内のファイルに限る必要はあると思うけど)プリプロセッサなどで付加できると良いような気も(人力で付けると整合性が取れないので、それはするべきではない気がする)。
ソースをgrep/explorer検索などすれば"scim_anthy_nicola.h"がincludeされているところはすぐ見つかる(→scim_anthy_reading.h)のだけれど、何かもっといい方法があるような……。
うーん、「プログラムを組むとき」に毎回思うのだけれど、「3日前のプログラムは他人のプログラム」という状態が、どうして発生するのか……というところは重要なことなのかもしれない。
プログラムを毎日触っているときには「どのステートが何をしていて、どういう風に関数なり処理なりが絡み合っているのか」をすぐに思い出すことができる、と。
そして、数日触っていないと(忘却曲線に沿う形で)それが思い出せなくなってきて、最終的には「全く読み取れない状態になってしまう」と。
一度概念が吹き飛んでしまったプログラムを読み直すのは、他者が書いたプログラムと同じで「全文読む→構造を理解する→挙動を理解する」というステップを踏まないと再理解はできないのだけれど、個人的にはこの「再理解」というプロセスが【ハンドコーディングによるプログラミング作業における「無理・無駄・ムラ」を3つとも含んでいる】様に思うのです。
プログラムをズバッと読解出来る方から見れば【は？馬鹿じゃねーの、それをすぐに読み取れてこそプログラマだろ。ソースは唯一の仕様書で、かつ唯一のコトバだ。】と笑われるだろうけれども……。
生産業務*1に関わってきた私から見ると、このソースの読解という作業は【プログラムを改変しようとする際に、必ず先立って行うプリプロセス】である様に見えるわけで、何らかの工夫を積み重ねていくことにより「そのプリプロセスはほぼ除去することが出来る」のではないかな……と、そう希望を持っていたりします。
とはいえ、私はプログラミングに関する知識など「ないに等しい」ワケで。
MS-DOS時代にはバッチファイルを書いたり、N88-BASICをちょっと触ってみたり、JGAWKで一行野郎コードを書いたりした事はあるのだけれど、言語構造の根本的な仕掛けは理解していないんですよね……。
【読解力のあるなしに関わらず、誰が見ても同じ時間でプログラムの内容(関数類の相関関係とか、動作の仕様とか)が理解できるようなシステムを構築する】ことが、今後のプログラミング環境における生産性を一気に引き上げるために重要なのかも？と。
こういうシステムは「コンパイラ」「プリプロセッサ」「システム関数」などと密接に関わっているので、基本的には「コンパイラを設計できる人でなければ構築できない」のかもしれないですけど……。
……ええと、誤解を承知で書くならば、「現状」と「理想」のプログラミング環境というのは、これぐらい乖離しているのかもしれない。
- 【現状】
- 【理想】
スクリプト規模のプログラミング環境や、エミュレータといった分野では出来ていそうなこと……それを、「一般的な大規模開発で使われている言語系で実現すること」ができれば、「(ソースをアイボールサーチすることと同じ精度で、かつ)すぐに動作を理解できる」ような気がしていたり。
それこそ、たとえば【GNU C Compiler(GCC)】に対する【GNU Visual C Compiler(GVCC)】……じゃなかった、【GNU Visceral C Compiler(GVCC)】*2が、今後必要になるのかもしれない。
#【Visceral ○○】の「○○」には、今あるどの言語/コンパイラでも当てはまるような気はする。
極端な話、こういう方式を取ってしまえば「多言語(無言語？)表示型プログラミング」とかいう事も出来そうな気はするわけで。
うーん……単なる放言しか出来ない自分の現状(理解力のなさ)に意気消沈していたりorz。
#あっ、ばかげた話だということは重々承知していますので……「さそり座の女(@美川憲一)」ばりに【気が済むまで笑って良いですよ】という感じです。
