  |
はてなキーワード: Lispとは
アタイ、アラサー職業プログラマーなんだが、去年の暮れ、米国に出張した際、
職場の同僚とアイリッシュパブで飲みつつ、いろいろ話したときの会話を書く。
同僚は、オートラリア出身の男20代後半、アメリカ某大学のCS専攻。
彼曰く、
パーティーとかで人と知り合うとする。
そうすると自己紹介するよね？
それで、相手が、
「私は医者なんです」
医学を学んできたんだろうなって
間違いなく思うだろ？
アメリカでは、ってことだけど。
ある人が
「私はプログラマーなんです」
っていうと、じゃあどこかでCSを学んできたんだろうなって、
当たり前のようになる。
CSの専攻だとしたら、もしかしたら俺の先輩か後輩かもしれないしね。
えーっと○○（←アタイ）は、、、
アタイ：×××××××××
そうか、Matzの後輩なのか！ （←チゲーよ！ いや、ツクバも受けたけどさ）
Lispは？Lispもやりなよ！Emacsで始めるのがおすすめ！
日本では、
「私はプログラマーなんです。」といっても
必ずしも、その人のこと、CSの専攻なのかな？とは思わないでしょ？
あれってなんでなの？
だってね、まあ極端な例えかもしれないけど、医学部を出てない医者に
手術させたら危ないでしょう？
たぶんこんな感じだったろう。
正直ね、うるさい奴だなーと思いました。
気分がよくなっていて2杯目のギネスで、もういい気分だったもん
だから、酔いにまかせて、言ってやったんだわ。
そうよ、□□（←ソイツ）の言うとおりよ。
出来たってねつ造したって騒がれてる。その騒がれ方にしてもね、
なんだろう、サイエンティフィックではないわけ。
ファナティックっていうかさ。
そういうね、なんだろうね、国の閉塞性？が嫌になって自殺する人や、
成功したアーティスト（漫画家さんだっけな？）のイベントを中止させて
「人生格差犯罪なんっす」とか言っちゃう、そういうのが流行っていて、
で、そんな中、男はみんな無気力で、セックスしたくなくなっていて、
でも日本にも良いところもあるんだよ？
とかってテキトーに答えたんだけれども。
まあでも、
メスもって人の体切り刻むようなもの
っていう感覚を持っている人といっしょに働くのは、
感じないで済むので、そこは良いなと。
すぐに仕事をホサれるというストレスはある。（これもけっこうキツい）
だが、同じストレスなら、後者のストレスのほうが、アタイには合っていた。
前者のストレスを我慢しながら働かされると、
基地外になっていたと思う。
メスもって人の体切り刻むようなもの
であることを感じない、もしくは感じても感じていないフリをする
のがお約束という慣習にどっぷり浸かった業界や会社や組織にうまく適応しつつ、
ストレスたまったら、それこそ美味い蕎麦を食べたり温泉に行ったり、
職場の 仲間とソフトボールやった後、ビール飲んでウサ晴らししつつ、
いつかオフパコを夢見てはてなで、頭のいいプログラマーっぽいブログ書いたりとか、
フェイスブックやブログに、日本人技術者ばっかりとで群れあって、
（日本の汚い）海にいって、ビーチで男女仲良くバーベキューして、
俺ら私らリア充だぜ！的な画像を載せて、自己マンに浸るっていう、なんか
そういう人生を送って年をとるっていう感じなわけじゃない？
それで基地外にならないで、シアワセになれるんだったら
憂鬱を今年はどうにか解決したい。
以上、年頭所感にかえて
これ読んでも関数型分からないけど、入り口の前あたりに立つために
プログラマとしての引き出しが増える。
って書くと「そんなもんどんなプログラミングテクニックだって一緒だわ」って言われそうだけど、でもそうとしか言い様がない。
とりあえず、オブジェクト指向と同じで、プログラムを構造化して、複数のレイヤーに切り分けて部品化していくテクニックだとは言える。
ただオブジェクト指向とは大分切り口が違う。何ていうか、割と直交する切り口でプログラムの構造を切り分けていく。
なので、関数型とオブジェクト指向と両方憶えるだけで、大分切り口の引き出しが増える。
オブジェクト指向と関数型両方憶えると、プログラマとしての引き出し増やすのに効率が良い、って思えば良いかも。
オブジェクト指向は、プログラムの各部品を「あれの中のこれの中のそれの中にあるあれ」みたいな感じで組み合わせる。
部品が更に細かい別の各部品で構成されていて、それぞれの部品が噛み合わさって、複雑な一つのプログラムを構成するような切り方。
関数型言語は、プログラムの部品を「あれをした物にこれをした物にそれをした物にあれをする」みたいな感じで組み合わせる。
もっというとプログラム全体を簡単に記述するできるDSLがあって、そのDSLを簡単に実装するためのDSLがあって、DSLの入れ子構造で一番小さい部品はシンプルな関数、みたいな切り方。
ケースバイケース。
ではあるんだけれど、シンプルな部品を大量に組み合わせて構成するのがしっくりくるならオブジェクトで、部品数が少ないんだけど一個一個が複雑な動作する構成にしっくりくるのが関数型……かも？
関数型言語たる条件として「関数が第一級オブジェクト」ってのがあるんだけど、関数が第一級オブジェクトだとイミュータブルなデータを素直に扱える。
で、イミュータブルなデータ構造使うと色々便利、ってことで実例として一番出てくるという。
関数型言語のエポックメイキング的な言語が三つくらいあって、元祖のLispとその流れ汲んだMLとMLの一種で関数型をある種の到達点に持っていったHaskellって感じ(独断と偏見)。
で、このうちのMLって奴が、プログラミング言語に型システムがついてるんじゃなくて、型システムにプログラミング言語がついてきた存在だったりする。
型で色々やるために生まれたわけで、まぁなんというかそもそも型と密接な関係にあって、Haskellもその流れを汲んでて、こいつが超有名になった、って感じ。
おかげさまで、型使って色々やったりする方法が日々考えられているわけです、静的型付関数型の世界では。
関数型言語ではよく「関数と関数を引き取って、合成した関数を返す関数」みたいなのが使われるんだけど、関数と関数の合成って、それ合成された関数がもともと引数として与えられていた関数憶えてないと無理やん？ 自分自身の構成部品憶えてられないわけだから。
クロージャあると憶えててくれるわけですよ。
そんな感じで高階関数を実用的なレベルで使うのには大体必須と言う。
関数型言語はDSLを作りまくる言語みたいに書いたけど、モナドはちょっと複雑なDSLを簡単に作らせてくれる仕組みだと思っとけば良い。
まず純粋の定義だけど「全ての関数は同じ引数を与えられた際、必ず同じ値を返す」ってことで、これがいわゆる副作用がないって状態だ。
で、これって逆に言えば「プログラム内である関数に対して、絶対に同じ引数を与えさえしなければ、その関数がどんな値を返したところで、事実上純粋だと言えてしまう」ってことでもある。
本末転倒感があるんだけど、HaskellではIOモナドという仕組みと特別なmain関数を使って「呼び出すたびに絶対に違う引数を自動的に関数に与えてくれる仕組み」を実現していて、こいつを使って入出力する。
うん……凄い本末転倒。ちなみにこの自動的に与えられる引数はRealWorldって名前がついていて、要は「刻一刻と変わり続け絶対に同じ状況にならない現実世界の状態を引数に取っちまっているようなもんだからしょうがないだろ？」的な感じ。
なんだか話題になってるから書く。
やっと初心者を脱して中級者になりかけてるプログラミング学習者が関数型言語に何を感じているかを書こうと思う。
Haskellが短いコードでプログラムを書けるというのは分かる。
それでやりたい処理のほぼ全てがまかなえるということも実感している。
副作用のない小さな関数を合成して大きな関数を作る利点も分かる。
再利用性も上がるし、どこからどう影響を受けているかが簡単に分かるからバグも出にくい。
ただ、Haskellの基礎になってる圏論が何の役に立つのかは、まったく分からない。
むしろ邪魔なんじゃないかと思う。
ファンクターやモナドの概念が圏論で扱われているのは分かるけど、圏論なんて名前だけ知ってればコードを書くのに不都合はないだろう。
圏論が必要なのは、Haskellを設計する人であって、使う人ではないと思う。
なのに、やれクライスリ圏だ自己関手の圏だのと、うるさいったらありゃしない。
Linux上で開発環境整えるのにカーネルのコードを読めって言うぐらい的外れだと思う。
いや、知識として持っとくのはいいだろうけど、役に立たんだろ。
Rubyが羊の皮をかぶったLispとはよく言われることだけど、関数型言語もオブジェクト指向言語とそこまで違いがあるような気がしない。
純粋な言語ではできないけど、クロージャに内部状態を保持してもらって無名オブジェクトみたいな使い方をすることはあると思う。
その無名オブジェクトにもっとあれこれデータや関数詰め込めば、いつの間にか普通にJavaやC#で使うようなクラスのできあがり。
その間はなめらかにつながっていて、不連続に切れるようなもんじゃない。
関数プログラミングと言いつつ、オブジェクト指向の考え方は利用できる。
上級者はデザインパターンをdisるのが好きかもしれないけど、逆の考え方をするべきだと思う。
デザインパターンはオブジェクト指向言語の欠点を補うための苦肉の策じゃないよ。
関数プログラミングの基礎的なパーツだと思う。
だからちょっと見た目がすっきりするだけで、結局やることはオブジェクトプログラミングと変わりはないと思う。
関数プログラミングコミュニティの人って、業務でクソコードメンテさせられて、その現実逃避に美しいコードに擦り寄っているように見える。
もちろん、美しいコードを書けるなら書いた方がいいし、現代的な言語を使えるなら使ったほうがいいと思う。
けど、適材適所というか、オブジェクト指向言語でも、やってやれないことはないわけで。
役に立たない圏論をありがたがる所とか、どうもイキがってるように見える。
せいぜい生産性が倍になる程度で、他の要素が悪ければ帳消しになるような利点でしかないに違いないのに。
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の強い分野だと認識していたのだけれど、さてはて
最後に要点をまとめると
