アカウント名:
パスワード:
だいたい同じように変な人たちだと思ってたのですが、プログラムの公開を巡ってはだいぶスタンスが違うようですね。
もう少し掘り下げると、プログラムの品質(仕上げ)にスタンスの差がありそうです。
前の方の議論で、メモリリークが多少あってもアルゴリズムと結果が基本的にあっていればOK、という話がありました。研究であれば、作ったアルゴリズムとそれによって得られた結果が一番重要なので大きな問題ではないと思います。
対して商売プログラマ(エンジニア)になると、メモリリークがあるかどうかはレビューでまずチェックされるし、テストで発覚すれば(基本的には)直すことになります。そうしないと、客先でどんな惨事になるか分からないから。# もちろんあえて目をつぶる場合もあるとして。
公開するということは、その品質も当然さらされるので、プログラムとしての一定品質クリアを要とするか不要とするかのスタンスの違いはあると思います。
リクルーターのサポートをしていたときに、プログラマ志望の新卒さんにはよく、仕事はコーディングだけじゃないですよって話をしてました。「営業・MKTとの折衝」「仕様・設計のレビュー」「開発者テスト」「レグレッションテスト」「保守」研究職と職業プログラマではやはり仕事に違いがあるので。
個人的には「商売かそうでないか」の違いだと思いますよ。
商売人としてのプログラマは「バグがない(正しく動作する)こと」が最重要であって、それの不安材料になるようなものはすべて排除されてしかるべきだと考える。そもそもそうしたバグが結果責任として自分の生活に直結してるから尚更。
だから、「メモリリークしてるなんて初歩的なミスがあるプログラムなんて信用できるか!そんな信用できないプログラムが正確な動作してると誰が保証する!中身も見れないものを信用できるわけないだろ!」
ってなるんだと思います。
逆に研究者はプログラムにバグが出ようとぶっちゃけ結果がおかしかろうと、自分の生活が追い込まれるわけじゃないし責任を取るわけでもない。だから少々のリスクには目を瞑れる環境にいるわけで、そういう人はバグの存在による潜在的なプログラムの信用度の低さを考慮しなくて良い。(結果責任を取らなくてもよい)
なもんで、「メモリリークぐらいどーでも良いだろ、動くんだから。間違ってるかもって?誰か検証すればいーじゃん」
となるんだろうね。
まあ、仕事に対するスタンスと言うか、置かれてる立場が全く違う環境なんで、相容れることはないだろうけど。
>個人的には「商売かそうでないか」の違いだと思いますよ。
「自分が使うか、他人が使うか」の違いかも。 自分用に適当に組んだプログラムを使っている人は、/.(J)には多いかと思います。エラー処理は適当(でも対応できる)、わかっている不具合もある(けど回避できる)、UIは不親切(だけど気にしない)、それでも目的は達せられるので自分で使う分には問題なしとしている人は、私だけじゃないですよね?
自分の作業用に使う分にはね。そんなものの出力結果を論文に使おうとするほど、恥知らずじゃないけどw
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
科学者 vs プログラマ(エンジニア) (スコア:0)
だいたい同じように変な人たちだと思ってたのですが、
プログラムの公開を巡ってはだいぶスタンスが違うようですね。
Re:科学者 vs プログラマ(エンジニア) (スコア:1)
もう少し掘り下げると、プログラムの品質(仕上げ)にスタンスの差がありそうです。
前の方の議論で、メモリリークが多少あってもアルゴリズムと結果が基本的にあっていればOK、という話がありました。
研究であれば、作ったアルゴリズムとそれによって得られた結果が一番重要なので大きな問題ではないと思います。
対して商売プログラマ(エンジニア)になると、メモリリークがあるかどうかはレビューでまずチェックされるし、
テストで発覚すれば(基本的には)直すことになります。そうしないと、客先でどんな惨事になるか分からないから。
# もちろんあえて目をつぶる場合もあるとして。
公開するということは、その品質も当然さらされるので、
プログラムとしての一定品質クリアを要とするか不要とするかのスタンスの違いはあると思います。
リクルーターのサポートをしていたときに、プログラマ志望の新卒さんには
よく、仕事はコーディングだけじゃないですよって話をしてました。
「営業・MKTとの折衝」「仕様・設計のレビュー」「開発者テスト」「レグレッションテスト」「保守」
研究職と職業プログラマではやはり仕事に違いがあるので。
Re:科学者 vs プログラマ(エンジニア) (スコア:1)
個人的には「商売かそうでないか」の違いだと思いますよ。
商売人としてのプログラマは「バグがない(正しく動作する)こと」が最重要であって、
それの不安材料になるようなものはすべて排除されてしかるべきだと考える。
そもそもそうしたバグが結果責任として自分の生活に直結してるから尚更。
だから、
「メモリリークしてるなんて初歩的なミスがあるプログラムなんて信用できるか!
そんな信用できないプログラムが正確な動作してると誰が保証する!
中身も見れないものを信用できるわけないだろ!」
ってなるんだと思います。
逆に研究者はプログラムにバグが出ようとぶっちゃけ結果がおかしかろうと、
自分の生活が追い込まれるわけじゃないし責任を取るわけでもない。
だから少々のリスクには目を瞑れる環境にいるわけで、
そういう人はバグの存在による潜在的なプログラムの信用度の低さを考慮しなくて良い。
(結果責任を取らなくてもよい)
なもんで、
「メモリリークぐらいどーでも良いだろ、動くんだから。
間違ってるかもって?誰か検証すればいーじゃん」
となるんだろうね。
まあ、仕事に対するスタンスと言うか、
置かれてる立場が全く違う環境なんで、
相容れることはないだろうけど。
Re:科学者 vs プログラマ(エンジニア) (スコア:1)
>個人的には「商売かそうでないか」の違いだと思いますよ。
「自分が使うか、他人が使うか」の違いかも。
自分用に適当に組んだプログラムを使っている人は、/.(J)には多いかと思います。エラー処理は適当(でも対応できる)、わかっている不具合もある(けど回避できる)、UIは不親切(だけど気にしない)、それでも目的は達せられるので自分で使う分には問題なしとしている人は、私だけじゃないですよね?
Re: (スコア:0)
自分の作業用に使う分にはね。
そんなものの出力結果を論文に使おうとするほど、恥知らずじゃないけどw
Re: (スコア:0)
今日日めんどくさい並列化でしょうもないバグを作り込むことは日常茶飯事であるから、論文を書いたときに使ったコードくらいは見せてくれないと困るが故に
メーカーもシミュレーションの失敗で見込み性能を大幅に下回るものをリリースしたりキャンセルしたり(例 PPC615)という疑いが濃厚であることもあるが故に