言語の設計判断This document contains code snippets in Python, Perl, and C++. It also contains text about Marcus Tullius Cicero and Otto von Bismarck.Read less
不完全にしてかなり言葉足らずな比較プログラミング言語学 - 西尾泰和のはてなダイアリー
プログラミング言語は人が作ったもの。人は誤るもの。なので完璧なプログラミング言語は存在しない。 「人は誤るもの、しかし誤りに固執するのは馬鹿の所業だ。」(キケロ) プログラミング言語も、間違った設計をして、馬鹿でない人がそれを修正することの繰り返しで発展してきた。 というわけで言語間での設計判断の食い違いとか失敗した設計とかを収集中。一部抜粋して講義資料に入れるつもりなので他の事例をご存知でしたらぜひ情報をいただけるとありがたいです。 if(x = 0) C言語では代入が式であるためif(x == 0)のつもりでif(x = 0)と書いてしまい、常に偽になってしまう。 x = 0の値はint、条件式はboolでないといけないので型エラーだよ派: Java x = 0は式ではないので条件式に入れたら構文エラーだよ派: Python 条件式にx = 0をいれたらx == 0と解釈するよ派: H
最悪なHello World | Happy My Life
To all who Think Themselves a Programmerより。 サンフランシスコのある会社での求人なのだが、この会社では書類選考として、どの言語を使用してもいいので最悪なHelloWorld(画面にHello Worldと表示させるだけのプログラム)を書いてもらい、それを採用基準にしている。 最善のコードではなく、最悪な手法で試すとはなかなか面白い。言語選びなどでも個性が出るので、その人の潜在的なスキルが試される。日本じゃこんな手法を採用している企業なんて少ないよなぁ。 採用された例 原文より抜粋して掲載。変態的(褒め言葉)なHello Worldの世界へご招待。 その1 y = lambda { |f| lambda { |x| lambda { |n| (f.call (x.call x)).call n } }. call lambda { |x| lambd
a = a + 1; /* って違和感あるはずなのに */ : 404 Blog Not Found
2009年07月10日15:00 カテゴリLightweight Languages a = a + 1; /* って違和感あるはずなのに */ ここまでは、いい。 だれでもわかるプログラミングの教え方もある……といいな - 狐の王国 じゃあ「c = a + b」はどうなるのか。 これはcという新しいバケツを用意し、aとbを足した数字を入れろという意味だ。ところが、 a = a + 1; でまともに数学を習った人ならつっかかるはずだし、実際つっかかるなのに、ほとんどの言語が代入演算子として=を採用しているのはなぜなのだろう? いや、私だってこれがFORTRAN由来だってことは知っている。私が知りたいのは、これが数学から見ても自然言語から見ても不自然なのに、ことプログラミングに関しては、なぜこれが自然になってしまったか、ということ。 代入に、=を使う必然性が全くないことは、それを使わぬ言語も
コードレビューって意味あるの ? | スラド デベロッパー
「こういうコードが恥ずかしいコードである」 という価値観について、上級技術者間で意識統一がなされていればね。 ようするにコードレビューと言うのは、大学の研究室で言う輪講とかと同じなんです。 コードをよりよいものにする、と言うのも目的の一つですが、コードを組んだ人のレベルアップを図る、という目的もある。 十分な人数の、良く判っているプログラマがいるならばペアプログラミングも良いでしょう。でもペアを組んで回れるほどレベルの高い人がいなかったら? 「教授と助教授と助手の目の前で発表させる」 しかないじゃないですか。 もちろん、この作業は「教授や助教授や助手」の時間を食います。もしあまりにも多くの時間を食うのであれば可能性は次の３つのどれか。 初心者が多すぎる。そのため、「教授や助教授や助手」の時間をフルに使っても、全部など到底見切れない。コードの品質は悪いままである。初心者が少なすぎる。コードの
伽藍とバザール - Wikipedia
『伽藍とバザール』（がらんとバザール、英: The Cathedral and the Bazaar、カテドラルとバザール）は、エリック・レイモンドによって書かれたオープンソースソフトウェア（OSS）のソフトウェア開発方式に関するエッセイおよび書籍である[1]。 当記事では、Cathedralの訳語に伽藍、Bazaarの訳語にバザールを使用する。訳語については、「Cathedral」の日本語訳の節を参照されたい。 伽藍方式としてGNU Emacsの開発スタイル、バザール方式としてLinuxカーネルの開発スタイルとFetchmailのマネージメント経験を挙げ、ソースコードを常時公開して多くの利用者・開発者がソフトウェア開発に携わる開発手法のメリットを主張している（「ソースコードを常時公開して多くの利用者・開発者がソフトウェア開発に携わっている」、という点はGNU Emacsでも後者と全く同じ
流れるようなインターフェイス - ぐるぐる～
なんか単に this を返せばいいって思っている人も多いようけど、ただ this を返せばそれが使いやすいかって言われると、正直微妙。 例えば、 public static class StringUtil { public static SubstrInfo Substr(this string str) { return new SubstrInfo(str); } public sealed class SubstrInfo { public SubstrInfo From(int from) { ... return this; } public SubstrInfo To(int to) { ... return this; } public SubstrInfo Length(int length) { ... return this; } } } なんてクラスは、 "hoge
サンプルを丸写ししてもプログラムの理解は出来ない - 遥か彼方の彼方から
雑記プログラムの勉強をするのに、参考書を丸写しして勉強するという方法があります。はっきり言って、あれはほとんど意味がないと思う。無意味とまでは言わないものの、中途半端に「頑張った感」を味わえるので気をつけた方がいいのは間違いないです。個人的には、丸写しするくらいならただ読むだけの方がいいとも思っています。 じゃあどうすればいいのかっていうと、プログラムの勉強をするときは参考書と少し違うことを書いて勉強するのがいいかなと思います。 最初にどうしようもないことを言うと、プログラムなんて書いても覚えないんですよ。漢字や英単語をたくさん書く練習だって怪しいのに、ましてやプログラムです。参考書を丸写しにしたから指が覚えているなんてことは、特殊能力の領域です。そういえばモンスターのルンゲ警部はキーを叩くことで頭の中のフロッピーディスクにデータを記録していましたね。それに、暗記そのものには意味なんてない
テスト駆動開発とClean Code: 柴田 芳樹 (Yoshiki Shibata)
テストファースト開発では、テストコードを最初に書いて、そのテストが通るように実装を行っていきます。そうすると、ひたすら実装しているだけで、従来のデバッグという感覚はなくなります。そして、すべてのテストが通るようになれば実装が完了となるわけです。この場合、テストコードが必要なテストをすべて記述していることが重要です。 最近の教育や講演でも述べていることですが、「すべてのテストが通るようになったら実装が終りではない」と話しています。ソフトウェアエンジニアに求められるのは、すべてのテストが通った後に、コードをリファクタリングして、できるだけクリーンにすることです。 実際、テストは通っているが、コードは汚いものを見かけます。担当者は、テストが通ったので実装が終わったと思ってコードをコミットして終りにしているのです。あるいは、テストが通った後に、コードを見直してできるだけクリーンにする作業をしたのか
「射程」を長くする | おごちゃんの雑文
ちょっとデスマっていたので、雑文を書く暇がなかった。 何をやっていたかと言えば、MONTSUQIのデータベースレイヤにつながるODBCドライバを書いていた。当然ターゲットはWindows。 実はこれは私が産まれて初めて書いたWindows上のプログラムだ。つまり、 初めて書いたWindowsのプログラムはODBCドライバ だということ。と言えば、Linuxを入れて初めて作ったプログラムはキーボード用のデバイスドライバだった。 件の仕事(仕事だ)をするまでは、私はただの一行も、Windows上のプログラムは書いたことがなかった。どれくらい書いたことがないかと言えば、Windows上ではそもそも 「メモ帳」以上のエディタを持っていない のだ。まぁそりゃ原理的にはメモ帳でもプログラムは書けるはずだけど、とても「快適なプログラミング環境」とは言えないだろう。それに「Windowsのプログラムって、
プログラマーの開発速度は「はまる」時間の長さで決まる : 小野和俊のブログ
プログラミングを始めてから今日に至るまで、 様々なタイプのプログラマーと開発を共にしてきたが、 驚くべき速度で高い品質のソフトウェアを作り上げるプログラマーには、 一つ共通の特徴があるように思える。 それは、「はまる」時間が極端に短い、ということである。 風のプログラマー」を指向しており、開発速度を重要視している。 例えば平成14年未踏ソフトウェア創造事業「PICSY」では、 発表直前に知人でプロジェクトリーダーの鈴木健にレスキュー隊として呼ばれて 2,3日でGUI全般と、クライアント/サーバー通信部分の設計と実装を終わらせたのだが、 このときなどは、大体の要件を口頭で聞いた後は、 ほぼまったく手が止まらずコードを書き続ける感じで開発をしていた。 「はまる」時間の長さは開発速度に直結するわけだが、 プログラマーが「はまる」場合にはある程度の傾向があると思うので、 今日は「はまる」プログラマ
Shibu's Diary: きれいなソースコードを書けるようになるためには
渋日記@shibu.jp 渋川よしきの日記です。ソフトウェア開発とか、ライフハックを中心に記事を書いていきます。 by chazmatazz 「構造のきれいなプログラムを書けるようになるためにはどうすればいいのか？」という質問を受けたので、「はて？どうしているだろうか？」と考えてみました。あ、形式知にきちんとなっているようなテクニックみたいなもんじゃなくて、モノローグなので、あまり凝ったものは期待しないように。あ、Pythonに限定してますが、他の言語でも似たようなものはあると思いますので、脳内変換をお願いします。 事前の設計はしません 「こういう処理が必要」「こういう計算しなきゃね」みたいなロジックや「要件はこうかな？」ということは事前に考えたりするけど、クラス構造とかは基本的に考えないで手をつけます。そして、ある程度規模が大きくなって「あ、ちょっとこの関数大きすぎて理解しにくいなぁ」と
プログラマーの誇りを見せ付けろ - レベルエンター山本大のブログ
僕は今回の案件で、システムのレスポンスに徹底的にこだわってる。 それには理由がある。 それは、プログラマの誇りを見せたいからだ。 この案件は、既存機能をコピーして似た機能を作るというものだ。 既存機能は、Webシステムなのに1アクションで 1分や2分以上のレスポンスタイムはザラで、 悪いときには数分後にタイムアウトして、 さらに悪いときには、アプリケーション全体をロックしてしまっていた。 顧客はそれでも我慢して使っていてくれたそうだ。 今回の改修に際して、顧客がパフォーマンスを要求するのは当然だった。 それにしても酷いアリサマだとコードを見てみると 酷い。 確かにパフォーマンスは出ないのも無理はない。 いや、それどころか僕は、このSI業界の問題を感じざるを得なかった。 この機能はそこそこ難しく、業務的にも重要だ。 しかし、そのコードは、新人〜3年目ぐらいのプログラマが書いたとしか思えないコ
カプセル化、情報隠蔽、データ隠蔽 - ぐるぐる～
あちこちのサイトを見てると、間違った解釈をしてるのが多い。カプセル化なんて、情報隠蔽まで含んでるのが常識になりつつあるような。。。ここまで一般化してると情報隠蔽してるのがカプセル化というのが常識なのかも。 カプセル化・情報隠蔽・データ抽象化 - 今日の役に立たない一言 − Today’s Trifle! − カプセル化と情報隠蔽、データ隠蔽の違いがよくわからくなったので、手持ちの本で調べてみた。 基準 基準としては、 カプセル化、情報隠蔽、データ隠蔽の関係 カプセル化は隠蔽を含んでいるかどうか 対象はクラスのみか、そうでないか などなど。 一番目はそのまんま。二番目は、 // 隠蔽せずともカプセル化か class Hoge { int hoge; // なんかhogeを使うメソッド } // 隠蔽しなければカプセル化ではないか class Piyo { private int piyo;
ウノウラボ Unoh Labs: 並行プログラミング
ウノウでは特に最近、積極的にエンジニアを採用しています。 採用ページをご覧になり興味のある方、ぜひご応募ください！！ Find Job!でも募集開始してます！ うちだです。おそらく今年最後のエントリーとなります。 今回は飲みの席でのネタになるような「平行プログラミング」の概念的な部分のご紹介です。高橋メソッド風味で書いているので説明が少ないですが、よろしければ見て下さい。 平行プログラミング
正直「半可通」にしか見えませんが orz - がるの健忘録
元ネタはこちら。 中途半端に優秀なプログラマが「正しいプログラミングテクニック」だと妄信しがちな３つポイント http://d.hatena.ne.jp/fromdusktildawn/20081026/p1 ああ先に。 ここは極論を楽しむ劇場です。プロフィールページをよく読んで、真に受けたり鵜呑みしたりしないように気をつけてご鑑賞ください。 という部分については「意図的に」オミットしています。 横にあるプロフィールを「誰もが見てる」とは限らんでしょ？ っつか。「わ〜いこいつネタに釣られたよゲラ」で、書いてる人は楽しいかもしれませんが。 それを真に受けて痛い目に遭う技術者とか現場の事を考えると、私はこれを「ジョークである」ではとても流せません。 他人に害をなし傷付ける冗談を笑えるほど、私は○○(字数制限なし。お好きな言葉を入れてくださいませ)ではないつもりなので。 で、本題。 「変数のスコ
ソフトウェア開発の「自由の悲劇」 : 小野和俊のブログ
クリエイティブな仕事というのはある意味で残酷だと思う。 なぜなら、 つくりあげたものが評価に値しないものだった場合に、 自由にできる環境があったのに、 この程度のものしかできなかったのかという批判が 本人に対して直接的に向けられやすいからだ。 というような話を耳にすることがあるのだが、 「誰でもいいからお金を出すので好きにつくってよい」 という状況はほとんど考えられないわけで、 もし本人の希望がかなった結果、 大したものを生み出すことができなければ、 自分には新しいものを生み出す才能がないのではないかという 悩みに直面することになる。 もちろん、中には自分自身でソフトウェアを次々と開発して、 ダウンロード数やアクセス数、メディアで取り上げられた記事などを印刷し、 この企画を会社の事業として採用しないか、 と持ちかけてくるような強者もいる。 だがそういう人でさえ、注目を浴びたソフトウェアの影
プログラム言語に「わくわく」なんていらんでしょ | おごちゃんの雑文
ひがさんのblogより。 Rubyにワクワク感以上に求めるもの Matzの寝言へのつっこみだから、多分信者があれこれ書くんだろうなぁ。あ、でもひがさんのblogはJavaの信者多いから、それ程でもないか。 今回は「私が知っているMatz」ベースではなくて、「みんなの知っているMatz」ベースの話。 ひがさんが後半で「わくわく感」についてつっこんでいる。 ワクワク感は、これまであったことのないものに触れたときに、感じることが多いと思いますが、仕事で使うときに、これまで出会ったことのないものが、いつもたくさんある状態は困るわけです。 私も同じことを考える。Rubyな人達はよく「わくわくする」とか言うけど、それは勘違いの気のせいだよ。そうでなかったら、それはまだその言語が実用として身についてないからだよ。 「わくわく」ってのは、未知のものに触れる時の感じるもの。これから入る世界への期待が「わくわ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
コードレビューのレベル感で悩んでいます 質問と回答(Q&A) [okyuu.com]
Google Code Archive - Long-term storage for Google Code Project Hosting.