  |
はてなキーワード: Pythonとは
swiftをJavascriptとかLLみたいに言ってる人沢山いたけど、あれって変数宣言がvarだとか、見た目がスッキリしてるとかそういう印象だけで言ってるんだよね。
以前、C#に型推論が導入されたときも(っていうか今でも)動的型やバリアント型と区別がつかなくて「使うな」「バグの元」みたいに言ってる人よくいたし。
あと、C++, Perl, Java, C#, Javascriptあたりをまとめて「C系の言語」と言ってPythonやらRubyみたいな言語と比較する文脈で「似てるから」おぼえやすいとかいう人とか。
VB6をやっていてVB.NETなら移行しやすいと思っていて「ぜんぜん違う言語だよ」って言われて驚く人とか。
共通のキーワードを使ってるとかぱっと見た目が似てたら、同じような言語と思ってしまう層がけっこうな量で存在するみたいで、そういう人たちも一応コードを書けてるんだよね。
今年に入ってからプログラミングを勉強し始めて、php、javascript、pythonでとりあえず動くものを作れるようになった。各言語のメジャーなwebフレームワークも使えるようになったし、過去の株価ダウンロードしてmysqlに突っ込んでta-libでシストレのバックテストして遊んだり、ニコ動のタグ検索結果のクローラー作って新着があればメールで知らせてくれたりするの作ったり、websocketためしてみたりbackbonejsで遊んだりもしてる。ニートだから時間が無限なのもあるけど、5か月弱でずいぶんできることが増えてきたなと思う。そろそろ何か作って公開してアフィで稼ぎたいなと思い始めた。でも何も出てこない。今月入ってからずっと考えてるのに作りたいものが浮かばない。いくら勉強してもアイデアがなければ無意味なんだと気付いた。誰かアイデアちょうだい
３行で
そうだったのか。。。。落ち込みんぐwwww
Webに憧れたのは小学生の時だった。YahooKids!を開くとでてくるポンタの冒険に夢中だった。
ここにはないデータを手にして、ゲームができてしまう。インターネットすごい！！僕も作りたいとおもった。
中学になって、引きこもりぎみだった僕は自宅にあったパソコンの本を読みあさった。HTMLなるものを使えばインターネットがつくれることを知った。
必死になって意味を理解しようとした。headないにJavaScriptをかいて、bodyには本文をかいて。拡張子の存在を初めてしった。ファイル名+αの文字がなければ画像を
インターネットに乗せれないことを知った。色々な色を使ってデザインして、くそだなーと思いながらHTMLを書きまくった。
PerlやRubyにも手をだした。図書館で本を借りて理解を深めた。頼る人なんていないのですべて独学だった。
高校入学まえにHatenaをしった。higeponやnaoya、amachang、Hamachiya2にあこがれた。
Plagger芸を真似してぴざの配達でわらったり、ニュースさいとの転送してみたり。
RSSリーダーが流行ったのはどっちが先だったっけ？自分でRSSリーダーつくったりもしたなー。
ニュースサイトをまとめるWebServiceつくったりもしたっけ。
ApacheのカスタマイズとかLinuxKernelを理解しようとしてたWebな人達の向上心にひかれた。
higeponが未踏にとおったときに、学歴をしって、情報系の学部にいくのはやめた。
理学系の学部でSICPよんでみたり、データベースいじってみたり。好きにうごいた。そのころはWeb技術に関心はなかった。
学部4年になってから研究室のHP管理をしたので、そのあたりからWebの情報を取入れはじめた。
JS系のフレームワーク、AngularJSやらBackbone。すげーJSの見通しがたちやすくなっててエレクトした。
サーバー側も、RailsだけでなくFuelPHP、Laravel4、Sinatra、PythonのWebApp2とか。
Herokuを使って感動した。nodeなんてものがでてて椅子からひっくりかえった。
おもしろすぎて使いまくった。
ハッカソンにも参加してみた。僕の様なよばなれした人が出る場でないのはわかっていた。
作れない人達にかわって瞬時に作った。意見をその場その場で聞いて、作るべきものをはあくした。
楽々アイディアを形にしていった。他の学生と比べても僕の方が早く正確にかけた。
かなわないか、同じ程度だとおもったのはMSPの学生くらい。
だれよりも技術が好きで情報を取り入れてアイディアを形にした。
もちろんメールと一期一句同じではなく、僕の解釈した言葉ではある。
Webのプログラマになろうとしたじてんで一生技術を学び続ける覚悟はした。
それに沿って行動もした。実際にサービス作ってOutputもしてる。
僕よりも技術に欲ある人がいるということでもある。みたことない。
いままでハッカソンで会ってきた学生はC言語みたいなJSかくやつしかいないし。
生JSからAngularJSに移行したら僕の前から消えたようなやつらだ。
僕以上のスピードと正確さでサービスのリリースに尽力して、技術をもとめてるやつがいるのか。
面接で、クラウドとか、ビックデータとかPじゃなくてNやらHな言語を勉強してるとか言えばよかったのかな。
八つ当りにGithubのBackboneのプラグインにプルリクしといた。
今日はいくつかリポジトリみつけて気晴らしにプログラムをかこうと思う。
最後まで読んだひとはわかるとおもうけど、僕は人に通じる言葉が苦手です。
付き合ってくれて有難う。僕は地方で働きます。さよならWeb。
ぼくにはピンポンのアクマみたいな、 「おまえ誰よりWeb好きじゃんよ！！」といってくれる友達はいない。
それとも僕が無能(アクマ)だったのか。
「何が」と簡単には断定出来ないが、元増田には色々と不足していたところがあるからこういう結果になってるんだろうと思うよ。
転職エージェント経由での書類選考とか、落ちる方が難しいわけで……。
その書類選考でこれだけ大量にお祈りされているということは、よっぽどエージェントの腕が悪いか
元増田の経歴が信じられないくらいしょぼいかのどちらかであろう。
指標として自分のスペックを書く、転職回数などで元増田と共通項があるので
ある程度参考になるかも知れない。
・転職4回
・社会人8年目
・Java、PHP、Python、Javascript、Objective-C
・ブログは少し書いている
・Linkedin や Facebook、公開しているメールアドレスにたまに企業から直接アプローチあり
上記のようなスペックで、グリーとかコロプラ、DMM.com ラボ辺りからは内定が簡単にでた。
もし、元増田がこれ以上の経歴で落ちまくってるなら人格に問題があるのかも知れない
そうでなければ、大手の方が決まった時のバックが大きいので、数打ちゃ当たるの運勝負で色々受けさせられている可哀想な人っぽいので
大手ばかり狙うのはやめた方が良いかもしれない。
Windows8を別のパソコンにインストして、Media Center Packを適用しようとするじゃない？
正規品だっての。
サポートに聞いたら、Media Center Packは元のパソコンでしか使えないんだって。
じゃあパソコン変えるたびに800円払うのかって聞いたら、そうです、だと。
しねよ。
分かったよ。Media Center Packは使わないから、認証済みの状態に戻してよ、つったら、
Media Center Packだけをアンインストールすることはデキマセン。
は？
しねよ。
再インストールするじゃない？
8→8.1→8.1Update
...Windows Updateで1日がかりだよ。
これの初回実行がとにかく遅いんだよ。
プログレバーもないし、実際にどんなメンテやってるのかの表示もねえ。
あほか。
（追記）タスクスケジューラーでDiskFootPrintを削除したら直った
エクスプローラーの詳細表示で複数ファイルをマウスで選択しようとするじゃない？
ユーザー追加しようとするでしょ？
そしたらメトロに飛ぶんだよ。
コンパネ内で完結させとけ、ぼけ。
アプリケーション一覧画面からでは起動できんのよ、Pythonシェルが。
どうやって起動すんのよ。
アプリケーションランチャーの極致にあったスタートメニューを廃止してこのザマか、しね。
タブレットではそこそこ使える。
それは認める。
デスクトップでも設定を練ればわりと使える。
それは認める、、、わけないやろ、
あほか。
めんどいわ。
ただひたすらに、むかつくOS。
それがWindows8。
スクリプト言語系の人がよく挙げるJavaの良さで「スタイルを強制できる」っていうのがありますよね。だから大人数・大規模開発に向いてるって。
口の悪い人は「奴隷用言語」とかいいますけど、悪くない人もまあ遠まわしにそう言ってるわけです。
でも、実際の人海戦術的に質は問わないでとにかく人数を投入するような現場で行われてるコードのスタイルを統一する手法って、まず少数の「できる人」が一画面分とかのコードを書いて、残りの人がそれをコピペして改変してコードを書くって方法で、オブジェクト指向であるとか静的型の言語であるとか、そういうJavaの特性とはまったく関係ないところで行われてます。
Rubyだろうが、Pythonだろうが言語を問わないで実行できる手法です。
ちょっと考えたらわかりますよね。静的型だからとかフレームワークを使うからとか、そんなことでスタイルを統一できるわけないって。
その昔 C.vs.Pascal の論争でも、Pascalは教育用に作られて採点用が楽になるように誰が書いても同じようなコードになるように作られてるって珍説がありましたけど、JavaにしろPascalにしろ、その言語を使っただけで誰が書いてもおなじようなコードになるような言語が存在したら、いまごろその言語が世の中を席巻してますって。
プログラミングにそれほど見識がなくても「Javaはスタイルを強制できる」っていうのは間違いだって分かりそうなのに、それなりに技術力のありそうな人がこんな意見を言ってしまうのって、Javaが生産性が高いって部分は認めたくないけど全否定すると大人げないから「大規模開発に向いてる」ってくらいは言っておこう、遠まわしに奴隷用って言ってるだけだし、みたいな心理なんじゃないかって思ってます。
今日から新卒研修の技術研修が始まりました。初日はJava(JDK)をMacにインストールして、簡単なプログラムを書くことから始めます。
さて、なんでJavaなのかと感じるかもしれません。Webに限らずスマートフォンのマルチプラットフォーム開発にもJavaScriptが浸透し、RubyやPythonは学生の間で人気があります。
逆説的ですが個人的には、Javaを研修に選びながらも「Javaを覚えてほしいわけじゃないだよね」って思っています。
習得して欲しいのはJavaそのものではなく、どこまで言語の深いところまで掘り下げたのか。つまり「深さを探った経験」を得てほしいからです。
Javaが新卒研修に適しているのは、適度な深さと広がりがあるから。それも、C++ほど底が途方もなく見えない感じもなく、Rubyのようにあs（以下略）
この「言語を深く探った経験」は、まとまった時間がないとなかなか掘り下げられなかったりします。配属されて仕事や成果を求められるようになると経験しづらい。興味本位でアプリを作ることに没頭する学生時代にも経験しづらい。教授に多くのタスクをふられがちな院生時代にも経験しづらかったりします。
プログラミング言語を、深いところまで掘り下げる機会は、新卒研修の時期に適していると僕は思います。成果や責務に追われずに、プログラミング言語に没頭することが許されているからです。
深く掘り下げた結果、何が見えてくるか
Javaのもうひとつの側面は、個性があらわれやすい言語だと僕は感じます。きれいに書けば人間性が感じられるほど美しく書けます。逆に雑に書けば、プログラマとしての伸びしろが良い感じに見えるくらい、未熟に書けます。
Javaが新卒研修に適しているのは、適度に思考の深みを表現できるから。それも、C++ほど哲学的に難解になることもなく、Rubyのようにとr（以下略）
ここは賛否両論ありますが、いずれにせよJavaで何ができるのかではなく、Javaを通してその人の可能性の何が見えるのかが大事になります。アプリを開発する新卒側と、人材を開発する人事側の、視点の違いもありましょうが。
だからこそ、Javaというプログラミング言語を通して、深く掘り下げる機会を大切にしてほしいと思います。それから、Javaを通して何を表現できるのか。プログラム設計という点から、いろいろチャレンジしてほしいなって思います。
そうすれば、掘り下げた分だけ他の言語も、もっと深く短時間で掘り下げられるでしょう。
そうして、自分の思想や仕事に対する人間性を、プログラミングで伝えられるようになったら、きっと一人前のプログラマになるでしょうね。
ゆーすけべーさんが以前に作ってたimeeroみたいな感じです。画像Blogをスクレイピングしてエロ画像を効率的に見るサイトです。
なお、先程解約手続きを済ませたので4月末くらいに見れなくなります。エロサイト自体にあまり興味がなく、ローンチしたらやる気が無くなったのです。
テスト駆動開発がやりたく、DSLに強いロック魂を感じたRSpec。
はやりに乗ってBootstrap。
特にCapistranoは名前がキュートでやっていることがカッコイイのでどうしてもやりたい技術でした。
あと、メインとなるRailsはこの記事に書いているスキルの中で唯一経験が無かったというのが一番の理由です。Rubyが好きなのもありますけどね。
いやぁ、退職しようとすると会議室で8時間説教されるって都市伝説じゃないんですね〜。
ところで転職活動をした感覚だと、今より給与が2倍出るところでも簡単に内定が出ることが分かりました。
転職活動やエロサイト作成を通して精神的な余裕も出ましたので、もう少しSIerそのものの問題、仕事の進め方などを熟考した上で、本当に正しいSIerのあり方を考えたいと思います。無理そうなら逃げます。
以上、よろしくお願いいたします。
今日から新卒研修の技術研修が始まりました。初日はCOBOLをMacにインストールして、簡単なプログラムを書くことから始めます。
さて、なんでCOBOLなのかと感じるかもしれません。Webに限らずスマートフォンのマルチプラットフォーム開発にもJavaScriptが浸透し、RubyやPythonは学生の間で人気があります。
逆説的ですが個人的には、COBOLを研修に選びながらも「COBOLを覚えてほしいわけじゃないだよね」って思っています。
習得して欲しいのはCOBOLそのものではなく、どこまで言語の深いところまで掘り下げたのか。つまり「深さを探った経験」を得てほしいからです。
COBOLが新卒研修に適しているのは、適度な深さと広がりがあるから。（特定言語に良くない印象を与える記載がありましたので、この箇所は削除しました。大変失礼しました。）
この「言語を深く探った経験」は、まとまった時間がないとなかなか掘り下げられなかったりします。配属されて仕事や成果を求められるようになると経験しづらい。興味本位でアプリを作ることに没頭する学生時代にも経験しづらい。教授に多くのタスクをふられがちな院生時代にも経験しづらかったりします。
プログラミング言語を、深いところまで掘り下げる機会は、新卒研修の時期に適していると僕は思います。成果や責務に追われずに、プログラミング言語に没頭することが許されているからです。
COBOLのもうひとつの側面は、個性があらわれやすい言語だと僕は感じます。きれいに書けば人間性が感じられるほど美しく書けます。逆に雑に書けば、プログラマとしての伸びしろが良い感じに見えるくらい、未熟に書けます。
COBOLが新卒研修に適しているのは、適度に思考の深みを表現できるから。（特定言語に良くない印象を与える記載がありましたので、この箇所は削除しました。大変失礼しました。）
ここは賛否両論ありますが、いずれにせよCOBOLで何ができるのかではなく、COBOLを通してその人の可能性の何が見えるのかが大事になります。アプリを開発する新卒側と、人材を開発する人事側の、視点の違いもありましょうが。
だからこそ、COBOLというプログラミング言語を通して、深く掘り下げる機会を大切にしてほしいと思います。それから、COBOLを通して何を表現できるのか。プログラム設計という点から、いろいろチャレンジしてほしいなって思います。
そうすれば、掘り下げた分だけ他の言語も、もっと深く短時間で掘り下げられるでしょう。
そうして、自分の思想や仕事に対する人間性を、プログラミングで伝えられるようになったら、きっと一人前のプログラマになるでしょうね。
id:minamiyama1994 さん、反論してくださってありがとうございます。
Haskellファンのご意見がいただけて嬉しいです。元増田です。
記事全体で「関数型言語」と呼ばれているものは「関数型言語一般」ではなく「Haskellや一部OCamlの話題を含むごくごく一部の言語」の話である
わかりにくくてすいません。記事では「関数型言語」の話はしていません。「関数型プログラミング」の話をしました。
「関数型言語」は範囲がよりボンヤリとした表現です。たとえばC言語が関数型言語かどうかをみても賛否両論にわかれるでしょう。
私が記事を書いた目的は、”関数型プログラミングに縁のない人に関数型プログラミングをわかりやすく紹介したい”でした。
その目的のため、「関数型言語」という表記を注意深くとり除き、代わりに「関数型プログラミングをサポートした言語」という言い方をしています。
このスタンスの上で、
”関数型プログラミングをフルにサポートした言語”の代表として、Haskellを紹介し、
”関数型プログラミングへのサポートが片手落ちな言語”として、LispやErlangなどを扱いました(それらのファンの皆、ごめんなさい)。
関数型プログラミング初心者の方は、それらの差異なんてどうでもよい、と考えるのではないでしょうか。
関数型プログラミングとは何が良いのか、を大雑把に知りたい。
そうなのではと考えて、あえて区別せずに記事を書きました。
「たとえばモナドを知っていれば、30分程度でパーサー(解析機)を理解することができて」？ モナドはそんな限定的用途のものではないし、パーサの理解とは無関係だ(単にライブラリの設計の問題)。それにApplicativeスタイルのほうがパーサが書きやすいという人もいるだろう
id:minamiyama1994 さんの仰るとおり、モナドはパーサー以外の多くの応用があります。
現状多くのパーサーがモナディックパーサーとして書かれています。モナディックでないパーサーは、あまり多くのユーザーには使われないでしょう。
モナドなどの抽象的な構造が幅を利かせてるお陰で、ライブラリに秩序が生まれ、ユーザーはそれを使いやすく・読みやすくなっている、というのが私の言いたかった主張です。
(なお細かいことで恐縮ですが、ある種のモナディックパーサーはApplicativeでは書けません。その点をお忘れですよ)
「テキスト処理」に対して
お前それShellやPerl、RubyやPythonの前でも言えるの？
「GUI」に対して
この二つは、先人が不利な環境ですごく頑張った成果が現状なのだ、と思っています。
本質的には関数型プログラミングの強みが活かせる分野のはずです。
「個人の技量の話題」
「レシピ」に関しては、関数型プログラミングのスタイルでは、手続きを手続きとして自然に表現できるのに対し、オブジェクト指向ではできない(DSLチックなものになってしまう)、ということを言いたかったのですが、
わかりにくかったですね。
「書きやすい」
(*)関数の例で、関数型プログラミングの無駄の無さを示せた、と思ったのですが…
マヂですか…反論のためのでっち上げとかじゃなくて(失礼)？(追記: Haskellの方が「短く書ける」、のタイポだそうです)
Haskell布教のために有休とって４時間かけて書いたのにーw
撲滅…
ｼｮﾎﾞｰﾝ(´・ω・｀)
いくつかまとめて反論したい
まず最初に言っておきたいけれども、僕自身はHaskellが大好きな関数型言語大好き人間である、ということを先に述べておきたい、それを踏まえた上で以下をお読みいただきたい
最初の「オブジェクト指向 v.s. 関数型プログラミング」や「ふたつのアプローチの比較」はまあ問題ないかなぁという感じ、問題があれば他の誰かに任せます
問題は「関数型プログラミングの利点」と「関数型プログラミングの得意分野はなにか」
まず「関数型プログラミングの利点」だけれども、ファンクタが云々、モナドが云々、これは「関数型言語の話」ではなく「Haskellの話」である
そこを引いてあくまでHaskellの話だと割りきって見たとしても、「たとえばモナドを知っていれば、30分程度でパーサー(解析機)を理解することができて」？ モナドはそんな限定的用途のものではないし、パーサの理解とは無関係だ(単にライブラリの設計の問題)。それにApplicativeスタイルのほうがパーサが書きやすいという人もいるだろう、パーサの理解にモナドの知識はあまり関係がないと言っても差し支えないのではないか
「書きやすい」に関してはこれはもう「主観の問題だよね」以上の言い様がない、僕自身はC++とHaskellの両方を書く人間で、確かにC++Hakellの方が「短く書ける」と「感じる」ことは多い、がしかしそれはあくまで個人の主観であり、更にはなにか明確な基準を取ったとして、やはりこれは「関数型言語」ではなく「Haskell」の話である、わかりやすく言えば「関数型言語であるLispを僕は読み書きできない」、特定言語の、主観に大きく左右される特徴を関数型言語一般の話であるかのように敷衍して話すのは感心できない
「静的型付け」云々もこれはもう完全にHaskellやOCamlの話である、LispやErlangとは何だったのか
多くの数値計算アルゴリズムは逐次的に定義されている、関数型言語で扱いやすいものではない、簡単にいえば「それFortranの前でも言えるの？」である
遅延評価はこれまたHaskellの特徴であり関数型言語一般の特徴ではないし、別に他の非関数型言語でエミュレートできないものでもない、更に言えばこれが何か数値計算に対して有利な何かをもたらすかといえばそういうわけでもない
「分数や虚数が扱えます」、に至ってはむしろ近頃の言語で扱えない言語何かあるんですか、である、大抵の言語にはその手のライブラリはある、関数型言語に限った話ではない
お前それShellやPerl、RubyやPythonの前でも言えるの？
この手の話は「ライブラリ」の話になり、言語パラダイムにより議論されるべき問題ではない、もちろん自動並列化などの問題で数学モデルに基づいていることが多いHaskellなどは有利かもしれない、が、やはりそれは特定言語や特定のライブラリの話になり、関数型言語一般の話ではない、並行処理の扱いにくい関数型言語の設計など容易だろう
言語の話でも言語パラダイムの話でもライブラリの話でもない、個人の技量の話だろう、関数型言語でも下手にしか書けない人は上手には書けない
GUIライブラリの設計にもよるけど、GUIってOOPの強い分野だと認識していたのだけれど、さてはて
最後に要点をまとめると
近年、関数型プログラミングの重要性はいろんなところで叫ばれています。
Javaの最新バージョンに関数型プログラミングに関する新機能が加わりました。
Rubyも昨今、関数型プログラミングへのサポートが手厚くなってきています。
プログラミングの教科書の大手、オライリー社から、Javascriptで関数型プログラミングを行うための解説書が発行されました。
関数型プログラミングへの注目度は高まってきています。
おそらく、みなさんは既にオブジェクト指向が何か、を知っています。
でも関数型プログラミングとは何か、胸を張って語れる人は、周りに見当たらないかと思います。
実際、オブジェクト指向によってプログラミングする方法は、わかりやすい解説があちこちにある一方で、
関数型プログラミングとは何か、何が良いのか、ということについての、よいまとめは見つけることはできませんでした。
この記事を読む方の中で、「関数型プログラミングを取り入れるか・取り入れないか」で切実に悩んでいる人は、おそらくいないでしょう。
この記事はあまり細かいところに立ち入りません。関数型プログラミングを使う側の立場に立って、利点や向き・不向き、それが導くスタイルを書きました。
みなさんは鳥のように飛んで、高い空から、関数型プログラミングとは何か、何が良いのか、を見渡してください。
オブジェクト指向的アプローチは、名前をつけてプログラムを整理する。
関数型プログラミング的アプローチは、汎用部品でなんとかする。
Googleが近年リリースした言語、Goには、”継承”を直接サポートする仕組みが無いことが話題になりました。
また、Mac OSXの基幹ライブラリCore Foundationは、ライブラリ自体はC言語で書かれているにもかかわらず、その設計方針は明確にオブジェクト指向です。
その本質とは"名前をつけて対象を識別し、それを扱うこと"、にあります。
最もプリミティブなオブジェクト指向の対象は、ファイルハンドラです。あるファイルを開いて、読み込んで、あるいは書き込んで、ファイルを閉じる。
これらの処理をまとめたら、わかりやすいですよね？
対象に関する処理を、対象の周りにまとめる。これがオブジェクト指向の基礎的な理念です。
識別することとイコールで比較できることは、とても良く似ています。
イコールによる比較は、オブジェクト指向では鬼門であることが知られています。
PointクラスのインスタンスとColoredPointクラスのイコール演算をどう決めればいいかに、正解はありません(詳しくは"effective java"をご参照ください)。
また名前をつけて識別する対象は、フワフワしていてはいけません。
たとえば、"軍人の階級"をオブジェクトにしたとしましょう。"大佐"クラスのある兵士は名前のフィールドや、性別のフィールドを持っているでしょう。
ところで彼が昇格したときに何が起こるでしょうか。
新たに"少将"クラスのインスタンスが作られます。"大佐"クラスを破棄する前に、名前、性別、その他沢山のデータを引き継がなくてはいけません。フィールドを増やしたい場合はその都度コードに修正を加える必要があります(*)。
なるべくイコール比較を避けたい。対象は不安定なものではいけない。では何に名前をつけて、識別するか。そこにオブジェクト指向技術者の熟練度が現れるのです。
一方、関数型プログラミングでは、特定の何かに名前をつけるより、極力、汎用部品でなんとかしようとします。
関数自体をリストなどのデータ構造に詰めることもよく行われます。
実は、関数型プログラミングというのは本質を表していません。
関数をはじめとして、リスト・ツリーのようなコンテナ、手続きを抽象化したもの、回路を抽象化したもの。
あらゆる対象を値として、合成し、ときに分解し、新しい値を作ります。
変数に適用する処理を作りあげることが、とても簡単だからです。
四則演算が定義されたデータを詰めたデータ構造もまた、四則演算可能だったり。
誤解を恐れずに言うと、オブジェクト指向がトップダウンなのに対し、関数型プログラミングはボトムアップです。
関数型プログラミングをサポートする言語には、沢山の汎用部品が定義されています。
このような構造をインターフェイスとして、様々なライブラリが組まれているので、
たとえばモナドを知っていれば、30分程度でパーサー(解析機)を理解することができて、
パーサーを理解できれば、JSONパーサー・ XMLパーサー・markdownパーサー・C++パーサー ... などを理解するのはとても容易です。
理解しやすいこと。これが関数型プログラミングの大きな利点です。
追記:
また、汎用部品と型のお陰で、ライブラリのドキュメントが圧倒的にひきやすい、というメリットも有ります。
Haskellな人がPythonにトライした結果 - Togetterまとめ
関数型プログラミングは「厳密な事前設計を必要とするため、簡単なことをやるのにも時間が掛かる」。
＞＞ map (*2) [1,2,3] [2,4,6]
邪魔な”儀式”や、"おまじない"のコードが徹底的に撤廃されているためです。
関数型プログラミングのコードは、潔癖かつ濃密です。
たとえばC言語でint hoge(int x,int y)が定義されているとき、hoge(3)はなんの意味も持ちませんが(コンパイルでコケますが)、関数型プログラミングでは意味があり、実際に有用です。
上の例では、「掛け算をする」(*)関数は、二引数関数ですが、それに引数を渡して作られた「2を掛ける」関数(*2)は、一引数関数になります。
関数型プログラミングでは、「簡単なことは簡単にでき、複雑なことは複雑にできる。ただし、間違ったことは殆どできないか、全くできない」。
また、静的型付けの力によって、コード補完は非常に強力になっています。インテリセンスの比ではないです。
たとえば、関数中のある表記の型を任意に表示できます(GHC/TypedHoles - HaskellWiki)。
やがてやってくる未来には、プログラムをテキストエディタで書くことは時代遅れになっているでしょう。
統合環境のサポートで、バグやミスの少ない、スムーズなプログラミングができます。
そしてその環境で動くプログラミング言語は、関数型プログラミングをサポートした言語なのです。
以下の様な兆候を感じたら、あなたはそのプログラムを関数型プログラミングで書くべきです。
一般に、オブジェクト同士の相互作用が複雑になるほど、オブジェクト指向では手に負えなくなっていきます。
そういうときは、オブジェクトを直接扱わず、替わりにその"相互作用"を扱うことで、複雑さを軽減するアプローチが有効です。
それこそが関数型プログラミング的アプローチです。
特にオブジェクト指向が有効なのは、プログラミング初心者がそのコードをいじるかもしれないときです。
関数型プログラミングは、強固さと柔軟さの代償として、高い学習コストを伴います。
オブジェクト間の相互作用が複雑でなく、着目している(名前をつけている)概念が安定しているとき。
そして、プログラムをいじる人たちの間で共通理解が図れているならば、オブジェクト指向が有利です。
遅延評価という機能によって、レガシーな言語で扱えなかった、巨大な数を扱うことができます。
関数型プログラミングで書かれたプログラムは、正確さが要求される、金融関連の業界で使われています。
手続きとしてパーサーを記述できるので、テキスト処理プログラムはより理解しやすく、メンテナンスしやすいものになります。
関数型プログラミングを知らない人は、「正規表現でおk」と言いますが、
彼の書いた複雑な正規表現は、半年後には(書いた本人でさえ)理解できなくなっていることでしょう。
手続き一般を扱うことができるので、途中で割り込みのある手続きの表現も容易です。
関数型プログラミングをサポートしていない言語ではコルーチン(ファイバー)などをつかってなんとかするしかありません。
さもなくば、非並行処理では普通に関数として記述できるところを、並行処理のために、Builder,Strategy,Command,Interpreterパターンを駆使して書き直すことになります。
Javascript使いの方は、Deferredなどの構造を使うでしょう(http://qiita.com/KDKTN/items/4c6986049d204f0645d8)。
C++使いの方はBoostで頑張りましょう。破滅的に解りにくいコンパイルエラーメッセージと格闘してください。
もう少し簡単な例をあげます。
あなたは、あるレシピにしたがって、自動的に料理を行うマシンの制御プログラムを書いているとしましょう。
1. まず玉ねぎを炒める。
2. 飴色になったら、肉を加えて炒める。
3. 野菜を加える。
4. 水を加えて煮る。
5. スパイスを加える。
…できませんよね？何故ならば、各ステップの"間に"、マシンのロボアームの位置や動きを調整する処理が必要だからです。
これをオブジェクト指向でやろうとすると、各ステップの副作用として、それらの処理を行うことになります。
そうすると、マシンが二機に増えた時などの変更量は、絶望的なものになります。
あるいは関数として表現するのを諦め、手順全体をDSLで記述できるようにします。
このアプローチは関数型プログラミング的です。しかし関数型プログラミングをサポートした言語の助けなしでは、そのDSLを記述するために沢山のユーティリティーコードを書かなくてはならないでしょう。
オブジェクト指向的アプローチでこの問題をエレガントに解こうとすると、クラス化の粒度を上げる事になります。
野菜クラス、フライパンクラス、ボイルクラス、フライクラス、焼き加減クラス、アームクラス、野菜の大きさクラス、切り方クラス、焼き方クラス、"焦げたよ"クラス、etc...
こうすると早晩レシピはプログラムのコード上から消え去ることになります。上記のたった5行は、依存性注入のオブジェクトグラフを構築するコードに取って代わることになります。そこには沢山の挙動の制御がオプションとして付記されているのです。
カレーなど、ある種のレシピに限定することで、見た目の理解しやすさを得ることができますが、一方それは表現力を損なうことを意味します。
C言語などではマクロを使うこともできますが、それは結局、関数型プログラミング的アプローチの意味するところと同じになります。すなわち、補助のために沢山のコードを書くことになるでしょう。
iOSのAppstoreアプリは、"無料"と書かれたボタンを押すと、それが"インストール"ボタンに変わり、それをもう一度押すと、ダウンロードの進捗を表すインジケータに変わり、それを押すとダウンロードをキャンセルできます。
このように、位置は同じなのに、ステートに依って見た目と機能が変わるボタンは複雑です。
これをオブジェクト指向で実現しようとすると、
という下らない問題にぶつかります。
一方関数型では、"機能"、"見た目"、"状態"、を独立に扱って、それらを合成してボタンを作るので、迷うことはありません。
「同じ位置にあるUIオブジェクトは、コード上で(インスタンスとして)独立して、他から干渉を受けない」
この条件が満たされているうちは、オブジェクト指向でGUIを実現することに無理はありません。
しかし、携帯端末のような小さい画面で、多くの機能を達成するためには、UI要素はコンテキスト依存的に複雑になりがちです。
近年、PCのディスプレイの大きさは、頭打ちになってきました。
画素数は増えているのですが、MacにおけるRetinaのように、複数ピクセルでひとつのドットを表すようになってきています。
これは、ひとつの画面に置かれるボタンなどのUI要素の数は、これから先の未来で増えることはない、ということを意味します。
したがって、未来のGUIのプログラミングは、注意深く機能をピックアップして制限するというデザイナーの努力を脇におけば、
関数型プログラミングの力を頼るしか無いでしょう。
つまり…
Haskell さいこうなのおおおおおおおおおおおおおおおおおお!! おしっこ漏れちゃうのおおおおおおおおおおおおおおおおおおおお(゜∀。)ﾜﾋｬﾋｬﾋｬﾋｬﾋｬﾋｬ
1. google:すごいHaskellたのしく学ぼう を注文する。
2. Download Haskell を自分のPCに導入する。
3. コンソールにghciと入力して、対話型コンソールを立ち上げる。
4. 次の関数をコンソールに打ち込んで、結果を見る。即値で書かれているところとかをいろいろ変更してみて、感動する。
take 4 $ map (*2) [1..]
追記:
いかがでしたか？
ちまたには、関数型プログラミングの利点は変数が無いことだ、とか、より安全だから、とか、より速いから、などという妄言が満ち溢れています。
オブジェクト指向と関数型プログラミングは、水と油ではありません。プログラマは自分のプログラムに最適なアプローチを選ぶことができます。
一般にはあまり知られていないことですが、Haskellにもオブジェクト指向へのサポートがあるんです(Lensライブラリ、これを使用したサードパーティ製ライブラリも最近増えてきています)。
この記事を読んだオブジェクト指向プログラマのあなたが、少しでも関数型プログラミングに(そしてHaskellに)興味を持ってくださって、ホームセンターの大人用オシメのコーナーが大賑わいになれば幸いです。。
特に結論は無い。興味があって勉強している。取引口座は作ったけどまだ一円も入れていない。
いろいろ本を読んだけど、まともそうな本に書いてあることをまとめると、利益を上げるための原則は以下の通りのようだ。
たぶんシステムの構築・検証に半年〜1年くらいはかかると思われるので、しばらくは実際の取引はしないと思う。やるとしても、最安株式の単元未満株を使って場慣れ＆検証をする程度かな。それだけ安い物だと手数料で負けるだろうけど、それは問題では無い。手数料はO(1)だし、システムの有効性が検証できれば問題なし。どちらにしても、始めるタイミングは中国の不動産バブル崩壊の直後がベストだと考えている。
プログラミングは得意なので、できれば売買まで自動化できるといいけど、ちょっと面倒かな。携帯用画面を使えばシンプルなので可能かも。
計算はRを使うのが一番簡単なのだけど、計算以外のところが面倒なんだよな。データ収集・可視化・注文実行にはPython+matplotlibを使いつつ、計算はRに投げるか。でも、パラメーターの総当たり検証もしたいけど、それはGPUに投げたいからC++で書く必要があるかも･･･
