アカウント名:
パスワード:
まあincludeくらいはコピペしてもいいけどほかはやめましょう。共通処理は関数化するかincludeできるようにしましょう。ということをinclude 過去の議論.logとかで済ませられないものだろうか。
重ねてお聞きしますが、何ででしょうか？お気持ちでコピペを禁止していただけだとしたら、コボラー並の批判を甘んじるのも仕方のないことだと思います。
バグがあると修正が面倒とかコピペミスがわいという程度
もし、オブジェクト指向プログラミングの継承は積極的に使うべきであるという時間軸が有ったとしましょう。 オーバーライド（スーパークラスで定義されたメソッドをサブクラスで 定義し直し、動作を上書き（変更）すること Wikipedia 日本語版 オーバーライド より）をして、似た、ただし共通部分を切り出す程似ていない様なプログラムを作る場合、まず、スーパークラスのメソッドをコピペをすると思います。 そこには、通常、複数の機能呼び出しが書かれていることでしょう。たとえば、画面プログラムでぶち切りを任意の時点で許容する必要があるシステムで、その対応の一連の動作が書かれているかも知れません。 ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
しかし、この、我々が居る時間軸では継承は最小限にすべきという認識で間違いは無いと思われ、そうしますと、この「パターン（コピペ後変更）」の適用は上記時間軸に比べ、さらに増えるでしょう。 実用的なプログラムで、似たプログラムを書く場合、コピペは必須です。バグ対応がより困難になるのは、単に、そう言う要求が有ったからです。似た、ただし共通部分を切り出す程似ていない様なプログラムを要求されてしまったから、畢竟、より困難になっただけで、 むしろ、コピペを使わない場合、さらに、将来のバグ対応がより困難になったでしょう。 ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー 自分が危惧しているのは、自分が言う、嘔吐主義者の動機が、・技術的な観点では無く、・より実用的なプログラムを書ける技法を不利にし、 次世代と言っているが実用的なプログラムを書けない技法を 有利にしようとする、・党派的な動機では無いかと言う点です。実用的なプログラムを書く際に必要な技法を「だめだ」としてしまうと、そこに至っていない（至る見込みが無い）技法を不当に優位に置くことになります。 もしその危惧が正しければ、・（高く後何年も使わないと収支が破綻する）汎用機を 守る為、なんらかの党派的な言動をしたコボラーと同じ 処断とすべきでは無いかという観点です。 確かにこの点は言葉足らずでしたが、そういう思いです。
まあコボラー批判イコールコピペ批判だと思ってるうちは頓珍漢なことを言っちゃうと思いますよ。
＞コボラー批判イコールコピペ批判というのは失当です。ただ、自分にとって最大のエモーショナルな部分であるコボラー批判を持ち出したのは、それだけコピペの話が大きい事だと思っているからです。 画面のプログラムで、モデルとビューとコントローラーが有り、・モデルはDB的なものを反映・ビューはWeb画面的なものを反映し、それぞれ整理が付くと思いますが、コントローラーはどのフレームワークでも鬼門です。 いままでの開発手法では、コントローラー部分は、・最低限の雛形をコピペし・その後は、開発者が要求に合わせてがちゃがちゃとプログラムを組むのが普通だと思います。ここで、新しい手法といわれるものは、・それに加えて追加の規範（うまく自由度を減らし、 開発者と言われる人間で無くてもいじれる様にする、開発者でも がちゃがちゃで無く、もっとスッキリいじれる様にする。） を設けて、より良くしようとしたのだと思います。 これが出来ればオブジェクト指向などお払い箱、出来なければ関数型や宣言型はお払い箱で、まさに天下分け目の要所だったと考えます。 実際、「追加の規範」がうまくいけばそれは関数型と称され、また宣言型と称されたのだと思いますが、その様な虫の良い規範は結局無く、コントローラーは、雛形をコピペし、がちゃがちゃとプログラムを組むのが最大限に単純化したやり方となります。 この「追加の規範」が出来ていれば、コピペばかりの年寄りは一掃出来たのかも知れませんが、実際は違います。逆に、コピペ批判をした人間は「ご苦労様でした、もう結構です」となります。 コピペ批判をした人間はコボラー並みに要らない人間になったのだと言いたかったのです。コボラー批判 イコール コピペ批判では無く、批判の対象者（コボラー批判） 同じ境遇 批判の対象者（コピペ批判）と言いたかったのです。
×批判の対象者（コボラー批判） 同じ境遇 批判の対象者（コピペ批判） ○批判の対象者（コボラー批判） 同じ境遇 批判の発言者（コピペ批判） でした。
逆に、制御（コントローラー）に関して、「サブセットフルセット」の仮説を言いうるかも知れません。 制御（コントローラー）に関しては、・どんなサブセットの問題であっても、・フルセットのプログラムの機能が必要という仮説です。 だから、一貫して制御しないといけない機能を分けて、サーバーレスにするとおかしくなるのだと思います。「機能を分けてサーバーレスにする」のは、プログラムの機能の制限だからです。 多分他にも有ると思います。プログラミングは魔法では無いので、・ソウ●ジェ●をかじられたから戒めが自動で解けるとか無いので、1つ1つ、嘔吐主義者の先走った思惑を解呪して行かないといけないです。＃高階関数など、怪しいです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
コピペ賛同者に対する反論にコピペ(のような回答)を強いられる悲劇 (スコア:0)
まあincludeくらいはコピペしてもいいけどほかはやめましょう。
共通処理は関数化するかincludeできるようにしましょう。
ということをinclude 過去の議論.logとかで済ませられないものだろうか。
Re:コピペ賛同者に対する反論にコピペ(のような回答)を強いられる悲劇 (スコア:1)
重ねてお聞きしますが、何ででしょうか？
お気持ちでコピペを禁止していただけだとしたら、コボラー並の批判を
甘んじるのも仕方のないことだと思います。
Re: (スコア:0)
バグがあると修正が面倒とかコピペミスがわいという程度
Re:コピペ賛同者に対する反論にコピペ(のような回答)を強いられる悲劇 (スコア:1)
もし、オブジェクト指向プログラミングの継承は積極的に
使うべきであるという時間軸が有ったとしましょう。
オーバーライド
（スーパークラスで定義されたメソッドをサブクラスで
定義し直し、動作を上書き（変更）すること
Wikipedia 日本語版 オーバーライド より）
をして、似た、ただし共通部分を切り出す程似ていない
様なプログラムを作る場合、
まず、スーパークラスのメソッドをコピペをすると思います。
そこには、通常、複数の機能呼び出しが書かれていることでしょう。
たとえば、画面プログラムでぶち切りを任意の時点で許容する
必要があるシステムで、その対応の一連の動作が書かれている
かも知れません。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
しかし、この、我々が居る時間軸では継承は最小限にすべきという
認識で間違いは無いと思われ、
そうしますと、この「パターン（コピペ後変更）」の適用は
上記時間軸に比べ、さらに増えるでしょう。
実用的なプログラムで、似たプログラムを書く場合、コピペは
必須です。バグ対応がより困難になるのは、単に、
そう言う要求が有ったからです。
似た、ただし共通部分を切り出す程似ていない様な
プログラムを要求されてしまったから、畢竟、より困難になった
だけで、
むしろ、コピペを使わない場合、
さらに、将来のバグ対応がより困難になったでしょう。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
自分が危惧しているのは、自分が言う、嘔吐主義者の動機が、
・技術的な観点では無く、
・より実用的なプログラムを書ける技法を不利にし、
次世代と言っているが実用的なプログラムを書けない技法を
有利にしようとする、
・党派的な動機では無いか
と言う点です。
実用的なプログラムを書く際に必要な技法を「だめだ」として
しまうと、そこに至っていない（至る見込みが無い）技法を
不当に優位に置くことになります。
もしその危惧が正しければ、
・（高く後何年も使わないと収支が破綻する）汎用機を
守る為、なんらかの党派的な言動をしたコボラーと同じ
処断とすべきでは無いか
という観点です。
確かにこの点は言葉足らずでしたが、そういう思いです。
Re: (スコア:0)
まあコボラー批判イコールコピペ批判だと思ってるうちは頓珍漢なことを言っちゃうと思いますよ。
コピペこそ天下分け目 (スコア:1)
＞コボラー批判イコールコピペ批判
というのは失当です。
ただ、自分にとって最大のエモーショナルな部分である
コボラー批判を持ち出したのは、それだけコピペの話が
大きい事だと思っているからです。
画面のプログラムで、モデルとビューとコントローラーが
有り、
・モデルはDB的なものを反映
・ビューはWeb画面的なものを反映
し、それぞれ整理が付くと思いますが、コントローラーは
どのフレームワークでも鬼門です。
いままでの開発手法では、コントローラー部分は、
・最低限の雛形をコピペし
・その後は、開発者が要求に合わせてがちゃがちゃとプログラムを組む
のが普通だと思います。
ここで、新しい手法といわれるものは、
・それに加えて追加の規範（うまく自由度を減らし、
開発者と言われる人間で無くてもいじれる様にする、開発者でも
がちゃがちゃで無く、もっとスッキリいじれる様にする。）
を設けて、より良くしようとした
のだと思います。
これが出来ればオブジェクト指向などお払い箱、出来なければ
関数型や宣言型はお払い箱で、
まさに天下分け目の要所だったと考えます。
実際、「追加の規範」がうまくいけばそれは関数型と
称され、また宣言型と称されたのだと思いますが、
その様な虫の良い規範は結局無く、
コントローラーは、雛形をコピペし、がちゃがちゃとプログラムを組むのが
最大限に単純化したやり方となります。
この「追加の規範」が出来ていれば、コピペばかりの
年寄りは一掃出来たのかも知れませんが、実際は違います。
逆に、コピペ批判をした人間は「ご苦労様でした、もう結構です」
となります。
コピペ批判をした人間はコボラー並みに要らない人間に
なったのだと言いたかったのです。
コボラー批判 イコール コピペ批判
では無く、
批判の対象者（コボラー批判） 同じ境遇 批判の対象者（コピペ批判）
と言いたかったのです。
Re:コピペこそ天下分け目 (スコア:1)
×批判の対象者（コボラー批判） 同じ境遇 批判の対象者（コピペ批判）
○批判の対象者（コボラー批判） 同じ境遇 批判の発言者（コピペ批判）
でした。
逆に (スコア:1)
逆に、制御（コントローラー）に関して、
「サブセットフルセット」の仮説を言いうるかも
知れません。
制御（コントローラー）に関しては、
・どんなサブセットの問題であっても、
・フルセットのプログラムの機能が必要
という仮説です。
だから、一貫して制御しないといけない
機能を分けて、サーバーレスにするとおかしくなる
のだと思います。「機能を分けてサーバーレスにする」
のは、プログラムの機能の制限だからです。
多分他にも有ると思います。
プログラミングは魔法では無いので、
・ソウ●ジェ●をかじられたから戒めが自動で解ける
とか無いので、
1つ1つ、嘔吐主義者の先走った思惑を解呪して
行かないといけないです。
＃高階関数など、怪しいです。