【.NET】F#について語れ3【OCAML】

**デフォルトの名無しさん** · 2023/11/23(木) 12:25:10.81

いろんなものを1つのシンプルな手法で表現できる仕組みなので、公式の説明にあるように抽象化された難しい概念なのでは
シンプルというのが簡単ではなくて、難しいというのは数学とかはよくあるよね

公式ではうそや矛盾する喩えを出さないように説明するから、
一面を単純化して喩えてるような、複数の外部の記事を自分の中で抽象化することで理解が進むんじゃないかな

**デフォルトの名無しさん** · 2023/11/24(金) 14:49:40.02

直ぐに仕組みを理解しなくても良いんでは？
仕組みを理解しなくてもある程度は使えるでしょ。
難しく考えすぎな気がする。

関数と変数と条件分岐が全部letだって、評価して何かしら結果が得られるものって思えば、全部同じでも困らないし。

**デフォルトの名無しさん** · 2023/11/26(日) 08:28:05.33

俺もそのマイクロソフトのサイトだけではさっぱり理解不能だと思う

コンピュテーション式はhaskellのdo記法を真似たものだから
わからなかったらそっちを勉強するのがいいかもしれない
bindの型をみて、bindがチェーンにする様子がイメージできたら
なぜ展開するとああいういかつい式になるのかが理解できてくるよ

**デフォルトの名無しさん** · 2023/11/28(火) 00:02:10.45

この表はよく見返して、型に合わせてパズルするよ。
https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/computation-expressions#creating-a-new-type-of-computation-expression

コンピュテーション式がなぜ必要なのかとか、どう置き換えればいいのかはここを読むといいかも
https://fsharpforfunandprofit.com/posts/computation-expressions-intro/

**デフォルトの名無しさん** · 2023/12/06(水) 04:53:42.99

ｒわｒ

**デフォルトの名無しさん** · 2023/12/09(土) 12:18:29.76

Haskellとかもそうだけどシンタックスシュガーの元の構文は複雑すぎるので
元の構文までしっかり理解して書けるようにするべきなのか？
というのは意見分かれるだろうな
使い方だけ覚えれば手続き言語のように使えるわけだし

**デフォルトの名無しさん** · 2023/12/15(金) 20:18:00.56

https://qiita.com/262144/items/01a3023612116180278e

**デフォルトの名無しさん** · 2024/02/18(日) 11:50:06.93

F#使ってる人殆といなくて悲しい

**デフォルトの名無しさん** · 2024/02/18(日) 13:02:53.69

どこのサイトで情報収集してる？

**デフォルトの名無しさん** · 2024/02/18(日) 22:19:20.19

f#の書き方Copilotに質問したらあっさり解決した
geminiは全然駄目だねコンパイル通らなかった

**デフォルトの名無しさん** · 2024/03/17(日) 01:51:00.22

既に三か月もF#の記事がない公式ブログかな
https://devblogs.microsoft.com/dotnet/tag/f/

最近ずっとAIとクラウドの話しかされてない

**デフォルトの名無しさん** · 2024/03/17(日) 01:52:34.69

公式ブログかissue
ブログはもはやAIとクラウドの話しかしてない・・・

**デフォルトの名無しさん** · 2024/03/17(日) 11:23:11.60

コミュニティベースで頑張るよって言ってるし、あまり書くこともないのかも？

**デフォルトの名無しさん** · 2024/06/25(火) 19:17:22.19

F#はどの分野でよく使われてるんだろう？
web？データサイエンス？

**デフォルトの名無しさん** · 2024/09/15(日) 13:50:02.80

F#は良い言語だと思うけど、
C#やTypeScriptにくらべてマイクロソフトの愛情不足だよな

**デフォルトの名無しさん** · 2025/01/18(土) 16:10:54.77

ScalaとF#の両方触ったことある人いる？
もしいれば、個人的な感想で良いのでどちらが好みか聞いてみたい

**デフォルトの名無しさん** · 2025/01/19(日) 09:31:11.83

自分はScalaはちょびっとしか触ってないけど、前のScalaはScala固有の部分と、Javaを引き継いでる部分と2つにわかれてて綺麗じゃないなって感じを受けた
その点F#はC#とかVBのより型が便利なバージョンって感じでこちらのほうが好み

**デフォルトの名無しさん** · 2025/01/19(日) 10:51:52.69

OCaml.NETと呼べる存在ならともかく実際はそこまで互換性ないし、どうせ.NET独自言語ならC#でいいからなあ

**デフォルトの名無しさん** · 2025/01/21(火) 20:29:20.50

scalaはオブジェクト指向側に軸足あるような雰囲気だけど
それにしてはよく頑張って関数型に手を伸ばしてる感じ

F#は生まれ持っての関数型ではあるけど
世間に転がってるF#のコード見ると
そんなに関数型にたしなんでる人のコードじゃないのも多々見る
関数合成よりパイプラインを使ってるようなというか
JavaのStreami APIみたいに、メソッドチェーンみたいにして満足してる人々を多々見る

**デフォルトの名無しさん** · 2025/01/21(火) 21:14:20.24

パイプラインはF#らしいコードって印象
HaskellもData.Functionに(&)が定義されてて、F#のバナナブラケットみたいな使い方が出来る

**デフォルトの名無しさん** · 2025/01/22(水) 14:27:10.61

むしろこれからどんどんストリーム的なプログラミングが多くなるんじゃないか
Algebra Effectsで厄介なところはhandlerに閉じ込められそうだし
それはBackusのFP的になるってことだよね

**デフォルトの名無しさん** · 2025/01/22(水) 14:43:36.01

F#は利用者が少な過ぎんじゃないかな
処理系やライブラリにバグがあると手こずるよ
でもF#駄目でもOCamlに行けるというのはメリットかも

**デフォルトの名無しさん** · 2025/07/04(金) 15:27:24.17

OCaml、C#, VB.NET→F#
と遍歴してきたけど
Ocaml.Netという造語？は誠にその通りだと思いますわ