このブログの更新は Twitterアカウント @m_hiyama で通知されます。
Follow @m_hiyama

メールでのご連絡は hiyama{at}chimaira{dot}org まで。

はじめてのメールはスパムと判定されることがあります。最初は、信頼されているドメインから差し障りのない文面を送っていただけると、スパムと判定されにくいと思います。

［参照用 記事］

フローチャートをめぐる迷信と妄言と愚昧

雑記／備忘

2011年12月20日の記事で：

[フローチャートについて書くのは] 僕にとっては定期ポストみたいなものです。年に一,二度はこのことを言っておきたい、みたいな。

と書きました。それから半年たってないのですが、なんかまたフローチャート・ネタをやりたくなりましたね。

そう思い立ったのは； 「フローチャートを復権させよう -- 2020年代のプログラミングへ」のブックマークに、羽生章洋(id:habuakihiro)さんが次のコメントを残しておりまして、

昔フローチャートについて講演したりポジティブなことを書いたりしたら偉い叩かれたなあ。似たケースにJavaScriptの記事書いたときも叩かれてその後gmail+ajaxブームが来たら一転したり。みんな原理原則より流行が好き。

いまさらながら当時の情報を探して読んでみたのですよ。2006年夏、羽生さんの講演について大森敏行記者が書いた記事が残っています。

羽生さんご自身のプレゼンテーション資料は：

羽生さんのご意見があまりも的確なので感服し、それに対する揶揄や中傷があまりも的外れなのでホトホト呆れました*1。

内容：

これは長い記事です。フローチャートをめぐるナゲカワシイ現状を知りたいなら、後半の3つの節「s/フローチャート/letrec付きラムダ式/ としてみると」「権威とか風説とか」「表層にとらわれない」を読めばいいと思います。

「フローチャート」という言葉の問題

フローチャートについて語ると、妙に感情的な（そして、たいていは非論理的な）反応やトンチンカンな議論に出会うのですが、「フローチャート」って言葉で想定しているモノが食い違っていることが、齟齬の原因のひとつとなっているでしょう。

ある人々は、「フローチャート」の意味を限定するために、JIS規格（JIS X 0121:1986）により定義される図式を「フローチャート」と呼んでいるようです。これは、定義がハッキリする点は良いのですが、世の中、「フローチャート ＝ JIS X 0121:1986」で合意しているとは思えません。例えば、「フローチャート」というキーワーでgoogle検索してみると、次のような図が引っかかります。

http://parashuto.com/rriver/development/mixi-connect-oauth-flow より：

http://minnano-seo.com/essence/post90/より：

多くの人は、箱や矢印を使った図をなんとなく「フローチャート」と呼んでいるでしょうし、僕の感覚でも、箱や矢印を使う図は「フローチャート」です、JIS規格は知りません。「JISの定義に外れる図式はフローチャートとは呼ばない」というのは狭量に過ぎるし現実的じゃないでしょう。

とはいえ、だいたいの目安は必要です。この目安に適切なのが羽生さんの次の提案です。

使う記号は，「開始」と「終了」を示す記号（端子），長方形の「処理」，ひし形の「分岐」，左辺と右辺が2重線になった長方形で表す「定義済み処理（モジュール）」，それに「矢印」に限定する。


僕は、もっと簡略化して箱と矢印だけでもいいと思っています。箱、矢印にラベルを付けますけどね。boxes and wires diagram なんて呼ばれることもありますし、圏論界隈ではストリング図（string diagram）と呼ぶことも多いです*2。僕のこのダイアリー内で説明用に出てくる絵図は（たいてい）ストリング図です。

すぐ下の絵は、白旗優（しらはた・まさる）さんの論文 "Geometry of Interaction explained" (http://repository.kulib.kyoto-u.ac.jp/dspace/bitstream/2433/43041/1/1318_19.pdf) からの引用です。これだってフローチャートでしょう。

プログラムの図示だと、箱以外に、菱形で表される条件分岐が欲しくなるのは事実です。だけど、if p then A else B は扱いにくい面もあるんで、ガード付きの式／文である p then A を基本に据えるほうがいいと思います。両者の関係は次のようになります。

  • (if p then A else B) ≡ (p then A | !p then B)

ここで縦棒「|」は並列（非決定性）実行のつもりです。「テスト付きクリーネ代数とその使い方」の記号法だと、p・A + (¬p)・B です。ガード条件の図形は、菱形の半分で三角がいいじゃないかな？ p・A = (＜p|→[A]) みたいな。まー、なんでもいいですけど。

フローチャートはもちろん万能じゃない

今述べたように、箱と矢印、それとガード条件くらいで構成された図をフローチャートと呼ぶことにしましょう（ゆるい定義）。このゆるい定義を受け入れられない、JISのアレしか認めん! とかなら、ここから先の僕の議論を読んでもしょうがないです。厳密にJISベースなら、僕の言っている事のほうがたぶんトンチンカンでしょう -- JISベースの発言をゆるい定義で再解釈してしまうことがありそうですから。

で、フローチャートに欠点があるのは事実です。例えば、手描きならともかく、コンピュータ上のツール（それが仮にあったとして）で入力しようとすると、手間がかかりすぎてまったく実用的じゃないですよね。他にも問題点はあるでしょう。

だけどね、「フローチャートは万能だ」とか「テキスト記述をフローチャート（図式表現）で完全に置き換えるべきだ」とか誰か主張してますか？*3 羽生さんは言ってないし、僕も言わないよ！ ダーレも言ってない架空の主張に対して、「フローチャートではアレが出来ない／コレが出来ない」とあげつらって「テキスト記述を完全に置き換えることはできない」（それ自明）と主張してみて、いったいなにがうれしいの？

実際のところ、「アレが出来ない／コレが出来ない」と言っている部分に対してけっこう反論はできるんだけど、そこは本質じゃないしメンドクサイからいいや。で、本質的な部分ですが： 羽生さんの講演タイトルは「仕事で必要なことはフローチャートで学んだ」ですから、学べることが眼目でしょ。「抽象化能力を極限まで高めるにはフローチャート程度がちょうど良い」ともおっしゃっているので、学習やトレーニング、思考の道具、特に抽象化能力の育成に良いということ*4。

ですから、羽生さんの意見・主張に反論するなら、「フローチャートは、学習／トレーニング／思考／抽象化などにサッパリ役に立たない」と言わなきゃダメでしょ。そうじゃないと、単にアサッテのほうを向いて関係ない事わめいているだけでしょ。

苦い経験？

んじゃ、なんで「関係ない事」をわめいてしまうのか？ ホントのところは分かりませんが、「フローチャート」がなにか苦い経験を想起させるような言葉なのかもしれません。例えば、

  1. 現場の開発工程のなかでフローチャート作成を義務付けられた。
  2. プログラムコード（テキスト記述）と同じ内容を重複して無駄に書かされた。
  3. 他人が描いた図を見ても、制御とデータの流れがゴチャゴチャでワケワカんなかった。
  4. 図をキレイにレイアウトしないと文句を付けられた。

もし、そんなことが実際にあったのなら、強い反感を抱くかもしれません。しかしそれは、フローチャートが学習や思考の道具として有効かどうかの議論とは別でしょう。

関数型言語では、フローチャートは書けない ?!

表記の見出しのようなことを真顔で言う（って、顔見てないけど）人がいるのですねー。ほんとに驚きです。ちょっと、誰か、どういうことか説明してくんないかなー。ひょっとして、例のJIS規格にそう書いてあるの？

もう一度繰り返すと、僕の言葉使いでは、箱と矢印で構成された図をフローチャートと呼んでいるわけですが、その描画方式を使って関数型言語の意味的モデルが描けないってこと？ それは不可解過ぎる！

そんなことを言う人は「関数型言語」が得意だったり好きだったりするのでしょうから、お聞きしたいわけですが、再帰的な定義を可能とするletrecを持ったラムダ式がありますよね、仮にletrec付きラムダ式と呼びますが、そのletrec付きラムダ式は関数型言語と無縁だったり、関数型言語としての記述能力が無いと思いますか？ もちろん、実用的プログラミング言語としてじゃなくて、学習や思考の道具、あるいは理論上の枠組みとして、です。

「これはひどい誤解だ -- フローチャートは手続き型…だってぇー?!」でも言ったことの繰り返しですが、箱と矢印で構成された図（＝フローチャート＝ストリング図）とletrec付きラムダ式は同値ですよ。

長谷川真人（はせがわ・まさひと）さんの素晴らしい論文や解説を読んでもらうのが一番だと思うので、URLを再掲します。

以下の図は、長谷川さんのスライドからの引用で、letrec式とフローチャート（ストリング図）の対応の例です。

再帰的定義の意味は、不動点で与えられます。モノイド積がデカルト積である対称モノイド圏では、不動点の存在とトレースの存在が同じことになります。そしてトレースは、図ではフィードバックサイクルになります。このことを厳密に示したのは長谷川さんご自身です。檜山による稚拙な解説なら：

羽生さんの講演で示されている典型的な次のフローチャート、これのフィードバックサイクル（繰り返しのために戻る線）はトレースです*5。

この図は（他のフローチャートも）トレース付きモノイド圏で解釈できます。ということは（直積-直和の双対で移りあうのを許して）、letrec付きラムダ式としても表現できます。逆も真で、letrec付きラムダ式はトレース付きモノイド圏の射としての解釈を持つので、フローチャートで図示できます。図と式の確実な対応の存在は、確かアラン・ジェフリー（Alan Jeffrey）が厳密な証明を与えていたと思います。

アラン・ジェフリーといえば、彼が描いた hello world の絵はこれ。

"Premonoidal categories and a graphical view of programs", http://fpl.cs.depaul.edu/ajeffrey/papers/premonA.pdf からの引用です。

s/フローチャート/letrec付きラムダ式/ としてみると

「フローチャート」という言葉が、今僕が使用している意味「箱と矢印で構成された図」と根本的に違うなら、議論が噛み合わないのは当然です。が、「箱と矢印で構成された図」から遠く離れた意味じゃないだろう、という想定で解釈すると、なんかもー、とんでもない事言ってる人がいるわけですよ。出典は特に明記しませんが。（[…]は檜山による補足文面）

  1. フローチャートがまともに記述できるのは「手続き」だけだ
  2. フローチャートで書くのが困難なのは、OOPだけではない。関数型はもっとそう
  3. フローチャートは、関数型を排除した手続き型パラダイム限定で[しか適用できない]。
  4. フローチャートのどこが抽象化なのかと。
  5. 並列処理とかでなければ、フローチャートは設計した結果を記述するのには使える*6。
  6. 高級言語でプログラミングするのに、フローチャートは害の方が大きいと思う。

フローチャートとletrec付きラムダ式は、かたや絵図表現、かたや記号表現ですが、同値な存在ですから、言葉を置き換えてみましょう。

  1. letrec付きラムダ式がまともに記述できるのは「手続き」だけだ
  2. letrec付きラムダ式で書くのが困難なのは、OOPだけではない。関数型はもっとそう
  3. letrec付きラムダ式は、関数型を排除した手続き型パラダイム限定で[しか適用できない]。
  4. letrec付きラムダ式のどこが抽象化なのかと。
  5. 並列処理とかでなければ、letrec付きラムダ式は設計した結果を記述するのには使える。
  6. 高級言語でプログラミングするのに、letrec付きラムダ式は害の方が大きいと思う。

こうしてみれば、いかにバカバカしい言明かが分かるでしょ。

ちょっと悪乗りなのは承知で：

  1. トレース付きモノイド圏がまともに記述できるのは「手続き」だけだ
  2. トレース付きモノイド圏で書くのが困難なのは、OOPだけではない。関数型はもっとそう
  3. トレース付きモノイド圏は、関数型を排除した手続き型パラダイム限定で[しか適用できない]。
  4. トレース付きモノイド圏のどこが抽象化なのかと。
  5. 並列処理とかでなければ、トレース付きモノイド圏は設計した結果を記述するのには使える。
  6. 高級言語でプログラミングするのに、トレース付きモノイド圏は害の方が大きいと思う。

「フローチャート（箱と矢印で構成された図）が関数型言語を記述する表現力がない」というのは誤謬、無知なのか勘違いしてるかですよ。箱と矢印で構成された図に対する意味論として、適切な意味領域（例えばトレース付きモノイド圏）と意味割り当てを採用してないだけなんです。わかりますか？ -- 絵や記号に意味を割り当ててない状態で、「意味が無い／出来ない」と言っているのです。ソリャソーだわ。

権威とか風説とか

「フローチャートはダメだけど、データフローダイアグラムやUMLのナントカ図ならいいんだ」とかノタマッテイル人もいて、何を言いたいのか僕にはサッパリわかりません。僕のように大雑把な言葉使いじゃなくて、フローチャートとデータフローダイアグラムの厳密な（しかも著しく異なった）定義をお持ちかも知れませんけど。

一度悪い評判で汚染された言葉を使い続けるのはヤッパリ難しいのでしょうね。「フローチャートを復権させよう -- 2020年代のプログラミングへ」より：

フローチャートの別名はやたらにあります。アクティビティ図（activity diagram）もその1つです。もう少し広義だとステートチャート図（statechart diagram）と呼ぶんだそうです。2009年に書いた記事「フローチャートからマゾ・テストまで」のなかで言及した名称には、フローダイアグラム（flow diagram）、フローグラフ（flowgraph）、フローノミアル（flownomial）、ネットワーク（network）などがあります。

そんなに別名を作ってどうすんだよ!? と思います。

別名を付けるのは、悪い先入観や変な誤解を避けるためだったのかも知れません。「UMLはモダンで役に立つけど、フローチャートなんて前世紀の遺物はダメ」とか何の根拠もなく言う人、いかにもいそうだものね。

フローチャートの研究者であるステファネスク師匠も、ひょっとしてそんな悩みがあったのかも知れません（単に想像）。UMLに対して、ステファネスク達が次のような同値変形を伴う図式法*7を提案したことがあります（経緯の詳細は知らないです）。

唾棄すべきモノとして扱っていた同じ図式も、UMLの冠が付くとアリガタガッタリする人がいるんでしょうね*8。

表層にとらわれない

さてと、長谷川さんの論説にベッタリと依拠して、またも引用しますが：



長谷川さんの真意を僕は取り違えている懸念もありますが、ソースコードの字面のレベルでしかプログラムの意味を理解しないなら、計算現象の本質には届かないよ、とも読み取れます。フローチャートが万能とは言いませんが、絵図表現が記号表現を補完してくれるのは確かだと思いますよ。

*1:羽生さん講演とは無関係なフローチャート批判も検索で引っかかったので、これも含めて呆れたのですがね。

*2:狭義のストリング図は、自然変換、関手、圏の矢印記法をポアンカレ双対で次元をひっくり返して描いたものです。射と対象の次元をひっくり返すと、射＝box＝point＝0次元、対象＝wire＝1次元となります。

*3:フローチャートを計算デバイスと考えて、計算的に万能（universal）にするのは容易ですがね :-)

*4:「開発の現場で、フローチャートが直接的に実務に役に立つ」という言い方は良くないと思います。反感と誤解を招くだけ。

*5:直積じゃなくて直和をモノイド積と考えたときのトレース、エルゴット・ダガーです。

*6:「並列処理とかでなければ」が笑いどころ。並列処理とフローチャートについては、いずれ述べるつもりです。

*7:これって、トレース付きモノイド圏の公理そのものです。

*8:アクティビティ図はフローチャートのことなので、既にUMLに入っているとも言えます。