プログラミング言語の優秀さと道具としての評価は別 - kなんとかの日記
ワシは、cgi.rb なんかが標準添付になっている Ruby に PHP を dis る資格はないと思ってる (cgi.rbの元ネタである CGI.pm を擁する Perl も同じじゃないかな)。cgi.rb は、標準添付モジュールのくせにコードが汚いし遅いし、cgi[] の戻り値が String だったり File だったりするし、どう考えても設計ミス。 ## Ruby だと cgi = CGI.new p cgi['name'] #=> これが File である可能性がある ## PHP だとそんな問題はない $name = $_REQUEST['name']; # 必ず文字列 $file = $_FILE['name']; # ファイルは別途取り出すそして大半の Rubyist はこういった問題に気づいてすらいない。そういう人たちが PHP を dis ってるのは「ハァ?」と思う。
プログラミング言語の速度とアプリケーションの速度がいかに関係ないかがわかるグラフ - kなんとかの日記
まずは次の表をご覧あれ。これはプログラミング言語のベンチマークとして有名な Computer Language Benchmarks Game のベンチマーク結果。上にいくほど高速で、下に行くほど遅い言語になる。 これを見れば、最速な言語は C/C++ であり、Java や Haskell や OCaml といった静的な言語は軒並み上位に登場する。これに対し、Ruby や Python や PHP といったスクリプトは全部下のほう (つまり遅い)。その速度差は非常に大きく、このベンチマークで見ると Python3 や Ruby1.9 は C/C++ の約50倍から60倍遅く、Perl は約90倍、PHP にいたっては約130倍遅いことになる。 (ちなみに JIT つきの Lua が驚異的に高速なのが目をひく。この結果が本当だとしたら、言語の速度に大きく関係するのは動的か静的かではなく、どれ
スクリプト言語の息の根を止めるのは案外 SSD かもな - kwatchの日記
大変たいへん興味深い記事。全プログラマーにとって。 HDDの代わりにSSDを利用したら、リレーショナルデータベースの性能はどれだけ向上するのでしょうか？ オラクルと富士通が共同検証を行い、その結果をホワイトペーパーとして先週発表しました ...(snip)... HDDは200スレッドで性能が頭打ちなのに対し、SSDは200スレッドから300スレッドになってもまだ性能は上昇。ただし、300スレッド時にはCPU利用率が100％に近づいており、先にCPU性能の方がボトルネックとなってしまったようです。 HDDをSSDにしたらデータベースはどれだけ速くなるか？ オラクルと富士通が実験 － Publickey 動的なスクリプト言語 (Ruby や Python など) と静的なコンパイル型言語 (C++ や Java など) では、だいたい 5 倍から 10 倍ぐらいの速度差がある。それでもスクリ
PHPとJavaScriptはスクリプト言語の範疇に入らないかもしれないんだってさ - kなんとかの日記
（追記: 2009-11-16: 引用元のブログは「SH2の日記」のコメント欄からであり、SH2氏とは別の方のコメントです。） さすがはJava屋さん。スクリプト言語をバカにする態度は堂々としたものだ。 JavaBlack >PHPなどのスクリプト言語もいつでもかけるようにしとけよってね それは全く逆でしょ．PHPプログラマの方が，JavaやPerlなどの汎用言語を使えるようになっておかないとだめ．PHP「しか」書けない人は，本物のプログラマーじゃない． そもそもPHPやJavaScriptについては，スクリプト言語の範疇に含めるべきか否かという問題さえある． http://d.hatena.ne.jp/sh2/20091106#c1257524055 PHPしか書けないと、なんで本物のプログラマ―じゃないことになるんだろう。 例外機構もないPerlは汎用言語と認めているのに、PHPはそう
HTMLコーダーやWebデザイナーをバカにしているプログラマーは全員腹切って死ね - kなんとかの日記
デザイナーとプログラマーの間に優劣なんかない。あるのは役割の違いだけ。なのになんでHTMLコーダーとかデザイナーとかをバカにするプログラマーが多いのかサッパリわからない。 HTMLコーダーやWebデザイナーをバカにしているプログラマーは全員腹切って死ね。 web業界にも様々な職種があり、最近では分業化も進んでるみたいだが、 だからって「自分はHTMLコーダーですから、プログラミングには興味ありません」は通用しない。 HTMLコーダーやデザイナーも、プログラミングは勿論サーバーやネットワークの知識を持つべき。 まぁデザイナーは別業界でもある程度潰しがきくかもしれない。 プログラミング知らないHTMLコーダーがダメな理由 なんでやねん。なんのために仕事が分かれていると思ってんねん。デザイナーがサーバやネットワークを知らないといけないような状況って、プログラマーがクソなだけだろ。 そんないうんや
『相手をしない勇気』って、それ勇気じゃなくて逃げてるだけじゃん、何カッコつけてんの? - kなんとかの日記
NOV1975さん、自分から仕掛けておいて、そんな幕引きはないんじゃないですか? 『30倍からだいぶ縮まりましたな。』とか『小規模プロジェクトしか経験ないのかなあ。』とか好き勝手言っておいて、しかも『あとで本気で書く。』とまで宣言しておいて、なに逃げてんですか? 好き勝手言われたこっちの身にもなってくれませんかね。 傍から見ていろいろとはっきりしているのに相手をしていると、どうも言わなくていいことを言ったり、苛立ちからか観客にとっても不愉快な態度をとってしまったりというようなマイナス面のほうが目立ってきてしまいます。 相手をしない勇気 - novtan別館 なにがどう『はっきりしている』んですか? 少なくともこっちはハッキリもスッキリもしてないんで、いい加減質問に答えていただけないでしょうか。 『ようはあなたが望む体制はスーパープログラマーに選ばれないってことじゃないの？』ってどういう意味
公務員より技術力が低いSEって大変だよね - kなんとかの日記
2億円が800万円で済んだって話。 「IP電話を導入する場合のベンダーの見積もりは約2億円だった。アナログ交換機を更新する場合でも費用は約2000万円。しかし自分たちで敷設することでサーバーは20万円，電話機500台は800万円で導入でき，電話料金も年間400万円削減できた」---秋田県大館市産業部商工課商業労政係主事の中村芳樹氏は，IP電話導入の経緯と効果をこう振り返る。 見積もり2億円のIP電話を820万円で構築した秋田県大館市から学べること | 日経 xTECH（クロステック） で、ベンダー側の人間の弁解。 ベンダーに頼むということは、ベンダーが仕事をするということです。仕事をするというのは什器をマージンを取らずに買ってきて敷設してくれるということではありません。適正な利益(これは市職員が自分で出来る程度のことだから安いというわけでは必ずしもありません)を取ること自体は商行為として当
Re: スーパープログラマーは生産性がスーパーなわけではない - kなんとかの日記
まーた「スーパープログラマー」に反応しちゃってるよこの人。 ようはあなたが望む体制はスーパープログラマーに選ばれないってことじゃないの？ スーパープログラマーは生産性がスーパーなわけではない - novtan別館 文章の意味がわかりません。ワシの頭でもわかるように書いてください。 そもそもの前提として、業界は今現存する(あるいは将来生まれる)スーパープログラマーで全ての需要が満たされるというものが成立しないと、属人性を排除して均質化および全体の質の向上を図るという戦略が間違っているとはいえないから。 なんでそんな前提が必要なの? 単に生産性の高い人の能力を引き出す、というだけの話になんでこんな前提が必要となるわけ? 僕はともかくdankogaiにそれいっちゃいかんだろｗｗｗ Dan氏じゃねーよ、キミのことだよ。「スーパー」とか「天才」とかに過敏に反応しているキミのこと。 それは捉え方が間違
従来のソフトウェア工学が決定的に間違っている点 - kなんとかの日記
従来のソフトウェア工学は、属人性を排除して開発者の能力を均一化しようとしている。この点に置いて、従来のソフトウェア工学は決定的に間違っている。 ソフトウェア開発では、個人の生産性は上と下とで 30 倍違うと言われる。これが本当だと仮定したら、これだけ差がでるものを均一化なんてできるわけない (したところで間違った結論しかでない) んだから、属人性を排除することは大きな誤りである。 仕事が高度になればなるほど、属人性は排除できないし、人材の替えはきかない。問題を解決できない人間を100人集めても、問題は解決できない。問題を解決できるのは、問題を解決できる能力を持った人間だけ。頭の悪い大人100人より、すごく頭のいい小学生1人のほうが、成果物が出る。ソフトウェア開発はそういう類いの仕事。 よく、ソフトウェア開発を工場での作業に例える人がいるけど、これも「属人性を排除できる」という勘違いからもた
「大規模プロジェクトではどうするか」を考えるより、「大規模にしないためにはどうするか」を考えよう - kなんとかの日記
はっきり言おう。大規模プロジェクトは存在自体が悪。 続けて同氏は、ケーパース・ジョーンズ氏の著書「Patterns of Software System Failure and Success」から調査結果を引用し、大規模プロジェクトになればばるほど、当初の見積もりとは大きくかい離したものになり、かつ失敗する可能性が高いことを示した。「（一般的なプロジェクトも含めた調査結果でさえこれなのだから）デスマーチについては推して知るべし」とヨードン氏。 エドワード・ヨードン、デスマーチを成功に導く対症療法を説く - ITmedia エンタープライズ (強調は筆者による) うむ。言っていることはごくあたりまえのことではあるが、ヨードン氏が言うと説得力がある。 調査結果の抜粋。FP（ファンクションポイント）はジョーンズ氏が定義している単位で、1FPが100行程度のコードであるという。1FPであればほぼ
マスゴミ屋さんとJava屋さんの区別がつきません（もちろん部分集合） - kなんとかの日記
すでに取り消し線が引かれているけど。 結論 アンチ Java の人が多い理由が分かった気がする。 何でかといえば そーゆーのって、個人に依存するのかなーとか思っていたのですが、界隈での共通の意見なんだね。何というか、一種の宗教性や強迫観念を感じた。もし、これから、Ruby（もしくは、Rails 経由で Ruby）を始める人がいて、次回以降の RubyKaigi2009 に参加しようと考えている人がいたら、まじめに、勉強してから行くことをおすすめする。俺にとっては、結構トラウマものだったな、まじで。 ...(snip)... ただ、『Java は、近代の言語。Ruby は、現代の言語』で会場中が爆笑できるほどの状況ならば、Java をフィールドに活動している人間にとっては、気持ちいいものではない。 http://d.hatena.ne.jp/yuta4839/20080622#1214155
Java における本質的でない記述がどのように大規模開発に役立つのか - kなんとかの日記
まじめな話に切り替えて、Java屋さんJava信者さんに質問したいと思います。 質問: Java における、本質的でない冗長な記述は、どのように大規模開発に役立つのでしょうか。 質問の背景を説明すると、以前の晒されエントリで、Java における本質的でない記述の数々について話題にしました。それに対する反応で、『Java は大規模開発向けだから記述が長くてもいいんだ (または長くなくてはいけない)』という意見が多くあります。 たとえば、ブックマークコメントより: エンタプライズ分野であの大伽藍が求められたのだから仕方ないですよ。 エンタープライズ分野のような大規模開発こそ、必要な情報を簡潔にわかりやすく記述する必要があると思ってたんですが、世の中は違うようです。 同じくブックマークコメントより: Java屋の怠慢は高層ビル建築をどうサボるかであって、犬小屋を作る時にどうサボるかという視点とは
小飼弾のフェイントテクニック - kなんとかの日記
ひがさんの、ちょっと前のエントリ。 ボクシングの内藤選手は、フェイントの達人です。ここにパンチを打ち込むぞーと目線を合わせているのと、まったく違う部分にパンチを打ち込むことができるのです。これは、超高度なテクニックで、達人にしかできないそうです。 弾さんのつっこみも、おんなじ感じですよね。何かを引用しつつ、別の部分を掘り下げるっていう。今日、やっとこれは、内藤選手のフェイントと同じなんだと気づきました(笑)。 例えば、「誰が書いても同じコード」は大事なことなのかの私のエントリ。これに対して「同じコード」の同じって何さとふって、TAPをすすめるって言うフェイント。 ついに永和の秘密を公開 - 受託開発の極意のエントリに関しても、極意より作品を - 書評 - 受託開発の極意で本の中身より「何を作ったか」を焦点にするフェイント。 フェイント後の話が面白いから成り立つテクニックだと思うんですが、最
「怠慢はプログラマの美徳」というけれど - kなんとかの日記
Java屋Java信者とスクリプト言語屋の間には、「めんどくさい」と感じるセンスについて超えられない壁が存在している。 本質的でない事柄に関する記述があったときに、スクリプト言語屋は「めんどくさい」と感じ、Java屋Java信者はそれを感じないか、または「これは必要な冗長性だ」と本気で思い込んでいる。 前にとり上げたけど、アクセッサの記述がその典型例。本質的でない記述がずらっと並んでいることに、Java屋Java信者はホントに何も感じないのだそうだ。あれがどれだけ readability を下げているか、まったく分かっていない。 また System.out.print() もそう。たかが print 文のくせして、なんで System.out.print() と書かないといけないのか。本来であれば、Java1.5 のタイミングで package java.util; public clas
Java が使いにくいのは静的だからではない - kwatchの日記
Java が使いにくい言語であるというのは、世界中の LL ファンが皆思っていることだろうから改めていうことでもないけど、使いにくいのは静的言語だからというのは間違っている。Java が使いにくいのは単に Java の設計者のセンスが悪かっただけであり、静的言語のせいではない。 たとえばこんなコード。 public Map<String, List<String>> example() { List<String> list = new ArrayList<String>(); list.add("foo"); list.add("bar"); list.add("baz"); Map<String, List<String>> map = new HashMap<String, List<String>>(); map.put("names", list); return map; }
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
