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

1 名前：デフォルトの名無しさん [2022/04/17(日) 17:52:35.38 ID:KG26dcth.net] スレタイ（順番はRedMonk準拠）以外の言語もok 前スレ 次世代言語24 Go Nim Rust Swift Kotlin TypeScript https://mevius.5ch.net/test/read.cgi/tech/1647887021/ 154 名前：デフォルトの名無しさん mailto:sage [2022/04/22(金) 20:15:46.28 ID:QUxpZq2Z.net] 言語じゃないけどWASMってどうよ 155 名前：デフォルトの名無しさん mailto:sage [2022/04/22(金) 20:25:25.90 ID:UKixTNef.net] >>149 Pony Rustよりも安全。データ競合だけでなく、デッドロック、実行時例外が起きないことも保証されてる actorモデルを採用している 156 名前：デフォルトの名無しさん mailto:sage [2022/04/22(金) 20:27:40.70 ID:aYwHbJz6.net] >>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制約などの� 157 名前：�ニークな機能をサポートしている。 [] [ここ壊れてます] 158 名前：デフォルトの名無しさん mailto:sage [2022/04/22(金) 20:34:28.61 ID:aYwHbJz6.net] >>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がなく、読み込み、書き込みのバリアも、カードテーブルマーキングもコンパクト化もない。コンパクト化が必要ないので、ポインタのフィクスアップも必要ない。 159 名前：デフォルトの名無しさん mailto:sage [2022/04/22(金) 20:39:31.11 ID:NkxiGfGV.net] erlang系で何かしら伸びてこないのか 160 名前：デフォルトの名無しさん mailto:sage [2022/04/22(金) 20:56:20.88 ID:UKixTNef.net] >>156 Erlang系でElixirの次に来そうなのはGleamかな？ まだまだ新しすぎて未成熟だけど、着実にコミュニティが大きくなってる気がする あとは他に33個ほどリストアップされてるから、なんか伸びそうなのあったら教えて https://github.com/llaisdy/beam_languages 161 名前：デフォルトの名無しさん mailto:sage [2022/04/22(金) 20:57:22.84 ID:MSzkRWeB.net] >>152 Wasm自体は十分に実用的でブラウザ上からクラウドエッジ上に至るまで様々な環境での環境非依存言語の地位確立 ただしWasm仕様へのGC導入は未来の話へと先送り したがって実用的なWasm記述言語としてはC/C++/RustのままとなりRustがベストチョイス 162 名前：デフォルトの名無しさん mailto:sage [2022/04/22(金) 21:14:40.69 ID:gmnEH6Vv.net] >>158 LLVMが噛めばほぼ全てWasm対応になりうるので利点でもなんでもない オレオレ言語でもWasmに対応できるというかすでに作った 163 名前：デフォルトの名無しさん mailto:sage [2022/04/22(金) 21:25:22.84 ID:p9LA8Dyp.net] >>159 GC言語だと明確に不利なだけでもちろん動くよ GCなし自作言語で良いものが作れたならばシェア取りに行くといいね 現状Rustの天下を崩すチャンス 164 名前：デフォルトの名無しさん mailto:sage [2022/04/22(金) 22:15:59.43 ID:AQMvQ4xM.net] 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つのサロンが転職に有効な技術を持ってしまうと、 他者が合格できなくなるので、対抗上、勉強しないといけなくなる 165 名前：デフォルトの名無しさん mailto:sage [2022/04/22(金) 22:38:59.17 ID:y1b9XJMs.net] Terraformが何なのかも理解せずにここプログラミング言語のスレに書き込んでいるのか 166 名前：デフォルトの名無しさん mailto:sage [2022/04/22(金) 22:55:47.09 ID:dDLjcogg.net] リスナーさんだか受講生だか知りませんが、KENTAさんの主張を引用するなら本人から許可を取って、 情報の許可範囲とガイドラインを守って書き込みしたほうが絶対良いと思いますね。 匿名掲示板ならアレな発言も、多少は仕方ないかもしれませんが、 他人の名を語ってそれだとさすがにまずいです。倫理とルールを守りましょう。 167 名前：デフォルトの名無しさん mailto:sage [2022/04/22(金) 23:14:15.38 ID:TXL8QlLI.net] え本人が書き込んでるんじゃないのか 168 名前：161 mailto:sage [2022/04/22(金) 23:17:44.40 ID:AQMvQ4xM.net] 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年ぐらいの初心者に負けてしまう 日本では解雇できないから、資格などの事前審査制。 米国では国民全員がフリーランスだから、ひとまず雇っても、すぐに首にできる 169 名前：デフォルトの名無しさん mailto:sage [2022/04/22(金) 23:32:50 ID:dDLjcogg.net] >>164 えまじで？ 170 名前：デフォルトの名無しさん mailto:sage [2022/04/22(金) 23:40:10.10 ID:BeccjQpB.net] KENTAさんは全エンジニアの輝きの星 171 名前：デフォルトの名無しさん mailto:sage [2022/04/22(金) 23:47:33.75 ID:dDLjcogg.net] 讃えよー敬えー 172 名前：デフォルトの名無しさん mailto:sage [2022/04/23(土) 05:52:57.97 ID:dsrvV+XF.net] >>165 相変わらずのゴミ動画 173 名前：デフォルトの名無しさん mailto:sage [2022/04/23(土) 07:28:43.83 ID:ebXv3GDe.net] >>151 RustがメモリをGC並みに雑に扱えたら、最高だったな。 174 名前：デフォルトの名無しさん mailto:sage [2022/04/23(土) 08:41:27.77 ID:X7wDySqh.net] RcもWeakも無くなればね 裏で勝手にやってくれるとかして？ プログラマ側が一切ケアしなくて良いんならスゴイよね 175 名前：デフォルトの名無しさん [2022/04/23(土) 09:12:54.44 ID:eZJZo8Wb.net] Goはコンパイル言語なのにスクリプト言語のように扱える軽量さが最大の魅力だろ Go並にエディタの補完が軽量でコンパイル爆速のコンパイル言語を俺は知らない Rustはライフタイムが全然わからなかったし、コンパイル遅すぎて無理だったね GCはあった方がいいに決まってるわ 開発時の生産性が圧倒的に違ってくる 176 名前：デフォルトの名無しさん mailto:sage [2022/04/23(土) 09:17:17.05 ID:kd0LPi6/.net] GoはCGo何とかしてくれればもっと使う気になれるんだけどな 177 名前：デフォルトの名無しさん [2022/04/23(土) 09:20:09.97 ID:eZJZo8Wb.net] とにかくGoは頭の悪い人でもすぐにプロジェクトに参加できるぐらいに機能がシンプルに削ぎ落とされていてコンパイル爆速ってのがポイントな言語 それに対して〇〇の機能がないーって言っても仕方ないだろ 頭の悪い人でも使いこなせる言語じゃないと企業ではなかなか普及しないと思うよ 178 名前：デフォルトの名無しさん mailto:sage [2022/04/23(土) 09:46:22.59 ID:o/e4rrgi.net] https://without.boats/blog/notes-on-a-smaller-rust/ だれかここで言われてる言語作ってくれ 179 名前：デフォルトの名無しさん [2022/04/23(土) 09:52:47.90 ID:XZjzYuNa.net] >>174 本当にその通りなんだけど、これだけは欲しかったみたいな機能も一緒に削られてるところが少しモヤモヤする ジェネリクス(ようやく追加されたけど)とか代数的データ型とか 180 名前：デフォルトの名無しさん mailto:sage [2022/04/23(土) 10:30:02.86 ID:19UflQcD.net] >>172 ライフタイムがわからなかった、って、かなり知能が低い人じゃないとありえないと思うよ そしてそのくらい低い人はプログラミングに向いていないと思う 181 名前：デフォルトの名無しさん [2022/04/23(土) 10:34:13.57 ID:WKX1mrZa.net] ライフタイムはわかるけどこれがリージョン推論とかいった厳密な理論とどう対応しているのかがわからん 一般的なプログラマーはここまで理解しなくてもいいんやろうけど なんでこんな単純なわかりやすい原則の背後にそんな謎な人口に膾炙されていない理論を導入しないといけないのかがわからんわ 182 名前：デフォルトの名無しさん mailto:sage [2022/04/23(土) 10:59:59.69 ID:BgAX+6b6.net] 荒らしなし規制無し 3ch NEXT2ch 45ch ふたばちゃんねる 明和水産 183 名前：デフォルトの名無しさん mailto:sage [2022/04/23(土) 11:09:11.96 ID:teuoZU8e.net] >>178 ブロックスコープというあまりにも大雑把な大きな枠で扱うのではなくて 実際に使われている有効な範囲(リージョン)で細かく扱いましょう、というだけだよ 生存単位は前者で、借用単位は後者で細かく区切る 具体的コード例を含めた解説ページの例 Non-Lexical Lifetimes って？ https://qiita.com/_EnumHack/items/8b6ecdeb52e69a4ff384 184 名前：デフォルトの名無しさん mailto:sage [2022/04/23(土) 12:06:36 ID:uMxflx63.net] プログラミング言語「Erlang」を生んだジョー・アームストロング氏死去 なお、アームストロング氏は「なぜオブジェクト指向はクソなのか」という名文を残しています。 185 名前：デフォルトの名無しさん [2022/04/23(土) 12:41:02 ID:lKjOluUR.net] >>177 プログラマーって言ってもOS作ったりドライバ作ったりする低レイヤーやってるのと、バックエンドやWeb系の高レイヤーやってるのはいるわけで Rustは前者の人たちが使えばいいのでは？後者の人たちがRustがーとかイキってるの見ると笑ってしまう 後者の分野ではRustはGoに勝てないでしょう 186 名前：デフォルトの名無しさん mailto:sage [2022/04/23(土) 12:48:09.21 ID:HJoWw7qN.net] >>182 むしろGoは対象が狭くて短命に終わる言語 言語の機能不足で書きにくい上に速いわけではない 唯一のメリット(?)が仕様が簡素なこと 187 名前：デフォルトの名無しさん mailto:sage [2022/04/23(土) 13:26:27 ID:o/e4rrgi.net] >>182 勝ち負けの定義次第だけど後者でもrustの方が有利な場合はあるんじゃないの discordのバックエンドの例とかあるよね だいたいのケースでgoが適しているって主張なら分かるけど 特定の分野で常にgoの方が適しているというのは言い過ぎかと 188 名前：デフォルトの名無しさん mailto:sage [2022/04/23(土) 13:31:57 ID:BV8u7mBP.net] これだからRust信者は嫌なんだ...12年続いて厳格に互換性を保ってる言語が短命だって？ 速いわけではないって、そりゃGCが裏で動いてメモリー解放をほとんど気にしなくて良い言語と比べれば、極限の速度では有利になるのは当たり前でしょ？ それでもC99やRustなどと比べても2倍も時間が掛かるわけではない、これを速いわけではないと表現するのは、自身でも気づいていないのか隠された悪意と偏見を持ちすぎてる。 むしろRustこそ後方互換を保つためなどと言いつつEditionなどという仕組みや、ボローチェックの強化なんて短命のコンパイルが通らないような事をして、短命で終わっている 今書いてるRustが10年後コンパイルが通るのかエラーになるのか全く見えない。普通の用途ではGoで十分という話に噛みついてくる 言語の表層的な機能をどんどん導入して直行性が無く、どんどん書きにくくなっていくのに苦労に見合う速度はC99以下。唯一のメリット(?)は意識高い系がたった1つの言語をやってればマウントできる事 189 名前：デフォルトの名無しさん mailto:sage [2022/04/23(土) 13:40:48.60 ID:j+9QGcWO.net] >>182 でも現実にWeb分野でもRustがじわじわと広まりつつあるよね サーバ側はGoよりRustが高速で省メモリでGC負荷なしで有利 ブラウザ側は実用的となったWebAssemblyでRustが最適 190 名前：デフォルトの名無しさん mailto:sage [2022/04/23(土) 13:46:57.71 ID:o/e4rrgi.net] >>185 不勉強でよく知らないんだけどeditionやborrow checkerの強化でコンパイル通らなくなったcrateってどういうものがあるの？ 191 名前：デフォルトの名無しさん mailto:sage [2022/04/23(土) 14:42:18.80 ID:iqGYI4s5.net] 長文に構うなよ 192 名前：デフォルトの名無しさん mailto:sage [2022/04/23(土) 17:59:39.00 ID:Yf3QCfCm.net] >>176 同感 必須機能が足りな過ぎてGoはプログラミングが修行のように辛い C言語で何でも書けるというのと同じで書けるけど辛い 193 名前：デフォルトの名無しさん mailto:sage [2022/04/23(土) 18:14:41.34 ID:DP+h97oH.net] >>186 コンビニに行くのにF1とかソーラーカーは要らない定期。どれだけ早かろうが省エネだろうが。 JavaやC#はセダン〜バスみたいな感じかな。 Goは原付2種みたいなもんでしょ。 まず主戦場も違えばドライバーも違う。 194 名前：デフォルトの名無しさん mailto:sage [2022/04/23(土) 18:17:56.69 ID:qKl7QP1V.net] >>186 それでお前は使ってるの？ Reference Types使ってもパフォーマンスがjsに比較してカスな件どうなった？ 195 名前：デフォルトの名無しさん mailto:sage [2022/04/23(土) 18:21:30.06 ID:FZleZnGe.net] >>191 え？ JSとは誤差 そして何か処理するコード次第で圧勝 196 名前：デフォルトの名無しさん mailto:sage [2022/04/23(土) 19:02:24.78 ID:qKl7QP1V.net] もう一回貼っておきますね https://zenn.dev/igrep/articles/2021-11-wasm-reference-types PythonにおけるCFFIみたいな用途で使う分にはきっと問題無いんだろうね 特定の目的に対してはぴったりはまるんでしょうが それを何の前提も付けず単に「実用的」と呼ぶのは誇大広告ではないんですかね 197 名前：デフォルトの名無しさん mailto:sage [2022/04/23(土) 19:03:19.39 ID:X7wDySqh.net] 最小限で考えると Cにあとひとつ何かを加えたものでやっていけそう Cに関数のオーバーロードがあればやっていけそう コンテナクラスもほしいけどOOPを持ち込んでしまうので今回はパス あくまで void add(struct vector_int *v, int value) void add(struct vector_float *v, float value) というふうに関数と構造体だけで頑張っていけそう 198 名前：デフォルトの名無しさん mailto:sage [2022/04/23(土) 19:36:04.43 ID:ugaeg6U2.net] Cに拘ってる奴は本気でCが使いやすいと思ってるのか冗談で言ってるのか 199 名前：デフォルトの名無しさん mailto:sage [2022/04/23(土) 19:53:30.81 ID:texCpgrl.net] go よりはcのが好きかな 200 名前：デフォルトの名無しさん mailto:sage [2022/04/23(土) 19:57:28.78 ID:stnqwczt.net] >>195 下手な増改築だらけのC++よりCが良い LinuxのLinusも同じ意見 201 名前：デフォルトの名無しさん mailto:sage [2022/04/23(土) 20:15:34.17 ID:qKl7QP1V.net] C言語にオーバーロード？ 結局C++みたいにABI建て増ししてマングリングしないといけないやつじゃん 202 名前：デフォルトの名無しさん mailto:sage [2022/04/23(土) 20:18:18.40 ID:o/e4rrgi.net] Cは_Genericで頑張れば 203 名前：デフォルトの名無しさん mailto:sage [2022/04/23(土) 21:14:20.68 ID:FKp57Oo8.net] 個人的いはCにがんばってほしい 204 名前：デフォルトの名無しさん mailto:sage [2022/04/23(土) 21:39:38.45 ID:X7wDySqh.net] >>199 > _Generic （´･∀･`）ﾍｰそんなのあるんだ勉強になりました これあったら十分やわ 205 名前：デフォルトの名無しさん mailto:sage [2022/04/23(土) 21:51:54.89 ID:w3sxk/eA.net] ジェネリックってプログラミング言語によって指すものが異なってるよな 異なるといってもレベルの低いもの高いもの玉石混交という意味で 206 名前：161 mailto:sage [2022/04/23(土) 23:08:55.47 ID:dSfqqc1i.net] IoT, AI でも、Elixir もある Nerves は、最小のLinux, Erlang を含む、組み込み向けOS Nx はテンソル用。 TensorFlow, PyTorch のフロントエンド Erlang VM のFFI で、他言語のモジュールも使える 207 名前：デフォルトの名無しさん mailto:sage [2022/04/24(日) 00:35:10 ID:tW7+nz8n.net] Cは文字列が弱点だった ちゃんとした文字列の型があればもっと便利だったとおもう 208 名前：デフォルトの名無しさん [2022/04/24(日) 01:36:20.84 ID:bAmVid1d.net] nimはもっと広まって欲しいかな。できればpython置き換えるくらいに。 209 名前：デフォルトの名無しさん mailto:sage [2022/04/24(日) 06:41:49 ID:4pJnSfn9.net] >>197 てかLinusはそんなにその言語がいいと思ってるならそれでお前がなんか作ればいいだろって話をしてるな。 ここの連中なんかはまさにそんな感じだが。 210 名前：デフォルトの名無しさん mailto:sage [2022/04/24(日) 09:27:58.32 ID:FwnGDc6j.net] これはなかなか面白い記事だった 原点回帰というか、ここのスレでの議論にも参考になると思う お前らの感想を聞きたい How the C programming language has grown https://opensource.com/article/22/3/how-c-programming-language-has-grown 211 名前：デフォルトの名無しさん [2022/04/24(日) 13:05:32 ID:LSLifE01.net] 結局言語は道具。結局は何を作るかなんだよ 212 名前：デフォルトの名無しさん mailto:shuang777gm@gmail.com [2022/04/24(日) 14:03:27.44 ID:plOa7TFC.net BE:557647423-2BP(0)] img.5ch.net/ico/2iyou_2.gif ネイティブ言語に変換できるビジュアルプログラミング言語とかいいと思う オブジェクト指向とかわかりやすいだろうし。 唯一問題なのはマウスとキーボードをせわしなく行き来することかな 以前Blockly使ってそんなの作ったけどソースコードどっかやっちゃった 213 名前：デフォルトの名無しさん mailto:sage [2022/04/24(日) 17:21:57.86 ID:uNEChMqn.net] なんだァ？てめェ…… 214 名前：デフォルトの名無しさん mailto:sage [2022/04/24(日) 17:26:29.56 ID:K5BkO09u.net] そうです、わたすが変なおじさんです 215 名前：デフォルトの名無しさん [2022/04/24(日) 18:16:43.21 ID:bl0Rasps.net] Rustのスレ複製おじさんが暴れまわってるから怖くなっちゃって見てないわ あんなスレ見てたら気がおかしくなりそう ここはまだまし 216 名前：デフォルトの名無しさん mailto:sage [2022/04/24(日) 19:14:30 ID:tfR0akyF.net] 頭おかしなるで 217 名前：デフォルトの名無しさん mailto:sage [2022/04/24(日) 19:46:35.09 ID:gbNK0/9l.net] >>181 「なぜオブジェクト指向はクソなのか」 １データ構造と機能は一緒にすべきではない ２すべてがオブジェクトである必要があります。 ３データタイプ定義はあちこちに散らばってしまう ４オブジェクトはプライベートな状態を持っている 218 名前：デフォルトの名無しさん mailto:sage [2022/04/24(日) 20:04:13.90 ID:tW7+nz8n.net] 最近はモジュールがまた流行ってるよね rustもGoも自分から見るとモジュール指向に見える 自分はモジュール型からOOPに進化した過程を知ってるから正直モジュール型は好きじゃない 219 名前：デフォルトの名無しさん mailto:sage [2022/04/24(日) 21:17:36.80 ID:slsDzRA2.net] ＞すべてがオブジェクトである必要があります C++やJavaみたいにすべてがオブジェクトじゃないオブジェクト指向言語なんていくらでもあるじゃん 220 名前：デフォルトの名無しさん mailto:sage [2022/04/24(日) 21:49:22.71 ID:+4D6Qx5V.net] >>216 そういう意味じゃないよ https://gist.github.com/posaunehm/4087971 221 名前：デフォルトの名無しさん mailto:sage [2022/04/24(日) 22:02:13.94 ID:4j4sWWkv.net] 真のオブジェクトっていうのは、一つのスレッドみたいなもので他のスレッドとの通信をメッセージパシングでやりとりするものと言っていたような 一方、普通にいわれているオブジェクト指向というのは単なるプログラミングの書き方の効率化の手法にすぎないって話 つまり、継承という方法で差分だけ書いていけるようにすることによる効率化だけの話だってこと。 222 名前：デフォルトの名無しさん mailto:sage [2022/04/24(日) 22:04:35.47 ID:uNEChMqn.net] 差分プログラミングならまあクソでしょうね 223 名前：デフォルトの名無しさん mailto:sage [2022/04/24(日) 22:06:02.75 ID:22aYjb+I.net] 今のオブジェクト指向継承あんま使わなくね？ 224 名前：デフォルトの名無しさん mailto:sage [2022/04/24(日) 22:09:28.03 ID:HH2OM4Tz.net] むしろ継承はクソすぎて足を引っ張る そのためGoやRustなどの言語ではclassを廃止というか最初から採用しなかった 225 名前：デフォルトの名無しさん mailto:sage [2022/04/24(日) 22:27:33.03 ID:L+Cr+2nK.net] >>216 一言でいえば、プリミティブ型のことを言ってるんじゃなく（オブジェクトに）メソッドがぶら下がる粘着性を言っている。 いまどきの言語はRustやGoならstructで、Goならダックタイピング、Rustならクレートによるimplでそのデータを扱う機能実装を行うが さらに考えを推し進め、D言語などでは(Pythonのself引数のように)データを引数に取るUFCと呼ばれる使い方も出来る。 関数が第一級の言語要素という考え（第一級関数）は、関数型言語には必要不可欠とされmap/reduceなどの高階関数でも 常用され、クロージャ・関数オブジェクト・無名関数と幅広く展開される。 OOPLとの明確な違いは、Classに対するオブジェクトにmethodという関数が束縛をされていないことである。もちろん上記の言語は OOPSをサポートするが、それは多態を表現できるだけの意味しかない。 以上、D言語の宣伝です。 226 名前：デフォルトの名無しさん mailto:sage [2022/04/25(月) 00:02:30.63 ID:m7DPUXtY.net] >>222 > Rustならクレートによるimplで ちょっと惜しい 『トレイトによるimpl』が正しい その後にD言語は更に進んでいるとの宣伝と書いてあるようだが Rustにも当てはまることばかりなので違いがよくわからない 227 名前：デフォルトの名無しさん mailto:sage [2022/04/25(月) 00:27:04.32 ID:GF+5hMbb.net] DのUFCSは任意の関数に適用できるけど Rustは第一引数がselfなassociated functionだけだよね 228 名前：デフォルトの名無しさん mailto:sage [2022/04/25(月) 00:33:35.96 ID:sDr1xuuT.net] typescriptでclassを使わないでやったときに無限にf(g(h(x)))みたいに書いたなあ tsにもほしいわ 229 名前：デフォルトの名無しさん mailto:sage [2022/04/25(月) 00:34:27.96 ID:LqFJ2u6k.net] どうしてDって今のgoやrustみたいにならなかったの？ 230 名前：デフォルトの名無しさん mailto:sage [2022/04/25(月) 00:35:54.45 ID:dSrWC4pO.net] DのUFCSもメンバ関数やネスト関数などには適用できない制限がある 231 名前：デフォルトの名無しさん mailto:sage [2022/04/25(月) 00:39:26.69 ID:cR9N6Lw+.net] UFCSなんかなくても最初の引数の型に対してメソッド定義するだけで目的達成可能 グローバル名関数を増やして名前空間を汚さずともその型のメソッド定義がベター 232 名前：デフォルトの名無しさん mailto:sage [2022/04/25(月) 00:47:38.84 ID:pTvSoM83.net] >>225 GoやRustはclassなんか無くても各型に対してメソッドを定義できるのでそういうことを招かずに済むのよ UFCSのメリットはメソッドチェーン記法が可能になることだから最初からメソッドを定義すればいいものね 233 名前：デフォルトの名無しさん mailto:sage [2022/04/25(月) 00:55:00.32 ID:sDr1xuuT.net] >>229 structかenumは定義する必要あるじゃん tsのtypeがどういうものか分かったうえでレスしてる？ 234 名前：デフォルトの名無しさん mailto:sage [2022/04/25(月) 00:58:26.21 ID:loxtuGTD.net] >>230 structやenumは単なるtypeだよ C言語でもstructと(enumの代わりにタグ無しの)unionがあるよね(ただしメソッド定義はできないけど) 235 名前：デフォルトの名無しさん mailto:sage [2022/04/25(月) 01:21:04.73 ID:W8ZZnspt.net] Nim言語にもUFCSがあって関数だけじゃなくtemplateやmacroも関数と同じ 236 名前：文法で呼び出せるのでUFCSが使える。ただし第一引数がuntypedだとmethod call syntaxが使えない。 UFCSのメリットは標準ライブラリとか他人の書いたコードにある型とプロシージャの組に対してもmethod call syntaxが使えることだと思う。 第一引数が組み込み型のプロシージャを定義すれば組み込み型に対してmethod call syntaxが使える。 ライブラリAで定義されている型Xのオブジェクトに対してまったく別に書かれたライブラリBで定義されているgenericsなプロシージャをmethod call syntaxで呼ぶ出すことができる。 [] [ここ壊れてます] 237 名前：デフォルトの名無しさん mailto:sage [2022/04/25(月) 01:28:09.79 ID:5Adpat0k.net] >>230 structやenum以外でもOK 任意の型にメソッドを定義可能 238 名前：デフォルトの名無しさん mailto:sage [2022/04/25(月) 01:31:48.98 ID:W8ZZnspt.net] >>228 オーバーロードがある言語なら引数が一つ以上あるグローバル関数を追加しても引数さえ異なれば同名の関数をグローバルに追加できる。 UFCSとオーバーロードがある言語では第一引数がFoo型の関数を定義するのはFoo型にメソッドを定義することとほぼ同じとみなせる。 239 名前：デフォルトの名無しさん mailto:sage [2022/04/25(月) 01:35:52.92 ID:V8fkjI23.net] つまりUFCSは汚染でありリスク要因 定義していないメソッドが使えることになってしまう UFCSがなくとも明確にその型に対して定義されたメソッドのみ対象で実用上困ることはない 240 名前：デフォルトの名無しさん mailto:sage [2022/04/25(月) 01:46:11.22 ID:GF+5hMbb.net] モジュールがあるなら関数のimport有無でどの関数が呼び出されるか制御できたりしないの？ Rustのtraitのuseみたいに 241 名前：デフォルトの名無しさん mailto:sage [2022/04/25(月) 01:55:33.57 ID:W8ZZnspt.net] >>235 UFCSのあるNim言語をよく使っているけど特に問題無く使えてるよ。 ライブラリAで定義された型を第一引数に持つ関数をライブラリAの外で定義してもgenerics/template/macroなど使わない限りライブラリAから呼び出せないし、ライブラリA内で使われている関数を外から勝手に上書きできない。 メソッド呼び出ししているように見えてもライブラリA内のプライベートな変数/関数はライブラリの外からアクセスできない。 method call syntaxってa.fooMethod(b)って書いてあるのを コンパイラがfooMethod(a, b)という関数呼び出しとして解釈しているだけでなんのリスクもないよ。 第一引数にFoo型のオブジェクトをとる関数を定義してもオーバーロードがあるのでFoo型を使わない人には何の影響も与えない 242 名前：デフォルトの名無しさん mailto:sage [2022/04/25(月) 02:05:19.36 ID:B7syBDSL.net] D言語のプロジェクト見て半笑いになるのやめてさしあげろ 243 名前：デフォルトの名無しさん mailto:sage [2022/04/25(月) 02:06:16.28 ID:W8ZZnspt.net] >>236 Nim言語だとimportするときにfrom std/strutils import `%`みたいに特定の型/関数だけをインポートすることができるよ。 もし同じ名前で同じ引数の関数が複数定義されている場合は関数名の前に"モジュルー名."をつけないとコンパイルエラーになる。 244 名前：デフォルトの名無しさん mailto:sage [2022/04/25(月) 02:34:25 ID:z8DQnMuR.net] 結局UFCSは不要だよな メソッド的に使いたいならば最初からその型にメソッドを生やせばよいだけ 必要ならばジェネリックに定義すれば複数の型に同時にメソッドを生やせる わざわざグローバル関数にしておいてからメソッド的に使えます！とかメリットを一切感じない 245 名前：デフォルトの名無しさん mailto:sage [2022/04/25(月) 02:47:04 ID:W8ZZnspt.net] >>240 標準ライブラリにある型とか他人のgithubリポジトリにあるライブラリにも自由にメソッド追加できるの？ ジェネリックにする必要が無いときでもジェネリックにしないとメソッドはやせないの？ Nim言語にはそもそもC++のメンバ関数みたいなのが無くて、第一引数がFoo型の関数がFoo型のメソッドの代わりみたいになっている。 246 名前：デフォルトの名無しさん mailto:sage [2022/04/25(月) 03:05:01.71 ID:hhhqUz2p.net] >>241 ジェネリックである必要なし もちろん同じ機能を複数の型に適用ならジェネリックで1回で済むのが普通 247 名前：デフォルトの名無しさん mailto:sage [2022/04/25(月) 03:21:57.26 ID:FFLrto9L.net] >>241 うん 標準ライブラリや第三者ライブラリにある型にもメソッドを増やすことができるよ だからUFCSが無くても困らないよ 248 名前：デフォルトの名無しさん mailto:sage [2022/04/25(月) 04:39:58.47 ID:W8ZZnspt.net] UFCSがあれば引数が一個以上持つ関数であればa.f(b)ともf(a, b)とも書ける。 a.f(b)とf(a, b)の両方で書きたい場合があったらどうするの? UFCSがなければa.f(b)で呼べるメソッドがあるときジェネリックな関数の中でf(a, b)の形式で呼ばれていたら、わざわざ新しくa.f(b)を中で呼ぶf(a, b)を定義しないといけない。 逆にf(a, b)な関数があったときに新しくメソッドを定義しなくてもa.f(b)と書ける。 それとNimだとcommand invocation syntaxがってf a, bという文法でも関数を呼べる。括弧がないので引数が複雑な式にならなければ書きやすくて読みやすいよ。 249 名前：デフォルトの名無しさん mailto:sage [2022/04/25(月) 05:29:11.29 ID:d+UJIvmE.net] >>244 Rustでも可能 例えばu64型のxに対して xのn乗はu64::pow(x, n)という関数が標準であるけど これはx.pow(n)と呼び出すことができる 250 名前：デフォルトの名無しさん mailto:sage [2022/04/25(月) 08:12:23.26 ID:7gaqSdm4.net] >>225 js/tsなら言語仕様拡張せんでも関数合成だろう。 251 名前：デフォルトの名無しさん mailto:sage [2022/04/25(月) 08:55:43.85 ID:VjXpH6fC.net] >>231 >>233 tsではどうやるの？ 252 名前：デフォルトの名無しさん mailto:sage [2022/04/25(月) 11:59:33.54 ID:QEeStXPn.net] >>241 既存の型にもメソッド追加できるよ 例えばJavaScriptならこんな感じ // 文字列にhello()を追加 String.prototype.hello = function() { console.log(`Hello ${this}!`); }; // 数値にhello()を追加 Number.prototype.hello = function() { console.log(`Hello ${this}!`); }; "abc".hello(); // 123.hello(); // 文法エラー let num = 123; num.hello(); 253 名前：デフォルトの名無しさん mailto:sage [2022/04/25(月) 12:16:38.60 ID:VSqj5wTk.net] Rustではジェネリックにメソッド追加することも可能 // メソッドhello()を持つトレイトHelloを宣言 trait Hello { fn hello(&self); } use std::fmt::Display; // 表示可能トレイトDisplayを満たす全ての型に対してhello()を実装 impl<T: Display> Hello for T { fn hello(&self) { println!("Hello {self}!"); } } fn main() { "abc".hello(); 123.hello(); } 254 名前：デフォルトの名無しさん mailto:sage [2022/04/25(月) 12:41:05.03 ID:GF+5hMbb.net] 既存の型へのメソッド追加はプロトタイプ汚染とか言われて忌避されてるよね 他モジュールへの影響の出ない形でメソッド追加する手法が望ましい

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef