「Ocaml」を含む日記 RSS

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

2016-05-20

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-03-19

http://anond.hatelabo.jp/20160318091757

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

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

2015-06-17

http://togetter.com/li/835942

セルフホスティング論争について俺がモヤモヤするのは2点

第一に、発端となった元ツイートには「非エンジニア新卒女子」とはっきり書いてあるのに

エンジニアとしては絶対に雇いたくない》

《旧式言語を学ばずに関数型言語一本槍でエキスパートを目指すような感じの方》

《「まず軽く触れてみよう」とか「趣味でやってみるか」といった程度ならいいのですが》

《実際には肝心なことを何も知らないのに、なんか知っていると思い込んでいる状態が、私いわく「脳味噌膿んでる」》

ひどい書きっぷりだよね。

もし自分当事者だったら「見ず知らずの人になんでここまで言われなきゃいけないの」と傷つくと思う。

第二に、下位層のレイヤーについて知っていなければ上位層のことをちゃんとやる資格がない

という態度が明らかに本人のダブルスタンダードっぷりを示している点

OCamlで書かれたコード関数型のパラダイム

コンパイルされたマシン語コード手続き型のパラダイム

と言いたいのだと思うけど、最近CPUマシン語に書かれていある命令をそのまま実行しない。

インテル場合CISC命令セットで記述されたコードRISC的なマイクロコードに分解・解釈して実行する。

さらに内部はパイプライン化されているため、単純に「1命令ずつ逐次実行」されてもいない。

外側から観察するとあたかマシン語命令列をひとつずつ逐次実行しているかのように振る舞っているだけだ。

マシン語コード記述されたプログラムが、命令通り入力と出力を繰り返すなら、内部でどのような先読み予測分岐を繰り返していても問題ない?マシン語の忠実な実行装置とみなしてよい?もちろん回路の設計ミスで誤動作するかも知れないけど、それがプログラマの「根本的な過ち」になる?

これは高級言語マシン語関係とまったく同じだ。

OCaml世界記述されているロジックが、OCaml仕様通りにちゃんと動作すれば、その下位層にあるマシン語がどういうパラダイム記述されていても関係ないと考えていいと俺は思う。

余談1

くだんの女子について、周辺のツイートを見てみると(完全に部外者憶測だけど)Railsを主力とするソフトウェア企業に非エンジニアとして新卒入社した新人プログラミングに興味を持ったのに対して上司OCamlの本を教科書として渡したのでそれを学んでプログラミング考え方を身につけた。その後Railsについても学んでみようとしたが、考え方のギャップに強い違和感を覚えた。…という経緯みたいだ。

余談2

https://twitter.com/camloeba/status/611051620877537281

https://twitter.com/sessoh/status/611052396161183744

このやりとり、拙僧さんが「肝心なこと」と思ってることを卯之助さんは「重要でない」と言ってるんじゃないですかね。

2015-03-26

なぜGo言語で書きなおさなきゃならんのか

別にバイナリ吐ける言語は他にもあるだろうに…

C++D言語OCamlHaskell、Rust、Nim、どれでもいいじゃないか。

2014-08-12

保守性・管理性が上がるPHPスマートコードレビュー12

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つを用途にあわせてうまく使い分けましょう。他にもループに関する構文や関数はありますが、基本的には下記で事足りるでしょう。

  1. for

主に回数でループさせたい場合は for 文を利用するといいでしょう。

例えば、10回同じ処理をする場合は下記のように書きます

<?php
for ($i=0; $i<10; $i++) {
  // 


  

2014-04-10

http://anond.hatelabo.jp/20140410134501

id:minamiyama1994 さん、反論してくださってありがとうございます

Haskellファンのご意見がいただけて嬉しいです。元増田です。

記事全体で「関数型言語」と呼ばれているものは「関数型言語一般」ではなく「Haskellや一部OCamlの話題を含むごくごく一部の言語」の話である

わかりにくくてすいません。記事では「関数型言語」の話はしていません。「関数型プログラミング」の話をしました。

関数型言語」は範囲がよりボンヤリとした表現です。たとえばC言語関数型言語かどうかをみても賛否両論にわかれるでしょう。

私が記事を書いた目的は、”関数型プログラミングに縁のない人に関数型プログラミングをわかりやすく紹介したい”でした。

その目的のため、「関数型言語」という表記を注意深くとり除き、代わりに「関数型プログラミングサポートした言語」という言い方をしています

このスタンスの上で、

関数型プログラミングをフルにサポートした言語”の代表として、Haskellを紹介し、

関数型プログラミングへのサポート片手落ち言語”として、LispErlangなどを扱いました(それらのファンの皆、ごめんなさい)。

言語パラダイムの話題」と「言語の話題」と「ライブラリの話題」と... を混同している

関数型プログラミング初心者の方は、それらの差異なんてどうでもよい、と考えるのではないでしょうか。

関数型プログラミングとは何が良いのか、を大雑把に知りたい。

そうなのではと考えて、あえて区別せずに記事を書きました。

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

id:minamiyama1994 さんの仰るとおり、モナドはパーサー以外の多くの応用があります

現状多くのパーサーがモナディックパーサーとして書かれていますモナディックでないパーサーは、あまり多くのユーザーには使われないでしょう。

モナドなどの抽象的な構造が幅を利かせてるお陰で、ライブラリに秩序が生まれ、ユーザーはそれを使いやすく・読みやすくなっている、というのが私の言いたかった主張です。

(なお細かいことで恐縮ですが、ある種のモナディックパーサーはApplicativeでは書けません。その点をお忘れですよ)

テキスト処理」に対して

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

GUI」に対して

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

この二つは、先人が不利な環境ですごく頑張った成果が現状なのだ、と思っています

本質的には関数型プログラミングの強みが活かせる分野のはずです。

「個人の技量の話題」

レシピ」に関しては、関数型プログラミングスタイルでは、手続きを手続きとして自然表現できるのに対し、オブジェクト指向ではできない(DSLチックなものになってしまう)、ということを言いたかったのですが、

わかりにくかったですね。

「書きやすい」

(*)関数の例で、関数型プログラミング無駄の無さを示せた、と思ったのですが…

僕自身はC++Haskellの両方を書く人間で、確かにC++の方が「短く書ける」と「感じる」ことは多い

マヂですか…反論のためのでっち上げとかじゃなくて(失礼)?(追記: Haskellの方が「短く書ける」、のタイポだそうです)

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

Haskell布教のために有休とって4時間かけて書いたのにーw

撲滅…

ショボーン(´・ω・`)

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-03-23

Linux信者ってなんでVisualStudio使わないの?

Linux信者Windows嫌う理由ってなんとなくわかるよ。

俺もハスケルとかOCamlとかWindowsで使おうと思ったらろくに使えなかったし

アパッチとかの環境も圧倒的にゴミすぎて使えない。

でも、それってWindowsのせいじゃないじゃん。

これらはサードの開発したソフトであって、使い物にならないのはそれらの開発者のせいでしょ。

(俺はわざとWin版はクソに作ってWindowsの評判を落とす工作だと考えているが)

MSWindows公式開発ツールとしてVisualStudio提供してるじゃん。

ここまで優れた開発ツールを提供してくるOS開発者が他にいるか

これ以外は非公式なんだからMSの関与するものではないので

マルチプラットフォームといいつつWinでは実質使えなくしている開発者もの力不足が悪いとしかいいようがない。

結局、Linux信者の文句ってWindowsユーザーLinuxC#使えないからクソって言ってるのと同じくらいの馬鹿馬鹿さなんだよね。

Windows信者にはそんな馬鹿はいないし、まともな知能を持っていれば馬鹿げたことだとわかるので

Windowsを貶めるための過剰反応した工作でしかないとはっきりわかんんだね。

あと、Linux信者ってF#スルーしてるのが笑えるw

F#ってMSOCamlなんだけど、数年前Linux信者のニワカどもががOCamlベタ褒めしてたけどF#には誰も触れなかったw

日本OCamlが普及しないのは問題だ、とか言ってたんだけど、一番普及させようとしてたのはMSなんだよね。

MSF#作ったかOCaml日本語書籍が出せたようなものなのに。ニワカすぎ。

2014-02-06

SIerって終わってんな

海外出張の後の振り休で暇なので書いてみよう

http://getlife.hateblo.jp/entry/2014/02/06/030300

こういう無知おっさんが居るから日本IT業には魅力がないのだよなぁ、という印象


自分プログラマというよりは、どちらかというと研究で飯を食ってる非SIエンジニア

このブログの著者のおっさんが言うところの、プラスアルファは手に入れてる側ではあるんでしょう

普通プログラマであることでは、差別化が出来ないと考えたからこそ様々な挑戦を繰り返し

生き残るために研究開発というポジションについた

外資でも働いたし、海外でも勤務経験がある

分析役(SEアプリケーションエンジニア、業務エンジニアシステムアーキテクトなど)

業務分析システム分析を行い、「何を作るべきか」を明確にするための分析役を担います

実装役(コーダーテスターなど)

実際に動くアプリケーションプログラミング品質評価を行う実装役を担います

この2つを分断している辺りが、もう絶望的にダメ


基本的には、実装スキルのない人間設計などはものの役に立たない、という所は同意して貰えるだろうけど

逆に、コーディング以外の技術、例えば無知おっさんが例にだしてるデータサイエンティストであれば

統計だの機械学習の学術的な知識、体系だって勉強してきた数学力がなければ、まともな設計はできない。

アルゴリズムがどんな計算をしていて、どの程度の計算量を要求し、どの程度の資源を求めるか、誤差はどうか、

負荷はスケールアウト出来るのか、他にいい手法存在しないか、といった知識は一朝一夕には手に入らない

実際のコードイメージしながら、各モジュール群を適切に設計運用するには、どちらかでは不足がある

まりコーディングスキルを含めた言語などの道具への理解と、それを使った技術力、そして経験は不可分のもの

揃ってやっと1人前の”プログラマ”と呼べる。そういう人間からこそ、高給取りになれる。

プログラマコーダという認識は、プログラマという職業技術を軽視しすぎている人間に見られる

結局のところ、プログラムを書く人(=コーダ)ではなく、プログラムを使ってビジネスが出来る人(≠コーダ)が生き残るって面では日米大差ありません。

ちっちゃい商売で食えてることがこの人の自慢なんだろうけど、これこそが日本Sierゴミな理由だ

世の中にどんな技術があり、どんな研究が進んでいて、何が出来て、何が出来ていないのか?

それを知らない人間が良くこういうことを言う、顧客ニーズを汲み取れるだけでビジネス(笑)が生まれるとかないでしょ

例をあげると、海外ではCADソフト研究開発は盛んだけど、もう国内では殆ど生き残ってない。

国内には世界的な自動車メーカーがあれほどあるにも関わらず、CADソフト国内には著名なソフトがない

こういう例には枚挙にいとまがない。日本ゲーム企業世界的だがそこで使われている、ツールやらレンダラは海外製だし

SIerお得意のビジネス(笑)を生み出す、クラウド分散コンピューティング関係でも、OpenMPIなど海外製だ

GitMercurial海外で生まれているし、OpenCVを初めとした画像認識ソフトやその技術海外で生まれている

カメラによる画像認識で車や人を判断してブレーキする車は日本で作られるが、その根幹を為すアルゴリズム

海外研究者やらエンジニアが作っている訳だ。広大の栗田先生など一部例外はあるけれど。

それぞれ、SIerが言うビジネス(笑)なんか比較にならないほどの市場規模を持っているのに、それらを無視してビジネスとはなんだろうか?w

電機・機械系では、研究開発が盛んで、技術と儲けることは不可分なのに、IT業界だけはどういうわけか

ビジネスとは技術を何一つしらない無知おっさんが作るものであるらしい

本物のプログラマにとっては、全く魅力がない、そんな業界な訳だ

お客からしたら技術の中身なんかぶっちゃけどうでもいいんです。JAVA で書こうが、Cで書こうが、COBOLで書こうが、そこに価値本質はないから

もちろん、手段は多ければ多いほどいい。そういった意味でのコーディング技術有用です。

ただし、あくまでも手段は手段。価値を生み出すという目的には別の考えが必要です。

無知おっさん無能さを再掲してやろう

道具というのは、それを適切に選択して使ってこそ価値がある。

フランスではOCAMLが普及しているが、なぜだか考えたことがあるか?

関数型言語は、どういう場面で威力を発揮するか?

Javaにできて、C#で出来ないこと、その逆は何か、

何を選択すればコストが抑えられるかをすら考えたことすらない

それをこれ程証明する言葉も無い

言語なんかなんでも一緒?w 

なるほど、鋸でなくともノミでも木は切れるだろうなw

切断面の美しさやかかった時間などは客には関係ない、切れてさえいればいいかw

こういう人間が作るビジネス(笑)とやらに先はあるだろうか?

お客にとっては技術などは確かにどうでもいい、しかし、それを上回る製品がないという前提だ

どうやって世界と伍して戦う?

どうやって他の製品を上回る?

微々たる使い勝手の差などは、技術力の差の前では圧倒的に無力だということは

データベースオラクルだのSQL依存し、製品ではSAPなどに完敗を喫し続けているSIerこそ理解すべきだろう

本当にビジネスを作る、というのが、技術と不可分なのは言うまでもない。

もちろん、その技術にはコーディングスキルも含まれている、という当たり前の話です。

id:hiroyuki1983

製品を生み出して売ってる会社SIerじゃ全然違うでしょ。どっちが上とか言う話ではなくて

オッサン論法でいけば、SIerサービスとして提供するものと、同一の機能を持った製品との間の明確な区分など

客には存在しない。どっちのほうが凄くて安いか、だ。

そんで、もう、そういう勝負に負けまくってるのがSIer技術で勝てないから安さで勝負するために

オフショア必死になったり、ブラック企業化してプログラマを潰しては、ますます技術力とサヨナラしていってるね

http://anond.hatelabo.jp/20140206172641

普通は「IT系」って企業の一部門だし実際日本でも自動車メーカーやら電機メーカーやらゲーム会社やら内部でプログラマー雇用して国際的な成果も上げてる企業なんていくらでもあるんですよね。

最近だとニュースサイトとか電子書籍とかの関係出版系みたいな文系会社プログラマ求人普通に出してます

なのに日本IT系というとまずSIerが思い浮かんで、そこが糞だから日本ITダメと。

全くだな。

技術力をもった企業エンジニアがフィーチャーされるべきなんだが、例えばゲーム屋だと

プロデューサーだのディレクターだのが表に出て学生のあこがれの対象になるし、

他もプロマネが表に出てくる事が多いので、文系職の比重の高さが問題なんでは・・・みたいな方向になるよな

大手でもホンダソニー日立など、研究部門が成果を上げている、中規模でもデンソーとか良い企業もあるし

小さい会社だと、先日googleに買われたシャフトとか、CADラティスとか、モーションポートレイトなど、固有技術で食ってる会社もある

しかし、そういった会社への就職は一般には要求水準が高くて難しい、

東大情報理工なんかを出たエリートでなくても、もっと裾野の方の楽に入れる企業でも技術が重視される風潮を作ることが大事

2014-01-20

http://anond.hatelabo.jp/20140120160918

「お前はその言語で何作ったの?」って聞けば黙るだろ。

HaskellだのOCamlだの使おうと思ったら、ライブラリレベルからガンガン自作しなきゃならんだろうし。

2013-11-26

バグテスト残業

ストライクswitch文 これはゾンビプロセスですか? キル-9キル

シューウデンタイム 最終納期彼女 テイルズ・オブ・エンジニア

VeriSignのばら ガンプラC++ビルダーズ IT土方まさかデスマ

ブラックラー刃牙 ロード・ストア戦記 れじ☆すた 謎の変数X

クレームモア 売るSEやつら フリージングサーバーが)

コード・アサート・オンライン(本番)環境 エクセル・ワード

文字化け物語 進捗の巨人 gdgd進捗s 11人月いる!

シスターprintf 新製品エヴァンジェリスト 鉄腕atof 評価

コード規約~反逆のリリース コードゼロ 大ピンチコード コード:ブレイカー

OCaml香辛料 あらいぐまHaskell ヒカルGo ななかC/C++ コボラ

あした納める製品仕様を僕達はまだ知らない。 LOTUS;NOTES

継承ダイモス 鋼の連勤術師 コンパイラ 機動戦士ガンダム0080 パケットの中の戦争

廻るpingDRAM とんでboolean ゼロ除算の使い魔 THEビッグオー記法

頭文字D言語 吸血鬼ハンターD言語 D.言語-man Apache野球

ニンゲツスレイヤー プロジェクト炎上 業界は衰退しました

2013-03-10

http://anond.hatelabo.jp/20130310152032

プロダクトマネージャさんが99%の人におすすめな静的型付け言語って?

Javaは99%の人に薦めてもいいかも知らないけど、型システムとしては静的型付け言語ダメなところをだけをかき集めたようなクソだよね。type safeですらないし。

ScalaとかHaskellとかOCamlとかを99%の人におすすめちゃうの?

2013-03-03

http://anond.hatelabo.jp/20130303135038

Haskellネイティブコードコンパイラあるよ。

OCamlにもある。

F#.netで動くわけだよね。

論点を整理し直そうぜ風に書き始めたのに結論ありきな締めくくりで、あんま理性的じゃないね

2013-03-02

変数に型がないということの利点について考える」の何が良くないの

ふえぇ・・・これの話ですよぅ

変数に型がないということの利点について考える」

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になったと言えるでしょう。

2012-12-09

http://anond.hatelabo.jp/20121209055355

WebGLOpenGLオフセットじゃん。

……サブセットだよな?

ちょっと前にOCamlマンセー流行ってたけど、

(中略)

あいつら最初からCやってればこんな情弱にならずに済んだのにな。

OCaml触っててC使えない奴がそうそういるとは思えんが。

http://anond.hatelabo.jp/20121208222828

想像ひとつも合ってないのが笑える。

まあ、そういう言い分は言語マニアにとっては都合が良いから無条件で真実とされてるわけだが

そういう嘘だらけな世界になってるのもウンザリしてる理由だな、

俺に言わせりゃお前らこそ「かじってる」だけだからからないんだと思ってるが。

つーか、プログラムで「何を」やったことあってそんなこと言ってんの?

俺のこと古い人間とか言ってる奴いるけど、

「最新技術」を使えば使うほどCやるしか無いって痛感するよw

からすりゃクソ言語愛好家は全員情弱から

WebGLOpenGLオフセットじゃん。今更何年も前に話題になった機能の入門記事が溢れてるのが笑えるwww、とか

ちょっと前にOCamlマンセー流行ってたけど、あれだけ賛美推奨しておいてF#(.NetOcaml)をどいつもこいつも無視してるはありえんだろwwwとか

クソ言語マニアブログ、記事、Twitterはこんな情弱ばっか。

あいつら最初からCやってればこんな情弱にならずに済んだのにな。言語以外の知識も今頃豊富だったろうに。

こういう言語仕様調べてるだけの役立たず情弱ばっかになったのもむかついてしょうがないわ。

2010-07-28

http://anond.hatelabo.jp/20100728215904

それがSTLの本来の使い方。

変数宣言すると名前覚えたりするの面倒なんだよ。そっちの方が楽だし、OCamlやFSharpみたいな関数型言語に慣れたら一時変数苦痛でしかない。

2009-06-09

http://anond.hatelabo.jp/20090609174454

俺もHaskell触ってみようかと思ってたんだけど、その話聞くと萎えるな…。

プログラミング言語なんて実用してナンボだから!ヨーロッパの趣とかどうでもいいから!

OCamlってのは全然知らないなあ。いっそのことLispでもやるかなあ。

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