Emacs Lisp のダメなところ - あどけない話
Emacs Lisp をこよなく愛する僕の目から、Emacs Lisp がダメだと思うところをまとめておきます。 文化的な問題 Emacs Lisper の多くは、Lisp が好きで使っているのではなく、Emacs が好きだからしかたなく使っているのでしょう。本当は C で書きたいのに、無理して Lisp を利用している感じです。 そのため、Emacs に付いてくる Emacs Lisp のコードは、Lisp らしくないものがほとんどです。単に C での発想を Lisp で表現しています。 これらのコードは、読みこなせないぐらい関数が大きく、副作用のある部分とない部分が分離されていません。また高階関数を用いて、データ構造を走査するコードと実際に仕事をするコードを分離するという意識も低いようです。 Google の MapReduceという論文のお陰で、Lisp の写像関数(map)と畳込み
PHP vs. X programming language
Being a new Zender I’ve spent some time in the recent past looking at people’s opinions about PHP now that it directly affects the work I do. In my research I have found a lot of interesting “opinions” about PHP vs. this that and the other thing, usually in the form of lists. “4 reasons why Java will outlast PHP”, for example. So, I figured I’d come up with a list of responses to the naysayers
Lisp:よくある正解
Lispについての正しい認識と、それでもLisperがLispを使う理由 yoriyukiさんのエントリがなかなか 真実を突いていたので、ネタにさせていただきます。 原因のほとんどは経路依存性とかネットワーク効果によるもので、Lisp自体の性質とは無関係だと思います。と言った上で、私が何となくLisp系言語を使わない理由としては、 Too dynamic: 実行時にコードが差し替えられることがすごい利点だ、と言っている人がいましたが、逆に言えば今どのコードが走っているか理解しにくい、という欠点にも繋がる。 Meta programming:S式のおかげでMeta Programmingがしやすいが、Meta Programmingを多用したプログラムは理解しにくい。 動的型付け:利点でもあるけど、特有のバグを引き起こす。 識別子に関数と値の2種類が別々にバインドできる。これは私には非常に美
なんでも継続
Shiro Kawai まだ下書き Schemeの特徴をあげるときに、「継続」や「call/cc」が出て来ないことはない。 でも、R5RSのcall/ccの項をいくら読んでも、どうもよくわからない。 call/ccを使えばC言語のbreakみたいなのとか、コルーチンとかいう スレッドもどきとかが書ける、というのはわかったけど、一体そういうのが書けて 何が嬉しいのか、そこんとこがピンと来ないんだ。 今、そこにある継続 プログラミングの世界の概念には、禅の公案のようなものがある。 それを説明する文章はほんの一文なのに、最初に目にする時、 その文は全く意味をなさない、暗号のように感じられる。 だがひとたびその概念を理解すると、 その概念の説明は確かにその一文で説明されているのがわかるのだ。 そんな、「分かれば分かる」という禅問答の中でも 「継続」は最も謎めいたものの一つと言えるだろう。 文献を
デモではものができあがっているように見せない
Kathy Sierra / 青木靖 訳 2006年12月27日 (アルファ版のような)開発中のものを私たちが世間や、クライアントや、ボスに見せるときには･･･彼らの期待のレベルを設定することになる。これは3通りの方法でやることができる。磨き上げられたモックアップで幻惑するか、プロジェクトの現状に合ったものを見せるか、ほとんどできていないものを見せながら順調に進んでいるから「信用しろ」と言っていら立たせるかだ。 結論を言うなら: どれくらい「できている」ように見えるかは、実際どれくらい「できている」かに合わせるべきだ。 ソフトウェア開発者はみんなそのキャリアにおいてこのことを何度も思い知ることになる。しかしテクニカルライターもまた、デスクトップパブリッシングツールによって同様の問題に直面する——フォントやレイアウトが完璧に仕上げられたドラフトを誰かに見せるなら、その人はあなたが考えるよりも
眠る開発屋blog｜最新オンラインカジノのニューカジノ情報
もしもこの世から「残業」が完全になくなったら ３年ぐらい前に読んだ本を思い出した。 １９８０−９０年代の話ですが、残業について、 「時間外・休日労働の弾力的運用が我が国の労使慣行の下で雇用維持の機能をはたしている」（１９８５年労働基準法研究会報告）とか、「我が国の労働慣行の実情に合うような上限設定が可能かどうか定かでない」（１９９２年同報告）と、雇用維持の為のコストとして恒常的な長時間労働を是認する考え方が主流でした。 需要の低下に応じて、生産水準を下げなくてはならなくなっても、バッファがあるから解雇せずに大丈夫でしょ、という。。。 まぁ、 ところが、その後、労働法政策が内部労働市場の雇用維持から外部労働市場における移動促進に徐々にシフトしていったにもかかわらず、この長時間労働哲学には疑問が呈されないまま２１世紀に至っているのです。 と著者は問題視しているわけだけど。 話変わって、最近友人
プログラマがC言語にこだわるべきでない0番目の理由 by Inquisitor
新しいプログラミング言語を作りたいと思ったら、そのプロトタイプはCのような低級言語ではなく、高級言語で実装したほうがいいのではないでしょうか。もちろん実行時のパフォーマンスなどのために、最終的にC言語で実装するということはあるかもしれませんが（相対的な話ではありますが、C言語を低級あるいは低水準と呼ぶのが許せないという人は、K&Rの1ページ目を参照してください。日本語訳では「はじめに」のp.2です。）。 Cは比較的“低水準”の言語である。この性格付けは非難の意味を込めているのではない。これは単に、Cが普通のコンビュータで扱う種類の、すなわち文字、数、アドレスを扱えるようになっているという意味である。もちろん、これらのデータを組み合わせて、現実の機械で実行されるような普通の算術論理演算でいろいろな処理を行なうことができる。(p. 2) 以下、本題 プログラマがC言語を学ぶべきたった一つの理由
ホワット・ア・ワンダフル・ワールド SQL とか全然知らないんですが
一応ルール型言語の研究者のはしくれとして違和感を感じたので． SQLに対する接し方 SQLは言語としては構造化以前のBASICレベルなので、複雑な事をさせたくない。1つのクエリが数十行あると、読みたくない。といって関数分けもできない。 ということで、複雑な処理は高機能な汎用言語上でやる。 SQL ってよー知らんのだけど，あれってまんま Prolog とちゃうん ? クエリの最適化かとも，Prolog プログラマならば誰でも無意識のうちにやってることだと思うしなぁ．なるべくバックトラックを減らすために，一気に探索範囲が絞られる順番にアトム (クエリ) を並べるとか． 逆に言うと，そういう下部の制御 (How) を意識しないといけないってのが，Prolog の (宣言型 (What) 言語としての) 致命的な欠点なんだけど．Java なんかに比べたら，はるかに高級な言語のような気が． まぁ，文
開発抽象化レイヤ - The Joel on Software Translation Project
Joel Spolsky / 青木靖 訳 2006年4月11日 火曜 若い男が町にやってきた。彼は見かけも悪くないし、ちょっとは金も持っていた。 過去のことについてはあまり話したがらないが、血の通ってない大企業に長くいたらしいことは明らかだった。 彼は生まれつき人当たりが良く社交的で、自分に自信を持っていながら傲慢ではない。だから地元のプログラマーズ・カフェにある求職の掲示の中からちょっとした仕事を見つけるのは、彼には簡単なことだった。しかし保険データベースプロジェクトや、主婦向けの飾りだらけのWebページや、会計計算エンジンといったものには、やがて興味をなくしてしまった。 １年もたつと、彼の慎ましい生計を1年支えられるくらいの蓄えができた。それで贔屓にしてくれるアルザス人へのコンサルティング仕事の後、食料品店の上にある自分のアパートの陽の当たる部屋にコンピュータを据え付け、選りすぐったツ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer
ソフトウェア開発の落し穴