アカウント名:
パスワード:
御説が上手く行くのはどことどことどこでしょうか？可能な全ての場合で御説は上手く行くのでしょうか？上手く行く範囲が定まっていない様な最先端の説にはとても関与出来ません。
その様な言い方は「せんせい」に言うのは、ふさわしく無いと思います。設計上のライバルに対して言うのが正当だと思います。（もっとも、教員としての将来の研究のネタを先に言ってしまった生徒 の指を切る様な教員に対してはふさわしいのかも知れません。） 関数型が手続き型やオブジェクト指向より、必ず良い（無限の責任範囲に良い）との主張はWikipediaでなされており、その良さの源は、・「計算をすると情報量が増える」種類の計算を、・（よりタチの良い）「計算をすると情報量が減る」種類の計算に、置き換える事で得られる、との目算からだったのでは無いかと、1週間前辺りから、自分は思う様になりました。しかし、その様な虫のよい目算は、100％ついえています。 たとえば、・戻り値（復帰コード）は下らない。業務知識をうまく活用して、全ての 計算が正しい様にしよう！とした人間が、自分が関数型で謂れの無い非難をあびていた頃に実際にいました。 少々の仕様変更で発狂する、一時期居た設計者の存在理由がこれだと思いました。・「うまく」全ての場合に、計算が正しい様にしようと無理した結果、 所与の設定（仕様）が少しでも変更されると、致命的に困る様になる。からです。
・「計算をすると情報量が増える」種類の計算を必要としている分野では 戻り値（復帰コード）は下らなく無い。というのが歴史的帰着です。 NULLは下らないとか言う人間も、同様で、「計算をすると情報量が減る」種類の計算を、そうで無いものが必要な場面で押し付ける類の人間でした。
一時が万事です。・「計算をすると情報量が増える」種類の計算を必要としている分野で、・（よりタチの良い）「計算をすると情報量が減る」種類の計算を押し付ける ことばかり。・ネタはさまざまで、何らかの事実から情報量を減らしても 構わないと言い張り、その事実が変わった後（あるいは事実を曲げてくる クラッカーの存在）で、脆弱さを披露するだけの人間です。 たんなるせんせいに対していう言葉ではないと思います。
単にあなたが挙げた個人が学術的被害に遭わない為のムーブに対する皮肉以上の意味のないコメントにズレた(無理筋の主張を回避する手法にいする指摘への回答ではなくソフトウェア開発に対する観点からのよくわからない主張)を長文でできるあたり暇人？
次回の日記の内容を、タイミングが合ったので載せただけでした。それほど暇では有りません。
すべての問題を解決する手立てはありません。なぜなら根本的原因が人間は間違いを犯すというところにあるからです。プログラミングやソフトウェア開発がうまく行かない原因として大きいものにビジネスや業務を的確に表現できる言語やフレームワークが存在しないってのもあるんだろうけど。
でもその分野の素人は、ある解法を紹介されると、明示的に「すべてでは無い」と言われない限り、「すべてだ」と思ってしまうのは事実です。紛れもない事実です。
専門家が、何か「すべてでは無い」と言わない場合、それにも関わらず「すべて」では無い場合、詐欺だとするべきだと思います。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
せんせーおしえてくださーい (スコア:0)
御説が上手く行くのはどことどことどこでしょうか？
可能な全ての場合で御説は上手く行くのでしょうか？
上手く行く範囲が定まっていない様な最先端の説にはとても関与出来ません。
Re:せんせーおしえてくださーい (スコア:1)
その様な言い方は「せんせい」に言うのは、ふさわしく無いと思います。
設計上のライバルに対して言うのが正当だと思います。
（もっとも、教員としての将来の研究のネタを先に言ってしまった生徒
の指を切る様な教員に対してはふさわしいのかも知れません。）
関数型が手続き型やオブジェクト指向より、必ず良い（無限の責任範囲に良い）
との主張はWikipediaでなされており、
その良さの源は、
・「計算をすると情報量が増える」種類の計算を、
・（よりタチの良い）「計算をすると情報量が減る」種類の計算に、
置き換える事で得られる、との目算からだったのでは無いか
と、1週間前辺りから、自分は思う様になりました。
しかし、その様な虫のよい目算は、100％ついえています。
たとえば、
・戻り値（復帰コード）は下らない。業務知識をうまく活用して、全ての
計算が正しい様にしよう！
とした人間が、自分が関数型で謂れの無い非難をあびていた頃に実際に
いました。
少々の仕様変更で発狂する、一時期居た設計者の存在理由がこれだと
思いました。
・「うまく」全ての場合に、計算が正しい様にしようと無理した結果、
所与の設定（仕様）が少しでも変更されると、致命的に困る様になる。
からです。
・「計算をすると情報量が増える」種類の計算を必要としている分野では
戻り値（復帰コード）は下らなく無い。
というのが歴史的帰着です。
NULLは下らないとか言う人間も、同様で、
「計算をすると情報量が減る」種類の計算を、そうで無いものが必要な
場面で押し付ける類の人間でした。
一時が万事です。
・「計算をすると情報量が増える」種類の計算を必要としている分野で、
・（よりタチの良い）「計算をすると情報量が減る」種類の計算を押し付ける
ことばかり。
・ネタはさまざまで、何らかの事実から情報量を減らしても
構わないと言い張り、その事実が変わった後（あるいは事実を曲げてくる
クラッカーの存在）で、脆弱さを披露するだけの
人間です。
たんなるせんせいに対していう言葉ではないと思います。
Re: (スコア:0)
単にあなたが挙げた個人が学術的被害に遭わない為のムーブに対する皮肉以上の意味のないコメントにズレた(無理筋の主張を回避する手法にいする指摘への回答ではなくソフトウェア開発に対する観点からのよくわからない主張)を長文でできるあたり暇人？
Re:せんせーおしえてくださーい (スコア:1)
次回の日記の内容を、タイミングが合ったので載せただけでした。
それほど暇では有りません。
Re: (スコア:0)
すべての問題を解決する手立てはありません。なぜなら根本的原因が人間は間違いを犯すというところにあるからです。
プログラミングやソフトウェア開発がうまく行かない原因として大きいものにビジネスや業務を的確に表現できる言語やフレームワークが存在しないってのもあるんだろうけど。
Re:せんせーおしえてくださーい (スコア:1)
でもその分野の素人は、ある解法を紹介されると、
明示的に「すべてでは無い」と言われない限り、「すべてだ」と思ってしまう
のは事実です。紛れもない事実です。
専門家が、何か「すべてでは無い」と言わない場合、それにも関わらず「すべて」では無い場合、
詐欺だとするべきだと思います。