 
|
はてなキーワード: Pythonとは
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を糞言語たらしめる最大の弱点である永久凍土の問題。コミュニティが凍れば言語の進歩も凍る。
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 流と想像。
これを読みづらいと感じるのは、左から右に流れる
もしかしてアラビア語ネイティブな人からすると逆に読みやすいのか？
JavaScript って生き物っぽいって思ったのがきっかけだった。
なんか菌？に遺伝子いれてたんぱく質を生産させるやつ？ Function は菌の細胞膜で prototype は遺伝子で、だから prototype に全然関係ない違う生物の遺伝子を生きてる菌に入れちゃったり。そうすると全然ちがうたんぱく質が生産されたり。prototype にべべーっとコピーして追加するのなんてまさしくそれっぽい。
だってプロトタイプベースって、生き物しかいない世界じゃない？基本的に。インスタンスってのは生き物じゃない設計図があってそれにしたがって出来た生き物がインスタンスってイメージあんだけど。プロトタイプベースの世界にはそんな設計図も生き物じゃないものもないよね？なのにわざわざインスタンスっていうのに何か違和感？ご都合主義的なもの感じる。クラスは型で、インスタンスを実体だとかなんとかって氾濫してるせいかな。多分この辺の用語が JavaScript をわかりにくくさせてる気がする。
僕の感覚では、オブジェクトってのは生き物で、クラスベースってのは神が設計図に基づいて生き物を生産してる世界で、インスタンスベースってのは生き物が生き物を複製してる世界のイメージだ。多分、原始の生物はインスタンスベースみたいな世界で、海の中にうようよしてたんだろうな、とか。
オブジェクトじゃないものは、生き物じゃない死んでるたんぱく質や RNA の破片みたいな。それだけじゃなにもできないみたいな。それだけじゃ命がないから、生き物の殻に詰めるってのが JavaScript のコンストラクタのイメージ。
Perl の bless したらこれはもう命入ったよ生き物だからねっあとは勝手にしてねってのも、Python の名前空間さえあればなんとかなるよねってのも、JavaScript のハッシュさえあれば世界作れるよねってのも、みんなどこか似ている。ちゃんと OOP を理解できてるかは別としてもこの三つはわりとすぐやりたいことができた。昔 Java の本を買ってきて挫折したのにくらべたら、なぜかずっとわかりやすかった。（bless という命名はすごく洒落てる）
全然関係ないけど、Django の日本語リファレンスは何か萌える。ラクダ本の日本語訳はむかつくのに。
プログラミングを始めたばっかりの時は、なんだか難しい用語の意味を理解しないと OOP がわからないと思ってた。それは僕らの住んでる世界とは全然関係のないプログラミングの技術ってやつだと思ってた。
でも多分違う。
世界が動く仕組みさえあれば、あとは作り手に世界の成り立ちを抽象化する表現力さえあれば、世界は勝手に表現されていくし、動き出してく。たまたま僕らの世界はオブジェクトなもので溢れていて、プログラミング言語が進化すれば世界に似るのも当然だろう。いや逆か。プログラミング言語が世界に似てきたから、オブジェクトなんていう世界に似た概念が出てきたってことか。なんだか難しい用語ってのは、その表現の一部分の技術に名前をつけてるだけなんだな、と。例えば何とか歌唱法や何々画法とか何とかレトリックとかパースの取り方みたいなのと同じ。それは表現を理解する手助けにはなるけど、その意味を知る事がイコール表現力をあげることにはならないんだよね。これに気づくのに遠回りしすぎたなあ。
（知識を得るだけで、100% 還元される人もいるかもしれないけど、そんなのは一部の天才だけだと思う。殆どの凡人はそうはいかない。とはいえ、元の錬度が低ければ、コツをいくつか教わるだけでいきなりうまくいくこともある。ただ、それをまるまんま実力だと思うのは、どんな分野でも危険だ。恋愛テクニックやらを必死に読んでる連中が男女間の深い人間関係を上手くやれてるとはちょっと想像できない！）
プログラミングで表現力を上げるにはどうすればいいんだろう。きっと他と同じだろうな。いい表現を沢山味わって、世界をよく観察して、どう成り立ってるかどう動いてるか、私達はそれをどう認知しているのか、考えることかもしれない。漫画家を志す人が美術解剖学を学んだり、優れた画家が絵筆で世界を生々しく描写するように、優れたプログラマは世界のなりたちをプログラムに写し取ったり、世界の仕組みを作る事が出来るのだと思う。
http://webrocketsmagazine.com/entry/20111209/html-code-generation-using-excel.html
http://mattn.kaoriya.net/software/vim/20111215034338.htm
http://d.hatena.ne.jp/takuya_1st/20111217/1324105198
真のプログラマーなら単純なHTML生成するのにテキストエディタは使わないよ。単純なHTML生成が必要なプログラマーなら、プログラムでやるでしょ。いちいちプログラムを書くのがだるい？いやいや、単純なHTMLの生成が必要なプログラマーなら、リストやディクショナリといった汎用的なデータ構造やCSVファイルといった汎用的な形式のファイルから、自動的にHTMLを出力するライブラリぐらい書いてるでしょ。わざわざ同じ作業をやるなんてめんどくさい。それにそのプログラムは他でも使うことができるしね。しかもPythonやRubyならほぼシェル感覚で使える。わざわざテキストエディタを使って同じ作業をする必要性はないね。真のプログラマーなら単純なHTMLの生成はプログラムでやるでしょ。プログラマーなんだから。
そういう原理的にどうかという話ではなくて、単にC#とかJavaとかだと何するにもまずclass宣言から入らないといけなくて、初心者的にはなんだよそれってなると思うという程度の話。
python(LL)ならクラスも使えるけど(便利な関数のついた)Cっぽくも書けるわけだし、型付けとか煩わしいことも少なくていいじゃんという程度。
Javascriptって触ったことないけど、むしろ関数型だと聞いたんだけどどうなのかね。pythonもかなり関数型っぽいけど。
ただまぁVBはねーだろって思う。
Action Script は 3 からかなりしっかりしたクラスベースの OO だよ。
JS も馬鹿みたいな使い方しないでちゃんとしたスタイルで使えば OO だし、全てがハッシュというオブジェクトだし、関数もオブジェクトだしその辺わからないと JS をつかっててもコピペプログラミングに終始して面白くないから結局 OO 理解しないといけない。prototype.js や jQuery やの中身とか読んで理解できるくらいになるには。
Perl だって悪しき過去の遺産が残ってるから OO じゃないイメージが一部にあるけど、モダンな Perl は OO だよ。CPAN にあがってるまともなモジュールは殆ど OO スタイルだし、もっとモダンなスタイルの環境でもいける。モダン Perl や Moose あたりで検索してみるといい。今からやるなら OO しかないけど、初心者は昔のうんこを踏みがちだよね。JS も同じ事が言えるけど。
JS や Perl というゆるい LL は OO を理解していなくても一応使えるってだけで、それじゃマスターには程遠い。あと言語仕様でやっちゃいけないことを縛っていないから、しっかりした開発をやるには 規約もしっかりしないといけない。 初心者は最初からいい出会いをするわけじゃないから、誤解が多いのかもしれない。
JS と Perl はレガシースタイルが残ってる例としてあげたけど、LL でも Python や Ruby はもともと OO スタイルしかない。だから、自分でやってることを理解してないと過去のうんこを踏む可能性のあるゆるい LL よりは、どうやっても綺麗にしかかけない Python は初心者向けだと思う。知り合いが何でも良いからプログラミングやってみたいと言い出したら GAE で Python 弄らせる。
ぶっちゃけ LL でもいまどき OO を避けて通るなんて無理。
プログラミングスキルは、本質的には言語に依存しない。 (よほど糞な言語を使うのでなければだが) OO への理解やアルゴリズムの理解ってのは LL か巨大な言語かに依存しない。絵を描くのに道具によって慣れの差はあっても画力は道具を変えても持ち越せる共通した力だというのに似ている。一つの言語をちゃんとある程度マスターすれば、他の言語の習得はとても早い。たとえ最初にやる言語が LL でもね。別の言語をやるときに壁になるのは関数型かそうでないかくらいのパラダイムの差がある場合だけど、JS や Perl でさえ 関数型で使うようなテクニック を実装できるし使いどころがあるから、やっぱり共通点はあって、～だから～を学ばなくていい、なんてのは上達したいなら殆どない気がする。
違うけど。
printf("Hello World!!\n");
の先にあるんだ。
データ処理をしたい、ユーザーに選択させたい、次のステップに進むとき、マイクロソフト系は環境を用意しやすいんだよ。
データベースアクセスだって、ＶＢならアクセスライクのＤＢでＳＱＬを疑似体験できる。
ここのステップを超えられないと、プログラムで「何が出来るか」に気付けずに、「つまんない」で終わっちゃうんだよ。
正味な話、PHPとかpythonって、初心者に「次」を用意するのがしんどいんだよ。
プログラミングは静的言語(C/C++,Java,C#など)と動的言語(rubyとかpythonとかperlとかいわゆるスクリプト言語)と関数型(lispとかF#とかhaskellとか)を一つずつくらい眺めた方がいいと思う。
どれか一個くらい自分に合ってるのが見つかるかも。
やりたいことにどの実装系が一番適しているかを考えるべきで、実装系を目的に合わせるべきじゃない。
そういう考えでいると、PHPで何でもやる奴とか出てきて迷惑なんだ。
そもそものロジック構築などは、ターゲットには依存しても、言語にはほとんど依存しない。
馴染むための登竜門って意味で言えば、VisualStudioなどのGUIでデバッグが出来る環境をもった言語が良いし、VB,C#などのサンプルが豊富で結果を確認しやすい言語が良いと思う。
C
をこの順番で覚えた。
変り種は2006年に勉強を始めたC++で、軽量言語花盛りのその時期に、CGIを書きたいがためにC++を学んだ。
C++は習得が難しい言語と言われているが、必要性を感じなかったので参考書の類は買わなかった。
他の言語もそうだ。
参考書は必要なかった。
これ自体は悪い本ではない。
でも結局、最初のWEBアプリ（サービス）はPHPではなくC++で作った。
この読書は、購入前に漠然と感じていたPHPへの不快感を再認識させただけだった。
そして学んだ。
歴史は繰り返す。
今まさに「明解Java 入門編」を購入しようか思案中なのだ。
今までJavaを避けてきたのは「ジェームズ・ゴスリンが嫌い」あるいは「金の匂いがする」からだ。
PHPの経験から言って、Javaも実用できないかもしれない。
Javaを覚えれば幅が広がるのは分かるんだけど…
なぜだろう、ワクワクしない。
上位レイヤーの話はしてないんだけどね。
「Python」でも良いし、「JRE」でも良いし、「HSP」でも良いよ。
「正しい申告」と言うのは、自身が必要とする実行環境についての、正しい申告。（リビジョンとかね）
「すべてのアプリが、自身が必要とする実行環境を必ず用意する」方が、一般市民御用達のWindowsではユーザーにやさしい。
配布サイトが変わる実行環境やライブラリって結構あるが、それは「アプリが独自に解決」すべきなのか。
それとも、それらの実行環境を配布する人は、逐一公的な実行環境としてマイクロソフトに報告しなきゃならなんのか。
１年前の記事がリンクすべて死んでるとかざらにある。
って言うようなパッケージは、自力で解決しろよ、と思うんだが？
ここがどういうことを言ってるのかちょっとよくわからないんだけど、
アプリ間の依存関係はまぁそれほど問題にならないからどうでもいいかな。
下位レイヤがほんと酷い。
dllだのランタイムライブラリだの、スクリプト言語の実行環境だの何だの
パッケージ単位で全部解決させようとするからどのインストーラにもいちいちpythonとか入ってやがる。
逆にその辺がまとまってないソフトを入れようとすると、依存関係を自分で解決する必要があって大体ハマる。
週末に行ってきたイベントだが、ちょっとインパクトが強すぎて、あとたぶん昼から通しで追っかけてるのは自分だけなので、この話誰かに伝えたい！と柄にもなく思ってしまった。
ここまで、日本語でウケを取り、アメリカ人にしか聞こえない英語をしゃべりつつの話。まじありえないレベルの覚悟と実践なんだが・・・！
この人のセッション、ブラジル事情の紹介みたいな話で大ホール側のセッションも覗いてみようかなと思っていた所にこれで、ただちに絶対参加すべきレベルのセッションに格上げされた。こんな人がいるとは。
で、昼休み後の問題のセッション。結局ツイートどころじゃなかったが、こんな感じ：
Javaはあれが酷いとかPHPがとかいう態度でRubyを使うのも無駄だ。
なんという激熱トーク。本当に小さかった南米のRubyコミュニティを仲間と共に成長させ、いまやRubyConf Brazilとか南米で何個もイベントが立ち上がるまでに育てた。この伝道のため、ここ数年で８０箇所は回って普及に努めたとかとか。ブラジル事情への関心と関係なく、この熱量を体験できてよかった。
最後の時間オーバー後の「あと一言だけ（本当はあと１分だけと本人は言っていたのだが、わざと誤訳してタイマー役の人に会場から叫んだ自分w）」でどんなにダメだとされていても、諦めずに進めという、過去の偉人が貶められたり失意にあった時代の動画もよかった（もっとも、この話は知っていたのでインパクト自体は薄めだった）。
この後はLTとクロージング。
インパクト強すぎｗ
これ漫画系展開をバックボーンにしたエンタテイニングなスタイルだと理解せずに真に受けると大変だなと心配になったり。なにしろ上は三行だけど全部通しで書くと
真面目に受け取ったらヤバイ発言多すぎだろ・・・
こ れ が 締 め の 講 演 か よ ！
そういえば途中にまどマギネタも入ってた記憶があるのだが、上のインパクトが強すぎてどこかに飛んでった。
その後の高橋さんの最後の挨拶とスタッフを集めてのスタンディングオベーションはちょっとうるっと来た。初参加だから今回の運営自体への思い入れはないのだけど、この回だけでも感激することが多かった。この完成度に達するまでどれだけの努力と熱意が投入されていたかと考えると。
隣の席が実はtdtdsさんでびびってたのだが、最初に立ち上がったのを見て、続く二人目のタイミングが大事！とすぱっと立ち上がってみてよかった。その後前列の人がみんな！立とうよ！みたいにやって一気に雪崩状態。
これで会議は閉幕したのだが、さらにherokuの緊急パーティーが開催され、思い切って行ってみた。まあ、懇親会に輪をかけたリア充な雰囲気でまともに話せなかったのだが、
こんな一日だった。熱かった・・・
RubyのSymbolと文字列の違いを研究室の輪講用に書いたのですが，折角なので公開したいと思います．
元々学部生に対する輪講用に書いた物なので，若干上から目線ですがご了承ください．
文字列とSymbolはよく似ています．プログラマから見ればどちらも文字列です．違いを一言で説明すると『プログラムが扱う』文字列か，『プログラマが見る』文字列かの違いです．例えば変数名は『文字列』ですが，rubyのオブジェクトである『文字列』ではないですよね？
例えば，今あなたがC言語でお絵描きライブラリを作っているとしましょう．その中に，色で塗りつぶすfillという関数があり，色を青・赤・緑の3色から選べ，fillの引数でそれを指定できるとしましょう．
fillの引数の設定方法として一番単純なのが，0を青，1を赤，2を緑として，0〜2で選択させる方法でしょう．しかし，それでは，どの数値が何色か覚えないといけないし，fill関数を知らない人から見れば，どういう意味の引数かすらさっぱり分かりません．
ではどうするかと言えば，普通はBLUE = 0, RED = 1, GREEN = 2と適当に定数を設定して，その定数を引数で指定させますよね．
こうして，fill関数の引数が意味の無い数値から意味のある文字列に変わったことによってプログラムが分かりやすい物となります．さて，ここで注意してほしいのは，ここで言う文字列はプログラムが扱うオブジェクトとしての文字列では無いということです．fill関数の引数として，"BLUE"，"RED"， "GREEN"などとC言語の文字列を渡すということは普通しませんよね．それは，ここで言う文字列は，あくまでプログラマがプログラムコードを分かりやすくするために必要な文字列であって，プログラムがオブジェクトとして扱う（例えば，長さを求めるとかする）文字列ではないからです．
分かってきたでしょうか？
プログラムコード上では（つまりプログラマから見れば）どちらも同じ文字列（文字の列という意味で）ですが，実際に動くプログラムから見れば単なる数値と本物の文字列という大きな違いです．結局，fill関数の引数の具体的な値は何でもいいわけです．プログラマから見て文字列であればそれだけでよく，プログラムが動くときの実際のその中身は何でもいいわけです．これのために存在するのが，Symbolであり，:fooとひとたびSymbolを作成すれば:fooの実態は適当な数値となります．（この数値がいくらかなんていうことはもちろん気にする必要はありません）
そして，もちろん同じプログラム上では:foo == :fooはちゃんと成り立ちます．もうここまでくれば，Hashのkeyとして文字列でなくSymbolを使う理由が分かりますね．Hashのkeyはあくまで，プログラマが見る（プログラムコードを分かりやすくするための）文字列であってプログラムが扱うオブジェクトとしての文字列では無くて，keyの実際の値は何でもいい，からですね．（特別な場合を除いて）Hashのkeyに対してrubyのStringのメソッドを使うなんてことは無いですよね．
しかし，他の軽量言語ではSymbolなどなくHashのkeyとして普通に文字列を使うことが多いです．では，なぜrubyだけSymbolを使うのでしょうか．
その答えは一言でいうと，rubyの（プログラムコード上に直接書かれた，つまりリテラルの）文字列は他の言語と違いimmutable(不変)でない，からです．実際，pythonやjavascriptの文字列(リテラル)は破壊的に変更することはできませんが，rubyの文字列は破壊的に変更することができます． （'abc'.concat('d')の様に）
これがどういう違いを生むかというと，コード上に直接現れる文字列がimmutable(不変)であるならば，実行時に一つだけそのオブジェクトを作成し，後はそれを使いまわすという最適化ができます．
そうした時，Hashのkeyの様なプログラマから見た文字列というのは，プログラムコード上のリテラルとして現れるわけですが，これらは実行時に一つだけオブジェクトが作成され（特にコード上に現れる同じ文字列は全て一つのオブジェクトにまとめると），それらの比較はそれらに対する参照（そしてこれは大抵メモリのアドレスなど単なる数値）の比較で済むので，結局Symbolと同じ様な働きをするわけです．
本当はプログラマが見るためだけの文字列だけど，それをオブジェクトとしての文字列としても，Symbolと同じ様な働き，パフォーマンスが得られるならば，別にオブジェクトとしての文字列であってもいいわけです．
繰り返しになりますが，プログラマが見るためだけの文字列は，その中身・実態は何でもいいわけですが，その実態がオブジェクトとしての文字列でも十分なパフォーマンスが得られるならば，別にオブジェクトとしての文字列でもいいわけです．
さて，rubyに話を戻しますと，rubyはコード上に現れる文字列であっても，実行時にそのコードを通る度に毎回新たな文字列オブジェクトを作成します．
（以下のプログラムを動かすことで確認できる．）
def foo 'foo'.object_id end p foo, foo
つまり，rubyでは文字列が可変であるため，先に述べたような最適化ができない（または難しい）ので毎回新たな文字列オブジェクトが作成されるのです．
こうなると，先ほどの話とはうってかわって，プログラマが見る文字列はその実態は何でもいいのに，それを文字列リテラル（rubyのオブジェクトとしての文字列）にしてしまうと，毎回毎回文字列オブジェクトが作成されてしまうという非常にばかばかしい状況になってしまいます．我々はそれらの文字列オブジェクトに文字列としての操作は一切施さないのにも関わらず，です．
こういうわけで，rubyではプログラマが見るためだけの文字列にSymbolというruby特有のものを使うのです．
もちろん，プログラマが見るためだけの文字列を全て定数として（そしてもちろん中身は適当な値で）定義しても構わないわけですが，Hashのkeyとかで数多くのプログラマが見るためだけの文字列が現れることを考えると，とてもじゃないですけどそんなことは面倒でやってられないですよね．ですので，実行時に自動で適当な値にしてくれるSymbolというものが存在するのです．
以上で，Symbolについての説明を終えます．以下は蛇足です．
最初の方で出てきたfill関数をrubyで実装しようとしたとき，青・赤・緑の各色はその実際の値はなんでもいいのでrubyのSymbolを使って:blue, :red, :greenとしてもいいのですが，ライブラリとかでは大抵ちゃんと定数として定義されていることが多いです．
これは恐らく，定数として明示的に定義することで値の存在を明示でき，ドキュメント化の際にも役立つことによっているのでしょう．
しかし，あくまでこれは外部に公開するようなライブラリでの話であって，自分が使うちょっとしたプログラムならこういう場面でも精力的にSymbolを使っていってもいいと思います．ちなみに，僕ならSymbolを使います．
Symbolだと定義もいりませんし，定数は大文字ですから打つのが面倒ですし，あまりソースに大文字が入ると見た目がすっきりしません（主観）．
Symbolは非常に便利なものですので，その意義・用途を十分に理解して，Hashのkeyにとどまらず様々な所で使えるようになりましょう．
証アナはTACの過去問集だけやってれば余裕で取れるｗただし証アナ協会にお布施(10万くらい？)しないといけないのがきついよね。
まぁでも実務経験に比べたら資格なんて関係ないと思うよ（弁護士と会計士は別）。証アナなんてうんこだって皆知ってるし。
ダメ元で色々履歴書出して地頭アピればいけなくもない気がする。リクルートはちょっと方向性が違う気がするｗ
なんにせよ地頭は俺よりずっと良さそうだからコンピュータは勉強しとくと何かと役に立つと思う。
文学部出身の異様に出来るプログラマーとかいるしな。金融系ならExcelVBAを極める必要があるけど、今ならC#と適当な動的言語(Pythonとか)やるといいかも。
わからんけどね。
カーネルコミッターでも、処理系実装者でも無さそうな人達が、「Cは滅びず！」と叫んでいる不思議な光景。
http://b.hatena.ne.jp/entry/shyouhei.tumblr.com/post/5545216280/c
http://b.hatena.ne.jp/entry/shyouhei.tumblr.com/post/5603961294/c
Linuxカーネル（せめてPOSIX互換品)を手前が思う言語にさっさと移植すれ。さすればCを滅ぼせん。（ちなみに高機能アセンブラの最適解がCとは俺も思っちゃいない。）
最後のＣの牙城、Linux（ＵＮＩＸ）をＪａｖａなり何なりベターな言語にさくっと移植してくれ。それともgoogleビッグブラザー様がクラウドでＵＮＩX鯖を駆逐してくれるのを祈ってればいいのか？
JavaもC#も，それにPerlもRubyもPythonも，実行環境自体はCで書かれている件。コンピューターが「シリコンを基材としたチューリングマシン」であるかぎり，アセンブラとCは滅びない。
はてな匿名ダイアリーを見て思った、最速でプログラミング言語を覚える為の10か条。
最初に覚える言語は、目的が明確でない場合はJavaかPythonを推奨する。言語仕様が簡潔で、資料が豊富で、応用範囲が比較的広い。