【.NET】F#について語れ3【OCAML】
>>182
それでなぜラムダ計算との相性が悪すぎるのか
スコープって見た目の話か >>189
おれはgforthで遊んでるくらいだけど、ラムダ計算っぽく書けないという意味ならスコープのせいだろう
ローカル変数(スタック){: ... :}もANSIに入りはしたけどゴミだから俺独自の{ ... }使えって始末
forth-standard.orgで議論やってるけど、ローカル関連は炎上祭りよ
そもそもの言語哲学に反してるのもある 仮引数すら拡張的な位置付けなら、λの入り込む余地なんてないわな 最近独学で触り始めて面白いなーと思ってるんだけど
日本でF#の案件ってないのかな 実案件にF#ぶっ込んだけど募集案件としてはたまーに見るくらいやな この言語って"知られていない"の一点に尽きる気がする
TypeScriptよりも書いていて気持ちいいと思うんだけどな MSが力入れてないのでテンプレートがないとかで使いにくいとこはあると思うけどそのほかは今でもC#より優れてるとこ多々あるとは思うよ
Unityで使えるならこっち使いたいわ >>197
F# Unityでググると、日本語の記事がいくつかヒットするけどどうなんだろ。 >>198
WindowsでIL2CPP使わないなら使えるというかF#でつくったdllの呼び出しが出来るって話だと思う。
モバイルとかはもうIL2CPP前提だから無理ぽ
無理というかタイプのネストが9以下ならいけるはずなんだけどF#じゃ軽く超えるからやはり無理ぽ Unityばかり使っててF#全然触ってないんだけど、ジェネリクス使おうとするとF#の楽さが身に染みる 実務でF#使ってるっていう会社の面接受けてて好感触なんだが果たして本当に大丈夫なのだろうか……C#の経験しか無いんだが
まぁあとはF#みたいな割とマイナー寄りなところの経験積んでも将来なぁみたいな。F#使ってる会社ってどれくらいあるんだろう 正直言語なんでなんでもいいしそこで関数型やら.NETやら慣れたら他にも応用効くでしょ Elixir の方が良い。
Ruby っぽくて可読性も高い
スクエニでも使っているらしいし、
Ruby on Rails の本も出している、黒田努の本も出た
Elixir実践ガイド、黒田努、2021/2/5
Ubuntu 20.04, Docker CE 19.03, Elixir 1.11
Phoenix, BEAM というフレームワークもある
YouTube で有名な雑食系エンジニア・KENTA は、
Phoenixでポートフォリオを作った。
Railsに似ているのかも 漠∞!!!!
列∞!!!!!
廷∞!!!!!!
器∞!!!!!!!
業∞!!!!!!!!
論∞!!!!!!!!!
寿∞!!!!!!!!!!
素∞!!!!!!!!!!! >>203だけど結局会社入った
F#とC#が入り乱れるフレームワークとそれによるシステムで超苦戦してる
というかF#まじで分かりにくくない?let let letでもう何が何なのか区別が本当につけにくい
{}の区切りも無いから巨大な1ファイルにたくさんクラスがあったりするとどっからどこまでが1クラスなのかすらよく分からない
あとそもそも学習リソースが無い。英語の本やサイトくらいしか包括的に学べない
転職先選び失敗したかなぁ……1週間で早くも落ち込んでる >>209
業務でF#使えるなんてうらやましい。
ちょっと古いけど、自分は「実践F#関数型プログラミング入門」って本で勉強したヨ。
がんばれ >>209
typeとletで普通に見分けつかん?
英語の本あれば十分なのでは…というか英語でダメならこれを機会に英語勉強しろ
翻訳するのもあり F#のベストプラクティスがよく分かってないからあれなんだけど
moduleはC#でいうところのstatic classみたいなもんっていうの読んであれ?って
ユーティリティクラスは良くないとか言われるけどあんまstatic classにいいイメージ無くて
F#だと全然そんなことないの?ガンガンmoduleに色々突っ込んじゃえみたいな感じ?
>>210
注文した
>>211
いやtypeとletはそりゃ区別つくけど。関数だろうと変数だろうと条件分岐だろうと全部letじゃない
あとまぁpythonもそうだけどインデントで分けるのほんと分かりにくくて。カッコが無いときつい
英語割りと得意な方だけど勉強するときはやっぱり日本語のほうが頭に入る 判別共用体がよくわかりません。例えば
type Shape =
| Rectangle
| Circle
| Prism
みたいな例だと最初いやお前らどこから出てきた。そんな型ないだろと思って
んじゃenumみたいに0から番号振ってるのかと思ったらそうじゃないって言うし
それでいきなりlet x = Rectangleみたいな使い方が出来るなんて言われてもうちんぷんかんぷん。それでxの型はShapeだっていうし
RectangleだのCircleだのは識別子って言うらしいけどこいつら一体なんなんですかね。英語サイトなんかだとコンストラクタだと思えばいいよみたいなこと書いてたけど
そもそもクラス定義なのにこの内のどれかってどういうことなんですかね。例えばlet y = Circleみたいにやったときxとyの違いってなんでしょう?(参照するアドレスの話ではない)
暗黙的にprivate int typeみたいなのが生成されて番号振られてるとかなら分かるんですが
今日一日ずーっとあれこれサイト巡ってchatgptとかにもお伺い立ててそれでも全然理解できませんでした
大体どの本も最初でさらっと流してるけどどうしてみんな理解できるんですか?自分の理解力の低さに悲しくなってきました >>213
オブジェクト指向でのクラス・サブクラス関係のようなものと考えればいいんじゃないか?
RectangleクラスやCircleクラスのインスタンスはShapeとして扱える、みたいな話の関数型の考え方での表現方法 自分は理解に困ったことなかったんで新しい知見だけど
背景知識でどう書き換えられるかを調べてみたらどうだろう。
その感じだとC#とかJavaとかのオブジェクト志向言語は使えるんでしょ
~言語で書いてみる、とかでググってみたらどうかな
番号振られてるのとコンストラクタ(≒クラス)で識別できるのはあまり変わらない気がするけども xとyの違いは値の違いだと思うよ
どちらもShapeクラスのインスタンス
C#で書くなら、Shapeクラスがpublic static readonly Shape Circle = new Shape(ShapeId.Circle)ってなやつを持ってれば、だいたい同じになりそうじゃん?
これならprivate int ShapeIdで区別してるって考えられるけど。
CircleとRectangleの区別のために、実際にどう実装されてるか気にしなくてもいいと思うけどね >>213
> そもそもクラス定義なのにこの内のどれかってどういうことなんですかね。
どういうことっていうか、そもそもクラス定義じゃないので。
無理やりオブジェクト指向に当てはめるとすると、
null許容型みたいに複数の選択肢を与える型とレコード型を融合させたものと考えたらいいんじゃないですかね。
ただ例え話にも限界が有るし、素直に頭を関数型言語にシフトさせた方がいいと思います。 >>213
その例だとRectangle、Circle、Prismは中身がないから
単なる番号と考えることもできるだろうけど
中身がある場合はそうもいかないでしょ
learn.microsoft.com/ja-jp/dotnet/fsharp/language-reference/discriminated-unions
Haskellにも同様のものがあるし
www.letitride.jp/entry/2020/05/05/092738
Scalaにも同様のものがある
zenn.dev/mossan_hoshi/articles/20230417_scala
ScalaではF#のinterfaceのようなものであるtraitと
こうした目的のための特別なclass定義 case classがあり
CircleやRectangleの定義でShapeを継承している >>214 >>217
あれちょっと衝撃的だったんですけどクラス定義ですよね?typeだし あーちょっと思いついて判別共用体をDLLにしてC#で呼び出して定義に移動したらC#で判別共用体がどう解釈されるかは分かりました
sealed class Shape の中にstatic class Tagsが定義されてint Rectangle = 0, int Circle = 1みたいに番号振られてますね。考え方としては間違ってなかったのかな…… returnが無いの本当にきついと思うんですけど慣れますか
最後まで関数読んでもそもそも何を返しているのかさえ分からないのが日常茶飯事なんですけど
if condition then xxx, true else...みたいなのがあっては?true?なんじゃこの構文と思って散々検索した後にxxxとtrueのタプルを返してるとchatgpt先生に教えてもらったときは無理だろってなりました 書かれているとおりのものが返るだけなのにreturnがあるはず(あるべき)という
思い込みのせいで分からなくなってるわけで、returnがあるはず(あるべき)という
思い込みはいつか消えますかと問われても、人によるだろと答えるしかないな 確かにオブジェクト指向とは違う表現が多いだろうけど、それ以上に面白いと思うけどなあ
特にCopilotとの相性が良すぎる コンピュテーション式まじでわかんねぇ……
let!とかdo!とか解説をいくら読んでも理解できん。デバッグでステップごとにやってるとlet!の次の行実行しないでいきなり波括弧終わったりするのなんでや コンピュテーション式の名前をはじめて知った初心者だけどステップインで実行したら1行ずつ動いて、
この記事のコメントで書いてるイメージのコールバックの動きが実感できた
ttps://zenn.dev/zecl/articles/a330820e9277cf#option%E3%83%A2%E3%83%8A%E3%83%89%E3%81%AE%E3%82%B3%E3%83%B3%E3%83%94%E3%83%A5%E3%83%86%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E5%BC%8F
中身がコールバックだからかデバッガが上手いこと判断してくれないんかな。 コンピュテーション式まじで難しい
大体公式のhttps://learn.microsoft.com/ja-jp/dotnet/fsharp/language-reference/computation-expressionsこれはなんだ。理解できる人間が存在するのか
記事とか読んでてもこういう風に自動的に変換できるんだよ簡単だねみたいな書き方してるけど変換先がもうわけわからん
これを頭の中で想像できない人間は書けないのか いろんなものを1つのシンプルな手法で表現できる仕組みなので、公式の説明にあるように抽象化された難しい概念なのでは
シンプルというのが簡単ではなくて、難しいというのは数学とかはよくあるよね
公式ではうそや矛盾する喩えを出さないように説明するから、
一面を単純化して喩えてるような、複数の外部の記事を自分の中で抽象化することで理解が進むんじゃないかな 直ぐに仕組みを理解しなくても良いんでは?
仕組みを理解しなくてもある程度は使えるでしょ。
難しく考えすぎな気がする。
関数と変数と条件分岐が全部letだって、評価して何かしら結果が得られるものって思えば、全部同じでも困らないし。 俺もそのマイクロソフトのサイトだけではさっぱり理解不能だと思う
コンピュテーション式はhaskellのdo記法を真似たものだから
わからなかったらそっちを勉強するのがいいかもしれない
bindの型をみて、bindがチェーンにする様子がイメージできたら
なぜ展開するとああいういかつい式になるのかが理解できてくるよ Haskellとかもそうだけどシンタックスシュガーの元の構文は複雑すぎるので
元の構文までしっかり理解して書けるようにするべきなのか?
というのは意見分かれるだろうな
使い方だけ覚えれば手続き言語のように使えるわけだし f#の書き方Copilotに質問したらあっさり解決した
geminiは全然駄目だねコンパイル通らなかった 既に三か月もF#の記事がない公式ブログかな
https://devblogs.microsoft.com/dotnet/tag/f/
最近ずっとAIとクラウドの話しかされてない 公式ブログかissue
ブログはもはやAIとクラウドの話しかしてない・・・ コミュニティベースで頑張るよって言ってるし、あまり書くこともないのかも?