  |
はてなキーワード: 処理系とは
世の中「プログラミング言語」を説く本はごまんとあれど「プログラミング」を説く本やブログはあまりない。
いや実際に "ない" というのはかなり語弊があるかもしれない。
しかし、通常この種の説明している本に辿り着くまでには多くの時間が必要だ。
普通の人は、多くの間違った方法を試し、その都度試行錯誤を重ね、プログラミング経験を経ることよって、重要な概念を獲得するのだと思う。
例えば、「計算機プログラムの構造と解釈」や「実用 Common Lisp」、「コンピュータプログラミングの概念・技法・モデル」などの書籍は現実の問題に対し "プログラム" をどう書くかという問題に正面から取り組んでいる良書だ。
しかし、どれだけ”普通の”プログラマが上記のような書籍を読んでいるのだろうか。
そして、"普通のプログラマ" がプログラミングを学ぶ書籍として、それらは果たして適切と言えるだろうか。
僕はそうは思わない。
というのも、多くの人は計算機科学を学び、効率のよいアルゴリズムとデータ構造、美しい階層化・モジュール化されたプログラム、などを作るためにプログラミングするのではない。目の前の問題を解決するためにプログラミングを行うからだ。
授業で出された宿題だったり、人それぞれだろう。
このような目の前の問題を解決したい人達が、わざわざ Lisp や Mozart など何の役に立つのか分からない言語を、根気よく勉強するのだろうか。（ちなみに、Lisp や Mozart は上記の書籍で実際に使われている言語である。）
新しいプログラミング言語を学ぶことや、プログラミングの種々の概念を獲得することではない。
もちろんプログラミング言語を上達するためには一つでも多くの概念を会得する必要があるので、あるレベル以上を目指すのであればこれらの書籍を読むことや、抽象化を実現するための様々なツールを手にすることは必須だと思う。
純粋にプログラミングを楽しんでいる人やハッカーを目指したい人はこのような文章を読むのではなく、ぜひ上記に挙げた本を実際に購入し、自分の手で動かして確かめてみることを勧める。プログラミングに対する考え方や姿勢が変わるのは間違いないと思う。
今回はそのような”純粋にプログラミングを楽しんでいる人”に向けた文章でない。
現実の問題をプログラミングを用いて取り組んでいる人に向けて書いた文章だ。
そのような人の中で、なかなかプログラミングが上達しないという人に向けた文章である。
もしプログラミングの学習に限界を感じているのであれば、プログラミングの学習方法が間違っている可能性が高い。
そして残念なことに、初学者向けの書籍では、"プログラミング言語の文法" を説く本はあれど、"プログラミングの学習方法や上達するための正しいスタンス" を説く本はほとんどない。
できるだけ多くの人にプログラムをする楽しみを知ってもらうためにも、
より多くの人がより生産的にプログラムが出来るようになるためにも、
そして特に、右も左も分からなかったプログラミングを始めたばかりの過去の自分に対して、
効果的な学習方法やプログラムする際の指針を書き記したいと思う。
それらは単に指針を示しているだけなので、
どんなプログラミング言語を使っていようとすぐに実践に移せるはずだ。
後はどれだけそれを実践に移し地道にプログラミングしていくだけである。
正しい努力と、ちょっとしたコツさえ知っていれば驚く程生産性を挙げられるはずだと確信している。
プログラマのレベルを以下の 3 つに分けてそれぞれについて説明していきたい。
・使えるプログラミング言語は一つだけ
ただし以下のことは出来ない。
・500行以上のコードが書けない
2. 中級者レベル
・1つ以上のプログラミング言語は使える
・オブジェクト指向は理解している
ただし以下に当てはまる。
・自分が制作しているアプリケーション向けに "実用的なフレームワークやライブラリ" を書けない
・1万行以上のコードだとスパゲッティコードになり、保守不能になる
・適切なサブルーチン化できない
3. 上級者レベル
・プログラミング歴 3 年以上
・現実の問題に対して適切なデータ構造とアルゴリズムを選択できる
・抽象化について理解し、可変部分と不変部分を考慮した設計ができる
またそれぞれのレベルをクリアするには明確な壁がある様に思う。
これらの壁を超えるにはどうすればよいかを説明する。
前置きが長くなったが、以下ではまず初級者レベルの人に向けた具体的なアドバイスをする。
完全に初心者レベルの人はまずどのようにプログラミングを行えばよいのか分からない。一行も書けない。そのため、必然的に以下のような行動を取ると思う。
・本に載っているプログラムをそのまま書き写す（いわゆる写経）
上のような行動を行なっているだけでは、いつまで経っても自分でプログラミングが出来るようにならない。
なぜなら上記のプロセスでは決定的に重要なことが学べないからだ。
それは、【プログラミング言語のモデル】を自分の中に作ることである。
それは普通の言語と同じように文法が存在し、そのしきたりに沿って記述しなければならない。
そのしきたりを学べば書けるようになれる。非常に単純だ。
それなのに、なぜいつまで経っても書けないのか？
それは、”書き写す・コピーする” だけでは、そのしきたりが習得できないからである。
特に最初のうちのプログラミングは頭を作業使う作業でなく、むしろ "体で覚える" 類のものである。
それは例えば、日本語を話すことと似ている。
友達と会話する時、頭を使っているだろうか。
それは簡単な受け答えについては体が覚えているので、考えるより先に日本語が出てくるのではないだろうか。
プログラミングも同様に頭を使うのではなく、こうしたい時はこう書く、という反射神経を育てなければならない。
もちろん日本語話せるだけでは、ミーティングでプレゼン出来ないのと同様に、文法が出来ただけではプログラミングが出来るとは言えない。しかし、文法が出来ないと "現実の問題に対処するソフトウェアを作る" というレベルには到底進めない。そのために、まずそのような文法の反射神経やパイプラインを頭の中に作る必要があるのだ。
・"何をしたい時" に "どう書けば正しく動くか" というデータベース（プログラミング言語のモデル）を自分の中に作ること
このままでは抽象的すぎるので、このような "データベース" や "考える習慣" を自分の中に作るための具体的な指針を以下に挙げる。
1. エラーをたくさん出す
2. デバックの仕方を覚える
3. 小さく動かして確かめる
4. Google を使い倒す
つまり、小さく動かして、エラーをいっぱい出し、デバッグを素早く行なって、分からないことは google などの検索エンジンで解決する。これが上達のコツである。
これらについては以下で詳しく説明するとして、
無理して覚えなくてよい。
プログラマは覚えることが星の数ほどあるので、メソッドなどはリファレンス片手に検索できればよい。
よく使うメソッドなどについては自然に覚えていくので、積極的に覚える必要はなし。それこそ、"体" で覚えるはずである。
覚えられないメソッドについてはそもそもあまり使わないから覚えられないので、重要性は低く覚える必要はない。
むしろ実現したい処理が既にメソッドや関数として提供されていないか、調べる力の方が大事。
・エラーがいっぱい出てつらい
全く問題ない。
・写経をしなければならない
教科書や本の中に書いてあることをそのままエディタで書き写し、実行することを写経という。
上記でも述べたように、これからあまり無駄な努力をしないことを願って言えば、
写経して書いた 10000 行のプログラムより、自分で考えて書いた 100 行のプログラムの方が遥かに意義がある。
そこに "言語のモデル" や "思考" が伴わないと意味がない。
”思考” が伴わないとただの書き写す作業をしているだけだ。
自分の中に "モデル" が出来ていないので、いざ自分でプログラミングしようと試みても、写経をしているだけでは全く書き出せないだろう。
写経はそもそもプログラミングに対するスタンスやプロセスそのものを勘違いさせる危険性をはらんでいるいる。
写経する場合、書き写しの間違いがなければプログラムは問題なく動く。
しかし実際のプログラムではコンパイルや実行するまで、そのプログラムが期待通りに動くかどうか、は絶対に分からない。
そして通常は一気に全てを書き上げるのではなく、まず小さなコア部分を書き、少しずつ他のコア以外の部分を書き上げながらプログラムを完璧なものにしていく。
書き間違えさえなければ正しく動くと知っているプログラムを、上から一行ずつ書いていくプロセスとは正反対だ。
また、以下で述べるようにエラーが発生した場合のデバッグ作業は非常に重要であるだが、そのための作法も写経から学ぶことができない。
なぜならば、写経中にエラーが発生した場合、教科書と自分で書いたプログラムの間違い探しをまず一番最初に行うからだ。これはプログラミングに関する作業ではなく、むしろ間違い探し絵本とにらめっこしているに近い内容である。
それでは、デバッグ方法や言語のモデルを作るとても大切なプロセスを経験できない。
ゆえにそのようにして完成したプログラムもおそらく正しく動きはするが、得られる経験値は驚くほど低いはずである。
とは言え、いきなり自分で書けと言われても書けないと思うので、小さなプログラムを一旦は教科書通り写し、その後自分なりに改変していくのがよいと思う。この場合も写経にはほとんどが意味がないと思った方がよい。"自分なりに改変する" というプロセスこそ意味がある。
今度はどのように "言語のモデル" を自分の中に作っていくかについて説明する。
初心者はエラーを出さない様にと慎重にプログラミングしようとしがちだ。
なぜならば、エラーを出すごとに、その言語の新しいルールを１つずつ学んでいくことになるからだ。
PHP で例えると、
printf の書式だとか
文末に付けるセミコロンだとか
function はネストできないとか
変数には $ を付けなければならないだとか
グローバル変数を関数の中で使う場合は global 宣言するとか
などである。
初心者のうちは一切上のようなルールは知らないはずだからエラーを全て踏むかもしれない。
例え今回作っていたプログラムでエラーを踏まなかったとしても、回数をこなしていけばいくつかエラーに遭遇するだろう。
しかし、それでよいのだ。
エラーを修正することの繰り返しの中で、その言語のモデルが自分の中に出来てくる。
そのようなトライアンドエラーを繰り返えすことで、"言語のモデル" は文字通り体の中に染み込み、プログラムをだんだんと書ける様になっていく。
おそらくこれはは自転車に乗れるようになるプロセスと似たようなものだと思う。
誰しも最初は上手く走れずに転んでばかりいるけれど、何度も何度も転んで起き上がってを繰り返しているうちに少しずつ多くの距離をこげるようになっていくだろう。
そして最終定期には、難なく自転車を乗りこなせるようなっている。
それらのエラーを地道に１つずつ潰して間違いを訂正していくうちに、少しずつ多くの行数の複雑なプログラム書けるようになっていく。
そして最終的には、自由にプログラミング言語を使いこなせるようになっていることに気付くだろう。
自転車も本を読んだだけで乗れるようにはなれないのと同じで
プログラミング言語も本を読んだだけで出来るようになれると思わない方がよい。
それらはトライアンドエラーの繰り返しの中でしか得ることはできないし、誰かから教わる類のスキルでもない。
そして、プログラミングを行うからにはエラーとは一生付き合っていかなければならない。
早めにそれに気付いて受け入れる必要がある。
実際にエラーに遭遇した時に大事なのはエラーに遭遇した時にいかにその原因を突き止めるかだ。
期待しない動作をした時のデバッグという。
まずいちばん基本的で一番重要なデバック方法は printf デバックである。これをまず出来るようにする。
怪しい変数をとにかく printf で出力し、変な値が入っていないかを確かめる方法である。
僕が常々許せないと思っていることは、初学者向けの書籍にはデバッグの重要性やその具体的な方法論が非常に重要であるにも関わらず、それについては解説すらされていないことである。
初心者だからこそ、デバッグの方法論や開発環境をきちんと整えるべきである。
ほとんどの言語処理系では、デバッグ作業を支援する機能を提供している。
分からなければ、"言語 デバッグ方法" でグーグルで検索してみればよい。
例を挙げると、
javascript だったら firebug
各言語にはいわゆる"定石"と言われるデバッグ方法があるはずで、それらを検索し習得すること。
これは無益な時間を過ごさないためにも本当に重要な要素なので、面倒くさがらずに開発環境を整えや方法論をマスターすること。
最初の内は、基本的にプログラミングする時は小さな部品に別けてから1つずつ確かめながら作る習慣を付けるようにする。
その理由は簡単で、人間は正確無比に物事を進めるのは苦手な一方で、プログラミングでは正確無比に物事を進めることを要求されるからである。そのため、大きなプログラムを一度も実行せずに作成し、一気に確かめようとするとまず間違いなく正しく動作しない。
そして厄介なことに、大きなプログラムを作ってしまうとどこに問題があるのか切り分けすることが困難になるので、ますますデバックが難しくなってしまう。
そのためまず小さく作って小さく確かめ、部品を組み合わせてプログラムを作っていくことが大事になる。
一般的に言って、どんなに熟練したプログラマーであろうとも、一つのミスもせずに一定以上の大きさのソフトウェアを作り上げることは不可能である。そのため、ミスやエラーはある程度発生することを前提に、少し作っては実行して確かめる、というサイクルをたくさん回す習慣を付ける。
ソフトウェアは一行書き上げた瞬間から指数関数的に複雑性が増大し、気付いた時にはどうにもならなくなっていることも多い。そういう時は思い切って一から作り直すという選択肢も検討してみるべきだ。
"Small is Beautiful"
これは非常に有名な unix （という OS）の設計理念である。
unix の開発者は様々な失敗経験から、このようなソフトウェア開発のベストプラクティスを学んだに違いない。
まだプログラミング経験の浅い人も、これから偉大な開発者の経験から学ぶことができるはずである。"Small is Beautiful"。小さく作って動かすこと。
先ほどから何度も書いてあるように、プログラミングする上ではエラーとの付き合い方が非常に重要になってくる。
おそらく何らかの上手くいかない場合は何らかのエラーメッセージが出るはずだ。
原因がどうしても分からない場合は、エラーの文章をそのままコピーして検索してみる。そうすると、おそらくエラーの原因と対策方法などが表示されるので、それを足がかりに再度挑戦する。
現実のプログラミングは、どんなにスキルが伸びようとも、いつも上手くいかないことばかりだ。それこそ、何をしてもエラーが出てくるし、何をしても上手く動作しない。だから僕は初心者のうちで一番大事な能力とは、実は "忍耐力" だろうと少しばかり思っている。
でも悩んでるのはあなただけではなく、おそらく全てのプログラマーが通ってきて道だ。
そして、自分の思い通りに動くプログラムを見た時程うれしいものはない。
ぜひ初心者の人はこれを読んで少しでもプログラミングが出来るようになればと思っている。
つ
なぜかLINEでのやりとり。このあとTwitterでblockされた。
| A | hi |
| B | yeah |
| B | 学校祭わろた |
| A | おつ。 |
| A | 打ち上げ的なものはないの? |
| B | ない |
| B | 今学校祭中 |
| A | ああ、把握。わろたがおわたに見えた。 |
| B | 学校祭ェ•••• |
| B | パソコン部の展示なう 誰もけえへんやん |
| A | なるほど |
| B | パソコン部だけ学校祭雰囲気じゃねーww |
| A | そんなもんや… |
| B | あっちで音ゲー こっちでぽけも |
| B | 君もパソコン部かい？ |
| B | 友達こねーくそわろ |
| A | んにゃ、高校のときは※※と〒〒やってたねえ。 |
| B | 学校祭の新しい形ですね |
| B | 学校祭なんてお客さんが楽しむもので、生徒が楽しむものではない、生徒は楽しませる側です |
| A | 僕んところの高校のパソコン部とか何やってたんだろうねえ。 |
| A | Twitterとか見てると灘校のパソコン部展示とかは相当盛り上がってたみたいだけど。 |
| B | 君は神学校出身かい？ |
| B | 灘高は秀才やから |
| A | いや、ずっと公立だね。 |
| B | つくこま のパソコン部もハイレベルやで |
| B | 偏差値は？ |
| A | 僕の偏差値? 学校の入試偏差値? |
| B | 私は地方の進学校(笑)です |
| B | 学校と君の |
| A | 同じく地方の進学校ってとこだね。もっとも田舎だから高校入試は大した競争はないんだけど。 |
| B | 数学できんねやろ？ |
| A | 入試偏差値はさすがに新聞か高校入試情報誌のバックナンバーあたらんとわからんなあ。 |
| B | というか君札幌じゃん |
| A | んにゃ、札幌じゃないけど。 |
| B | え北海道？？ |
| A | 北海道。 |
| B | むろらんさかえ？ |
| B | くしろちょうりょう？ |
| A | ノー。 |
| B | かいせい？ |
| B | あさひがおか？ |
| B | 東西南北 |
| B | ？ |
| B | どれ？ |
| B | 帯広はくよう？ |
| A | ちゃうねん。 |
| B | どこ？ |
| B | 西？ |
| A | 柏葉とか〒〒強かったなあ。 |
| B | W |
| B | 君×高？ |
| A | No. |
| B | 俺×高www |
| B | わろたqwwww |
| B | ×高わろたwww |
| B | ×高わろわろわろたwwww |
| A | なにがおもしろいｗｗｗｗ |
| B | 君は？ |
| A | (そもそも高校生ではないんだけどね…) |
| B | 中学生？大学生？ |
| A | 大学出てるよ |
| B | 出身高どこ？ |
| B | 北海道ではないの？ |
| A | △△。 |
| B | もれ札幌×高。知ってる？私服やで！ |
| B | △△？ |
| A | 私服やで。 |
| B | △△高校？？ |
| A | yes. |
| B | ▲▲系？ |
| A | とは |
| B | 画像 |
| B | 偏差値67わろた ●●県かー |
| A | それ●●の男子校な。 |
| A | ●●の△△はたぶん私服じゃないぞ |
| B | ●●神やな |
| B | 何県？ |
| A | △△市知らんのか… |
| B | 画像 |
| B | しってるで！ |
| B | 理数科？ |
| A | 普通。 |
| B | なんで私服、 |
| B | ？ |
| A | なんでって言われても、校則に制服がないからだけど。 |
| B | わろた |
| B | この話やめよ |
| A | ( なんでいきなり学校の訊問から始まったんだ…? ) |
| B | Htmlの話にかえよう |
| A | うむ。 |
| A | で、HTMLって何さ? |
| A | 何だと思う? |
| B | はいぱーてきすとまーくあっぷらんげーじ 絵や歌と一緒で自分を表現するもの |
| B | メディア |
| A | ほむほむ。 |
| A | 「まーくあっぷ」って何? |
| B | 表現メディアの一種 |
| B | 記すこと |
| A | んー |
| A | じゃあ、ハイパーテキストは? |
| B | 特殊効果付属された文字列及び画像 |
| B | 及び記号 |
| A | 特殊効果とは? |
| B | 色つき、アニメ、 |
| B | この問答に終点はあるんですか？ゴールがみえてますか？ |
| A | ん、取りあえずHTMLがわかってないと話にならんしね。 |
| A | 満点はつけられないけど及第点じゃないかなー、と。 |
| B | はいぱーてきすと はネットにつながるやつですか |
| B | てへぺろ |
| A | 「ネットにつながるやつ」が正確な表現かどうかはともかくとして、それはハイパージャンプ。ハイパーテキストの特徴。 |
| B | ハイパーテキストとは |
| B | 模範回答 |
| B | は |
| B | なんや |
| B | なんやーなんやーなんややややややややややややや |
| A | 「ハイパーなテキスト」 |
| B | んーなるほど |
| A | 要するに、ただのテキストを超えてる。 |
| B | ○○高校のクズがおるで |
| A | って概念。 |
| B | 後ろに |
| B | それで |
| A | でだ、そこで |
| A | HTML5って何? |
| B | なんや |
| B | テキストを超越したものを創造するための道具 |
| A | No. |
| B | なんや |
| B | プログラミング言語 |
| A | そういう名前の「マークアップ言語」ってだけの話なんだけど。 |
| A | プログラミング言語ちゃうねん。 |
| B | しっとるわ |
| B | でいいたいことは？ |
| B | 要旨はなんや |
| A | 「マークアップ言語」ってことが重要。 |
| B | はい |
| B | それで |
| A | 言語であるからには規格があって処理系がある。 |
| A | ってことはおｋ? |
| B | うん |
| B | 規格？ |
| A | 規格。 |
| B | 処理系？ 説明せぇ言われても説明できない言葉やわ |
| B | おしえで |
| B | おしえてー |
| A | 要するに、"print A" って文字列を与えたら "A" って出力するような仕組。 |
| B | それが処理系 |
| B | きかくは？ |
| A | ざっくり言うとそう。 |
| A | 言語が言語として成立するための決まり。 |
| A | さっきの例だと "print A" なら「Aを出力しろ」という命令であるべし、みたいな。 |
| A | HTMLの場合は基本的には要素と属性の定義になってる。 |
| B | あーわかります |
| B | いえーす |
| A | 要素と属性はおｋ? |
| A | element と attribute 。 |
| B | 要素 属性width height |
| A | おｋ。 |
| B | 要素が親 属性が子 |
| A | それはちゃうねん。 |
| B | じゃあなんや |
| A | でもそれは脇道だから置いておく。 |
| B | いいす |
| B | いえす |
| B | そして |
| B | からの |
| B | からの？ |
| A | てっとり早く言うなら、HTML5で定義されてる要素の集合に font や center は入ってない。 |
| B | ふむ |
| A | 集合は? |
| B | じゃあそれらはなんや |
| B | ドモルガンの法則 |
| B | 要素の集まり |
| A | おｋおｋ。問題ないね。 |
| B | なめてんのか、て感じですよ |
| A | で、つまるところ何を見て font とか center を使ってんのよ、ってことになる。 |
| B | しらん |
| B | 理由なくても動くから |
| B | ね |
| A | ってことは、HTML5を知ってることにはならん、と。 |
| B | た(^-^)/な |
| B | だね |
| A | "理由なくても動くから" niceだね! |
| B | だろぅ？ |
| B | ワイルドだろぅ？ |
| B | で使っちゃダメな理由があんの？ |
| A | さっきの話に戻すと、HTMLの処理系って何? |
| A | いっぱいあるよ！＜だめな理由 |
| B | 命令の内容とそれに対応する文字 |
| A | ノー。 |
| B | なんや |
| B | ユーザーの命令に対してのコンピュータが処理する内容 |
| A | 入力に対して応答する「仕組」が処理系。 |
| B | しすてむ |
| A | nice |
| B | 入力に対して応答する仕組み=処理系 |
| A | 日本語の「系」は "system" に対応する。 |
| B | おつす |
| A | で、HTMLを与えて、それをよしなに処理してくれるシステムって何? |
| B | 処理系 |
| A | 具体的には? |
| B | Htmlの処理系 |
| A | HTMLの有名な処理系は何? |
| B | html5 |
| A | それは規格。 |
| B | やー |
| B | こんぱいらー？ |
| A | コンパイラも処理系。 |
| A | (の一部 |
| B | Htmlの処理系てなんや |
| B | コンピュータ |
| A | 大雑把すぎる |
| B | cpu |
| A | ノー。 |
| B | めもり |
| B | なんやねん |
| A | ノー。 |
| B | Os |
| B | web |
| B | ブラウザ |
| A | iPhoneにもWindowsにも処理系が入ってるからWebが見られる。 |
| A | 正解。 |
| B | プレインストールされてすか |
| A | されてるね。 |
| B | なるほどね |
| A | 「HTMLの有名な処理系は何?」の模範解答は InternetExplorerとかMozilla FirefoxとかOperaとかGoogle Chromeとか。 |
| B | で |
| A | で、どうして規格を守る必要があるのか、の話。 |
| B | ブラウザの名前をあげればいいんですね |
| A | それはもう終った。 |
| B | exactly |
| B | ね |
| B | で |
| A | HTML5では文書の先頭に って書くことになってるけど、これはどういう意味か。 |
| B | 宣言 |
| A | DOCTYPE宣言 |
| A | 宣言してるのに規格守らなかったらだめじゃん |
| A | やーいうそつきうそつきー、ってことになる。 |
| A | (まじで |
| B | どういうこと |
| B | Doctype宣言してんのにcenter、fontを要素として使うのはだめだということですか？ |
| A | 「HTML5の」宣言してんのにcenter、fontを使うのはだめー、ってこと。 |
| B | へー |
| A | HTML 4.01 Transitional とかならおｋ。 |
| B | 規格守らないとどういう弊害が？ |
| A | おｋだけど、なんでそんな古いの使ってんのや、ってことになる。 |
| A | あらゆる意味でめんどくさい。 |
| B | で |
| B | 規格守らないと誰か困るの？ |
| A | ユーザも困るし、処理系を作るひとも困る。 |
| B | なんで？ |
| A | 困ったちゃんは絶滅しないから有名な処理系は古い規格をサポートし続けることになるのは確定的に顕かなんだけど。 |
| A | たとえばちょっと処理系を自作しようとしたときに規格を守ってない文書に当たると、例外的な処理をしなければならなくなる。 |
| B | 新しいhtmlの規格がでても 古いバージョンのサポートをやめられないのですか |
| A | そんなことをしたら、君のページを表示できるブラウザがなくなるよね。 |
| A | (HTML5のサポート外の要素を使ってるから |
| B | なるほど |
| B | center、fontに変わる要素はなんや |
| B | 何を使えばええんや |
| A | そもそもそれを要素で指定するのがナンセンスである、って話になってくる。 |
| A | つまり「中央揃え」とか「フォント」とかって意味の要素がナンセンス。 |
| B | 最初Css使ってたけど他人のコードよんでfontていうやつ見つけたんで使ってみた |
| A | 「他人のコードよんで」←まちがい |
| B | cssでcolor: ; |
| A | 「規格書を読む」←せいかい |
| B | 辞めてfont color使うことにした |
| B | 他人のページのソースコード読んででええやろ |
| A | 赤の他人はだいたい間違ってる |
| A | (僕の言ってることも間違ってる可能性があるから規格書を読むべき |
| B | なんや |
| B | 表現が間違ってるわけじゃねぇんだよな |
| B | そういえや |
| B | 規格書をよめってことか |
| A | 暇なときにね |
| A | html5.jp とかで良い。 |
| B | web |
| B | なるほどね |
| B | 偏差値nn |
| B | ？ |
| A | ? |
| B | 君の偏差値は？？ |
| A | さあ |
| B | 教えてや |
| A | そもそも偏差値の基準とは |
| B | 模試の偏差値とか教えて |
| B | 偏差値の基準は？？？ |
| B | 偏差値の基準？なにをいいたい？ |
| A | 模試って言われても高校出て何年も経ってるから数値自体に何の意味もないんだが。 |
| B | 君は賢いかどうか知りたいだけよ。それを知るために偏差値は聞きたい |
| B | はを |
| A | 僕が賢いかって言われたらそりゃ賢くはないねえ。 |
| B | 俺より？ |
| B | プログラミングの大会とかでたことある？？ |
| A | 偏差値が良ければ賢いって価値判断がそもそも相当賢くない気がするんだけど。 |
| A | プロコンは趣味程度にもやってないね。 |
| B | ぉーわかってないねー |
| B | 賢い奴は、学校の勉強くらいできるのよ |
| B | 学校の勉強程度はってことね |
| A | さっきの偏差値nnって何の数字? |
| B | プログラミング技能と偏差値関係ねぇはずだけど、優秀なプログラマーは有名大学出身ばっかさ |
| B | ん？ |
| B | んとね 君の高校の偏差値ね |
| B | 今のね |
| A | 把握。 |
| A | 「優秀なプログラマーは有名大学出身ばっか」の統計的根拠はあったりする? |
| B | ない。俺が感覚的に感じた |
| B | アメリカね |
| B | れいおじー |
| A | 「実際に会った優秀なプログラマと出身大学の関係」とかでも良いんだけど。 |
| B | レイ オジー、マークザッカーバーグ、ビルゲイツ、ポールアレン、 |
| B | 下村努 |
| B | スティーブ ウォズニアック |
| A | おお、そりゃあ有名人だ。 |
| A | で? |
| B | こいつら全員アメリカのトップ高校ばっか |
| B | なんや、小さい頃から理系型天才エリートか、。？ |
| A | そもそもその世代は有名な大学にしかまともな計算機がないんだけどね |
| B | 日本Google、グリーの幹部は東大東工大京大の情報工学ばっか |
| B | なんだ、理系エリートか |
| B | なんやー |
| B | そういうことかー |
| B | 所詮 有名企業は高学歴の巣窟か、 |
| A | ってことで、勉強がんばれ |
| B | 君はこの事実をうけとめられるか |
| A | そういうもんだからねー |
| B | 学生のうちは勉強をすべきなんだ....... |
| B | だから勉強を.........!!!!!! |
| A | するべき。 |
| A | 僕はまともに学校の勉強はしてこなかった人間だからねー |
| B | しろわ |
| B | しろやいま |
| A | んー、いまさら大学入試受ける予定もないしねえ。 |
| B | 君どんな仕事してんの？ |
| A | 自宅を警備するお仕事をしてるよ☆ ってTwitterのbioにも書いてる |
| B | ニート |
| B | か |
| A | こんな夢見がちな大人になっちゃいけないよ☆ |
| B | 仕事する予定は？ |
| A | ないない |
| B | しろや |
| B | 家でなにしてんの？ |
| A | お勉強 |
| B | なんの？ |
| A | SICP |
| B | 親が生活費だしてんこ？ |
| B | だしてんの？ |
| A | んにゃ、自分のお金でだけど |
| B | ふりーたーか？ |
| B | アルバイトはしてる？ |
| A | ないない。アルバイトなんてしたら自宅を警備できないしね。 |
| A | そんな大人になっちゃいけない |
| B | 自分の金てなに？お前が稼いだ金？ |
| A | いえーす |
| B | どこで？ |
| B | 働いてないのに |
| A | 不思議だ… |
| B | お前なんやねん |
| B | 何者やねん |
| A | 自宅警備員 |
| B | ばか？ |
| A | Twitterのbioに書いてる以上でも以下でもない感じ。 |
| B | ごみ？ |
| B | 社会のゴミ？ |
| A | 少なくともいまの君よりは計算機科学に詳しい、ってことでおｋ? |
| B | おーけー |
| A | ってことで、こんな社会のゴミなんか秒速で追い抜いてみせろ、ってことでひとつ。 |
| B | まあ俺がお前の歳だったら、お前より知識あるがな。俺×高やし、北大いくし |
| A | おーすごいすごい。 |
| A | さっきの学歴を持ち出すなら北大じゃいろいろ物足りない気がするけど。 |
| A | 素直に京大とか東大とか行っとけ |
| A | 北大の教授で京大や東大ではしてない研究をしてるのが居てその分野を專攻したいー、とかなら別だけど。 |
| A | 知ってる範囲の北大の学生でものすごいのって、□□□□出てて高校時代から一人でばりばりプログラム書いてる、とかそんな感じだから |
| B | まあお前よりは高等だから |
| B | こめん |
| B | ごめん |
| A | 僕より偏差値高いだろうってことは知ってるから、いまさら確認することじゃないなｗ |
| A | ただ、具体名は避けておくけど、GoogleとかMSだけに優秀なプログラマが集まってると思ってるなら、それは間違ってるねー |
| A | 「高学歴=優秀なプログラマ」が真なら、国内のメーカーはどうしてこんな惨状なのか… |
| A | 僕がこの2年くらいで会ってきた、そこそこ多めな数の高校生とか大学生たちから見るに、優秀な高校生が良い大学入ってるってのはおよそ間違ってないね。東大とか京大とか筑波とか東工大とか。 |
| A | s/優秀な高校生/優秀な高校生プログラマ/ ね |
| B | そう吠えんな |
| B | ごみなんだからお前は |
| B | 情報オリのメダリストは全員高学歴だろ |
| A | それはまったく否定しない |
| B | 高学歴=優秀なプログラマーとはいってないよくず |
| B | 優秀なプログラマーは高学歴であることが多いてことな |
| A | で、情報オリンピックとか挙げちゃうとお前はどうなのよ、って話になってくる。 |
| B | それ俺より馬鹿なクズがいうセリフじゃないぞ |
| A | 情報オリンピックのメダリストになりたいの? 高学歴になりたいの? |
| B | 最終目標は金持ちやね |
| B | 金持ちになるにはいい大学いったほうが確実だろ？ |
| B | プログラミングは興味本位かな |
| A | 確実って言うには出身大学は要件としていささか貧弱な気がするんだけど |
| B | 金持ちになるには、いい大学いくことが近道 |
| A | 僕は読みたい本が買えるだけの儲けがありゃ良いから金持ちとかあんまり関係ない話やね |
| B | くずめ |
| A | 上位の大学の方が平均年収が高い、とかって水準の話ならまったくその通り。 |
| B | 金持ちなれねぇやつが かっこつけんなくず |
| A | 君が儲ける金は君のものだし、僕が儲けた金は僕のものだから、まったく関係がないよね |
| B | きも |
| B | くずだw |
| B | お前は負け犬だ |
| B | 可哀想に |
| A | 別に君のおこぼれに与ろうってことは期待してないから、君が勝っても負けてもどうでも良いんだけど。 |
| B | くずめ死ね |
| B | お前らはくずなんだから今すぎ死ね |
| A | 今すぎ |
| B | お前みたいな奴が日本の足引っ張んだよくずwww |
| A | 内心蔑みながらも日本の未来を案じるさまは立派です。 |
Flashで作るかFlexで作るかの違いだと、レイヤーやムービークリップの概念とか共通だから問題無いぞ？
C99とANCI以前のCとか、ものすごい違うのだが？
昔からメンテしてるコードだと、コンパイラに「古い組み方です」的なwarning吐きまくられたりするし。
というか、CPUのbit数が違うだけで別物になる処理系だしな。
たまたまActionScriptが差すものの範囲が小さいから、混同されがちだが、ActionScriptはあくまで言語であって、ActionScriptが呼んでいるFlashのライブラリとは別物という解釈。
JavascriptだってDOM使わない独自拡張製品もいくつかでてるしな。かならずしもブラウザでDOMがなければJSというわけでもあるまい。
それだと、Flashで作るかFlexで作るかの違いについてお前が語るのはおかしくね？
まぁ、そう拡大解釈しても、
とかは依然あるわけだがなー。
追記: トラバ間違えた。
第1章 並行プログラミングとGHC (上田和紀) 1.1 はじめに 1.2 ターゲットを明確にしよう 1.3 はじめが大切 1.4 GHCが与える並行計算の枠組み 1.4.1 GHCにおける計算とは，外界との情報のやりとり(通信)である 1.4.2 計算を行う主体は，互いに，および外界と通信し合うプロセスの集まりである 1.4.3 プロセスは，停止するとは限らない 1.4.4 プロセスは，開いた系(open system)をモデル化する 1.4.5 情報とは変数と値との結付き(結合)のことである 1.4.6 プロセスは，結合の観測と生成を行う 1.4.7 プロセスは，書換え規則を用いて定義する 1.4.8 通信は，プロセス間の共有変数を用いて行う 1.4.9 外貨も，プロセスとしてモデル化される 1.4.10 通信は，非同期的である 1.4.11 プロセスのふるまいは，非決定的でありうる 1.5 もう少し具体的なパラダイム 1.5.1 ストリームと双方向通信 1.5.2 履歴のあるオブジェクトの表現 1.5.3 データ駆動計算と要求駆動計算 1.5.4 モジュラリティと差分プログラミング 1.5.5 プロセスによるデータ表現 1.6 歴史的背景と文献案内 1.7 並行プログラミングと効率 1.8 まとめ 第2章 様相論理とテンポラル・プログラミング (桜川貴司) 2.1 はじめに 2.2 様相論理 2.3 時制論理 2.4 多世界モデル 2.5 到達可能性と局所性 2.6 純論理プログラミングへ向けて 2.7 Temporal Prolog 2.8 RACCO 2.9 実現 2.10 まとめと参考文献案内 第3章 レコード・プログラミング (横田一正) 3.1 はじめに 3.2 レコードと述語の表現 3.3 レコード構造とφ-項 3.3.1 φ-項の定義 3.3.2 型の半順序と束 3.3.3 KBLとLOGIN 3.4 応用――データベースの視点から 3.4.1 演繹データベース 3.4.2 レコード・プログラミングとデータベース 3.4.3 いくつかの例 3.5 まとめ 3.6 文献案内 第4章 抽象データ型とOBJ2 (二木厚吉・中川 中) 4.1 はじめに 4.2 抽象データ型と代数型言語 4.2.1 抽象データ型 4.2.2 代数型言語 4.2.3 始代数 4.2.4 項代数 4.2.5 項書換えシステム 4.3 OBJ2 4.3.1 OBJ2の基本構造 4.3.2 モジュールの参照方法 4.3.3 混置関数記号 4.3.4 モジュールのパラメータ化 4.3.5 パラメータ化機構による高階関数の記述 4.3.6 順序ソート 4.3.7 属性つきパターンマッチング 4.3.8 評価戦略の指定 4.3.9 モジュール表現 4.4 おわりに 第5章 プログラム代数とFP (富樫 敦) 5.1 はじめに 5.2 プログラミング・システム FP 5.2.1 オブジェクト 5.2.2 基本関数 5.2.3 プログラム構成子 5.2.4 関数定義 5.2.5 FPのプログラミング・スタイル 5.3 プログラム代数 5.3.1 プログラム代数則 5.3.2 代数則の証明 5.3.3 代数則とプログラム 5.4 ラムダ計算の拡張 5.4.1 ラムダ式の拡張 5.4.2 拡張されたラムダ計算の簡約規則 5.4.3 そのほかのリスト操作用演算子 5.4.4 相互再帰的定義式 5.4.5 ストリーム(無限リスト)処理 5.5 FPプログラムの翻訳 5.5.1 オブジェクトの翻訳 5.5.2 基本関数の翻訳 5.5.3 プログラム構成子の翻訳 5.5.4 簡約規則を用いた代数則の検証 5.6 おわりに 第6章 カテゴリカル・プログラミング (横内寛文) 6.1 はじめに 6.2 値からモルフィズムへ 6.3 カテゴリカル・コンビネータ 6.3.1 ラムダ計算の意味論 6.3.2 モルフィズムによる意味論 6.3.3 カテゴリカル・コンビネータ理論CCL 6.4 関数型プログラミングへの応用 6.4.1 関数型プログラミング言語ML/O 6.4.2 CCLの拡張 6.4.3 CCLに基づいた処理系 6.4.4 公理系に基づいた最適化 6.5 まとめ 第7章 最大公約数――普遍代数，多項式イデアル，自動証明におけるユークリッドの互除法 (外山芳人) 7.1 はじめに 7.2 完備化アルゴリズム 7.2.1 グラス置換えパズル 7.2.2 リダクションシステム 7.2.3 完備なシステム 7.2.4 完備化 7.2.5 パズルの答 7.3 普遍代数における完備化アルゴリズム 7.3.1 群論の語の問題 7.3.2 群の公理の完備化 7.3.3 Knuth-Bendix完備化アルゴリズム 7.4 多項式イデアル理論における完備化アルゴリズム 7.4.1 ユークリッドの互除法 7.4.2 多項式イデアル 7.4.3 Buchbergerアルゴリズム 7.5 一階述語論理における完備化アルゴリズム 7.5.1 レゾリューション法 7.5.2 Hsiangのアイデア 7.6 おわりに 第8章 構成的プログラミング (林 晋) 8.1 構成的プログラミング？ 8.2 型付きラムダ計算 8.3 論理としての型付きラムダ計算 8.4 構成的プログラミングとは 8.5 構成的プログラミングにおける再帰呼び出し 8.6 おわりに：構成的プログラミングに未来はあるか？ 第9章 メタプログラミングとリフレクション (田中二郎) 9.1 はじめに 9.2 計算システム 9.2.1 因果結合システム 9.2.2 メタシステム 9.2.3 リフレクティブシステム 9.3 3-Lisp 9.4 リフレクティブタワー 9.5 GHCにおけるリフレクション 9.5.1 並列論理型言語GHC 9.5.2 GHCの言語仕様 9.5.3 GHCのメタインタプリタ 9.5.4 リフレクティブ述語のインプリメント 9.6 まとめ
第1章 新しいプログラミング・パラダイムをめぐって (井田哲雄) 1.1 はじめに 1.2 プログラミング・パラダイムの形成 1.3 プログラミング・パラダイムの展開 1.4 パラダイムと作法と構造化プログラミング 1.5 構造化プログラミングを超えて 1.6 関数型プログラミング，論理型プログラミング，対象指向プログラミング 1.7 新しいプログラミング・パラダイム 1.8 まとめ 第2章 ラムダ計算と高階プログラミング (横内寛文) 2.1 はじめに 2.2 ラムダ計算 2.3 最左戦略 2.4 コンビネータによる計算 2.5 まとめ 第3章 マルセイユProlog，Prolog Ⅱ，Prolog Ⅲ 3.1 はじめに 3.2 準備 3.2.1 述語 3.2.2 項 3.2.3 項の単一化 3.2.4 節およびHorn節 3.2.5 論理式の意味 3.2.6 論理的帰結と導出 3.3 マルセイユProlog 3.3.1 Prologの記法 3.3.2 Prologの計算規則 3.3.3 Prologプログラムの例 3.3.4 カット・オペレータ 3.3.5 DEC-10 Prologとの相違 3.4 Prolog Ⅱ 3.4.1 difオペレータ 3.4.2 freeze 3.4.3 ループ構造 3.4.4 Prolog Ⅱのインプリメンテーション 3.5 Prolog Ⅲ 3.5.1 制約の枠組 3.5.2 Prolog Ⅲのプログラム例 3.5.3 束縛の領域と制約系 3.5.4 Prolog Ⅲのインプリメンテーション 3.6 まとめ 第4章 制約論理型プログラム (相場 亮) 4.1 はじめに 4.2 制約プログラミング 4.3 制約の分類 4.4 プログラムの実行 4.5 制約の評価 4.6 まとめ 第5章 オブジェクト指向 (柴山悦哉) 5.1 はじめに 5.2 モジュラリティと抽象化 5.2.1 抽象化 5.2.2 手続き抽象 5.2.3 データ抽象 5.2.4 オブジェクトによる抽象化 5.2.5 並列オブジェクトによる抽象化 5.3 共有 5.3.1 多相型 5.3.2 継承 5.3.3 多重継承 5.3.4 Self 5.3.5 動的束縛の意義 5.4 対話性 5.4.1 クラスの再定義 5.4.2 表示機能の一体化 5.5 オブジェクト指向の弱点 5.6 まとめ 第6章 型推論とML (横田一正) 6.1 はじめに 6.2 LCFの超言語からMLへ 6.3 プログラミング言語と型 6.4 MLの表現と型宣言 6.5 MLの型推論 6.6 LCFへの応用 6.7 まとめ 第7章 Miranda (加藤和彦) 7.1 はじめに 7.2 Mirandaの概観 7.2.1 等式による定義 7.2.2 基本データ型と基本演算子 7.2.3 ガード付き等式とスコープ・ルール 7.2.4 高階関数とカリー化 7.2.5 パターン・マッチング 7.2.6 ノンストリクト性と遅延評価 7.2.7 ドット式とZF式 7.3 型 7.3.1 強い型付けと静的な型付け 7.3.2 多相型 7.3.3 型類義 7.3.4 代数データ型 7.3.5 抽象データ型 7.4 処理系 7.5 まとめ 7.6 文献の紹介 第8章 項書換えシステムと完備化手続き (大須賀昭彦) 8.1 はじめに 8.2 項書換えシステム 8.3 TRSの停止性 8.3.1 意味順序 8.3.2 構文順序 8.4 TRSの合流性 8.4.1 完備なTRS 8.4.2 危険対 8.4.3 危険対を用いたTRSの合流性判定 8.5 Knuth-Bendixの完備化手続き 8.6 KBの応用 8.6.1 帰納的な定理証明への応用 8.6.2 等号論理の定理証明への応用 8.7 まとめ 第9章 等式プログラミングから融合型プログラミングへ (富樫 敦) 9.1 はじめに 9.2 等式プログラミング 9.2.1 等式プログラム 9.2.2 代表的な等式プログラム 9.2.3 プログラミング技法 9.2.4 正則プログラムと正規化戦略 9.3 条件付き等式プログラム 9.3.1 条件付き書換え規則 9.3.2 条件の種類 9.3.3 利点と問題点 9.4 融合型プログラミング 9.4.1 AMLOGシステム 9.4.2 向付き等式 9.4.3 実行戦略の変更 9.4.4 代入操作 9.4.5 合流するプログラムへの変換 9.5 まとめ
横だが、おれは型変換とか、そのあたりの事かなぁと思った。
データ型は、じつはオブジェクトであり独自の処理ルールをもっているってのを知らないと、結構悲惨なバグを生んだりする。
高級が故の悲劇。
Javaなどの「高機能な」言語仕様が「無自覚に仕込むバグ」を知ってたら、とてもじゃないけど言えない。
でも「無自覚（ユーザーが仕込んだわけじゃないバグ）」は不味い、それを拾おうとすると、結局言語仕様で起こりうるバグをカプセル化してチェックするって話になるからだ。
横だけど、これ何の話してるんだろ？
つまり、「生産性の高い言語」は、人間の不注意やミスを言語処理系の側で防止したり、影響範囲を最小限にしてくれるということ。
これを無邪気に言い放つ人とは一緒に仕事したくないわ、とだけ言っておきますよ。
Javaなどの「高機能な」言語仕様が「無自覚に仕込むバグ」を知ってたら、とてもじゃないけど言えない。
でも「無自覚（ユーザーが仕込んだわけじゃないバグ）」は不味い、それを拾おうとすると、結局言語仕様で起こりうるバグをカプセル化してチェックするって話になるからだ。
そこに意識的にならないと、そもそも議論の出発点にすら立ってない。
Javaの場合、ユーザのフィードバックにより成熟したライブラリやツール群を、多くの場合無料で利用できるのがメリットと言える。
人間は必ずミスをするものだ、という前提を無視した開発手法は信用するに値しない。完全な設計は、存在しない。規模が大きくなればなるほど、そうしたナイーブな前提は容易に崩壊する。
つまり、「生産性の高い言語」は、人間の不注意やミスを言語処理系の側で防止したり、影響範囲を最小限にしてくれるということ。
「○○はC言語でもできる」ではなくて、ライブラリやツールがどれだけ整備されているか、それらがどれだけ容易に導入できるか、という点に注目してみるといい。
Cで開発してるチームなら絶対に持っている、自前のライブラリ群や
それらが十分に品質が高く、容易に利用できるものならいいんじゃないかな。
Javaの場合、ユーザのフィードバックにより成熟したライブラリやツール群を、多くの場合無料で利用できるのがメリットと言える。
カーネルコミッターでも、処理系実装者でも無さそうな人達が、「Cは滅びず！」と叫んでいる不思議な光景。
http://b.hatena.ne.jp/entry/shyouhei.tumblr.com/post/5545216280/c
http://b.hatena.ne.jp/entry/shyouhei.tumblr.com/post/5603961294/c
Linuxカーネル（せめてPOSIX互換品)を手前が思う言語にさっさと移植すれ。さすればCを滅ぼせん。（ちなみに高機能アセンブラの最適解がCとは俺も思っちゃいない。）
最後のＣの牙城、Linux（ＵＮＩＸ）をＪａｖａなり何なりベターな言語にさくっと移植してくれ。それともgoogleビッグブラザー様がクラウドでＵＮＩX鯖を駆逐してくれるのを祈ってればいいのか？
JavaもC#も，それにPerlもRubyもPythonも，実行環境自体はCで書かれている件。コンピューターが「シリコンを基材としたチューリングマシン」であるかぎり，アセンブラとCは滅びない。
fooのintへのキャストがtrue/falseを返すというように、fooのクラス仕様が決められてるんなら、
そしてboolへのキャストが未定義だったり、また違う意味なのなら
if (foo) {
ではなく
if (foo == true) {
って書かざるをえないだろう。嫌いとか好きとかの問題ではないと思う。
class { public: operator bool() { std::cout << "xxx\n"; return true; } //*1 operator int() { std::cout << "yyy\n"; return true; } //*2 } foo;
があったときに、「if (!foo)」だったら*1が、「if (foo == false)」だったら*2が実行されるような処理系がある。
最新のVC++だと後者は曖昧だってエラー出るね(たぶんC++だと「trueは1でfalseは0」なんかではなくあくまでもtrueとfalseなんだ)。
なんにせよ演算子や条件式などに関連する暗黙のキャストはわかりづらく、そしてそんなのを利用したコードはきっとバグる。
だから
というのが本当なら、==trueがどうこうなんて些細な問題はおいておいて、fooを暗黙のうちにintにキャストしたりboolにキャストしたりして使っているという危険な部分をまずなんとかすべきだろう。
古いC言語風に書けばこんな感じ。
#define FALSE 0 #define TRUE (!FALSE)確かに、実際に値を表示させてみると、昔のVC6だと「1」という結果が出てくるし、VB6だと「-1」という結果が出てくる。これ、当時混乱の元だったんだよね。
VC6とか関係なくてC言語の仕様でそうなんだが、それをわかってないとすればやばい。
個人的には
if( foo != FALSE ){
も十分きもちわるいので
if (foo) { ... }
if (!foo) { ... }
にしてほしい。
まぁ、タイトルの「レガシープログラマ」とは私の事なんですけどね。
if( foo == TRUE ){
という判定文をよく見かける（fooはいろんなオブジェクトだと思ってほしい）。
個人的には、この書き方、嫌いなんだよね。
if( foo ){
か
if( foo != FALSE ){
と書いて欲しいわけよ。とにかく「TRUEか？」という判定にはして欲しくないわけです。
で、なんでこう書くの？と外注や若い連中に聞いたら、「TUREは1ですから」と必ず答える（断言する）。
あ、あれ？？？自分は「TRUEはFALSEでは無い。確定しているのはFALSE=0という事だけ」だとずっと思っていたんですわ。
古いC言語風に書けばこんな感じ。
#define FALSE 0 #define TRUE (!FALSE)
確かに、実際に値を表示させてみると、昔のVC6だと「1」という結果が出てくるし、VB6だと「-1」という結果が出てくる。これ、当時混乱の元だったんだよね。
新しいC++や規格ではBOOL型というのがきちんと定義されたと思うけど、製品寿命が20年とかいう私の職場では、DOSやC(K＆R)、アセンブラは現役だし、プラットフォームもなにもWindowsに限らない。組み込みマイコンも使う（うちのところはVxWOKSだが）し、UNIXやLINUXも使う。
もちろん、マネージドC++（.netFramework)やC#、JAVA、Parlも私は使うし。でも、どのプラットフォームでどの言語になっても「TRUEか？」という判定文は使ってこなかった。
で、試しに、VC2008のincludeフォルダをgrepしてみたら、
#define TRUE 1
あ、ほんとに「1」だ。
typedef bool int
なんて見かけるから、やろうと思えば「5」でも何でも数字が入ってしまうわけですよ。そこで「== TRUE」なんてやられたら、絶対に成立しないわけで。バグの温床になるんじゃないかなー、と思ってかたくなに前述の姿勢を持っていたわけです。
今（最近の）言語はきちんと「BOOL」型（またはboolという名のクラス）を定義されていて、コンパイルエラーになるか、自動的に補正してもらえるのかもしれないけど、ちょっと気持ち悪い。
最近、ちょくちょく外注や若い連中と意見や話が合わず、「ああ、俺ってレガシープログラマなんだな」と思う事が多くなった今日この頃。ネットワークに平気でリトルエンディアンのデータを流すとか、勘弁して欲しい。LANアナライザでデータが見にくくてしょうが無い。
3%タイプしたらあとはIDEが補完してくれるなら、その3%を記述しておけば後はコンパイラがよしなにやってくれる言語をつくればいいんじゃないかな。
(ここでいう「コンパイラ」は広い意味の処理系。インタラクティブにミスを指摘したりインクリメンタルにリンクしてくれたり、といった機能も込みで。)
期待しているものと少し違うかもしれないが、既にJava向けのウェブフレームワークでは、必要最低限のコードだけ書くと他の部分を自動生成してくれるようなプロダクトが出てきている。"Spring Roo"とか"Play framework"とかが代表的かな。バックグラウンドでツールを走らせておくと、ファイル変更のタイミングで、自動的にビルドとコード生成をやってくれる。
これらは、RoRと同様の生産性を実現しつつ、既存のJava資産を活用し、静的型言語の恩恵をも受けられるようにすることを目指している。
http://anond.hatelabo.jp/20090326142330 の続き
pythonでベンチとった。試した方法は以下
長くなるので、使用したスクリプトと生の結果は http://anond.hatelabo.jp/20090326123924 に貼った。
結果としては、早さは3, 4, 1, 2の順で、３を基準にとると、
| 文字列長 | md5hex | crc32x4 | headtail | skipover | ループ回数 |
|---|---|---|---|---|---|
| 256 | 6.6 | 36 | 1.0 | 1.4 | 65536 |
| 1024 | 8.3 | 36 | 1.0 | 2.0 | 16384 |
| 4096 | 26 | 85 | 1.0 | 2.5 | 4096 |
という比率になった。
文字列長が長くなるとやはり後2つが有利だ。また、今回は32文字に切り詰めたがそれでもコリジョンは発生しなかった。アルゴリズム上、数文字だけの変化には対応出来ない可能性があるが、切り詰める量が少なく入力にいくらかのランダム性があれば実用になると思う。
(追記：URLで使ったら、ランダム性が悪くてコリジョン出た。素直にmd5がベターかもしれない)
しかし、この程度の速度差であれば、コリジョン耐性を重視して素直にmd5を使用するのも良いかもしれない。特に、今時はネイティブコードのライブラリをほぼ標準で持つ処理系が多いため、まずはmd5で、としても間違いはなさそう。
最初のネタ扱いの書き方が失礼だったことは申し訳なかったですが、どうかカッカしないで欲しい...。
で、結局、何を「メリット」と考えるか、何を軸に「大小関係」を考えるのかがずれているのだと気づきました。
「forを再帰で代替するなんて、どういうメリットがあるの？」という大元増田の疑問に対して、「ループは再帰の一種なので、表現力としてはメリットもデメリットもありませんよ（大小関係はないですよ）」と申し上げましたつもりでした。
まあ、そもそも元がfizz_buzzの書き換えの話だしね。
「再帰に書き換えて俺のプログラムが速くなるのか」というのなら、処理系にもよりますが速くなったり遅くなったり変わらなかったりすると思います。
それで、一番引っかかっているのが、これ。
再帰処理って処理を停止して新しい処理を行い、終了後に停止していた処理に戻ることじゃない？
元増田と違う人かもしれないが、
これには同意します。しかしながら、
再帰処理って処理を停止して新しい処理を行い、終了後に停止していた処理に戻ることじゃない？
これは再帰呼び出しの説明としては、やっぱり変だと思いますよ。
ネタ扱いしたのは悪かったですけど。
もちろん、別増田も指摘している通り、すべての言語が末尾最適化されてるわけじゃありません（ついでに言うと、すべての再帰呼び出しがループに変換できるわけでもありません）。
しかし、gccですら（条件付きながら）末尾再帰を最適化してくれるご時世ですから、必ずしも「再帰はスタック領域を消費」「ループのほうが一般的に処理コストが小さい」とは言えないと思いますよ。まあ、gccなんぞ知らんと言われればそれまでですが。