  |
はてなキーワード: 再帰呼び出しとは
Steamで買った『Recursed』というゲームを全ステージクリアしたので、記念に感想を書く。
Steam：Recursed
https://store.steampowered.com/app/497780/Recursed/?l=japanese
一見すると『Recursed』は2Dのレトロな雰囲気のアクションゲームである。操作はシンプルで、方向キーで左右に移動し、アクションはジャンプと物をつかむ/投げるだけだからだ。部屋の中を移動してブロックをつかんで足場を作ったり、鍵をつかんで扉を開錠したりしてゴールへと到着（crystalを獲得）すればステージクリアだ。
ステージの始めはチュートリアルの様に簡単だが、ステージを経るごとに難しくなり、そのうち何度も試行錯誤したり難しさのあまり何十分も頭を抱えたりもした。
この複雑さを生み出す要因は箱(ゲーム中表記ではChest)である。このゲームでは箱の中へジャンプすることで部屋の内に入れるが、一度箱の外にでると箱の内部状態はリセットされてしまうのだ。よって箱の中にブロックや鍵などのオブジェクトを持ち込んでも保存することはできないし、ブロックの位置もリセットされるし、開錠した扉もまた施錠されてしまうことになる。
さらに大きな特徴として、箱を持ち歩いて移動することができるのだ。それにより、箱を持ったまま別の箱に入ったり箱を持って箱の外にでることもできる。
そして、ステージを経ると箱の中の部屋は箱の外と同じ部屋という場面に出くわす。Recursedは『再帰呼び出し』という意味らしいが、まさにこのゲームのタイトル通りの現象が起こるのだ。そして、以降のステージでは再帰を交えることでパズルの複雑さはより深まっていく。
再帰は数学的帰納法やアルゴリズムでは定番の概念だが、それがパズルとなってプレイヤーの思考回路を奪ってくる。私はかつて社畜プログラマとしてJavaプログラミングを経験していたので、箱に入ることはメソッドを呼び出すことの様に感じた。オブジェクトを持って箱に入ることは引数を使ってメソッドを実行することであり、オブジェクトを持って箱の外に出ることはreturn文でメソッドを終わらせることであった。
「ゴール前の段差が大きくブロックが必要だから、ブロック生成メソッドを呼び出してブロックオブジェクトを返り値として渡さなくてはいけないけど、そうすると鍵オブジェクトをゴールメソッドの引数として渡すことができなくて……、いっそのこと、ブロックメソッド内からゴールメソッドを呼び出すべきか……、メソッドの返り値は一つだけだが何度も呼び出せばいけるか？ この緑色のオーラはなんだ？ Staticを意味するのか？ Staticなオブジェクトの位置情報をあらかじめ変更しておけば、ゴールメソッドで引数渡しをする必要がなくなるのか？」
こんなことを一つのステージをクリアするだけのために何十分も考えていたのだ。念のために書いておくが、ゲーム内には数学用語やプログラミング用語は一切出てこない。ただ単に、私にJavaプログラミングの経験があるからその用語でパズルを考えていただけだ。ゲーム内で箱から出入りしたりオブジェクトを箱の中から出し入れするとどうなるかを、Eclipseでステップ実行するように想起していた。ちなみに、ゲーム内で存在しない部屋や壁の中に移動しようとするとparadoxが発生して強制的に特殊な部屋へ移動されるが、私はその度にステップ実行でExceptionに遷移されたことの様に感じた。他の言語に精通するプログラマだったり数学畑の人ならば、私とは異なる概念でパズルを思考をするのだろうか。
プログラマを辞めて何年もプログラミング的思考をしてこなかった私でも全ステージクリアすることができたのだから、学校でプログラムを学んでいたり現役でプログラミングをしてきた人ならばこのゲーム『Recursed』をクリアすることは可能だろう。いっそのこと、『Recursed』のクリアすらできない人にプログラミングができるのか？ と煽ってみたいくらいだ。
ちなみに、もし私が社畜プログラマ時代にこのゲームをやったらブチ切れていただろう。なんで仕事でプログラミングで脳を酷使した上に自宅のゲームでも同じようなプログラム的な思考をしなければならないんだよと。プログラミングから何年も離れていた今の私にとって『Recursed』は、プログラミングや単体テストが無事成功した時の快楽を思い出させるものだった。
『Recursed』はパズルとしての難易度は非常に高いが、理不尽な解法を求められることはない。理不尽な解法のクイズやパズルには怒りが湧いてくる。ひと昔前のクイズ番組を見たことのある人なら『モヤッとボール』を投げつけたくなる、と言えばその感情が伝わるだろう。『Recursed』はどんなに難しいステージでも、ただただ開発者のパズル作成能力に感嘆するだけで怒りは湧いてこない。
似たようなアクション風パズルゲームとして有名なのは『The Witness』であろう。『The Witness』も私が好きなパズルゲームであり、ゲームとして高い評価を得ていることに間違いはないのだが、しばしば理不尽な解法を求められるパズルがありその度に私は怒りが湧いてきたものだ。そう考えると、『Recursed』はパズルとしての洗練さだけなら『The Witness』を超えるものだと私は思う。
具体的にパズルを解説するととただのネタバレになってしまうので（もっとも、文字だけでパズルの解法を説明できないのだが）、『Recursed』で私が好きなステージを述べる。順番は攻略順に並べた。
チュートリアルの様に簡単だったこれまでのステージから突如再帰の概念を見せつけられることで、このゲームのタイトル名の意味を理解することになった。
鍵を手に入れたら扉に到達できず、先に扉に到達したら鍵が手に入らずで、まさにインターロックの名前に相応しいステージだった。
一画面だけのオブジェクトが少ないシンプルなステージだが、氷の壁に阻まれてゴールできず苦戦した。試行錯誤の繰り返しの末クリアできたが、何故クリアできたのかがわからない。
The Voidのステージはどれもこれまでの集大成という感じでやりごたえあったが、中でも頭をひねらせたのがこれ。ゴールの部屋を水没させたり水の無い状態で入ったりして鍵を運搬するのに苦労した。
箱を左右へ投げて移動を繰り返して、高い位置にあるゴールを目指すのがまさにEscalateというステージ名そのものだった。paradoxを発生した後のパターンが複雑だったのが印象に残っている。paradoxを発生させたらcrystal獲得（通常のクリア）できないのかよ……という落胆は大きかった。しかし、それだけにcrystal獲得とdiamond獲得（paradox発生によるクリア）のどちらも大きな達成感を得られた。
簡単そうに見えて難しく、唯一ステージを飛ばして次のステージへと進んだので印象に残っている。後に複数日に及ぶ数時間の試行錯誤で改めてこのステージをクリアができて、クリアにかかった時間が最も長くなったステージでもある。しかしながら、おそらく開発者の想定外の方法でのクリアであり。初期画面から右の方へ一切行かずにOobleckさえ使用しないというクリア方法にスッキリしなかった。といっても、開発者の想定を無視するゴリ押し的なクリアを見つけたのはこのステージだけだった。
The Void/Escalateと似たコンセプトのステージだが、釜（JavaにおけるThread？）のギミックを利用したより複雑な構成となっている。高い位置にあるゴールを目指すのは、やはりFlightというステージ名そのものだった。
この記事を投稿する前にエンディングを見れていないことに気づいた。
全ステージクリア（全てのCrystal取得）したからと、この記事を執筆するためにネタバレを気にせず攻略情報を調べていたけど、エンディングなんてわかる訳ねえよ。The Void/Trilemmaの最後にCrystal取得とは関係ない意味深なオブジェクトがあることには気づいていたけど……。ちなみに、私のSteam実績によるとdiamondとrubieの全取得はできてないけれども、もう取得する気力はない。パズルゲームガチ勢にとっては、実績全解除を目指さない私は軟弱者に映るのだろうか？ 攻略を調べずに実績全解除できる人は、高い論理的思考能力を有しているに違いない。
てほしい。
プログラミングを理解できない人はいます。いい加減この事実を認めて下さい。
こういう話になると、やれ「教え方が悪い」だとか、やれ「順序立てて学べば誰でも理解できる」などという輩が出てきますが、それは事実に反します。
まず、プログラミングは手順さえ覚えれば誰でもできるようになると言うものではありません。プログラミングを理解するには、一定レベルの論理的思考能力を要します。それが身に付いていない人には無理です。また、どんなレベルの人でも、プログラミングで分からないことは出てきます。プログラミングができる人は、そういう時に、
といったことをして解決する力があります。そういう試行錯誤をしない人や、複雑だったり抽象的な概念を突き詰めて考えることをしない人に、プログラミングを理解するのは不可能です。
たとえば、再帰関数が分からないとしましょう。具体的に何が分からないのかは人によって異なります。たとえば、
など。これらを解決するには、自分で仕組みを突き詰めて考えたり、コードを書いてデバッグしてみたり、調べたり人に聴いたりするしかありません。講師が気の聞いた喩え話などをすれば、たちまち疑問が氷解するなどということはあり得ません。
また、一口に「プログラミングを理解する」と言っても、そのレベルは様々です。
最初の2〜3程度が「自分の思うプログラミングの全て」な人が、軽々しく「プログラミングは誰でも理解できる」などと思わないでいただきたいのです。それは実用上は全然足りていません。サンプルコードをググりながら、やっとこさVBAで複数のエクセルファイルを集計できる程度の人が「プログラミングできる」気になっていては困るのです。
上記の大部分は、自分のプログラムを他人に見せるつもりのある人なら十分に習得しておく必要があります。ましてや、プログラミングで飯食おうと言う人間が、FizzBuzzに毛の生えたようなコードを読み書きするのに精一杯で、効率や保守性に気を配れないのは論外です。
上記の特に後半に書いたようなことは、誰にでもできることではありません。ちょっとしたコツや方針を守れば機械的にこなせるというものではなく、技術力の高い人でも熟考を要することです。彼らは、そうした高度なことを正しく考える力があるから、技術力が高いのです。そういう力は、誰かに用意してもらったカリキュラムを受動的にこなすだけではまず身に付きません。
こんにちは、シャイニング増田(シャイ増)です♥町中で良くリクルートスーツの就活生を見るようになりましたね。先日後輩の紹介で○○大学の学生からグーグルに入りたいという相談を受け渋い気持ちになりました。○○大学ではTopCoderのRed Coder相当の実績でも残していないと入れないでしょうし、ネームバリューだけでなんとなく「ビッグデータ♡」「人工知能♡」と言っている様は山師スタートアップの「フィンテック事業部を新設しました」のIRと同等クラスの浅ましさです。そこで若者に捧ぐ私が考えるプログラマのキャリア論を参考にしていただければと思います。
http://www.shiningmaru.com/entry/2016/04/29/212824
を見て、あんまりプログラマがどうやって高給取りになれるかというキャリアの話って見たこと無いな、と思ったので書いてみます。
全てのプログラマが給料を一杯稼ぐことを目指すべきだとは思いませんが、私のように、研究職でもなく、マネージャー職でもなく、コード書いてお金が貰えるならなんでも書くよ、という節操のないプログラマ志望の大学生にはとてもおすすめの高給取りになるための方法です。
まずは目標である高給取りになるにはどうすればいいか考えてみましょう。どんな能力があれば年収1000万円もらえるの？と思われるかもしれませんが、そもそも残念ながら給与というのは純粋にあなたのスキルによって上下する余地はあまりありません。
年収500万円のプログラマが頑張って仕事後も勉強会などへ行き、頑張ってスキルアップしても、会社が年収を1000万円にしてくれることはほぼ無いと考えてください。年収500万円のプログラマと年収1000万円のプログラマの一番大きな違いは職場です。大抵の会社はどんなに優秀なプログラマでも給料で大金を払うことはできません。
身も蓋もないんですが、高給取りになりたいと思ったら、自分磨きなんて糞くらえで、自分に給料を一杯払ってくれる会社を見つけて入社するのが一番重要です。
金回りがいい会社が一番です。どういうところがいいの？というと、ざっくり２つのグループにわかれると思います。
1. 世界的にシェアのあるサービス・プロダクトを持っている会社
1の典型的な企業は、ベイエリアとかにある、世界向けのプロダクトを持っていて、競争力のある会社です。とても金回りがいいです。有名どころではGoogle、Facebook、Appleや若干株価が心もとないTwitterなんかがあります。何故これらの会社がプログラマに大金を払い、何故日本の大抵の会社がプログラマに年収1000万円を払えないかについてはhttps://note.mu/whynotgetrich/n/nd71f86a3e0cbを御覧ください。
2はあまりプログラマの人は縁がなく、存在すら知らない会社が多いのではないでしょうか？とても勿体無いですね。例えば金融系の企業はとても金回りがよく、社内システムの開発でもその恩恵を受けることができます。例えば外資金融系ではGoldman Sachs、Merrill Lynchは給与がよく、保険系では東京海上とかもまったりと年収1000万越えるらしいんで、狙うといいんじゃないですかね。あまり詳しくないので、具体的な業務内容はインドに発注と管理するプログラマというよりはSEなのかもしれないですけど。
では他のドメスティックなネット系企業はどうなの？というと、残念ながらあまりいい話は聞きません。
数年前に年収1000万円で新卒を採用(http://news.livedoor.com/article/detail/5997716/)、みたいな話が数社から出てきて、ようやく日本でも人材獲得競争が激しくなってきたな！と思いましたが、どうなったんですかね？全然うまくいかなかったからもうやっていない、という話を聞きましたが、実際どうなのか現場の話を聞いてみたいものです。
私が最近聞いた中ではLineは年収1000万円を軽く越えるオファーを出していて、他のインセンティブもついてたら、上場したあかつきには軽く2-3000万円はいくんじゃないかと思われます。Lineくらいになってくると、1のグループに入ってる感じですね。景気いいですね。うらやましいです。
そんな会社全部よくわからないよ！無理だよ！私が志望しているこれらの会社の中からだったらどれ選べばいいの？と思ったら技術部門の最高責任者っぽい人とかの給与を調べましょう。それより多くは絶対にもらえません。あとは平均給与を調べてみましょう。プログラマは社内の中でも特に多く給料が貰える職であることは少ないと思われるので、平均給与が1000万円越えてなければ、プログラマとしてキャリアを積んで1000万円の大台に達することは難しいかもしれません。
と、1000万円を稼げる企業がおわかりいただけたかと思いますので、次にこれらの企業に入社するにはどうすればいいかについて考えてみましょう。
まず先に2のグループの企業についてですが、私は全く明るくないので、どんな採用プロセスなのか全然わかりません。とりあえず英語憶えてたほうが外資系が選択肢に入ってくるのでいいんじゃないですかね？
次に1ですが、こちらもやはり英語がわかると、海外での勤務が選択肢に入ってくるので同じくおすすめです。新卒で日本法人に入る場合は、企業によってはちゃんと英語習得のためにフォローが入るので、技術力優先だったりもします。
ここまできてようやく技術の話が来ましたが、具体的に何ができればいいの？というと、まずポインタと再帰呼び出しを理解できるか調べてみましょう。
Joel先生が書いてますが、ポインタと再帰呼び出しはどんだけ優秀なプログラマでも何故か書けなかったりするので(http://local.joelonsoftware.com/wiki/Java%E3%82%B9%E3%82%AF%E3%83%BC%E3%83%AB%E3%81%AE%E5%8D%B1%E9%99%BA)、まずこれらをちゃんと理解してるか見てみましょう。私も世界中の100を越えるプログラマの面接を行ってきましたが、再帰呼び出しを書かせようとすると絶望するプログラマはとても多いです。
ポインタは使う機会は大分減ったと思いますが、再帰呼び出しはまだ現役なので、理解できなくて、プログラマになりたいわけではなく、ただ高給取りになりたいのであれば、別のキャリアを目指した方が楽かもしれません。
採用において重要なのは、履歴書の実績と面接での技術力です。ベイエリアなどの企業のプログラマの採用面接では、「あなた自身を動物に例えると何ですか」みたいな質問を聞いてくることはありません。技術的な質問、又はコードを書かせる問題を出してきます。Top Coderのような競技プログラミングと似てるので、練習しておくことをおすすめします。各種データ構造とアルゴリズムの計算量を憶え、うまく適用できるよう勉強しましょう。
面接官によってはコンピュータ・ネットワークの仕組みについて聞いてきたりするので、ヘネパタ、オペレーティングシステム、詳解TCP/IPあたりは読んどくといいかもしれません。後々色々な技術を学ぶ時に理解が深まりやすいので、どちらにせよ読んでおいて損はないです。
面接対策だけでなく、プログラムはよほど専門的な内容でなければ、レファレンス引きながら問題なく実装できる、というレベルには達しておきましょう。履歴書に華を添えるなら、オープンソースプロジェクトに参加するかソフトウェアやサービスを公開してみてください。githubのアカウント名やプロダクト名、サービスの概要とURLを書いておけばあなたの技術力がより上手く伝わるはずです。
外資だと必要になる英語ですが、技術的な話がを中心であれば、一般会話より必要なボキャブラリが限られており、習得は思われているほど難しくはありません。かつ、メールのテキストベースでのやりとりが中心であれば、最初のうちは大変ですが、ゆっくり時間かけることもできます。
あなたの技術力が認められ、年収1000万円はないかもしれませんが、結構な高給取りになれました。おめでとうございます！さてここから昇給するにはどうすればいいのでしょうか？
第1章 並行プログラミングとGHC (上田和紀) 1.1 はじめに 1.2 ターゲットを明確にしよう 1.3 はじめが大切 1.4 GHCが与える並行計算の枠組み 1.4.1 GHCにおける計算とは，外界との情報のやりとり(通信)である 1.4.2 計算を行う主体は，互いに，および外界と通信し合うプロセスの集まりである 1.4.3 プロセスは，停止するとは限らない 1.4.4 プロセスは，開いた系(open system)をモデル化する 1.4.5 情報とは変数と値との結付き(結合)のことである 1.4.6 プロセスは，結合の観測と生成を行う 1.4.7 プロセスは，書換え規則を用いて定義する 1.4.8 通信は，プロセス間の共有変数を用いて行う 1.4.9 外貨も，プロセスとしてモデル化される 1.4.10 通信は，非同期的である 1.4.11 プロセスのふるまいは，非決定的でありうる 1.5 もう少し具体的なパラダイム 1.5.1 ストリームと双方向通信 1.5.2 履歴のあるオブジェクトの表現 1.5.3 データ駆動計算と要求駆動計算 1.5.4 モジュラリティと差分プログラミング 1.5.5 プロセスによるデータ表現 1.6 歴史的背景と文献案内 1.7 並行プログラミングと効率 1.8 まとめ 第2章 様相論理とテンポラル・プログラミング (桜川貴司) 2.1 はじめに 2.2 様相論理 2.3 時制論理 2.4 多世界モデル 2.5 到達可能性と局所性 2.6 純論理プログラミングへ向けて 2.7 Temporal Prolog 2.8 RACCO 2.9 実現 2.10 まとめと参考文献案内 第3章 レコード・プログラミング (横田一正) 3.1 はじめに 3.2 レコードと述語の表現 3.3 レコード構造とφ-項 3.3.1 φ-項の定義 3.3.2 型の半順序と束 3.3.3 KBLとLOGIN 3.4 応用――データベースの視点から 3.4.1 演繹データベース 3.4.2 レコード・プログラミングとデータベース 3.4.3 いくつかの例 3.5 まとめ 3.6 文献案内 第4章 抽象データ型とOBJ2 (二木厚吉・中川 中) 4.1 はじめに 4.2 抽象データ型と代数型言語 4.2.1 抽象データ型 4.2.2 代数型言語 4.2.3 始代数 4.2.4 項代数 4.2.5 項書換えシステム 4.3 OBJ2 4.3.1 OBJ2の基本構造 4.3.2 モジュールの参照方法 4.3.3 混置関数記号 4.3.4 モジュールのパラメータ化 4.3.5 パラメータ化機構による高階関数の記述 4.3.6 順序ソート 4.3.7 属性つきパターンマッチング 4.3.8 評価戦略の指定 4.3.9 モジュール表現 4.4 おわりに 第5章 プログラム代数とFP (富樫 敦) 5.1 はじめに 5.2 プログラミング・システム FP 5.2.1 オブジェクト 5.2.2 基本関数 5.2.3 プログラム構成子 5.2.4 関数定義 5.2.5 FPのプログラミング・スタイル 5.3 プログラム代数 5.3.1 プログラム代数則 5.3.2 代数則の証明 5.3.3 代数則とプログラム 5.4 ラムダ計算の拡張 5.4.1 ラムダ式の拡張 5.4.2 拡張されたラムダ計算の簡約規則 5.4.3 そのほかのリスト操作用演算子 5.4.4 相互再帰的定義式 5.4.5 ストリーム(無限リスト)処理 5.5 FPプログラムの翻訳 5.5.1 オブジェクトの翻訳 5.5.2 基本関数の翻訳 5.5.3 プログラム構成子の翻訳 5.5.4 簡約規則を用いた代数則の検証 5.6 おわりに 第6章 カテゴリカル・プログラミング (横内寛文) 6.1 はじめに 6.2 値からモルフィズムへ 6.3 カテゴリカル・コンビネータ 6.3.1 ラムダ計算の意味論 6.3.2 モルフィズムによる意味論 6.3.3 カテゴリカル・コンビネータ理論CCL 6.4 関数型プログラミングへの応用 6.4.1 関数型プログラミング言語ML/O 6.4.2 CCLの拡張 6.4.3 CCLに基づいた処理系 6.4.4 公理系に基づいた最適化 6.5 まとめ 第7章 最大公約数――普遍代数，多項式イデアル，自動証明におけるユークリッドの互除法 (外山芳人) 7.1 はじめに 7.2 完備化アルゴリズム 7.2.1 グラス置換えパズル 7.2.2 リダクションシステム 7.2.3 完備なシステム 7.2.4 完備化 7.2.5 パズルの答 7.3 普遍代数における完備化アルゴリズム 7.3.1 群論の語の問題 7.3.2 群の公理の完備化 7.3.3 Knuth-Bendix完備化アルゴリズム 7.4 多項式イデアル理論における完備化アルゴリズム 7.4.1 ユークリッドの互除法 7.4.2 多項式イデアル 7.4.3 Buchbergerアルゴリズム 7.5 一階述語論理における完備化アルゴリズム 7.5.1 レゾリューション法 7.5.2 Hsiangのアイデア 7.6 おわりに 第8章 構成的プログラミング (林 晋) 8.1 構成的プログラミング？ 8.2 型付きラムダ計算 8.3 論理としての型付きラムダ計算 8.4 構成的プログラミングとは 8.5 構成的プログラミングにおける再帰呼び出し 8.6 おわりに：構成的プログラミングに未来はあるか？ 第9章 メタプログラミングとリフレクション (田中二郎) 9.1 はじめに 9.2 計算システム 9.2.1 因果結合システム 9.2.2 メタシステム 9.2.3 リフレクティブシステム 9.3 3-Lisp 9.4 リフレクティブタワー 9.5 GHCにおけるリフレクション 9.5.1 並列論理型言語GHC 9.5.2 GHCの言語仕様 9.5.3 GHCのメタインタプリタ 9.5.4 リフレクティブ述語のインプリメント 9.6 まとめ
口調が違うのでわかります。
より多くのものを表現できることを表現力が高いというと思うのですが。
今回の場合、再帰で表現できるのはループ処理だけですが、再帰には他の表現もあるため可読性の点でマイナスに働いてしまいます。
まぁ、それがシンプルでわかりやすい、ということですが。
それはそれとして、再帰呼び出しは「呼び出し」と言うぐらいで、関数呼び出しの一種ですね。
（今までそういう話は出てなかったですが、改めて合意します）
ここで出てきた。http://anond.hatelabo.jp/20081028222130
元エントリについている『大はずれだろ。どこが「名前の由来」やねん。』云々は別増田です
（って言っても増田だから説得力ないかもしれませんが）
さて、
より多くのものを表現できることを表現力が高いというと思うのですが。
ループの方がシンプルで判りやすいぞ、というのであれば（前にも書きましたが）人それぞれなので特に否定しません。
えーと、従前からの私の主張は「ループは再帰呼び出しの一種である」ということです。
それはそれとして、再帰呼び出しは「呼び出し」と言うぐらいで、関数呼び出しの一種ですね。
（今までそういう話は出てなかったですが、改めて合意します）
だからといって、再帰呼び出しの説明として、（再帰呼び出し以外のすべての関数呼び出しにも当てはまってしまうような）一般的な関数呼び出しを持ち出すのは範囲が広すぎると思いませんか。
というか、以下の言い方だと何でも再帰呼び出しになってしまいますよ。
再帰処理って処理を停止して新しい処理を行い、終了後に停止していた処理に戻ることじゃない？
すなわち、
A() { B(); }
ですら再帰呼び出しだということになってしまいますが、それはやっぱり説明として変でしょう？
別に怒っちゃいないよ。
再帰処理はループ以外の処理もできるけれど、ループはループしかしないからね。
何を今更。
最初のネタ扱いの書き方が失礼だったことは申し訳なかったですが、どうかカッカしないで欲しい...。
で、結局、何を「メリット」と考えるか、何を軸に「大小関係」を考えるのかがずれているのだと気づきました。
「forを再帰で代替するなんて、どういうメリットがあるの？」という大元増田の疑問に対して、「ループは再帰の一種なので、表現力としてはメリットもデメリットもありませんよ（大小関係はないですよ）」と申し上げましたつもりでした。
まあ、そもそも元がfizz_buzzの書き換えの話だしね。
「再帰に書き換えて俺のプログラムが速くなるのか」というのなら、処理系にもよりますが速くなったり遅くなったり変わらなかったりすると思います。
それで、一番引っかかっているのが、これ。
再帰処理って処理を停止して新しい処理を行い、終了後に停止していた処理に戻ることじゃない？
元増田と違う人かもしれないが、
これには同意します。しかしながら、
再帰処理って処理を停止して新しい処理を行い、終了後に停止していた処理に戻ることじゃない？
これは再帰呼び出しの説明としては、やっぱり変だと思いますよ。
ネタ扱いしたのは悪かったですけど。
もちろん、別増田も指摘している通り、すべての言語が末尾最適化されてるわけじゃありません（ついでに言うと、すべての再帰呼び出しがループに変換できるわけでもありません）。
しかし、gccですら（条件付きながら）末尾再帰を最適化してくれるご時世ですから、必ずしも「再帰はスタック領域を消費」「ループのほうが一般的に処理コストが小さい」とは言えないと思いますよ。まあ、gccなんぞ知らんと言われればそれまでですが。
