OOPと手続き型プログラミングの比較 - ページ 21

新しいコメント
 
Реter Konow:

ユーザーが外部テーブルのトレイリングを有効にしているとのことですね。したがって、彼は1つのトレーリングしか有効にすることができません。そうすると、ifの代わりにswitchを使うことができます。


誰が読むんだ？ここで何してるの？

 
Реter Konow:

では、あなたのこの決断のメカニズムを説明してください。具体的に記述しています。あなたの持っているものは理解不能です。あなたのソリューションがより効果的であるという言葉だけ。どのような条件下でより効果的なのでしょうか？私が説明したような条件下であれば、あなたのソリューションはスイッチオペレーターよりも効率が良いということですか？

逸話となると、自分の主張を証明するよりも明らかに饒舌になりますね...。

明確に示していますね。

1.読めません。

2.あなたはここで何を論じているのか理解していない-それが一番面白いところです。議論しているのに、何を議論しているのかわからない。

 
Dmitry Fedoseev:

誰が読むんだ？ここで何してるの？

要するに、すべてがクリアなのです。


あなたができる証拠は、支離滅裂なフレーズの断片、奔放さ、ジョーク、理解できないものへの言及だけです...。

 
Реter Konow:
要するに、すべてがクリアなのです。


あなたの証明は、支離滅裂なフレーズの断片、奔放さ、ジョーク、理解不能なものへの言及だけ...。


そして、この 記事をもう一度読み直してみてください。

 
Реter Konow:


すでに説明されていることですが ))あなたの言葉でもう一度...。どんな仕事でもOOPがなければ解決できないが、OOPは便利、時間がかからない、読みやすい、などなど...。プロジェクトが 大規模で複雑であれば、OOPの有効性がより明らかになる、大規模なプロジェクトを扱ったことがなければ、ポイントがわかりにくい......。より快適に感じる場合は、ご自身の判断でどうぞ

 
Nikolay Ivanov:

すでに説明されていることですが ))あなたの言葉でもう一度...。どんな仕事でもOOPがなくても解決できるけど、OOPは便利、時間がかからない、読みやすい、などなど...。プロジェクトが大規模で複雑であれば、OOPの有効性がより明らかになる、大規模なプロジェクトを扱ったことがなければ、ポイントがわかりにくい......。自分の意見に固執するのは、その方が気が楽だからです。

それなら、本来証明できないことを証明しようとする必要はない。OOPが手続き型より優れていることを証明することはできませんが、OOPなしでもどんなタスクでも解決できることを証明することは可能です。つまり、私は自分の主張を証明できるのに、他の人は主張以外を証明できないということがわかったわけです...。

OOPの原点は、開発者の思考の構造化であり、それ以上のものではありません。このように構造化することで、まるで演劇の台本のようにプログラムの論理を見抜き、構築することができるのです。機械と完全に一体化して使いこなすための、さらなるチャンスなのです。

反対はしませんが、プログラムという仕組みそのものの効率化とは関係ありません。

それが、今回のコミュニケーションで一番理解できたことです。

皆さん、ご感想をありがとうございました。

 
Реter Konow:

それなら、本来証明できないことを証明しようとする必要はない。OOPが手続き型より優れていることを証明することはできませんが、OOPなしでもどんなタスクでも解決できることを証明できることがわかりました。つまり、私は自分の主張を証明できるのに、他の人は主張以外を証明できないということがわかったわけです...。

OOPの原点は、開発者の思考の構造化であり、それ以上のものではありません。このように構造化することで、まるで演劇の台本のようにプログラムの論理を見抜き、構築することができるのです。機械と完全に一体化して使いこなすための、さらなるチャンスなのです。

反対はしませんが、プログラムという仕組みそのものの効率化とは関係ありません。

それが、今回のコミュニケーションで一番理解できたことです。

皆さん、良識あるご意見をありがとうございました。



議論している内容を理解していないから、全てが既に証明されていることに気づけないだけだろう。馬鹿馬鹿しい、蛇ゴリ押しのケツに怒鳴るのはやめろ。

 
Dmitry Fedoseev:

議論している内容を理解していないから、全てが既に証明されていることに気づけないだけだろう。馬鹿馬鹿しい、蛇ゴリ押しのケツに怒鳴るのはやめろ。

恥をかかないようにね。私の目には、あなたが倒れているように映ります。
 
Реter Konow:

それなら、本来証明できないことを証明しようとする必要はない。OOPが手続き型より優れていることを証明することはできませんが、OOPなしでもどんなタスクでも解決できることを証明できることがわかりました。つまり、私は自分の主張することを証明できるが、他の人は何も証明できないが、それでも主張することができるということがわかった。


現代のシステムはすべてOOPを採用しているというのは、優劣の証明にはならないのですね。理解する準備が出来ていないだけで、簡単な質問をして複雑な答えを理解できない...答えがないと思っている......。それはおかしいな......。

OOPの原点は、開発者の思考を構造化することであり、それ以外の 何物でもありません。この構造化によって、まるで台本劇のようにプログラムの論理を見抜き、構築することができるのです。機械と完全に一体化して使いこなすための、さらなるチャンスなのです。


考え方が変わるというのは、そうですね、最初は「何のために？しかし、プロジェクトが 何千行ものコードの塊になると、その恩恵を受け始め）、なぜ、何のためにそれが必要だったのかが理解できるようになるのです。）


これには何の反対もしませんが、これは機構そのものの効率化とは関係ないことです。

あるプロジェクトが保守や更新が困難で費用がかかり、別のプロジェクトが迅速で簡単であれば、最初のプロジェクトは死んでしまう。これが自然淘汰だ

 
Dmitry Fedoseev:

逸話があります。

イリヤ・ムロメッツは、大蛇ゴリニチと戦うために出かけた。一日経ち、二日経ち、突然山が見え、その中に洞窟がある。
洞窟の中を覗き込んで叫んだ。
- 大蛇のゴリニチ、出てこい！戦うぞ
そして、その答えは「沈黙」です。また言う。
- 大蛇のゴリニチ、出撃せよ
静粛に。3度目の正直
- 大蛇のゴリニチ、出てきて戦え!
そして、山の背後から頭が現れる。
- まあ、戦おうよ。でも、なんで叫ぶんだ？


このトピックと同様))昔、ポピュラー・メカニクス誌を購読していたら、ユーモアのあるページがあった。

一度、レオが戦場に出たことがある。だから、ボソボソと歩いているんです。彼は一匹の狐に出会う。フォックス、早く、獣の王は誰だ？

- レバさん、もちろんです!

そして、「これでいいんだ」と納得した。

ウサギに会ったが、同じ結果だった。

そして象は熱くなり、ハエから幹を振って、ライオンは飛び去りました。

そして、茂みの中に座っていたゾウが、去っていくときに何と言ったか、皆さんご存知ですか？

- そして、答えが分からなくても怒らないでください（笑)。

1...141516171819202122232425262728...48
新しいコメント