次世代言語25 TypeScript Swift Go Kotlin Rust Nim

**デフォルトの名無しさん** · 2022/04/17(日) 17:52:35.38

スレタイ（順番はRedMonk準拠）以外の言語もok

前スレ
次世代言語24 Go Nim Rust Swift Kotlin TypeScript
https://mevius.5ch.net/test/read.cgi/tech/1647887021/

**デフォルトの名無しさん** · 2022/04/21(木) 22:55:52.73

>>135
Optionにget()メソッドはありません

**デフォルトの名無しさん** · 2022/04/21(木) 23:17:57.08

ほぼOptionのNoneと言ってるのに、null相当(nilやundefined等含む)を代入とか、Option<T>型となるため型が異なりとか
もう誤魔化して言いくるめる気にしか見えない。。。
どれだけNull安全で助かってるか、なんてコードを書いてればそんなに無いでしょ。確かにNullが無いのだから、Nullのような状態で
クラッシュ/panicする事態は減るでしょう。コンパイルが通った時点でNull安全性が保障されるなんてのも、今どきの多くの言語は
外付けながらLint系の警告をしてくれます。もちろん言語に統合されてない後付けで「美しくない」とかそういうのはあるでしょうが。
そして手続き型プログラミングを初めて数年の初心者なら沢山のミスを犯すのかもしれんけどさ、そもそも宣言と同時に初期化を
する重要性は、関数型プログラミングでも少しでもしていれば分かるはずでそんな経験もなく、旧Java系なんかからRustへ移ったら
感嘆するように見えるのかもしれんが、そんなしつこく言うほど便利な場面って具体的にどういう時よ？逆にさ？
次はNan安全言語とか、-+Inf安全言語とかやるのかい？

**デフォルトの名無しさん** · 2022/04/21(木) 23:28:25.00

Rustのアドバンテージを認めざるを得ないから認めつつ
それでも批判したいから言い掛かり長文
みっともない

**デフォルトの名無しさん** · 2022/04/21(木) 23:47:03.05

>>137 その通りだからきみはJavaとかHaskellとか使えばいいと思うよ

Rustの良いところを教えてほしいなら普通に指導を乞えばいいのに

**デフォルトの名無しさん** · 2022/04/22(金) 00:11:43.18

null安全をlinterが警告してくれる言語なんてあったっけ？

**デフォルトの名無しさん** · 2022/04/22(金) 00:18:27.86

>>140
未初期化変数へのアクセスのことを言ってそうな気がする
それ以外のケースでnullの問題踏んだことない人なのかもしれない

**デフォルトの名無しさん** · 2022/04/22(金) 02:18:54.02

>>134
Goが無いのはGoでは不可能なの？

**デフォルトの名無しさん** · 2022/04/22(金) 16:02:25.23

Rustにいいところなんてないよ
面倒なだけ

**デフォルトの名無しさん** · 2022/04/22(金) 16:09:03.51

色々とプログラミングが楽で快適だからRust使ってるわ

**デフォルトの名無しさん** · 2022/04/22(金) 18:41:08.80

普通に煽りじゃない反論ができない時点でRustニワカのキモさが良くわかる。Null安全を全否定してないのに
「指導を乞え」とか「JavaとかHaskellとか使え」とか「それ以外のケースでnullの問題踏んだことない」とか
Nullのような状態でクラッシュ/panicする事態は減るって書いてるのに文字も読めもしない。
”それほど強調して、気持ち悪く粘着してNull安全言語なんて宣伝してることがRustのために良くない”って話だよ
言語の悪口を言ってるんじゃない、おまえのようなキモくて何も答えられないで煽りだけクズを論ってんの

**デフォルトの名無しさん** · 2022/04/22(金) 19:03:56.53

自分でこれが煽りじゃない反論だと思ってるならヤバい

**デフォルトの名無しさん** · 2022/04/22(金) 19:15:01.24

Rustより良い言語が出現したらそれを検討する予定
今のところそういう言語がないためメイン言語はRustのまま

**デフォルトの名無しさん** · 2022/04/22(金) 19:20:14.50

煽ってるだけの書き込みにまともな返答がくるわけないじゃん

**デフォルトの名無しさん** · 2022/04/22(金) 19:21:33.19

まだスレタイに出てないけど注目してる言語とかありますか？

**デフォルトの名無しさん** · 2022/04/22(金) 20:02:04.18

flixかな
scala亜種といった感じで流行るようには見えないけどね

**デフォルトの名無しさん** · 2022/04/22(金) 20:06:53.42

この根源的な差が決定的かな

＞プログラミング言語は以下の3つに分類される
＞ CとC++　←『省メモリ高速』だが、「メモリ解放でミスると危険」
＞ GC言語　←『省メモリ高速』ではないが、「メモリ解放は自動で気にしなくていい」
＞ Rust　←『省メモリ高速』だが、「メモリ解放は自動で気にしなくていい」

**デフォルトの名無しさん** · 2022/04/22(金) 20:15:46.28

言語じゃないけどWASMってどうよ

**デフォルトの名無しさん** · 2022/04/22(金) 20:25:25.90

>>149
Pony
Rustよりも安全。データ競合だけでなく、デッドロック、実行時例外が起きないことも保証されてる
actorモデルを採用している

**デフォルトの名無しさん** · 2022/04/22(金) 20:27:40.70

>>150
これですかね
ありがとうございます

The Flix Programming Language
https://flix.dev/
https://github.com/flix/flix

プログラミング言語Flixに関するMagnus Madsen氏へのインタビュー
https://www.infoq.com/jp/news/2022/03/flix-programming-language/

Flixは多くのプログラミング言語にインスパイアされたオープンソースのプログラミング言語であり、開発者は関数型、命令型、論理型のスタイルでコードを書くことが可能である。FlixはScalaに似ており、Hindley-Milnerに基づく型システムとGoにインスパイアされた並行処理モデルを採用している。JVM言語はポリモーフィックエフェクトシステムやDatalog制約などのユニークな機能をサポートしている。

**デフォルトの名無しさん** · 2022/04/22(金) 20:34:28.61

>>153
どもです

https://www.ponylang.io/

フィンテックでアクターモデルのプログラミング言語Ponyを使う
https://www.infoq.com/jp/news/2016/05/pony-fintech/

Ponyはアクターモデルを使ったネイティブ言語であり、LLVMを使う。アクターモデルはErlangやAkkaで有名であり、1973年のCarl Hewitt氏他の論文から生まれた。アクターは状態管理と非同期メソッドを組み合わせる。フィールドに加え、アクターはひとつのメッセージキューとヒープを持つ。Clebsch氏によれば、Ponyのアクターは独立してガベージコレクションがされ、ErlangやAkkaとは違い、アクターそのものもガベージコレクションされるので、アクターを殺すためのメッセージのようなものは必要ない。手動でのメモリ管理は不要なのだ。

アクターは自分のヒープのガベージコレクションをmark-and-don’t-sweepアルゴリズムを使って他のアクターとは独立して行う。つまり、Ponyは到達可能なグラフに対してはnのオーダーだ。到達不可能なメモリは影響を与えない。アクターのヒープのGCにはsafepointがなく、読み込み、書き込みのバリアも、カードテーブルマーキングもコンパクト化もない。コンパクト化が必要ないので、ポインタのフィクスアップも必要ない。

**デフォルトの名無しさん** · 2022/04/22(金) 20:39:31.11

erlang系で何かしら伸びてこないのか

**デフォルトの名無しさん** · 2022/04/22(金) 20:56:20.88

>>156
Erlang系でElixirの次に来そうなのはGleamかな？
まだまだ新しすぎて未成熟だけど、着実にコミュニティが大きくなってる気がする

あとは他に33個ほどリストアップされてるから、なんか伸びそうなのあったら教えて
https://github.com/llaisdy/beam_languages

**デフォルトの名無しさん** · 2022/04/22(金) 20:57:22.84

>>152
Wasm自体は十分に実用的でブラウザ上からクラウドエッジ上に至るまで様々な環境での環境非依存言語の地位確立
ただしWasm仕様へのGC導入は未来の話へと先送り
したがって実用的なWasm記述言語としてはC/C++/RustのままとなりRustがベストチョイス

**デフォルトの名無しさん** · 2022/04/22(金) 21:14:40.69

>>158
LLVMが噛めばほぼ全てWasm対応になりうるので利点でもなんでもない
オレオレ言語でもWasmに対応できるというかすでに作った

**デフォルトの名無しさん** · 2022/04/22(金) 21:25:22.84

>>159
GC言語だと明確に不利なだけでもちろん動くよ
GCなし自作言語で良いものが作れたならばシェア取りに行くといいね
現状Rustの天下を崩すチャンス

**デフォルトの名無しさん** · 2022/04/22(金) 22:15:59.43

WEB+DB Press 127号で、
Elixir のPhoenix が、28ページの特集

Ruby on Rails 7, Phoenix 1.6 から、脱Webpack でesbuild へ

RailsのHotwire, PhoenixのLiveView で、websocket によるリアルタイム通信。
ここ数年、SPA でReact に奪われたシェアを回復すべき戦略

他には、Bootstrap よりも、Tailwind が多くなってきた

128号は、Terraform 特集。
Software Design 2022/1月号も、Terraform特集だった

YouTube で有名な、雑食系エンジニア・KENTA のRuby on Rails サロンでも、
Terraformで転職を差別化できると言ったから、すべての雑誌・学校も動いた

1つのサロンが転職に有効な技術を持ってしまうと、
他者が合格できなくなるので、対抗上、勉強しないといけなくなる

**デフォルトの名無しさん** · 2022/04/22(金) 22:38:59.17

Terraformが何なのかも理解せずにここプログラミング言語のスレに書き込んでいるのか

**デフォルトの名無しさん** · 2022/04/22(金) 22:55:47.09

リスナーさんだか受講生だか知りませんが、KENTAさんの主張を引用するなら本人から許可を取って、
情報の許可範囲とガイドラインを守って書き込みしたほうが絶対良いと思いますね。

匿名掲示板ならアレな発言も、多少は仕方ないかもしれませんが、
他人の名を語ってそれだとさすがにまずいです。倫理とルールを守りましょう。

**デフォルトの名無しさん** · 2022/04/22(金) 23:14:15.38

え本人が書き込んでるんじゃないのか

**161** · 2022/04/22(金) 23:17:44.40

KENTA

2021年のWeb系エンジニア転職を成功させる3つの技術要素、2021/4
https://www.youtube.com/watch?v=70VrB7LTe9g

Web系エンジニアを目指す人のためのプログラミング学習ロードマップ、2021/2
https://www.youtube.com/watch?v=0TABrlhci5M

上の動画で、Terraform で転職を差別化しましょうと言っている。
それで、すべての雑誌・学校も動いた。
Terraformが出来ないと、転職に負けてしまうから

米国人からすると、日本のRuby on Rails は異次元の戦い。
10年以上のプロでも、1年ぐらいの初心者に負けてしまう

日本では解雇できないから、資格などの事前審査制。
米国では国民全員がフリーランスだから、ひとまず雇っても、すぐに首にできる

**デフォルトの名無しさん** · 2022/04/22(金) 23:32:50.63

>>164
えまじで？

**デフォルトの名無しさん** · 2022/04/22(金) 23:40:10.10

KENTAさんは全エンジニアの輝きの星

**デフォルトの名無しさん** · 2022/04/22(金) 23:47:33.75

讃えよー敬えー

**デフォルトの名無しさん** · 2022/04/23(土) 05:52:57.97

>>165
相変わらずのゴミ動画

**デフォルトの名無しさん** · 2022/04/23(土) 07:28:43.83

>>151
RustがメモリをGC並みに雑に扱えたら、最高だったな。

**デフォルトの名無しさん** · 2022/04/23(土) 08:41:27.77

RcもWeakも無くなればね
裏で勝手にやってくれるとかして？
プログラマ側が一切ケアしなくて良いんならスゴイよね

**デフォルトの名無しさん** · 2022/04/23(土) 09:12:54.44

Goはコンパイル言語なのにスクリプト言語のように扱える軽量さが最大の魅力だろ
Go並にエディタの補完が軽量でコンパイル爆速のコンパイル言語を俺は知らない

Rustはライフタイムが全然わからなかったし、コンパイル遅すぎて無理だったね
GCはあった方がいいに決まってるわ
開発時の生産性が圧倒的に違ってくる

**デフォルトの名無しさん** · 2022/04/23(土) 09:17:17.05

GoはCGo何とかしてくれればもっと使う気になれるんだけどな

**デフォルトの名無しさん** · 2022/04/23(土) 09:20:09.97

とにかくGoは頭の悪い人でもすぐにプロジェクトに参加できるぐらいに機能がシンプルに削ぎ落とされていてコンパイル爆速ってのがポイントな言語
それに対して〇〇の機能がないーって言っても仕方ないだろ

頭の悪い人でも使いこなせる言語じゃないと企業ではなかなか普及しないと思うよ

**デフォルトの名無しさん** · 2022/04/23(土) 09:46:22.59

https://without.boats/blog/notes-on-a-smaller-rust/
だれかここで言われてる言語作ってくれ

**デフォルトの名無しさん** · 2022/04/23(土) 09:52:47.90

>>174
本当にその通りなんだけど、これだけは欲しかったみたいな機能も一緒に削られてるところが少しモヤモヤする
ジェネリクス(ようやく追加されたけど)とか代数的データ型とか

**デフォルトの名無しさん** · 2022/04/23(土) 10:30:02.86

>>172
ライフタイムがわからなかった、って、かなり知能が低い人じゃないとありえないと思うよ
そしてそのくらい低い人はプログラミングに向いていないと思う

**デフォルトの名無しさん** · 2022/04/23(土) 10:34:13.57

ライフタイムはわかるけどこれがリージョン推論とかいった厳密な理論とどう対応しているのかがわからん
一般的なプログラマーはここまで理解しなくてもいいんやろうけど
なんでこんな単純なわかりやすい原則の背後にそんな謎な人口に膾炙されていない理論を導入しないといけないのかがわからんわ

**デフォルトの名無しさん** · 2022/04/23(土) 10:59:59.69

荒らしなし規制無し

3ch
NEXT2ch
45ch

ふたばちゃんねる
明和水産

**デフォルトの名無しさん** · 2022/04/23(土) 11:09:11.96

>>178
ブロックスコープというあまりにも大雑把な大きな枠で扱うのではなくて
実際に使われている有効な範囲(リージョン)で細かく扱いましょう、というだけだよ
生存単位は前者で、借用単位は後者で細かく区切る
具体的コード例を含めた解説ページの例

Non-Lexical Lifetimes って？
https://qiita.com/_EnumHack/items/8b6ecdeb52e69a4ff384

**デフォルトの名無しさん** · 2022/04/23(土) 12:06:36.75

プログラミング言語「Erlang」を生んだジョー・アームストロング氏死去
なお、アームストロング氏は「なぜオブジェクト指向はクソなのか」という名文を残しています。

**デフォルトの名無しさん** · 2022/04/23(土) 12:41:02.85

>>177
プログラマーって言ってもOS作ったりドライバ作ったりする低レイヤーやってるのと、バックエンドやWeb系の高レイヤーやってるのはいるわけで
Rustは前者の人たちが使えばいいのでは？後者の人たちがRustがーとかイキってるの見ると笑ってしまう

後者の分野ではRustはGoに勝てないでしょう

**デフォルトの名無しさん** · 2022/04/23(土) 12:48:09.21

>>182
むしろGoは対象が狭くて短命に終わる言語
言語の機能不足で書きにくい上に速いわけではない
唯一のメリット(?)が仕様が簡素なこと

**デフォルトの名無しさん** · 2022/04/23(土) 13:26:27.68

>>182
勝ち負けの定義次第だけど後者でもrustの方が有利な場合はあるんじゃないの
discordのバックエンドの例とかあるよね

だいたいのケースでgoが適しているって主張なら分かるけど
特定の分野で常にgoの方が適しているというのは言い過ぎかと

**デフォルトの名無しさん** · 2022/04/23(土) 13:31:57.99

これだからRust信者は嫌なんだ...12年続いて厳格に互換性を保ってる言語が短命だって？
速いわけではないって、そりゃGCが裏で動いてメモリー解放をほとんど気にしなくて良い言語と比べれば、極限の速度では有利になるのは当たり前でしょ？
それでもC99やRustなどと比べても2倍も時間が掛かるわけではない、これを速いわけではないと表現するのは、自身でも気づいていないのか隠された悪意と偏見を持ちすぎてる。
むしろRustこそ後方互換を保つためなどと言いつつEditionなどという仕組みや、ボローチェックの強化なんて短命のコンパイルが通らないような事をして、短命で終わっている
今書いてるRustが10年後コンパイルが通るのかエラーになるのか全く見えない。普通の用途ではGoで十分という話に噛みついてくる
言語の表層的な機能をどんどん導入して直行性が無く、どんどん書きにくくなっていくのに苦労に見合う速度はC99以下。唯一のメリット(?)は意識高い系がたった1つの言語をやってればマウントできる事

**デフォルトの名無しさん** · 2022/04/23(土) 13:40:48.60

>>182
でも現実にWeb分野でもRustがじわじわと広まりつつあるよね
サーバ側はGoよりRustが高速で省メモリでGC負荷なしで有利
ブラウザ側は実用的となったWebAssemblyでRustが最適

**デフォルトの名無しさん** · 2022/04/23(土) 13:46:57.71

>>185
不勉強でよく知らないんだけどeditionやborrow checkerの強化でコンパイル通らなくなったcrateってどういうものがあるの？

**デフォルトの名無しさん** · 2022/04/23(土) 14:42:18.80

長文に構うなよ

**デフォルトの名無しさん** · 2022/04/23(土) 17:59:39.00

>>176
同感
必須機能が足りな過ぎてGoはプログラミングが修行のように辛い
C言語で何でも書けるというのと同じで書けるけど辛い

**デフォルトの名無しさん** · 2022/04/23(土) 18:14:41.34

>>186
コンビニに行くのにF1とかソーラーカーは要らない定期。どれだけ早かろうが省エネだろうが。
JavaやC#はセダン～バスみたいな感じかな。
Goは原付2種みたいなもんでしょ。
まず主戦場も違えばドライバーも違う。

**デフォルトの名無しさん** · 2022/04/23(土) 18:17:56.69

>>186
それでお前は使ってるの？
Reference Types使ってもパフォーマンスがjsに比較してカスな件どうなった？

**デフォルトの名無しさん** · 2022/04/23(土) 18:21:30.06

>>191
え？
JSとは誤差
そして何か処理するコード次第で圧勝

**デフォルトの名無しさん** · 2022/04/23(土) 19:02:24.78

もう一回貼っておきますね

https://zenn.dev/igrep/articles/2021-11-wasm-reference-types

PythonにおけるCFFIみたいな用途で使う分にはきっと問題無いんだろうね
特定の目的に対してはぴったりはまるんでしょうが
それを何の前提も付けず単に「実用的」と呼ぶのは誇大広告ではないんですかね

**デフォルトの名無しさん** · 2022/04/23(土) 19:03:19.39

最小限で考えると
Cにあとひとつ何かを加えたものでやっていけそう
Cに関数のオーバーロードがあればやっていけそう
コンテナクラスもほしいけどOOPを持ち込んでしまうので今回はパス
あくまで
void add(struct vector_int *v, int value)
void add(struct vector_float *v, float value)
というふうに関数と構造体だけで頑張っていけそう

**デフォルトの名無しさん** · 2022/04/23(土) 19:36:04.43

Cに拘ってる奴は本気でCが使いやすいと思ってるのか冗談で言ってるのか

**デフォルトの名無しさん** · 2022/04/23(土) 19:53:30.81

go よりはcのが好きかな

**デフォルトの名無しさん** · 2022/04/23(土) 19:57:28.78

>>195
下手な増改築だらけのC++よりCが良い
LinuxのLinusも同じ意見

**デフォルトの名無しさん** · 2022/04/23(土) 20:15:34.17

C言語にオーバーロード？
結局C++みたいにABI建て増ししてマングリングしないといけないやつじゃん

**デフォルトの名無しさん** · 2022/04/23(土) 20:18:18.40

Cは_Genericで頑張れば

**デフォルトの名無しさん** · 2022/04/23(土) 21:14:20.68

個人的いはCにがんばってほしい

**デフォルトの名無しさん** · 2022/04/23(土) 21:39:38.45

>>199
> _Generic

（´･∀･`）ﾍｰそんなのあるんだ勉強になりました
これあったら十分やわ

**デフォルトの名無しさん** · 2022/04/23(土) 21:51:54.89

ジェネリックってプログラミング言語によって指すものが異なってるよな
異なるといってもレベルの低いもの高いもの玉石混交という意味で

**161** · 2022/04/23(土) 23:08:55.47

IoT, AI でも、Elixir もある

Nerves は、最小のLinux, Erlang を含む、組み込み向けOS

Nx はテンソル用。
TensorFlow, PyTorch のフロントエンド

Erlang VM のFFI で、他言語のモジュールも使える

**デフォルトの名無しさん** · 2022/04/24(日) 00:35:10.40

Cは文字列が弱点だった
ちゃんとした文字列の型があればもっと便利だったとおもう

**デフォルトの名無しさん** · 2022/04/24(日) 01:36:20.84

nimはもっと広まって欲しいかな。できればpython置き換えるくらいに。

**デフォルトの名無しさん** · 2022/04/24(日) 06:41:49.87

>>197
てかLinusはそんなにその言語がいいと思ってるならそれでお前がなんか作ればいいだろって話をしてるな。
ここの連中なんかはまさにそんな感じだが。

**デフォルトの名無しさん** · 2022/04/24(日) 09:27:58.32

これはなかなか面白い記事だった
原点回帰というか、ここのスレでの議論にも参考になると思う
お前らの感想を聞きたい

How the C programming language has grown
https://opensource.com/article/22/3/how-c-programming-language-has-grown

**デフォルトの名無しさん** · 2022/04/24(日) 13:05:32.72

結局言語は道具。結局は何を作るかなんだよ

**デフォルトの名無しさん** · 2022/04/24(日) 14:03:27.44

ネイティブ言語に変換できるビジュアルプログラミング言語とかいいと思う
オブジェクト指向とかわかりやすいだろうし。
唯一問題なのはマウスとキーボードをせわしなく行き来することかな
以前Blockly使ってそんなの作ったけどソースコードどっかやっちゃった

**デフォルトの名無しさん** · 2022/04/24(日) 17:21:57.86

なんだァ？てめェ……

**デフォルトの名無しさん** · 2022/04/24(日) 17:26:29.56

そうです、わたすが変なおじさんです

**デフォルトの名無しさん** · 2022/04/24(日) 18:16:43.21

Rustのスレ複製おじさんが暴れまわってるから怖くなっちゃって見てないわ
あんなスレ見てたら気がおかしくなりそう
ここはまだまし

**デフォルトの名無しさん** · 2022/04/24(日) 19:14:30.43

頭おかしなるで

**デフォルトの名無しさん** · 2022/04/24(日) 19:46:35.09

>>181
「なぜオブジェクト指向はクソなのか」
１データ構造と機能は一緒にすべきではない
２すべてがオブジェクトである必要があります。
３データタイプ定義はあちこちに散らばってしまう
４オブジェクトはプライベートな状態を持っている

**デフォルトの名無しさん** · 2022/04/24(日) 20:04:13.90

最近はモジュールがまた流行ってるよね
rustもGoも自分から見るとモジュール指向に見える

自分はモジュール型からOOPに進化した過程を知ってるから正直モジュール型は好きじゃない

**デフォルトの名無しさん** · 2022/04/24(日) 21:17:36.80

＞すべてがオブジェクトである必要があります

C++やJavaみたいにすべてがオブジェクトじゃないオブジェクト指向言語なんていくらでもあるじゃん

**デフォルトの名無しさん** · 2022/04/24(日) 21:49:22.71

>>216
そういう意味じゃないよ
https://gist.github.com/posaunehm/4087971

**デフォルトの名無しさん** · 2022/04/24(日) 22:02:13.94

真のオブジェクトっていうのは、一つのスレッドみたいなもので他のスレッドとの通信をメッセージパシングでやりとりするものと言っていたような
一方、普通にいわれているオブジェクト指向というのは単なるプログラミングの書き方の効率化の手法にすぎないって話
つまり、継承という方法で差分だけ書いていけるようにすることによる効率化だけの話だってこと。

**デフォルトの名無しさん** · 2022/04/24(日) 22:04:35.47

差分プログラミングならまあクソでしょうね

**デフォルトの名無しさん** · 2022/04/24(日) 22:06:02.75

今のオブジェクト指向継承あんま使わなくね？

**デフォルトの名無しさん** · 2022/04/24(日) 22:09:28.03

むしろ継承はクソすぎて足を引っ張る
そのためGoやRustなどの言語ではclassを廃止というか最初から採用しなかった

**デフォルトの名無しさん** · 2022/04/24(日) 22:27:33.03

>>216
一言でいえば、プリミティブ型のことを言ってるんじゃなく（オブジェクトに）メソッドがぶら下がる粘着性を言っている。

いまどきの言語はRustやGoならstructで、Goならダックタイピング、Rustならクレートによるimplでそのデータを扱う機能実装を行うが
さらに考えを推し進め、D言語などでは(Pythonのself引数のように)データを引数に取るUFCと呼ばれる使い方も出来る。
関数が第一級の言語要素という考え（第一級関数）は、関数型言語には必要不可欠とされmap/reduceなどの高階関数でも
常用され、クロージャ・関数オブジェクト・無名関数と幅広く展開される。
OOPLとの明確な違いは、Classに対するオブジェクトにmethodという関数が束縛をされていないことである。もちろん上記の言語は
OOPSをサポートするが、それは多態を表現できるだけの意味しかない。

以上、D言語の宣伝です。

**デフォルトの名無しさん** · 2022/04/25(月) 00:02:30.63

>>222
> Rustならクレートによるimplで

ちょっと惜しい
『トレイトによるimpl』が正しい
その後にD言語は更に進んでいるとの宣伝と書いてあるようだが
Rustにも当てはまることばかりなので違いがよくわからない

**デフォルトの名無しさん** · 2022/04/25(月) 00:27:04.32

DのUFCSは任意の関数に適用できるけど
Rustは第一引数がselfなassociated functionだけだよね

**デフォルトの名無しさん** · 2022/04/25(月) 00:33:35.96

typescriptでclassを使わないでやったときに無限にf(g(h(x)))みたいに書いたなあ
tsにもほしいわ

**デフォルトの名無しさん** · 2022/04/25(月) 00:34:27.96

どうしてDって今のgoやrustみたいにならなかったの？

**デフォルトの名無しさん** · 2022/04/25(月) 00:35:54.45

DのUFCSもメンバ関数やネスト関数などには適用できない制限がある

**デフォルトの名無しさん** · 2022/04/25(月) 00:39:26.69

UFCSなんかなくても最初の引数の型に対してメソッド定義するだけで目的達成可能
グローバル名関数を増やして名前空間を汚さずともその型のメソッド定義がベター

**デフォルトの名無しさん** · 2022/04/25(月) 00:47:38.84

>>225
GoやRustはclassなんか無くても各型に対してメソッドを定義できるのでそういうことを招かずに済むのよ
UFCSのメリットはメソッドチェーン記法が可能になることだから最初からメソッドを定義すればいいものね

**デフォルトの名無しさん** · 2022/04/25(月) 00:55:00.32

>>229
structかenumは定義する必要あるじゃん
tsのtypeがどういうものか分かったうえでレスしてる？

**デフォルトの名無しさん** · 2022/04/25(月) 00:58:26.21

>>230
structやenumは単なるtypeだよ
C言語でもstructと(enumの代わりにタグ無しの)unionがあるよね(ただしメソッド定義はできないけど)

**デフォルトの名無しさん** · 2022/04/25(月) 01:21:04.73

Nim言語にもUFCSがあって関数だけじゃなくtemplateやmacroも関数と同じ文法で呼び出せるのでUFCSが使える。ただし第一引数がuntypedだとmethod call syntaxが使えない。
UFCSのメリットは標準ライブラリとか他人の書いたコードにある型とプロシージャの組に対してもmethod call syntaxが使えることだと思う。
第一引数が組み込み型のプロシージャを定義すれば組み込み型に対してmethod call syntaxが使える。
ライブラリAで定義されている型Xのオブジェクトに対してまったく別に書かれたライブラリBで定義されているgenericsなプロシージャをmethod call syntaxで呼ぶ出すことができる。

**デフォルトの名無しさん** · 2022/04/25(月) 01:28:09.79

>>230
structやenum以外でもOK
任意の型にメソッドを定義可能

**デフォルトの名無しさん** · 2022/04/25(月) 01:31:48.98

>>228
オーバーロードがある言語なら引数が一つ以上あるグローバル関数を追加しても引数さえ異なれば同名の関数をグローバルに追加できる。
UFCSとオーバーロードがある言語では第一引数がFoo型の関数を定義するのはFoo型にメソッドを定義することとほぼ同じとみなせる。

**デフォルトの名無しさん** · 2022/04/25(月) 01:35:52.92

つまりUFCSは汚染でありリスク要因
定義していないメソッドが使えることになってしまう
UFCSがなくとも明確にその型に対して定義されたメソッドのみ対象で実用上困ることはない