 
|
はてなキーワード: プログラミング言語とは
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
メソッドチェーンは書き易い
内包表記は見た目が整ってて綺麗、最終的な型がわかり易い
いじょ。
Pythonの方が弄れる対象が多いのに、なんでウェブ系だとPHPの方が流行ってんだろ
端末からのテキスト処理も楽だし、数値計算周りのライブラリも充実しているのに
PHPが優遇されているのって歴史的な経緯以外に何か他の理由でもあるのか？
けどまぁ、情弱な文系SEが大半を占めているバカだらけの日本じゃ別にPHPで困ることもないか
数値計算や端末からのテキスト処理なんてWeb系じゃ大して使わないからなあ…
Pythonに関しては、ZopeさえコケていなければWebサーバ用LLとして大成功していたはずなのに、
Railsなんかが登場したおかげで、すっかり影が薄くなってしまいますた....
ってか、railsにインスパイアされたフレームワークって今じゃ幾らでもあるよね
djangoとかCakePHPとか。rubyってRoRを使いたいユーザを除くと、
pythonやPHPの方がユーザー数は圧倒的に多いと思うんだけど
本家のrailsって、他を遥かに越えるほど良いものなんだっけ？
44
Zopeが登場した当時、「RDB+PHPはもう古い、これからはOODB+ZopeがWebの中軸になる！」と
少なくとも自分はZopeからPythonという言語を知ったし、その時点でRubyは知らなかった
そして、その後のORM(RDB)+Railsの出現と華々しい革新性への注目は、誰もが知っているだろう
今でもZopeの開発は継続されてはいるが、結果的に当初の期待が大きく裏切られたという事実は動かしがたい
djangoとCakePHPについては実際に触っていないので憶測になるが、おそらく技術水準ではRailsと同等だろう
しかしRailsはRailsでコミュニティの活動が活発だし、その進化は異常に早い
Railsに何か致命的なトラブルが発生して開発が停滞する、あるいはdjangoやCakePHPから
何かのイノベーションが提示されでもされない限り、後発のdjangoやCakePHPがRailsに追いつくのは無理
Railsは決して技術的に完璧なWebフレームワークではないんだけどね....（たとえばSeaSideのような.... ）
だからこそ「もしもZopeが....だったなら」という「たら・れば」感はPythonコミュニティの潜在認識になっている
C a k e P H P は う ん こ
CakePHP使ってんの？
可哀そうにw
でもやっぱりいつもの使い慣れたLL(Python/Ruby)で
Webサービスを書きたいってのがある
求人数は
Ruby on Rails＞＞＞＞＞＞＞＞Django
http://www.indeed.com/jobtrends?q=django%2Cruby+on+rails&l=
どういうことなの？
求人数が多いのはそのためだと思うよ
なんかのミスかと思ったがアメリカでもRuby on Railsは人気があるのかなあ・・・
Pythonのほうが使いやすいと思うのだがフレームワークはRailsが優位なんだろうか
Djangoは周辺ライブラリが微妙だし本体も鈍くさい感じがする。
でも、FlaskはSinatraより好きだから、Pythonが嫌いってわけではない。むしろ好き。
ただ、いざ作り始めるとやっぱりRailsが楽だなあってなって、Railsを使い続けている。
同感だ
同じように思っている人が他にもいて安心した
PHPはフレームワークが乱立しすぎているから、RailsをPHPで実装してみようというやつが出てきた。
それに比べてPythonは、Zopeというデファクトスタンダードが既に存在していたけど、
ただ、どうやってもRailsもどきがRailsを超えることはできないのは間違いない。
パクリはオリジナルを超えられない(ｷﾘｯ って定型句だけど、
これってｷﾘｯって言いたいだけだと思う。
D言語って超えたって？
B言語って超えたって？
PHPで同じ事をできないわけではないだろうけど、Ruby on Railsほど簡潔にはできない
まあくだらねえWEBサービス作って喜んでる情弱は早く死ねって事だよ
そういう理由じゃなくてRailsのほうが単純に情報もプラグインも多いからでしょ
linuxじゃデフォのツールなんだし、ツールとの連携を考えたらpython一択じゃん
わざわざ不合理で不完全な言語を使うなんて
もしも
＞linuxじゃデフォのツールなんだし、ツールとの連携を考えたらpython一択じゃん
真実であるのなら、今頃はdjangoの情報とプラグインが溢れかえっているはず
yumや、gdbとgnomeの拡張がpythonであるからといって、それをwebアプリでも使いたいと思う人は少ないというだけのこと。
ソースからインストールする必要があったとしても、web開発ではrubyを使いたいという人が多いというだけのこと。
というか、世界中のPythonプログラマが Remeber Zope!! を合い言葉に
打倒RailsたるWebフレームワークを開発しているはずだけど、
Railsも登場してから、かなりの年月が経過しているんだけどなぁ....
その間にもRailsはRails 3が登場して、REST/AJAXの強化等の進化が継続しているよ
Ruby では
ary.map {|x| x**2}
map(lambda x: x**2, ary)
となり、lambda の本体が1つの式では表現しきれなくなると
.....
と書き換える必要があります。
f = lambda x:(x and f(x-1)*x)or 1
RubyにはPythonのように「lambda本体は式でなければならない」という限定がありませんから、
f = lambda{|x|if x == 0 then 1 else x*f.call(x-1) end}
または
f = lambda{|x|x == 0 ? 1 : x*f.call(x-1)}
と書けます。lambda内でreturnが使えますから、書きたければ
f = lambda{|x|if x == 0 then return 1 else return x*f.call(x-1) end}
でもOKです。
348
これはPythonをdisっているように見せかけてRubyをdisっているのか？ と一瞬思ってしまったｗ
だってRubyのほうが長くない？CLのfuncallみたいなcall()がちょっとうざいし…
そしてどっちもlambda式の中で束縛変数の名前で再帰可能、と
print [x*2+100 for x in [1,2,3,4,5] if x > 2 and x < 5]
暗号のように見える。
puts [1,2,3,4,5].select{|i| i > 2 and i < 5}.map{|i| i*2+100}
思考の流れと、コードの流れが一致しているので書きやすい。
map(lambda x: x*2+100, filter(lambda x: x > 2 and x < 5, [1,2,3,4,5]))
pythonて可読性が高いのをうたってる割にはそこいまいちだよね
Rubyの場合には、左から右へと無名関数がデータフローあるいは
関数型プログラミングに不慣れな初心者でも、参照透明性のあるコードが自然に書ける
プログラマにとって優しい or プログラミングの楽しさを教えてくれるのがRuby
それと比較すると、Pythonのコードは、関数型プログラミングというものが
いかに高度で難解なものであるかという事をもったいぶってプログラマに押し付ける
もしもPythonしか知らないプログラマであれば、関数型 = 難解 という印象を持つだろう
階乗計算くらいだと単純すぎて、ナゼ重要なのかが分かりづらいと思うのでコードで示す
result_list = source_list.map { |elem|
x = foo(elem.x) # ここが局所宣言を書く部分
x + y # 最後に評価された式の値が、無名関数のリターン値になる
}
Rubyでは、map等に与える無名関数の中で局所的な環境(クロージャ)が作られるから、
x = foo(...) のような代入文がいくつでも(= 複雑な処理でも)書ける
このポイントは、実用的なプログラムを関数型風で書こうとした時に、威力を発揮する
余計分かりづらくなった
高卒ドカタなんだろうなぁと可哀想になる
集合の表記に似せてることが分かるから
355
＞map/filterはfor/ifと同じだと言っているだけだから、難解という印象は持たない。
関数型プログラミングに慣れた、あるいは得意な人であれば、そういった印象なんだろね
Rubyの魅力はこれから関数型プログラミングを学ぼうとする初心者、 あるいはそんな初心者へ教える立場から見た、優しさ or 分かりやすさなんだ
[1,4,3,2].sort.reverse.map{|x| x.to_s}.join('-')
Pythonだと読みにくい。
'-'.join(map(str, reversed(sorted([1,4,3,2]))))
Pythonでは思考の流れと一致しないばかりか、「カッコだらけ」のコードになると.....
カッコだらけのコードを分かりやすくする基本的な方法は静的単一代入じゃないか
Rubyのやり方は基本ではなく玄人のやり方だろ
Pythonでは組み込みの型でメソッドチェインはやって欲しくないな
似たようなコレクションtuple,deque,array,queue等にも同じメソッドが必要になってくるし。
372
外部のライブラリでも列挙可能なものは、たいていEnumerableモジュールをimportしてますね
Rubyユーザーは列挙可能なものはmapやselectできて当然だろって思ってる気がします
Pythonは「何かを便利に書くためのしわ寄せ」をはっきり寄せてくる
得意と不得意を言語レベルではっきり主張するのでメリケン好みと言えなくもない
Rubyは全方位になんとなく八方美人なので、全体的になんとなく書きやすくてなんとなくキモくて遅い
「書きにくいってことはその処理に向いてないってことだから諦めろ」を地で行く
無名関数が文を使うほど複雑なら名前を付けるのが Python 流と想像。
これを読みづらいと感じるのは、左から右に流れる
もしかしてアラビア語ネイティブな人からすると逆に読みやすいのか？
Webシステムとは縁遠い事務職のリーマンが、ある日思い立って、ニッチな用途の検索エンジンサービスを作ってみたので、ちょっと書いてみようと思います。
ちなみに、検索エンジンといっても、googleカスタム検索とかのお茶濁し系じゃなくて、apache Solrというオープンソース検索エンジンを、VPS上で動かしているという、それなりに本
気度の高いものです。
なんで素人がそんな物騒なものを動かす羽目になったかは、後述。
やりたい構想みたいなことを思いついたのは、もう6、7年前ほど前のこと。初めて独り暮らしを始めたときに、ひどく不便を感じたことがあり、こんなサービスがあったら便利だなあ、
ちなみにその妄想をふと高校の同期に話したとき、そのサービスはどこにあるのか？！と、えらくがっつかれたのを、覚えてます。まあ、俺と同じく偏執狂の奴だったからだと思います
が。
ただ、しがない事務職リーマンということもあり、当然、技術も無く、そのときは、やるならこんな名前のサービス名だろうなあ、とか、そんな妄想レベルで、話は終わっていました。
そんな感じで、5年ほど月日は経ち、なんとなくリーマン人生の流れも見えてきたところで、以前、妄想していたことを、ふと思い出しました。
5年も経ったら、さすがに自分が考えたようなこと、誰かがやっているだろうと調べてみたところ、意外なことに、競合になるようなサービスは存在せず。ちょうど異動があって、少し時
間が出来たこともあり、じゃあ、着手してみようかと思い立ちました。
やりたいことは、大手サイトの情報検索。ただ、商品ページ内の特定情報、それも、商品ごとに正規化されていない表記を、正規化して抽出する必要があったので、大手サイトの既設API
だけではとても実現不可能でした。
まあ、だからこそ、5年間、誰もやろうとしなかったんでしょうが。
ということで、とても一発では解決できなさそうな内容だったので、自分でなんとか実現できそうな機能に細分化して、各個撃破していくことにしました。
随分と考えた結果、
以上に区分できると考えて、これらを各個撃破していくこととしました。
また、技術もなく、プログラミングも出来ず、ましてやlinuxサーバのお守りをしたことなんて当然ないので、インターネット上に置くサーバですべての処理を完結させるのではなく、イ
ンターネット上に置くリソースは最小限に留め、できる限り、勝手がわかる自宅のwindowsパソコンで処理を行うことにしました。
ちなみにさらっと結論だけ書いてますが、ここまで至るまでに、いろいろと調べ続たり、考え込んだりしていたので、思い立ってから3ヵ月は掛かってます。。。
さて、やる方針を決めたあと、はじめに着手したのは、要の検索エンジンサーバです。
いろいろとググって調べて、mySQLというやつか、apache Solrというやつかに絞りましたが、結局、Solrを使うことにしました。
MySQLのほうが実績は多そうだったのですが、Solrのほうが検索専門で、滅茶苦茶動作が速いらしいということ、MySQLでも出来るが特に速度が遅いらしい全文検索機能も使いたかったこ
と、あとファセット機能がジャンル絞りこみに便利に使えそうだったので、というのが理由です。
ちょうどSolr本が発売されていたこともあり、それを参考に、自分が使うように設定ファイルを変更していきました。
しかし、初めは設定ファイルの内容も意味不明な上に、私の書き方も雑なのか、少しいじっただけでまったく動かなくなる。結局、設定ファイルを一文字ずつ変更しては動作検証、とい
った始末で、進捗は地を這うよう。ある程度思い通りにSolrを扱えるようになるまで、3ヵ月以上掛かったでしょうか。。。
さらに、検索エンジンのフロントエンド（Solrの検索結果を、htmlに変換するプログラム）も書かなければならない。プログラミングが出来ない人間には、これが本当に辛かった。
Solr本に、いろんなプログラミング言語でサンプルがあったのですが、迷った末に、わずか数行なら書いた（≒コピペした）経験があるという理由で、javascriptを苦渋の選択。
しかし、選択はしてみたが、基礎が本当に無いから内容がサッパリ頭に入ってこない。こちらも、わかるところから本当に1文字ずつ変えていくといった手探り状態。
プログラミングについては、今回のためだけだから、といった理由で、一切基礎をやらずに着手したのが裏目に出たのか、サンプルのソースをモノにして、書き上げるのに、ゆうに半年
以上。本当に時間が掛かりました。
さらに、Solr周りで計9ヶ月間ハマっていた頃、忘れもしない、kanzen21のおっさんが彗星のように現れて、衝撃を受けることになります。
大手サイトのページをクロールして検索エンジンを作る手法は、私と考えていた構想の枠組みとまさに「完全に一致」な訳で。。。
図書館事件に注目していたのも同じで、あまりの一致具合に衝撃を受けっぱなしでした。
その後の成り行き等も含めて、興味深く観察させて頂き、本当に参考になりました。
そんな感じで紆余曲折もありましたが、ようやく難題だった、プログラミング関連に目処が立ってきたので、あとはクローラと肝心のデータ処理です。ここからは、勝手知ったるwindows
まず、クローラですが、専用のクローラをwindows用に探してきたり、それを設定するのも大変なので、今回はテレホーダイ時代に使っていたような、フリーのweb巡回ソフトを利用する
こととしました。指定のhtmlをダウンロードしてくるだけなので、別に変に新しいものに手を出す必要もないので。
また、ダウンロードしてきたhtmlファイルについては、これまたフリーの日本語処理ツールでcsv方式に加工することにして、処理ルール部分を相当に作り込みました。
このあたりは、全体を通して見てもキモの部分なんですが、ある意味、ちょっとしたパズル感覚だったので、プログラミング言語の部分と違って、かなり楽しかったです。
あとは、msdosのバッチファイル（これは前から知っていた）で、これらの処理を繋ぎ、cygwinのcurlとかいうツールで、連続して検索エンジンサーバにcsvファイルをアップロードする
仕組みを作りました。
検索エンジンサーバには、容量は少ないが、安くて高性能という、今回の用途にピッタリだった、さくらのVPSを借りて設定。CentOSのサーバ構築ホームページを見ながら、サーバとか
Solr管理URLとかにセキュリティを掛けて、こちらも素人ながら、意外とすんなり設定。
ホームページは、vpsサーバに相乗りさせるのではなく、別にさくらのレンタルサーバを借りました。apacheの設定方法等を習得する必要がありませんし、vpsのリソースをapacheと分け
合う必要が無くなるので。ホームページのhtmlファイル、cssファイル等も調べながら設定し、画像も準備しました。
あと、構想を思いついたときに妄想していたサービス名の.comドメインは、すでに他者に取得されていたのですが、どうも使っている風にも見えなかったので、whoisで出てきたメールア
ドレスに連絡して交渉し、幾ばくか払って買い取りました。
結局、足かけ18か月。ようやく完成。
楽天市場の家具を、幅x奥行x高さ(家具サイズ)で検索できる、楽天市場・家具カテゴリ専門の検索エンジン
この商品数規模（データ収録約30万アイテム）で、1センチ単位で家具のサイズ指定検索が可能な手段は、商用サービスも含めて、ほかには存在しないと思います。
kanzen21と違って、エロじゃないから華はないけどね。。。
ちなみに冒頭で少し書いたきっかけですが、就職して独り暮らしを開始したときに、新しい家にピッタリサイズの家具が欲しかったのですが、これが楽天で探すのは至難の技でして。
楽天で家具を探してみようと思った人には判っていただけると思うのですが、楽天では、価格では範囲指定やソートができても、サイズでは検索出来ないんです。
これは、楽天では、商品のサイズ情報は商品の自由記述欄に記載することになっているためで、商品ごとにサイズの記載方法がバラバラのため、検索が事実上、不能となっています。
家電製品とかに関しては、種類が少ないこともあり、メーカーのホームページとかでサイズを確認した上で、商品型番で検索すればいいので、それほど問題にはならないのですが、家具
って、種類が非常に多く、型番もあったり無かったりで、家電のようにサイズを調べることができません。
・・・ということで、カグサイズでは、楽天の商品ページにいろいろな書式で書かれているサイズ情報を拾って解析して正規化し、範囲指定やソートして検索ができるようにしています
。
また、単に寸法サイズを拾うだけでは、梱包サイズとか引き出し内寸とかも引っ掛かってしまうので、それらは出来るだけ排除して、商品の外寸が優先して引っ掛かるよう、アルゴリズ
ムを調整しています。
単位（センチとミリ）に関しても、商品ごとにバラバラ（単に単位だけでなく、商品説明のどこに"センチ"とか"ミリ"と記載しているかについてもバラバラです。）なので、サイズ表記
の前後の状況をみて、正しいと思われる単位で拾うようにしています。
あと、変わった使い方としては、欲しい家具の価格比較みたいなこともできます。
家具は、同じ商品でも、店ごとに型番が違ったりすることがよくあり、簡単には価格の比較が行いづらいジャンルの商品です。
しかし、型番は違っても、同じ商品なら原則、サイズは同じですから、欲しい商品とまったく同じサイズで検索をかけると、同等商品があるのかどうか比較しやすい・・・といった使い
方もできます。
と、そんな感じで、しがない事務職リーマンが作ってみた、ニッチな用途の検索webサービスを、サービスインさせて頂きました。
一般に公開されていて、誰でもアクセスできる情報でも、ニーズが有りそうな切り口の条件で検索性を高めれば、新しい価値を創造できるんじゃないかという実験です。
もしよろしければ、ぜひ、使ってみてくださいー。それでは！
----------
JavaScript って生き物っぽいって思ったのがきっかけだった。
なんか菌？に遺伝子いれてたんぱく質を生産させるやつ？ Function は菌の細胞膜で prototype は遺伝子で、だから prototype に全然関係ない違う生物の遺伝子を生きてる菌に入れちゃったり。そうすると全然ちがうたんぱく質が生産されたり。prototype にべべーっとコピーして追加するのなんてまさしくそれっぽい。
だってプロトタイプベースって、生き物しかいない世界じゃない？基本的に。インスタンスってのは生き物じゃない設計図があってそれにしたがって出来た生き物がインスタンスってイメージあんだけど。プロトタイプベースの世界にはそんな設計図も生き物じゃないものもないよね？なのにわざわざインスタンスっていうのに何か違和感？ご都合主義的なもの感じる。クラスは型で、インスタンスを実体だとかなんとかって氾濫してるせいかな。多分この辺の用語が JavaScript をわかりにくくさせてる気がする。
僕の感覚では、オブジェクトってのは生き物で、クラスベースってのは神が設計図に基づいて生き物を生産してる世界で、インスタンスベースってのは生き物が生き物を複製してる世界のイメージだ。多分、原始の生物はインスタンスベースみたいな世界で、海の中にうようよしてたんだろうな、とか。
オブジェクトじゃないものは、生き物じゃない死んでるたんぱく質や RNA の破片みたいな。それだけじゃなにもできないみたいな。それだけじゃ命がないから、生き物の殻に詰めるってのが JavaScript のコンストラクタのイメージ。
Perl の bless したらこれはもう命入ったよ生き物だからねっあとは勝手にしてねってのも、Python の名前空間さえあればなんとかなるよねってのも、JavaScript のハッシュさえあれば世界作れるよねってのも、みんなどこか似ている。ちゃんと OOP を理解できてるかは別としてもこの三つはわりとすぐやりたいことができた。昔 Java の本を買ってきて挫折したのにくらべたら、なぜかずっとわかりやすかった。（bless という命名はすごく洒落てる）
全然関係ないけど、Django の日本語リファレンスは何か萌える。ラクダ本の日本語訳はむかつくのに。
プログラミングを始めたばっかりの時は、なんだか難しい用語の意味を理解しないと OOP がわからないと思ってた。それは僕らの住んでる世界とは全然関係のないプログラミングの技術ってやつだと思ってた。
でも多分違う。
世界が動く仕組みさえあれば、あとは作り手に世界の成り立ちを抽象化する表現力さえあれば、世界は勝手に表現されていくし、動き出してく。たまたま僕らの世界はオブジェクトなもので溢れていて、プログラミング言語が進化すれば世界に似るのも当然だろう。いや逆か。プログラミング言語が世界に似てきたから、オブジェクトなんていう世界に似た概念が出てきたってことか。なんだか難しい用語ってのは、その表現の一部分の技術に名前をつけてるだけなんだな、と。例えば何とか歌唱法や何々画法とか何とかレトリックとかパースの取り方みたいなのと同じ。それは表現を理解する手助けにはなるけど、その意味を知る事がイコール表現力をあげることにはならないんだよね。これに気づくのに遠回りしすぎたなあ。
（知識を得るだけで、100% 還元される人もいるかもしれないけど、そんなのは一部の天才だけだと思う。殆どの凡人はそうはいかない。とはいえ、元の錬度が低ければ、コツをいくつか教わるだけでいきなりうまくいくこともある。ただ、それをまるまんま実力だと思うのは、どんな分野でも危険だ。恋愛テクニックやらを必死に読んでる連中が男女間の深い人間関係を上手くやれてるとはちょっと想像できない！）
プログラミングで表現力を上げるにはどうすればいいんだろう。きっと他と同じだろうな。いい表現を沢山味わって、世界をよく観察して、どう成り立ってるかどう動いてるか、私達はそれをどう認知しているのか、考えることかもしれない。漫画家を志す人が美術解剖学を学んだり、優れた画家が絵筆で世界を生々しく描写するように、優れたプログラマは世界のなりたちをプログラムに写し取ったり、世界の仕組みを作る事が出来るのだと思う。
プログラミング言語は基本的に複雑すぎるので、習ってどうにかなるもんじゃない。
そりゃhello worldに毛が生えたようなもんだったら習えばいいだろうけどね。
先日「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 でまた再現するつもりなの？」
という皮肉であろう。
第1章 プログラミング概念入門 1.1 計算器 1.2 変数 1.3 関数 1.4 リスト 1.5 リストについての関数 1.6 プログラムの正しさ 1.7 計算量 1.8 遅延計算 1.9 高階プログラミング 1.10 並列性 1.11 データフロー 1.12 明示的状態 1.13 オブジェクト 1.14 クラス 1.15 非決定性と時間 1.16 原子性 1.17 ここからどこへ行くのか？ 1.18 練習問題 第1部 一般的計算モデル 第2章 宣言的計算モデル 2.1 実用的プログラミング言語の定義 2.1.1 言語の構文 2.1.2 言語の意味 2.2 単一代入格納域 2.2.1 宣言的変数 2.2.2 値格納域 2.2.3 値生成 2.2.4 変数識別子 2.2.5 識別子を使う値生成 2.2.6 部分値 2.2.7 変数の，変数への束縛 2.2.8 データフロー変数 2.3 核言語 2.3.1 構文 2.3.2 値と型 2.3.3 基本型 2.3.4 レコードと手続き 2.3.5 基本操作 2.4 核言語の意味 2.4.1 基本概念 2.4.2 抽象マシン 2.4.3 待機不能な文 2.4.4 待機可能な文 2.4.5 基本概念再訪 2.5 メモリ管理 2.5.1 末尾呼び出し最適化 2.5.2 メモリライフサイクル 2.5.3 ガーベッジコレクション 2.5.4 ガーベッジコレクションは魔術ではない 2.5.5 Mozartのガーベッジコレクタ 2.6 核言語から実用的言語へ 2.6.1 構文上の便宜 2.6.2 関数(fun文) 2.6.3 対話的インターフェース(declare文) 2.7 例外 2.7.1 動機と基本概念 2.7.2 例外を持つ宣言的モデル 2.7.3 親言語の構文 2.7.4 システム例外 2.8 進んだ話題 2.8.1 関数型プログラミング言語 2.8.2 単一化と内含(entailment) 2.8.3 動的型付けと静的型付け 2.9 練習問題 第3章 宣言的プログラミング技法 3.1 宣言的とはどういうことか？ 3.1.1 宣言的プログラムの分類 3.1.2 仕様記述言語 3.1.3 宣言的モデルにおいてコンポーネントを実装すること 3.2 反復計算 3.2.1 一般的図式 3.2.2 数についての反復 3.2.3 局所的手続きを使うこと 3.2.4 一般的図式から制御抽象へ 3.3 再帰計算 3.3.1 スタックの大きさの増加 3.3.2 代入ベースの抽象マシン 3.3.3 再帰計算を反復計算に変換すること 3.4 再帰を用いるプログラミング 3.4.1 型の記法 3.4.2 リストについてのプログラミング 3.4.3 アキュムレータ 3.4.4 差分リスト 3.4.5 キュー 3.4.6 木 3.4.7 木を描画すること 3.4.8 構文解析 3.5 時間効率と空間効率 3.5.1 実行時間 3.5.2 メモリ使用量 3.5.3 償却的計算量 3.5.4 性能についての考察 3.6 高階プログラミング 3.6.1 基本操作 3.6.2 ループ抽象 3.6.3 ループの言語的支援 3.6.4 データ駆動技法 3.6.5 明示的遅延計算 3.6.6 カリー化 3.7 抽象データ型 3.7.1 宣言的スタック 3.7.2 宣言的辞書 3.7.3 単語出現頻度アプリケーション 3.7.4 安全な抽象データ型 3.7.5 安全な型を備えた宣言的モデル 3.7.6 安全な宣言的辞書 3.7.7 資格とセキュリティ 3.8 宣言的でない必要物 3.8.1 ファイルを伴うテキスト入出力 3.8.2 グラフィカルユーザインタフェースを伴うテキスト入出力 3.8.3 ファイルとの状態なしデータI/O 3.9 小規模プログラム設計 3.9.1 設計方法 3.9.2 プログラム設計の例 3.9.3 ソフトウェアコンポーネント 3.9.4 スタンドアロンプログラムの例 3.10 練習問題 第4章 宣言的並列性 4.1 データ駆動並列モデル 4.1.1 基本概念 4.1.2 スレッドの意味 4.1.3 実行列 4.1.4 宣言的並列性とは何か？ 4.2 スレッドプログラミングの基本的技法 4.2.1 スレッドを生成すること 4.2.2 スレッドとブラウザ 4.2.3 スレッドを使うデータフロー計算 4.2.4 スレッドのスケジューリング 4.2.5 協調的並列性と競合的並列性 4.2.6 スレッド操作 4.3 ストリーム 4.3.1 基本的生産者／消費者 4.3.2 変換器とパイプライン 4.3.3 資源を管理し，処理能力を改善すること 4.3.4 ストリームオブジェクト 4.3.5 ディジタル論理のシミュレーション 4.4 宣言的並列モデルを直接使うこと 4.4.1 順序決定並列性 4.4.2 コルーチン 4.4.3 並列的合成 4.5 遅延実行 4.5.1 要求駆動並列モデル 4.5.2 宣言的計算モデル 4.5.3 遅延ストリーム 4.5.4 有界バッファ 4.5.5 ファイルを遅延的に読み込むこと 4.5.6 ハミング問題 4.5.7 遅延リスト操作 4.5.8 永続的キューとアルゴリズム設計 4.5.9 リスト内包表記 4.6 甘いリアルタイムプログラミング 4.6.1 基本操作 4.6.2 ティッキング(ticking) 4.7 Haskell言語 4.7.1 計算モデル 4.7.2 遅延計算 4.7.3 カリー化 4.7.4 多態型 4.7.5 型クラス 4.8 宣言的プログラムの限界と拡張 4.8.1 効率性 4.8.2 モジュラ性 4.8.3 非決定性 4.8.4 現実世界 4.8.5 正しいモデルを選ぶこと 4.8.6 拡張されたモデル 4.8.7 異なるモデルを一緒に使うこと 4.9 進んだ話題 4.9.1 例外を持つ宣言的並列モデル 4.9.2 さらに遅延実行について 4.9.3 通信チャンネルとしてのデータフロー変数 4.9.4 さらに同期について 4.9.5 データフロー変数の有用性 4.10 歴史に関する注記 4.11 練習問題 第5章 メッセージ伝達並列性 5.1 メッセージ伝達並列モデル 5.1.1 ポート 5.1.2 ポートの意味 5.2 ポートオブジェクト 5.2.1 NewPortObject抽象 5.2.2 例 5.2.3 ポートオブジェクトに関する議論 5.3 簡単なメッセージプロトコル 5.3.1 RMI(遠隔メソッド起動) 5.3.2 非同期RMI 5.3.3 コールバックのあるRMI(スレッド使用) 5.3.4 コールバックのあるRMI(継続のためのレコード使用) 5.3.5 コールバックのあるRMI(継続のための手続き使用) 5.3.6 エラー報告 5.3.7 コールバックのある非同期RMI 5.3.8 二重コールバック 5.4 並列性のためのプログラム設計 5.4.1 並列コンポーネントを使うプログラミング 5.4.2 設計方法 5.4.3 並列性パターンとしての機能的構成要素 5.5 リフト制御システム 5.5.1 状態遷移図 5.5.2 実装 5.5.3 リフト制御システムの改良 5.6 メソッド伝達モデルを直接使用すること 5.6.1 1つのスレッドを共有する複数のポートオブジェクト 5.6.2 ポートを使う並列キュー 5.6.3 終点検出を行うスレッド抽象 5.6.4 直列依存関係の除去 5.7 Erlang言語 5.7.1 計算モデル 5.7.2 Erlangプログラミング入門 5.7.3 receive操作 5.8 進んだ話題 5.8.1 非決定性並列モデル 5.9 練習問題 第6章 明示的状態 6.1 状態とは何か？ 6.1.1 暗黙的(宣言的)状態 6.1.2 明示的状態 6.2 状態とシステム構築 6.2.1 システムの性質 6.2.2 コンポーネントベースプログラミング 6.2.3 オブジェクト指向プログラミング 6.3 明示的状態を持つ宣言的モデル 6.3.1 セル 6.3.2 セルの意味 6.3.3 宣言的プログラミングとの関係 6.3.4 共有と同等 6.4 データ抽象 6.4.1 データ抽象を組織する8つの方法 6.4.2 スタックの変種 6.4.3 多態性 6.4.4 引数受け渡し 6.4.5 取り消し可能資格 6.5 状態ありコレクション 6.5.1 インデックス付きコレクション 6.5.2 インデックス付きコレクションを選ぶこと 6.5.3 その他のコレクション 6.6 状態に関する推論 6.6.1 不変表明 6.6.2 例 6.6.3 表明 6.6.4 証明規則 6.6.5 正常終了 6.7 大規模プログラムの設計 6.7.1 設計方法 6.7.2 階層的システム構造 6.7.3 保守性 6.7.4 将来の発展 6.7.5 さらに深く知るために 6.8 ケーススタディ 6.8.1 遷移的閉包 6.8.2 単語出現頻度(状態あり辞書を使用する) 6.8.3 乱数を生成すること 6.8.4 口コミシミュレーション 6.9 進んだ話題 6.9.1 状態ありプログラミングの限界 6.9.2 メモリ管理と外部参照 6.10 練習問題 第7章 オブジェクト指向プログラミング 7.1 継承 7.2 完全なデータ抽象としてのクラス 7.2.1 例 7.2.2 この例の意味 7.2.3 クラスとオブジェクトを定義すること 7.2.4 クラスメンバ 7.2.5 属性を初期化すること 7.2.6 第1級メッセージ 7.2.7 第1級の属性 7.2.8 プログラミング技法 7.3 漸増的データ抽象としてのクラス 7.3.1 継承グラフ 7.3.2 メソッドアクセス制御(静的束縛と動的束縛) 7.3.3 カプセル化制御 7.3.4 転嫁と委任 7.3.5 内省 7.4 継承を使うプログラミング 7.4.1 継承の正しい使い方 7.4.2 型に従って階層を構成すること 7.4.3 汎用クラス 7.4.4 多重継承 7.4.5 多重継承に関するおおざっぱな指針 7.4.6 クラス図の目的 7.4.7 デザインパターン 7.5 他の計算モデルとの関係 7.5.1 オブジェクトベースプログラミングとコンポーネントベースプログラミング 7.5.2 高階プログラミング 7.5.3 関数分解と型分解 7.5.4 すべてをオブジェクトにすべきか？ 7.6 オブジェクトシステムを実装すること 7.6.1 抽象図 7.6.2 クラスを実装すること 7.6.3 オブジェクトの実装 7.6.4 継承の実装 7.7 Java言語(直列部分) 7.7.1 計算モデル 7.7.2 Javaプログラミング入門 7.8 能動的オブジェクト 7.8.1 例 7.8.2 NewActive抽象 7.8.3 フラウィウス・ヨセフスの問題 7.8.4 その他の能動的オブジェクト抽象 7.8.5 能動的オブジェクトを使うイベントマネージャ 7.9 練習問題 第8章 状態共有並列性 8.1 状態共有並列モデル 8.2 並列性を持つプログラミング 8.2.1 さまざまな手法の概観 8.2.2 状態共有並列モデルを直接使うこと 8.2.3 原子的アクションを使うプログラミング 8.2.4 さらに読むべき本 8.3 ロック 8.3.1 状態あり並列データ抽象を構築すること 8.3.2 タプル空間(Linda) 8.3.3 ロックを実装すること 8.4 モニタ 8.4.1 定義 8.4.2 有界バッファ 8.4.3 モニタを使うプログラミング 8.4.4 モニタを実装すること 8.4.5 モニタの別の意味 8.5 トランザクション 8.5.1 並列性制御 8.5.2 簡易トランザクションマネージャ 8.5.3 セルについてのトランザクション 8.5.4 セルについてのトランザクションを実装すること 8.5.5 トランザクションについてさらに 8.6 Java言語(並列部分) 8.6.1 ロック 8.6.2 モニタ 8.7 練習問題 第9章 関係プログラミング 9.1 関係計算モデル 9.1.1 choice文とfail文 9.1.2 探索木 9.1.3 カプセル化された 9.1.4 Solve関数 9.2 別の例 9.2.1 数値例 9.2.2 パズルとnクイーン問題 9.3 論理型プログラミングとの関係 9.3.1 論理と論理型プログラミング 9.3.2 操作的意味と論理的意味 9.3.3 非決定性論理型プログラミング 9.3.4 純粋Prologとの関係 9.3.5 他のモデルにおける論理型プログラミング 9.4 自然言語構文解析 9.4.1 簡単な文法 9.4.2 この文法に従う構文解析 9.4.3 構文木を生成すること 9.4.4 限定記号を生成すること 9.4.5 パーサを走らせること 9.4.6 パーサを「逆向きに(backward)」走らせること 9.4.7 単一化文法 9.5 文法インタプリタ 9.5.1 簡単な文法 9.5.2 文法のコード化 9.5.3 文法インタプリタを走らせること 9.5.4 文法インタプリタを実装すること 9.6 データベース 9.6.1 関係を定義すること 9.6.2 関係を使って計算すること 9.6.3 関係を実装すること 9.7 Prolog言語 9.7.1 計算モデル 9.7.2 Prologプログラミング入門 9.7.3 Prologプログラムを関係プログラムに翻訳すること 9.8 練習問題 第2部 特殊化された計算モデル 第10章 グラフィカルユーザインタフェースプログラミング 10.1 宣言的／手続き的方法 10.2 宣言的／手続き的方法を使うこと 10.2.1 基本的ユーザインタフェースの要素 10.2.2 GUIを構築すること 10.2.3 宣言的座標 10.2.4 リサイズ時の宣言的振る舞い 10.2.5 ウィジェットの動的振る舞い 10.3 対話的学習ツールPrototyper 10.4 ケーススタディ 10.4.1 簡単なプログレスモニタ 10.4.2 簡単なカレンダウィジェット 10.4.3 ユーザインタフェースの動的生成 10.4.4 状況順応時計 10.5 GUIツールを実装すること 10.6 練習問題 第11章 分散プログラミング 11.1 分散システムの分類 11.2 分散モデル 11.3 宣言的データの分散 11.3.1 オープン分散と大域的ネーミング 11.3.2 宣言的データを共有すること 11.3.3 チケット配布 11.3.4 ストリーム通信 11.4 状態の分散 11.4.1 単純状態共有 11.4.2 分散字句的スコープ 11.5 ネットワークアウェアネス 11.6 共通分散プログラミングパターン 11.6.1 静的オブジェクトとモバイルオブジェクト 11.6.2 非同期的オブジェクトとデータフロー 11.6.3 サーバ 11.6.4 クローズド分散 11.7 分散プロトコル 11.7.1 言語実体 11.7.2 モバイル状態プロトコル 11.7.3 分散束縛プロトコル 11.7.4 メモリ管理 11.8 部分的失敗 11.8.1 失敗モデル 11.8.2 失敗処理の簡単な場合 11.8.3 回復可能サーバ 11.8.4 アクティブフォールトトレランス 11.9 セキュリティ 11.10 アプリケーションを構築すること 11.10.1 まずは集中，後に分散 11.10.2 部分的失敗に対処すること 11.10.3 分散コンポーネント 11.11 練習問題 第12章 制約プログラミング 12.1 伝播・探索法 12.1.1 基本的考え方 12.1.2 部分情報を使って計算すること 12.1.3 例 12.1.4 この例を実行すること 12.1.5 まとめ 12.2 プログラミング技法 12.2.1 覆面算 12.2.2 回文積再訪 12.3 制約ベース計算モデル 12.3.1 基本的制約と伝播子 12.3.2 計算空間の探索をプログラムすること 12.4 計算空間を定義し，使うこと 12.4.1 深さ優先探索エンジン 12.4.2 検索エンジンの実行例 12.4.3 計算空間の生成 12.4.4 空間の実行 12.4.5 制約の登録 12.4.6 並列的伝播 12.4.7 分配(探索準備) 12.4.8 空間の状態 12.4.9 空間のクローン 12.4.10 選択肢を先に任せること 12.4.11 空間をマージすること 12.4.12 空間失敗 12.4.13 空間に計算を注入すること 12.5 関係計算モデルを実装すること 12.5.1 choice文 12.5.2 Solve関数 12.6 練習問題 第3部 意味 第13章 言語意味 13.1 一般的計算モデル 13.1.1 格納域 13.1.2 単一代入(制約)格納域 13.1.3 抽象構文 13.1.4 構造的規則 13.1.5 直列実行と並列実行 13.1.6 抽象マシンの意味との比較 13.1.7 変数導入 13.1.8 同等性の強制(tell) 13.1.9 条件文(ask) 13.1.10 名前 13.1.11 手続き抽象 13.1.12 明示的状態 13.1.13 by-need同期 13.1.14 読み出し専用変数 13.1.15 例外処理 13.1.16 失敗値 13.1.17 変数置き換え 13.2 宣言的並列性 13.2.1 部分停止と全体停止 13.2.2 論理的同値 13.2.3 宣言的並列性の形式的定義 13.2.4 合流性 13.3 8つの計算モデル 13.4 よくある抽象の意味 13.5 歴史に関する注記 13.6 練習問題
完全な初心者の状態から勉強を始めてから大体5ヶ月でウェブサービスが完成したので何を用意したり何をどうやって勉強したらいいのか色々書いてみました。
アイデアはあるんだけど、プログラムとか難しそうで自分にはウェブサービスなんて作れないと思ってる人がいたらその敷居を少しでも低くできたらいいなあなんてと思ってます。
ちなみにボクはぼんやり１年くらいはてなブックマークにのってる記事を見ていてプログラムとかできたらいいよなあなんて思っていてようやく重い腰をあげた人です。
さらに自分は文系で数学も英語もロクにできない人なので、基本的に誰でもサイトは作れると思います。
そもそも中学生でもプログラミングができるんだから大人に出来ないわけないですよね。
これからウェブサービスを作りたいっていう方の参考になればと思います。
※自分も初心者なのでまちがってることがあったら教えてください。
●何を用意すればいいのか
※自分がWindowsなので何個かWindows向けのソフトを紹介しています。
※Macの方は申し訳ないですが、Mac向けのソフトをご自分で探してください。
(1)メモ帳
アドビのdreamweaverっていう便利なソフトがあるらしいですがお金もかかるし別に必要もないと思います。
ただのメモ帳だと使いづらいのでボクは「TeraPad」っていうフリーソフトを使っています。
例えばプログラム言語ごとに表示を切り替えると、関数とかコメント部分の色が変わって見やすくなって便利です。
・TeraPad ： http://www5f.biglobe.ne.jp/t-susumu/library/tpad.html
サイトを作っても各ブラウザごとに見え方が違うのでそれぞれ確認するために何種類かブラウザをインストールしましょう。
ボクはIEとFireFoxとChromeの３つをそれぞれ表示して確認していました。
OperaとかSafariも本当は確認しないといけないと思うんですがこの3つで十分だと思います。
(3)XAMPP
ザンプって読みます。ざっくり言うとローカル環境(自分のパソコン)でプログラムを動かす環境を作るソフトです。
いちいちサーバーにアップロードしなくても、プログラムが動くかを確認できるので便利です。
またレンタルサーバーでプログラムが暴走してしまうと迷惑がかかるらしいのであらかじめ自分のパソコンで確認するのがいいようです。
・XAMPP： http://www.apachefriends.org/jp/xampp-windows.html
(4)ドメイン
何とかドットコムっていうやつです。ネット上の住所的なやつです。example.comとかexample.netとか。
ボクはお名前.comでドメインをとりました。ドメインの個人情報を隠せる？サービスがあるのが理由です。
まあどこで取っても大して変わらないと思うので目についたところで取るといいと思います。
「.com」だったら年間1000円くらいです。長すぎるドメインはとらない方がいいかもです。
(5)サーバー
ネット上にファイルをアップロードするところです。ドメインが住所だとすると土地みたいなイメージです。
ボクはさくらインターネットさんのレンタルサーバー(スタンダードプラン)を借りています。
理由はグリーの社長さんがほめてたから。お金も月額500円なので安いです。
同じ500円だとニコニコ動画のプレミアム会員になれますね。ちなみにボクは一般会員です。
さっきファイルをアップロードとかさりげなく書きましたが、そのファイルをアップロードするソフトがFTPソフトです。
ボクはFFFTPを使っています。最初使い方がわからなくて戸惑いましたが慣れれば簡単です。
・FFFTP ： http://www2.biglobe.ne.jp/~sota/
(7)FireMobileSimulator(FireFoxのアドオン)
携帯電話のサイトを確認するには基本的に実機で確認するのが一番ですが、個人で全部そろえるのは難しいです。
そこでFireFoxのアドオンのFireMobileSimulatorという拡張機能を使って簡易的に確認するのがおすすめです。
XAMPPのようなローカルサーバでも確認することができます。
・FireMobileSimulator ： http://firemobilesimulator.org/
FireMobileSimulatorで確認できるといってもやはり見え方は違います。念のため実機で確認しましょう。
ボクはiphone使っていてそれの確認はしてるんですが、androidの友達がおらんのでまだ確認してなくて実はまだ不安だったりしてます。
上と同じようにやはり実機で確認した方がいいです。特にガラケーは見え方もそうですが、プログラムがうまく動かなかったりします。
例えば、AUだけフォームに「enctype="multipart/form-data"」を入れてると文字化けするという謎の現象が起きたり。
他にも色々あって制作に時間がかかったのは正直このガラケーのせいです。色々３キャリアで統一とかしてくれないんですかねえこれ。。。
友達のY君とMさんとNさん本当にありがとうございました。匿名ブログだけど感謝してます。
●何を勉強すればいいのか。
さて具体的に何を勉強すればいいのかわからない人がいると思いますが、以下を勉強すればウェブサービスが作れます。
ということでひとつずつ説明。
マークアップ言語っていうらしいです。プログラムじゃなくてhtmlファイルを作る言語です。
とりあえずhtmlでサイトの文書の論理構造を書いて、cssでサイトの見た目をキレイにするものだと思ってください。
適当に検索すれば勉強できるサイトがたくさん出てくるのでそこで勉強してください。
本も売ってますけど基本的なところは難しくないので買う必要はないと思います。
調べると、html5とかxhtmlとかあって戸惑うかもしれませんが、とりあえずPCとスマホなら何でもいいと思います。
(ガラケーについては各キャリアごとに対応させる必要があります。書くとすごい長くなるのでガラケー用にサイトが作りたいなら調べてみてください。)
ただhtml5が一番新しいので今後勉強される人はそれの方がいいかもしれないです。
ちなみにボクはたまたま見たサイトがxhtmlの説明だったので今回はxhtmlで作りました。
まだボクは90年代初頭のホームページみたいなデザインしかできないので偉そうなことは言えないんですが(笑)
最初はhtmlだけでサイトが作れると思っていたんですが、はてなのような動的なサイトを作るときは何かしらプログラミングする必要があります。
んで、いろいろ調べるとperlやらRubyやらJAVAやら色々でてきて一体どのプログラム言語がいいのか悩むと思いますがウェブサービスが作りたいならPHPがいいと思います。
理由はウェブに特化した言語っていうのと他に比べると簡単で勉強時間が少なくて済むらしいので。
PHPなんかで本なんか買う必要はないらしいんですが、ネットのサイトだとよく理解ができなかったので本を買いました。
以下の書籍がとてもわかりやすくていいです。おすすめです。やっぱり本は体系的にまとまってるので勉強がしやすいです。
この本の通りやっていけばとりあえずプログラムが動く感覚が得られます。
あとすごい賢そうなことをやってる感覚になるので頭がよくなったような気がしますよ（笑）
MySQLもこの本で勉強ができます。MySQLというのはデータベースで、そういうソフトです。
他にもOracleとかPostgreSQLとかあるらしいですが、
とりあえずMySQLでSQL文っていうのを勉強するとデータの検索だったり、データのアップデートだったりが数行でできたりするのですごい楽になります。
決して簡単ではないですけど、思ったより難しくはなかったっていう印象です。
自分は大抵その時理解できなくてもだいたい一晩寝てから、もう一度頭からやり直すと理解できました。
(3)Apache
ボクはさくらさんのレンタルサーバーを借りていて今回はあまりいじってないんですが例えば「.htaccess」という名前のファイルを作るとapacheの設定をいじることができます。
例えばアクセスされたくないファイルがあったらそういう指定を「.htaccess」というファイルに書いておけばアクセスされないようになります。
基本的にパソコンと同じように作ればいいです。ボクは以下の本を見て勉強しました。
「iPhone+Androidスマートフォンサイト制作入門(たにぐちまこと)」
正直ネットの情報でも十分だと思いますが一度体系的に勉強するのもいいと思います。
ガラケー向けのサイトの制作は特殊で一度頭真っ白の状態で勉強した方がいいです。それだけPCとスマホとは全然違います。
ネットにも情報はたくさんありますが、断片的なものなので以下の書籍で体系的に勉強してから補助的にネットで調べた方がいいです。
この本は実践アプリケーション集というだけあってそのまま使えるコードが収録されているのがとてもいいです。
正直PHPのプログラミング自体はそこまで難しいという印象はなかったんですが、この本に出会わなかったら多分ガラケー向けのサイトは作れなかったと思います。
もしガラケー向けのサイトが作りたいならこの本を買うのが近道だと思いますよ。
CakePHPとかSymfontとかいうのがあるらしいです。
このフレームワークを使うとあらかじめある程度のところまでできてるんで、ボクみたいに全部TeraPadで手書きしなくてもいいみたいです。。。
(2)javascript
PHPはサーバーで動作するプログラム言語ですがjavascriptはブラウザ上で動作するプログラム言語です。
非同期通信なんていうよくわかんないけど何かすごいこともできたりするらしいですよ。
●もし調べまくってもわからなかったら
もし一日中検索してもよくわからなかったらそういう時はネットの頭のいい人たちに質問しましょう。
ボクは以下のサイトで質問していました。
(1)ヤフー知恵袋
巷ではヤフー知恵遅れなんて言われてますが、コンピュータ系の質問に関してはしっかり教えてくれる人がほとんどです。
ポイントを100枚くらい使うとカテゴリマスターなんていう天才が回答してくれます。
(2)２ちゃんねる
どういうスレッドなのかよく読んで質問しないとボロクソに言われますが、２ちゃんねるなのに皆さんすごい優しく教えてくれます。
たまにケンカしてたりすることもありますがそのときはケンカが終わるまで待ちましょう。ケンカの流れで質問がスルーされたりします。
ヤフー知恵袋も２ちゃんねるもそうですけど、質問するときは自分の環境をしっかり書いて何がしたいのか、どんなエラーがでるのか明確に書きましょう。
回答する人もわからないですし、自分がほしい回答がまず来ないと思います。
あと当たり前ですが回答してくれたらお礼をしっかりいいましょうね。
●こうして出来上がったウェブサービス
こうやって今回できあがったのが６人まで登録ができる招待制のレンタル掲示板です。
「ひそり-秘密共有ネットワーク」(http://hisori.com/)です。
なんだ掲示板かよー！！とか言わないでください(笑)これでもけっこうがんばったんで。。。
そういえばサイトを作ろうと思った経緯を書いてなかったんでちょろっと書いておきます。
ボクはミクシィとツイッターをやってるんですが、一瞬その時だけ仲のよかった人の更新とか見たくなかったりするんですよね。
でもマイミクを外したりフォローを外したり小心者のボクにはできなかったりするわけです。
そもそもあーいうソーシャルって自分のキャラに一貫性をもたせないといけないから窮屈なんですよね。
例えば、会社の同僚には真面目を絵を書いたようなキャラだけど学生時代の友達には下ネタ好きのどうしようもないキャラだったりすると
マイミクやフォロワーにその会社の同僚がいたら、下ネタなんか書きたくても書けないという窮屈さがソーシャルにはあるわけです。
だったらあらかじめ人数制限しておいて、例えば同じ学生時代の人しか見ることができないサイトがあれば
下ネタだって気にしないで何でも書けるよねっていう考えに至ったわけです。
今回６人までという人数制限と招待制っていう形にしているのはそういう理由と本当に仲のいい何でも話せるグループに使ってもらいたかったからです。
んで、ネットにそういうのがなさそうだったので勉強がてら自分で作っちゃえ！ってことで今回作りました。
ちなみに何で秘密共有ネットワークなのかというと「招待制無料レンタル掲示板」だとどんなサイトかイメージがつかないと思ったからです。
じゃあ何て名前にしようかと考えた結果、秘密でも何を書いても大丈夫ですという意味を込めて「秘密共有ネットワーク」って名前にしました。
とまあ、そういうことで初心者でボクみたいな完全文系の人でもこれくらいのサイトなら作れるんで
もしプログラムとか難しそうとかそういう理由でウェブサービスの制作を躊躇してる人はぜひチャレンジしてみてださい！！
※もしサイトが変な挙動がしてるとかあったら更新報告用にツイッターのアカウントを作ったんでよかったら教えてください。
http://twitter.com/#!/hisori_com/
ではでは。。。
ガチ無知というのは「HTMLとかの知識が全くない人」という意味です。他意はありません。
先日「WEBサービスを作りたい！」と思い立ったガチ無知の自分。まずHTMLから勉強した。そんな自分の理解を復習ついでにまとめてみる。
まあはてな界隈では少ないだろうけど、俺と同じガチ無知の人がいたら、HTML/CSSについてイメージが掴める、かも。間違ってたらごめんね。
HTMLをプログラミング言語みたいなもの？と思ってた人。（少なくとも俺はそうだった） 違います。
じゃあHTMLとは何か。文章を飾り付ける魔法だ。飾り付け。それ以上でもそれ以下でもない。
世の中には数多のサイトがある。数多のデザインがある。アレ全部文章の飾り付け。画像？Flash？飾り付けだ。
HTMLは、ずらっと文字だけが並んでるとページが見づらいからそれを見やすくする魔法。とりあえずそう認識しとこう。
HTMLは「文章を飾り付ける魔法」だ。じゃあ魔法を使うにはどうすればいい？
呪文を使うんだ。35まで純潔を貫き通す必要のないお手軽な魔法だ。
じゃあ呪文の使い方をば。
[呪文 飾り付けたい文章] ←これを
[呪飾り付けたい文章文] ←こう
そう、挟めばいい。HTMLは範囲指定魔法。だから効果範囲を呪文で挟む。以上。HTMLの使い方解説終了。
↓これは、文章を強調する呪文。
＜strong＞＜/strong＞
で、↓この文章の一部に魔法をかけよう
HTMLは、"HTML is Text Markup Language"の略です
これを、
＜strong＞HTML＜/strong＞は、"＜strong＞HTML＜/strong＞ is Text Markup Language"の略です
すると、
HTMLは、"HTML is Text Markup Language"の略です
こうなる、と。おしまい！
ここまででわかるだろうけど、俺の解説はものごっつい大雑把だ。
「呪文を強化する」 魔力を底上げするわけじゃない。魔導書は特定の呪文しか強化できない。
氷の魔導書を読むと、ヒャドは強化されるけど、メラは変化なし、みたいな話。
CSSと言う名の魔導書の書き方はこうだ。
強化する呪文名 { 強化内容 }
以上！
じゃあさっきHTMLの紹介で使った＜strong＞呪文を強化する魔導書をつくる。
strong {color: red;}
これは、strongに{color: red;}の効果を追加する魔導書。読んで字のごとく。色を赤にする追加効果。
さっきの飾り付けた文章が
HTMLは、"HTML is Text Markup Language"の略です
となる、と。呪文自体が強化されてるから両方赤になっている、と。
以上。終了。
さらっとメモ書きをするつもりが、すっげえ長々と書いてしまった。
まあインターネッツの大原則として、「間違ったことをドヤ顔で披露するとみんなに修正してもらえる」というのがあるので、このエントリもそういう役割を果たしてくれるんじゃないかな、、、
HTML4.0を勉強したんだけど、HTML4→HTML５の違いというのは、魔法を使う杖がランクアップしたようなもの、という認識でいいのかな？
Webサービスやアプリをつくって公開するのが好き。またブログもよく書く。その為、非プログラマーの人達にもよく知られているので”スーパープログラマー”のような評価で持ち上げられがちだが、プログラマーたちの評価はそれほど高くなくそのギャップに悩んでいる。よく起業する。
自分が使っているプログラミング言語(やエディタ)のライブラリを作って公開するのが好き。プログラミング活動が自己実現に直結したエコシステムも持っている。勉強会やオフ会によく行くので友達も多く、望んだ職場に出会えることが多い。延々とtwitter をやっている
大企業の製品の開発現場に生息する。業務の為に必要なプログラミングを学習したので目的に特化したスキルをもっている。その反面、自主的な学習意欲は少く体系的な知識がないので潰しがきかない。プログラミング以外が好き
todesking
http://tech.g.hatena.ne.jp/itkz/20101125/1290685725
本当に無限に入るんでしょうか？
それって、はてな星の脆弱性じゃないんでしょうか？ (追記 確認したらリロードされて、小さくまとまって星の数が表示されてました。何千入れてもこういう形になるから大丈夫なんでしょう。)
最近ギークハウス関係の人がお気に入りに居る人に、よく星を贈られます。
リアル中房にも
まさかマジで厨房とは知らなかったが朝日学生新聞に顔写真付きで記事が載ってるの見て知りました。
その彼は関係者じゃありません、デマがよくないと思ったんですキラキラ☆ブリブリとツイートしてましたが、お気に入りに「こちら、大変読み応えのあるコメント欄となっておりますので、是非ご覧になってみてください」と書いた人http://megalodon.jp/2011-1025-0222-41/b.hatena.ne.jp/entry/d.hatena.ne.jp/pha/20111009/1318158999%23cとギークハウスでドワンゴの人の所に星コメしてる人が居ました。
http://www.diigo.com/item/image/1wnkt/icjv
ツイートも拡散希望で困っている事協力を呼びかけたい事に関するものを、そのようにツイートするのではありません。
こちらは、その事でブログを作ってまでして訴えているのです。身内に苦しめられると言うややこしさを説明する困難とも戦いながら
どうして、こちらが支援を求めている事はやらずに、嫌がらせのようなツイートするのか聞いても、「協力するとは言っておらず一つの震災関係のデマに関する意見として見ただけです．」
それで、嫌がらせのようなツイートはします。ブクマで「warota」と入れてます。http://megalodon.jp/2011-1026-1625-52/b.hatena.ne.jp/entry/twitter.com/Tasmanian_good/status/129056457483235328
前に事件を起こした時も、ネットと現実がリンクしてるのを忘れてるような態度だった
ネットなら何をしても良い ネットなら何をしなくても良い という風潮が生まれたのは、法律はネット人格と言うのを認めてないので、匿名な場合は名誉毀損が成立しなかったからで、認めてないというより対応できてないので規定してなかった想定外だったというだけの事だと思います。
昔から官僚的態度と批判されるものはあったと思いますが、あの中学生の木で鼻を括ったような返信は、まるでそれのようだと思いました。最近の東電についても、エリートにありがちな官僚的態度は、国民に迷惑もかけ、不快感も与え、批判もされてます。それよりもっと変だしエリートかどうかもわからないですが。
前に増田が、はてなで敵を作ると書いた日記は、気持ちはあるけど、かえって迷惑という話でしたが、気持ちもなくて開き直って来るという場合は、どうなるのでしょう？しかも記名で。記名に繋がる状態で。ネットに実名とアカウントが繋がる状態で、この行状って・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
２ｃｈの物理板だったか、原子力の事がわかる板で、質問してる人にもっとこういうふうに言えばわかりやすいのに、と京大の先生の事を言ったら、なんでそんな事しないといけないんだ？と書かれた事もあったが、それは匿名だった。
http://anond.hatelabo.jp/20111022215058
この増田は支援学云々言ってるけど、傍観でも積極的傍観とも言えるこのような行為は、一緒の加害行為ではないでしょうか？
ごく普通の感性の人からしたらちょっと考えられない感覚ではないかと思います。
http://togetter.com/li/205729 光り輝くid:kabiy さんを応援してあげて id:kabiyさんは、新しいおもちゃが手に入って大変お喜びのようです。 そして、私を応援してくれる大変素晴らしい方です。 ギークハウス万歳 応援していただいたので、私も応援のお返しのエールを送りたいと思います。 光り輝くkabiyさんに、shine
http://togetter.com/li/205866 こんなに素晴らしい人権意識をお持ちのsora_hさんは、朝日学生新聞に載った大変素晴らしい栃木の中３だった！！！
http://goo.gl/ZjA77 (google cash)朝日学生新聞社に取材されました
http://backupurl.com/km7wzw googlecash保存
他にもギークハウスと初期２ｃｈの類似についてなど
ギークハウスは愛知にもあるらしいけど、そこまで巣食われてるかどうかはわからないし、全部がこうかどうかはわからないけど、みんないいひとなのに・・・(pha氏の台詞)なんてのは無いのではないかと思います。
ものすごい反社会性というか、なんていうか意地でも人の役に立たないぞ！という堅い決意みたいなものでもあるのかな？と思ってしまうほどの勢いさえ感じてしまいます。
追記
こんな超優秀な人が！！！
http://megalodon.jp/2011-1027-2233-41/www.atmarkit.co.jp/news/201104/14/sora.html
「デジタルネイティブ」の素顔
2011/04/14
オープンソースのプログラミング言語「Ruby」の開発コミュニティで、いま注目されている人がいる。福森匠大（Shota Fukumori、sora_h）さん、14歳だ。国籍、性別、年齢などは無関係というオープンソースの世界だが、これほど年若い参加者が「コミッタ」と呼ばれる開発のコアメンバーに迎え入れられることは珍しい。Ruby開発に加わった時点では中学2年生。「最年少記録」を塗り替えた。
第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 まとめ
第1章 有限オートマトン D.Perrin：橋口攻三郎 1. 序論 2. 有限オートマトンと認識可能集合 3. 有理表現 4. Kleeneの定理 5. 星の高さ 6. 星自由集合 7. 特殊なオートマトン 8. 数の認識可能集合 第2章 文脈自由言語 J.Berstel and L.Boasson：富田 悦次 1. 序論 2. 言語 2.1 記法と例 2.2 Hotz 群 2.3 曖昧性と超越性 3. 反復 3.1 反復補題 3.2 交換補題 3.3 退化 4. 非生成元の探求 4.1 準備 4.2 生成元 4.3 非生成元と代入 4.4 非生成元と決定性 4.5 主錐の共通部分 5. 文脈自由群 5.1 文脈自由群 5.2 Cayleyグラフ 5.3 終端 第3章 形式言語とべき級数 A.Salomaa：河原 康雄 1. 序論 2. 準備 3. 書換え系と文法 4. Post正準系 5. Markov系 6. 並列書換え系 7. 射と言語 8. 有理べき級数 9. 代数的べき級数 10. べき級数の応用 第4章 無限の対象上のオートマトン W.Thomas：山崎 秀記 序論 Ⅰ部 無限語上のオートマトン 記法 1. Buchiオートマトン 2. 合同関係と補集合演算 3. 列計算 4. 決定性とMcNaughtonの定理 5. 受理条件とBorelクラス 6. スター自由ω言語と時制論理 7. 文脈自由ω言語 Ⅱ部 無限木上のオートマトン 記法 8. 木オートマトン 9. 空問題と正則木 10. 補集合演算とゲームの決定性 11. 木の単項理論と決定問題 12. Rabin認識可能な集合の分類 12.1 制限された単項2階論理 12.2 Rabin木オートマトンにおける制限 12.3 不動点計算 第5章 グラフ書換え：代数的・論理的アプローチ B.Courcelle：會澤 邦夫 1. 序論 2. 論理言語とグラフの性質 2.1 単純有向グラフの類S 2.2 グラフの類D(A) 2.3 グラフの性質 2.4 1階のグラフの性質 2.5 単項2階のグラフの性質 2.6 2階のグラフの性質 2.7 定理 3. グラフ演算とグラフの表現 3.1 源点付きグラフ 3.2 源点付き超グラフ 3.3 超グラフ上の演算 3.4 超グラフの幅 3.5 導来演算 3.6 超辺置換 3.7 圏における書換え規則 3.8 超グラフ書換え規則 4. 超グラフの文脈自由集合 4.1 超辺置換文法 4.2 HR文法に伴う正規木文法 4.3 超グラフの等式集合 4.4 超グラフの文脈自由集合の性質 5. 超グラフの文脈自由集合の論理的性質 5.1 述語の帰納的集合 5.2 論理構造としての超グラフ 5.3 有限超グラフの可認識集合 6. 禁止小グラフで定義される有限グラフの集合 6.1 小グラフ包含 6.2 木幅と木分解 6.3 比較図 7. 計算量の問題 8. 無限超グラフ 8.1 無限超グラフ表現 8.2 無限超グラフの単項性質 8.3 超グラフにおける等式系 8.4 関手の初期不動点 8.5 超グラフにおける等式系の初期解 8.6 等式的超グラフの単項性質 第6章 書換え系 N.Dershowitz and J.-P.Jouannaud：稲垣 康善，直井 徹 1. 序論 2. 構文論 2.1 項 2.2 等式 2.3 書換え規則 2.4 決定手続き 2.5 書換え系の拡張 3. 意味論 3.1 代数 3.2 始代数 3.3 計算可能代数 4. Church-Rosser性 4.1 合流性 4.2 調和性 5. 停止性 5.1 簡約順序 5.2 単純化順序 5.3 経路順序 5.4 書換え系の組合せ 6. 充足可能性 6.1 構文論的単一化 6.2 意味論的単一化 6.3 ナローイング 7. 危険対 7.1 項書換え 7.2 直交書換え系 7.3 類書換え 7.4 順序付き書換え 7.5 既約な書換え系 8. 完備化 8.1 抽象完備化 8.2 公平性 8.3 完備化の拡張 8.4 順序付き書換え 8.5 機能的定理証明 8.6 1階述語論理の定理証明 9. 書換え概念の拡張 9.1 順序ソート書換え 9.2 条件付き書換え 9.3 優先度付き書換え 9.4 グラフ書換え 第7章 関数型プログラミングとラムダ計算 H.P.Barendregt：横内 寛文 1. 関数型計算モデル 2. ラムダ計算 2.1 変換 2.2 計算可能関数の表現 3. 意味論 3.1 操作的意味論：簡約と戦略 3.2 表示的意味論：ラムダモデル 4. 言語の拡張 4.1 デルタ規則 4.2 型 5. 組合せ子論理と実装手法 5.1 組合せ子論理 5.2 実装の問題 第8章 プログラミング言語における型理論 J.C.Mitchell：林 晋 1. 序論 1.1 概論 1.2 純粋および応用ラムダ計算 2. 関数の型をもつ型付きラムダ計算 2.1 型 2.2 項 2.3 証明系 2.4 意味論と健全性 2.5 再帰的関数論的モデル 2.6 領域理論的モデル 2.7 カルテシアン閉圏 2.8 Kripkeラムダモデル 3. 論理的関係 3.1 はじめに 3.2 作用的構造上の論理的関係 3.3 論理的部分関数と論理的同値関係 3.4 証明論的応用 3.5 表現独立性 3.6 論理的関係の変種 4. 多相型入門 4.1 引数としての型 4.2 可述的な多相的計算系 4.3 非可述的な多相型 4.4 データ抽象と存在型 4.5 型推論入門 4.6 型変数をもつλ→の型推論 4.7 多相的宣言の型推論 4.8 他の型概念 第9章 帰納的な関数型プログラム図式 B.Courcelle：深澤 良彰 1. 序論 2. 準備としての例 3. 基本的な定義 3.1 多ソート代数 3.2 帰納的な関数型プログラム図式 3.3 同値な図式 4. 離散的解釈における操作的意味論 4.1 部分関数と平板な半順序 4.2 離散的解釈 4.3 書換えによる評価 4.4 意味写像 4.5 計算規則 5. 連続的解釈における操作的意味論 5.1 連続代数としての解釈 5.2 有限の極大要素と停止した計算 6. 解釈のクラス 6.1 汎用の解釈 6.2 代表解釈 6.3 解釈の方程式的クラス 6.4 解釈の代数的クラス 7. 最小不動点意味論 7.1 最小で唯一の解を得る不動点理論 7.2 Scottの帰納原理 7.3 Kleeneの列と打切り帰納法 8. プログラム図式の変換 8.1 プログラム図式における同値性の推論 8.2 畳込み，展開，書換え 8.3 制限された畳込み展開 9. 研究の歴史，他の形式のプログラム図式，文献ガイド 9.1 流れ図 9.2 固定された条件をもつ一様な帰納的関数型プログラム図式 9.3 多様な帰納的関数型プログラム図式 9.4 代数的理論 9.5 プログラムの生成と検証に対する応用 第10章 論理プログラミング K.R.Apt：筧 捷彦 1. 序論 1.1 背景 1.2 論文の構成 2. 構文と証明論 2.1 1階言語 2.2 論理プログラム 2.3 代入 2.4 単一化子 2.5 計算過程―SLD溶融 2.6 例 2.7 SLD導出の特性 2.8 反駁手続き―SLD木 3. 意味論 3.1 1階論理の意味論 3.2 SLD溶融の安全性 3.3 Herbrand模型 3.4 直接帰結演算子 3.5 演算子とその不動点 3.6 最小Herbrand模型 3.7 SLD溶融の完全性 3.8 正解代入 3.9 SLD溶融の強安全性 3.10 手続き的解釈と宣言的解釈 4. 計算力 4.1 計算力と定義力 4.2 ULの枚挙可能性 4.3 帰納的関数 4.4 帰納的関数の計算力 4.5 TFの閉包順序数 5. 否定情報 5.1 非単調推論 5.2 閉世界仮説 5.3 失敗即否定規則 5.4 有限的失敗の特徴付け 5.5 プログラムの完備化 5.6 完備化の模型 5.7 失敗即否定規則の安全性 5.8 失敗即否定規則の完全性 5.9 等号公理と恒等 5.10 まとめ 6. 一般目標 6.1 SLDNF-溶融 6.2 SLDNF-導出の安全性 6.3 はまり 6.4 SLDNF-溶融の限定的な完全性 6.5 許容性 7. 層状プログラム 7.1 準備 7.2 層別 7.3 非単調演算子とその不動点 7.4 層状プログラムの意味論 7.5 完全模型意味論 8. 関連事項 8.1 一般プログラム 8.2 他の方法 8.3 演繹的データベース 8.4 PROLOG 8.5 論理プログラミングと関数プログラミングの統合 8.6 人工知能への応用 第11章 表示的意味論 P.D.Mosses：山田 眞市 1. 序論 2. 構文論 2.1 具象構文論 2.2 抽象構文 2.3 文脈依存構文 3. 意味論 3.1 表示的意味論 3.2 意味関数 3.3 記法の慣例 4. 領域 4.1 領域の構造 4.2 領域の記法 4.3 記法上の約束事 5. 意味の記述法 5.1 リテラル 5.2 式 5.3 定数宣言 5.4 関数の抽象 5.5 変数宣言 5.6 文 5.7 手続き抽象 5.8 プログラム 5.9 非決定性 5.10 並行性 6. 文献ノート 6.1 発展 6.2 解説 6.3 変形 第12章 意味領域 C.A.Gunter and D.S.Scott：山田 眞市 1. 序論 2. 関数の帰納的定義 2.1 cpoと不動点定理 2.2 不動点定理の応用 2.3 一様性 3. エフェクティブに表現した領域 3.1 正規部分posetと射影 3.2 エフェクティブに表現した領域 4. 作用素と関数 4.1 積 4.2 Churchのラムダ記法 4.3 破砕積 4.4 和と引上げ 4.5 同形と閉包性 5. べき領域 5.1 直観的説明 5.2 形式的定義 5.3 普遍性と閉包性 6. 双有限領域 6.1 Poltkin順序 6.2 閉包性 7. 領域の帰納的定義 7.1 閉包を使う領域方程式の解法 7.2 無型ラムダ記法のモデル 7.3 射影を使う領域方程式の解法 7.4 双有限領域上の作用素の表現 第13章 代数的仕様 M.Wirsing：稲垣 康善，坂部 俊樹 1. 序論 2. 抽象データ型 2.1 シグニチャと項 2.2 代数と計算構造 2.3 抽象データ型 2.4 抽象データ型の計算可能性 3. 代数的仕様 3.1 論理式と理論 3.2 代数的仕様とその意味論 3.3 他の意味論的理解 4. 単純仕様 4.1 束と存在定理 4.2 単純仕様の表現能力 5. 隠蔽関数と構成子をもつ仕様 5.1 構文と意味論 5.2 束と存在定理 5.3 隠蔽記号と構成子をもつ仕様の表現能力 5.4 階層的仕様 6. 構造化仕様 6.1 構造化仕様の意味論 6.2 隠蔽関数のない構造化仕様 6.3 構成演算 6.4 拡張 6.5 観測的抽象化 6.6 構造化仕様の代数 7. パラメータ化仕様 7.1 型付きラムダ計算によるアプローチ 7.2 プッシュアウトアプローチ 8. 実現 8.1 詳細化による実現 8.2 他の実現概念 8.3 パラメータ化された構成子実現と抽象化子実現 8.4 実行可能仕様 9. 仕様記述言語 9.1 CLEAR 9.2 OBJ2 9.3 ASL 9.4 Larch 9.5 その他の仕様記述言語 第14章 プログラムの論理 D.Kozen and J.Tiuryn：西村 泰一，近藤 通朗 1. 序論 1.1 状態，入出力関係，軌跡 1.2 外的論理，内的論理 1.3 歴史ノート 2. 命題動的論理 2.1 基本的定義 2.2 PDLに対する演繹体系 2.3 基本的性質 2.4 有限モデル特性 2.5 演繹的完全性 2.6 PDLの充足可能性問題の計算量 2.7 PDLの変形種 3. 1階の動的論理 3.1 構文論 3.2 意味論 3.3 計算量 3.4 演繹体系 3.5 表現力 3.6 操作的vs.公理的意味論 3.7 他のプログラミング言語 4. 他のアプローチ 4.1 超準動的論理 4.2 アルゴリズム的論理 4.3 有効的定義の論理 4.4 時制論理 第15章 プログラム証明のための手法と論理 P.Cousot：細野 千春，富田 康治 1. 序論 1.1 Hoareの萌芽的な論文の解説 1.2 C.A.R.HoareによるHoare論理のその後の研究 1.3 プログラムに関する推論を行うための手法に関するC.A.R.Hoareによるその後の研究 1.4 Hoare論理の概観 1.5 要約 1.6 この概観を読むためのヒント 2. 論理的，集合論的，順序論的記法 3. プログラミング言語の構文論と意味論 3.1 構文論 3.2 操作的意味論 3.3 関係的意味論 4. 命令の部分正当性 5. Floyd-Naurの部分正当性証明手法とその同値な変形 5.1 Floyd-Naurの手法による部分正当性の証明の例 5.2 段階的なFloyd-Naurの部分正当性証明手法 5.3 合成的なFloyd-Naurの部分正当性証明手法 5.4 Floyd-Naurの部分正当性の段階的な証明と合成的な証明の同値性 5.5 Floyd-Naurの部分正当性証明手法の変形 6. ライブネスの証明手法 6.1 実行トレース 6.2 全正当性 6.3 整礎関係，整列集合，順序数 6.4 Floydの整礎集合法による停止性の証明 6.5 ライブネス 6.6 Floydの全正当性の証明手法からライブネスへの一般化 6.7 Burstallの全正当性証明手法とその一般化 7. Hoare論理 7.1 意味論的な観点から見たHoare論理 7.2 構文論的な観点から見たHoare論理 7.3 Hoare論理の意味論 7.4 構文論と意味論の間の関係：Hoare論理の健全性と完全性の問題 8. Hoare論理の補足 8.1 データ構造 8.2 手続き 8.3 未定義 8.4 別名と副作用 8.5 ブロック構造の局所変数 8.6 goto文 8.7 （副作用のある）関数と式 8.8 コルーチン 8.9 並行プログラム 8.10 全正当性 8.11 プログラム検証の例 8.12 プログラムに対して1階論理を拡張した他の論理 第16章 様相論理と時間論理 E.A.Emerson：志村 立矢 1. 序論 2. 時間論理の分類 2.1 命題論理 対 1階述語論理 2.2 大域的と合成的 2.3 分岐的 対 線形 2.4 時点と時区間 2.5 離散 対 連続 2.6 過去時制 対 未来時制 3. 線形時間論理の技術的基礎 3.1 タイムライン 3.2 命題線形時間論理 3.3 1階の線形時間論理 4. 分岐的時間論理の技術的基礎 4.1 樹状構造 4.2 命題分岐的時間論理 4.3 1階の分岐的時間論理 5. 並行計算：その基礎 5.1 非決定性と公平性による並列性のモデル化 5.2 並列計算の抽象モデル 5.3 並列計算の具体的なモデル 5.4 並列計算の枠組みと時間論理の結び付き 6. 理論的見地からの時間論理 6.1 表現可能性 6.2 命題時間論理の決定手続き 6.3 演繹体系 6.4 モデル性の判定 6.5 無限の対象の上のオートマトン 7. 時間論理のプログラムの検証への応用 7.1 並行プログラムの正当性に関する性質 7.2 並行プログラムの検証：証明論的方法 7.3 時間論理による仕様からの並行プログラムの機械合成 7.4 有限状態並行システムの自動検証 8. 計算機科学における他の様相論理と時間論理 8.1 古典様相論理 8.2 命題動的論理 8.3 確率論理 8.4 不動点論理 8.5 知識 第17章 関係データベース理論の構成要素 P.C.Kanellakis：鈴木 晋 1. 序論 1.1 動機と歴史 1.2 内容についての案内 2. 関係データモデル 2.1 関係代数と関係従属性 2.2 なぜ関係代数か 2.3 なぜ関係従属性か 2.4 超グラフとデータベーススキーマの構文について 2.5 論理とデータベースの意味について 3. 従属性とデータベーススキーマ設計 3.1 従属性の分類 3.2 データベーススキーマ設計 4. 問合わせデータベース論理プログラム 4.1 問合わせの分類 4.2 データベース論理プログラム 4.3 問合わせ言語と複合オブジェクトデータモデル 5. 議論：関係データベース理論のその他の話題 5.1 不完全情報の問題 5.2 データベース更新の問題 6. 結論 第18章 分散計算：モデルと手法 L.Lamport and N.Lynch：山下 雅史 1. 分散計算とは何か 2. 分散システムのモデル 2.1 メッセージ伝達モデル 2.2 それ以外のモデル 2.3 基礎的概念 3. 分散アルゴリズムの理解 3.1 挙動の集合としてのシステム 3.2 安全性と活性 3.3 システムの記述 3.4 主張に基づく理解 3.5 アルゴリズムの導出 3.6 仕様記述 4. 典型的な分散アルゴリズム 4.1 共有変数アルゴリズム 4.2 分散合意 4.3 ネットワークアルゴリズム 4.4 データベースにおける並行性制御 第19章 並行プロセスの操作的および代数的意味論 R.Milner：稲垣 康善，結縁 祥治 1. 序論 2. 基本言語 2.1 構文および記法 2.2 操作的意味論 2.3 導出木と遷移グラフ 2.4 ソート 2.5 フローグラフ 2.6 拡張言語 2.7 その他の動作式の構成 3. プロセスの強合同関係 3.1 議論 3.2 強双模倣関係 3.3 等式による強合同関係の性質 3.4 強合同関係における置換え可能性 3.5 強等価関係上での不動点の唯一性 4. プロセスの観測合同関係 4.1 観測等価性 4.2 双模倣関係 4.3 観測合同関係 4.4 プロセス等価性上での不動点の唯一性 4.5 等式規則の完全性 4.6 プロセスの等価性に対するその他の概念 5. 双模倣等価関係の解析 5.1 等価性の階層構造 5.2 階層構造の論理的特性化 6. 合流性をもつプロセス 6.1 決定性 6.2 合流性 6.3 合流性を保存する構成子 7. 関連する重要な文献
はてな匿名ダイアリーを見て思った、最速でプログラミング言語を覚える為の10か条。
最初に覚える言語は、目的が明確でない場合はJavaかPythonを推奨する。言語仕様が簡潔で、資料が豊富で、応用範囲が比較的広い。
最近、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を残して廃棄処分。 |
お前もうすうす気付いてると思うんだ。この村は時空のハザマでループしてるって。発生源は村民の中の誰か。プログラミングを身に付けたい、でも身に付かない歯痒い思い。その人物を特定できりゃ早いんだが、虱潰しに探すにはもう人口が増えすぎてる。ループを抜け出す鍵は、村民全員が何でも良い、ひとつ以上の言語の基礎文法を完全マスターすること。でもこれは無理だ。
現実解としては…俺とお前と、やる気のある奴だけでコードを書くことだ。別に完全マスターなんてしなくてもいいんだ。
さて。
①はてな的プログラミング言語人気ランキング - Life like a clown 1144users
http://b.hatena.ne.jp/entry/d.hatena.ne.jp/tt_clown/20100202/1265096776
②高速でプログラミング言語をマスターするのに有効な記事まとめ - NAVER まとめ 2650users
http://b.hatena.ne.jp/entry/matome.naver.jp/odai/2129649658966682001
③短期間でプログラミング言語を覚えるのに役に立ちそうなサイトまとめ | ラジック 1615users
http://b.hatena.ne.jp/entry/rajic.2chblog.jp/archives/51811716.html
2.まとめ出現「これはすごい」
3.それを覚えてたやつがVIPPERの質問に回答「しょうがねえな どんどん行くぞ」
4.まとめブログが捕捉
まとめのまとめのまとめ(時々劣化)を有難がるという構造。
VIPPERも村民も中の人は大体同じだろうし言わないよ？ お前ら③の元スレの>1以下だなんて。自覚はあると思うし。
情報をまとめるという行為に価値を認めるのはなんというか社会的成熟の表れって感じで嫌いじゃなかった。メタだよね。村なのに現代的。でも水が流れ続ける有名なエッシャーの騙し絵よろしく、同じ空間を無限に下流に向かって流れ続けるのはいかがなものかと。
①と②が同日エントリーっぽいので断定するのもあれだけども、仮にですよ。数日後に③のブクマ数が①や②を完全に凌駕するようなことになったら…記事をまとめ直すだけで元記事より格段に釣られる人数が増えるなんて、どんな釣堀だよと。エントロピーのなんちゃら…は関係ないか。
新年度だし気持ちは分からんでもないけれど、2ヶ月という短期間でループが発生したのを目の当たりにしたので 自戒を込めて指摘
そもそもの各記事のタイトルにあるように「基礎文法」なんだから、皆さんサクっと完全マスターしてもっと上のレベルに進んでくださいよっていう思いもある。皆でbreak;
}
PHPerの問題点は、視野が狭いこと。典型的には以下のような悪癖を持つ。
何も知らないからPHPを愛せるんだよ、PHPerは。だからまず、HTML、CSS、JavaScript、SQLを覚えろ。次に、Javaに移行しろ。そんなに難しくないよ、Java。特に大量にコードを書けるPHPerは、速度が出てライブラリ化が容易なJavaの方が向いている。今はVPSがあるので、小規模案件でも問題ない。
15年間ほどPHPはインターネットを支えてきたが、そろそろ設計の脆さが問題になっている。PHP 6の開発が振り出しに戻ったのは、不幸な事故ではない。ウェブで仕事をしていれば、PHPとJavaで共通する知識も多い。PHPerはJavaを覚えてPHPとさよならしろ。そして恥ずかしい悪癖を直すべきだ。
亀仙流やつ鶴仙流など、世の中にはいくつかの流派（＝クラス）があり、それぞれの流派にかめはめ波やどどん波、舞空術などの技（メソッド）がいくつかあります。
実際に流派にある技を使う場合、技を覚えているZ戦士（インスタンス）が必要になります。
例）亀仙流を覚えた孫悟空を使ってかめはめ波を放って敵を倒す goku = new KamesenRyu("goku"); goku.shootKamehameha(teki);
Z戦士によっては複数の流派の技が使えたり、自分の技を人に教えることが出来ます（継承）。
また悟空とクリリンのように同じ流派でも同じ技で違う性能を持っていたり、オリジナルの技を持っているなどの違いがあります。
クラスはセルを作るためのZ戦士達の遺伝子情報と言っても良いかもしれません。
例）セルを作りましょう。 class Cell extends Goku,Veget,Picoro,Tenshinhan,Kuririn{ .... } cell_inst = new Cell(); cell_inst.shootKienzan(); //Kuririnをextendsしているので気円斬が使えます。
世界（プログラミング言語）によってはただの人を後付でZ戦士にすることが可能です。
(JavaScriptやRubyなど）
noumin = new Hito();
noumin.kougekiKuwa = function(){
//戦闘力たったの5…ゴミめ！
};
noumin.shootKamehameha = function(){
//な、なんだと！？
};
農民がいきなりかめはめ波をうつようになったら危険ですね、危ないです。
このように後付でメソッドを追加出来るタイプは危険性を含んでいます。
とても良いつっこみが来たので追記します。
前半部分ではZ戦士をインスタンスとしましたが、セルを作るにはZ戦士がインスタンスでは出来ないので
何をインスタンスにして、何をクラスにするかが「設計」なんですね。
セルの第一段階ではGokuなどのZ戦士の遺伝子があれば作ることが出来ました。
cell_inst = new Cell(); //このセルは第一段階
cell_inst.absorb(17gou); //第二段階に変身 cell_inst.call18gou(); cell_inst.absorb(18gou); //最終段階に変身 class Cell ....{ function call18gou(){ if(!this.17gou)return error(); //17号を吸収していないと失敗する this.17gou.speak("＊＊＊＊略＊＊＊＊＊ドクターゲロ様＊＊＊＊略＊＊＊＊"); } }
17gouを吸収したので、17号の声で18号を呼ぶことが出来るようになりました。
でもドクターゲロ「様」って言ったのでセルだってバレバレですね。
http://anond.hatelabo.jp/20110316224648
クロージャについてちゃんと書こうと思って挫折。どなたか良いアイディアを下さい。
変数のスコープを解説する必要があるかなと思ったんですがオブジェクト指向からは外れるような気がします。
エネルギー波→連続エネルギー波がどこかに使えそうな気がしましたが、気のせいだったぜ…
プログラミング言語ヒエラルキーにおける罵倒 http://anond.hatelabo.jp/20070502200124
phpのいやなところ / perlのいやなところ http://anond.hatelabo.jp/20070522174725
LL編プログラミング言語ヒエラルキーにおける罵倒 http://anond.hatelabo.jp/20070503000905
1年くらい前にKENTWEBでCGIを覚えた私はどれくらい時代にとり残されているんだろう http://anond.hatelabo.jp/20070427114039
PHPで自称ギークとかアホか。 http://anond.hatelabo.jp/20080527201030
文系の大学出身の人が気軽にプログラマになることはお勧めしません。 http://anond.hatelabo.jp/20080830010043
[Perl][PHP][Python][Ruby] 無題 http://anond.hatelabo.jp/20080731154801
プログラミング始めてみた(笑) http://anond.hatelabo.jp/20080201185253
日本が誇るスゴ腕geekの紹介 http://anond.hatelabo.jp/20090102145542
PHPの比較の素晴らしさ加減は正常 http://anond.hatelabo.jp/20090617130518
言語による分野の住み分けがすでにできてるんだよ http://anond.hatelabo.jp/20110220120714
なぜJavaの求人が多いのか考えよう。 http://anond.hatelabo.jp/20110220101806
LL言語が後退局面に差し掛かっている件 http://anond.hatelabo.jp/20110210084023
これからweb開発に携わりたいと考えている人にお勧めの言語 http://beta.anond.hatelabo.jp/20110220013933
※はてな匿名ダイアリーの標準スタイルシートでデコるバッドノウハウ http://anond.hatelabo.jp/20100827202157
一説によると有史以来開発されたプログラミング言語は4000を超えるとされている。その中でどの言語を選べばいいのか初学者にとっては悩みの種であろう。この記事ではそんな初学者のとっかかりとなることを想定して書かれている。
Javascriptは長らく「使えない糞言語」とのレッテルを張られていた言語である。2005年頃からAjaxの台頭で価値が見直され、2010年頃からはnode.jsの盛り上がりで一気にweb開発の主要言語の一つに躍進した。
node.jsは現在活発に開発が進んでおり今年中には実践投入が可能になる画期的なアーキテクチャとなる可能性が高い。それによって「クライアントサイド」と「サーバーサイド」をどちらもJavascriptで開発できることになり、これはよく比較対象にされるLLのライバル達が絶対になし得る事の出来ない独占的なメリットである。iPhoneやandroidのアプリをJavascriptで開発が可能なTitaniumの登場で最早死角が見当たらない状況になっており、求人数は急伸することが予想されている。
web開発初心者がファーストチョイスするプログラミング言語に最も適していると自信を持って断言できる唯一の言語である。
この言語の対象分野：クライアントサイド、サーバーサイド、スマートフォン(iPhone,android)
著名なプログラマ：amachang(webエンジニアのアイドル) mala(Best Japanese Javascript Programmer)
COBOLのようなレガシー言語を除けば世界中で最も基幹分野に使われている重要で需要の高い言語はJavaである。求人数も圧倒的に多く安定した職が得やすい。LLに比べて冗長な記述が必要とされるがその反面高いパフォーマンスを実現しており、またプラットフォームを問わない広い守備範囲と大規模開発に向く言語特性が相まって10年近くプログラミング言語の王者として君臨している。
近年web分野でも大規模データ処理が求められるようになってきたが低パフォーマンスなLLでは実現不可能な大規模分散処理をJavaは可能にしている。オープンソースプロジェクトの雄ApacheプロジェクトでもJavaが使われたソフトウェアの勢いが最も盛んである。
初学者が習得するのには少し時間がかかると言われているが一度習得してしまえば君の知肉となり人生を豊かなものに導いてくれる万能言語と言えるだろう。
この言語の対象分野：サーバーサイド、スマートフォン(android)
著名なプログラマ：ひがやすを
webフレームワークの歴史を変えたRuby on Railsの登場により一気にwebアプリケーション開発の主役級に躍り出たRubyも初学者にお勧めできる言語の一つだ。シンプルで可読性の高い文法で簡単に習得できるであろう。しかし他の言語と比べると求人数は少なく、後述するPythonの伸びにも押されてシェアはあまり伸びないとされる。
著名なプログラマ：matz(Ruby開発者 世界的に最も名の知れた日本人エンジニア)
Rubyとよく比較される事の多いPythonは今後５年かけてシェアを確実にのばすJavascript以外の唯一のLLである。Googleが肝いりであるという抜群の追い風にのって世界的にはシェアを急速にのばしつつあるが日本国内ではあまり人気がない為にweb上の情報が少ないのが難点。国内での求人はほとんど無い。Ruby同様にシンプルな文法で可読性が高く学びやすい。オライリーの書籍等でアルゴリズムの解説に使われる事が多くなってきたために書けなくとも最低限読めるようになっておくとよい。
もはやPerlプログラマと名乗るだけで嘲笑の的となった感のあるレガシー言語。進化の速いwebにおいて10年前からほとんど何も変わらない希有な存在。「モダンなPerl」などと質の低いマーケティング戦略に頼らざるを得ない悲しいぐらい進歩が無いために最も勧められない言語である。
著名なプログラマ：otsune(年中暇そうなnetwatcher)