  |
はてなキーワード: Haskellとは
型論争の一部。
動的型陣営と静的型陣営がそれぞれ大規模開発に向いてるとか向いてないとか言うけど、「大規模開発」って何よ？って話。
自分としていくらかのパターンがおもいつくし、それぞれ質的に異なるからごっちゃにしても話が混乱するだけだ。
お前らの言う大規模開発ってどれだよ？あともちろんこれ以外にもあれば募集。
ITゼネコンみたいな連中が行う、何万人月というコストをかけて行う開発。失敗した特許庁の開発みたいなやつだ。典型的にはワンオフ品なので、かけたコストのわりに品質は低い。fizzbuzzも書けない人すら1人月と数えられるし、そういう人が生息するのはここである。2013年現在では多分Java（かたまにScalaなど）で開発される。末端の人には自分たちの担当領域外の仕様をどうこうする権利が基本的にはない。
OS（カーネルのみの狭義のOSではなくパッケージとしての広義のOS全体）とか、あるいはモダンなブラウザみたいな、膨大な機能セットをもち、様々な環境でロバストに動く必要がある開発。膨大な機能セットの中には、膨大な後方互換のための機能（例えばブラウザであればクソみたいなレガシーHTMLでもなんとなく見せてやるような機能）や、ありとあらゆるハードウェアや言語などの細かな実行環境の組み合わせで動作するための抽象化および各環境のための固有の機能を含む。オープンソース形態で開発されることもよくあり、2013年においては多分C/C++で開発される。自分たちで仕様をコントロールする権利があったりなかったりする。
1日のPVが億オーダー以上になるようなWebサービスなど。昨今だと1日にGバイト〜Tバイトにもなるデータを解析できるシステムもセットになってることが多い。サーバの1台や2台がハードウェア的な故障してもロバストに動き続けるための機能や、そのときのリカバリが容易であること、壊れた分や単なる新規追加ののサーバの補充が容易であること、みたいや機能および設計上の工夫が求められる。人的な大規模開発や量的な大規模開発と比べると比較的少人数（数人〜数百人。数千人になるのは数えるほど）で開発される。2013年においても様々な言語で開発されていて決定打はない。自分たちで仕様をある程度コントロールする権利がある。
例えばこの方が、Haskellは大規模開発に向いていると主張されているが、おそらく人的な大規模開発には向かない。これは2013年においてHaskellを使うユーザがそれほど多くないから、というのも大きな理由だがそれだけではない。Haskellは学習コストが低いことを目指して作られた言語ではないことも極めて本質的かつ決定的な理由の一つである。（自分の思う学習コストが低いことを目指して作られた言語とは例えばJavaとPHPだ。）fizzbuzzを書けない人をHaskellを書けるまでに教育するのは、どうしたらいいのだろう？
Haskellが量的な大規模開発に向いているかどうかは（自分の無知により）よく分からない。典型的には量的な大規模開発を実現するためには、そのソフトウェアがWindowsとか各種ブラウザ並に多くの計算機上で稼働することが必須だ。そうでないと膨大な開発コストがペイできない。オープンソース的に貢献を募るとしても、量的に巨大なソフトウェアに貢献する人を一定以上集めるには、それなりのユーザベース（単に使うだけの人も含めて）が必要である。Haskellの実行環境というのは全然枯れていないが、10年前のハードウェア＋OSを未だに使っている人の計算機上でもちゃんと動くのだろうか？HaskellってVMで動くんだっけ？ネイティブコードを吐くんだっけ？
ふえぇ・・・これの話ですよぅ
「変数に型がないということの利点について考える」
http://d.hatena.ne.jp/perlcodesample/20130227/1361928810
この記事の内容についてはですね、多くのなーどの皆さんが、「何言ってんだこいつ」の気持ちを抑えきれずにいたんですけどね。
特に話題が「型」なものですから、関数型もひかんの皆さんが我慢できずに、「ひゃっはー汚物は消毒だー」とばかりに集まって大騒ぎする事になってしまったわけです。(ほとんどTwitterから来たんじゃないですかね・・・)
そりゃぁ、ガタイのいいお兄様達が火炎放射器構えながら、端正込めて書いた記事を炎上させれば、主様の頭に血が登るのも当たり前の話ですか。
わざわざ、こんなブログを定期的に更新する主様の事ですから、きっとプログラムが好きなのでしょう。でもきっと、「プログラム」が好きという点については、もひかんさん達負けてません。負ける気がしません。だからもひかんさん達も、自分達の足りない脳みそ使って、勉強してるんです。
『「静的型付け言語」と「動的型付け言語」ではどっちのほうが良いんだろう。そもそも「静的型付け」「動的型付け」ってどういう事なんだろう、っていうか第一「型」って一体何ものなんだろう・・・？』
答えを求めて、勉強してるんです。
僕もそんなもひかんさんの一人です。低い知能で出せるだけのぱわーを出して、それなりの勉強をしてきてます。だから言うんですよ。
「お願いだから、間違った事を間違ったまま広めないで」って。
これはね、別に「間違っている」事を責めているのでは無いのです。そんなもの、記事の冒頭に「僕が間違ってましたふひひさーせんｗ」って一言付け加えたなら、皆納得するんです。
そうじゃなくて、明らかに間違った事を間違っていると指摘しているのに、「いや、僕は間違っていない」と言い続けている事に問題があるのです。
そうです、件の記事の内容は、残念ながら・・・誠に残念ながら、その多くが間違っているんです。
具体的な間違いの内容は、コメント欄や多のブログ記事で散々指摘されいるので、僕が今更蒸し返すのは野暮でしょう・・・ただ、困ったことに主様はそれが「実感」として得られないので、何が間違っているか解らないのでしょう。
解らない事は恥ずかしいことではありません。ツーステップ以上登った先にある事を実感するのはとっても労力がいるものです。僕だって今、圏論とHaskellのモナドの関係についての厳密な説明を求められたら、泣いて謝るしか無いのです。
では、主様が今、件の記事の指摘の内容を実感するためには、どうすれば良いのでしょう？僕からは、ふたつ、提案する事ができます。
ひとつは・・・僕が散々言っているように、「お勉強」しましょう。僕はHaskell大好きなので、型を学びたいのであれば迷わずこの言語を学ぶことをお勧めします。多分、実用に耐えうる言語の中では最も型がしっかりした言語じゃないかなって、思うんです。
そしてね、お伝えしておきたいのはこの言語、ParlやRuby使いさんがビックリするくらい柔軟で簡潔なんですよ。静的型付け言語は無駄が多いなんて、とんでもない事です。
うーん、僕は、OCaml良くわからないですが、Scalaは直積型を再現するのが面倒な印象ありますです・・・
もう一つは・・・言語は何でも良いです、何か静的型付け言語を使って、それなりに大規模なものを・・・できれば二人以上で実装してみてください。それが終わったら、もし動的型付け言語で同じ事をしたらどうなっていたか、想像して見てください。きっと主様は、件の記事を上げたことを、後悔する事でしょう。
「型」ナメんなヴォケが(# ﾟДﾟ)
って事なんです。
プログラミングの型は、プログラマが間違いを犯さないために、プログラミング言語がわざわざ用意してくれているものです。そしてその基礎になっている理論は、コンピュータが真空管だった時代から、今にかけて、ずーっと研究され続けているテーマなんです。だから安易に「型がないことによって、たくさんの面倒から解放されるからです。」なんて、すっとぼけた話が通用するほど簡単な世界じゃないのです。
型は、主様が考えているよりも、もっと強力で、もっと柔軟で、僕や、主様や、なんとなくこの日記を除いた誰かさんのプログラミングを大いに手助けしてくれる凄いものなんです。それが動的型付けの言語だって、型の考え方は実装の指針を示してくれます。どうです？もっと型の事を知りたくなって来ませんか？
最後に、「本物のプログラマはHaskellを使う」から、いくつか引用して終わります。ばーいばい。
http://itpro.nikkeibp.co.jp/article/COLUMN/20080108/290605/?ST=develop&P=1
型がテスト自動化の道具であるという概念は、最初は理解しにくいかもしれません。しかし、Haskellのような強い静的型付けの言語に慣れるにつれて、こうした考え方を自然なものととらえられるようになります。
型のわずらわしさを克服し、型での静的なテストに慣れて型検査のメリットを実感するにつれて、「型を考えること自体がプログラミングである」と理解し、「型によってバグを防ぐためのテスト・コード」を当たり前のように書けるようになります。こうした感覚を身に付ければ、一人前のHaskellerになったと言えるでしょう。
どっち？
SIでは09:00から23:00まで毎日働く程度に社畜してきたけど、最近楽できるポジショニングを覚えて定時退社したり仕事してると見せかけ違うことしてたりする。
最近は仕事していると見せかけて全然関係ないFuelPHPとか触っていたしな。
おかげでAuthとかPaginationとかViewのFormクラスとか覚えた。FuelPHP簡単で良いな…！
（でもHaskellとか今まで理解のない難しい概念とかは仕事をサボりながら、ではいまいち理解できない…）
RedisとかMongoDBとかも触りはしているけど活かし方が分からない。
MySQLが一番いいよおおおおおおお。
仕事をサボる。それって良くないだろ…とは思うけどまだ仕事を楽し始めて1,2ヶ月目。
仕事やりたがっている人に仕事させるのがいんじゃね、とか思ってしまう。
なんか聞きに来るしな、これでいいですかとか、ここどうしたら良いですか、とか。その質問に答えて手を動かすのはその人にやってもらおう。
この前とか「言ってくれたらなんでもやりますよ！」とかいう子分気質の人とかいたしな。
だがしかし「何を言うのか」を考えるのが面倒くさいんじゃ、何をやればいいのかまで考えてくれ…と思ったので「まじっすか！あざす！何かあったときはお願いします。」とか言って終った。
暗に自分で考えてもらうように言ったり、今まで自分がしてきた人との調整が必要な作業とかもなるべくお願いするようにして楽できるように頑張った。
あっちも言われたとおりにやれば進捗（自分の実績）が上がるし、美味しいとか思っていたんだろう。甘い甘い！もっと自分でやれ。
せめて「自分はこう思うがこれではいけないですか？もしくはこうすべきですか？」ぐらいの「自分の期待値」と「期待値とのズレ」を持って質問しに来て欲しい。
だがしかし、オレは仕事がしたくないし、作業を持ちたくないんだ…！（クズ）
適度にそういう質問が来るのは、仕事をしてるっぽい、忙しっぽいと思われるための重要な要素の１つではあったりするから、丁寧に対応するけどなッ！
プログラム覚えられて社畜出来るなら、23時ぐらいまで土日休めるならなら全然余裕だと思っているけど、1時とかまでやらされたらさすがに…／(^o^)＼
WebはWebでも、上場していてあるてーどでかいところなので大丈夫なんじゃないかなぁ、とは思っているが…！
まぁ一応、職場の環境が良くて仕事が面白いなら、逆に帰る意味って？って感じだけど。具体的にはPCとイスと作業環境。適度に人がいない感じ。人と目線があまりぶつからない作業スペース。ディスプレイとPCを上手く使って作り出すパーティション。
ポテンシャル層を採用したいってお前ら…実は楽したいんだろ！とか思うけど、実際僕とか実績/実力無いのであなた達の世界に入れるだけでも幸せでございます、その層で働かせてください、なんとか追いつきます。という感じですが。。。
「あまり同じ環境にいすぎるのは良くない。楽をしたがるくせがついてしまう」
ととある人が言っていたのですが、まさにその通り！
The・今いかに楽をするかにフォーカスをあてて仕事してる！！！
作業をお願いされて、明らか揉めそうな案件なら断る方法を真っ先に考える／(^o^)＼
これはいかん。
今までは意味不明に個人受注の副業も持っていたので、仕事中にその事考えたりコーディングしたりしていたからサボり時間を有効活用できたが、今やそういうのやめたのでサボり時間はあまり活かせない！というのも、インターネットを見続けるのはさすがにサボっているっぽいが、ターミナルでカタカタやっているのは仕事しているっぽく見える。そういう意味でサーバーサイドのコーディングはサボりつつもサボりをフェイクして出来た。
それを考えると、いいタイミングでWeb屋へのコンバートが決まった。
やりたいことと仕事がマッチング出来れば、もうヤバイじゃないっすか。
隠れてコソコソする必要ないっすよ。
もっともっと技術を好きにならないとヤバイ気がするんですが、頑張ろうと思います。
まだコーディングは飽きてないですが、いつか飽きて「これは楽する対象の事項だ」と脳が判断した時、何をするんだろ…。
いずれにしても若いうちからこんなあぐらかいていたらヤバイと思うので、Webのステージで頑張ってきます。
怠け癖が付く前に…。
そしてこんな怠けているのがバレるとヤバイと思うので…。
■ C
for( const char *s="12345"; *s; ++s ) if( '2'<*s&&*s<'5' ) printf( "%d", (*s-'0')*2 );
console.log([1,2,3,4,5].filter(function (i){ return (i > 2 && i < 5 ); }).map(function(i){ return 2 * i; }));
■ Python
print(map(lambda x: x*2, filter(lambda x: x>2 and x<5, [1,2,3,4,5])))
■ Ruby
puts [1,2,3,4,5].select{|i| i > 2 and i < 5}.map{|i| i*2}
■ C#
new{}{ 1,2,3,4,5 }.Where(x => 2 < x && x < 5).Select(x => x*2);
(print (loop for x in '(1 2 3 4 5) if (< 2 x 5) collect (* x 2)))
■ Haskell
print [x*2| x <-[1,2,3,4,5], x > 2, x < 5]
■ J
■ R
print((function(){x<-c(1,2,3,4,5);x[2<x&x<5]*2})())</p>
■ Clojure
(print (for [x [1,2,3,4,5] :when (< 2 x 5)] (* x 2)))
(1 to: 5) select: [:x | x between: 3 and: 4] thenCollect: [:x | x * 2]
http://d.hatena.ne.jp/yamasawa8911/20120519/1337407233
だそうなので、俺が思うところを書いておきます。
基本的にMacのほうが羨ましいとは思うけれども(まあ、MacBookとかが欲しいんだよね、きっと）、でもきっとMacなんてフルスペックで使えるわけない。
周りの子に自慢したいとかいうのであるならば、あるいはどうしてもiOSアプリが作りたいというんだったら、それしか選択肢がないけれども、そうじゃないんだったら辞めましょう。
あとWindowsも、Windowsアプリとか、C#をいじりたいんです！っていう話であるならば、それに固辞するのも結構ですけど、そうじゃなくて、ITに行きたいなら、Windowsを捨ててLinuxにしましょう。
自分はGentooが好きですけど、ハードコアすぎるので、Ubuntuのほうがいいかと思う。
Linuxとか難しいんじゃないの……とか思うかもしれないですけど、Ubuntuは素晴らしいです。
Ubuntuは、知り合いの絵師のパソコンに入れたら、わりと好評でちゃんと使っていたので、それなりにパソコンが使えるならば、ちゃんと使えます。
プログラミング言語関係は、そのOSに依存するような環境を使いたいというわけではないのなら、Linuxにしておいたほうが、無難に使えます。
CとJavaでもいいとは思うんだけど、どちらもコンパイルが必要だし、コードを書くのに、ある程度の量(書きたいときに気軽に書くという感じではない、という意味）が必要なので、もう一つ言語を覚えた方がいいです。
PHP、Ruby、Python、Perl、Clojure、Haskell、お好きな言語をどうぞ。
ただ、PHPはどちらかといえばWebアプリケーションよりかな？という気がするので、PerlかRubyかPythonがいいかとは思いますが、お好みで。
自分はPythonのほうが好きですけど、Rubyのほうが割と見つけてもらえる確率は高いかもしれません。
あと、パブリックマンも「Railsでいこう！」というブログ名だったので、尊敬する人にあわせるならRubyのほうがいいんじゃないかと。
こわいおじさんににらまれたいならPerlのほうがいいでしょう。
ちなみに、Ruby on Railsは、割とWebサービスを作るのが楽になります。Herokuとかありますしね。Webアプリケーション周りということだったら、ついでにそのプログラミング言語で使われているメジャーなフレームワークとか調べながら勉強するといいかもしれません。
で、上記を踏まえて、エディタをちゃんと使いましょう。
パワーが有り余っているなら、総合開発環境であるところのEclipseでもいいんだろうとは思うんですけど、それはおっくう、というのならば、ちゃんとエディタの使い方を覚えましょう。
もう既にUbuntuを入れていると思うので、EmacsかVimを使いましょう。Vimのほうが好きではあるんですけど、キーバインドや、その他の癖を考えるとEmacsのほうがいいかなあという気がします。
Ubuntuを入れたなら、Geditというエディタも、Windowsのメモ帳の非じゃないくらい極まったエディタなので、それでもいいです。Windowsがそんなに好きなら、サクラエディタを使うといいでしょう。
あなたはどうやら貧乏だけれども、インターネットは使えているようなので、英語を読む練習をするといいです。
英語なんて全くわからない？ノープロブレム。そんなの適当でいいです。「なんとなくこういう意味かなー」とか、あるいは英語を読むだけでクラクラしない程度でいいと思います。
英語を読めると便利です。少しだけ多くの解説が読めるからです。
あと、英語が読めると「pdf Orailly」という魔法の言葉が使えたりするんですけど、何に使うかは想像におまかせします。
で、上記を踏まえてなんですが、コードを書きましょう。
コードなんて書いてなんぼです。「如何に優秀なハッカーになるべきか」という記事はゴロゴロありますが、そんなのは気休めに読むべきで、まずはコードを書きましょう。
なんだかんだいって、コードを書くのは経験がモノをいいます。量を書きましょう。そして躓きましょう。最初から質なんて無理です。
躓いたら、なんで躓くのか考えましょう。また、「こんなところが、コードを書く点で不満だなあ」と思うことがあれば、それも考えていきましょう。
偉い人がいろんなソリューションを考えてくれています。最初からそのソリューションがなぜ素晴らしいかなんて理解できないとは思います。躓いて始めて「ああ、だからこういう開発手法がいるんだ」ということを理解できるでしょう。
ついでに、コードで躓いたら、その躓いたところを、Twitterアカウントに積極的に発信していきましょう。
そのついでに、そのプログラミング言語を学んでいるTwitterアカウントをフォローしましょう。
あなたの呟いていることによっては、その人は興味を持ってくれるでしょうし、場合によっては手助けをしてくれるかもしれません。
あなたがサービスを立ち上げたら、積極的にRTをしてくれるかもしれません。
だいたいなれてきたところで、自分が作りたいものを作ってみましょう。そして公開してみましょう。できるならGithubで。
Githubに載せる理由は、ソースコードを公開したほうが、突っ込まれる率が高くなり、それに応じて勉強になるというところと、あとはGitというバージョン管理システムの勉強をしていたほうが、のちのちに便利だからです。SVNとかありますが。
あと、コードの引き写しに関しては、ブログに書くか、あるいはコードの断片を載せるという意味で、Gistに載せるという点もありますが、その辺りはご自由に。
VPSを借りてみましょう。あなたが貧乏だというのはわかっています。VPSとは、仮想専用サーバーのことです。
別に最初っから何でも揃ってるようなホスティングサービスでもいいんですが、サーバーを一から立てるという作業は、勉強にもなります。下手な技術書より余程勉強になったりします。
最初から借りると宝の持ち腐れとなると思うので、一つのWebサービスでもいいので、それを自分のマシン内でのみ見られるようなったら、借りるというのは一つの手だと思います。
VPSがつらいというのならば、Herokuとかもありかもしれないです。
コードを書くのが辛いなら、コードを読みましょう。人のコードはアイデアの山です。
自分の場合は、割と実例が無いと、挙動がピンとこなかったりするので、コードを読むことのほうが多いです。
特に、その言語で有名なライブラリとかいいかもしれません。ガンガン読みましょう。
あとは若さでなんとかなるでしょう。
ついでに、この文章を「テメーはなんにもわかってねえんじゃボケ」という言い方をして修正してくれる人もいると思うので、そういう人のアドバイスも真摯に受けとりましょう。
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 流と想像。
これを読みづらいと感じるのは、左から右に流れる
もしかしてアラビア語ネイティブな人からすると逆に読みやすいのか？
第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 練習問題
２ｃｈでは私がぼろくそ言われた( スレのＵＲＬ探しに行ったら、２ｃｈ書き込み情報があり、性格はそれなりにそれなりらしい事がわかった )
http://hibari.2ch.net/test/read.cgi/tech/1317639700/365-
つるんでるは、その方が見る人が多くなるかと思って書いたので、一緒にブクマしてたりとか、リツイートされたりとか、はてなブックマークのお気に入られに、ドワンゴ社員でギークハウス在住の奴が入ってたりとか
まあ、こんなところか
365 ：デフォルトの名無しさん：2011/10/28(金) 15:54:08.91
まつもとゆきひろさんの連絡先知ってる人いませんか？
あなたは化け物を作った と言いたい
こんなに素晴らしい人権意識をお持ちのsora_hさんは、最年少ruby開発者だった。。。orz
光り輝く id:kabiy さんを応援してあげて id:kabiyさんは、新しいおもちゃが手に入って大変お喜びのようです。
そして、私を応援してくれる大変素晴らしい方です。 ギークハウス万歳 応援していただいたので、私も応援のお返しのエールを送りたいと思います。
光り輝くkabiyさんに、shine
366 ：デフォルトの名無しさん：2011/10/28(金) 16:00:01.19
これは人災じゃないんでしょうか？この人は地震の震災の時の何かの１００人ボランティアを使う開発に関わったそうですが
支援や協力をお願いしている部分は関知せず、こちらからしたら嫌がらせにも取れるようなツイートだけして、開き直ってきた
ネットだし事実確認が、ネットを見ただけでは判断できないから、躊躇する人というのもいるかもしれないし
関わりたくないと思う人もいるだろう。みんなそれぞれの事情や都合で生きているのだから
だからと言って、ないがしろにしたり、からかって良いわけはないと思う。
こんなかかわり方は無い
367 ：デフォルトの名無しさん：2011/10/28(金) 16:08:25.51
はてなブックマークというもので、わざわざ私のツイートに対し、「warota」と言っています。
ゲームのデバッグのバイトの例を出したから、ruby開発者の自分に何を言っているんだ という笑いだったのかと思いますが
技術の事ではなく、コミュニケーションの取り方というか、それ以前のような気がしますが、
そのような傲慢すぎる関わり方を言っていました。
こんな人 いくら技術力が能力があっても、人間として破綻してないですか？
こういうのは、匿名でしかものが言えない未来がないような人が、する事かと思ってました。
実名で前途有望なはずの人がする事でしょうか？
本当に２ｃｈねららしい目撃情報も
376 ：uy：2011/10/28(金) 18:00:01.89
可愛そうに ああ可愛そうに ひたすら可愛そうに
そいつは悪くないよｗ 中学生なんてそんなもんだし、何言うかわからないのが中二病、人それぞれ発病の仕方が違うだけ
むしろ中学生程度を天才だ！ っとかいって祭り上げた大人が悪い
そろそろ気づき始めるんだろ
「あれ？自分って天才って言われるほどすごくなくね？あいつのほうがすごくね･･･？うわあああああああああああああ！！！！！！！！！！！！！！！！！１」こうなる。
995 : uy : 2011/10/03(月) 18:35:47.45
初修正報告…ども…
俺みたいな中3でRuby開発に参加してる腐れ野郎、他に、いますかっていねーか、はは
Groovyかっこいい とか Haskell総合IDEほしい とか
かたや俺はRubyコミッター、メーリングリストでBUG報告を見て、呟くんすわ
it'a true Bug．再現率低い？それ、もう仕様でいいんじゃね。
なんつってる間に10時っすよ(笑) あ～あ、義務教育の辛いとこね、これ
377 ：デフォルトの名無しさん：2011/10/28(金) 19:47:25.39
uyにだけは言われたくないだろうな
でも、増田は技術系の人が多いから、rubyはrubyってかんじなのかな。日本人が作った軽いプログラム言語？ ってことくらいしかしらないけど、私だって名前を知ってるくらいに有名なものに、中学生で携わってるのに、名にこの人格の歪み・・・
今のうちなら治るかもしれないのに
プログラミングは静的言語(C/C++,Java,C#など)と動的言語(rubyとかpythonとかperlとかいわゆるスクリプト言語)と関数型(lispとかF#とかhaskellとか)を一つずつくらい眺めた方がいいと思う。
どれか一個くらい自分に合ってるのが見つかるかも。
やりたいことにどの実装系が一番適しているかを考えるべきで、実装系を目的に合わせるべきじゃない。
そういう考えでいると、PHPで何でもやる奴とか出てきて迷惑なんだ。
そもそものロジック構築などは、ターゲットには依存しても、言語にはほとんど依存しない。
馴染むための登竜門って意味で言えば、VisualStudioなどのGUIでデバッグが出来る環境をもった言語が良いし、VB,C#などのサンプルが豊富で結果を確認しやすい言語が良いと思う。
色々教えてください偉い人。
自分で考えろってのはご尤もですが、色々な方の意見が聞いてみたいのです。
・Struts（ver2じゃないほう）上でのJava（max2000行程度）
・perl（max7000行程度）
・c/c++（ちょっと）
・Haskell（ほんの少し）
・VisualBasic（.NETじゃないほう）（ほとんど忘れた）
・HTML/CSS（セマンティック厨）（HTML5は勉強中）（バイトでWEBデザイン経験有）
・javascript（簡単なものなら）
・MovableType（CMSとして利用。ちょっとした企業サイトレベルくらいのものの構築。簡単なプラグインの作成とかも）
・Apache（セットアップと最低限の設定くらい）
・Tomcat（同上）
・Linux（CentOSとUbuntu。セットアップとちょっとした設定程度）
・AdobeのDTP系製品（CS2）（雑誌編集経験有、ただし学生レベル）
・Oracle（10g）（Bronzeレベルの知識とちょっと触ったことがある程度の経験）
・postgreSQL（ちょっと触ったことがある程度）
・会計関連の知識（日商簿記2級）（大学で管理会計をかじった）
・数学系の知識（論理とか集合やらの基礎。大学で計算機科学をかじった）
・印刷物/WEBサイトのデザイン（独学だけどそれなりに。一般人よりはそれっぽいデザインが作れるかと）
C# は趣味というか私生活で必用な時にしか使ってないです。他の方の意見を聞いたほうがいいと思う。趣味でやってる感想としては、まず過去のどろどろがないのがいい。標準ライブラリだけで殆ど足りちゃうのも初心者にありがたい。あたらめて考えてみると初心者に対する敷居は低いなあ。
作りたいものが明確なら結果への近道になる言語なのは確かなんですけど、プログラミングで何をしたらいいかわからないからプログラミング言語を知りたいという段階の人には薦めにくいかなあ。前記事で Python 薦めたのは元増田さんがそういう段階だからです。
関数型言語も趣味レベルでしかやってないです。関数型言語とは違うけど SQL は仕事で毎日使ってる。むかーし Haskell ぶんなげて、SQL 使ってたらなんかひらめきがきて、それから結構わかるようになった。（ようなきがする）関数型言語って独特の脳汁でるんだよね・・・難しい SQL 弄ってるときも同じ脳汁が出る。関数型っぽい脳みその使い方は他の関数型じゃない言語でもできるし気持ちいい。関数型言語自体は触った時間短いけど、ああいう脳みその使い方はすごく武器になると思います。
基礎体力を養う意味ではここら辺がいいと思うんですがどうでしょう。
これがわかるとCLRやJVMのインフラ部分もわかりますし、組み込み方面にも強くなります。
C++はマルチパラダイム言語であり、これをひとつやれば構造化プログラミングとオブジェクト指向プログラミングの両方がわかります。
C++はCのほぼ上位互換言語ですので（正しくはC99が制定されるまでは）、プレーンなCしかやらない理由はありません。
嫌なとこも多くある言語で（どうしてEffective C++シリーズやExceptional C++シリーズみたいな書籍が多くでてるか考えるといいよ）、メモリ管理も手動ですが（これは半分嘘。RAIIがあるから半分自動。GCがないから半分手動）、逆に細かいとこに気を配る態度を養うには最適です。
Erlangで並列プログラミングをやるのもいいかもしれません。
Common LispかSchemeで怪しい（でも美しい）世界を爆走するのもいいかもしれません。
これだけやっとけばC#やJava、軽量言語の類はあっさりと料理できるでしょう。
あくまでもプログラミング言語についてはですからね。
圏論を何に使いたいの？
Haskell向けだったら
http://www.haskell.org/haskellwiki/Category_theory
あたりをじっくり読めばいいと思う
Rubyは、純粋オブジェクト指向と評されるHaskellの直系と遇されるのが常だが、私の見解は、むしろマクロアセンブラにより近い、というものなのだ。Rubyにおいて継続すなわちcontinuationの使用はもはや常態とも言えるが、一方のSchemeでは、Algol的な例外機構の残滓により、Unixシグナルに留まっている。
制御構造のみならず、データ構造の観点からも、RubyはSchemeよりはるかにポストモダンと言えるだろう。淵源へと遡れば、マクロアセンブラとPascalの対立の図式へと導かれる。私は、Schemeのデータ構造は、唾棄すべき要因を含むという思いを抱く誘惑に抗いかねるのだ。そうであるならば、民主党の政権交代は失敗であったと結論せざるを得ない。
もとより、アインシュタインの相対性理論からも、明らかにRubyに軍配が上がるだろう。SchemeをSchemeたらしめているブロックスコープ構造にしろ、今となっては決して珍しいものとは言えない。いやむしろ、真に純粋関数型を指向するなら、Schemeへの共用体の導入をこそ今真摯に検討すべきなのだ。演算子オーバーロードですべての問題が解決するわけではない。この実存的な課題をただ黙殺しているSchemeに、私は異議を申し立てる。
