「遅延評価」を含む日記 RSS

はてなキーワード: 遅延評価とは

2024-06-28

anond:20240628095628

10個以上とは言うけど、じゃあいくつまで対応せにゃならんの?ってのは気になるな

メモリ足りなかったらどうすんの?まで来たら地獄

そもそも今処理する必要ある?遅延評価でええやろ、とか言って突っかかってみたりして

2024-03-21

もうね・・・

コーンフレークじゃなくて、Haskellだとして、全体のネタを書き直してくださいっていう指示した結果

ツッコミ「どうもーどうも ミルクボーイですー」

ボケツッコミ「お願いしますー ありがとうございますー」

ツッコミ「あー ありがとうございますー ねっ 今Githubスターいただきましたけどもね」

ボケツッコミありがとうございますー」

ツッコミ「こんなん なんぼあっても良いですからね」

ボケ「一番良いですからね」

ツッコミ「ねー 有り難いですよ ほんとにね」

ボケ「入れておきましょう」

ツッコミ「ゆーとりますけどもね」

ボケ「いきなりですけどね うちのオカンがね 好きなプログラミング言語があるらしいんやけど」

ツッコミ「あっ そーなんや

ボケ「その名前ちょっと忘れたらしくてね」

ツッコミプログラミング言語名前忘れてもうて どうなってんねそれ」

ボケ「でまあ色々聞くんやけどな 全然からへんねんな」

ツッコミ「分からへんの? いや ほな俺がね おかんの好きなプログラミング言語 ちょっと一緒に考えてあげるから どんな特徴ゆうてたかってのを教えてみてよ」

ボケ「あのー関数型言語で、型システムが強力で、遅延評価するやつやって言うねんな」

ツッコミ「おー Haskellやないかい その特徴はもう完全にHaskellやがな」

ボケHaskellなぁ」

ツッコミ「すぐ分かったやん こんなんもー」

ボケ「でもこれちょっとからへんのやな」

ツッコミ「何が分からへんのよー」

ボケ「いや俺もHaskellと思うてんけどな」

ツッコミ「いやそうやろ?」

ボケオカンが言うには 将来の夢はそれで書かれたOSを使うことやって言うねんな」

ツッコミ「あー ほなHaskellと違うかぁ Haskell製のOSなんてまだ無いもんね」

ボケ「そやねん」

ツッコミHaskellOSを作るのには向いてへんからなぁ」

ボケ「そやねんな」

ツッコミ「な? Haskell側もOS開発に任命されたら荷が重いよあれ」

ボケ「そやねんそやねん」

ツッコミHaskellってそういうもんやから ほなHaskellちゃうがなこれ」

ボケ「そやねん」

ツッコミ「あれほなもう一度詳しく教えてくれる?」

ボケ「なんであんなにモナドが難しいのか分からんらしいねん」

ツッコミHaskellやないかい モナドは確かに難しいねHaskellの でも俺はね あれはHaskellの良いところやと思うねん 俺の目は騙されへんよ 俺騙したら大したもんや」

ボケ「まあねー」

ツッコミ「ほんであれよー いざ使ってみたらね モナドのおかげでコードスッキリするねん 俺は何でもお見通しやねんから Haskellモナドなんて」

ボケ「分からへんねんでも」

ツッコミ「何が分からへんのこれで」

ボケ「俺もHaskellと思うてんけどな」

ツッコミ「そうやろ」

ボケオカンが言うには プロダクションで使うにはまだ早いって言うねんな」

ツッコミ「ほなHaskellちゃうやないかい プロダクションHaskell使ったら 上司がひっくり返すもんね Haskellはねー まだ研究段階やから実務では使いにくいねん」

ボケ「そやねんそやねん」

ツッコミ「な? Haskell使ってみたらだんだん罠が見えてくるから 最後ちょっとだけ避けてまうねんあれ」

ボケ「そやねんそやねん」

ツッコミ「そういうカラクリからあれ」

ボケ「そやねんな」

ツッコミHaskellちゃうがな ほな もうちょっとなんか言ってなかった?」

ボケ学生の頃 なんでみんな憧れるんか分からんかったらしいねん」

ツッコミHaskellやないかい 学生の頃はHaskellOCamlLispに憧れるんやから あとSmalltalkも憧れたな Haskellそんなもんよ」

ボケ「分からへんねんだから

ツッコミ「なんで分からへんのこれで」

ボケ「俺もHaskellと思うてんけどな」

ツッコミ「そうやろ」

ボケオカンが言うには 関数型プログラミング教科書に必ず載ってるっていうねん」

ツッコミ「ほなHaskellやないかい 教科書サンプルコードHaskellコードが出てこんわけないやん」

ボケせやねん

ツッコミHaskellはね 関数型プログラミング王道中の王道やねん」

ボケせやねんせやねん

ツッコミ「あれみんな関数型の慣用句書いとんねんあれ」

ボケせやねんせやねん

ツッコミHaskell絶対 ほな ほなもうちょっとなんかゆうてなかったか?」

ボケWebアプリ作るのに適してるらしいで」

ツッコミHaskellやないかい Yesodとかあるやろ な? RubyとかPythonの次はHaskellが来るって言われてるねん 俺はそう思うよマジで Haskell絶対

ボケ「分からへんねんでも」

ツッコミ「なんで分からへんのこれで」

ボケ「俺もHaskellと思うてんけどな」

ツッコミ「そうやて」

ボケオカンが言うには ジャンルでいうたら数学やっていうねん」

ツッコミ「ほなHaskellやないかい ジャンル数学言うたらHaskellしかあらへんやん な? Haskell数学理論ベースになってるんやで ラムダ計算とか圏論とかな」

ボケ「そやねんそやねん」

ツッコミ「ほなHaskellに決まりやないかい ほなもうちょっとなんかゆうてなかった?」

ボケコードを書いてる時に 変数感謝してまうらしいねん」

ツッコミHaskellやないかい Haskell変数が不変やから 変数感謝するのは当然やねん ね? 状態変更せんと安心して使えるからな」

ボケ「そやねんそやねん」

ツッコミJavaとかの変数は裏切るからアカンねん Haskell変数は一生そばにおってくれるから最高やで」

ボケ「でも分かれへんねん」

ツッコミ「分からへんことない おかんの好きなプログラミング言語Haskell もぉ」

ボケ「でもオカンが言うには Haskellではないって言うねん」

ツッコミ「ほなHaskellちゃうやないかい オカンHaskellではないと言うんやから Haskellちゃうがな」

ボケ「そやねん」

ツッコミ「先ゆえよ 俺がラムダ計算説明してる時どう思っててんお前」

ボケ申し訳ないよだから

ツッコミ「ホンマに分からへんがなこれ どうなってんねんもう」

ボケ「んでオトンが言うにはな」

ツッコミ「オトン?」

ボケBASICちゃうか?って言うねん」

ツッコミ「いや絶対ちゃうやろ BASICなんて時代遅れもええとこやん もうええわー」

ボケツッコミありがとうございましたー」

2022-05-23

anond:20220522163908

ラテン語古代ギリシャ語・サンスクリット語のうち、最低どれか1つは読めるようになった方が良いとは思う。

少し前に、ギリシア詞華集に出てくる女性詩人ヒロインにしたマンガが一部で流行って、それで古典ギリシャ語に手を出した人が相当数いたみたいだが、何らかのきっかけでこういう古典言語に入ると広い世界が拡がってる。

それはともかく、たとえばHaskell勉強して遅延評価関数型言語妙味を知り、Rustを勉強してメモリ管理の大変さを知り、Go勉強してCSP代数面白さを再認識する、などの知的好奇心を満足させる意味で、各言語の特徴を把握した上で勉強するのはすごく楽しいんじゃないだろうか。

さらバックグラウンドとして、簡単でも良いので半導体ゲートと同期回路がどうCPUメモリを作り出していったか、を知ると、よりこれらの「プログラミング言語」というもの妙味を味わえるだろう。

金を儲けたければ、浅く広く勉強した上で、どれか1つの言語に絞って、深く、深く、ライブラリと同じ機能は自前で用意できる程度まで深められたなら、おそらく食いっぱぐれはない。

2021-07-19

anond:20210718234819

∞と∞を不等号で比較することはできないんだ。

それは事実。∞/∞ は定義されてないよ。知ってるよ。でもさ、数式的にわかっているときに発散具合で、関数自体比較できるのじゃないの?

④の式を計算機で処理することはできないというあなたの説に反論する為に、WolframAlphaに④の式を計算させるリンクを張ったのだけれども、意図を全く理解してないようだな。

そりゃ、そうだろ。WolframAlpha が数式を表記できなかった誰も使わねえ。アホか。俺は電卓までは否定しないよ。違うってば。オレっちは「制限のあるメモリ(=有限)上では ∞ は定数としか扱えない」から、「数学=計算機科学」ではない、と言いたいの。「反例の反例」で書いたけど、遅延評価のような手法を使うと数学問題プログラミングで解けるよ。なんなら、虚数分数でも HaskellRuby を使うとプログラミング上は解けるよ。それは言語製作者がパフォーマンスを落として実現しているだけで、メモリプロセッサでは直接演算してないのよ。まさかだけど「物理学小数分数を同じものとして扱ってはいけない」ことを知らないとかじゃないよね?

2021-07-18

anond:20210718161719

数学という学問は「反例があったら、仮説を否定できる」という学問なんだよな?だったら、数学的な問題計算機で処理できなければ「計算機科学=数学」を否定できるのだろ?なら、今からやってやる。

f(x) = x ^ 2, g(x) = 2 ^ x とする.

② x に無限に大きくなるときf(x) とg(x) は共に無限に発散するが、

数学的には lim が「x →∞」のときf(x)〈 g(x) と言える。

④ なぜならば lim が「x →∞」のとき、(x^2)/(2 ^ x) は 0 に収束するからだ。

これは数学的には合っているだろ?歴史的にはカントールがこの難題をクリアしてくれたのだろ?俺は大学数学科じゃないか不勉強なのは認める。ただ、上記の主張は数学的には合っているはずだ。

じゃあ、計算機無限比較するとどうなるか?これから書くことは、IEEE 754 といった現実世界プロセッサで語るぞ。


③' 計算機では lim が「x →∞」のときf(x) 〈 g(x) と言えない。

④' なぜならば lim が「x →∞」のときf(x) と g(x) は +∞ という二進法上の値となり「等値」となるか、「比較できない」ものになる。

⑤' 以上から、「数学=計算機科学」ではないと言える。

反例の反例が来るだろうから、こっちも否定しとくぞ。たとえば、Haskell のような遅延評価をする言語では ⑤ の「(x^2)/(2 ^ x) は 0 に収束する」という記述可能ではある。ただ、それはアルゴリズム的に Haskell記述できるからであって、メモリ上やプロセッサ上では扱えているわけではない。よって、この「反例の反例」は否定できる。


俺の言っていることは、おかしいか

2021-03-27

C#勉強をしている

本買ってきた

LINQRubyで見たことあるやつだ

迂闊に遅延評価確定させると遅くなって怒られるやつ

結局for文がいちばん勢力大きいの?1行で書けるよりもパフォーマンス重要?そう…

2020-10-10

anond:20201010162229

基本的に最小限

 ↓

なんで基本なの?

 ↓

まちがて、つかうといけないか

 ↓

だって、最長にしたばあい

あなたがいうように間違って使う位置では、前回のライフタイムは終了しているか

値を書きかえようが、なにしようが実害は出ない

次のブロックだもんねぇ 再利用するのは

では 最長にした場合 遅延評価と同じで、いちいちメモリを開放しない

では 最小のほうが良いと主張する理由は? って思ったんだ

まぁ、どっちでもおもしろいけどね

 

論理的には最小が良さそうに見えるけど 現実には最大のほうが効率よくね?とうけとってもらってもいい。実際はおれも最小で書くがwww

anond:20201010162103

変数スコープをなるべく大きくとっておいて

開放するタイミングを遅らせる

というのはあるいみ遅延評価だよね

anond:20201010161417

スクリプトだと、遅延評価に合わせて宣言時にメモリを確保することが多いけど

C++だとコンパイル時に確保する場合もあるから微妙 つまりAutoならい宣言してもあまりかわらない。Localでも宣言位置ではかわらないよね

2020-06-08

C++17むずかしい

書いたとおりに実行してほしいのだが

なぜか遅延評価でもされているかのような結果になってしまうので

遅延実行をキャンセルというか呼び出し時実行してくれるようにするにはどうかいたらよいか方法確認中 シーケンシャルな処理の順序が狂うので 確認中 むずいこれ

うかっとすると遅延実行みたいになっちまうthread async .joinなどは書いているはずなんだが むずいな

2019-01-29

Land of Lisp読み終わった

一周目は軽く読み流し、二周目にコードを書きながらしっかり読んだ。2週間かかった。

これに手を付ける前のLisp歴は1週間。ネットLisp入門読んだ程度。

オライリーの本にあるまじきファンキーな表紙なだけでなく、中身もジワる漫画イラストがちょくちょくある。

にもかかわらず内容は恐ろしく難しかった。

読んでいて素晴らしい技術書だと絶賛されているのがわかったし私もそう思うが

Lispを学ぶのに一冊目の本としては適さないと思った。

一冊目の本は機能解説に特化すべきだ。

ソケット通信ゲーム木、ミニマックス法によるAI実装など出てきて

それを今学習中の未知のプログラミング言語解説されるので二重の複雑さ・苦しみになっていた。

とは言っても他にLispの本なんてないし、これをやるしかないのだろう。

2018-10-04

anond:20181004145230

俺が知ってるのはswitchよりelseifの方が早いとかラムダ式遅延評価とか

詳しい人はメモリとかレジスタレベルで語るからついていけない。ってか尊敬してる。

でもまあ理由あってうっとおしがってるから、語ってくる奴らは大したことないんだろう

2018-04-17

anond:20180417215313

増田は「遅延評価」を知らないのかな?

コンピュータプログラム世界では、「この計算やっとけよ。結果はこの紙に書いとけよ」という命令を出してもその場では実行されないことがあるんだ。

あとで「答いくつになった?」って尋ねられたら、その時「あっもちろん計算しておきましたよ」とばかりにあわてて紙に書き始めたりする。

もし「答いくつになった?」と聞かれる機会なく終わるようなら、計算せずに白紙のままで済んじゃうので、CPUパワーを節約できるというわけだ。コンピュータも上手にサボってるみたいでおもしろいよね!

 

ところでみんなは学校テストを受けたり、職場仕事アサインされたりして、定期的にその能力評価されているよね。

ももし「能力」を参照する機会自体をなくしてしまえるとしたら?その場合評価関数の実行をまるごと省略できることになる。つまり結果はずっと不定のままになるんだ。

たとえ「能力を測って、結果をこの履歴書に書いとけよ」とはっきり命令したとしても変わらない。誰もその履歴書を見る人がいないとわかっているなら、CPU履歴書を書かずに済ませようとするし、能力も測らないんだ。

このように、遅延評価という考え方を導入すれば人生の労力の大部分を節約することができる。ちゃんと考えられてる。角度とか

2018-04-03

haskell勉強

高階関数遅延評価とか参照透過性とか結構面白い概念でやってて楽しいんだけど

デフォルト遅延評価だったり参照透過性だから実行中に何しても値変えられないとかやっぱ頭おかしいわ

でもこれ好き、癖になりそう

2015-01-18

みんな大好き

#毛の壁 氏について。

人格的なことは触れないとしても、みんな思うのは、「どうして色々読んでるっぽいのにああなれるのか」ということだと思うので、ちょっと考察してみた。

恐らく氏は、センテンス、辞書の項目くらいの長さのものの把握には長けている。ただ、文脈を読むとか、全体像を把握するとかそういう能力が欠如してる。多分、話の筋に展開があるとセクション単位のものも把握できない。

そのため、ミクロ理解のみで全体を捉えようとするから認識現実齟齬が起きる。また、一見同じ形をしているが、論じるべき階層がそもそも異なるようなことを混同してしまう。もちろん物事の体系的な理解も出来ない。そうなると多分いわゆる構造化が必要レベルソースも書けない。形式的定義証明理解も怪しいのだろう。

そう考えると、関数型プログラミング遅延評価だと思うのも、評価戦略としての遅延とライブラリレベル提供される lazy/force を混同するのも、S式Lisp 構文を混同するのも理解できる。アカデミックな体系的学習必要haskell, ML に手が伸びないのもわかるし、数学的基礎と言っておきながら基礎論が全く出てこないのも分かる。ラムダ計算を知らないとすると、Lisp のあのへんてこな改造(?)もうなずける。局所的なスコープクラスモジュール単位アクセス制限の話で揉めてたのは、多分モジュールクラスをまともに扱ったことがないからなのだろう。それは github珍妙コードからもなんとなく推測できる。

全く無駄時間を過ごしたが、なんかある意味未知との遭遇で楽しかった(小並感

これが氏の発するカリスマオーラなのだろうか。

2014-05-15

未来の為の寛容さ

関数本と称したデタラメ本なんかどれだけ高く平積みしたところで、どうでもいいと思ってるよ。間違って買っちゃった初心者右往左往するだろうが、きっといつかは正しい知識に戻ってくるだろうし、それで諦めちゃう人はどのみち辞める定めなんだろう。たとえQiitaとかで議論を吹っかけられようと、話し合いが成立しないと判った時点で席を立てばいい。煽られようとワザワザ付き合ってやる必要はない。でも実際のお前らは腹を立て、戦い、傷ついてPTSDになって、数スレを消費した。そんなナイーブなお前らが、今回の事件は何故かスルーできた。

悪意のカタマリだろうと、他愛のない道化はむしろ放置でいいと思うんだよ。色んな奴がもっと好き勝手に書くべきだ。ちゅーんさんはモナド本を書いていいし、漫画解説する関数型があっていいし、遅延評価解説本は望まれている。市井プログラマー素人技術本を書いていいんだ。関数型プログラミング繁栄はそういう態度の先にあると思う。選択肢は多い方がいい。その中で、何が本当に重要かは読者が決める。ヘンテコリンな奴をありのまま受け入れる寛容さは必要だと思うんだ。

でも今回のはそれに収まらない。重要さのレベルが違うだろ。どこぞの馬の骨じゃない。あの子日本Haskellコミュニティの若手ホープじゃないか。今は女性関係で腹を立てているだけかもしれないが、将来トップに立った彼に「あなたライブラリは負の価値しか持ちません」っつって包丁画像突きつけられたらどうする。Slackでは「勉強会に参加する学生が少ない」とか嘆かれてたけど、俺が学生なら、もはや頼まれても行きたくない彼女言及しなければ安全? 俺はそんな風には全然思えないし、正直不安だよ。



…いや、だからどうしろって言う意見はない。どうすればいいかは判らない。お前らの冷静さにビックリしたというのが感想だ。他人が頭ごなしに言っても伝わらないだろうし、本当に必要なのは排斥することじゃなくて、自分の考えを親身になって聞いてくれる仲間だと思う。ただ正論ねじ伏せるのでなく、それでいて「単なる腰抜け」じゃない誰か。

彼はスレ民でもあった筈だが、ム板のこのスレはそういう話に適さないだろう。俺たちが場を提供することはできない。勝手だが身内に期待したい。圏論の話ならいつでも歓迎です。

以上、スレ汚し済まなかった。コードポイントフリーにする作業(たのしい)に戻ります

--------------------------

この文章は当初2ちゃんねるプログラムHaskellスレに投げる予定だったが、スレ汚しになると判っていて書くのもどうかと思い、失礼してこちらに置きました。あとリツーイータビリティ。(この記事リンクフリーです)

2014-04-10

http://anond.hatelabo.jp/20140409010816

いくつかまとめて反論したい

まず最初に言っておきたいけれども、僕自身はHaskellが大好きな関数型言語大好き人間である、ということを先に述べておきたい、それを踏まえた上で以下をお読みいただきたい

最初の「オブジェクト指向 v.s. 関数型プログラミング」や「ふたつのアプローチ比較」はまあ問題ないかなぁという感じ、問題があれば他の誰かに任せます

問題は「関数型プログラミングの利点」と「関数型プログラミングの得意分野はなにか」

関数型プログラミングの利点」に対して

まず「関数型プログラミングの利点」だけれども、ファンクタが云々、モナドが云々、これは「関数型言語の話」ではなく「Haskellの話」である

そこを引いてあくまでHaskellの話だと割りきって見たとしても、「たとえばモナドを知っていれば、30分程度でパーサー(解析機)を理解することができて」? モナドはそんな限定的用途のものではないし、パーサの理解とは無関係だ(単にライブラリ設計の問題)。それにApplicativeスタイルのほうがパーサが書きやすいという人もいるだろう、パーサの理解モナドの知識はあまり関係がないと言っても差し支えないのではないか

「書きやすい」に対して

「書きやすい」に関してはこれはもう「主観の問題だよね」以上の言い様がない、僕自身はC++Haskellの両方を書く人間で、確かにC++Hakellの方が「短く書ける」と「感じる」ことは多い、がしかしそれはあくまで個人の主観であり、更にはなにか明確な基準を取ったとして、やはりこれは「関数型言語」ではなく「Haskell」の話である、わかりやすく言えば「関数型言語であるLispを僕は読み書きできない」、特定言語の、主観に大きく左右される特徴を関数型言語一般の話であるかのように敷衍して話すのは感心できない

「静的型付け云々」に対して

「静的型付け」云々もこれはもう完全にHaskellOCamlの話であるLispErlangとは何だったのか

関数型プログラミングの得意分野はなにか」に対して

数値計算」に対して

多くの数値計算アルゴリズム逐次的に定義されている、関数型言語で扱いやすものではない、簡単にいえば「それFortranの前でも言えるの?」である

遅延評価はこれまたHaskellの特徴であり関数型言語一般の特徴ではないし、別に他の非関数型言語エミュレートできないものでもない、更に言えばこれが何か数値計算に対して有利な何かをもたらすかといえばそういうわけでもない

分数虚数が扱えます」、に至ってはむしろ近頃の言語で扱えない言語何かあるんですか、である、大抵の言語にはその手のライブラリはある、関数型言語に限った話ではない

テキスト処理」に対して

お前それShellやPerlRubyPythonの前でも言えるの?

「並行処理」に対して

この手の話は「ライブラリ」の話になり、言語パラダイムにより議論されるべき問題ではない、もちろん自動並列化などの問題で数学モデルに基づいていることが多いHaskellなどは有利かもしれない、が、やはりそれは特定言語特定ライブラリの話になり、関数型言語一般の話ではない、並行処理の扱いにくい関数型言語設計など容易だろう

レシピ」に対して

言語の話でも言語パラダイムの話でもライブラリの話でもない、個人の技量の話だろう、関数型言語でも下手にしか書けない人は上手には書けない

GUI」に対して

GUIライブラリ設計にもよるけど、GUIってOOPの強い分野だと認識していたのだけれど、さてはて

まとめ

最後に要点をまとめると

記事そのもの価値基本的にないっぽい、こういう記事撲滅されないかなぁ

2014-04-09

オブジェクト指向 v.s. 関数型プログラミング

近年、関数型プログラミング重要はいろんなところで叫ばれています

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言語などではマクロを使うこともできますが、それは結局、関数型プログラミングアプローチ意味するところと同じになります。すなわち、補助のために沢山のコードを書くことになるでしょう。

GUI

iOSのAppstoreアプリは、"無料"と書かれたボタンを押すと、それが"インストール"ボタンに変わり、それをもう一度押すと、ダウンロードの進捗を表すインジケータに変わり、それを押すとダウンロードキャンセルできます

このように、位置は同じなのに、ステートに依って見た目と機能が変わるボタンは複雑です。

これをオブジェクト指向で実現しようとすると、

1. 三つの異なるボタンを同じ位置に置くか

2. 同じボタンが三つの異なる機能を持つか

という下らない問題にぶつかります

一方関数型では、"機能"、"見た目"、"状態"、を独立に扱って、それらを合成してボタンを作るので、迷うことはありません。

「同じ位置にあるUIオブジェクトは、コード上で(インスタンスとして)独立して、他から干渉を受けない」

この条件が満たされているうちは、オブジェクト指向GUIを実現することに無理はありません。

しかし、携帯端末のような小さい画面で、多くの機能を達成するためには、UI要素はコンテキスト依存的に複雑になりがちです。

近年、PCのディスプレイの大きさは、頭打ちになってきました。

画素数は増えているのですが、MacにおけるRetinaのように、複数ピクセルひとつドットを表すようになってきています

これは、ひとつの画面に置かれるボタンなどのUI要素の数は、これから先の未来で増えることはない、ということを意味します。

したがって、未来GUIプログラミングは、注意深く機能ピックアップして制限するというデザイナー努力を脇におけば、

関数型プログラミングの力を頼るしか無いでしょう。

はじめよう、関数型プログラミング

まり

Haskell さいこうなのおおおおおおおおおおおおおおおおおお!! おしっこ漏れちゃうのおおおおおおおおおおおおおおおおおおおお(゜∀。)ワヒャヒャヒャヒャヒャヒャ

1. google:すごいHaskellたのしく学ぼう を注文する。

2. Download Haskell自分のPCに導入する。

3. コンソールghciと入力して、対話コンソールを立ち上げる。

4. 次の関数コンソールに打ち込んで、結果を見る。即値で書かれているところとかをいろいろ変更してみて、感動する。

take 4 $ map (*2) [1..]

5. ステップ1で買った教科書を読んで、学ぶ。


追記:

いかがでしたか

ちまたには、関数型プログラミングの利点は変数が無いことだ、とか、より安全から、とか、より速いから、などという妄言が満ち溢れています

オブジェクト指向関数型プログラミングは、水と油ではありません。プログラマ自分プログラムに最適なアプローチを選ぶことができます

一般にはあまり知られていないことですが、Haskellにもオブジェクト指向へのサポートがあるんです(Lensライブラリ、これを使用したサードパーティライブラリ最近増えてきています)。

この記事を読んだオブジェクト指向プログラマあなたが、少しでも関数型プログラミングに(そしてHaskell)興味を持ってくださって、ホームセンター大人用オシメのコーナーが大賑わいになれば幸いです。。

2013-03-10

動的言語」の本当の意味の分からない半可通は静的型付言語をつかえ

プロダクトマネージャーの親父がとおりますよ。

最近、型不要とか言っている半可通がいるけど

それを書いている人より、それを見て型不要とかを真に受ける連中のほうが心配なんだよね。

とりあえず99%の庶民は静的型付言語を使ったほうがいいよ。

昔とくらべて、使える敷居は低くなってきているけど、実際に

きちんとした教育を受けていない半可通が、動的言語がきちんと

使えこなせるわけないから。

一般庶民は

コンパイル時にきちんと型エラーにしてくれる「TypeSafe」な言語を使ったほうが幸せだし

遅延評価なんかの動作がきちんと理解できない、職業プログラマIT土方)は多いんだよ。

一般庶民がそれなりに、一定品質を確保するために、「TypeSafe」な言語必要なの。

教養として、動的言語勉強するのはいいよ。

だけど、普通仕事に使うのはやめとけ。ろくな品質にならないから。

2011-09-23

「新しいプログラミングパラダイム」の目次


第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章 マルセイユPrologProlog Ⅱ,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 まとめ

2011-08-24

http://anond.hatelabo.jp/20110823201509

これからHTML5投資するか、このままFlash投資し続けるか、だよ問題は。

なぜ両方使うという選択肢がない。真の技術者ウェブ標準だろうがFlashだろうがネイティブだろうが、その場その場でユーザーの体験を最善にし、クライアントの要求を最高に満たすベスト技術を使う。JavaScriptFlashかなんて動きさえすればユーザーには関係ないんだから。実際、HTML5スゲEEEEE!!!ってページにFlashタグブクマが間違ってつけられたりしてるよ?(笑) ウェブ標準の崇高さなんてパンピーにはわからんです

そもそも分からないんだけど、HTML5が「投資」するほどたいしたもの? 誰もが基礎教養として身につけているはずの、これまでのHTMLCSSJavaScriptの延長線上の技術でしょ。今まで普通にやってきたウェブ開発者ならすぐにキャッチアップできるはずだよ。

どうせHTML5の実装の普及には当分かかるし、その時点のブラウザ環境で使用可能なものゆっくりまったりと導入していけばいいだけ。その意味はいわゆる遅延評価学習で十分。あわてることはないです。どうせ皆使うことになるんだから

一応言っておくと、いいものだと思いますよ、HTML5は。現段階で頑張って凝ったものを動かしておられるイノベーターの方々もたいしたものだと思います。敬意を。マリオやらグラディウスやらは著作権的にどーなのかと突っ込みたいが。

Appleスマホ市場で落ちぶれることを祈らないとね。

それはシナリオひとつですよね。Google甲斐性次第では十分にあり得る。それと、ジョブズが翻意するというシナリオもありますよ。今までに散々あったことですが。どこかでそれをネタにしている記事があったと思いますが。

AdobeですFlashに見切りをつけ始めてるけどね。

もしEdgeを見てそう思ったのなら、Flash CSを使って制作したことがありますか? Edgeを実際に使ってみましたか? と問いたい。

他にも、最低でも、

これらにきちんと答えられない人間HTML5 vs Flashなど語る資格はないです。そもそも対立させる時点でわかってないなー ┐(´д`)┌ って感じなのだけど。

あとFlashへの投資無駄になると思ってるようですが、俺はFlash投資判断「Buy」継続だと見てますよ。たとえこのままiOSで動かずともね。AIRもあるし、ブラウザプラグインとしてのFlashだけ見ていると考えを誤るよ。ブラウザのほうにしても、GPUアクセラレーションつきの3Dが真っ先に使用可能になるのはFlashプレイヤーの普及が速いから、WebGLと異なり、今後1~2年内に実案件で使用可能になるでしょう。そういった面ではなおカッティングエッジ技術だよ。

まあ、プラットフォーム言語の選択は投機から、どの銘柄が買いか売りかで紛糾するのはわかる。ただ、それなら分散投資だとか、インデックス投資という考え方もあるのでね。HTML5に惚れ込んで一点買いなんて若いエンジニアがいたら、それはもう相当危なっかしいなと、視野も相当狭くなるだろうなと危惧するよ。

というか、JavaだろうがC++だろうがObjective-CだろうがLLだろうがアセンブリ言語だろうが関数型言語だろうが、一度全部触ってみなよ。いいから。HTML5で手一杯なんてのでは話にならんですよ。

あと言いたいんだけど、Flashエンジニアも皆もうちょっと落ちつけ。

ログイン ユーザー登録
ようこそ ゲスト さん