はてなキーワード: OCamlとは
「OCamlでは」普通に副作用を使うライブラリしかないからスケールしない、って書いてあるのに
なんで勝手に一般化して、Haskellとかでもスケールしないことにしたいの? 本当に牽強付会のオンパレードですね。
http://qiita.com/nonstarter/items/2763f5d85f2b8df3b18b#comment-d9a8cdf2efc67044c158
>OCaml の全ての GUI ライブラリは状態は副作用を使うことを前提にメインループが設計されているからです。これを乗り越えるとすると @Lambada さんのようにメインループ自体を自分で書く事になり、一般的にはスケールしません。Haskell の GUI ライブラリでは普通は状態は State なり IO を含む GUI モナドを使って書く事になりますが、そのような GUI ライブラリを OCaml 上で作れば同じような事が出来るはずです。OCaml でそこまで純粋関数型のコードを書く事に実用的意味があるとは思えませんが。
あのさ、それ
とか、言い切って、別の人間からスケールしない、とつっこまれた後だから。
最初の時点で「限界がある」と自覚しているのに、学習者や読者にむかって何も言わない隠し玉してたのか、
本気で何でもできると思ってたのかまでは不明。
いずれにせよ、突っ込まれて自ら限界を認めた。ついでにFRPの限界も同じに設定したっぽい。
これのどこをどう読んだら「状態渡しはスケールしない」になるんだ……
ひょっとして状態渡しをモナド化したのがStateとか、基本的なことを全く理解していない?
http://qiita.com/nonstarter/items/2763f5d85f2b8df3b18b#comment-d9a8cdf2efc67044c158
「OCaml の全ての GUI ライブラリは状態は副作用を使うことを前提にメインループが設計されているからです。これを乗り越えるとすると @Lambada さんのようにメインループ自体を自分で書く事になり、一般的にはスケールしません。Haskell の GUI ライブラリでは普通は状態は State なり IO を含む GUI モナドを使って書く事になりますが、そのような GUI ライブラリを OCaml 上で作れば同じような事が出来るはずです。OCaml でそこまで純粋関数型のコードを書く事に実用的意味があるとは思えませんが。」
何度も指摘されているが「岡部氏のFRP」は同じメンバ変数tに何度も値を上書きしてるだけの
FRP以前に関数型でもない普通の命令型プログラム。いくら論文を曲解したり哲学とか言い訳しても
客観的には単なるメンバ変数への破壊的代入。オブジェクトにconstをつけたところで
じゃあOCamlで純粋関数型や(本当の)FRPで複雑なGUIアプリが書けるかと言うと、
誰もそういうライブラリを整備してないから、ライブラリから作るのは
まあ面倒だろうし、わざわざ非純粋関数型言語で純粋関数型のGUIを作る動機も
現時点ではまずないだろう。これもすでに指摘されているとおり。
ああQiitaに出没してるスパゲッティコードと気炎吐くだけの駱駝さんね・・・
timeengineのソースコードはそのサイトにあるように200行以下にまとめられている簡潔なコードだけど、どこがどうスパゲッティになってるのか「おまえが理解できない」という以外のきちんとした理由でどうぞ?まあリファクタリングしろっつってもOCamlしか書けないんだろうし土台無理だろうけど。「お絵かきロジック」にするためには、マウスイベントとTimeengineそのまま接続したら良い、超簡単のはライブラリの特性として見りゃわかるが、それすら理解できないやつが何いってんだよw
第一に、発端となった元ツイートには「非エンジニア新卒女子」とはっきり書いてあるのに
《旧式言語を学ばずに関数型言語一本槍でエキスパートを目指すような感じの方》
《「まず軽く触れてみよう」とか「趣味でやってみるか」といった程度ならいいのですが》
《実際には肝心なことを何も知らないのに、なんか知っていると思い込んでいる状態が、私いわく「脳味噌膿んでる」》
ひどい書きっぷりだよね。
もし自分が当事者だったら「見ず知らずの人になんでここまで言われなきゃいけないの」と傷つくと思う。
第二に、下位層のレイヤーについて知っていなければ上位層のことをちゃんとやる資格がない
という態度が明らかに本人のダブルスタンダードっぷりを示している点
と言いたいのだと思うけど、最近のCPUはマシン語に書かれていある命令をそのまま実行しない。
インテルの場合もCISCの命令セットで記述されたコードをRISC的なマイクロコードに分解・解釈して実行する。
さらに内部はパイプライン化されているため、単純に「1命令ずつ逐次実行」されてもいない。
外側から観察するとあたかもマシン語の命令列をひとつずつ逐次実行しているかのように振る舞っているだけだ。
マシン語のコードで記述されたプログラムが、命令通り入力と出力を繰り返すなら、内部でどのような先読みや予測分岐を繰り返していても問題ない?マシン語の忠実な実行装置とみなしてよい?もちろん回路の設計ミスで誤動作するかも知れないけど、それがプログラマの「根本的な過ち」になる?
OCamlの世界で記述されているロジックが、OCamlの仕様通りにちゃんと動作すれば、その下位層にあるマシン語がどういうパラダイムで記述されていても関係ないと考えていいと俺は思う。
余談1
くだんの女子について、周辺のツイートを見てみると(完全に部外者の憶測だけど)Railsを主力とするソフトウェア企業に非エンジニアとして新卒で入社した新人がプログラミングに興味を持ったのに対して上司がOCamlの本を教科書として渡したのでそれを学んでプログラミング考え方を身につけた。その後Railsについても学んでみようとしたが、考え方のギャップに強い違和感を覚えた。…という経緯みたいだ。
余談2
https://twitter.com/camloeba/status/611051620877537281
https://twitter.com/sessoh/status/611052396161183744
このやりとり、拙僧さんが「肝心なこと」と思ってることを卯之助さんは「重要でない」と言ってるんじゃないですかね。
1. 括弧の省略
PHPにおいてはif文やwhile文において、1行であれば括弧を省略することができます。
<?php if (...) hoge(); while(...) hoge();
これは、保守性・管理性を上げたいのであればやってはいけません。括弧がつくことで視認性が下がることなどありません。むしろインデントに騙されてしまい、ミスが増えます。例えば下の例です。
<?php $a=0; $b=0; while ($a < 10) $a++; $b++;
さて、このとき $a はいくつですか? $b はいくつですか?
答えは $a が 10、 $b は 1 です。$b は while のスコープにはないので、ループしません。
括弧でくくられていればこのようなミスを防げます。括弧はきちんと書きましょう。
2. 三項演算子
ネストしすぎると可読性が損なわれるため注意が必要ですが、うまく使うとスマートに書けます。うまく活用しましょう。
3. switch文
条件分岐が多い時にうまく使いましょう。
ただし if 文で素直に書いた方が速度は速いという噂もあります。
実用上の違いはほとんどありませんので、チームの方針に従いましょう。
4. ループ文
PHP にはループ制御構文が用意されています。主に下記の3つを用途にあわせてうまく使い分けましょう。他にもループに関する構文や関数はありますが、基本的には下記で事足りるでしょう。
主に回数でループさせたい場合は for 文を利用するといいでしょう。
<?php for ($i=0; $i<10; $i++) { //
id:minamiyama1994 さん、反論してくださってありがとうございます。
Haskellファンのご意見がいただけて嬉しいです。元増田です。
記事全体で「関数型言語」と呼ばれているものは「関数型言語一般」ではなく「Haskellや一部OCamlの話題を含むごくごく一部の言語」の話である
わかりにくくてすいません。記事では「関数型言語」の話はしていません。「関数型プログラミング」の話をしました。
「関数型言語」は範囲がよりボンヤリとした表現です。たとえばC言語が関数型言語かどうかをみても賛否両論にわかれるでしょう。
私が記事を書いた目的は、”関数型プログラミングに縁のない人に関数型プログラミングをわかりやすく紹介したい”でした。
その目的のため、「関数型言語」という表記を注意深くとり除き、代わりに「関数型プログラミングをサポートした言語」という言い方をしています。
このスタンスの上で、
”関数型プログラミングをフルにサポートした言語”の代表として、Haskellを紹介し、
”関数型プログラミングへのサポートが片手落ちな言語”として、LispやErlangなどを扱いました(それらのファンの皆、ごめんなさい)。
関数型プログラミング初心者の方は、それらの差異なんてどうでもよい、と考えるのではないでしょうか。
関数型プログラミングとは何が良いのか、を大雑把に知りたい。
そうなのではと考えて、あえて区別せずに記事を書きました。
「たとえばモナドを知っていれば、30分程度でパーサー(解析機)を理解することができて」? モナドはそんな限定的用途のものではないし、パーサの理解とは無関係だ(単にライブラリの設計の問題)。それにApplicativeスタイルのほうがパーサが書きやすいという人もいるだろう
id:minamiyama1994 さんの仰るとおり、モナドはパーサー以外の多くの応用があります。
現状多くのパーサーがモナディックパーサーとして書かれています。モナディックでないパーサーは、あまり多くのユーザーには使われないでしょう。
モナドなどの抽象的な構造が幅を利かせてるお陰で、ライブラリに秩序が生まれ、ユーザーはそれを使いやすく・読みやすくなっている、というのが私の言いたかった主張です。
(なお細かいことで恐縮ですが、ある種のモナディックパーサーはApplicativeでは書けません。その点をお忘れですよ)
「テキスト処理」に対して
お前それShellやPerl、RubyやPythonの前でも言えるの?
「GUI」に対して
この二つは、先人が不利な環境ですごく頑張った成果が現状なのだ、と思っています。
本質的には関数型プログラミングの強みが活かせる分野のはずです。
「個人の技量の話題」
「レシピ」に関しては、関数型プログラミングのスタイルでは、手続きを手続きとして自然に表現できるのに対し、オブジェクト指向ではできない(DSLチックなものになってしまう)、ということを言いたかったのですが、
わかりにくかったですね。
「書きやすい」
(*)関数の例で、関数型プログラミングの無駄の無さを示せた、と思ったのですが…
マヂですか…反論のためのでっち上げとかじゃなくて(失礼)?(追記: Haskellの方が「短く書ける」、のタイポだそうです)
Haskell布教のために有休とって4時間かけて書いたのにー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の強い分野だと認識していたのだけれど、さてはて
最後に要点をまとめると
Linux信者がWindows嫌う理由ってなんとなくわかるよ。
俺もハスケルとかOCamlとかWindowsで使おうと思ったらろくに使えなかったし
でも、それってWindowsのせいじゃないじゃん。
これらはサードの開発したソフトであって、使い物にならないのはそれらの開発者のせいでしょ。
(俺はわざとWin版はクソに作ってWindowsの評判を落とす工作だと考えているが)
MSはWindowsの公式開発ツールとしてVisualStudioを提供してるじゃん。
ここまで優れた開発ツールを提供してくるOS開発者が他にいるか?
マルチプラットフォームといいつつWinでは実質使えなくしている開発者どもの実力不足が悪いとしかいいようがない。
結局、Linux信者の文句ってWindowsユーザーがLinuxでC#使えないからクソって言ってるのと同じくらいの馬鹿馬鹿しさなんだよね。
Windows信者にはそんな馬鹿はいないし、まともな知能を持っていれば馬鹿げたことだとわかるので
Windowsを貶めるための過剰反応した工作でしかないとはっきりわかんんだね。
F#ってMS版OCamlなんだけど、数年前Linux信者のニワカどもががOCamlをベタ褒めしてたけどF#には誰も触れなかったw
http://getlife.hateblo.jp/entry/2014/02/06/030300
こういう無知なおっさんが居るから、日本のIT業には魅力がないのだよなぁ、という印象
自分はプログラマというよりは、どちらかというと研究で飯を食ってる非SIのエンジニア
このブログの著者のおっさんが言うところの、プラスアルファは手に入れてる側ではあるんでしょう
普通のプログラマであることでは、差別化が出来ないと考えたからこそ様々な挑戦を繰り返し
基本的には、実装スキルのない人間の設計などはものの役に立たない、という所は同意して貰えるだろうけど
逆に、コーディング以外の技術、例えば無知なおっさんが例にだしてるデータサイエンティストであれば
統計だの機械学習の学術的な知識、体系だって勉強してきた数学力がなければ、まともな設計はできない。
各アルゴリズムがどんな計算をしていて、どの程度の計算量を要求し、どの程度の資源を求めるか、誤差はどうか、
負荷はスケールアウト出来るのか、他にいい手法は存在しないか、といった知識は一朝一夕には手に入らない
実際のコードをイメージしながら、各モジュール群を適切に設計し運用するには、どちらかでは不足がある
つまりコーディングスキルを含めた言語などの道具への理解と、それを使った技術力、そして経験は不可分のもので
揃ってやっと1人前の”プログラマ”と呼べる。そういう人間だからこそ、高給取りになれる。
プログラマ=コーダという認識は、プログラマという職業や技術を軽視しすぎている人間に見られる
結局のところ、プログラムを書く人(=コーダ)ではなく、プログラムを使ってビジネスが出来る人(≠コーダ)が生き残るって面では日米大差ありません。
ちっちゃい商売で食えてることがこの人の自慢なんだろうけど、これこそが日本のSierがゴミな理由だ
世の中にどんな技術があり、どんな研究が進んでいて、何が出来て、何が出来ていないのか?
それを知らない人間が良くこういうことを言う、顧客のニーズを汲み取れるだけでビジネス(笑)が生まれるとかないでしょ
例をあげると、海外ではCADのソフトの研究開発は盛んだけど、もう国内では殆ど生き残ってない。
国内には世界的な自動車メーカーがあれほどあるにも関わらず、CADソフトは国内には著名なソフトがない
こういう例には枚挙にいとまがない。日本のゲーム企業は世界的だがそこで使われている、ツールやらレンダラは海外製だし
SIerお得意のビジネス(笑)を生み出す、クラウド、分散コンピューティング関係でも、OpenMPIなど海外製だ
GitもMercurialも海外で生まれているし、OpenCVを初めとした画像認識ソフトやその技術も海外で生まれている
カメラによる画像認識で車や人を判断してブレーキする車は日本で作られるが、その根幹を為すアルゴリズムは
海外の研究者やらエンジニアが作っている訳だ。広大の栗田先生など一部例外はあるけれど。
それぞれ、SIerが言うビジネス(笑)なんか比較にならないほどの市場規模を持っているのに、それらを無視してビジネスとはなんだろうか?w
電機・機械系では、研究開発が盛んで、技術と儲けることは不可分なのに、IT業界だけはどういうわけか
ビジネスとは技術を何一つしらない無知なおっさんが作るものであるらしい
本物のプログラマにとっては、全く魅力がない、そんな業界な訳だ
お客からしたら技術の中身なんかぶっちゃけどうでもいいんです。JAVA で書こうが、Cで書こうが、COBOLで書こうが、そこに価値の本質はないから。
道具というのは、それを適切に選択して使ってこそ価値がある。
フランスではOCAMLが普及しているが、なぜだか考えたことがあるか?
何を選択すればコストが抑えられるかをすら考えたことすらない
言語なんかなんでも一緒?w
なるほど、鋸でなくともノミでも木は切れるだろうなw
切断面の美しさやかかった時間などは客には関係ない、切れてさえいればいいかw
お客にとっては技術などは確かにどうでもいい、しかし、それを上回る製品がないという前提だ
どうやって世界と伍して戦う?
どうやって他の製品を上回る?
微々たる使い勝手の差などは、技術力の差の前では圧倒的に無力だということは
データベースはオラクルだのSQLに依存し、製品ではSAPなどに完敗を喫し続けているSIerこそ理解すべきだろう
本当にビジネスを作る、というのが、技術と不可分なのは言うまでもない。
もちろん、その技術にはコーディングスキルも含まれている、という当たり前の話です。
オッサン論法でいけば、SIerがサービスとして提供するものと、同一の機能を持った製品との間の明確な区分など
客には存在しない。どっちのほうが凄くて安いか、だ。
そんで、もう、そういう勝負に負けまくってるのがSIer、技術で勝てないから安さで勝負するために
オフショアに必死になったり、ブラック企業化してプログラマを潰しては、ますます技術力とサヨナラしていってるね
http://anond.hatelabo.jp/20140206172641
普通は「IT系」って企業の一部門だし実際日本でも自動車メーカーやら電機メーカーやらゲーム会社やら内部でプログラマーを雇用して国際的な成果も上げてる企業なんていくらでもあるんですよね。
全くだな。
技術力をもった企業やエンジニアがフィーチャーされるべきなんだが、例えばゲーム屋だと
プロデューサーだのディレクターだのが表に出て学生のあこがれの対象になるし、
他もプロマネが表に出てくる事が多いので、文系職の比重の高さが問題なんでは・・・みたいな方向になるよな
大手でもホンダ、ソニー、日立など、研究部門が成果を上げている、中規模でもデンソーとか良い企業もあるし
小さい会社だと、先日googleに買われたシャフトとか、CADのラティスとか、モーションポートレイトなど、固有技術で食ってる会社もある
ストライクswitch文 これはゾンビプロセスですか? キル-9キル
シューウデンタイム 最終納期彼女 テイルズ・オブ・エンジニア
VeriSignのばら ガンプラC++ビルダーズ IT土方まさか☆デスマ
ブラックラー刃牙 ロード・ストア戦記 れじ☆すた 謎の変数X
シスターprintf 新製品エヴァンジェリスト 鉄腕atof 評価
コード規約~反逆のリリース コードゼロ 大ピンチ・コード コード:ブレイカー
OCamlと香辛料 あらいぐまHaskell ヒカルのGo ななかC/C++ コボラ
あした納める製品の仕様を僕達はまだ知らない。 LOTUS;NOTES
継承ダイモス 鋼の連勤術師 コンパイラ 機動戦士ガンダム0080 パケットの中の戦争
廻るpingDRAM とんでboolean ゼロ除算の使い魔 THEビッグオー記法
ふえぇ・・・これの話ですよぅ
「変数に型がないということの利点について考える」
http://d.hatena.ne.jp/perlcodesample/20130227/1361928810
この記事の内容についてはですね、多くのなーどの皆さんが、「何言ってんだこいつ」の気持ちを抑えきれずにいたんですけどね。
特に話題が「型」なものですから、関数型もひかんの皆さんが我慢できずに、「ひゃっはー汚物は消毒だー」とばかりに集まって大騒ぎする事になってしまったわけです。(ほとんどTwitterから来たんじゃないですかね・・・)
そりゃぁ、ガタイのいいお兄様達が火炎放射器構えながら、端正込めて書いた記事を炎上させれば、主様の頭に血が登るのも当たり前の話ですか。
わざわざ、こんなブログを定期的に更新する主様の事ですから、きっとプログラムが好きなのでしょう。でもきっと、「プログラム」が好きという点については、もひかんさん達負けてません。負ける気がしません。だからもひかんさん達も、自分達の足りない脳みそ使って、勉強してるんです。
『「静的型付け言語」と「動的型付け言語」ではどっちのほうが良いんだろう。そもそも「静的型付け」「動的型付け」ってどういう事なんだろう、っていうか第一「型」って一体何ものなんだろう・・・?』
答えを求めて、勉強してるんです。
僕もそんなもひかんさんの一人です。低い知能で出せるだけのぱわーを出して、それなりの勉強をしてきてます。だから言うんですよ。
「お願いだから、間違った事を間違ったまま広めないで」って。
これはね、別に「間違っている」事を責めているのでは無いのです。そんなもの、記事の冒頭に「僕が間違ってましたふひひさーせんw」って一言付け加えたなら、皆納得するんです。
そうじゃなくて、明らかに間違った事を間違っていると指摘しているのに、「いや、僕は間違っていない」と言い続けている事に問題があるのです。
そうです、件の記事の内容は、残念ながら・・・誠に残念ながら、その多くが間違っているんです。
具体的な間違いの内容は、コメント欄や多のブログ記事で散々指摘されいるので、僕が今更蒸し返すのは野暮でしょう・・・ただ、困ったことに主様はそれが「実感」として得られないので、何が間違っているか解らないのでしょう。
解らない事は恥ずかしいことではありません。ツーステップ以上登った先にある事を実感するのはとっても労力がいるものです。僕だって今、圏論とHaskellのモナドの関係についての厳密な説明を求められたら、泣いて謝るしか無いのです。
では、主様が今、件の記事の指摘の内容を実感するためには、どうすれば良いのでしょう?僕からは、ふたつ、提案する事ができます。
ひとつは・・・僕が散々言っているように、「お勉強」しましょう。僕はHaskell大好きなので、型を学びたいのであれば迷わずこの言語を学ぶことをお勧めします。多分、実用に耐えうる言語の中では最も型がしっかりした言語じゃないかなって、思うんです。
そしてね、お伝えしておきたいのはこの言語、ParlやRuby使いさんがビックリするくらい柔軟で簡潔なんですよ。静的型付け言語は無駄が多いなんて、とんでもない事です。
うーん、僕は、OCaml良くわからないですが、Scalaは直積型を再現するのが面倒な印象ありますです・・・
もう一つは・・・言語は何でも良いです、何か静的型付け言語を使って、それなりに大規模なものを・・・できれば二人以上で実装してみてください。それが終わったら、もし動的型付け言語で同じ事をしたらどうなっていたか、想像して見てください。きっと主様は、件の記事を上げたことを、後悔する事でしょう。
「型」ナメんなヴォケが(# ゚Д゚)
って事なんです。
プログラミングの型は、プログラマが間違いを犯さないために、プログラミング言語がわざわざ用意してくれているものです。そしてその基礎になっている理論は、コンピュータが真空管だった時代から、今にかけて、ずーっと研究され続けているテーマなんです。だから安易に「型がないことによって、たくさんの面倒から解放されるからです。」なんて、すっとぼけた話が通用するほど簡単な世界じゃないのです。
型は、主様が考えているよりも、もっと強力で、もっと柔軟で、僕や、主様や、なんとなくこの日記を除いた誰かさんのプログラミングを大いに手助けしてくれる凄いものなんです。それが動的型付けの言語だって、型の考え方は実装の指針を示してくれます。どうです?もっと型の事を知りたくなって来ませんか?
最後に、「本物のプログラマはHaskellを使う」から、いくつか引用して終わります。ばーいばい。
http://itpro.nikkeibp.co.jp/article/COLUMN/20080108/290605/?ST=develop&P=1
型がテスト自動化の道具であるという概念は、最初は理解しにくいかもしれません。しかし、Haskellのような強い静的型付けの言語に慣れるにつれて、こうした考え方を自然なものととらえられるようになります。
型のわずらわしさを克服し、型での静的なテストに慣れて型検査のメリットを実感するにつれて、「型を考えること自体がプログラミングである」と理解し、「型によってバグを防ぐためのテスト・コード」を当たり前のように書けるようになります。こうした感覚を身に付ければ、一人前のHaskellerになったと言えるでしょう。
まあ、そういう言い分は言語マニアにとっては都合が良いから無条件で真実とされてるわけだが
そういう嘘だらけな世界になってるのもウンザリしてる理由だな、
俺に言わせりゃお前らこそ「かじってる」だけだからわからないんだと思ってるが。
つーか、プログラムで「何を」やったことあってそんなこと言ってんの?
俺のこと古い人間とか言ってる奴いるけど、
WebGL?OpenGLのオフセットじゃん。今更何年も前に話題になった機能の入門記事が溢れてるのが笑えるwww、とか
ちょっと前にOCamlマンセーが流行ってたけど、あれだけ賛美推奨しておいてF#(.Net版Ocaml)をどいつもこいつも無視してるはありえんだろwwwとか
クソ言語マニアのブログ、記事、Twitterはこんな情弱ばっか。