  |
はてなキーワード: スクリプト言語とは
ソフトウェア開発プロジェクト（一定規模以上）がトラブルが起こって納期までに終わりそうにない、赤字が出てでも終わらせないと困る時の別解
色々な方法があるんだけど、その中でもなぜかこういう方法をとるところが案外少ないように思われるので…。この方法はもちろん万能じゃないので、「こんな欠点がある」って突っ込みはいっぱいあるでしょうが、「いついかなる時でも使えない」話ではないレベルです。
・増員する、ただし、雑用係専用部隊を大幅に。
→業務メインをやる人が増えるとコミュニケーションコストが増大してかえって遅延する現象は散見されますので、そういうコストが相対的に起きにくい仕事になるべく人を投入するという発想です。
ただ、これは、「低時給バイトさん」「事務職」ではだめです（チームの中にそういう人を入れるのはいい場合も多々ありますが、「低時給バイトさん」「事務職」ばかりを多数入れてもソフトウェア開発では大抵困ります。つまり、PG/SEレベルの、ソフトウェア開発の一般常識のある単価の高い人を敢えて雑用や事務に投入するんです。これの一つのデメリットはSE/PGにそんな仕事をさせるとモチベーションが下がって当然なので、長期には向きません。プロジェクトが長いなら少しずつメンバーを入れ替えながらがベターかと。
例）「このデータ加工しといて」と振ってExcelベース（関数とかVBAは使えてよ）なりスクリプト言語なりで加工する人
例）コピーを頼まれたらそれに徹する人 …ここだけ見ると単価高い人をそんな仕事に、と思うかもしれませんが、変にチームに投入して遅延を拡大させるのとどっちがいいんですかって話ですよ。
議事メモではなく議事録が必要なら、録音してテープ起こしするのの草稿を別の人がやる（ここ例えメインの仕事に入ってなくともSE/PGかどうかで品質が随分違う。もっというと、草稿の草稿は音声認識ソフトにやらせる手もある 録音レベルが悪いときついけど）…これは普通のプロジェクトでやってもまずコスト的に割が合わないでしょう。あくまでここに書いているのはすべて「赤字が出てでも早く終わらせる」みたいな特殊な状況なのでやってみるといい場合があるんじゃないの、というお話です。
例）必ずしも雑用ではないが、特にキーマンには秘書をつけてしまえ。その人のスケジュール管理から色々とね。秘書検定もってるエンジニアとかいたら最高ですが（どんだけおるんや） この人に用事があるんだけど今取り込み中…みたいな時って用事がすんでからタイムリーにってなかなかいかないんですよね。秘書がいたらなんとかできませんかね？
人を横断して作業効率化を図れる書類の自動化とか可能なら専任作ってExcel VBAでもスクリプト言語でもなんでもいいので作ってしまえ。
・アメニティの充実を図る。
機材のせいでボトルネックになってませんか？PCの性能は大丈夫ですか？ディスプレイは大きいですか？プリンタやコピー機の数は足りてますか？プリンタやコピー機の速度は十分ですか？カラー印刷出来ますか？ファイル共有サーバが遅かったりしませんか？ ※PCを変更すると環境移行コストはかかりますが、一時的なものです。
事務専門でも出来る所では「コピー用紙がなくなってから補充までにタイムラグとかないですよね」とか
ポットに沸かしたお湯が空っぽとかないですよね？ …まぁこれはエンジニアじゃない人に任せてもいい領域。
ホワイトボードに書いたものを電子データでPCに送れるとかいまどき常識ですよね？丁寧に書いてあったらOCRも可能ですよね？
経費で、高いのでいいからうまい弁当をオフィス配達してしまえ ※税金の問題等色々あるし、自分で選んだり外食に行く方が効率上がる人もいるので全員ってわけにはいかないんですけど。希望者だけでも。
赤字覚悟で増員してるのに、人を増やしたけど「予算がないからPCにいいのが調達できなくって」って話は実在するようですが、何かおかしくないですか？
1人月60万とか100万とか何人も入れるのに。会計上の問題とか壁があるので表面的な金額では決められないんですけど、でもおかしくないですか？
あ、上記のようなことを実際にやって酷い目にあったエピソードがあったら教えてください。「うまくいかない場面」なんて当然いくらでもあると思うので。
Pythonをかれこれ5年ほど使っているけれど、いい加減頭にきた。
大体頭に来るような内容というのは限られていて大体は
http://www.aoky.net/articles/steve_yegge/tour_de_babel.htm
本当にPythonを殺し、メインのスクリプト言語となる望みを、あるいは何であれメインの言語となる望みを絶ったのは、永久凍土の問題なのだ。人々はいまだ埋め込みインタプリタにTclを使っている。どのような面から見てもTclよりPythonの方が遥かに優れているというのに——ただし永久凍土の問題を別にすれば。
これに尽きる。
よく言われるが、インデントに縛りがあるのもselfが付くのも慣れてしまえばさほど気にならないし、むしろ魅力的とも感じる。
しかし、Pythonを本当の意味で糞たらしめて居るのはその言語を使っているコミュニティがあまりにも思考停止しているからだ。
インデントやselfが気に入らないなんて些細な問題を他の言語使いから散々文句を言われたがために、本当の意味で言語の弱点になっている部分が指摘された時にも「それは言語仕様が悪いんじゃない。言語仕様に沿って考えられないお前の頭が悪いだけだ」と言ってくる。
実際のところ、Pythonの仕様には言い逃れのできない仕様の穴は幾つもある。もちろんよく引き合いに出されるRubyやPerlにも仕様の落とし穴は山ほどある。仕様の穴そのものは実はそんなに深刻な問題ではない。
真に問題なのは、Pythonコミュニティはその仕様の穴を断じて穴と認めない事だ。
言語同士でdisり合いになったとき、何かその穴をつつかれた場合の各人の反応はおよそこんな感じだ。
Perl使い「そうだよね、そこの仕様は頭悪いよね。でもPerl6のこの機能使えばこんなに短く綺麗に書けるんだぜ(と全く読めないコードを出す)」
Ruby使い「うんうん、仕様の話題でもそこは殺人現場とか呼ばれてるね。コミュニティ的にはこっちの機能を使うことを推奨しててそっちはobsolatedだね」
PHP使い「それ言い出したらこっちにこんなに大きな地雷あるし、この地雷なんてもっと大きいぜ。ほんとPHPは地獄だぜ」
Python使い「お前の思考通りに言語が動くんじゃなくてお前の思考を言語に添わせるんだよ、言語の挙動すら理解せずに使おうとするんじゃねえ」
こんな感じに、まず最初に質問者へ人格攻撃を行う。インデント言語であることやselfの問題について未熟なプログラマからのどうでもいい指摘を散々受け流してきたPythonコミュニティは、言語仕様について文句を言われる事に慣れているためまず相手を攻撃する。初心者を寒波が洗礼するのだ。
言語仕様が汚くなっている事まではどの言語も一緒なのだけれど、Pythonコミュニティだけは欠点を認めず必死に(∩ ﾟдﾟ)アーアーきこえないという態度を取る。
これこそがPythonを糞言語たらしめる最大の弱点である永久凍土の問題。コミュニティが凍れば言語の進歩も凍る。
先日「Flashエンジニアが今後10年食べていくには？」というテーマを元に
Flash に精通した Web 技術者達のディスカッションが行われる催し物があった。
http://www.publickey1.jp/blog/11/flash10.html
この記事だけでは内容が省略しすぎているため
時間があれば是非録画の模様もみていただきたい。前半初頭は音量が小さいので注意。
こういった催し物は面白いなと、私はとても楽しく見させていただいた。
http://www.ustream.tv/recorded/19073524
http://www.ustream.tv/recorded/19074357
ディスカッションでは Flash だけではなく HTML5 についても触れている。
ディスカッションの感想をディレクションや営業を行なっている知人に聞いたり、
ネット上の反応を見てみたところ以下のような意見がいくつかあった。
「『Flash が好きな人』だけではなく HTML5 派の人との対談もあればよかった」
「Flash 派の人の話だから HTML5 が使えないという話はいまいち参考にならない」
『Flash 派』『HTML5 派』という くくりで考えてしまう人は
まだまだ多いと実感する。
パネリスト達は
過去から現在までに様々なプログラミング言語を利用し、あらゆる技術に精通している。
Flash という表示媒体/環境開発がベター(時にはベスト)だと考え、
Flash をよく扱っている、という旨を話している。
最後の締めとして
Flash よりも優れたものが登場するのであればそちらに移行するでしょう、
とも言っている。
これだけの説明があったのに
ディスカッション内で触れた HTML5 に対する否定的な話は、
『Flash 派』とやらのポジショントークだと目に写ってしまったのだ。
Java やら C やら objective-c やら perl やら php やら
サーバサイドからスマホ用ネイティブ言語を用いてのアプリ制作まで
色んな事やってます、と言っても
現在世の中には HTML5 を推し、合わせて Flash を否定する記事が結構出回っている。
技術者が話す専門的な用語の飛び交う話よりも
HTML5 vs Flash 的な読みやすい記事に耳を傾けてしまう人はいる。
Apple 製品を好む人は「ジョブズがそう選択したのだから」と
なおさらこういった記事に目を向けてしまう。
「Flash vs HTML5 の話にのせられてしまうのは、よくわかっていない人だ。」
ディスカッション内では、
ネット上の煽り記事を読み不安に思ったクライアントから連絡を受け
きちんと状況をゼロから説明するハメになってしまった、という内容があった。
似たような状況になっている人もいるのではないだろうか。
当方周辺では、
「Flash は駄目だ」「Flash でなくても HTML5 ならできるはずだ」
「HTML5 は Flash の代わりになるものだと言われている」と
クライアント、あるいは仕事先の関係会社から耳にする機会が増えてきた。
技術者の及ばないところで
ベターではない技術が選択、あるいは勧められてしまう やっかい性。
その記事は世間の目には届かない。
TV CM でバンバン流れている iPhone や iPad では Flash を見ることができない
という状況に乗じた
勘違いを正すためには、今までよりもより一層
あるいはメッセージを発信するよう心がけていかねばならないと感じる。
パネリスト達のような
Flash を扱う事が可能な技術力を持ち合わせている人にとって
Flash が終わろうが、代わりの技術が HTML5 やらその他何になろうが
大した影響はない。
『プログラミング』についての話をしてみる事にする。
「世にあらゆるプログラミング言語があるが
「何か一つ言語を習得し
『Flash の事は全く知らないがプログラミングプロフェッショナルの人』
が近くにいるならば是非上記について伺ってみてほしい。
その通りだと答えてくれるはずだ。
他の言語で作ったものを Flash のプログラミング言語に移植することも容易いのだ。
ここで上記三行の「他の言語」を「JavaScript」に置き換えてみてほしい。
HTML の DOM 操作に必要な言語は JavaScript である。
言語は、Flash ならば ActionScript、HTML5 ならば JavaScript を用いる。
画面描画は
あるいは用意されている描画用 API を ActionScript で呼び出し、
あるいは用意されている描画用 API を JavaScript で呼び出す。
Flash と似たような技術として Java Applet や Shockwave があるが、
これらも一緒で
言語を変え、その技術に合わせた描画を行う処理を記述するだけだ。
Web 技術者が何かに属していて、何かには属していないかのような区別の仕方は
的がはずれている事を なんとなく感じていただけただろうか。
仕事に対し、あるいは表現したい事に対し、ベターな選択を行うだけの事なのである。
環境や表示内容に合わせ両方を採る選択もあるだろう。
パネリストの中に ActionScript が好きだ、という人がいた。
これは別に
Flash が好き(製品のファン)だから ActionScript が好き、と言っているのではない。
ActionScript が優れたプログラミング言語だと判断しての発言なのだ。
HTML5 を選択するだけの事であり、
その別の技術を選択し、
Flash より優れた技術が登場しなければ Flash を使い続ける、
ただそれだけの事なのである。
もう少し突っ込んだ話をすると
Flash のプログラミング言語である ActionScript(ActionScript 1.0)と
HTML 表示制御を行う言語 JavaScript は 実は同じ言語仕様である。
『ECMAScript』という単語で調べてみてほしい。
「Flash と HTML5 は対立するもの」と考えていた人、
あるいは ActionScript や JavaScript を触れたことがない人にとって
「え？そうなの？」と思う人もいる事だろう。
JavaScript は大規模開発に向いていない、という話は聞いたことがないだろうか。
同様の言語仕様である ActionScript 1.0 はこの問題を解決するため
ActionScript 2.0 から ActionScript 3.0 へと進化していった。
Flash は開発がし易い、という話がよく挙げられるが
その理由の一つがこれである。
現行の JavaScript と ActionScript 1.0 は ECMAScript 3 準拠に対し、
ActionScript 3.0 は ECMAScript 4 準拠である。
言語として進化しているものを Flash は採用しているので
開発は抜群にし易い。
ECMAScript 4 準拠の JavaScript も登場する日もあったかもしれなかったのだが、
ECMAScript 4 標準化が白紙、
ECMAScript 4 は無かったことになってしまったのだ。
ActionScript 3.0 で作成したプログラムが
ちなみに JavaScript は大規模開発に向いていない、という事に対し、
最近では Google が新言語 Dart というものを開発している。
位置づけとしては ActionScript 2.0 に近いと比喩した人もいる。
ActionScript 2.0 はコンパイル時 ActionScript 1.0 に変換されて出力される。
Dart も同じく JavaScript 変換機能を持つ。
先の事は誰にもわからない。
HTML5 が成長するとは必ずしも言えない。
技術者は身を持って知っている。
表示と動作の差異、技術者はずっと苦しめられてきている。
めんどくさい。コストがかかる。
HTML5 も同じ道を辿るのでは、と言われてしまうのも仕方がない。
実際に HTML5 の各ブラウザの実装具合はバラバラである。
Flash はといえば、
今でも 10年以上前のスクリプト言語 (ActionScript 1.0 よりも前の言語)で
Flash が動作するブラウザがいつまで携帯に搭載され続けるのか、
まだ誰にもわからない。
今後も当面携帯向け Flash を作り続ける事になるのかもしれない。
携帯向け Flash は一つの容量が小さいというのが救いである。
IE6 対応 HTML サイト制作にせよ、携帯向け Flash 制作にせよ
状況に応じて何を選択するかを判断できるほどの技術力を身につける事
選択する技術に何ができて何ができないのか、
どの技術を組み合わせるとよいのか、
自ら判断できるようになった時、一人前の Web 技術者になったと言えるだろう。
一つ何かをモノにしてしまえば前述の通り移行は容易い。
それを極めるくらいまでとことん勉強してほしい。
続けていくと見えてくるはずだ。自信という名の悟りの道が。
気になった点をいくつか。
現状の HTML5 の実装具合のバラバラさに対し、
「(HTML5の)表示の差分を埋めてくれる何かが登場するかもしれない」
と言う発言があった。
言った当人も会場にいる人達も、きっとこう思っただろう。
「それってなんて Flash Player？」と。
「あれはやめたほうがいい」という発言があった。
勝手に注釈するのであればこの発言は
「Flash で作られた重たい Web を HTML5 でまた再現するつもりなの？」
という皮肉であろう。
2010/05/16 23:40
こんにちは。昨日会った者です（これで特定するには情報不足だけど、まあわかるよね）。
で「幅優先探索でやる」という方針自体はいいと思うし、データ構造の作り方も基本は押さえていると思います（斜め読みしかしてませんが）。
ただ、コーディングの発想が「C で作る」という大方針から見て、少しちぐはぐな印象も受けます。データ構造の設計や操作の部分、汎用のライブラリを作ろうというのならあれでもいいと思うのですが、わざわざ汎用のライブラリを使わずに自分で専用の道具を一から作ろうというのなら、問題の性質を考慮して能率良くやることが大事です。
ところが、ここに載っているコードを見ると、見かけが C らしくなく、C++ や Java の劣化版のような印象を受けます。記法（マクロを大文字化しない、ルーチン名を大文字で始めるなど）だけの問題ではなく、データ構造の設計思想が「C で書く」という方針と矛盾しているように見えます。
もう少し具体的に言うと、そもそも C というのは現在 Web 系の世界などで流行のスクリプト言語類とは逆で、汎用言語でありながら低レベル（ハードウェアに近い）処理が簡単にできることに特色があります。つまり、組み込みを想定してプラットフォーム非依存のコードを書いたり、ハードウェアの特性を考慮して低レベルな最適化をやりたいというときに適しています。
そこでこの問題ですが、これを C でやるということは、処理速度や使用メモリ量の最適化が要求される状況、つまり迷路の大きさが途方もなく大きいような状況を想定すべきです。もっと言ってしまえばこの問題、たとえば画像処理などで似たような発想が要求されることがあります。このため、どうすれば時間のかかる処理を切りつめることができるかを考えてやらねばなりません。
このプログラムの場合、時間のかかる処理の代表格である malloc() が大量に使われています。これはいかにもまずいです。このような大量データを処理する場合の定石は、あらかじめ必要なだけメモリを確保しておいて、自分で割り当てることです。具体的には、必要と想定される量だけメモリを配列の形でどかっと確保しておいて、配列のインデックスをポインタ代わりに使います。そして、足りなくなったら倍々のような感じでメモリを realloc() してやればよいのです。
なお、そのような観点で言って、木の各節点の子の数は高々 4 （スタート地点が内点でないとすれば 3）であることを使っていることはよいと思います。ここで「子のリスト」とかを作ってしまっていたらこれはもうアホもいいところですから（容量の節約にすらなりません）。
そんな感じでしょうか。
とにかく、この手の問題は、アルゴリズムさえわかっていれば可読性もヘッタクレもないので、「短く書く」というような表層的なことよりも、何が求められているのかをよく考えて、柔軟に設計思想を考えることが大事だと思います。
2010/05/17 13:54
Oさんですね。専門的なコメントありがとうございます！cで書くと言いつつObjective-Cっぽい発想で書いていました。マクロの命名もその影響で、関数はImage Magickなどに似た命名規則になっている気がします。mallocを使いすぎると時間がかかるということは全然意識していませんでした。今度作るときはメモリ管理を自前で用意する発想を取り入れてみたいです。参考になるコメントありがとうございました！
プログラミングは静的言語(C/C++,Java,C#など)と動的言語(rubyとかpythonとかperlとかいわゆるスクリプト言語)と関数型(lispとかF#とかhaskellとか)を一つずつくらい眺めた方がいいと思う。
どれか一個くらい自分に合ってるのが見つかるかも。
やりたいことにどの実装系が一番適しているかを考えるべきで、実装系を目的に合わせるべきじゃない。
そういう考えでいると、PHPで何でもやる奴とか出てきて迷惑なんだ。
そもそものロジック構築などは、ターゲットには依存しても、言語にはほとんど依存しない。
馴染むための登竜門って意味で言えば、VisualStudioなどのGUIでデバッグが出来る環境をもった言語が良いし、VB,C#などのサンプルが豊富で結果を確認しやすい言語が良いと思う。
ここがどういうことを言ってるのかちょっとよくわからないんだけど、
アプリ間の依存関係はまぁそれほど問題にならないからどうでもいいかな。
下位レイヤがほんと酷い。
dllだのランタイムライブラリだの、スクリプト言語の実行環境だの何だの
パッケージ単位で全部解決させようとするからどのインストーラにもいちいちpythonとか入ってやがる。
逆にその辺がまとまってないソフトを入れようとすると、依存関係を自分で解決する必要があって大体ハマる。
管理システムへの登録スクリプト環境をきちんとしとけば（例えばmacのhomebrewはrubyに統一されてる）、
http://anond.hatelabo.jp/20110731225757
爽やかで頼れる職場の先輩のWebサイトを、同僚たちと訪問する事になった。
そうしたらその先輩が、ちょっと照れたように、でも爽やかに
「ちょっとサーバーサイド・スクリプトとかがいっぱいあるけど許してね」と笑う。
同僚たちとワイワイ問い詰めてみたら、『CakePHP』のフレームワークだそうだ。
先輩曰く「奥さんと二人で、一昨年くらいからハマっちゃって」らしい。
うっかり「Google App Engine ですか」とか言わなくて良かった。
何よりも、スクリプトを普通に実装して普通にその事を話せる点が、大違いです。
もちろん、同僚たちの誰も引いたりしない。
一口にスクリプト言語が好きって言っても、何かもう色々根本的に違う。
適わねーなー、と思いました。
そんだけ。
こんにちは、プログラミングをしているただの女子です。私は学歴も知識もありませんしブスですが、staticに関してはプロフェッショナル。今回は、モテるstatic女子力を磨くための4つの心得を皆さんにお教えしたいと思います。
あえてnewを使ってインスタンスを生成するようにしましょう。そして飲み会の場で好みの男がいたら話しかけ、わざとらしくパソコンを出してインスタンス生成してみましょう。そして「あ～ん！ この言語本当にマジでチョームカつくんですけどぉぉお～！」と言って、男に「どうしたの？」と言わせましょう。言わせたらもう大成功。「プログラミングとか詳しくなくてぇ～！ ずっとこのオブジェクト指向言語っていうやつ使ってるんですけどぉ～しっくりこないんですよぉ〜！いちいちnewって書かないといけなくて使いにくいんですぅ～！ ぷんぷくり～ん（怒）」と言いましょう。だいたいの男はインスタンスを生成せずに、すべてstaticな関数でプログラムを書く習性があるので、newなんてキーワードは使っていないはずです。
そこで男が「static関数使わないの？」と言ってくるはず（言ってこない空気が読めない男はその時点でガン無視OK）。そう言われたらあなたは「なんかなんかぁ～！最近SQLが人気なんでしょー!? あれってどうなんですかぁ？ 実行時に一行ずつコンパイルするスクリプト言語と違って、もっとも高級な言語なんでしょ？でもなんかよくわかんなーい。私かわいそーなコ★」と返します。すると男は「あぁあいつね、あいつ俺の友達なんだ、イイヤツだろ」といってくるので、そのまま調子に乗らせておきましょう。
「ファイル内ローカル関数」や「関数自体で状態を持つ」ことなどができる「static」をとにかく無闇につかうと、一般のstatic男性は「この子はstaticを愛してるんだなぁ」や「え？こんなところにもstatic使えるの？なにこれ？」と思ってくれます。インターネット上ではそのような〇〇おじさんや、××おじさんなど、変なひとがいるので、よいこの皆さんは関わらないようにしましょう。
飲み会などで男が女性に話すことといえばstaticの話やVBの話ばかり。よって、女性にとってどうでもいい話ばかりです。でもそこで適当に「へぇーそうなんですかぁ～？」とか「よくわかんないですけどすごいんですねぇ」と返してしまうと、さすがの男も「この女ダメだな」と気がついてしまいます。ダメ女だとバレたら終わりです。そこは無意味にテンションをあげて、「えー！ なにそれ!? 知りたい知りたーい♪」と言っておくのが正解。たとえ興味がない話題でも、テンションと積極性でその場を乗り切りましょう。積極的に話を聞いてくれる女性に男は弱いのです。
いろいろと話を聞いたあと、「staticな関数を使えば、newって書かなくていいんですねー。覚えたぞぉ！ メモメモ！」とコメントすればパーフェクト。続けて頭に指をさしてくるくる回しつつ「キュンキュンキュン！ キュンキュンキュン！」と言って、「どうしたの？」と男に言わせるのもアリ。そこで「うるせぇハゲ」と言えば女子力アップ！ そこでまた男は「オブジェクト指向ってしっくりこないんですよね〜オブジェクト指向って(ry」と連呼して壊れだすので、放置しておきましょう。
男とプログラミングするときは、とにかく「あーん！ 私インスタンス生成ないんですよねぇ～（悲）」と言いましょう。するとほぼ100パーセント「え？インスタンスなんて生成する必要ないじゃん。static理解せずにわざわざインスタンス宣言してるやつなんて笑っちゃうよね〜」といわれるので、(こいつなんなの・・・)と心のなかで思うだけにして口には出さないようにしましょう。ここでまた100パーセント「どうしたの？」と聞かれるので、うつむいて3～5秒ほど間をおいてからボソッとこう言います。「そうですよね〜staticおじさんカッコイイ〜」と心にもないお世辞を言っておきましょう。
その瞬間、あなたの女子力がアップします。きっと男は「なんて優しい天使のようなコなんだろう！ 絶対にゲットしてやるぞ！ コイツは俺の女だ！」と心のなかで誓い、あなたに惚れ込むはずです。そういうやつより上にのし上がったら、そんなことは忘れて好きなだけインスタンスを生成して大丈夫です。「インスタンスを生成できないんじゃなかったっけ？」と言われたら「は？」とか「うざい」や「おまえは一生C言語でもかいてろ」と言っておけばOKです。
PHPerの問題点は、視野が狭いこと。典型的には以下のような悪癖を持つ。
何も知らないからPHPを愛せるんだよ、PHPerは。だからまず、HTML、CSS、JavaScript、SQLを覚えろ。次に、Javaに移行しろ。そんなに難しくないよ、Java。特に大量にコードを書けるPHPerは、速度が出てライブラリ化が容易なJavaの方が向いている。今はVPSがあるので、小規模案件でも問題ない。
15年間ほどPHPはインターネットを支えてきたが、そろそろ設計の脆さが問題になっている。PHP 6の開発が振り出しに戻ったのは、不幸な事故ではない。ウェブで仕事をしていれば、PHPとJavaで共通する知識も多い。PHPerはJavaを覚えてPHPとさよならしろ。そして恥ずかしい悪癖を直すべきだ。
間違いもあるかもしれないし、詳細はググっていただくとして。
まずはFXの作りの話になるんだけど、あれのUIとかはXULって言う、javascriptやCSS, XMLなんかをベースにした言語で書かれている。
で、拡張機能はこのXULで作る。つまり、元々のUIとかを形作っているXUL群に追加でインストールするXULが拡張機能。
対してプラグインはnetscapeの時代から続く、DLLを使う方式。
拡張機能はスクリプト言語ベースで、しかもwebで使ってるものの流用だから、入りやすく作りやすい。メモ帳あれば作れる的。
プラグインはコンパイラとか必要だし、色々敷居が高いが、その分速度面も出来ることも上。
さて、スクリプト言語は軒並みトロいということが分かったうえで、次のグラフをご覧頂きたい。これは各プログラミング言語でのテンプレートエンジンのベンチマーク結果である。
…（中略）…
これを見ると、Java や C で実装されたテンプレートエンジンが必ずしも最速ではないことが分かる。
…（中略）…
このように、プログラミング言語の速度とアプリケーションの速度は、必ずしも一致しない。一致しないどころか、まるで関係ないと言っても差し支えないぐらいである。もちろんテンプレートエンジンの速度でアプリケーションの速度を測れるわけではないが、「必ずしも一致しない」という結論は変わらない。
…（中略）…
.@tagomoris あんなテンプレートの記事に感心してちゃだめですよ。テンプレートの処理の全体に対する時間の割合が出てないと意味ないのに、ああいう結論を出している時点でその釣りレベルがわかるというものです
んー、「言語の速度 != アプリの速度」という主張を示すにはあれで十分だと思いますけど。データベースやネットワークまで含めて計測したら、それこそ言語の速度に関係ない部分が増えるわけですから、先の主張がもっと強調されるだけです。そういった、明らかに言語に関係のない部分を含めなくても「言語の速度 != アプリの速度」というのがよくわかるという点で、あのベンチマークは十分意味があると思いますが、いかがでしょうか。
パフォーマンスの結果は、その測定対象に対しては事実ですが、別のモノに対しては確かな根拠とは成り得ません。あるひとつの測定結果のみで、ほかも大体そうだろうというような人は、根拠がないので、それを説得した上で認めないならしかとしてもいいんじゃないかな。しょせんそのレベルの人だから
wwwwwwww
「言語の速度 == アプリの速度」という思想に対し、id:kwatchが反証を出している。
id:kwatchの反証は、つまり、アプリケーション中でテンプレートエンジンについてのみ取り出してみた場合に、テンプレートエンジンの速度とアプリケーションの速度が関係ないということを示している。
このような事実にも関わらず「言語の速度 == アプリの速度」という思想を維持するには、テンプレートエンジンの速度差にも関わらず、アプリケーションの他の部分の速度差によって必ず「言語の速度 != アプリの速度」が達成されなければならない。そしてそれは有り得ない。テンプレートエンジンの速度差は主にアーキテクチャや実装によって生じており、アプリケーションの他の部分もそれぞれ異なるアーキテクチャや実装を採用している以上、同様に速度差が発生するからだ。
もちろん他の部分の実装等で差を取り戻し、あるいは逆転するアプリもあるだろうが、差を広げられるアプリもあろう。しかし、それはアプリごとにバラバラなので結局「言語の速度 == アプリの速度」というおとぎ話に立ち戻ることは出来ない。
結局のところ、「言語の速度 != アプリの速度」を証明する場合には、アプリ中で同じ役割を担う一部分どうしを比較して「言語の速度 != アプリの速度」となることを示せば十分だ。
ところがid:higayasuoはテンプレートエンジンの速度差があろうと、アプリの速度が言語の速度で決まることを否定出来ないという。
端的にいって勘違いだ。
これが仮に「言語の速度 == アプリの速度」という妄想を証明するために「言語の速度 == テンプレートエンジンの速度」である例を持ち出したのであれば、パフォーマンスの結果は、その測定対象に対しては事実ですが、別のモノに対しては確かな根拠とは成り得ません
などという不抜けた妄言も成り立つところである。
しかし今回は != だ。
!= と == の区別がついてないとすれば馬鹿だし、!= への反証が == への反証と同じだと考えているのならやはり馬鹿だ。!= を証明するには、ただ１つでも反例を挙げれば良い。 == への反例が一つでも挙がれば != の証明になるのだ。
まさかid:higayasuoは、id:kwatchが「テンプレートエンジンの速度 == アプリの速度」と書いていると読んだのだろうか。
そんなことは本文のどこにも書いていないばかりか、上記の引用の中で明確に否定されている。
世の中には、どうしても「賢い人」と「あまり賢くない人達」人たちがいて、「あまり賢くない人達」は「賢い人」の足を引っ張るモノです。
「あまり賢くない人達」が自らの愚かさゆえ、人生を無為に過ごすのはある意味しかたがないことだと思いますが、問題なのはこれから賢くあろうとする未来ある若者達が、このような「あまり賢くない人達」に惑わされ、不幸に見舞われることであります。
日向さんはこのような未来ある若者のために、わざわざ時間を割いて素晴らしいエッセイを書きおこしてくれました。
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氏は同レビュー中で日向さんを「真に初心者向けに本を書ける希有の存在」と評しています）
なお、訳者はあらゆる書き込みに対していちいち反論することはできません。 また、一部の低俗な掲示板のような増田を読んだり書き込んだりするのは 時間の無駄なので、私に限らずほとんどの著者は、そのようなものに書き込むことはもちろん、 目を通すこともありませんのであしからず。
大学教育について話題になっているようですので、私が卒業した、大阪大学基礎工学部情報科学科について書いてみたいと思います。
大阪大学基礎工学部情報科学科は、昭和45年に最初に国立大学に設立された情報工学関連学科のうちの一つで、コンピュータサイエンスの分野では日本で最も古い歴史を持っている学科、ということになります。
情報科学科の特徴は、そのプログラミング実習の充実ぶりです。入学すると、まずPascalというプログラミング言語で構造化プログラミングを勉強することになります。次にアセンブリ言語であるCASLを勉強し、Pascalとアセンブリ言語を応用してC言語を勉強します。またその後、スクリプト言語であるPerl、関数型言語のML、オブジェクト指向言語としてJavaを学習します。
また、言語だけではなく、コンピュータサイエンスの基本であるアルゴリズムやデータ構造についても幅広く学ぶことができます。
全ての実習は課題が出され、実際にコードを書かなければいけません。例えばC言語の授業の最終的な課題は、「shのようなシェルプログラムを作成すること」でした。最終的には、「Pascal風の言語をCASLに変換するコンパイラを作成する」という課題に取り組むことになります。
大阪大学は全体的に単位の取得が厳しいことで知られていますが、情報科学科も例外ではありません。もしプログラミングをあまりしたことがないのであれば、遅くまで実習室にこもることになると思います。だけど、それは情報工学の世界で生きていくためには必要な知識なのです。
実習で勉強する言語は、Javaを除くとあまり現在使われている主流の言語とは言えないのですが、様々な言語を学ぶのは「プログラミング言語はそれぞれに違いがあり、それぞれに適した用途がある」ことを理解することに繋がります。また大学を卒業してから、新しい言語を学ぶ必要が出てきたとき、それに対応する能力を磨くことができます。
日本の大学で、ここまで実戦的なコンピュータに関する教育を行っている場所はあまりないのではないか、と思います。コンピュータがどのように動いているのか、内部原理までしっかり教えてくれます。卒業生の進路は、研究者というよりは、エンジニアとして開発の現場で働くことが多いようです。
大阪大学の入試問題は、東大や京大と違って特殊な問題はそれほど出ません。努力でなんとかなるレベルだと思います。
情報工学は新しい分野なので、大学院で研究するために必要な知識は他の分野ほど多くありません。このため情報工学科では、3年生の夏に大学院の試験を受けて合格すれば、学部を卒業しなくても4年目から大学院に進むことができます。この仕組みを活用すれば、5年で大学院を卒業できます。実際、学部生の1/4くらいはこの仕組みを活用しています。
もちろん、ここに書いたのは情報科学科の全てではありません。ネットにも他に情報がありますし、もし興味があったら、大学のオープンキャンパスに行ってみるのもよいと思います。
コンピュータの世界は変化が激しくて、エンジニアとして生きていくのはとても大変ですが、それでもいい、プログラマとして将来何かを作りたいんだという人であれば、ここはそのための力を与えてくれるはずです。進学先として検討してもらえたら幸いです。
ものすごい重箱のすみをつつくけど
動的で型制約のないスクリプト言語
型制約って、parametric polymorphism の用語だと思う
C++だと concept で書けるんだっけ？
C#は知らんけど一番凄そう
言語なんて静的で型厳密なオブジェクト指向型言語と動的で型制約のないスクリプト言語と関数型言語
それぞれ1種類ずつ使えるようになっとけば後はなんでも対応できるでしょ。
対応は全然できるんだけど、ある程度実績がないと仕事こないんだよねー
勉強でもプログラムでも何でも同じ。てか本当のところ、高校も出ててこんなこと分かってない奴いないだろ？ いたらいたですげー痛い奴だが。
あとはどうモチベーションを維持するか。この辺は20代だとまだ確立できてない奴もいるだろう。こういう最先端をミーハーするとモチベーション保てる人もいるだろうけど、一番手っ取り早いのは、ある程度の規模の作りたいものを一つ作ること。
あと言語選びに関して少しだけ。
上に書いたようになんでもいい。
仕事で使うならその言語だが、そうでなけりゃ、比較的細部を気にせずに覚えても何とかなるスクリプト言語選んどけばいい。具体的には Python とか Ruby とか JavaScript とか Perl とか PHP とか。もしWeb系じゃなく例えばWindowsアプリが作りたいなら C# とか。
この言語選んどけば、みたいなのは全部無視して、とりあえず１つをある程度覚えろ。話はそれからだ。
