技術評論社の本、サーバサイドJavaScriptとかC言語 [本]
いつも技術評論社の本のダイレクトメールが来るので、ぼちぼち読んでたまに買っています。技評の本は自分的にカテゴリーがハマっていて、仕事でも何冊か技評の本を買っています。パソコン関連の技術者向けの本が多いのですが、それだけじゃなくてテクニカルな方面とか、自然科学の方面の本も多く出しているみたいです。
個人的な会社ごとの分類、あるいは気分。
ソフトバンク…技術的に具体的な本が多い。具体的過ぎて潰しがきかなくて、すぐに陳腐化する
オライリー…日本人が書いた本もあるけど、多くを締める洋書の翻訳の水準が本によってまちまち。
マイコミ…主題とするカテゴリが狭いが、そこから広がってきて読み応えがあることも少なくない。
翔泳社…独習シリーズを始めとして、通読するには重く、簡単なリファレンスには使いにくい。
技術評論社…わりと時間によって陳腐になりにくい記事の本が多い。汎用的。
Rubyの本を見渡してみると、そんな感じ。
そんなわけで、気になった本をチェック。書かないとすぐ捨てて忘れちゃいそうなので、いつもの通り備忘録。
・サーバサイドJavaScriptの本。
なんじゃそりゃと思って、店頭で読もうとしたけど怪し過ぎてスルーした。ちょっと立ち読みしとけば良かったかなぁと少し後悔。
内容的には、クライアントの負荷をサーバに移して負荷分散しようって魂胆らしい。JavaなりPHPなりで普通にサーバで実装すればいいんだけど、同じ事をサーバでやらせるんだから、JavaScriptをサーバで走らせちゃいましょうや、という事らしい。確かにスマホとかの使用率が上がってくると、モバイル機器での負荷は低い方がいいので、サーバ側で処理した方がいいってことになってくるらしい。
確かに今までは無駄にスペックが良くて速かったデスクトップやノートマシンだったら問題にならなかった事も、電池で駆動させる上に電話の機能も落とせないスマホなどだと、何であれ処理は軽い方がいいわけで。JavaScriptの動作はマシンスペックのおかげでウヤムヤにされてきましたが、最近のWebページの使われ様からIEのJavaScriptの処理の遅さが露呈して、今HTML5の実装と並行して、高速化に頑張っているところみたいです。
ただ、インプリを使い回して楽しようという技術なので、技術的に全く萌えません。CommonJSとかがあるそうですが、JavaScriptの文法だけじゃなく、実装するAPIも決めておこうという動きがあるらしい。HTML5の後追いなのかな？ JSONはJavaScriptが読めるライブラリがあったから広まったみたいだけど、作ったり読んだりするのはYAMLの方がいいと思うんだな、僕わ。それと、避けて通れないHTML5。WebSocketとかWebWorkersなどは親和性良さげですね。などなど旬な話題も載っているようです。
・C言語のポインタの本と、ISO C99の本
永遠の極壁ポインタ、と題名が書かれていますが、C言語ってそんなに難しいものなのかな？ 確かに現在のLLなRubyやPythonなどの読むのも書くのも簡単な言語と比べると、何書いてんだか分からなくなる率は高い。そして、ポインタで分からなくなる率が高い。
ポインタの概念自体が難しいんじゃなくて、書き方がピンと来ない事が多いのと、参照する表現形式がちょっと変、というのが、かなりガンになっているような気がします。ポインタをインクリメントしてるのか、値をインクリメントしてるのか、いろいろ処理した形で一行に書かれていたりして、わかりづらいソースってのは普通にありますし、そこいらのところは演算子の優位の順序とか見ないと分からないってこともあります。本当はそういうソースをコメントなしに書いちゃいけないと思うんだけどね、僕としてわ。
ポインタを理解できない人は、mem何とか系の関数も分かりにくいと思うし、ポインタをわざわざ使う事の意味も分かりにくいから、ポインタを使ったコードが読んで分かりずらいなら、無理にでも理解しておいた方がいいと思います。そんなあなたにこの本。↓
最近の言語は、オブジェクト指向の要素が大抵入っているから、わざわざポインタの考えを導入するよりか、オブジェクト自体を参照形式の値にしている事が多いと思う。よく昔言われた、Javaにポインタはない、みたいな事ですよ。ポインタとしてメモリの値を直接触れさせないようにしているだけで、結局のところ、オブジェクトを参照形式にしてポインタを保持しているのは変わらないらしいです。ポインタはない、のではなくて、言語的にポインタを数字として渡さない、というのが分かるまでかなり時間がかかりました。
というか、C言語自体が低級言語に限りなく近いところが難しくしているのでしょうね。だから、アセンブラまで行くとダメだから、言語として一般化できるまで頑張りました、というのがC言語なのだろうと思う。だから、ポインタやメモリ操作をなるべく見せないようにして、ガベージコレクションなどで勝手にメモリの世話をする言語と比べちゃいけないし、C言語とアセンブラ程度の隔たりはあるのは当たり前です。RubyがC言語で書かれているっていうのも、メモリをいじくれるのがC言語だからという事情なんだろうと思います。何にしても、割り切りすぎで、ぶっちゃけ過ぎな言語なような気がします。
そういやC言語も少しずつ変化しているらしく、自分は始めから//をコメントとして使えるC言語を使っていたので、比較的新しい部類に入ると思うのですが、K&Rとかの記述法はあんまり好きではないです。K&R → ANSI C → ISO C90 → ISO C95 → ISO C99という流れがあるそうですが、そんな事は全然知らずに、C言語よりの変なC++のコードを作り続けていました。
結局、C言語はずーっと残る気がします。アセンブラは書きたくないし、C言語以上になると抽象度がずっと高くなるから、直接言語を実装するのは、ほぼ無理なんじゃないかと思います。C言語のすごいところは、C言語のコンパイラをC言語自ら作っているというところだと思います。始めはC言語のコンパイラってアセンブラで作られてるんでしょ、って知ったかぶりをしていましたが、自らを規定できる言語ってなかなかないんじゃないか、と思います。きちんと見たわけじゃないですが、アセンブラが使われているのって部分的だった気がします。
でも、今更、C言語標準文法とか買いたくないなぁ。あんまり役立ちそうもないし、今更標準を知ったところで、標準的に作ってうれしい事なんて、GNUのツール以上の利便性はないのだろうな、と思ったり。でも、C言語を始めから学ぶ人は、Webだけじゃなく、manとかの一次情報とか、こういうリファレンスを買った方がいいプログラマーにはなれると思います。
個人的な会社ごとの分類、あるいは気分。
ソフトバンク…技術的に具体的な本が多い。具体的過ぎて潰しがきかなくて、すぐに陳腐化する
オライリー…日本人が書いた本もあるけど、多くを締める洋書の翻訳の水準が本によってまちまち。
マイコミ…主題とするカテゴリが狭いが、そこから広がってきて読み応えがあることも少なくない。
翔泳社…独習シリーズを始めとして、通読するには重く、簡単なリファレンスには使いにくい。
技術評論社…わりと時間によって陳腐になりにくい記事の本が多い。汎用的。
Rubyの本を見渡してみると、そんな感じ。
そんなわけで、気になった本をチェック。書かないとすぐ捨てて忘れちゃいそうなので、いつもの通り備忘録。
・サーバサイドJavaScriptの本。
- 作者: 井上 誠一郎
- 出版社/メーカー: 技術評論社
- 発売日: 2011/04/20
- メディア: 大型本
なんじゃそりゃと思って、店頭で読もうとしたけど怪し過ぎてスルーした。ちょっと立ち読みしとけば良かったかなぁと少し後悔。
内容的には、クライアントの負荷をサーバに移して負荷分散しようって魂胆らしい。JavaなりPHPなりで普通にサーバで実装すればいいんだけど、同じ事をサーバでやらせるんだから、JavaScriptをサーバで走らせちゃいましょうや、という事らしい。確かにスマホとかの使用率が上がってくると、モバイル機器での負荷は低い方がいいので、サーバ側で処理した方がいいってことになってくるらしい。
確かに今までは無駄にスペックが良くて速かったデスクトップやノートマシンだったら問題にならなかった事も、電池で駆動させる上に電話の機能も落とせないスマホなどだと、何であれ処理は軽い方がいいわけで。JavaScriptの動作はマシンスペックのおかげでウヤムヤにされてきましたが、最近のWebページの使われ様からIEのJavaScriptの処理の遅さが露呈して、今HTML5の実装と並行して、高速化に頑張っているところみたいです。
ただ、インプリを使い回して楽しようという技術なので、技術的に全く萌えません。CommonJSとかがあるそうですが、JavaScriptの文法だけじゃなく、実装するAPIも決めておこうという動きがあるらしい。HTML5の後追いなのかな？ JSONはJavaScriptが読めるライブラリがあったから広まったみたいだけど、作ったり読んだりするのはYAMLの方がいいと思うんだな、僕わ。それと、避けて通れないHTML5。WebSocketとかWebWorkersなどは親和性良さげですね。などなど旬な話題も載っているようです。
・C言語のポインタの本と、ISO C99の本
永遠の極壁ポインタ、と題名が書かれていますが、C言語ってそんなに難しいものなのかな？ 確かに現在のLLなRubyやPythonなどの読むのも書くのも簡単な言語と比べると、何書いてんだか分からなくなる率は高い。そして、ポインタで分からなくなる率が高い。
ポインタの概念自体が難しいんじゃなくて、書き方がピンと来ない事が多いのと、参照する表現形式がちょっと変、というのが、かなりガンになっているような気がします。ポインタをインクリメントしてるのか、値をインクリメントしてるのか、いろいろ処理した形で一行に書かれていたりして、わかりづらいソースってのは普通にありますし、そこいらのところは演算子の優位の順序とか見ないと分からないってこともあります。本当はそういうソースをコメントなしに書いちゃいけないと思うんだけどね、僕としてわ。
ポインタを理解できない人は、mem何とか系の関数も分かりにくいと思うし、ポインタをわざわざ使う事の意味も分かりにくいから、ポインタを使ったコードが読んで分かりずらいなら、無理にでも理解しておいた方がいいと思います。そんなあなたにこの本。↓
C言語 ポインタが理解できない理由 ［改訂新版］ (プログラミングの教科書)
- 作者: 朝井 淳
- 出版社/メーカー: 技術評論社
- 発売日: 2011/04/08
- メディア: 単行本（ソフトカバー）
最近の言語は、オブジェクト指向の要素が大抵入っているから、わざわざポインタの考えを導入するよりか、オブジェクト自体を参照形式の値にしている事が多いと思う。よく昔言われた、Javaにポインタはない、みたいな事ですよ。ポインタとしてメモリの値を直接触れさせないようにしているだけで、結局のところ、オブジェクトを参照形式にしてポインタを保持しているのは変わらないらしいです。ポインタはない、のではなくて、言語的にポインタを数字として渡さない、というのが分かるまでかなり時間がかかりました。
というか、C言語自体が低級言語に限りなく近いところが難しくしているのでしょうね。だから、アセンブラまで行くとダメだから、言語として一般化できるまで頑張りました、というのがC言語なのだろうと思う。だから、ポインタやメモリ操作をなるべく見せないようにして、ガベージコレクションなどで勝手にメモリの世話をする言語と比べちゃいけないし、C言語とアセンブラ程度の隔たりはあるのは当たり前です。RubyがC言語で書かれているっていうのも、メモリをいじくれるのがC言語だからという事情なんだろうと思います。何にしても、割り切りすぎで、ぶっちゃけ過ぎな言語なような気がします。
そういやC言語も少しずつ変化しているらしく、自分は始めから//をコメントとして使えるC言語を使っていたので、比較的新しい部類に入ると思うのですが、K&Rとかの記述法はあんまり好きではないです。K&R → ANSI C → ISO C90 → ISO C95 → ISO C99という流れがあるそうですが、そんな事は全然知らずに、C言語よりの変なC++のコードを作り続けていました。
結局、C言語はずーっと残る気がします。アセンブラは書きたくないし、C言語以上になると抽象度がずっと高くなるから、直接言語を実装するのは、ほぼ無理なんじゃないかと思います。C言語のすごいところは、C言語のコンパイラをC言語自ら作っているというところだと思います。始めはC言語のコンパイラってアセンブラで作られてるんでしょ、って知ったかぶりをしていましたが、自らを規定できる言語ってなかなかないんじゃないか、と思います。きちんと見たわけじゃないですが、アセンブラが使われているのって部分的だった気がします。
でも、今更、C言語標準文法とか買いたくないなぁ。あんまり役立ちそうもないし、今更標準を知ったところで、標準的に作ってうれしい事なんて、GNUのツール以上の利便性はないのだろうな、と思ったり。でも、C言語を始めから学ぶ人は、Webだけじゃなく、manとかの一次情報とか、こういうリファレンスを買った方がいいプログラマーにはなれると思います。
C言語標準文法 ポケットリファレンス ［ANSI C、ISO C99対応］
- 作者: 河西 朝雄
- 出版社/メーカー: 技術評論社
- 発売日: 2011/04/14
- メディア: 単行本（ソフトカバー）
Cは確実に残るでしょうね。組み込み系のフロントエンドはハードウェアまで抽象化されたら困るし。
それどころかハードウェア記述やシステム記述といったコンピュータ以外のところでもCライクな言語がつかわれてて、もはやデファクトスタンダードってやつになってますね。
by 7700 (2011-06-23 20:28)
C言語ってなんやかや言っても使いどころが便利なんですよね。ライブラリはそんなに便利じゃなくても、ハードウェア寄りからアプリケーション寄りまで全部行けちゃうってのは、めちゃくちゃ汎用性がありますね。
とはいえ、おっしゃる通り、組み込み系、別の言語を作る、Linuxとかのシステムなどの所以外はどんどん減っていっているのだろうと思います。となると、C++とかもっと使われなくなりそう。だって標準ライブラリはたいして使いやすくもないし、C言語的なポインタが使える危険性が残ってますしね。そういやC++でガベッジコレクションを使うとか聞いた事ないですね。なぜだろう。
by miff (2011-06-24 10:40)
サーバーサイドJavaScriptはクライアント側と同じ言語が使えるというのはあくまでオマケで
その真髄は大量のアクセスを効率よく掃ける非同期処理にあります
by 名無し (2011-06-24 11:31)
おいでませ、名無しさん。
んーオマケが大事な事って多いんですよね。おっしゃられる通りに、非同期処理がさくさく使えるって話が肝心なのでしょうけど、言語って曲がりなりにもある程度理解して書ける人が多いって事が何よりも必要です。
Javaがミッションクリティカルな場面にすら使われるようになったのも、言語の素養もそれなりにあると思うのですが、書ける人が多くてそれなりにDBへの機能が充実しているってことにあったんだと思います。なので、COBOLをずっと使ってるわけにもいかんだろう、という気持ちよりも、書ける人をすぐに雇えるというマンパワー的な理由が多いと思います。
それに、非同期なんちゃらの話は、実装の問題だから、言語がどうあれそんなに違いはないと感じます。LLな言語で非同期処理でってのはどのくらい効率的かが見えないので何とも言えません。でも、ちょっと気になるので、上で紹介した本を気合い入れて立ち読みしてみようかなぁ（って買えよ）。
って口が悪いこっちの記事が気になる。JavaもライブラリとIDEで楽できて、細かい所の記述言語に成り下がっているという話。
http://anond.hatelabo.jp/20110210084023
LLな言語って使いどころだよね。人月でかっちり仕上げないといけない規模がでかめの案件はJavaでないとダメだって話で、LLが大規模がうれしくないってのは始めから言われているし。というか私的にはHadoopがJavaで実装されているくらいの事しか気にならねーのだが。
っつうか、はてなはPerlが主じゃないの？ 使えないシステムばっか作ってるhatelaboの人に、でかいシステムうんぬんの話をされたくないものである。
by miff (2011-06-24 11:57)
実用性からいうとかなり下がるけど
プロとしてプログラミング、アーキテクチャを覚えようとしたら、C言語は最高の教材ですよね。
ドット演算子もアロー演算子も使ってるし、三項演算子も使ってるから、PerlやPHP見てもついていけます。
構造体や共用体があって、ポインタを操作できる。しかも、ネイティブなオブジェクト指向ではない。だから、オリジナルな方式でクラスベースアーキテクチャを実装することができます。
たとえば、構造体のメンバに関数を組み込んじゃえばクラスになります。で、その構造体をポインタ参照すりゃオブジェクトですね。さらに共用体を使って継承すれば、かなりオブジェクト指向ライクですよ。
PerlやPythonみたいな参照カウンタ方式でもいいし、JavaみたいなGCでもいい…全く実用的ではないが、OSやLLやオブジェクト指向の動作原理を理解するにはもってこいの言語…それがC言語であります。
JavaやLLプログラマは、教養としてC言語くらい分かっておきましょう。こんな程度のものについてすら分かることができない方は、プロの世界からは引退して日曜プログラマにでもなった方が社会のためですよね。
by ばしくし (2011-11-14 05:52)
いや、仕事としてだけプログラミングしているのであれば、必ずしもC言語は必要ないと思います。むしろ他の言語を知らない方がすんなり仕事できるってものです。変に他の言語の常識を持ち出されて混乱するってこともないわけですから。
それに日曜プログラマの方が、こういう知識が役に立つことが多いし、日曜でやっている方がレベル高かったりする事がままあるのですがね。色々知っている事は、実用性よりも自己満足な事が多いので、悪い事ではないにしても、すべてのプログラマに強要する事ではない気がします。
C言語は言語的に汎用性が最強であることは間違いないでしょうね。
by miff (2011-11-27 18:35)