Java と Python のプログラマーから生まれた、問題に対する洗練された強力な APL ソリューションの構文は、多くの場合、紛らわしいほど長くなります。私が書いたコードは同じように手ごわいように見えるかもしれませんが、理解のために適切な変数名を持つ変数チャンクを好みます。より受け入れられている発達過程はどれですか? 計算が同じであっても、より多くのコード行を持つことのマイナス面はありますか (変数のためにメモリ使用量が少し増えますが)。
4 に答える
6
いいえ、私ではありません。また、保守性、明快さ、さらには効率性を重視している場合もそうではありません (実際、1 つのライナーは非常に非効率的です)。
もちろん、問題はワンライナーとは何かにかかっています。APL では、従来の言語では多くの行が必要になる可能性がある短いワンライナーで多くのことを実行できます。1 行のコードで 1 つの概念を表現することに問題はありません。たとえば、文字列から先頭の空白を削除するための式を構成要素に分割しても、得られるものはほとんどありません (おそらく入門クラスを除く)。
(∨\' '≠a)/a
しかし、英語と同じように、文が長くなりすぎることがあります。文法的には正しくても、細かく分割することで改善されます。
つまり、短いワンライナーが良いのです。長いワンライナーはダメです。明らかに、この 2 つの違いは科学というよりは芸術であり、好みの問題でもあります。
適切なバランスを示していると私が考えるコードの非常に良い例は、Dyalog APLのdfns コレクションです。
于 2013-07-26T16:15:24.317 に答える
3
密集した 1 行の APL ソリューションの傾向は、初期 (1970 年代) に、テレプリンター端末で機能を編集するのが非常に退屈だったという事実からおそらく来ました。APL\360 で提供されるデフォルトのエディターは、初期の IBM PC-DOS の EDLIN と比較しても、非常に原始的でした。また、APL/1130 などの以前のバージョンの APL は、コード行ごとにディスク読み取りが必要であると言われている遅いハードウェアで実行されました。1980 年代に入ってようやくまともなフルスクリーン エディタが登場し、見栄えの良いコードの作成がはるかに簡単になりました。
あの時、これが今。
今日では、おそらくエンターテイメント以外に、1 行に詰め込みすぎる理由はありません。読みやすさは、最小の CPU や省スペース (最新のハードウェアでは問題にならない) よりもはるかに重要であるため、この方法でコーディングする傾向にあります。
受け入れられるのは、あなたとあなたの同僚が、あなたが書いた数日後、数ヶ月後、または数年後に読むことができるコードです。
于 2013-10-23T14:09:54.293 に答える
0
私は APL 開発者として約 3 年間働いていますが、問題を 1 つの長い行として解決し、それを改良するのが好きであることがわかりました。1 つの長い行の場合、(私にとっては) ラムダという名前の単純なワンライナーに抽象化できる同様のコードの「チャンク」があるかどうかを簡単に確認できます。
于 2015-01-15T00:57:24.843 に答える