関数に渡される引数の量を制限することに基づく言語

このアイデアは、+、-、％などのファクト演算子に触発されており、1つまたは2つの引数が渡され、副作用がない関数と見なすことができます。私または他の誰かが、3つ以上の引数の受け渡しを停止し、戻り値を介してのみ機能する言語を作成すると仮定します。

a）そのような言語はコードを理解しやすくするでしょうか？

b）コードの流れはより明確になりますか？（より多くのステップを強制し、潜在的に少ない対話を「非表示」にします

c）制限により、より複雑なプログラムでは言語が非常に大きくなりますか？

d）（ボーナス）賛否両論に関するその他のコメント

注意：

2つの決定を行う必要があります。1つ目は、main（）または同等の外部でのユーザー入力を許可するかどうか、および配列/構造体を渡すときに何が起こるかについてのルールです。たとえば、1つの関数で複数の値を追加したい場合、その関数を配列にまとめることで制限を回避できます。これは、配列または構造体がそれ自体と対話することを許可しないことで停止できます。これにより、たとえば、各数値をその位置に応じて異なる量で除算できます。

Robert C. Martinの著書「Clean Code」では、最大で0、1、または2つのパラメーターを持つ関数の使用を強く推奨しているため、少なくともこのスタイルを使用するとコードがきれいになると考える経験豊富な著者が1人います（ただし、確かにここでは究極の権威ではなく、彼の意見は議論の余地がある）。

ボブ・マーティンが私見的に正しいのは、3つ以上のパラメータを持つ関数は、多くの場合、コードの匂いの指標です。多くの場合、パラメーターはグループ化されて結合されたデータ型を形成する場合があります。他の場合は、関数が単純に多すぎることを示すインジケーターになる場合があります。

ただし、このための新しい言語を発明することは良い考えではないと思います。

• コード全体にこのようなルールを強制する場合は、既存の言語のコード分析ツールが必要です。このために完全に新しい言語を発明する必要はありません（たとえば、C＃の場合は「fxcop」などを使用できます） ）。

• パラメータを新しいタイプに結合するのは面倒なだけの価値がないように見える場合もあれば、純粋な人工的な組み合わせになる場合もあります。たとえば、.NetフレームワークのこのFile.Openメソッドを参照してください。4つのパラメーターが必要です。異なるAPIを関数に提供する最も実用的な方法だと考えたため、そのAPIの設計者は意図的にこれを行ったと確信しています。

• 技術的な理由で2つ以上のパラメーターで物事を簡単にする現実のシナリオがあります（たとえば、単純なデータ型の使用に縛られ、異なる組み合わせができない既存のAPIへの1：1マッピングが必要な場合）パラメーターを1つのカスタムオブジェクトに）

Haskellなど、すでにこの方法で機能する言語がたくさんあります。Haskellでは、すべての関数は1つの引数を取り、1つの値を返します。

n個の引数を取る関数を、n-1個の引数を取る関数に置き換えて、最終的な引数を取る関数を返すことは常に可能です。これを再帰的に適用すると、任意の数の引数を取る関数を常に1つの引数を取る関数で置き換えることが常に可能です。そして、この変換はアルゴリズムによって機械的に実行できます。

これは、1950年代に広範囲に研究したHaskell Curry、1924年にそれを記述したMosesSchönfinkel、および1893年に予言したGottlob Fregeにちなんで、Frege-Schönfinkeling、Schönfinkeling、Schönfinkel-Currying、またはCurryingと呼ばれます。

つまり、引数の数を制限しても、影響はまったくありません。

私はここ数週間、Jコンピューター言語を学ぼうと試みてきました。Jでは、ほとんどすべてが演算子であるため、「monads」（引数が1つだけの関数）と「dyads」（引数が2つだけの関数）しか取得できません。さらに引数が必要な場合は、配列で提供するか、「ボックス」で提供する必要があります。

Jは非常に簡潔ですが、前身のAPLと同様に、非常に不可解な場合もあります。文字ではなく名前を使用して演算子を作成することにより、Jプログラムをより読みやすくすることができます。

開発者を制約する方法に基づいた言語は、言語開発者が各プログラマーのニーズを理解するという前提に依存しています。これが実際に有効な場合があります。たとえば、ミューテックスとセマフォを使用した同期を必要とするマルチスレッドプログラミングの制約は、多くのプログラマが「良い」と見なします。同様に、マルチスレッドガベージコレクションアルゴリズムのニュアンスを完全に把握したい人はほとんどいません。GCアルゴリズムを単純に破らない言語は、プログラマにあまりにも多くのニュアンスを認識させるよりも優先されます。

言語開発者として、あなたがあなたの言語を使用するプログラマよりもはるかによく引数を渡すことを理解しているので、あなたが有害だと思うことを彼らが防ぐのに価値がある理由について、有効な議論をする必要があります。それは難しい議論になると思います。

また、プログラマーが制約を回避することを知っておく必要があります。3つ以上の引数が必要な場合、カリー化などの手法を使用して、引数の少ない呼び出しに変換します。ただし、多くの場合、これを改善するのではなく、読みやすさが犠牲になります。

私がこの種のルールで知っている言語のほとんどはエソランであり、限られた機能セットで実際に操作できることを実証するために設計された言語です。特に、すべての文字がオペコードであるエソランは、単にオペコードのリストを短くする必要があるため、引数の数を制限する傾向があります。

次の2つが必要です。

• 閉鎖
• 複合データ型

JörgW Mittagによって書かれた答えを説明する数学的な例を追加します。

ガウス関数を考えます。

ガウス関数には、その形状に2つのパラメーター、つまり平均（曲線の中心位置）と分散（曲線のパルス幅に関連）があります。2つのパラメーターに加えて、1つはx評価するために自由変数の値を提供する必要があります。

最初のステップでは、3つのパラメーター、つまり平均、分散、自由変数すべてをとるガウス関数を設計します。

2番目のステップでは、平均と分散を1つのものに結合する複合データ型を作成します。

3番目のステップでは、2番目のステップで作成した複合データ型にバインドされたガウス関数のクロージャーを作成することにより、ガウス関数のパラメーター化を作成します。

最後に、3番目のステップで作成されたクロージャーを、自由変数の値を渡して評価しますx。

したがって、構造は次のとおりです。

• 評価（計算）
  • ParameterizedGaussian（閉包：数式、およびいくつかのバインドされた変数）
    • GaussianParameters（複合データ型）
      • 平均（値）
      • 分散（値）
  • X（自由変数の値）

1. ほぼすべてのプログラミング言語で、何らかのタイプのリスト、配列、タプル、レコード、またはオブジェクトを唯一の引数として渡すことができます。唯一の目的は、他のアイテムを個別に関数に渡すのではなく保持することです。一部のJava IDE には、まさにそれを行うための「パラメーターオブジェクトの抽出」機能さえあります。内部的に、Javaは配列を作成して渡すことにより、可変数の引数を実装します。

2. あなたが本当に純粋な形で話していることをしたいのであれば、ラムダ計算を見る必要があります。それはまさにあなたが説明するものです。Webで検索できますが、私にとって意味のある説明はTypes and Programming Languagesにありました。

3. HaskellおよびMLプログラミング言語を見てください（MLの方が簡単です）。どちらもラムダ計算に基づいており、概念的には関数ごとに1つのパラメーターしかありません（少し目を細めている場合）。

4. Josh BlochのItem 2は、「多くのコンストラクターパラメーターに直面したときにビルダーを検討する」です。これがどのように冗長になるかを見ることができますが、このように書かれたAPIを使用するのは楽しいことです。

5. 一部の言語には、名前付きのパラメーターがあります。これは、巨大なメソッドシグネチャをナビゲートしやすくする別のアプローチです。 Kotlinは、たとえば名前付き引数を持っています。