In the past months, many new features were added to Red/System, the low-level dialect embedded in Red. Here is a sum up if you missed them. Subroutines During the work on the low-level parts of the new Red lexer, the need arised for intra-function factorization abilities to keep the lexer code as DRY as possible. Subroutines were introduced to...
少なくとも実装を隠す（自分自身にも隠す）、つまり計算のロジックだけを書く、それは便利で、読みやすく、論理エラーを避けることができる。
SZZY：トレーディングに関してですが、私は注文のグリッドの実験を行い、A + B - Cのように注文を出すロジックを書きました。
Wrappersは、論理的で良い解決策だと思います。目的に合ったとき。そして、ラッパーは手続き型言語の革新だと思います。まさに、新規性・有用性という意味で。
トレーディングに関しては、私は注文のグリッドの実験を行い、注文のロジックをA + B - Cと書きました。
あらかじめパラメータを 設定した A、B、C- 遺伝的アルゴリズムの表現型として？
カプセル化することで、名前の自由度が増します。そして、この問題が名前の論理で解決されるとしたら。もちろん、これにはコストがかかりますが、Pythonは関数で書けばいいのです。が、可能です。
Pythonでは、どんな関数も変数と同じようにオブジェクトです)
ちなみに、連続的なOOPの例としては、Pythonがあります。そこでは、むしろ、誰もOOP以外のものの存在を知らないのです。
はクロージャがありますし、少なくとも昔のものではOOPを全く使わずに書けますから、お好きなほうをどうぞ。
pythonでは、関数も変数と同じようにオブジェクトです)
名前が重ならない限りは、すべてリファレンスで解決できるのです。関数はもちろんオブジェクトですが、その結果は内部で統一されており、内部を見ることができるのはglobalとpublicだけです。pythonのロジックは好きです)))
クロージャがあり、少なくとも古いものではopを全く使わずに書くことが可能で、好きな方
しかし、それでも最小限の構成要素はオブジェクトです。
しばらく見てないんだけど...。
彼は本当に別のスクリーンネームで行っているのでしょうか？
なーんだ、ピーターじゃないんだ、文体が違うんだ。
は、企業向けOOPとしてはJavaが突出している。私たちのドメインでは、Du* *opyを表現しています（巻き込まれないように振り分けました）。オブジェクトの美しさを求めるなら - 彼らのAPIを理解し、覚えておくために地味に試してみて、ありがたいことにテーマが知られている:-)。
でも、全部デタラメなんです...。
プログラミングのスキルを上げるには、何か頭をひねるようなことを学ぶといいかもしれませんね。例えば、Rebol/Red(https://www.red-lang.org/ ) があります。すごいもので、クソクリアではないですが、カッコいいですよね。
や、定番のSmalltalk(https://pharo.org/)があります。本番で使うことも可能です。
それに、「A+Bを異なるスタイルで書こう」というのは、正直言って子供の遊びです。
そうすれば、OOPとFPのどちらがクールかという疑問は、ひとりでに消えてしまうでしょう。
しかし、それでも最低限の構成要素は設備です。
というのが、ブレイクスルーとなった。
OOPの方が便利な場合はOOPを使い、メモリと時間を節約し、自分のためにコーディングする必要がある場合は手続き型に留まります。ちょうどある記事に出会ったので、どこがいいのか、何がいいのか、意見を聞きたいと思った）。結果 - プログラミングのことではなく、アドレスでいろいろなことを聞いた）全てはいつも通りです。
だから、誰も新しいことを教えてはくれません。自分が使いやすいものを使う、ただそれだけです。
エラーを最小限に抑えるために、エビデンス・プログラミング（特に形式検証）という分野があります。
コード品質を向上させるための部分的な対策として、一般的なコーディングスタイル（例：google codestyle）に従うこと、アサーション、制約（const、override、アクセス指定子）など、実際には実行には影響しないが、間違って使用するとコンパイルエラーを 引き起こすものを使用すること、設計におけるアプローチ一般に精通することなどが考えられるでしょう。
実際、重要なプログラミング分野を除けば、一般に、コードの品質よりも製品版を早く出すことの方が重要であり、これは悪いことだが事実である