2026年4月15日水曜日

📈10年後にif文は消滅する？

 かつてgoto文という命令が隆盛していたが、70年代から衰退しはじめた

「構造化プログラミング」を提唱していたコンピュータ科学者らの一人であったダイクストラは、1968年にGo To Statement Considered Harmful（「Go To 文は有害（Harmful）とみなされる」）という刺激的な記事を国際学会ACMの学会誌Communications of the ACMに投稿し（ただし、本人が付けたタイトルはA Case Against the Goto Statementという穏便なもので、少なくともタイトルの過激さと、レターとして発表を急いだことは、編集を担当していたヴィルトによるものである）

「goto文、いかがなものか」と言われ始めたのは６８年で、ダイクストラのせいではないだろうが今goto文について意識する人は少なくなっていると思う。いまやgotoを使うためにはラベルが必要になっている。

ダイクストラが有名だが、その前に物申した人もいたようだ。

1959 年に開催されたpre-Algolの会議で、ハインツ・ゼマネクは GOTO文の必要性について明確に疑念を投げかけたが、後に GOTO の象徴的な反対者となったエドガー・W・ダイクストラを含め、当時は誰も彼の発言に注意を払わなかった。

ALGOLはgotoが不要そうなしくみになっていそう。ここまでコンテンポラリーだとなぜ廃れたかの方が気になる。

https://www.tutorialspoint.com/execute_algol_online.php

ALGOLはこちらで試運転できる。コードはrosetta codeでいくつか読んでみよう。

PROC gcd = (INT a, b) INT: (
 IF a = 0 THEN
   b
 ELIF b = 0 THEN
   a
 ELIF a > b  THEN
   gcd(b, a MOD b)
 ELSE
   gcd(a, b MOD a)
 FI     
);
test:(
 INT a = 33, b = 77;
 printf(($x"The gcd of"g" and "g" is "gl$,a,b,gcd(a,b)));
 INT c = 49865, d = 69811;
 printf(($x"The gcd of"g" and "g" is "gl$,c,d,gcd(c,d)))
)

ALGOL68でGCD（最大公約数）を求めるサンプルだが、wikipediaの説明通り、再帰を使っている風な感じがかいまみえる。PROCというキーワードがプロシージャー（命令のまとまり）の宣言に違いない。

６０年代に構造化のブームがあった

原爆が広島に落ちてナチの時代が終わり、冷戦をむかえながら、ベトナム戦争の時代に突入するときに、哲学では実存が叫ばれたあとに構造主義のブームがあった。Structuralismというブームは哲学にもあって、プログラムもALGOLを皮切りにStructuredというブームが起こった。ここでgoto文は実存主義みたいなものだ。

構造主義が台頭しはじめると、次第にサルトルの実存主義は「主体偏重の思想である」として批判の対象になる。とりわけクロード・レヴィ＝ストロースが、1962年の『野生の思考』の最終章「歴史と弁証法」において行ったサルトル批判は痛烈なものであった。

スパゲティプログラム

サルトルがどれぐらい混乱を招くかわからないが、gotoはスパゲティプログラムを引き起こすと一般には知られている。(要出典）

Linuxの生みの親リーナス先生の冒頭にもgoto文が出てきた。無限ループの世界へようこそ。

関数型の隆盛

関数型は古くからあるが、マシンスペックの向上によりだいぶ普及してきた。オブザーバーを代表するMVCなどのデザインパターンがかつてのFORTRANやCOBOLになりつつあるのかもしれない。。。


Goto文の衰退の整理

  1. プログラムの可読性の低下:

    • Goto文は、プログラムのフローを追跡するのが難しく、可読性を著しく低下させます。コードがスパゲッティ化し、バグの発見や修正が困難になります。

  2. 構造化プログラミングの台頭:

    • 1970年代にエドガー・ダイクストラが「Goto文の使用は有害である」と述べ、構造化プログラミングが広まりました。このプログラミングパラダイムは、ループや条件分岐などの制御構造を使うことで、コードの明瞭性と保守性を向上させました。

  3. 言語の進化:

    • 近代的なプログラミング言語（例：C、Java、Pythonなど）は、Goto文を使用せずに制御フローを管理するための高度な構造を提供しています。これにより、Goto文の必要性が減少しました。

  4. メンテナンスの容易さ:

    • Goto文を避けることで、コードのメンテナンスが容易になり、プログラムの品質が向上します。特に大規模なプロジェクトでは、構造化されたコードがチームでの協力作業を円滑にします。

if文の衰退シナリオ

  1. 関数型プログラミングの普及:

    • 関数型プログラミングでは、if文の代わりにパターンマッチングや高階関数を使用することが推奨されます。これにより、コードの明確さと予測可能性が向上します。

  2. 代替構造の採用:

    • 三項演算子（条件演算子）やスイッチ文、さらにはマッチング構文（例：RustやScalaのmatch文）など、if文の代替となる制御構造が広まりつつあります。

  3. デザインパターンの活用:

    • 状態パターンやストラテジーパターンなどのデザインパターンを使用することで、条件分岐をオブジェクト指向的に処理することが可能になります。これにより、if文を減らし、コードの保守性を向上させることができます。

  4. ドメイン特化言語（DSL）の利用:

    • 特定のタスクやドメインに特化したDSLでは、条件分岐を簡潔に表現できる構文が用意されていることが多く、if文の使用が不要になる場合があります。

まとめ

Goto文の衰退は、プログラムの可読性と保守性を重視する構造化プログラミングの普及によるものであり、言語の進化によってもたらされました。一方、if文の衰退シナリオは、関数型プログラミングの普及や代替構造の採用、デザインパターンの活用などによって進行する可能性があります。これらの進化は、より明確で保守しやすいコードを作成するためのものです。



投稿者