マルチ・スレッド（multi-thread）プログラミングの落とし穴、その１（かもしれない）
ここのところ技術系ブロガーの間で話題になっている、「C10K問題（参照１、参照２）」は、ひとことで言えば、多くのウェブ・サーバーで採用されているmulti-threadやmulti-processに頼った（もしくは頼りすぎた）多重処理というアーキテクチャーのスケーラビリティに対する極めてまっとうな警告である。 この話は、決して最近になって始まった話ではなく、パソコン業界ではパソコンのOSにpreemptiveなマルチタスクが導入されはじめた９０年代の前半から、さらに遡ると、DECを中心にテクノロジーが進化したミニコンの時代から、ソフトウェア・エンジニアたちの間で盛んに討論されてきたテーマである（さすがに、メインフレーム時代の話は私は知らない）。 十数年を経た今でも、いまだに決着が付いていないこの問題は、私の大好きなテーマの一つでもあるし、もし私が博士号をこれから取得しようとするのであれば、
ひたすら読みにくいCコード:Geekなぺーじ
「The International Obfuscated C Code Contest」という面白いコンテストがあります。 1984年から行われているこのコンテストは、どれだけ読みにくいC言語プログラムを書けるか競うものです。 wikipediaでは、以下のように説明されています。 IOCCCとは「The International Obfuscated C Code Contest（国際邪悪なCコードコンテスト）」の略称。汚く読みづらいC言語コードをあえて書き、その汚さを競うというC言語ハッカーの奇祭である。むろんただ汚ければよいというわけではなく、目にした瞬間のインパクト、実行結果の美しさなど、さまざまな要因でアーティスティックなものが選ばれる。多くのコードはそもそも全くC言語に見えない。コード全体がアスキーアートになっているものなどが典型的である。 第一回大会は1984年に行われ、
String非推奨の勧め - minghaiの日記
Javaプログラムにおいて，クラスを作ることを厭う人たちが多い． そのような人たちの多くはデータを桁数依存にて構造が存在する文字列にして扱うことを好む． しかしJavaにおいてStringを解析することは多くの例外の原因となり，ひいてはシステム障害の原因となることが多い． またStringの演算は重く，Stringはメモリ消費量が多い． この文章では，Java利用システムにおいてStringの濫用を戒め，適切な型の利用と適切なクラス設計を行うことを勧める．*1 Stringの問題 多発する例外 Stringを利用することにより発生する例外には次のものがある． NullPointerException StringIndexOutOfBoundsException IndexOutOfBoundsException IllegalArgumentException UnsupportedEn
Lisp:よくある誤解と、その中にあるちょっとした真実
Lispについてのよくある誤解と、その中にあるちょっとした真実 はてなの質問: プログラミング言語で最強（スケーラブル）なのは、 Lispだと思われます。 http://jp.franz.com/index.html しかし、 世間ではマイナー言語のようです。 なぜでしょうか。 についた回答のいくつかには、「Lispを少しだけかじった人がしがちな誤解」が 含まれてるようなので、それをネタに少し解説してみます。 ただ、誤解が生じるのは、やっぱりそれなりの理由があって、従ってその 誤解の中にも(条件つきの)真実が含まれていることがあります。 そのへんまでをも含めて考えてみましょう。以降、引用は回答からです。 Lispはスクリプト言語? 一昔前まで、これらのスクリプト系の言語は「とてつもなく遅い」のが嫌われる最大の要因でしたが、最近のコンピューターの性能向上でようやくRuby,Python,Li
プログラミング言語"D"、待望のバージョン1.0登場 | エンタープライズ | マイコミジャーナル
Digital MarsとWalter Bright氏は2日(米国時間)、プログラミング言語D(D Programming Language)の最新版となるプログラミング言語「D 1.0」(以下、D言語 1.0)を公開した。D言語は同社によって開発されているプログラミング言語。C言語、C++、C#、Java、各種スクリプト言語などを参考にして開発されている言語で、さまざまな特徴を備えている。シンプルでかつ強力な機能を実現しつつ、Javaと違ってネイティブコードを出力できることからC/C++の次に位置付けられるプログラミング言語とみる向きもある。 2日に公開された1.0は、同社が提供しているD言語コンパイラDMD(Digital Mars compiler for D programming language)。WindowsとLinuxがサポートされている。同日、GCCに対するD言語フロン
Geekなぺーじ：C言語が嫌いな理由
「Why I hate C」という記事がありました。 私は個人的にはC言語が好きですが、C言語が嫌だという視点も面白いので要約してみました。 かなり削っているので詳細は原文をご覧下さい。 C言語は組み込みに使うには良い言語ですが、その他の99.9％のアプリケーションを作るには最適とは言えません。 現在、アセンブラが一般的なアプリケーションを書くための良い解では無いことは自明です。 ここでは、もはやC言語もそうでは無い理由を述べたいと思います。 C言語の最も大きな問題はプログラマが間違いを犯しやすい事です。 私も良く間違えます。 どんなプログラマであっても数千行のコードを書いてバグが一つも無いということはありません。 コード量が少ないということは間違いの数も少ないということになります。 C言語は、言語のデザイン上、より多くのコードを書く事を要求します。 また、新しく開発されたプログラミング言
Re: ＳＥの理想とプログラマの理想 - ブログは死なず、ただ放置されるのみ。
まなめさん。ＳＥの理想とプログラマの理想 でのご丁寧なお返事ありがとうございました。以下、私の考えたことを書かせていただきますが、ちゃんと書けているか正直自信がありません。まなめさんを含むみなさんで「何それ？」と思うような点があればご指摘いただきたく思います。 まなめさんの背景をご説明いただいたので、私の背景も少し説明させていただこうかと思います。 私の場合、まなめさんとは正反対で、ある日プロジェクトに突然つっこまれ、そこでミッションの概要を指示され、何とかする、というような仕事をここ数年やっています。行き先は、先の見えない新規案件だったり、メラメラ燃えてるデスマだったり、現状の品質やコスト面の改善を要求されるものだったりします。いずれも「行ってなんとかしてきて」という系統のものになります。 なので、この段階ですでに考え方に違いが現れるのは当然なことだろうと理解しました。 まなめさんがされ
ＳＥの理想とプログラマの理想 - 304 Not Modified
ksh Days - プログラマのスキルレベルに依存しない体制ができたらプログラマはいらないような気がする件についてにお返事。 あえて悪いほうに解釈すると『プログラマのスキルレベルに依存しない体制』って例えば、マニュアルどおりの対応しかできない人が頭数だけそろっても大丈夫な体制ってことでしょうかね。じゃあもしそういう体制ができたら、べつにプログラマじゃなくてもいいですよね。だってスキルに依存しないんだから。まあ、そこまでじゃなくて、じゃあ最低ラインスキルのプログラマさんたちだけ来ていただくことになるんですかね。 半分くらいは「はい」だと思っているのですが、正確に答えるならば求められるスキルが異なるといったところでしょうか。私の職場では、技術と呼ばれるスキルはほとんど必要ありません。反面、バグのないプログラムをどれだけ効率的に書くことができるかというスキルが求められます。決してバグがないこと
プログラマのスキルレベルに依存しない体制ができたらプログラマはいらないような気がする件について - ブログは死なず、ただ放置されるのみ。
ところで まなめはうすさんのところで、おそらく今年最後のひっかかり。 個人的に大規模ではSEに依存し、小規模ではプログラマに依存すると思う。だから、大規模でしか仕事したことのない私はSEが重要だと思っているんだよね。プログラマのスキルレベルに依存しない体制を作り上げることが最強なのです。 あえて悪いほうに解釈すると『プログラマのスキルレベルに依存しない体制』って例えば、マニュアルどおりの対応しかできない人が頭数だけそろっても大丈夫な体制ってことでしょうかね。じゃあもしそういう体制ができたら、べつにプログラマじゃなくてもいいですよね。だってスキルに依存しないんだから。まあ、そこまでじゃなくて、じゃあ最低ラインスキルのプログラマさんたちだけ来ていただくことになるんですかね。 SEとなってしまった自分にとって、プロジェクトでもっとも重要なことは「メンバの個々のスキルを適切に判断し、適材適所に配置
2006年のJava界の勝ち組と負け組 - ma2’s diary
2006 Java Technology Winners and Losers オライリーのOnJavaの記事。Eclipseは負け組かー。 と思ったら元記事が修正された。更新バージョンはこちら→http://d.hatena.ne.jp/ma2/20061225/p1 部門 勝ち 負け 開発環境 NetBeans IDE Eclipse JavaEEフレームワーク Spring Framework 2 JBoss Seam 1.x Eclipse Dali-JSF Eclipse WTP (JST-WST) JavaEE アプリサーバ GlassFish Java EE 5 Apache Geronimo ORマッパー Hibernate Webフレームワーク JSFとAjax（次点: RIFEとWicket） Struts 1.2.x スクリプト言語とフレームワーク GroovyとGr
美しいプログラムの美しくないソース : 404 Blog Not Found
2006年12月19日17:00 カテゴリArt 美しいプログラムの美しくないソース 半分だけ同意。 304 Not Modified: プログラマの美意識 私にとって美しいプログラムとは、シンプルなプログラムのことです。なぜ半分だけ、かというと、美しくない状況をより美しくすることがプログラムの使命であるならば、結果としてソースコードが美しくならないことも往々にしてあるから。 もっと身も蓋もない言い方をすると、この世の穢れをプログラムが背負う事もまたあるのだということ。 このことは、特にAPIを提供するソースを書くときに顕著だ。こういったプログラムに求められるのは、APIが美しいことであって、ソースコードそのものが美しいことではない。そこでは、さまざまな泥臭いことはAPIを提供するプログラムがかぶることで、APIのユーザーは醜いものを気にせずにプログラムできるようになる。 実装が美しいけど
『GOTOを使ってもいいんですか？』
悪態のプログラマとある職業プログラマの悪態を綴る。 入門書が書かないプログラミングのための知識、会社の研修が教えないシステム開発業界の裏話は、新人プログラマや、これからプログラマを目指す人たちへのメッセージでもある。 ある新人プログラマに質問を受けた。処理の流れをどう書いたらいいのか分からないという。 「GOTO を使ったらいいんじゃないの？」 「GOTO を使ってもいいんですか？」 なるほど、彼は GOTO を使ったらクビになるとでも思っているらしい。しかし、このケースでは、GOTO を使わなければ、既存の処理の流れを大きく書き直すか、かなり不自然な書き方をしなければ、目的を実現できなさそうだ。また、GOTO を使っても、コードがそれほど読みにくくなるようなこともないようだった。 「なるほど、どこかで GOTO を使ってはいけないと聞いたんだね。じゃぁ、なんで使ってはいけないと思う？」
凄いプログラマはバグを多数見つけられる:Geekなぺーじ
凄いプログラマな方がテストを行うと、大量にバグを発見してくれる凄いテスターになってくれます。 プログラミングには必ずデバッグという作業が入ります。 プログラミング経験が豊富な人が上手にバグを発見するのは、過去の経験からどこにバグが潜んでいそうか良く知っているからだと思われます。 「いや、良くそんな例外命令を突っ込んでみようと思いましたね」というようなピンポイント攻撃で、こちらの書いたプログラムを見事に撃沈してくれます。 凄いプログラマな人がホワイトボックステストをしてくれて、バグが潜んでいる行まで示して「バグってない？」と言われてしまうと「ごめんなさい。ありがとうございます。」以外に何も言えなくなります。 そのような方法でバグ指摘をしてくれると、何が原因でバグっているかを調べる時間が軽減されてコード書きが非常に迅速になります。 なお、プログラミングが上手であることが良いテスターの条件では無
プログラマがC言語を学ぶべき10の理由:Geekなぺーじ
「Ten reasons why every programmer should learn C」という記事がありました。 個人的な感想ですが、何と無く言いたい事はわかる気がしました。 ただ、多少誇張している(言い過ぎ/嘘)かなと思いました。 あと、恐らくLinuxとオープンソースなどを念頭において書いているんだろうなと思いました。 ちょっと言いすぎ感も漂う内容でしたが、面白かったので訳してみました。 誤訳や勘違いなどが入っている可能性があるので、詳細は元記事をご覧下さい。 以下訳です。 全てのプログラマはC言語を学ぶべきである。 C言語を学ぶ事により得られる利点は無視できないほど大きい。 C言語を学ぶ事により、仕事の機会に恵まれるだけではなく、コンピュータへの理解が深まる。 1) C言語は、C++やJavaと比べて低レベル(low level)な言語である。 低レベル言語を使ってプログラ
日経ソフトウェア2007年1月号 - perlはどこだ!? : 404 Blog Not Found
2006年11月24日17:30 カテゴリ書評/画評/品評 日経ソフトウェア2007年1月号 - perlはどこだ!? これ、私も頂いたのだけど... 日経ソフトウエア 2007年 01月号 日経ソフトウエア1月号 @ 2006年11月 @ ratio - rational - irrational @ IDM 日経ソフトウエア2007年1月号に記事を書かせていただきました。いろんなプログラミング言語からその言語の特徴的なところを学んでみようというようなお話の中で、Rubyを担当してます。 Perlはどこだ!? はっきりいって、ハブられているとしか思えないほど気になる不在なのだ。 pp.39-41の「こんなにあるフリーの言語処理系」にもない。その中の「定番スクリプト言語」は、PHP、Python, Ruby で、Perlという文字が登場するのは、そこのActivePerlに関する部分だけな
404 Blog Not Found:オブジェクトは難しくない。難しいのはクラス
2006年11月16日16:55 カテゴリLightweight Languages オブジェクトは難しくない。難しいのはクラス 大人だからオブジェクトは難しくなる。子供にとっては実はオブジェクトは自然で自明で簡単だ。 オブジェクト指向を正しく理解する：ITpro オブジェクト指向はしばしば，とっつきづらく難しい技術と言われます。その理由の一つには，対象とする分野が広く，それぞれに深みがあることが挙げられます。しかし，それ以上にこの技術を難しくしている落とし穴とも言うべき原因が二つあると筆者は考えています。それは比喩を乱用する説明の仕方の問題と，「もの中心」を意味するコンセプト自体の問題です。事実、オブジェクト指向というのは最初は子供向けだったのだ。 このことを、現在「オブジェクトとはなんぞや」という大人たちは忘れてしまっている。 それで、オブジェクトとは何か、といえば、「自分が何が出来る
Rubyの呼び出し可能オブジェクトの比較(1) - 世界線航跡蔵
Rubyにはコード片を表すオブジェクトが複数ある。 Method , UnboundMethod , Proc である。 Continuation は少し違うけど、実行コンテキストを記憶しているオブジェクトという意味では近いものがあるか。『 Ruby Way 』にはこういういろいろがあることについて「驚くほどのことではありません」と書いてあるけれども私は驚いた。で、これらが微妙に違うのだ。困ったもんだ。いや、便利なのかもしれないが。 それで今回はこれらの概要を眺めてみたいと思う。 普通のメソッド defでメソッドを定義するのが一番普通だやな。 class C def greeting(arg) puts "C#greeting reveived #{arg}" end def iterator yield 'iterator 1st' yield 'iterator 2nd' yield
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
perl/php/rubyなどLL言語のプログラマって日本に何人くらい居るんでしょうか？…
http://hiratch.net/blog/archives/2007/01/000146.html
プログラミング言語ヒエラルキー:Geekなぺーじ