「Haskell」を含む日記 RSS

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

2022-04-20

おすすめ言語教えてください

今の業務でメインで使うのがC言語

過去業務で使ったことがあるのがC++, Java, Ruby

たまに自分ツールで書くのがPerl, Python, bash

勉強しようとして挫折したのはHaskell, Scheme

自分的に

C言語は読みやすいから嫌いじゃないけどあんまり面白みはない

Rubyは書きやすいが読みづらい

Perlは書きづらいし読みづらいが面白

という感じです。

色んな観点おすすめ言語を教えてください。

2022-03-18

anond:20220317235749

以前は100%技術内容だったが

???からポエム論争」は何回も繰り返しているけど。

QiitaでのHaskellポエムについて何故か作者に敵視されている非Haskellerが思うこと - aokomoriuta's blog

https://aokomoriuta.hateblo.jp/entry/2015/01/25/194232

2022-01-07

全ての関数カリー化されてたほうが扱いやすいじゃん

Rubyばっかり使ってたけど必要に迫られてHaskell勉強しながら仕事で使ってるんだが一瞬でHaskellに惚れた

2022-01-01

2021年の振り返り(メンタルクソザコエンジニア大学生編)

### はじめに

こういう振り返り記事は書いても大した意味はないと思いつつも、自分ちゃんと生きていた印を残しておけばいつか役に立つかなと思って書きます

### 1月

めちゃくちゃ病んでたのであまり覚えていません。初めて精神科に行って薬をもらいました。医者からバイトを辞めろと半強制的に言われました。

休職していたバイトは復帰する予定だったけど、医者言葉&どうしても働くのが怖くて無理だったので、結局そのまま事実上退職という形になりました。

バイト先の人はとても優しかったし、ヘナチョコ自分をギリギリ現場で使える程度のコーダーに育ててもらっただけに申し訳ない気持ちはありました。

メンタルを病んでからコードを書くのも怖くて嫌だった気がします。

### 2月

所属する大学が4月からリモート授業になることがわかりました。「リモート授業下で新入生は履修登録とかどうすんだろ、大変そうだな」と思い、何か力になりたいと思ったので、授業の口コミを共有できるWebアプリを作り始めました。あんなにコード書くのが嫌だったのになんでだろう…。多分人の役に立つことによって、自分がまだ生きてていいことを確認たかったのではないかと思います、知らんけど。

### 3月

文字通り寝る食う以外はコードを書いていました。一日10時間くらいは書いていた気がします。

アプリは月末になってなんとかリリースすることができました。

250人くらいに使ってもらえて、「こういうの欲しかったんです!」とか「デザインが使いやすいです!」とか言ってもらえて、嬉しすぎて泣きました。自分でも誰かの役に立てるんだって思うことができて、すごく嬉しかったのを今でも覚えています

### 4月

進路について考え始めました。就職する気になれなかったので大学院に行こうと思いました。志望する研究室先生メールを送って宿題を出してもらいました。内容はHaskellで色々やるみたいな感じで、Haskell楽しいな〜ってなりました。

一応就活もやってました。行きたいと思える企業が1つだけあったので、そこにESを出しました。それ以外は何もやってなかったです。

### 5月

大学院の先生から出される課題がむずすぎて病みました。院進も就活もうまくいかなくてやばいやばいと思っていました。

結局院進は諦めて就活することにしました。面接を受けたりしました。

### 6月

ずっと就活でした。面接が本格化してきて、面接で落とされるたびに落ち込んでました。この時はメンタルがやばくて毎日薬を飲んでいました。

面接のために学校キャリアセンター面接練習してもらったり、自分の年表を作ったりしてました。昔の自分キラキラしすぎてて「この時に自殺しておけばよかったのに」と思ってました。今は思ってないですが…

### 7月

唯一行きたいと思ってESを出した企業から内定が出ました。なんで????いまだによくわかりません。でもとりあえず辛かった就活から解放されたのが心の救いでした。

### 8月

実家帰省して毎日アニメだけ見て生活してました。この生活をずっと送られたらどれだけ幸せなのだろうと思いました。

### 9月

内定先でアルバイトリモート)を始めました。最初は「なるほど、これがReactか…ふぅ〜ん、おもしれー技術」みたいな感じで楽しかったのですが、途中から自分もびっくりするくらい楽しくなかったです。なんで???リモートワーク適性がないのかな〜と思ってたけど、そもそも自分には労働の適性がなかったのを思い出しました。

働き始めて2週間で「働きたくない」「早く辞めたい」と思って病みました。また薬を飲み始めました。薬は飲み続けないと意味ないよ…?

### 10月

相変わらず死んだ顔をしながらバイトしてました。この頃になるとバイト中に漫画読んだり昼寝してました。バイトサボりながら『NEW GAME!』読んでたら頑張ってるあおっちたちに申し訳なくなりました。こんなカス人材、今すぐクビにしたほうがいいですよ!御社

最終出勤日にPCを返却して退職したとき気持ち良すぎて最高でした。退職するために働いてるみたいなところないですか…?

### 11月

バイトストレスからずっとアニメ見て漫画読んでました。いつもなら働いてる時間に近所を散歩していたら「空ってこんなに綺麗だっけ!?」と驚きました。

### 12月

卒論やばいので書き始めました。3週間くらいで書き終わりました。

あと知り合いのツテで業務委託コードを書き始めました。あんなにイヤイヤいってたのに気づいたらコード書いてるのよくわかりません。趣味なら楽しいのかなぁ。

### まとめ

基本的にずーーーっと心を病んでいました。本当に辛かった。

でもゴミカスなりにちゃん就活したり働いたり卒論書いたりしてて偉いと思います

2022年ちゃん卒業して、心身ともに(特に心)健康に楽しみながら働きたいです。

2021-12-11

関数型プログラミングが『銀の弾丸』」の記事ダメなところ

関数型プログラミングが『銀の弾丸』であるという非常識な常識2022のなにがダメなのかわからない人が多いようなので、個人攻撃をまったくせずにダメ出しする。

まず言っておくが、私はあの記事ほとんど読んでいない。しかし、簡単ダメ出しできる。

あの記事はめちゃくちゃ長いのに末尾再帰に触れていない

あの記事急所は末尾再帰である

記事内を「末尾再帰」で検索してみよう。1か所もヒットしない。「末尾」でも1か所もヒットしない。そう、あの記事はめちゃくちゃ長いのに末尾再帰に触れていないのである。では「再帰」ならどうだろう。11か所ヒットした。しかし、具体的な再帰コードはまったくない。長い記事内にあれだけ多数のコードを書いているにも関わらずである

末尾再帰重要

「末尾再帰って何?」とか「再帰ってそんな重要なの?」と思う読者も多いだろうから、末尾再帰重要さだけ説明しよう。

あの記事は、forやwhileを使わないプログラミング手法を前提に書かれている。記事内を「制御」とかで検索すればわかる。

末尾再帰はforやwhileの代わりになるもので、そういったプログラミング手法には欠かせない。forもwhileも末尾再帰も使わないとなると、ツリー探索などのアルゴリズムを書くことが困難になる。(こういったことが苦手な私に思いつく他の方法は、setIntervalを無理やりforループの代わりにするくらい)

JavaScriptはたいてい末尾再帰サポートしていない

そもそもほとんどのJavaScript実行環境は、末尾再帰サポートしていない。つまりJavaScriptはforやwhileを使わずに込み入ったプログラムをまともに書けるような言語ではない。あの記事に書いてあるようなことをする言語ではないのである。私は別にそれでもいいのでTypeScript使いまくってるけど。classとか好きだし。

あの記事JavaScriptを使っている理由は、JavaScriptが人気だからだろうか?もしそうだとしてもダメである。あの記事は「JavaScriptは、ほどんどの実行環境が末尾再帰サポートしていない、このプログラミング手法に適していない言語である」といったこ自体に触れていない。人気のある言語を使いたいなら、他の末尾再帰サポートしている人気言語を使えばいい。

おまけ。実行速度について

ろくに読まなくても、他にもダメ出しできる。

関数型プログラミングで気になるのは、言語にもよるが実行速度やコンパイルにかかる時間である銀の弾丸と言うからには、C言語を使うような場面でも銀の弾丸でなければならない。(Haskellの実行速度はC並に早くできるそうだが)

記事内を「パフォーマンス」で検索したところ、実行速度に関する箇所がヒットした。

記事の実行速度関連の内容を要約すると「最近AWSAzure・GoolgeCloudPlatformなどを使って並列計算するので、昔ながらの命令型の順次実行は不適切である」となる。私が嘘を言っていると思うなら、記事内を「パフォーマンス」とか「AWS」で検索してヒットした箇所の前後を読んで欲しい。そんなに長くはない。

2021-12-07

良いのプログラマ

問題に対して適切なツール選択できるのが、良いプログラマだと思うんよ。

高速化が求められているところでGCありの言語とか使わんし、コード書くのにメモ帳使ったりしないでしょ。

から、ツウィッターで議論してるプログラマは良いプログラマじゃないか、別の意図がある良いプログラマだと思う。

ちなみに、適切ってのは、その人のレベルによるので、そっとしてあげればいいんじゃないかな。

Haskell最高

2021-11-20

anond:20210811224000

もともと研究用の言語なんじゃないの?Haskellデータ構造ポインターが分離しているように見えたが、修士レベルまでいかないと無理なんじゃないか?めちゃくちゃ難しいで、あれ。

anond:20211105092529

Python 使いは、RubyJava勢力からOOP無視しすぎていたし、Haskell のような関数型言語の人たちから失笑されるし、まぁ VBPHP といったたぐいのイージー言語とされていたのよ。少なくとも、人工知能が注目されるまでは。

2021-09-25

オブジェクト指向はすでに粒度時代にあっていない」を読んで

記事

@kis (id:nowokay) さんの以下の記事についてです。

https://nowokay.hatenablog.com/entry/2021/09/25/042831

ブコメにもあるようにちょっと内容が雑というかわかりにくいせいで賛否両論になってしまっていて、もしかしたら近いうちにアンサー記事が出るかもしれませんが、自分自身理解を助けるためにも言わんとしていることを推測しつつ、自分認識もまとめておこうと思い書くことにしました。明らかに誤読してそうな箇所があれば、指摘してください。

前提

まずは前提を書いておかないと論点がぼやけると思うのでいちおう。

自分バックグラウンドは以下:

その他の前提:


本文およびブコメを読んで思ったこ

2000年代に入って関数型プログラミングが脚光を浴び始めたのは、コンピュータ資源が潤沢になりパフォーマンスをそれほど気にしなくってよくなったことが大きな理由ではないか、という認識があります

関数型プログラミング言語の内部実装を読んだことがないので推測ですが、データを不変にするということはその都度メモリ領域を新たに割り当てることになり、そのオーバーヘッドプログラムパフォーマンスに影響を与えるので、パフォーマンス要件がをシビア場合、どうしてもメモリ割り当てや計算効率を考えるとミュータブルにせざるをえないと思います。が、ウェブアプリケーションに限っていえば、データベースアクセスネットワークアクセスレイテンシが大きいので、そうした相対的に細かいオーバーヘッド無視しても(大抵の場合は)問題にならなくなった、というのが「時代」の流れなんだという認識です。

いっぽうで別の観点もあって、REST API や FaaS が一般化して、関数単位で処理を分割し、アプリケーション外部に配置することが当たり前になってきた現状があり、マイクロサービスのようにアプリケーション自体モジュールの一単位として考えると、アプリケーション内部のモジュール同士でも関数ベースでやりとりする形になっても不自然ではないと考えられます

記事にもありますが、RPC派生実装?)として生まれJava の CORBA や MicrosoftDCOM みたいな振る舞い付きのオブジェクトコンポーネント)を共有しようという世界観は廃れ、REST API のような単一の振る舞い(エンドポイント)とそれにひもづく JSON のようなデータ構造のみを受け渡すやり方が一般的になったアプリケーション通信の潮流と、計算資源が潤沢になって再度脚光を浴びた関数型プログラミングが、レイヤーの違いを飛び越えてひとつになろうとしているのではないか、と。

まり、元記事に書かれている「時代に合ってない」というのは、「データ構造と振る舞いが一体となったオブジェクト」のような「なにか」は、そうした背景があるために、どこにも存在する必要がなくなってきているのではないか、と解釈しました。

なので、以下のコメントちょっと論点がずれてると思いました。

はあ?「再利用する方法としてはWeb APIが主流」って、その中身をオブジェクト指向設計することは、全く矛盾しません。 部品化の単位は、慣習や柵などで大きく変わりますオブジェクト指向とはほぼ無関係です。

https://b.hatena.ne.jp/entry/4708813645995359202/comment/suikyojin

なんでサービスとして外とやり取りする話とサービスの内部設計の話をごっちゃにしてんだ。なんか理解度が怪しくない

https://b.hatena.ne.jp/entry/4708813645995359202/comment/ssssschang

しかに、アプリケーション単位アプリケーション内部のモジュール単位とでその表現形式を合わせる必要はないんですが、元記事の言わんとしていることはこの一文に端的に表れていると思います

ソフトウェア記述をまとめるという視点では主にステートレス関数を分類できれば充分で、データと振る舞いをまとめたオブジェクトというのは大きすぎる、システムを分割して管理やすくするという視点ではオブジェクトというのはライフサイクルリソース管理視点が足りず小さすぎる、ということで、オブジェクト指向粒度でのソフトウェア管理は出番がなくなっているのではないか、と思います

個人的にわからなかったのは以下の部分です。

オブジェクト指向でなぜつくるのか」という本がありますが、「え、いまどきオブジェクト指向でつくらなくない?」っていつも思います。内容的には、もうほとんどはオブジェクト指向関係ないソフトウェア工学の紹介になっていますね。

当該書籍は読んだので後半はまぁわかるんですが、前半は「え、いまでもオブジェクト指向でつくるのが主流じゃないの?」って思ってしまますオブジェクト指向定義が「データ構造と振る舞いが一体となったオブジェクトの集まりとしてソフトウェア組織化すること」なのであれば)。

おわりに

Joe Armstrong が "Why OO Sucks" を書いたのが2000年とのことなのですが、そろそろこうした議論収束に向かってほしいと個人的には思います(とっくに収束していると感じている方もいらっしゃるでしょうけど)。

https://gist.github.com/posaunehm/4087971

2021-08-11

昔一瞬「Haskell」って流行ったよな

何だったのあれ

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 ちゃん

2021-07-19

Haskell 言語の作者の演算子順位の付け方の実装方法は良くない

優先順位を 1 とか絶対的な数値、業界用語で言うところのマジックナンバーにしたのは、設計ミスだと思うのだ。相対的表記にすべきだったのだ。

anond:20210124191254

拝啓、偉大なる数学者よ。ハスケル挫折した同士で伺いたいことがある。

Haskell関数のうち do ~ action既存C言語副作用の原因となる in out圏論というものラップすることで、対応しているのだと思うのですが、如何でしょうか?

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記述できるからであって、メモリ上やプロセッサ上では扱えているわけではない。よって、この「反例の反例」は否定できる。


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

anond:20210718161714

https://ja.wikipedia.org/wiki/%E3%82%A8%E3%83%89%E3%83%AF%E3%83%BC%E3%83%89%E3%83%BB%E3%83%AD%E3%83%BC%E3%83%AC%E3%83%B3%E3%83%84

Wikipedia引用すると、

計算結果の検証のため同一のデータを初期値として複数回シミュレーションを行うべきを、

ここまではよくわかる。それで物理学数学的なカオス理論を押す連中が間違っていると思うのが、

二度目の入力の際に手間を惜しみ、初期値の僅かな違いは最終的な計算結果に与える影響もまた小さいだろうと考えて、小数のある桁以降の入力を省いたところ、

ここ。ここが諸悪の根源だ。まず計算科学の連中が大学に入って最初に引っかかるミス大御所がひっかっている。たとえば、0.4 - 0.3 は計算科学では 0.1 じゃない。それは十進法から二進法に変換するという計算機の特性理解してない人がやるミスだ。嘘だと思ったら、0.4 - 0.3 == 0.1 と C なり Ruby なり Python なり Java なり Haskell なりでやってくれ。ちなみに JavaScript なら 0.4 - 0.3 === 0.1、Lisp族の Clojure は (== (- 0.4 0.3) 0.1)、PHPちょっと自信がないので省かせてもらう...。浮動演算ユニットがついているプロセッサIEEE 754 の類をサポートしているなら「偽」となるはずだ。ここでは「桁あふれ」「丸め誤差」なんかは説明しないが、計算機で小数を扱うのは注意が必要ってことだ。閑話休題、つまり計算機で数学物理学実数のように小数点を扱うなら 3.0 と 3.1と 3.14 は別物として扱う必要があって、カオス理論創始者であるローレンツは「有史に残る」ミスを犯した。

結果が大きく異なった。

これは金融界隈のエンジニアたちにとっては、コンピュータが現れてから悪夢のような形で襲っていて、ゴースト・イン・ザ・シェルの題材にすらなっている「既知の未知」という類のエラーだ。はっきりいうと、大御所にこんなことを言うことは憚れるが、エンジニアだと3年目以降だとしないミスMITエリートがやっているという、なんというか「そりゃ、そうなるだろ」的なミスをしでかした結果なんだよ。例えば、古典物理学だと有効数字ひとつ下の数値は切り上げて四捨五入するというのは教科書的には正しい。だがね、計算科学だと小数点の扱いは事故の元なんだよ。具体例を出すと「Ruby円周率を100回掛け合わせる、Ππ(パイパイ、n=100)みたいなことをする。

puts [3.0, 3.1, 3.14].map{|i| 100.times.reduce(i) {|j, k| j *= k + 1}}
# 2.7997864633183236e+158
# 2.893112678762268e+158
# 2.930443164939848e+158

もう一度、特に高校物理をやった人は考えてほしい。数値を切り捨てしないだけで、これだけの差が生じるのだ。そりゃ、ローレンツ大先生も驚くわな。現実世界では起きないような気がするのはなぜか?、と思うじゃん。そこで、わたしはこう思うわけですよ、

計算機は実数を正しく扱えない」

とね。だからこそ、

計算機を正しく扱わないことで生じる偏見差別

というもの科学する学問があって良いのじゃないかと。つまり

それこそが【計算科学】というもの

なのではないかと。


異論は認める

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