「OCAML」を含む日記 RSS

はてなキーワード: OCAMLとは

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なんて時代遅れもええとこやん もうええわー」

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

2023-09-27

anond:20230927200327

でもガチCS勉強しようと思ったらアルゴリズムデータ構造必須で、それに適した言語となるとC以下あれやこれやでしょ。

あと、デザインレシピかいう考え方なら OCaml とかの関数型言語が入門に適しているし、オブジェクト指向ならCじゃ無理だし。

anond:20230927192102

初心者にもいろんなタイプがいるんだよ。すぐ何かに役立つ知識よりもCSの基本からじっくり勉強したい初心者もいる。(俺とか) 

大学によっては一年生向けの最初言語が C だったり OCaml だったり Haskell だったり Oberon だったり PascalAda だったりするところもあるくらいだからな。もちろん少数派だけど。(今の多数派は多分 Python か C)

anond:20230927111127

7つの言語 7つの世界

著者Bruce A. Tate 著、まつもと ゆきひろ 監訳、田和 勝 訳

  ・・・ この本、面白そうなんだけど、取り上げられている言語が「Ruby、Io、PrologScalaErlangClojureHaskell」なので、ある程度プログラミング経験がある人が対象かな。たぶん複数言語を多少なりとも使ったことのある人向けかと。

ちなみにオックスフォード大学では1年生向けの最初プログラミング言語として Haskell が選ばれているとか。凄いよね。そして彼らが2番目に教わるのが Oberon だとか。言語定義が最もコンパクト言語からとか。(ケンブリッジ大学最初に教えるのは OCaml だそうです。)

2022-08-11

プログラミング言語の紹介

初心者Pythonから始めましょう。やりたいことはPythonでだいたいできます世界で一番人気の言語資産豊富にあります低学歴素人がなんと言おうとPythonです。Pythonを覚えるのです。簡単なので1日あれば覚えられるでしょう。

次にSQL勉強しましょう。SQLは3日くらいあれば中級者になれるでしょう。現代データベースはだいたいSQLかそれのパチモンが備わっていますSQLができると仕事の幅が広がるでしょう。

そしてJavaScript勉強しておきましょう。Webブラウザは全部JavaScriptが動きますJavaScript勉強することでWebページで遊ぶことができるようになりますスクレイピングなどの理解も深まりますJavaScriptは便利です。

さて、ここまで来たら仕事必要プログラミングは身についているので次に進む必要は無いです。コンピュータ気持ち理解するためにはC言語をかじってみるのもいいでしょう。大企業で働きたいならJava必須です。型に興味を持ったらOCamlHaskellに手を出してみても良いでしょう。システムプログラミングをしたいならGoやRustも良いです。Goバカみたいに簡単ですがRustは初心者向きではないです。

2021-08-08

プログラミング言語関数型言語ってOOPを含めた命令言語に劣る理由

Scala や Elm と Lisp やら HaskellOCamlSML関数型のプログラミング言語勉強したけど、これらが命令言語に劣る理由解説しよう。

解釈自由関数言語アセンブリレベル最適化ができない

これは、SQL も同じ問題を持っているが、関数言語は「こういうふうに動いてね」という解釈インタープリターやコンパイラが「推測する」必要があるのだ。つまり、書いているときパフォーマンスプログラマー想像できない。

ハイパフォーマンスを出す関数言語コンパイラを作れば良いじゃん?

それが、現実的に厳しいのだよ。マジでコンパイラ関連は金にならない領域になってきたので、関数言語のための独自コンパイラを作る持続可能組織が無い。確かにLLVM を使えば x64arm といった最新のアーキテクチャ対応できるかもしれないけど、フロントエンドレベルすら応対が辛い。よって、関数言語C言語にてチューリング完全な同等なコードだと「いくら最速に書いても」遅いのである

人間は「命令するほうが楽」なので、関数言語は負けます

例えば if と書いたら、関数言語は else が必須ですが、命令言語は else 無しでも動いちゃうのですね。文系の連中が数学的な背景を加味して要件定義できると思うか?違うだろ。毎回、上に else のことについて聞いたら、プログラマー生産性は下がるだろ。関数言語は、上が文系だとますますだが、分岐もきっちりとおさえる必要があるから生産性命令言語に劣るよ。

2021-07-31

Scala や Elm と Lisp やら HaskellOCamlSML関数型の勉強したけど、

結局は RubyJavaScript といった似非関数言語レベルですらついていける人間の方が少なくて、もはや Python なんていう関数型もOOP馬鹿にしたような言語大学側が積極的にプッシュするという、過去プログラマーの偉大な苦労が荼毘に付されそうな今、一体何のために俺たちは戦ってきたのだろうね。本当は、PHPVB で良かったんじゃねーの?


僕は Ruby と Rust ちゃん

2017-09-11

まずは自分がプログラマーになってみよう!

山本五十六名言「やってみせ」

やってみせ、言って聞かせて、させてみせ、ほめてやらねば、人は動かじ。

話し合い、耳を傾け、承認し、任せてやらねば、人は育たず。

やっている、姿を感謝で見守って、信頼せねば、人は実らず。

まずは、あなた自身プログラマーになって、見本を見せることが第1歩です。

プログラマーに向いている性格

その後受託系の会社就職できたのだけど、人間関係がうまくいかなかったようで数ヶ月で辞めた。

鬱病気味になったみたい...。

どうやら、プログラミングという仕事の特徴について、あなた理解していないようですね?

 

プログラミングの特徴は、「コンピューター相手なので、嘘やハッタリが一切通用しない」ということです。

人間相手なら、適当に指示を出したり、いい加減な対応でも何とかなるけど、コンピューター相手だと1mmも融通が利きません。

 

従って、プログラマーに向いている性格は、

  1. 嘘をつかない
  2. 几帳面
  3. パズルを解くのが好き

という3点が必要です。

 

警察職務質問されて有名になった江添亮さんのブログ等を読んで、この方のようにネチネチと論理をこねくり回すのが好きなら、プログラマーに向いています

(例)本の虫: 麻布十番職務質問を受けた話 https://cpplover.blogspot.jp/2017/08/blog-post.html

関数型プログラミング

プログラムというのは、小さな部品を組み合わせて、大きなシステムが作られています

さな部品パズルピースに相当して、大きなシステムパズルの完成品です。

まり、大きな問題を小さな問題に分解して、1つずつ順番に問題をつぶして行く姿勢必要です。

 

プログラミングパラダイム(考え方)には、

  1. 命令
    1. 手続き型(Java等)
  2. 宣言
    1. 問合せ型(SQL等)
    2. 関数型(Haskell等)
    3. 論理型(Prolog等)

があります

 

命令型のプログラミング言語しか使えない人がプログラマーになると、テスト地獄に陥って、結果的鬱病発症やすくなるだろうと危惧しています

上述のように、パズルピースを組み合わせてプログラムを作るには、「関数型」の作法を身に付けておくと良いでしょう。

Haskell

関数型プログラミング習得するために、今なら「Haskell」または「OCaml」というプログラミング言語お勧めします。

HaskellOCamlは、良い参考書がたくさんあるので、本屋に行って実物を確かめてください。

 

Haskellを学んでみて、パズルピースを組み合わせる感覚理解できたら、あなたテスト地獄に苦しめられないプログラマーになれるでしょう。

もしも、Haskell理解できないようだったら、残念ですがプログラマーには向いていないかもしれません。

例外的に、あなたマゾで、テスト地獄残業徹夜楽しいと思える性格なら、Haskell理解できなくても大丈夫かもしれません。)

 

Haskellの教材(英語)を紹介するので、参考までに読んでみてください。

http://learnyouahaskell.com/chapters

(このサイトの内容は、日本語書籍「すごいHaskellのしく学ぼう!」として出版されています。)

 

Haskellは、順番に学べば必ず理解できるようになっています

もしも、Haskell習得できなければ、大きな問題を小さな問題に分解して解決していく作業には不向きな性格かもしれないので、他の仕事検討してはいかがでしょうか?

人生は一度きり。時間無駄にならないようにお気を付けください。)

 

あなたと友人が、無事Haskell習得して、テスト地獄を乗り超えるスーパーハッカーになり、日本IT産業を牽引されることに期待いたします。

 

(追記)

まずは、自分が作りたいアプリサービスを作ってみよう。

自分が作りたいプログラムすら作れない人が、他人希望するプログラムを作るなんてできっこいからねw

プログラマーが楽で簡単仕事だと思ったら大間違いですよ?)

 

(追記 その2)

関数型プログラミングマスターしておけば、OOPでも役に立つよ。(現実には、関数型もOOP必要に応じて投入するし)

iOS→「プロトコル指向プログラミング」「RxSwift」、Android→「RxJava」辺りのキーワードでググってみて。

別に皮肉とか宗教戦争で煽ってるわけじゃなくて、自分も苦労して辿りついた口だから、今から始める人には遠回りして、余計な苦労を味わって欲しくない。

 

(追記 その3)

他の人が書いてたけど、1人でプログラミングするんじゃなくて、2人(ペアプログラミング)や3人以上(モブプログラミングから始めたら良いかも。

Googleの「プロジェクトアリストテレス」で、仕事生産性改善するには「心理的安全性」が重要と分かり、プログラミング仕事もやり方が変わって来ています

ソニックガーデン倉貫さんの働き方が参考になると思います

https://kuranuki.sonicgarden.jp/2017/01/psychological-safety.html

 

(追記 その4)

記事が消えていたのでバックアップしておきます。(この投稿だけ読むと意味が分からなくなるため)

https://anond.hatelabo.jp/20170910205249

2017-09-10

■知り合いをプログラマにさせたいんだけど知恵を貸してくれ

プログラマって育休からの復帰しやすいだろうし、アルバイトよりは待遇いいし、勤怠ゆるいし、労力の割に楽ちんだと思うんだよね。

接客バイトで消耗するくらいなら、プログラマになればいいと思っているのだが、その知り合いは自身のことをプログラミングを不向きと評価しているらしい。私は、プログラミングに限らず物事時間をかければ習熟していくものだと思っているので、不向きではないと思うんだ。不向きというのは物理的に制限のある時だと思う。

その知り合いについて。

Vimはぎこちないけど使える。日常的にmacOSを使っていてターミナル操作はできている。cd, ls あたりは理解している。

趣味を含めてアプリケーションを完成させた経験はないが、ifやfor文などの基本構文は理解している。数年前にプログラミングスクールのようなところに半年間通っていた。その後受託系の会社就職できたのだけど、人間関係がうまくいかなかったようで数ヶ月で辞めた。鬱病気味になったみたい...。

何か成功体験があれば自然とのめり込んでと思うんだけどなかなかスイッチが入っていないみたい。

こちら側からは、プログラマーになれば?と直接は伝えてはなくて、素人でもプログラミングできましたみたいなネット記事シェアーしているくらい。(心理的リアクタンス避け)

知恵を貸して欲しい。

2016-07-24

ヘルプミー。プログラマ

プログラム書くときって、「Aがしたい」っていう考えから始まると思ってるんですけど、

なんで「Aを行うHogeClientってクラスを作って、次に....」ってする人間がいるんですか?

シンプルに考えるとクラス作らなくてよかないですか?

モジュールで良くないですか?

Simulaとビャーネ、Smalltalkアランが居ない世界にいたかった。

追記

SchemeとCしてました。OCaml齧ります

2016-05-25

http://anond.hatelabo.jp/20160525213232

バグがあって、ストリームに変な値が入った時、どこがバグなのか、追跡するのが困難でしょ?

第一に、それは、ストリームFRPの値の定義)の問題であって、ユニットテストすれば良い。もしくは単にFRPログを取れば良い。

グローバル変数ではそういうことはできない。FRPでは、岡部氏のFRPライブラリ特にそうだけど、基本的ミュータブルな値同士が関数リアクティブ連携されて常に整合性を保っているのだからグローバル変数の、各所で更新されたそれぞれの値によって全体の整合性が損なわれないように気を配らなければいけないという(テスト自体困難な)問題は発生しない。それがFRPの唯一とも言えるメリットだとも言える。

使用する関数問題じゃないし、「印」として引数に加えても別に構わないと思うが、君のいうグローバル変数問題と一緒というのはまったく違う。

岡部氏との争いって「OCamlGUIアプリ純粋関数型(状態渡し)で簡潔に書けるか」ってところじゃないよね?

いや、それがそもそもの発端であるブログの経緯には書かれている。説明されている方式GUIアプリまで書けるのか?と疑念が呈されたことがきっかけ。

岡部氏はFRP状態関数の外部に持ってても純粋関数型だ、と言ってて、そこで争ってるんだよね?

この論点は聞いたことがない。岡部氏がこだわっているのは非手続き型の宣言型で、純粋がどうとか議論はされてないように思う。

あと、OCamlGUI状態渡しで書いたら簡潔で無いのを「書けない」、「不可能」って言ってるのはわざと印象操作しようとしてるよね?

原理的に可能かという議論ではなく、実用的な範疇か?という議論。反対派ブログで出てきたコードは、本人が認めるように普通のやり方ではなく、実用的なコードだとは思えない。あと、FRP状態渡しは同じ複雑さだという主張も崩されている。そこが重要

Haskellで書けて、OCaml冗長になっても、書けるなら「書ける」、「可能」だよね?

段階を踏んだ上で、非FRPHaskellのIOモナドコードを誰かが書いたらいんじゃない?当面、最初OCamlの話だったのに、いきなりHaskellやElmのコードで書いて、そういうのがごちゃまぜに、何がどの言語でできるのかできないのか、誤魔化しがあると見做されたか制限されたんでしょ。実際には、OCaml関数型では冗長しか書けないと実証されたけど、そういうのがバレないように、別の言語を利用していたと看破されて当然の状況だと俺は思うね。

俺の書き込み他人といきなり結び付けられたから、電波だな、と思ったの。

俺1人か、とか、らくだや住井が含まれてない根拠とか、関係無いよね。

関係ある。君ひとりは、そうじゃない、と君ひとりが言ってもそれが本当だとは確認のしようがないし、

書き込みをみれば、君以外の書き込みもすべて、その一派ではない、とでも言いたそうだ。

http://anond.hatelabo.jp/20160525202812

否。ストリームに限らず、定数は引数で与えなくても純粋関数である、という見解はごく普通

定数って、プログラム中で更新不可能で、いつ読みだしても同じ値が出てくるからグローバルでも問題無いんだよ。

ストリームは定数だ、って言ってみたところで、プログラム全体から更新可能なんじゃ、グローバル変数と同じでしょ?

バグがあって、ストリームに変な値が入った時、どこがバグなのか、追跡するのが困難でしょ?

なんで伝わらないんだろ。

複数人プログラム開発したり、他人プログラムデバッグしたり、したこと無いんだろうか。

まりGUIになればもはや関数型では書けない、というのが推奨スタイルだ、って言ってるようなもの

純粋関数型」とは何か、という話と、とOCamlでそれが推奨スタイルか、って別の話だよね?

岡部氏との争いって「OCamlGUIアプリ純粋関数型(状態渡し)で簡潔に書けるか」ってところじゃないよね?

純粋関数型とは何かといった時にHaskellのように、IOも含めて引数戻り値表現する、関数のふるまいが関数の外の状態依存しない、関数副作用が伴わないとかの性質をいうと思うんだけど、岡部氏はFRP状態関数の外部に持ってても純粋関数型だ、と言ってて、そこで争ってるんだよね?

あと、OCamlGUI状態渡しで書いたら簡潔で無いのを「書けない」、「不可能」って言ってるのはわざと印象操作しようとしてるよね?

Haskellで書けて、OCaml冗長になっても、書けるなら「書ける」、「可能」だよね?

その発言事実か確かめる術はないし、ここで岡部攻撃しているのは君ひとりなのか?他の人間まで一連の誹謗中傷集団ではない、す駱駝、住井が含まれていないみたいに断言する根拠は何か?

俺の書き込み他人といきなり結び付けられたから、電波だな、と思ったの。

俺1人か、とか、らくだや住井が含まれてない根拠とか、関係無いよね。

http://anond.hatelabo.jp/20160525104221

ストリーム関数の外部に持つFRP純粋関数型っていうのは少数派でしょ。

否。ストリームに限らず、定数は引数で与えなくても純粋関数である、という見解はごく普通

http://stackoverflow.com/questions/37405262/is-this-pure-functional-using-a-value-in-the-nested-closure-like-function/37405374

OCamlの元々の推奨スタイルならもっと短く書けるんでしょ?

まりGUIになればもはや関数型では書けない、というのが推奨スタイルだ、って言ってるようなもので、OCamlベースいくら関数型の講義やっても、最終的にはその関数型でまともなGUIアプリすら書けない、という批判でしょ。その批判岡部からされたら、あたか関数型で書ける、という強弁からまれたのが「状態渡し」理論。それが無理筋だ、ということが今回実証された。

だって駱駝でも住井でもない面識も無い俺の書き込みが住井扱いされるんだもの

その発言事実か確かめる術はないし、ここで岡部攻撃しているのは君ひとりなのか?他の人間まで一連の誹謗中傷集団ではない、す駱駝、住井が含まれていないみたいに断言する根拠は何か?

いやだからグローバル変数使ってるプログラム欠点をそのまま持ってるじゃん

あのね、グローバル変数欠点とは、それが「変数」だからなの。

何度も言うけど、「定数」ならグローバルだろうがなんであろうが、そんな欠点なんてないの。

http://anond.hatelabo.jp/20160524164501

関数型という枠組みの中にミュータブルな時間要素が純粋に収まるようにしているのがFRPだろ。

ストリーム関数の外部に持つFRP純粋関数型っていうのは少数派でしょ。

関数の結果が引数以外で決まるわけだからさ。

多分、純粋とかの定義もまた違うんだろうね。

関数型の拡張」で全部丸く収まると思うんだけど。

いやそもそも岡部氏が複雑なアプリになるとFRP必要

これはGUIアプリ(対話的なアプリ)ってことでいいのかな。

コンパイラだとかをFRPで書かないでしょ。

ユーザから入力リアルタイムに処理するプログラムにはFRP有効だよね。

事実、「駱駝」は「状態渡しはむしろ異常」って書いた上に、

OCamlでは」じゃないの?

全部純粋関数型(引数戻り値に収める、状態渡し)にするのを良しとするHaskellと違って、OCaml副作用部分的に使うのが普通で、IOモナドみたいな入出力までも純粋に書くための道具立てが揃ってない、それでちょっと冗長になる、ってことでしょ?

OCamlの元々の推奨スタイルならもっと短く書けるんでしょ?

俺はそう読んだけど。

それっぽい書き込みほどそうやって、事実誤認だ、と強調するから、なんで当事者でもないのに、そんなことが断言できて、電波だということになるんだ?

だって駱駝でも住井でもない面識も無い俺の書き込みが住井扱いされるんだもの

いやだから、どの関数で読み書きされようと、誰が書き換えようとも、時間にたいしてイミュータブルな定数なんだから、定数は定数なのよ。

いやだからグローバル変数使ってるプログラム欠点をそのまま持ってるじゃん

グローバル変数使ってるプログラム欠点説明する必要ある?

2016-05-24

http://anond.hatelabo.jp/20160523093706

なにこれ?本人?

10年前にOCaml関数型じゃない破壊的代入の命令コード書いたってこと?

http://anond.hatelabo.jp/20160523164755

一応、要求通りに新しい課題OCamlコード書く

http://okaml.blogspot.jp/2016/05/done2.html#more

 ↓

kenokabe氏に、

OCaml関数状態渡し : 74行

JavaScript+React+TimeEngineのFRP : 29行

kenokabe氏のFRPじゃ半分以下のコード実装できたと、トドメをさされて終了

http://kenokabe-techwriting.blogspot.jp/2016/05/frptimeenginereactjsocaml.html

結果、kenokabe氏の圧勝かな、おもしろかったです!

2016-05-21

http://anond.hatelabo.jp/20160302090242

http://kenokabe-techwriting.blogspot.jp/2016/05/timeengine.html

nonstarterの言うことがハッタリじゃなければ、さっさとToDoListの課題Ocaml関数型の状態渡しをもって実装してみせればいいだけだが、言い訳始めてるからな。

もちろん、OCamlであれHaskellであれ破壊的代入の類の副作用使用せずに書くのもなんら困難ではありません。

nonstarterはこの発言の時点では、Ocaml関数型の状態渡しに限界があることはお首にもだしていない。読んだものはそうだったのか、何でもできると思って不思議ではないだろう。

しかしなぜか、Haskellが急に登場する。別の言語の助けを求め始めた最初がここ。

そのうち、OCaml実際的環境じゃスケールしないという指摘がはいる。

nonstarterは、複雑性への限界を認めるが、同時に、FRPの足をひっぱることも忘れ得なかった。つまり「負けてない!」ってことなんだろw

しばらく有耶無耶にされていたが、お絵かきアプリもまだ書けないといか書かれているのを目撃した岡部氏が、すでに実装していた自作FRPライブラリお絵かきアプリを示して、

ついでに、ハードルを引き上げた。

nonstarterの言うとおり、

もちろん、OCamlであれHaskellであれ破壊的代入の類の副作用使用せずに書くのもなんら困難ではありません。

かつ、FRPも同じ複雑さへの限界ならば、

岡部氏が示したFRPコードと同等のかんたんさで、OCamlでも出せるはずだ。

もちろん、他のHaskellFRPは使うな、という至極当然の縛りつき。

ちょっと本気出されたら、言い訳始めた、それが今。

http://anond.hatelabo.jp/20160520153948

OCamlでは」普通に副作用を使うライブラリしかいかスケールしない、って書いてあるのに

なんで勝手一般化して、Haskellとかでもスケールしないことにしたいの? 本当に牽強付会オンパレードですね。

そもそもの最初がesumiiやlambadaなどのOCamlユーザへむけての課題で、

nonstarterが、

もちろん、OCamlであれHaskellであれ破壊的代入の類の副作用使用せずに書くのもなんら困難ではありません。

と急に何故かいきなりHaskellを持ち出し、Haskellコードを引っ張り出した。

いろいろとっちらかしてんじゃねーよ、ってことだろ。

OCamlではライブラリも足りず机上の空論だったという、ひとつ区切りはついた。

もちろん、OCamlであれHaskellであれ破壊的代入の類の副作用使用せずに書くのもなんら困難ではありません。

とこの点について「一般化」を試みた、誤魔化そうとしたのは、nonstarterだ。

からごましてんじゃねーよ、ってそこをまず明確化されている。

2016-05-20

http://anond.hatelabo.jp/20160520061937

http://kenokabe-techwriting.blogspot.jp/2016/05/timeengine.html

nonstarterの言うことがハッタリじゃなければ、さっさとToDoListの課題Ocaml関数型の状態渡しをもって実装してみせればいいだけだが、言い訳始めてるからな。

もちろん、OCamlであれHaskellであれ破壊的代入の類の副作用使用せずに書くのもなんら困難ではありません。

nonstarterはこの発言の時点では、Ocaml関数型の状態渡しに限界があることはお首にもだしていない。読んだものはそうだったのか、何でもできると思って不思議ではないだろう。

しかしなぜか、Haskellが急に登場する。別の言語の助けを求め始めた最初がここ。

そのうち、OCaml実際的環境じゃスケールしないという指摘がはいる。

nonstarterは、複雑性への限界を認めるが、同時に、FRPの足をひっぱることも忘れ得なかった。つまり「負けてない!」ってことなんだろw

しばらく有耶無耶にされていたが、お絵かきアプリもまだ書けないといか書かれているのを目撃した岡部氏が、すでに実装していた自作FRPライブラリお絵かきアプリを示して、

ついでに、ハードルを引き上げた。

nonstarterの言うとおり、

もちろん、OCamlであれHaskellであれ破壊的代入の類の副作用使用せずに書くのもなんら困難ではありません。

かつ、FRPも同じ複雑さへの限界ならば、

岡部氏が示したFRPコードと同等のかんたんさで、OCamlでも出せるはずだ。

もちろん、他のHaskellFRPは使うな、という至極当然の縛りつき。

ちょっと本気出されたら、言い訳始めた、それが今。

http://anond.hatelabo.jp/20160520153948

OCamlでは」普通に副作用を使うライブラリしかいかスケールしない、って書いてあるのに

なんで勝手一般化して、Haskellとかでもスケールしないことにしたいの? 本当に牽強付会オンパレードですね。

そもそもの最初がesumiiやlambadaなどのOCamlユーザへむけての課題で、

nonstarterが、

もちろん、OCamlであれHaskellであれ破壊的代入の類の副作用使用せずに書くのもなんら困難ではありません。

と急に何故かいきなりHaskellを持ち出し、Haskellコードを引っ張り出した。

いろいろとっちらかしてんじゃねーよ、ってことだろ。

OCamlではライブラリも足りず机上の空論だったという、ひとつ区切りはついた。

もちろん、OCamlであれHaskellであれ破壊的代入の類の副作用使用せずに書くのもなんら困難ではありません。

とこの点について「一般化」を試みた、誤魔化そうとしたのは、nonstarterだ。

からごましてんじゃねーよ、ってそこをまず明確化されている。

http://anond.hatelabo.jp/20160520153948

もちろん、OCamlであれHaskellであれ破壊的代入の類の副作用使用せずに書くのもなんら困難ではありません。

nonstarterはこの発言の時点では、Ocaml関数型の状態渡しに限界があることはお首にもだしていない。読んだものはそうだったのか、何でもできると思って不思議ではないだろう。

しかしなぜか、Haskellが急に登場する。別の言語の助けを求め始めた最初がここ。

そのうち、OCaml実際的環境じゃスケールしないという指摘がはいる。

nonstarterは、複雑性への限界を認めるが、同時に、FRPの足をひっぱることも忘れ得なかった。つまり「負けてない!」ってことなんだろw

しばらく有耶無耶にされていたが、お絵かきアプリもまだ書けないといか書かれているのを目撃した岡部氏が、すでに実装していた自作FRPライブラリお絵かきアプリを示して、

ついでに、ハードルを引き上げた。

nonstarterの言うとおり、

もちろん、OCamlであれHaskellであれ破壊的代入の類の副作用使用せずに書くのもなんら困難ではありません。

かつ、FRPも同じ複雑さへの限界ならば、

岡部氏が示したFRPコードと同等のかんたんさで、OCamlでも出せるはずだ。

もちろん、他のHaskellFRPは使うな、という至極当然の縛りつき。

ちょっと本気出されたら、言い訳始めた、それが今。

http://anond.hatelabo.jp/20160520153948

http://anond.hatelabo.jp/20160520153948

nonstarterのいうことが嘘ハッタリじゃないのならば、さっさとOCaml関数状態渡しでToDoリストアプリ書いて見せればいいだけ。

出来ない時点で終わってる。

もちろん、OCamlであれHaskellであれ破壊的代入の類の副作用使用せずに書くのもなんら困難ではありません。

nonstarterはこの発言の時点では、Ocaml関数型の状態渡しに限界があることはお首にもだしていない。読んだものはそうだったのか、何でもできると思って不思議ではないだろう。

しかしなぜか、Haskellが急に登場する。別の言語の助けを求め始めた最初がここ。

そのうち、OCaml実際的環境じゃスケールしないという指摘がはいる。

nonstarterは、複雑性への限界を認めるが、同時に、FRPの足をひっぱることも忘れ得なかった。つまり「負けてない!」ってことなんだろw

しばらく有耶無耶にされていたが、お絵かきアプリもまだ書けないといか書かれているのを目撃した岡部氏が、すでに実装していた自作FRPライブラリお絵かきアプリを示して、

ついでに、ハードルを引き上げた。

nonstarterの言うとおり、

もちろん、OCamlであれHaskellであれ破壊的代入の類の副作用使用せずに書くのもなんら困難ではありません。

かつ、FRPも同じ複雑さへの限界ならば、

岡部氏が示したFRPコードと同等のかんたんさで、OCamlでも出せるはずだ。

もちろん、他のHaskellFRPは使うな、という至極当然の縛りつき。

ちょっと本気出されたら、言い訳始めた、それが今。

そもそもの最初がesumiiやlambadaなどのOCamlユーザへむけての課題で、

nonstarterが、

もちろん、OCamlであれHaskellであれ破壊的代入の類の副作用使用せずに書くのもなんら困難ではありません。

と急に何故かいきなりHaskellを持ち出し、Haskellコードを引っ張り出した。

いろいろとっちらかしてんじゃねーよ、ってことだろ。

OCamlではライブラリも足りず机上の空論だったという、ひとつ区切りはついた。

もちろん、OCamlであれHaskellであれ破壊的代入の類の副作用使用せずに書くのもなんら困難ではありません。

とこの点について「一般化」を試みた、誤魔化そうとしたのは、nonstarterだ。

からごましてんじゃねーよ、ってそこをまず明確化されている。

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