アカウント名:
パスワード:
とりあえず、プロジェクト杉田玄白協賛参加テキストの ガベージ・イン/ガベージ・アウト:善き人々が悪しきプログラムに手を染める時 [practical-scheme.net] 原文 [pipeline.com]を読もう。そして知能指数が20も違えば会話が成り立たないことを思い出そう。
そこまで言っても分からない馬鹿ならば。djbやクヌースのように、自分の書いたプログラムのバグや脆弱性に対して賞金をかけろと言ってやれ。破産するころには理解してくれるだろう。馬鹿には体で教えるしかないのだ。
馬鹿がdjbやクヌースをどれだけこき下ろそうとも、彼等の書いた
それが理解できないから馬鹿は馬鹿であり、我々凡人は凡人のままなのだ。
そうそう。その通り。でね。それを前提にして。我々「圧倒的大多数の」凡人、逆立ちしても死んでも希少な彼らのような天才にはなれない凡人たちが(おそらくはチームで)プログラミングをするにあたって、どうしたらいいと思う?というのが元々のACの問いなんだと思うんだよね。元ネタの困ったコードを書く同僚が天才なのか凡才以下の凡凡才なのかはわからないけど、とにかく彼に周囲の凡人にあわせてもらうにはどうしたらいいか、ってこと。周囲にあわせる必要が無いような環境で働く超のつく天才たちはいざ知らず、周囲に同僚がいる環境においては、周囲の迷惑になるのは全体の生産性を下げる行動だよね、という観点で見てみたほうがいいんじゃないかと思うんですよ。
それと、現場的に言うと、動けばいい、というのは超短期的な話ですよ。書き捨てのプログラムとか、ライフサイクルが短かかったり代替商品があったりするものとか。半年以上とかそれなりに長く働くものであったり、社内/部内システムのようにユーザーの要望に強く結びついたものなどは、上記のものよりも強めに「メンテナンスコスト」を意識しますよ。それこそ1バイトのメモリをやりくりしてギリギリで商品開発をしていた頃とは違いますからね。それよりも、多少は実行効率が悪くてもメンテナンスしやすい構造にしておけば、あとが楽(どころかコストの安いところに丸投げとか)できますからね。全体的なコストを考えれば、そして中・長期的に見れば、プログラミングに所謂天才と凡人以下の存在は不要です。凡人の、凡人による、凡人のためのプログラムこそが正義ですよ。あえて例外をあげるとすれば、趣味のプログラムなら別ですけどね。
>メンテナンスしやすい構造にしておけば、あとが楽
と言うのは共通認識になっていないと思います。と言うより、メンテナンスしやすくする手間など、真っ先に仕分けの対象になると思います。
もちろん先になれば仕分けた人間(たぶん収支責任者)が真っ青になるのは確かですが、ビジネスはファクトが基本で、なかなか先の話は飲み込んでもらえません。
さらにそういう責任者体質の人は、「後で真っ青になる」と脅すと、自動的に不屈の精神が起動し、脅した人間を、万難を排してでも討滅すべき対象と見なすと思います。
そんな簡単に正義だと言えるとも思えません。
>凡人の、凡人による、凡人のためのプログラムこそが正義ですよ。言いたい事はわからんでもないが、そういう発想の行き着く先が人月商売・人海戦術・構成人員の質の低下という状態の肯定になっているような気がするんで、完全に同意はしかねる。
もう少し書くと、日本の会社における凡人万能主義といえる錯覚は、単に、雇った人間を良かれ悪しかれ使いつづけるしかないという固有の事情により、構成人員は使いやすい凡人が望ましいという状況を後付で肯定しているだけだと思う。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
この本家のACはガベージ・イン/ガベージ・アウトを熟読すべき (スコア:2, 興味深い)
とりあえず、プロジェクト杉田玄白協賛参加テキストの ガベージ・イン/ガベージ・アウト:善き人々が悪しきプログラムに手を染める時 [practical-scheme.net] 原文 [pipeline.com]を読もう。
そして知能指数が20も違えば会話が成り立たないことを思い出そう。
そこまで言っても分からない馬鹿ならば。
djbやクヌースのように、自分の書いたプログラムのバグや脆弱性に対して賞金をかけろと言ってやれ。
破産するころには理解してくれるだろう。
馬鹿には体で教えるしかないのだ。
馬鹿がdjbやクヌースをどれだけこき下ろそうとも、彼等の書いた
Re:この本家のACはガベージ・イン/ガベージ・アウトを熟読すべき (スコア:1)
そうそう。その通り。
でね。
それを前提にして。
我々「圧倒的大多数の」凡人、逆立ちしても死んでも希少な彼らのような天才にはなれない凡人たちが(おそらくはチームで)プログラミングをするにあたって、どうしたらいいと思う?
というのが元々のACの問いなんだと思うんだよね。
元ネタの困ったコードを書く同僚が天才なのか凡才以下の凡凡才なのかはわからないけど、とにかく彼に周囲の凡人にあわせてもらうにはどうしたらいいか、ってこと。
周囲にあわせる必要が無いような環境で働く超のつく天才たちはいざ知らず、周囲に同僚がいる環境においては、周囲の迷惑になるのは全体の生産性を下げる行動だよね、という観点で見てみたほうがいいんじゃないかと思うんですよ。
それと、現場的に言うと、動けばいい、というのは超短期的な話ですよ。
書き捨てのプログラムとか、ライフサイクルが短かかったり代替商品があったりするものとか。
半年以上とかそれなりに長く働くものであったり、社内/部内システムのようにユーザーの要望に強く結びついたものなどは、上記のものよりも強めに「メンテナンスコスト」を意識しますよ。
それこそ1バイトのメモリをやりくりしてギリギリで商品開発をしていた頃とは違いますからね。
それよりも、多少は実行効率が悪くてもメンテナンスしやすい構造にしておけば、あとが楽(どころかコストの安いところに丸投げとか)できますからね。
全体的なコストを考えれば、そして中・長期的に見れば、プログラミングに所謂天才と凡人以下の存在は不要です。
凡人の、凡人による、凡人のためのプログラムこそが正義ですよ。
あえて例外をあげるとすれば、趣味のプログラムなら別ですけどね。
Re:この本家のACはガベージ・イン/ガベージ・アウトを熟読すべき (スコア:1)
>メンテナンスしやすい構造にしておけば、あとが楽
と言うのは共通認識になっていないと思います。
と言うより、メンテナンスしやすくする手間など、真っ先に仕分けの対象に
なると思います。
もちろん先になれば仕分けた人間(たぶん収支責任者)が真っ青になるのは
確かですが、ビジネスはファクトが基本で、なかなか先の話は飲み込んで
もらえません。
さらにそういう責任者体質の人は、「後で真っ青になる」と脅すと、自動的に
不屈の精神が起動し、脅した人間を、万難を排してでも討滅すべき対象と
見なすと思います。
そんな簡単に正義だと言えるとも思えません。
Re: (スコア:0)
>凡人の、凡人による、凡人のためのプログラムこそが正義ですよ。
言いたい事はわからんでもないが、そういう発想の行き着く先が人月商売・人海戦術・構成人員の質の低下という状態の肯定になっているような気がするんで、完全に同意はしかねる。
Re: (スコア:0)
もう少し書くと、日本の会社における凡人万能主義といえる錯覚は、
単に、雇った人間を良かれ悪しかれ使いつづけるしかないという固有の事情により、構成人員は使いやすい凡人が望ましいという状況を
後付で肯定しているだけだと思う。