「OCaml」を含む日記 RSS

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

2017-10-26

プログラマーのススメ

日本人は全員プログラミング勉強した方が良い。

プログラミング簡単だし、IT企業なら開業資金も少額で済む。(最初パソコン回線プリンターがあれば十分)

 

自己資金で数カ月で軌道に載せれるようなネタしかできない。

 

IT起業の道のりを教えてあげるよ。

  1. 下請け他人が作って欲しいものを作って納品する=資金を増やす自転車操業の段階。
  2. 自社開発:自分で作りたいものを作って売る=自転車操業からストックビジネスに移行する。
  3. レベニューシェア下請けと自社開発の中間ビジネスモデル

 

増田投稿できるってことは、パソコンぐらい持ってるんだろ?

本屋図書館に行って、自分に合った分かりやすプログラミングの本を探してみよう。

 

仕事を取ってくる方法は、ソニックガーデンのやり方を参考にしたら良い。 https://www.sonicgarden.jp/

プログラミング入門

最初に1冊だけ推薦するなら「プログラミングの基礎」という本をお勧めする。 https://www.amazon.co.jp/dp/4781911609/

買う前に、著者のサポートページを見てみると良い。

 

プログラミングパラダイム(考え方)には4種類ある。(【】内は基礎となる計算モデル

計算可能理論で見ると、どれもノイマン型のCPU上で動作する点で同じと言えば同じと言える。(優劣はない)

ただ、筋の良いプログラミング作法を身に付けたいなら、最初関数型を理解しておくことをお勧めする。

関数型の中で一番簡潔かつ強力なのはOCaml」というプログラミング言語だ。(HaskellをやりたければOCamlの次に学ぶスムーズ理解できる。)

関数型言語を学んだ後なら、手続言語はすぐに習得できるだろう。

WEB開発

WebサービスWebアプリを作るのは簡単

  1. HTML
  2. CSS
  3. JavaScript
  4. PHP
  5. MySQL
  6. Linuxサーバー構築)
  7. TCP/IPネットワークセキュリティーの基礎知識

を学べば作れるようになる。3か月勉強すればものになるよ?

 

Webアプリの特徴は、システム構造ネットワークを介して「サーバー側とクライアント側」に分割されていること。(REST - Wikipedia

Webアプリを作るってことは、一言で言えば、データベースラッパーCRUD)を作るだけの話。

アプリ開発

スマホアプリは、GUIの仕組みが分かれば簡単に作れる。

iPhoneアプリ

iPhoneの仕組みは糞だから後回しにしてもOK

XcodeじゃなくてAppCodeで作れるような段階に成熟したら手を出しても良い。

まあ、iPhoneアプリは金のためなら避けられない道だと思うので、苦労覚悟で取り組んでほしいw

Androidアプリ

Androidの中身はLinuxJavaアプリを開発できる。今ならJetBrainsIDEKotlinで楽々開発できる。

日本じゃAndroid貧乏しか使ってないので、あまり金にならないかも。

資金集め

お前偉そうなこと言うのなら、誰か起業してやろうというやつにガッツリ寄り添って手伝ってやりな。

俺はハゲタカじゃないから、無知な奴から搾取することはしない。

というか、自分のことで精一杯だから他人のケツ拭いまでやる体力・気力・理由がないw

 

他人から金をもらうと相手支配下に置かれる。だから資金調達お勧めしない。

自己資金で行けるところまで行って、ダメならまた社畜生活に戻ればいいだけの話。(パソコンインターネットがなくならない限り、プログラマーならIT業界で食っていける)

 

俺は、NPO法人とか社会起業しようとしてる奴だけ無償で手助けすることにしている。(プロボノ

社会起業家は、社会変革の担い手として、社会課題を、事業により解決する人のことを言う。

社会問題認識し、社会変革を起こすために、ベンチャー企業創造組織化経営するために、起業という手法を採るものを指す。

プロボノ(Pro bono)は、各分野の専門家が、職業上持っている知識スキル経験を活かして社会貢献するボランティア活動全般。また、それに参加する専門家自身

 

おまえが将来、社会起業することがあったら増田で呼びかけてくれ。

増田で返答できる範囲アドバイスするよ。頑張れ!

 

(追記)プログラミングパラダイムの4分類は「日経ソフトウェア」という雑誌説明表記しました。

ちなみにSQLチューリング完全なので、問合型言語でもプログラミング可能です。 https://qiita.com/utgwkk/items/20e887645da18e460fee

かに俺は理系だが情報学出身じゃない。独学でプログラミングを学びました。技術的な誤りがあったらブコメで教えてw(夜露死苦

 

(追記2)マイクロソフト関数型言語F#」は、OCamlベースにして開発されました。

現在マイクロソフトで開発中の量子コンピューターではF#が動く予定だそうです。(将来OCaml知識が役に立つでしょう) http://ascii.jp/elem/000/001/569/1569477/

 

(追記3 10/28ブコメレス全部拝見しました。様々なご意見・ご指摘をいただきありがとうございます。大変参考になりました。

「何か既視感があるな」と思ったら、最近ホリエモンが「保育士は誰でも出来る仕事」と言って炎上してたのと似てますね?→「プログラミング簡単」(プログラマーは誰でも出来る仕事

プログラミング学習や実務で苦戦されている方が多いようですね? だとすれば、それを改善支援するサービスニーズがありそう。

具体的にはディアゴスティーニ雑誌みたいに「週刊 プログラミングゲームを作る」みたいな教材があればいい。

https://deagostini.jp/

拝承いたしました。(微力ながら、皆様のお役に立てるよう作ってみたいと思います。)

 

(追記4 10/28OCaml関数型言語メリットについて

ちょっと前に岡部健氏(通称:毛の壁、kenokabe)が、関数型言語を巡りQiita等で論争を巻き起こしていましたが、俺は是々非々岡部氏の意見に一部賛同していました。(全部じゃない)

関数型言語を難しいものとして敬遠するのではなく、まずは使ってみて便利だったら嫌う必要はないと考えています

構造プログラミング命令型、手続型)との対応で言えば、関数型プログラミングは再代入なしでも、

で同じことができます。(優劣はない)

最初関数型プログラミング習得しておけば、参照透過性に注意を払う癖が身につき、テストときに「組合せ爆発」を少なくできます

関数型言語はたくさんありますが、OCamlが良いと思ったのは(自分にとって)分かりやすい教材が揃っており、学習コストが低いと思ったからです。

プログラミングを学ぶとき、独学ではなく、周りに聞ける人がいるなら他の言語でもOKです。

 

(追記5 10/28)「iPhoneの仕組みは糞」=storyboardが使いづらいと思いました。あくま個人の感想なので、Apple関係者信者の方はスルーしていただければ幸甚です。(Swift開発者クリスラットナー氏は、Appleからテスラ転職してしまいましたが、今後もAppleObjective-CからSwiftへの移行を押すのでしょうか?)

幸いiOSアプリ開発は分かりやす教科書がたくさんあるので、初心者でも心配無用です。iOSアプリ開発は(最初簡単なので)気軽に始めてみてくださいw

2017-10-23

OCAML FOR WINDOWS

Windows用のOCamlインストーラーがあった。

https://fdopen.github.io/opam-repository-mingw/installation/

これを使ったらダブルクリック後、OK連打的な操作で行けた。

デスクトップに「OCaml64」というアイコンが現れた。

これをダブルクリックして開き、「ocaml」というコマンドを打つ。

OCaml version 4.05.0

バージョンが表示されて、コマンドプロンプトが「$」から「#」に変わった。

テスト

「# 3 + 3 ;;」と入力したら、「- : int = 6」と返ってきた。

とりあえず、OCamlの実行環境が用意できた!(めでたし、めでたし)

WindowsにOCamlをインストールする方法

OCaml練習しようと思って、Windowsインストールしようと思ったら、何か面倒くさい方法が紹介されていた。

OCamlって、Windows用のインストーラー(ワンクリックで入る奴)がないみたいですね?

OCamlを使うなら、LinuxmacOSでやったほうが良いとのこと。

 

OCaml流行らない理由が分かったような気がする。。。

 

…と言って終わらせる訳にもいかないので、頑張ってインストールしてみよう。

Cygwinを用意するのと、仮想マシン上にLinux用意するのと、どっちが楽なんだろ?

[][] OCaml学習

今日からOCamlの勉強を始めます。

教科書は「プログラミングの基礎」という本です。

https://www.amazon.co.jp/dp/4781911609/

という点がメリットかな?

暇な人は、一緒に勉強しましょう!

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だ。

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

http://anond.hatelabo.jp/20160520153456

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

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

http://qiita.com/nonstarter/items/2763f5d85f2b8df3b18b#comment-d9a8cdf2efc67044c158

OCaml の全ての GUI ライブラリ状態副作用を使うことを前提にメインループ設計されているからです。これを乗り越えるとすると @Lambada さんのようにメインループ自体自分で書く事になり、一般的にはスケールしません。HaskellGUI ライブラリでは普通状態State なり IO を含む GUI モナドを使って書く事になりますが、そのような GUI ライブラリOCaml 上で作れば同じような事が出来るはずです。OCaml でそこまで純粋関数型のコードを書く事に実用意味があるとは思えませんが。

http://anond.hatelabo.jp/20160520152852

あのさ、それ

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

とか、言い切って、別の人間からスケールしない、とつっこまれた後だから

最初の時点で「限界がある」と自覚しているのに、学習者や読者にむかって何も言わない隠し玉してたのか、

本気で何でもできると思ってたのかまでは不明

いずれにせよ、突っ込まれて自ら限界を認めた。ついでにFRP限界も同じに設定したっぽい。

岡部氏は、これは誤魔化しだとして、FRPで書いたコード提示し、

同じもの状態渡しでかけと要求

限界値」が同じならば、振り落とされずに書けるはずだが、無理っぽい。つまりnonstarterの主張は嘘で誤り。

http://anond.hatelabo.jp/20160518170332

これのどこをどう読んだら「状態渡しはスケールしない」になるんだ……

ひょっとして状態渡しをモナド化したのがStateとか、基本的なことを全く理解していない?

http://qiita.com/nonstarter/items/2763f5d85f2b8df3b18b#comment-d9a8cdf2efc67044c158

OCaml の全ての GUI ライブラリ状態副作用を使うことを前提にメインループ設計されているからです。これを乗り越えるとすると @Lambada さんのようにメインループ自体自分で書く事になり、一般的にはスケールしません。HaskellGUI ライブラリでは普通状態State なり IO を含む GUI モナドを使って書く事になりますが、そのような GUI ライブラリOCaml 上で作れば同じような事が出来るはずです。OCaml でそこまで純粋関数型のコードを書く事に実用意味があるとは思えませんが。」

http://anond.hatelabo.jp/20160519142942

状態渡し派」なんてレッテル張り典型的詭弁藁人形論法)。

誰も状態渡しで何でも簡単に書けるなんて言ってないし、状態渡しで書くべきとも言ってない。

お絵かきアプリ」には自称FRP絶対必要、という明らかに誤った主張に対する反例として

nonstarter他が「状態渡し」を挙げただけ。

それなのにHaskellから認めないとか、OCamlでも簡単だったから認めないとか……

自分で「FRP必要」と断言して挙げた例題なのに。

2016-05-19

http://anond.hatelabo.jp/20160518171946

何度も指摘されているが「岡部氏のFRP」は同じメンバ変数tに何度も値を上書きしてるだけの

FRP以前に関数型でもない普通命令プログラムいくら論文曲解したり哲学とか言い訳しても

客観的には単なるメンバ変数への破壊的代入。オブジェクトconstをつけたところで

メンバ変数constにはならない。

 

じゃあOCaml純粋関数型や(本当の)FRPで複雑なGUIアプリが書けるかと言うと、

理論的には不可能ではないかもしれんが、もともと非純粋なので

誰もそういうライブラリを整備してないから、ライブラリから作るのは

まあ面倒だろうし、わざわざ非純粋関数型言語純粋関数型のGUIを作る動機

現時点ではまずないだろう。これもすでに指摘されているとおり。

 

もっとも「岡部氏」は「お絵かきアプリ」も「FRP実装が必ず必要となります。」と自分ブログで断言し、

その反例としてOCamlやらHaskellやらのコード直ちに書かれた以上、また話を逸らすのも大概ではある。

2016-05-16

http://anond.hatelabo.jp/20160515231526

出たでたw まーた駱駝の「すぱげってぃこーど」

まーた、「FRPライブラリ実装」にイチャモンつける大バカ

馬鹿質問だが、OCamlソースコードって、純粋関数型で実装されてんの?

HaskellC++ソースコードって純粋関数型なの?って話なんだが、すっこんでろよキチガイ

2016-04-04

30歳をすぎてからプログラミング学習価値はあるのか

現在無職歴5年33資格なし

生活保護障害者年金精神二級)に頼った生活から抜け出したいがどこからも雇ってもらえそうにない

宝くじでも当てるか起業するくらいしか手は無いと思うのだが、現実的なのは後者だろう

というわけでプログラミングの本など読んでは寝る日々

二年くらい触ってないノートパソコンが部屋のどこかにあるので鬱が改善したら引っ張り出して電源をいれてみようと思う

読んでる本が扱っている言語Ruby, JAVA, C++, scheme, OCamlなどだが、確かPythonの本も部屋を探せば見つかるはず

しかし本で扱っているプログラミングの基礎と起業との間が果てしなさ過ぎてとてもではないが現実的とは思えない

結局なにも成し遂げられず生活保護が打ち切られる恐怖に怯えながら細々と生活していくしかないのだろう

はてブをやっている有象無象一家言ある人々は本職じゃなくてもひとつくらいプログラミング言語に習熟しているものと聞くが、いったいどういう動機学習したのだろうか

わたしのような人間が生きるための手段としてプログラミング言語学習することをどう思うだろうか

2016-03-19

http://anond.hatelabo.jp/20160318091757

ああQiitaに出没してるスパゲッティコードと気炎吐くだけの駱駝さんね・・・

timeengineのソースコードはそのサイトにあるように200行以下にまとめられている簡潔なコードだけど、どこがどうスパゲッティになってるのか「おまえが理解できない」という以外のきちんとした理由でどうぞ?まあリファクタリングしろっつってもOCamlしか書けないんだろうし土台無理だろうけど。「お絵かきロジック」にするためには、マウスイベントとTimeengineそのまま接続したら良い、超簡単のはライブラリ特性として見りゃわかるが、それすら理解できないやつが何いってんだよw

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん