「科学者が書いた質の低いコードが、ベストプラクティスに則ったコードに勝る理由」？
ちょっとだけ．
うーんと，要するに釣りタイトルだな．
「ベストプラクティスも知らないヘッポコなんちゃって糞プログラマもどきが書いた糞コードが，（非プログラマの）科学者が書いたコードよりも酷くなることがある」というだけの話．もちろんそういう糞プログラマはベストプラクティスなんて全く理解してないし，使いこなせるわけがない．
- 並列処理に関するバグをまったく考慮しない（ツールの使用によりほぼ100パーセント回避可能）。
お気づきだと思いますが、こうしたミスならすぐに修正できます。
ダウト．*1
他はともかく*2，並列処理はアルゴリズムレベルから見直さないと修正不可能なことも多いし，そもそもバグがあることさえ検出できないことがある．「ツールで検出」ってどんなツールだ．仮に可能でも，ごく初歩的な特定のバグ限定の話じゃない？*3
ところがソフトウェア・エンジニアの犯すミスは、全然異なるタイプのものなので、そう簡単にいきません。
- 多重継承や仮想継承など、行き過ぎたクラス継承。
アホか．いまどき多重継承しまくるなんて，ド素人でもやらんわ．
それは「ソフトウェア・エンジニアの犯すミス」じゃなくて，「ヘボプログラマが犯すミス」でしょ．
- まぎらわしいネーミングの多用。ドライバ・コントローラ、コントローラ・マネージャ、ドライバ・マネージャ、マネージャ・コントローラ、コントロール・ドライバと、きりがない。すべて同じものを指している。
これも「ヘボプログラマが犯すミス」だな．「ソフトウェア・エンジニア」といえるほどのスキルの無い人．*4
ここで一つ、あまりに真理を突いているので省略するにしのびない、ささやかな見解をお伝えしましょう。それは、怠惰は大きなトラブルの原因であるということです。
えー．
- id:id:John_Kawanishi Programmerの三大美徳は･怠惰（Laziness）･短気（Impatience）･傲慢（Hubris）
Laziness: The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful and document what you wrote so you don't have to answer so many questions about it.
http://d.hatena.ne.jp/JavaBlack/20130730/p1
科学者は、科学で頭がいっぱいなので、いたずらにコードを複雑にするひまがありません。一方、多くのプログラマは、仕事に対して本質的な意義など感じていません。たかが仕事です。だから彼らは時間を持て余しています。
「科学者が科学で頭をいっぱいにしている」のなら，なんで「プログラマがプログラミングで頭をいっぱいにしている」ということに気付かないのだろう？もちろん結論も大ハズレ．
The Low Quality of Scientific Code
http://techblog.bozho.net/?p=1423
元ネタより．
The general feeling is that scientific libraries have mostly bad code. I will not point fingers, but there are too many freshman mistakes ? not considering thread-safety, cryptic, ugly and/or stringly-typed APIs, lack of type-safety, poorly named variables and methods, choosing bad/slow serialization formats, writing debug messages to System.err (or out), lack of documentation, lack of tests.
「科学者は，一般にこんな凄い糞コードを書いてる」という話．*5 *6
On the other hand these libraries have a lot of value, because the low-level algorithms will take even more time and especially know-how to implement, so just reusing them is obviously the right approach. Some libraries are even original research and so you just can’t write them yourself, without spending 3 years on a PhD thesis.
コードは糞でも，その背景にある研究に基づくアルゴリズムは価値のあるものであることが多い．
But that’s only the surface. Scientists in general can’t write good code. They write code simply to achieve their immediate goal, and then either throw it away, or keep using it for themselves. They are not software engineers, and they don’t seem to be concerned with code quality, code coverage, API design. Not to mention scientific infrastructure, deployment on multiple servers, managing environment. These things are rarely done properly in the scientific community.
科学者は自分の研究が実証できる最小限の機能さえ動けば良いので，そこがゴール．プログラマとしては，そこはスタート地点という違いもある．
しごく冷静で真っ当な指摘．
http://b.hatena.ne.jp/entry/postd.cc/why-bad-scientific-code-beats-code-following-best-practices/
- id:atsushifx 作成するソフトウェアの規模と複雑さを考えないと意味がない。プログラミングをよく知らない科学者が質の低いコードを書くのは仕方ないが、グローバル変数ばりばりなコードとかは後で地獄を見る。
- id:zz_sexy 単純なことを複雑に書いて自分がうまいと思ってるヘタクソが無駄に複雑にしたコードならその通りだと思うが、ヘタクソがヘタクソに書き散らかしたコードはそれはそれでメンテする人が泣いてるんだよ。
- id:inazakira ベストプラクティスのバグにあげられたものが本当にサイエンス系のプログラムに必要なの？聞きかじりで不要なテクニックを使おうとして失敗してない？KISS原則を知ってるプログラマならやらないような事ばかりな予感
- id:knjname コピペコードのほうが理解しやすいと言われているのとかわらん気がする
- id:terazzo 生煮えの方が料理の味直し易い的な。
ついでに味付けもしてないと完璧ですね．でもそれは料理人失格ということでもある．
*1:翻訳ミスという可能性はあるけどね．．．
*2:他も不可能ではないにせよ，楽とは限らん．
*3:そもそも普通の科学者が並列プログラムを書けるとは思えん．
*4:日本企業だと普通だけどなー．orz
*5:日本企業の専業プログラマでも，このレベルのヤツはいやがりますけどね．死ねばいいのに．
*6:stringly-typedというのは初めて見たが，まあだいたい予想はついた．そういう糞コードをデバッグしたことあるし．引数も戻り値も基本が文字列型！日付をDBに入れる時も全部文字列型！馬鹿だろ死ねよ． http://tech.a-listers.jp/2012/07/25/new-programming-jargon/
