 
|
はてなキーワード: 関数型言語とは
Python vs Ruby vs PHP vs Haskell プログラミング言語バトル part1
http://anond.hatelabo.jp/20120118220204
Rubyistってなんであんな小学校の図書室で毎日読書してそうな
顔面オジサン、オバサンばっかなの？
Scalaer: 鼻持ちならない、モヒカン
Lisper: マジキチ
Rubyist: ネクラ、オタク、キモメン、いじめられっこネクラチビメガネ、色黒、キモオタ、顔面オジサン、オバサン
Rubyのブロックが便利すぎて、Pythonをやめたくなった。
いちいちtemporaryな関数を作成してから目的の関数に渡していたのがばからしくなった。
リストやジェネレータ式の内包表記が便利過ぎて
どうせ廃れる。
609
＞リストやジェネレータ式の内包表記が便利過ぎて
おれもそう信じてたけど、Rubyの、メソッド呼び出しを続けて書けるほうが便利だわ。
まるでjQueryみたい。といってもjQueryのほうが後発だけど。
たとえば「xsから0以上のものを選んで、その二乗の和を求める」場合
sum([ x*x for x in xs if x > 0 ])
これだと、後ろから読まないといけないんだよね。でも
xs.select{|x| x > 0}.map{|x| x*x }.sum
これなら頭からひとつずつ読めばいいから、わかりやすいし、考えたとおりに書きやすい。
まさにスクリプトって感じがする。
Python: [[x,y] for x in xs for y in xs]
Ruby: xs.map{|x| xs.map{|y| [x,y] } }.flatten(1)
いっぽうメソッドチェーンは
orz.sage().hage().hoge().hige() タイプの問題には向いている
つまり向いている方向がちがう
(まあHaskellなら hige . hoge . hage . sage と書くだけだというのは置いといて）
強い弱いということで言うと、問題を解くのに必要な一番能力が弱い
（限定された）道具を使うという考え方があるようだよ
ベタ再帰は強い（汎用的）、がそれゆえ読むのに注意を必要とする
foldrは再帰よりは弱いが、foldrで表現可能な問題のクラス（原始再帰）はかなり
広いので、mapやfilterで済むならもちろんそのほうが望ましい
ではこの問題は弱いmapやfilterを結合させるほうがいいかというと、
俺はlist comprehensionのほうが集合表記そのもの=whatを表現していて好きだな
Pythonのlist comprehensionのsyntaxはあまり好きではないが
それは大きな問題じゃない
メソッドチェーンってバグをわかりにくくするだけだと思うなあ。もちろん性能面もあるし。linqとかは良いと思うけど。
同じメソッドチェーンでも、linqなら良いけどrubyなら悪い .....
一言で言うと「俺はRubyが大嫌いなんだぁーー」ということですな
内包表記は構文でサポートしないと難しい（マクロがあれば別だが）
メソッドチェーンが関数型の方法に比べて特に優れている点があるようには思えないが
パイプ順に書きたければ書けるし
680,663
Pythonには関数型として致命的な弱点があるから、メソッドチェーンでは簡潔なコードが書けない
たとえば「(1) Rubyは 条件判定が(文ではなく)式」だから以下のようなコードが書ける
if test
if test_1 then test_1_1 else test_1_2 end
else
if test_2 then test_2_1 else test_2_2 end
end
}
あるいは「(2) Rubyはブロック内で局所宣言が可能」だから上のコードを以下のように書き換えてもいい
cond_1 = if test_1 then test_1_1 else test_1_2 end
cond_2 = if test_2 then test_2_1 else test_2_2 end
if test then cond_1 else cond_2 end
}
関数型言語であれば「(1) 条件判定(if/case)が式」で「(2) 局所宣言(let .. in .. end)が可能」なの当たり前
ところが残念な事に、どちらもPythonには欠落しているから、上の例はストレートにコード化できない
だからPythonではメソッドチェーンは使われないし、「酸っぱい葡萄」に見える
Rubyでもリスト内包表記が言語として組み込まれてくれると嬉しい
だと思う
頭に浮かんだロジックをすばやくコード化するのはメソッドチェーンが適しているし、
じっくり腰を据えてコード設計するならリスト内包表記のほうが美しい
自分は、たぶんこのスレもRubyコアの中の人も見ているだろうから
そのうちRubyにもリスト内包表記が実装されるんじゃないかと期待しているw
メソッドチェーンは書き易い
内包表記は見た目が整ってて綺麗、最終的な型がわかり易い
いじょ。
なぜ両方使うという選択肢がない。真の技術者はウェブ標準だろうがFlashだろうがネイティブだろうが、その場その場でユーザーの体験を最善にし、クライアントの要求を最高に満たすベストの技術を使う。JavaScriptかFlashかなんて動きさえすればユーザーには関係ないんだから。実際、HTML5スゲＥＥＥＥＥ！！！ってページにFlashタグのブクマが間違ってつけられたりしてるよ？（笑） ウェブ標準の崇高さなんてパンピーにはわからんのです。
そもそも分からないんだけど、HTML5が「投資」するほどたいしたもの？ 誰もが基礎教養として身につけているはずの、これまでのHTML＋CSS＋JavaScriptの延長線上の技術でしょ。今まで普通にやってきたウェブ開発者ならすぐにキャッチアップできるはずだよ。
どうせHTML5の実装の普及には当分かかるし、その時点のブラウザ環境で使用可能なものをゆっくりまったりと導入していけばいいだけ。その意味ではいわゆる遅延評価学習で十分。あわてることはないです。どうせ皆使うことになるんだから。
一応言っておくと、いいものだと思いますよ、HTML5は。現段階で頑張って凝ったものを動かしておられるイノベーターの方々もたいしたものだと思います。敬意を。マリオやらグラディウスやらは著作権的にどーなのかと突っ込みたいが。
それはシナリオのひとつですよね。Googleの甲斐性次第では十分にあり得る。それと、ジョブズが翻意するというシナリオもありますよ。今までに散々あったことですが。どこかでそれをネタにしている記事があったと思いますが。
もしEdgeを見てそう思ったのなら、Flash CSを使って制作したことがありますか？ Edgeを実際に使ってみましたか？ と問いたい。
他にも、最低でも、
これらにきちんと答えられない人間にHTML5 vs Flashなど語る資格はないです。そもそも対立させる時点でわかってないなー ┐(´д｀)┌ って感じなのだけど。
あとFlashへの投資が無駄になると思ってるようですが、俺はFlashは投資判断「Buy」継続だと見てますよ。たとえこのままiOSで動かずともね。AIRもあるし、ブラウザのプラグインとしてのFlashだけ見ていると考えを誤るよ。ブラウザのほうにしても、GPUアクセラレーションつきの3Dが真っ先に使用可能になるのはFlash。プレイヤーの普及が速いから、WebGLと異なり、今後1～2年内に実案件で使用可能になるでしょう。そういった面ではなおカッティングエッジな技術だよ。
まあ、プラットフォームや言語の選択は投機だから、どの銘柄が買いか売りかで紛糾するのはわかる。ただ、それなら分散投資だとか、インデックス投資という考え方もあるのでね。HTML5に惚れ込んで一点買いなんて若いエンジニアがいたら、それはもう相当危なっかしいなと、視野も相当狭くなるだろうなと危惧するよ。
というか、JavaだろうがC++だろうがObjective-CだろうがLLだろうがアセンブリ言語だろうが関数型言語だろうが、一度全部触ってみなよ。いいから。HTML5で手一杯なんてのでは話にならんですよ。
最近、Scala信者が増えたが、Scala、Groovy、Clojureで仕事している人はいるのだろうか？
Javaと比較してライブラリが増えるわけでもなく、応用分野が増えるわけでもなく、良さが理解できない。
| 検索順位 | 人気順位 | 言語名 | 登場年 | 特徴 |
|---|---|---|---|---|
| 1位 | 95位 | Scala | 2003年 | Javaに関数型言語の特徴を組み込んだ。 |
| 2位 | 71位 | Groovy | 2003年 | Javaより少ない記述量が特徴。 |
| 3位 | - | Jython | 1997年 | Python 2系のポーティング。 |
| 4位 | - | JRuby | 2001年 | Rubyのポーティング。 |
| 5位 | - | Clojure | 2007年 | Lispの方言、つまり関数型言語。 |
| 6位 | 75位 | JavaFX Script | 2008年 | JavaFXを残して廃棄処分。 |
仰る通り、ハードウェアアーキテクチャについては知らないですね（スタックやヒープがどうとかは表面上わかりますが）。
というのはズバリそこが非常に嫌い（肌に合わない）で、意図的に避けてるからです…。アセンブラの本とかも持ってますが、どうにも読めないですね…。
当然Cは嫌いです…。C++がギリで、できればRやpythonレベルの抽象度で全部済ませたい派です。が、さっきも書いたようにちょっと踏み込むとすぐ低レベルの話が出てきますね…。
最近はGPUだの並列化だのを使いこなさないと生きていけない感じですし。
関数型言語くらい抽象化して数学っぽい雰囲気になってると個人的には嬉しいですねw
誇張や事実と異なる表現がございます。ネタとしてお読みください。
特に関数型言語は全く触ったことが無いため誤っている可能性があることをご了承下さい。
while(i＜10000)++i;
| COBOL | バブル時代に銀行のCMにも出演したことがあるが現在はほぼ引退している。 |
| BASIC | 一時期は誰もが知っている国民的アイドルだったが、現在はほぼ引退している。しかし昔からの根強いファンによって現在も一部で活躍中。 |
| FORTRAN | インテリ層に大人気のアイドルグループ。 |
| Brainfuck | アイドルの定義を逆手に取った誰も得をしない名ばかりアイドル。 |
| PERL | もともとは活字メディアでの活動を主軸にと結成されたが、現在はネットで活動することが多い。 |
| RUBY | PERLを真似た純国産のアイドルグループ。こちらも最近はネットでの活動が多い。 |
| C | 今も現役で活躍する言わずと知れた国民的アイドル。しかし最近はJAVAなど後進のアイドルたちに仕事を奪われつつある。 |
| C++ | Cのメンバーに加え、あらゆる属性の女の子を集めた超大型アイドルグループ。しかしあまりにマニアックなため、一部のファン以外はついて行けていない。 |
| JAVA | C++の失敗を反省し一部のマニアックな属性を削った正統派アイドルグループ、初心者はJAVAから入ることを進められる。 |
| C# | まっくろ社がJAVAのパクリユニットとして一度デビューさせたが太陽社に訴えられたため名称を変えた。しかし後進だけあり、女の子の質は高いと好評。 |
| GO | 新進気鋭のぐぐるからデビューした新人アイドル、デビュー時は大きな注目を集めたがその後は期待ほど売れていない。 |
| D | 他のアイドル達のいいとこ取りをした最強ユニットのはずが、未だメジャーになりきれないマイナーアイドル。 |
| Objective-C | Cに新たなメンバーを加えたユニット。しかしC++ほどメジャーになれずそのまま消えるかと思われたが、出演した林檎の映画が大ヒットし延命した。 |
| JAVA SCRIPT | 身近がモットーのネットアイドル。あなたも気付いていないだけで、いろいろなところでお世話になっています。 |
| PHP | ネットアイドルとしてデビュー、物珍しさも手伝って人気になったが、女の子が明らかに寄せ集めと批判も多い。 |
| LISP | 81が新人声優を売り込むために作ったスフィアのパクリユニット。おっぱいが大きい。 |
C# は趣味というか私生活で必用な時にしか使ってないです。他の方の意見を聞いたほうがいいと思う。趣味でやってる感想としては、まず過去のどろどろがないのがいい。標準ライブラリだけで殆ど足りちゃうのも初心者にありがたい。あたらめて考えてみると初心者に対する敷居は低いなあ。
作りたいものが明確なら結果への近道になる言語なのは確かなんですけど、プログラミングで何をしたらいいかわからないからプログラミング言語を知りたいという段階の人には薦めにくいかなあ。前記事で Python 薦めたのは元増田さんがそういう段階だからです。
関数型言語も趣味レベルでしかやってないです。関数型言語とは違うけど SQL は仕事で毎日使ってる。むかーし Haskell ぶんなげて、SQL 使ってたらなんかひらめきがきて、それから結構わかるようになった。（ようなきがする）関数型言語って独特の脳汁でるんだよね・・・難しい SQL 弄ってるときも同じ脳汁が出る。関数型っぽい脳みその使い方は他の関数型じゃない言語でもできるし気持ちいい。関数型言語自体は触った時間短いけど、ああいう脳みその使い方はすごく武器になると思います。
http://anond.hatelabo.jp/20100725025127
"どうすればいいか"を教わって、プログラミングが身につく人は多くありません。"なにをやりたいのか"を自分で生み出せないと、詰まってしまうし、なにより楽しくありません。
やりたいことがあれば手段は後からついてきます。これは物作り全般に言えることです。特に学び始めにおいてモチベーションを維持し勢いをつけるのに大事なのは"やりたいことがあるか"、もっと具体的に言うなら"作りたいものは何か"です。これがないと始まりません。それがどうしてもないなら、そういう状況に自分を追い込むのも有効です。仕事でどうしてもやり遂げなければならない状況に追い込まれれば人間 0 からでも身につきます。実際自分がそうでした。
とかく、プログラミングというのは手段さえ知れば、あとはだれがやっても同じ結果が出る生産業だと誤解されがちです。そういう認識で学ぼうとしても楽しくありませんし、本質を掴みにくいので応用が利かなく上達しにくいです。
本質は絵や音楽と同じです。言語を覚えるということは道具の使い方を覚えることでしかありません。音楽の理論や絵筆の使い方を知っているだけで、すぐに素晴らしい音楽や絵ができるでしょうか。殆どの人がそうは思わないはずです。プログラミングもそれと同じです。作りたいものがある人が圧倒的に強いのです。
んー、ここまで読んでも｢やりたいことはないけどとりあえず勉強したい｣というなら、すぐに動くものをつくりやすい言語がお勧めかなあ。
Google App Engine で Python をやるとか。 Python のいいところは、明快で作法にあまり迷わなくていいところです。自分がまったく言語やったことない知り合いにすすめるとしたらこれ。
レガシーではないちゃんとした JavaScript (http://www.crockford.com/javascript/ この辺にあるような) もいいです。ブラウザですぐ動きますし、 Firefox 環境なら本格的なデバッガまであります。 JavaScript は非常に誤解の多い言語ですが、悪いものではありません。 お手軽にグラフィカルなものを扱える、結果がわかりやすいので初心者向けです。それでいて、拡張性が高く、プログラミングに必要な概念、ロジックの殆ど再現できる底力も秘めています。
Perl はレガシーな作法がいまだに見受けられる (Perl って CGI のことでしょ的な解説が未だにある) のですが、初めから strict に慣れて、 CPAN にあるようなスタイルを参考にして、初めから OOP に突っ走るなら今からやってもいい言語です。 CPAN 等のリソースの豊富さとコミュニティの広さが強いです。ただ、懐の広さ、できることの多さゆえに初心者向きではないところもあります。
PHP はお勧めしません。理由は適当に検索してください。 PHP5 でかなり良くなりましたが、逆に言えば 4 と 5 では別言語と言っても良いほどです。古い考え方と新しいスタイルがごったになりすぎていて、かつて同じような状況にあった Perl に比べても、洗練されたスタイルを学びにくいと思います。また、ロジックの面白さに感動するような部分が PHP にはちょっと足りないです。
MMORPG やそのエミュレーターの中には、 Lua を使って AI やマクロやイベントスクリプトなどを組めるものがあります。すぐに結果が出て自分の役に立つものが作れるので、既にその手のゲームが趣味ならお勧めです。こうした用途では、自分の望む世界を構築するために嫌でも物事をモデル化して考えるので、自然と OOP 的な考え方やデザインパターンが身につきます。
VB は簡単に GUI アプリケーションが作れるのでやる人が多いですが、癖が強いし応用がききにくいのでお勧めしません。また、公開されているソースコードが少ないことも学ぶには不便です。
Ruby はそれほどやりこんでないのでコメントはしないでおきますが、悪くはないと思います。
C++ は何をすればいいのか？を聞いてる人にはすすめにくいです。作りたいものが明確にあり、ロジックを見つけることで応用が利く人ならほっといても覚えるでしょう。自分は、必要に迫られて身につきましたが・・・
個人的には、作りたいものがあってそれにマッチしてるなら、関数型言語を最初にやったっていいと思います。一度ロジックを掴み取る能力がついてしまえば、第二第三の言語は猛スピードで身につくので。
作ったものを公開して、人に見せたり使わせたりして、レスポンスを得るというのはモチベーションの維持や上達に非常に有効です。むしろ、早く上達したいなら必須と言ってもよいです。プログラミングの場合はこれがおざなりにされがちです。
絵を上達したいなら、 pixiv を薦められますよね。今下手かどうかは関係ない。上手くなりたい人が沢山投稿してる。歌が上手くなりたいなら、人前で歌う事は避けられない。ニコニコ動画などで公開してる人がいるよね。人の作品をみると刺激をうける。これはすごいパワーだってのはわかると思う。
プログラミングだって全く同じです。なのに、プログラミングは引きこもって一人で勉強する人が多すぎる。絵や歌は公開しても人に害を与えないけど、プログラミングはバグやセキュリティホールがあったら人に害をあたえるかもしれない、といった印象が強いのかもしれません。
それでも、もっとコミュニティに参加したり、作ったものを公開することが学び始めのうちから重視されていいのは事実。そういった面から考えると、バグやセキュリティホールが出来にくく、安全で、危険な動作がしようもない実行環境があり、加えて Web に公開しやすい言語が学びはじめに向いています。
こちらも参考にしてみて下さい
http://d.hatena.ne.jp/Hamachiya2/20090721
http://d.hatena.ne.jp/Hamachiya2/20080131
学校に行けば一人で学ぶよりは後押しや出会いがあるかもしれませんが、”やりたいこと””必用なこと””作りたいもの”が無い限り、殆どの人は身につきません。
また、残念なことに講師にも大変当たり外れが多いです。自分は専門学校にいったことはありませんが、講師の知り合いがいるのでよく学生さんの話を聞きます。結局の所、しっかり身につく人は、家に帰っても色々作りたいものを作って公開したり、著名なプログラマ達のブログを読みまくったり、フォーラムに出入りしたり、ML に入ってたり、 twitter で刺激的な知り合いをつくるとかしていて、そういうところでめっちゃ差がつきます。
学校に行くなとまでは言いませんが、学校いかないで身に付ける人は本当に多いし、学校いって身につかない人も本当に多いということは考えて下さい。
元増田さんがどの言語をやれば・・という方だったので仕方なくこのような書き方になってしまいましたが、作りたいものが既にある人はあまり”どの言語をやるか”には拘らなくてよいと思います。
そんなことよりも、今必用で/気軽に/すぐ結果がわかることをやるのが、始めてのプログラミングには大事。だから本当は、どの言語をやるかよりも何を作りたいのかを先に見つけてほしい。
目の前の意外なところにプログラミングは生かせます。できるだけ身近な、すぐ効果がわかるところからとりかかった方がプログラミングの楽しさにはやく気付けるはず。
みたいな導入口でもいいんだ。
例えば C++ でのプログラミングを初心者が 0 からやるのは難しいだろうけど、既存のアプリケーションのプラグインなら開発のためのテンプレートや目的に近い作例があってコードも短いからそれを改造するところから始められる。需要があるから楽しいよ。
BGM : http://www.youtube.com/watch?v=zvuC7D_IBuY
(眠くて朦朧としながら Haskell と格闘していて、この言語は、いいとこもある、わるいとこもある、と思っていたらスネークマンショーを思い出した。それだけ。)
いいんじゃないかな。
俺が思うに基礎体力を付けるなら、アセンブラからはじめて、時系列でプログラミング言語の歴史を追体験してもらうのがいいと思うよ。
基礎体力を養う意味ではここら辺がいいと思うんですがどうでしょう。
これがわかるとCLRやJVMのインフラ部分もわかりますし、組み込み方面にも強くなります。
C++はマルチパラダイム言語であり、これをひとつやれば構造化プログラミングとオブジェクト指向プログラミングの両方がわかります。
C++はCのほぼ上位互換言語ですので（正しくはC99が制定されるまでは）、プレーンなCしかやらない理由はありません。
嫌なとこも多くある言語で（どうしてEffective C++シリーズやExceptional C++シリーズみたいな書籍が多くでてるか考えるといいよ）、メモリ管理も手動ですが（これは半分嘘。RAIIがあるから半分自動。GCがないから半分手動）、逆に細かいとこに気を配る態度を養うには最適です。
Erlangで並列プログラミングをやるのもいいかもしれません。
Common LispかSchemeで怪しい（でも美しい）世界を爆走するのもいいかもしれません。
これだけやっとけばC#やJava、軽量言語の類はあっさりと料理できるでしょう。
あくまでもプログラミング言語についてはですからね。
世の中には、どうしても「賢い人」と「あまり賢くない人達」人たちがいて、「あまり賢くない人達」は「賢い人」の足を引っ張るモノです。
「あまり賢くない人達」が自らの愚かさゆえ、人生を無為に過ごすのはある意味しかたがないことだと思いますが、問題なのはこれから賢くあろうとする未来ある若者達が、このような「あまり賢くない人達」に惑わされ、不幸に見舞われることであります。
日向さんはこのような未来ある若者のために、わざわざ時間を割いて素晴らしいエッセイを書きおこしてくれました。
http://www5.ocn.ne.jp/~seablue/res/ckp.html
けれども日向さんの文章は、あまりのレベル差故か、極力平易に書こうとはしているものの、それでも文章が高度すぎて、対象である「あまり賢くない人達」には今一歩言わんとしていることが伝わらないのでは、と感じました。
そこで私は、日向さんの文章の意味を極力損ねないまま、このエッセイを対象である「あまり賢くない人達」向けの言葉に翻訳することを試みました。
もちろん、訳者が至らないために、間違いや勘違い、あるいは校正の際の見落としなども あるかと思います。そのようなことがないように努力はいたしますが、 お気づきの点があれば冷静にご指摘いただければ幸いです。
この書籍については、さまざまなご意見がさまざまなところに書き込まれているようです。
まったく話題にもならないたくさんの本があり、また批評もされない多数の著者たちがいるなかで、 拙著または著者に関心を持っていただいたことにまずお礼を申し上げます。
いやぁ、人気者はつらいね。いつだって妬まれる。
本書については、書籍のはじめに「本書では、初歩のプログラミングの学習を終えて、 プログラマが実践的なプログラミングに臨む時に知っておかなければならない重要な事項をわかりやすく解説します。」 と明示してあるように、プログラミングの初心者を対象にしています。
具体的には、はじめてのプログラミング言語を勉強したか、これから何か言語を学ぼうとしている人、 ふたつめの言語を選ぼうとしているひと、あるいは、 「どうしてデータ型などというものがあるのだろう？」とか、「オブジェクトって、いったい何？」という 素朴な疑問を抱いている人を対象とした書籍です。
また、筆者の「常識」を読者に押しつけようとするものではなく、プログラミングの常識とは何かという ことについて考えるヒントにする本です（このことは書籍の中でも重ねて説明しています）。
この本は エキスパートの俺様が、初心者のために書いた本だ。初心者向けって所が重要な。ついでに世の中常識のないやつが多いから、プログラミングだけじゃなく常識まで教えてやる、そういう本でもあるな。そうそう、断っておくが俺がこの本で言っていることは「世の中の常識」な。だから、異論挟むヤツはそのまま「常識」のないやつってことになる。ここも重要だ。
プログラミングに限らず、対象によって説明の仕方、取り上げる範囲、そして「何が正しいか」は異なります。 身近な学校教育という場を考えてみても、小学生には「人はみな平等です」と教えます。 しかし、それは理想であって、実際に差別は存在し、したがって、教えている対象を考慮しなければ、 小学校で教えていることは嘘ばかりである、ということになります。 実際、大学生ならば、「実際には人は平等ではない」という前提にたって、社会問題などを考える必要があることは 誰にも異論のないことでしょう。
同様に、プログラミングでも、初歩のプログラミングの学習を終えた人と、 より高度なプログラミングをマスターした人を対象にするときでは、解説の範囲も表現もすべて異なります。
ところで、みんな平等というけどさ、愚民がいるのが現実なのよ。愚民がいるなら愚民向けに方便をつかわなくちゃいけない。大人ならわかるな。
本書について、文章の真意を理解しないで書き込みをされていることも多々あるようです。 たとえば、「プログラミング言語はどれがよいか？」というトピックの主眼は、本文で 「多人数を運ぶならバス、荷物をたくさん運ぶならトラック、少人数でドライブするなら小型セダンと、 目的に応じて最も良い自動車の種類が違う」と例をあげて説明していますが、プログラミング言語においても 用途やプログラマの経験あるいは環境等々によって適する言語は異なり、 特定の具体的な条件を示したうえでなければ「プログラミング言語はどれがよいか？」という質問自体がナンセンスである、 というのがこのトピックの主眼です。
したがって、それに関連する説明は、それぞれのプログラミング言語がおおよそどのように異なるかわかればよい という立場で書いており、具体的な解説についてはたとえば環境（近くにすぐに質問できる先輩がいる、 特定の言語の学習環境が際立って整っている、特定の種類の言語をすぐに使う必要がある、など）に よって異なるという前提で書かれています。
また、このトピックは、これから最初のプログラミング言語を選ぼうとしているか、 ふたつ目のプログラミング言語を選ぼうとしているような初心者で、 車にバスから軽自動車までいろいろな種類があるように、プログラミング言語にもまた さまざまな用途の言語があるということを認識していない読者を想定して解説しているものです。 すでに複数のプログラミング言語をマスターしている読者を対象としたときには、 自ずと表現も記述するレベルや範囲も変わってきます。
で、だ。俺の書いた本にケチつけるガキ共がいるんだけどさ、ヤツラ何？ 技術的なことを書くと低能なヤツラじゃ理解できないから、車の話に喩えてやる。（略）つまりヤツラは、車にもいろいろ車種ってものがあることすら、わかんないバカってことだ。
そのほか、本書について間違いであるかのように指摘されているところの多くも、本書の意図を理解できれば、 指摘したことが逆に誤っていることに気づくでしょう。 （もちろん、筆者が至らないために、間違いや勘違い、あるいは校正の際の見落としなども あるかと思います。そのようなことがないように努力はいたしますが、 お気づきの点があれば冷静にご指摘いただければ幸いです。）
また、本書の批判の多くは、本書が初心者プログラマ向けに書かれていることをまったく無視した、 きわめて無責任な意見が多く、そのような書き込みが何の批判もなく行われていることは残念でなりません。 良識のある人たちは、想定読者レベルを無視した無責任な意見は無価値であると考え 頭から相手にしていないのでしょうが、初心者はそのような判断ができないので惑わされる可能性があるからです。
ようするに、愚民向けの本を読んでも「方便」を「方便」だって読み取れないバカ？ww 指摘(笑)を通して 自分の馬鹿さ加減を世界に発信しているってことに気づかないって超ウケるじゃん？ この内容は間違ってます(キリッ みたいな？wwww ま、少しでも知性があれば、恥ずかしくてで出来ねえことだよな。
わかっているヤツは わざわざ DQN の相手をしたりせず鼻で笑うだけだ。しかしお前らひよっこは、こういう低レベルな扇動に惑わされるかもしれないな。気をつけろよ。
書籍の批評ということについて、ひとつ例を示して筆者の考えを明らかにしましょう。
B.W.カーニハン/D.M.リッチーが書いた「プログラミング言語C」という本があります。現在は第2版となり訂正版として出されていますが、 日本語翻訳初版から現在まで、プログラミング言語の本として名著のひとつとみなされてきました。
実際、私もC言語についてまだほとんど何も知らない日本語訳初版が出たときにこの本を一読して、 「Hello, world」の出力のしかたから始まり、徐々に高度な内容に導いてゆく書き方に自然となじんで、 まるで読み物を読むように一気に読了し、同時に、C言語とはどういうもので、何ができて、何ができないのかを理解しました。 日本語訳初版は間違いも多く、記述の仕方もプログラミング言語の書籍としては最良とはいえないものでしたが、 C言語についてまだほとんど何も知らない私にとって、まさに「プログラミング言語C」はとても良い本でした。 また、プログラミング言語の仕様という概念が今ほど確立していなかった当時、C言語のコンパイラを実装する（開発する） ようなレベルの人にも、「プログラミング言語C」はバイブルといってよいほど重要な本でした。
ところで、今、誰かが「プログラミング言語C」と同じようなスタイルでC++かJavaの本を きわめて丁寧に間違いもほとんどなく書きあげて私に献本してくれて私個人の率直な意見を求められたら、 それを読んできっと「冗長で退屈である」と答えるでしょう。 なぜなら、私はC++やJavaについて講義（授業や講演）をする程度にすでに知っているから、 「プログラミング言語C」のような書き方の本を改めて最初から読むのは苦痛にさえなりかねないからです。
しかし、その本について公開するレビューを書いてくれと頼まれたら、 「これからC++（またはJava）を学習する人にとってはとても良い本である」と推奨するでしょう。 なぜなら、まだ何も知らない人が、まるで読み物を読むように一気に読んでその言語を理解できれば、 それはとても素晴らしいことだからです。
読む人のレベル、その本の主眼とすることとその表現のしかた、本が出版されたときの状況などによって本の価値というものは異なり、 それが本というものです。
ヤツラにも解るように具体例を示すけれどさ、ストラウストラップ？ってヤツの 「プログラミング言語 C++」って本、冗長で退屈でダセェよな。内容のレベル低すぎるしさ。けど、どうしてもオレにレビューしてくれっていわれたら、まぁ「俺には必要ないけど良い本だぜ」って紹介してやるよ。だってバカどもにはちょうど良いじゃん。バカ向けの本はバカ向けってことを考慮して評価する。それが大人ってもんだ。
インターネットが普及して誰でも自由に発言できるようになったのは良いことですが 一部のお暇をもてあましている方々が、拙著に限らず、 さまざまな著作や著者に対して誹謗中傷に近い書き込みを匿名で行っているのが見受けられます。 このような状態が続けば、 誤解を受けることを承知の上で初心者向けにあえてやさしく解説するような著者は書く気をなくし、 どのようにでも解釈できる（あるいはすでに理解している人しか理解できないような）難解な 文章を書く一部のいわゆる権威だけが著者として残る結果となり、 出版文化や書店を含む出版界はますます疲弊し、いずれ現在のように多種多様な書籍が出版できなくります。
インターネットが出来てから、そんな大人の対応も出来ないウゼえガキが増えたよな。マジ ウゼェ。ったく、「間違っている」「正しくない」とか、ウゼェウゼェウゼェ！偉大なるオレ様のやる気が無くなったらどうしてくれるのか。これでオレが本を書かなくなったら人類の損失になるって事実、わかんねぇのかコイツらは。ほんっとカスだな。
どうか、初心者の方々は無責任な批判や的外れなレビューなどに惑わされずに、 まずは本を読んでみて（買わずに図書館で借りてでもかまいません）、自分自身で判断してくださるようお願いいたします。
まぁ、カスのことはほっといて、お前らは黙って俺の本を買っておけ（貧乏だったら図書館でもいいぜ。自治体に買わせろ）。普通に考えれば有象無象の匿名ブロガーより、本まで出してるエリートのオレの本の方が信頼できるってのは、ひよっこのお前らにだってわかるだろ。つべこべ言わず買えば幸せになれるってモンさ。
さて、無責任な批判や的外れなレビューを書き続けている人には、次のように申し上げておきます。
批判する人間にもし本当に能力があるのであれば、匿名で無責任な批判をする前に、 C++、Java、アセンブリ言語、JavaScriptのようなスクリプト言語、XMLやXAMLのような記述言語を 含めて、5種類上の言語で実際に動作するプログラムを作成してそのソースコードを広く一般に公開し、 他人の批判を受けてみてから、 自分で完璧な本を書いて出版社に持ち込んで出版してみてください。
そうすれば、著作、あるいは出版というものがどういうものか、少しはわかるでしょう。
あー、それと、バカどもに言っておく。オレ様は C++、Java、アセンブリ言語、JavaScriptのようなスクリプト言語、XML・XAML のよな記述言語 を含めた5種類以上の言語に精通した超絶スーパーエンジニアだ。ハッカーと言ってもいい。しかもコードを公開して完璧な本まで書いている、マジ パねぇ男だ。 マチュアーしてるんだよ。おめぇらなんて足元におよばねぇ。身の程を知れ。（関数型言語はマイナでどうでもいいから勉強しなくてもいいぜ。あ、でもオレの Scala の本は買えよな。）
もし、自らは何も創造しないで、単に無責任な批判や的外れなレビューを続けるなら、 そういう人は、いずれ何年かのちに（そのときまでボケずに、人間社会というものを学んで人間として少しは成長したとしたら） 自分がしてきたことが無意味であり、そのようなことだけに時間を費やした自分自身の人生そのものが 無価値であったことに必ず気づくはずです。しかし、その時になって謝罪していただく必要はまったくありません。
まー、オレ様は心が広いからバカがバカであることは責めないでやる。人間生まれついてのものはどうしようもねぇ。俺はどうしようもないことは責めない主義だ。でも、お前らが無価値なゴミクズであるってことだけは理解しとけよな。ゴミはゴミなりの人生がまってるさ。身の程を知って生きればオレは哀れみくらいはかけてやるぜ？
なお、著者はあらゆる書き込みに対していちいち反論することはできません。 また、一部の低俗な掲示板のようなものを読んだり書き込んだりするのは 時間の無駄なので、私に限らずほとんどの著者は、そのようなものに書き込むことはもちろん、 目を通すこともありませんのであしからず。
最後に言っておく。お前ら如きがオレ様に意見するなんて間違っている。なぜならオレ様はいつだって正しいからだ。そして、間違った意見などに反論を書くなんて無駄な時間はオレ様にはない。お前らはせいぜい便所で落書きに勤しむんだな。あばよ。
長い文章が読めない方のために、要点のまとめを作りました。
日向さんは、本当に素晴らしい技術力をお持ちで、その著書リストをご覧になれば皆様もその高い技術力をご納得いただけるかと思います。
http://www.amazon.co.jp/exec/obidos/search-handle-url?_encoding=UTF8&search-type=ss&index=books-jp&field-author=%E6%97%A5%E5%90%91%20%E4%BF%8A%E4%BA%8C
これだけの内容の濃い本を、こんなにも沢山発行していらっしゃるので、日向さんが新たに本を書い時、気がつけば参考文献リソース 一覧が 過去の自著ばかりになった――というエピソードだけでも、日向さんの凄さの一端が伝わるかと思います。
ですので皆様も
のような「匿名の愚か者」の世迷い言に惑わされないように、ご注意願います。解っている人から見れば、日向さんの著書は総じて評価が高い という事実は、「記名の賢者」であるdankogai氏のレビュー
をご覧になっていただければ、一目瞭然かと思います。（dankogai氏は同レビュー中で日向さんを「真に初心者向けに本を書ける希有の存在」と評しています）
なお、訳者はあらゆる書き込みに対していちいち反論することはできません。 また、一部の低俗な掲示板のような増田を読んだり書き込んだりするのは 時間の無駄なので、私に限らずほとんどの著者は、そのようなものに書き込むことはもちろん、 目を通すこともありませんのであしからず。
おお、反応をいただけるとは、どうもありがとうございます。
確かに保守的な内容と思われるかもしれないのですが、ここに書いたのは学部３年までの内容ですので、プログラミングをやったことのない生徒もいることを考えると、基礎からやっていったらこういう内容になるのではないか、と思います。
４年以降になると、さらにUMLや、3DCGなど、応用的な分野の実習も入ってきます。
他大学のシラバスも見てみたつもりだったのですが、このような内容の実習を行っている大学は他にもあるのかもしれませんね。筑波大学の授業や、CLUは面白そうだと思いました。
今はほとんどシラバスの内容をネットで見られるので、受験生が授業の内容を調べながら大学を選ぶことができるのですが、一つ一つ調べていくのは大変だと思います。
各大学の売りをみんなで宣伝しあったら、受験生の助けになるんじゃないかな、と思いました。
あと、scheme やっていないの？
残念ながらやってないみたいです。関数型言語については、一応MLを使った演習があるのですが、それほどサポートが手厚いとは言えなそうです。
大学教育について話題になっているようですので、私が卒業した、大阪大学基礎工学部情報科学科について書いてみたいと思います。
大阪大学基礎工学部情報科学科は、昭和45年に最初に国立大学に設立された情報工学関連学科のうちの一つで、コンピュータサイエンスの分野では日本で最も古い歴史を持っている学科、ということになります。
情報科学科の特徴は、そのプログラミング実習の充実ぶりです。入学すると、まずPascalというプログラミング言語で構造化プログラミングを勉強することになります。次にアセンブリ言語であるCASLを勉強し、Pascalとアセンブリ言語を応用してC言語を勉強します。またその後、スクリプト言語であるPerl、関数型言語のML、オブジェクト指向言語としてJavaを学習します。
また、言語だけではなく、コンピュータサイエンスの基本であるアルゴリズムやデータ構造についても幅広く学ぶことができます。
全ての実習は課題が出され、実際にコードを書かなければいけません。例えばC言語の授業の最終的な課題は、「shのようなシェルプログラムを作成すること」でした。最終的には、「Pascal風の言語をCASLに変換するコンパイラを作成する」という課題に取り組むことになります。
大阪大学は全体的に単位の取得が厳しいことで知られていますが、情報科学科も例外ではありません。もしプログラミングをあまりしたことがないのであれば、遅くまで実習室にこもることになると思います。だけど、それは情報工学の世界で生きていくためには必要な知識なのです。
実習で勉強する言語は、Javaを除くとあまり現在使われている主流の言語とは言えないのですが、様々な言語を学ぶのは「プログラミング言語はそれぞれに違いがあり、それぞれに適した用途がある」ことを理解することに繋がります。また大学を卒業してから、新しい言語を学ぶ必要が出てきたとき、それに対応する能力を磨くことができます。
日本の大学で、ここまで実戦的なコンピュータに関する教育を行っている場所はあまりないのではないか、と思います。コンピュータがどのように動いているのか、内部原理までしっかり教えてくれます。卒業生の進路は、研究者というよりは、エンジニアとして開発の現場で働くことが多いようです。
大阪大学の入試問題は、東大や京大と違って特殊な問題はそれほど出ません。努力でなんとかなるレベルだと思います。
情報工学は新しい分野なので、大学院で研究するために必要な知識は他の分野ほど多くありません。このため情報工学科では、3年生の夏に大学院の試験を受けて合格すれば、学部を卒業しなくても4年目から大学院に進むことができます。この仕組みを活用すれば、5年で大学院を卒業できます。実際、学部生の1/4くらいはこの仕組みを活用しています。
もちろん、ここに書いたのは情報科学科の全てではありません。ネットにも他に情報がありますし、もし興味があったら、大学のオープンキャンパスに行ってみるのもよいと思います。
コンピュータの世界は変化が激しくて、エンジニアとして生きていくのはとても大変ですが、それでもいい、プログラマとして将来何かを作りたいんだという人であれば、ここはそのための力を与えてくれるはずです。進学先として検討してもらえたら幸いです。
