24/02/08 17:55:44.80 TVrzLD8V.net
Rust で簡易アセンブラっぽいものを作ったことがあった (特に std を避けるとかしてない) ので
wasm で出力してみたけどだいたい 140kb くらいな感じ。
たぶん JavaScript で書いて最適化もすればもっと小さくは出来そうな感触はあるが
だからといって Rust でやって深刻に巨大すぎるということはない。
小さいプログラムのときでも Wasm は使い物になる。
いや、もちろん比較したら JavaScript で書いたほうがよいことも多いのだろうけど、
全くのアンチパターンってことはない。
481:デフォルトの名無しさん
24/02/08 17:56:24.51 ug5u5xxX.net
>>472
いやー、watでいいかな
482:デフォルトの名無しさん
24/02/08 18:26:36.73 d7zFncjn.net
Figmaはecmascripten使ってるそうだよ
C++で書いてWebGL用にコンパイル
おそらく世界最大のwasmコードだろう
URLﾘﾝｸ(www.figma.com)
483:デフォルトの名無しさん
24/02/08 18:29:10.38 d7zFncjn.net
今のところrustよりはecmascriptenの方が既存コードを活かせる
484:デフォルトの名無しさん
24/02/08 18:37:22.37 //05Mhwl.net
>>462
Next.js使ってるならサーバーサイドでSSGやSSRのためにJavaScriptを動かしてるってことだね
そこをRust化したいと思わないの？
485:デフォルトの名無しさん
24/02/08 18:41:39.17 d7zFncjn.net
>>478
next.jsはUI部分だけでバックエンドはRustだから特に必要性は感じないね
486:デフォルトの名無しさん
24/02/08 18:54:05.90 //05Mhwl.net
>>479
Next.jsでSSRなら毎回JavaScriptのコードが動くわけだけど
「バックエンドはRustだから」って？
外から受ける部分のサーバはRustでもそこからNext.jsを動かすためのNode.jsなどを呼び出すことになるよね
487:デフォルトの名無しさん
24/02/08 19:25:31.03 QINBs586.net
単にNext.jsがデータをフェッチする先のAPIエンドポイントがRust製ってだけだろ。
LBやらWebサーバーのような低レイヤがRust製かどうかみたいなのはそんなにユーザーに近いWeb屋が気にかけて手をいれる場所でもない。
488:デフォルトの名無しさん
24/02/08 19:29:46.46 0U3NNgcj.net
途中にビルド嚙ませれば同じにできるけど一般的にはCommonJSとECMAScriptで違う方言のJSでやり取りする事になるけどね
TypeScriptは使ってないから知らん
489:デフォルトの名無しさん
24/02/08 19:34:55.22 XA34Vq7w.net
>>480
Next.jsがまるで悪かのように言ってるけど、そんな遅いと思わんな
自分が求めてるレベルが低いだけなのかな
490:デフォルトの名無しさん
24/02/08 19:38:03.57 XODN4PGj.net
next.jsは普通に速いよ
ビルドがクソ遅いだけで
他のエコシステムはもっと高速なんだけどねえ
491:デフォルトの名無しさん
24/02/08 19:54:29.48 vWC2S6ww.net
サーバーサイドは可能な限りリソースコスト(クラウド代/ハード代電気代)を下げたい
Next.jsに限らずJavaScriptを含めた遅い言語の実行は避けたい
すべてをRust化するのが最善案
492:デフォルトの名無しさん
24/02/08 20:01:51.28 ZqeEswjg.net
Next.js(Nuxt.js)はどんなにクソだとしても使わざるをえないものなんだよね
Next.js以上のものはもはや作れんよ
493:デフォルトの名無しさん
24/02/08 20:03:16.79 XODN4PGj.net
それな
App Routerが神過ぎるんよ
これのおかげでサーバーサイドエンジニアが全てコントロールできるようになった
494:デフォルトの名無しさん
24/02/08 20:29:26.04 ZTHDKZhp.net
>>464
forthみたいで面白くない？
495:デフォルトの名無しさん
24/02/08 21:09:57.90 iGefvq8R.net
Next.jsがRailsの息の根を止めたわけだが、
React+Next.js+〇〇
このバックエンド部分の〇〇がRustが活かせるところ
496:デフォルトの名無しさん
24/02/08 21:15:13.68 fAoXwANU.net
>>486
>>487
ReactとNextの大改革されてきた歴史を知っていれば
数年後にはまた改善されて新たな導入が必ずある
497:デフォルトの名無しさん
24/02/08 22:03:30.31 z3hLjd3o.net
もう大きくは変わらないんじゃないか？
正直俺はPages Routerまでのnext.jsはゴミだと思ってたから使ってなかった
しかしApp Routerを見たときまさに俺の求めているものだと感じた
多分これが最高地点だよ
498:デフォルトの名無しさん
24/02/09 00:17:38.71 tjbjc/kZ.net
今はRuby on Rails でも、React/Next.js, TypeScript が転職で必須。
少し前は、Vue.js だったけど、Vue 3 は流行らなかった
Rails 7 からは、Hotwire に変わった。
HotwireはHTML Over The Wireの略で、
SPAの開発において、JavaScriptのコーディングを極力必要としない。
脱node.js, webpack
JSONではなく、HTMLベース。
サーバーサイドでHTMLを生成し、WebSocketでWebブラウザへ送信する
これで、Reactに取られたシェアを回復する
499:デフォルトの名無しさん
24/02/09 06:07:49.74 79P7yOqB.net
>>492
javascript使ったほうがラクなのになんでわざわざhtml縛りするの？
500:デフォルトの名無しさん
24/02/09 07:43:30.04 uUxbU3bY.net
Ruby信者はズレてるから仕方ない
501:デフォルトの名無しさん
24/02/09 07:53:26.10 cmMrL7Ws.net
SSRのsvelteはWebオーサリングツールから実画面に持っていきやすい
WebページのスクリプトにRust使えるブラウザとRust実装のsvelteを作ってもらいたい
502:デフォルトの名無しさん
24/02/09 08:55:44.38 so08h4Qi.net
SvelteもNext.jsもサーバーサイドでJavaScriptを動かすためエコじゃないのでいずれ新たなものに置き換えられるでしょう
503:デフォルトの名無しさん
24/02/09 09:34:26.12 Kdv0HxUE.net
std::any::type_name_of_val()は学習時にも良さそ
504:デフォルトの名無しさん
24/02/09 09:59:55.75 so08h4Qi.net
昔から使えるよ
fn type_name_of_val<T: ?Sized>(_val: &T) -> &'static str {
std::any::type_name::<T>()
}
505:デフォルトの名無しさん
24/02/09 10:27:55.96 C39eXNkM.net
>>493
JS使った方が楽という感覚は理解できんわ
506:デフォルトの名無しさん
24/02/09 13:19:22.70 YdTAf9YB.net
>>496
next.jsのapp routerがサーバーサイドフレームワークになったの知らないの？
507:デフォルトの名無しさん
24/02/09 13:59:04.29 wfDAL7tm.net
リソースコストがかかるスクリプト言語をサーバーサイドで動かしてる連中はいずれ消えるさ
508:デフォルトの名無しさん
24/02/09 14:16:42.17 YdTAf9YB.net
>>495
app routerの登場によりSSRだとかCSRとかややこしい概念は必要ない
あるのサーバーコンポーネントとクライアントコンポーネントとサーバーアクションのみ
極めてシンプルになった
509:デフォルトの名無しさん
24/02/09 15:05:02.67 7wM1u29W.net
どんどんrustの話から離れていってんな
510:デフォルトの名無しさん
24/02/09 15:19:56.77 d4LbU2O8.net
SSRやCSRがややこしいと感じる意味がわからん
Next.jsのPage Router時代の区別がややこしかったと感じてるだけとちゃう？
特定の実装とは関係のない概念としてのSSRやCSRは別にややこしくも何ともないでしょ
ReactのサーバーコンポーネントはNext..jsではサーバーサイドでレンダリング(HTML生成される)、つまりSSR
クライアントコンポーネントはクライアントサイドでレンダリングされる、つまりCSR
ついでに言うとHotwireみたいなのも仕組みとしての基本的な考え方は同じ
511:デフォルトの名無しさん
24/02/09 15:26:09.73 wyTCEkUp.net
Rustで引数の数を可変にしたいと思っただけでマクロが必要になるの、どういう思想なんだ
512:デフォルトの名無しさん
24/02/09 15:36:06.60 gZOHhCrR.net
>>505
型システムとの兼ね合い。
513:デフォルトの名無しさん
24/02/09 15:38:36.69 ixshWTAh.net
>>505
オプショナル引数 → 数が少ないならOption多いならbuilder
可変長の引数 → スライス
マクロを使うのは個々の引数の扱いがそれぞれ異なりそれぞれをコンパイル時に型をチェックしたい場合などに使う
514:デフォルトの名無しさん
24/02/09 15:52:26.69 IKpgt5UR.net
next.jsはRustフレンドリーなフレームワークだから実質Rustなんだよね
515:デフォルトの名無しさん
24/02/09 16:25:40.87 YdTAf9YB.net
>>504
その発想だとサーバーアクションは説明できないよ
516:デフォルトの名無しさん
24/02/09 16:28:31.07 YdTAf9YB.net
>>508
俺は将来的にnext.jsは全部rustで書きなおされると思ってる
517:デフォルトの名無しさん
24/02/09 16:37:49.82 DOCRBofH.net
>>504
概念自体はそっかという感じだけどそれを実装する方法があまりにもいけてなさすぎたんでしょ
App Routerはどこで実行されるか？だけを意識すればよろしい
518:デフォルトの名無しさん
24/02/09 17:13:49.98 wfDAL7tm.net
>>510
同感
519:デフォルトの名無しさん
24/02/09 18:59:39.30 wyTCEkUp.net
C++であれば関数のオーバーロードで実現していたようなことをRustでは全部封じてしまった結果、ライブラリは至る所マクロだらけ
これはRustの目指したいところなのか？
520:デフォルトの名無しさん
24/02/09 19:22:48.34 6IeD8Xf6.net
実行時の分岐ではなくコンパイル時のコード生成に置き換わるんだから
ゼロコスト抽象化という観点ではC++のほうがそちらを目指さな
521:ければいけなかったんじゃないでしょうか。
522:デフォルトの名無しさん
24/02/09 19:24:12.28 6IeD8Xf6.net
あ、可変長引数の話とオーバーロードの話を混同してしまっていた。
523:デフォルトの名無しさん
24/02/09 19:32:53.51 RpHX5dqz.net
URLﾘﾝｸ(qiita.com)
こういうの知ってたら
オーバーロードもデフォルト引数もいらね～
どうしてもほしけりゃ別名の関数作るわ
ってならん？
524:デフォルトの名無しさん
24/02/09 19:45:04.86 qkcXaSLH.net
別名の関数を作りたくなるのはわからんでもないけど、実際crates.ioはそうならずにマクロだらけなので
525:デフォルトの名無しさん
24/02/09 20:35:29.36 gZOHhCrR.net
田舎者は十年間使わない道具でも納屋にしまいっぱなしってことがまあまああるけど都会だとどんどん捨てるじゃん。
都会では物より空間のほうが高くつくから。
何が大事か、何を大事ということにするかで判断が変わる。
名前を考えるってのは人にとって思ったより負荷が高いということに対する解がオーバーロードなんだよ。
でもまあオーバーロードにもデメリットは当然ながらあるので結局は何を重視するかの問題。
526:デフォルトの名無しさん
24/02/09 23:53:50.41 qm1w3dJY.net
オーバーロードは無くてもいいけどキーワード引数は欲しいかな
527:デフォルトの名無しさん
24/02/09 23:59:48.02 D/1cks9J.net
>>519
あるよ
X { name: "foo", num: 123, ... }
528:デフォルトの名無しさん
24/02/10 02:54:22.21 rfU+NtYa.net
>>520
いちいちstructを定義しなくてもいいようにするためにキーワード引数って存在してるんだよ
529:デフォルトの名無しさん
24/02/10 09:13:20.91 KcmgHb9l.net
>>521
同じことだろ
関数の引数で列挙するか構造体で列挙するかで差はない
構造体で列挙しておけば関数の引数はその構造体名だけ出せばよい
他の関数でも使い回せるメリットもある
530:デフォルトの名無しさん
24/02/10 09:40:29.45 d2BF2Jtb.net
Rustでなぜデフォルト引数がサポートされてないのかはここでよろしく
URLﾘﾝｸ(www.reddit.com)
531:デフォルトの名無しさん
24/02/10 09:50:58.48 lXB6J68A.net
構造体を使うかビルダーパターンで困ることはないからね
もし技術的に矛盾のない他の良い方法があれば提案してみるべきだけど既出だと思うよ
532:デフォルトの名無しさん
24/02/10 09:54:14.05 Lf9bQLCg.net
ビルダーパターンは自分で書くならめんどい
533:デフォルトの名無しさん
24/02/10 10:07:03.72 iJNhxzEm.net
>>525
でも可視性があがるよ、あと保守が楽ちん
メリットいっぱいなんだよ✌
534:デフォルトの名無しさん
24/02/10 10:08:52.95 QvZInASK.net
ADAってどう？
535:デフォルトの名無しさん
24/02/10 10:22:50.56 iJNhxzEm.net
Adaってなんだと思って調べたら米国国防総省が主導のもとで開発されたプログラミング言語なんだね
後に開発されたC++やJavaに影響を与えたんだって
536:デフォルトの名無しさん
24/02/10 10:33:01.11 VP+Iax6j.net
>>490
OSSはなんだって始め数年は大改革されるもんよ
良くない作りは早めに治さんと後になったら大変になるから
逆にズルズル引きずって大変な事になったのがPython2&3だったりyum辺りだな
537:デフォルトの名無しさん
24/02/10 10:33:37.95 2jz47bNZ.net
パターンとかきしょすぎ
Javaみてえな文化
538:デフォルトの名無しさん
24/02/10 10:36:17.39 VP+Iax6j.net
>>501
スクリプト言語は人員が集めやすいから消えはしない
世の中は理想論じゃなく現実で回ってるんだから
539:デフォルトの名無しさん
24/02/10 11:15:35.75 6T66/lvp.net
>>522
えっ、マジで違いがわからないの？
キーワード引数の価値を理解できない人がいるとは
540:デフォルトの名無しさん
24/02/10 11:20:28.46 iJNhxzEm.net
>>530
悪いがデザインパターンの考えは大事だと主張させてもらうよ
可読性、保守性至上主義なので
541:デフォルトの名無しさん
24/02/10 11:21:55.77 xcSAMi5J.net
キーワード引数のような劣った方法より構造体あるいはビルダーパターンが絶対にいいぞ
デフォルト値はまとめてDefault実装でがっちりコードも書けるしな
542:デフォルトの名無しさん
24/02/10 11:24:20.16 iJNhxzEm.net
キーワード引数は>>523に書いてあるように、いまだ有用な実装が挙がってないから無い
数年後には有用な実装が提言されてるかもしれないから待て
543:デフォルトの名無しさん
24/02/10 11:32:26.22 iJNhxzEm.net
パターンにアンチ的な考えを持つのはお門違い
Webアプリにしてもコア部分のライブラリにしても、一般的なデザインパターンに基づいて設計されていればあとから雇った技術者に引き継がせるのが楽ちん
デザインパターンのうちのひとつ、ビルダーパターンだって可読性、保守性に優れてるから使われているんだ
544:デフォルトの名無しさん
24/02/10 11:53:44.03 H5a70urg.net
>>533
構文が優れていないからパターンみたいなキショいものが必要になる
誰が書いても同じようなコードになることを目指して開発されたPythonにはデザインパターンは必要ない
545:デフォルトの名無しさん
24/02/10 11:54:44.92 H5a70urg.net
可読性・保守性のために追加のパターンの勉強が必要だなんて信じられない
まるでJavaみたいだ
546:デフォルトの名無しさん
24/02/10 11:57:02.97 iJNhxzEm.net
>>537
だってPythonはデザインパターンを意識しないと保守が面倒になるような複雑に設計すること自体がアンチパターンじゃんか
547:デフォルトの名無しさん
24/02/10 12:00:29.93 iJNhxzEm.net
>>539 アンチパターンは言い過ぎか、Pythonにだってデザインパターンの基本的な原則はあるんだから
548:デフォルトの名無しさん
24/02/10 12:04:27.79 09Czk/ru.net
>>537
Pythonは欠陥プログラミング言語として知られているように酷い状況だよ
特に酷いと言われてるのはPythonにはinterface機能がないこと
抽象クラスで無理に実現しても劣りコードも汚い
Pythonはプログラミングはせずにあくまでもスクリプトとして用いる範囲内で使うのがよい
549:デフォルトの名無しさん
24/02/10 12:09:31.06 H5a70urg.net
まあでも言われて考えてみればbuilder patternなんてせいぜい「Pythonらしいコード」とかの範疇か
550:デフォルトの名無しさん
24/02/10 12:12:05.42 X5MB5Dp7.net
>>541
pythonにインターフェースがないのは、インターフェースが必要になるような製品にpythonで設計するなってことだぞ
551:デフォルトの名無しさん
24/02/10 12:13:49.11 H5a70urg.net
Pythonで抽象クラス使うくらいならProtocolでも使うかな
まあtrait使う方が良いのはそうかも
552:デフォルトの名無しさん
24/02/10 12:18:46.21 Gv6WNLHY.net
デザインパターンとかいうオブシコ要素をRustに持ち込むの迷惑だからやめろ
553:デフォルトの名無しさん
24/02/10 12:30:54.19 iJNhxzEm.net
パターンアンチが多いのか知らんけど、デザインパターンのうちクリーンアーキテクチャの考えは最低限習得しとくべきよ
フレームワークやライブラリと疎結合に実装しておけば保守性はばっちり
フレームワーク入れ替えのリファクタリングだって容易にできる
554:デフォルトの名無しさん
24/02/10 12:33:11.47 lBFnzKPs.net
いわゆる従来のデザインパターンと呼ばれているものは前提としてクラスやクラス継承を前提としているものが多い
そのためRustに持ち込んでも意味がないものやRustに持ち込む必要がそもそもないことが多い
Rustを理解していない人がRustを批判しようとして逆に失敗する一因にもなっている
555:デフォルトの名無しさん
24/02/10 13:01:44.04 YTHRY4oL.net
>>546
オブジェクト指向ありきのあの本はもうオワコン
読み返すとオブジェクト指向だらけで胸焼けするよ
556:デフォルトの名無しさん
24/02/10 13:16:33.29 8ut+BFv7.net
Rustスレにオブシコアンチの居場所はないぞ
Rustはオブシコの主要機能の2/3を取り入れてるんだから
557:デフォルトの名無しさん
24/02/10 13:20:09.17 LlCsSE+Z.net
>>537
Pythonもデザインパターン盛り盛りで作られてる
必要ないとか思っちゃってるのは経験が浅いだけ
558:デフォルトの名無しさん
24/02/10 13:24:24.95 RZD3J/dp.net
>>547
>いわゆる従来のデザインパターンと呼ばれているものは前提としてクラスやクラス継承を前提としているものが多い
この考えが間違ってるんだよなぁ
デザインパターンの特定の実装しか理解してない人とデザインパターンの実装例から導き出される原則まで理解してる人では見えてる景色が正反対になってしまう例だね
559:デフォルトの名無しさん
24/02/10 13:42:15.57 bXBK2+hH.net
>>541
Pythonではインターフェースを抽象クラスで代替できるってのと
Rustではキーワード引数を構造体で代替できるってのと全く同じことなんだよな
一言で言えばどちらも低DX
560:デフォルトの名無しさん
24/02/10 13:57:43.35 UK9hi/1i.net
>>552
それは全く違う
C++とRustにキーワード引数がないのは
リソース管理の問題があるためだ
つまり引数部分で色々やると
リソース獲得問題と解放問題などが生じてしまう
だからキーワード引数ではなぬ分離したほうが好ましい
561:デフォルトの名無しさん
24/02/10 13:58:54.16 iJNhxzEm.net
>>548
クリーンアーキテクチャはアーキテクチャパターンの中でもすごくシンプルだと思うぞ
とにかく関心の分離にこだわる、この考えに尽きる
まあ、これこそオブシコの中のオブシコの考えだからアンチは大嫌いなんだろうけど
562:デフォルトの名無しさん
24/02/10 14:03:55.89 lW9Vkr52.net
>>551
言いたいことはわかるがデザインパターンといえば
GoFと言われてるようではダメで
今のパラダイムに合った本が出ないとつらいかな
563:デフォルトの名無しさん
24/02/10 14:05:28.57 iJNhxzEm.net
デザインパターンといえばGoFは流石に古くないか？？
564:デフォルトの名無しさん
24/02/10 14:05:43.92 AU1t0rvZ.net
デザインパターンという言葉はGoFに汚染されているからな
デザインパターンという言葉を使うこと自体がアンチパターン
565:デフォルトの名無しさん
24/02/10 14:08:00.40 iJNhxzEm.net
デザインパターンが広義的すぎるのは分かる
デザインパターンではなくアーキテクチャパターンと表すべきだというのなら、まさにごもっともでございます
566:デフォルトの名無しさん
24/02/10 14:23:27.48 Aed3I3PZ.net
話がそれてるけどデフォルト引数（キーワード引数）がRustに無いのは現時点での仕様
デフォルト引数を使える点はPythonの勝ちだねおめでとう、じゃあPythonくんはブラウザバックしようか
567:デフォルトの名無しさん
24/02/10 14:40:14.16 XEL9SE6k.net
出来ることが多いほどいいってわけじゃないからなぁ。
「構造化は好きな場所にジャンプできないから欠陥のあるパラダイム！」とは言わんでしょ。
そんでそういうのは他の言語機能との連携とか諸事情を考えて決めるべきことだから
Rust でキーワード引数がないのは「今のところは」よいバランスの仕様が思いつかないでいるってだけ。
これから良いアイデアが出るかもしれないし出ないかもしれない。
568:デフォルトの名無しさん
24/02/10 14:40:53.07 b8HpDXca.net
>>559
いつからブラウザで見ていると勘違いしていた
569:デフォルトの名無しさん
24/02/10 14:42:22.10 YTHRY4oL.net
>>551
その導き出される原則がデザインパターンなんだが何か勘違いしてない？
570:デフォルトの名無しさん
24/02/10 14:46:24.04 VP+Iax6j.net
Javarが考えた設計は根本的に汚い
571:デフォルトの名無しさん
24/02/10 14:49:44.24 WFGhMJhr.net
オブジェクト指向におけるリスコフの置換原則もクラス継承を前提にしているように
一時期のオブジェクト指向はクラス継承を使うことが前提の狭い話が多かった
元々のオブジェクト指向はオブジェクトに値がカプセル化されてメソッドが公開されてればいい
クラスやクラス継承はオブジェクト指向に必須ではなく害悪のほうが大きい
そのためRustやGoなど多くのモダン言語がクラスを排除している
572:デフォルトの名無しさん
24/02/10 14:56:46.66 iJNhxzEm.net
>>563
Java？古いぞKotlinでだいぶキレイになった
>>401にも書いたけどclassに継承まわりの制限が設けられたのは可読性保守性においてgood
573:デフォルトの名無しさん
24/02/10 14:58:45.32 VP+Iax6j.net
いや、デザインパターンとかいうワードを声高に主張してたのって昔から大体Javarだったって話
574:デフォルトの名無しさん
24/02/10 14:59:40.15 iJNhxzEm.net
ついJavaという言葉に反応しちゃったけどよく見たらJavarだった…
575:デフォルトの名無しさん
24/02/10 15:00:30.74 iJNhxzEm.net
>>566
ごめん勘違いした>>565はスルーしてほしい
576:デフォルトの名無しさん
24/02/10 15:16:47.93 +PSgdWvA.net
・コンストラクタと関数を区別するのが面倒臭い
・関数とオブジェクトを区別するのが面倒臭い
・引数リストと普通のリストを区別するのが面倒臭い
デザパタの原則を導き出せばまあこうなる
577:デフォルトの名無しさん
24/02/10 16:24:25.37 YTHRY4oL.net
今こそ新しいソフトウェア設計の本が必要かもな
オブジェクト指向でも関数型でもない「ふつうのソフトウェア設計入門」みたいな
578:デフォルトの名無しさん
24/02/10 16:37:42.00 LPOrO1iz.net
継承抜きオブシコで十分っす
579:デフォルトの名無しさん
24/02/10 16:45:54.10 8zmdFTlm.net
なんでrustスレで他言語の雑談始まってしもたん
580:デフォルトの名無しさん
24/02/10 16:58:53.57 WFGhMJhr.net
>>572
他言語の話ではなく
デザインパターンの多くがクラスとその継承を前提あるいは例示していて
Rustなどのクラスを排除した最近のプログラミング言語に対して手法もしくは例示が適さない話かと
581:デフォルトの名無しさん
24/02/10 17:00:23.08 9OXXn/no.net
継承なんざインターフェースでいくらでも代用できるやん
応用力ないん？
582:デフォルトの名無しさん
24/02/10 17:09:17.38 qHcm0B3l.net
従来は継承を使ってカプセル化とポリモーフィズムを実現してたけど、最近は継承を使わずにカプセル化とポリモーフィズムやるのが主流よね
継承をサポートしないならクラスいらないし
583:デフォルトの名無しさん
24/02/10 17:37:53.51 lWs+b/Tw.net
Rustの型クラスは最強
584:デフォルトの名無しさん
24/02/10 17:45:44.24 cODs5/To.net
rustのデザインパターン本こそ現代のソフトウェア開発に必要なものだ
誰か出してくれ
585:デフォルトの名無しさん
24/02/10 17:48:42.70 7r8QxWN2.net
>>546
クリーンアーキテクチャとかアーキテクチャ設計レベルの話はデザインパターンの範疇ではないよ
デザイン(設計)のパターンではあるけど「デザインパターン」という言葉はもう一段階詳細レベルの話
586:デフォルトの名無しさん
24/02/10 18:00:46.16 5OwpQQMY.net
>>578
デザイン(設計)のパターンの中のひとつにGoFデザインパターンがあるのでは？
587:デフォルトの名無しさん
24/02/10 18:18:59.99 cODs5/To.net
>>578
クリーンアーキテクチャとかもろにオブジェクト指向だろ
588:デフォルトの名無しさん
24/02/10 18:20:18.08 iJNhxzEm.net
>>578
うん>>558でも言ったけどアーキテクチャパターンと言うべきだったすまん
589:デフォルトの名無しさん
24/02/10 18:22:04.19 /ZC4Oa+s.net
只の道具なんで、向いていれば適応するし、向いてなければ使わない。
宗教的な正しさなんてどうでも良いんですよ。
おまいらは政治将校か？
590:デフォルトの名無しさん
24/02/10 18:23:43.39 7r8QxWN2.net
実装パターン < デザインパターン < アーキテクチャパターン
すべてデザイン(設計)のパターンではあるけど対象とする粒度の違いで呼び名が違う
591:デフォルトの名無しさん
24/02/10 18:25:26.70 iJNhxzEm.net
Rustでよく使われてるパターンは
レイヤードアーキテクチャ
DDD
クリーンアーキテクチャ
なのかな？他にある？
592:デフォルトの名無しさん
24/02/10 18:26:30.51 iJNhxzEm.net
>>583
勉強になる👍
593:デフォルトの名無しさん
24/02/10 18:27:23.64 7r8QxWN2.net
>>580
そう感じるのはクリーンアーキテクチャをオブジェクト指向で実装した例だけを見て
クリーンアーキテクチャをオブジェクト指向の文脈でしか理解できてないからだと思う
594:デフォルトの名無しさん
24/02/10 18:29:37.58 +PSgdWvA.net
>>570
暴力でも寛容でもないふつうの非暴力闘争がいいのに
非暴力的な二項
595:対立まで否定するのは行き過ぎだよ
596:デフォルトの名無しさん
24/02/10 18:50:48.17 cODs5/To.net
>>586
そういう逃げは良くないぞ
例えばDDDはオブジェクト指向じゃなくても実現できる！と言ってるのと同じ
実質そのような原典は存在しない
独自解釈によるものにすぎない
597:デフォルトの名無しさん
24/02/10 19:06:04.16 kzqqrU6F.net
オブジェクト指向、スタック指向、手続き型しか知らないんだけど他になにがあるの？勉強したいから教えてくれ
598:デフォルトの名無しさん
24/02/10 19:08:51.93 kzqqrU6F.net
あと関数型と手続き型の区別がつかない
599:デフォルトの名無しさん
24/02/10 19:19:34.87 IjP+HezS.net
関数型はオブジェクト指向において部分的に使うもの
高階関数とかラムダ式とかはそんなに難しくない
600:デフォルトの名無しさん
24/02/10 19:31:34.99 76r5Dddg.net
>>590
一緒だよ
601:デフォルトの名無しさん
24/02/10 19:44:00.53 6ZZO7tOM.net
高階関数は「人間にとって」わかりにくくなるので使うなと
言われているね
あと論理型というのがあったなあ
602:デフォルトの名無しさん
24/02/10 19:47:12.54 IoMlesHJ.net
>>589
フロントエンド用途でコンポーネント指向
あと関数型というのは名前の通り関数に型を持たせたってだけ
高階関数と呼ばれてるね
オブジェクト指向に成り代わるものはいまだ出てきていない
603:デフォルトの名無しさん
24/02/10 19:50:32.36 H74b4wDc.net
オブジェクト指向信者の人達、その時々の優れたものをオブジェクト指向認定してるイメージがある
あるいはオブジェクト指向とはオブジェクト指向を名乗った言語の良いところどりおよびそれと重なる全てと定義していそう
オブジェクト指向信者もJavaは嫌いそう
604:デフォルトの名無しさん
24/02/10 19:52:30.82 IoMlesHJ.net
それはそうと継承の省かれたオブジェクト指向はオブジェクト指向と名乗るべきではないと思うんだが、新しい名前は無いの？
605:デフォルトの名無しさん
24/02/10 19:57:03.35 iu2BL++f.net
むしろ継承を省かれたぐらいでオブジェクト指向を名乗れなくなる方が意味不明なんだが。
606:デフォルトの名無しさん
24/02/10 20:00:09.44 lgwlEc8K.net
オブジェクト指向は単なる理論であって言語がどう実装するかは言語の勝手
607:デフォルトの名無しさん
24/02/10 20:03:05.61 6ZZO7tOM.net
狭義のオブジェクト指向言語は
データと操作を一つにまとめて型として使えるよ
ということだけ
カプセル化、継承、多態性をオブジェクト指向に入れるかどうかは
昔から諸説ある
608:デフォルトの名無しさん
24/02/10 20:03:30.97 WFGhMJhr.net
>>596
オブジェクト指向はオブジェクトの中に値(異種複数可)を閉じ込めてオブジェクトへの公開メソッドのみ公開すること
継承なんて概念はない
609:デフォルトの名無しさん
24/02/10 20:05:33.42 2iG7gUv6.net
なんかオブジェクト指向といいデザインパターンといい一般的な意味とは違うふうに捉えてる人が多いね
610:デフォルトの名無しさん
24/02/10 20:10:54.41 VlV2WaeL.net
オブジェクト指向かどうかはどうでもよくてどういうアーキテクチャで設計して実装するかが重要なんだけど
611:デフォルトの名無しさん
24/02/10 20:13:45.74 o2x+aGn+.net
関数型プログラミングがどこで使われてるのか調べてみたけどコンピューターサイエンス分野しか見つからない
612:デフォルトの名無しさん
24/02/10 20:22:15.34 6cZfMrU8.net
>>603
関数型プログラミングはただの手続き型プログラミングなんだから当たり前だろ
613:デフォルトの名無しさん
24/02/10 20:30:09.19 xWWw0qe+.net
フロントエンド屋か単にスクリプト組むくらいしかやらない人はオブジェクト指向に触れない
実装屋は逆にオブジェクト指向をベースにしたものばっかりやる
オブジェクト指向アンチの正体が分かっちゃうね
614:デフォルトの名無しさん
24/02/10 20:39:26.86 U5vUZCjE.net
手続き型を文芸的にしたのがオブジェクト指向で、数学的にしたのが関数型
615:デフォルトの名無しさん
24/02/10 20:46:30.71 lnD8LNvj.net
オブジェクト指向も関数型も確固たる定義がないバズワードだからな
話題にするだけ無駄
616:デフォルトの名無しさん
24/02/10 20:54:14.59 XEL9SE6k.net
グラデーション的だわな。
常識的な分類として「かなりこっち寄り」くらいに言えるものはあるけど。
文句なく関数型といえる汎用プログラミング言語は Haskell くらいか。
617:デフォルトの名無しさん
24/02/10 21:00:12.52 2fVxDtyX.net
オブシコアンチってなんでアンチやってるの？オブシコへのただならぬ恨みを感じるけど
618:デフォルトの名無しさん
24/02/10 21:04:41.79 hNXhuidE.net
勉強になるような知識どんどん書き込んでくれ
619:デフォルトの名無しさん
24/02/10 21:20:25.37 wHWIBAUz.net
オブジェクトを指向指向したら汚いコードがいっぱい出た
620:デフォルトの名無しさん
24/02/10 21:34:14.43 t6h0tc+k.net
オブジェクト指向自体には問題はなにもない
問題とされているのはオブジェクト指向ではなくクラス継承
これは実装継承となるアンチパターンなので使ってはいけない
621:デフォルトの名無しさん
24/02/10 22:00:16.03 EoWeXpbc.net
>>612
ここはRustスレで継承問題はクラス機能ごと排除することでとうに解決されているんだがなんで継承問題を擦ってるんです？
622:デフォルトの名無しさん
24/02/10 22:03:08.49 TERvB2uZ.net
みんながRustを使えば解決だね
623:デフォルトの名無しさん
24/02/10 22:07:13.96 a08tomEu.net
一部のRust信者の布教活動がひどかったせいで他スレ住人からさんざんヘイトを買い
普通のRust使いもクソどうでもいいこだわりを押し付けられるばっかりで
有益な情報が集まらないと判断しここを見限った
結果、ここが雑談部屋になることを止めようという勢力はRust信者だけになってしまった
624:デフォルトの名無しさん
24/02/10 22:12:14.65 Bpk68K+1.net
今どきRustだけしか使えない実装屋なんているわけなくて他の言語の雑談がちゃんと通じるからなにも問題ない
バイリンガルプログラマな姿こそ実装屋が目指すべきところ
625:デフォルトの名無しさん
24/02/10 22:14:50.40 XEL9SE6k.net
べつに実装継承でもそれ自体が問題ってわけではない。
実装継承が依存を強める (密結合) といったって実際に依存があるものが依存するのは当たり前だし仕方がない。
ただ問題なのは事前に適切な設計をすることもまた出来ないという現実があるってことだ。
プログラムを書き進めたら思ってのと違うかったというときに強固な依存があると軌道修正がしんどい。
626:デフォルトの名無しさん
24/02/10 22:26:31.80 ewSY5W0Q.net
継承は廃れた技術だから議論する意味がない
関心の分離を意識したプログラミングをしていこう
627:デフォルトの名無しさん
24/02/10 22:29:03.46 Lf9bQLCg.net
>>613
前にこのスレで話題になってただろ
Servoではポインタを使って無理矢理DOMの継承を実装してるとかなんとか
628:デフォルトの名無しさん
24/02/10 22:30:28.98 HLmY2iS7.net
>>619
なにそのアンチパターンww
俺らはこれを反面教師として頑張ろうな
629:デフォルトの名無しさん
24/02/10 22:42:16.36 +PSgdWvA.net
>>604
手続き型には関数とデータ構造がある
関数しか(抽象化され)ないというのはオブジェクト指向の視点からそう見えるだけだ
630:デフォルトの名無しさん
24/02/10 22:56:15.78 XEL9SE6k.net
関数型言語が言う関数ってのは数学用語の関数のことで、
引数と評価結果の関係で表現される。
C とか Rust とかがいう関数のことではないよ。
関数とは呼ばれていても値を返すサブルーチンであって関数ではない。
631:デフォルトの名無しさん
24/02/10 22:57:32.43 YTHRY4oL.net
いやマジレスすなw
632:デフォルトの名無しさん
24/02/10 23:01:02.32 2CpL/1KO.net
Deref使った継承もどきは委譲と変わらんよ
継承が敬遠されるのは変数、関数単位でfinalとかsealedで修飾したりprivate/protectedを使い分けないと
基底クラスで満たすべき不変条件を継承クラスでぶっ壊されてしんどいって話だから
基底クラスをブラックボックスで抱えて公開機能だけをそのまま公開する形なら全部委譲してるのと同じ
633:デフォルトの名無しさん
24/02/10 23:23:00.37 +PSgdWvA.net
正しい責任転嫁と悪い責任転嫁を区別するのが面倒臭いと思えば全部委譲でいい
正当化が必要と感じる人には継承が必要なのだろう
634:デフォルトの名無しさん
24/02/11 08:17:40.00 Jcf8p7/N.net
委譲やるよりインターフェースで共通項をもたせてポリモーフィズムできるほうがスッキリ実装できる
635:デフォルトの名無しさん
24/02/11 08:28:38.26 8+WjthrU.net
インターフェースでやるときこそ委譲の使いどころでは？
データレイヤーでのインターフェースRepositoryのImplからDataSourceの各メゾットを呼び出すのはまさしく委譲の考え
636:デフォルトの名無しさん
24/02/11 09:33:37.86 QXc2iF2X.net
オブシコ＝オブジェクト指向
で使ってるとやっとわかった。「あたしこ」の「しこ」かと勘違いして訳がわからなかったよ。
637:デフォルトの名無しさん
24/02/11 09:47:23.19 mQVY2wVN.net
>>627
レポジトリはドメインレイヤーがやるところでしょ
638:デフォルトの名無しさん
24/02/11 12:10:09.20 xzgPE83s.net
>>627
delegationとforwardingの区別が付いてないね
639:デフォルトの名無しさん
24/02/11 12:18:42.79 eNn3abAv.net
ここで数学用語ではなく、学校では評価されない用語を使うのがオブジェクト指向
640:デフォルトの名無しさん
24/02/11 13:10:55.53 5cbdJqGT.net
オブジェクト指向の良い所は真に賢い人は真面目に勉強しないしょうもなさと多彩な用語の数にある
だからオブジェクト指向言語を勉強した人間は真に賢い人間と競合することなくマウントを取ることが出来るようになる
641:デフォルトの名無しさん
24/02/11 13:30:06.52 UTHxd4xs.net
>>627
それは委譲ではない
継承と委譲とインターフェースは違うもの
642:デフォルトの名無しさん
24/02/11 14:12:49.22 tvA72CFJ.net
自分の使っている用語の定義に無頓着な人が賢いwとか有り得ない
643:デフォルトの名無しさん
24/02/11 14:28:55.59 FmT3HYkV.net
>>634
“賢い”の定義が違うんだろ
察してやれ
644:デフォルトの名無しさん
24/02/11 14:35:31.96 eNn3abAv.net
定義を後出しすることに罪悪感がない人はたぶんもっとリアルな悪を見慣れている
645:デフォルトの名無しさん
24/02/11 15:00:23.67 p0mJmxcL.net
Rustにはインターフェースは無くて型クラスはある
型クラスを推してけ
646:デフォルトの名無しさん
24/02/11 15:56:01.57 EVWrf4kv.net
>>634
その用語、定義ありませんよｗ
君が勝手に思い込んでるだけｗ
647:デフォルトの名無しさん
24/02/11 16:06:16.13 nNzLNGzY.net
オブシコ用語って掛け算順序界隈の主張する「等分除と包含除」とかの仲間だよね
648:デフォルトの名無しさん
24/02/11 16:16:18.76 +E66gntj.net
>>639
(^_^)ﾉ
649:デフォルトの名無しさん
24/02/11 16:21:31.17 cP74y9AE.net
時代はオブシコではなく関数型プログラミング
オブシコは時代遅れ
例えば機械学習は関数型プログラミングやってる
650:デフォルトの名無しさん
24/02/11 16:24:12.02 aCOYKxUA.net
>>637
型理論においてはどちらも同じ
651:デフォルトの名無しさん
24/02/11 16:30:25.25 O/MMVA2r.net
なんかみんな単発だからレスバできないなあ
652:デフォルトの名無しさん
24/02/11 20:46:34.90 XOn8R4o/.net
RustがJSを滅ぼしてくれるのはいつになるかいのう……
653:デフォルトの名無しさん
24/02/11 21:26:37.41 M/VumamL.net
まず先にDOMを滅ぼしてくれないとRustがウェブを乗っ取れない
DOMがJS依存すぎる
654:デフォルトの名無しさん
24/02/11 21:51:44.10 XOPhWcHA.net
DOMはJSに依存しないしいろんな言語のインターフェースがあるが。
655:デフォルトの名無しさん
24/02/11 22:42:14.41 575tRfGH.net
>>646
肝心のWasmにDOM操作を許可しないんじゃ意味ない
656:デフォルトの名無しさん
24/02/11 22:47:25.71 YLWTi6Ka.net
>>647
DOM操作自体はwasmでもできるぞ
オーバーヘッドが大きすぎて遅いだけ
657:デフォルトの名無しさん
24/02/11 22:56:40.04 Ij1X5KaV.net
>>648
Wasmから直接DOM操作は不可能
JavaScriptにやってもらうしかない
つまりJavaScriptしかできない
そのため単純なDOM操作だとJavaScriptが有利だが
Wasmで何らかの処理をしつつのDOM操作だとWasmが勝つことが増えていく
658:デフォルトの名無しさん
24/02/11 23:09:37.71 bi52uRem.net
自演ええて
659:デフォルトの名無しさん
24/02/11 23:36:32.19 BuG8Esm8.net
>>649
645だけど、だからDOM自体が欠陥品なんだって
JS依存の現状から脱却するにはDOMに変わるものが必要
660:デフォルトの名無しさん
24/02/12 00:40:57.30 cVfqqlnc.net
tree構造以外である程度の汎用性あるデータ構造なんてないわ。
661:デフォルトの名無しさん
24/02/12 01:04:43.36 tgn3NuIP.net
DOMに文句言ったところで何かが変わるわけじゃないからな
どうでもいい話
662:デフォルトの名無しさん
24/02/12 10:19:02.60 Autq7Dxb.net
>>651
現状JSからしか使えないってのとDOMに欠陥があるかどうかってのは全然別の話だと思うが。
663:デフォルトの名無しさん
24/02/12 10:33:25.13 QcKWCRm/.net
>>654
DOMには安全性のためにJavaScriptでしか触れないのは、DOMの出た当初は良かったが、JavaScript以外の言語も幅広く使われるようになった今ではその設計が古くなって欠陥品になってるのは事実
664:デフォルトの名無しさん
24/02/12 10:41:33.86 Autq7Dxb.net
DOMの設計と全然関係ない話。
665:デフォルトの名無しさん
24/02/12 10:51:22.86 dpV2oNnW.net
>>653
他人に文句を言うより自分で労働するという正義感は過労死の原因だよ
クレーマーはこの正義感を変えるじゃなくて既に変化した人
666:デフォルトの名無しさん
24/02/12 11:07:16.48 UiVeSAOt.net
domなしでのナビゲーションの方法があってもいいとは思う
667:デフォルトの名無しさん
24/02/12 11:08:30.75 CTu12wXT.net
いい加減にDOMはXMLをやめようぜ
無駄な構文が莫大な通信ロスを生んでる
668:デフォルトの名無しさん
24/02/12 11:23:28.89 u1N968/b.net
>>657
正義感w
自分でコントロールできないこととコントロールできることの判別こそ過労死しないためには最重要なんだけどね
DOMが欠陥品？
で？君はどうしたいんだい？
669:デフォルトの名無しさん
24/02/12 11:28:30.41 e3JrcLqa.net
>>655
昔DOMは他の言語からでも直接触れたがほぼ全て淘汰されてJSだけが生き残った
670:デフォルトの名無しさん
24/02/12 11:38:53.51 nlvJBCEb.net
DOMをゴミと言うのはWindowsをゴミと言ってるのと同等で無駄なこと
671:デフォルトの名無しさん
24/02/12 11:41:30.45 dpV2oNnW.net
やりたいことを先に固定してからそれに合わせて物事をコントロール可能にするという順序は逆にしたい
672:デフォルトの名無しさん
24/02/12 13:30:26.12 UkU83gVN.net
DOMの代替の候補って存在するのかな
673:デフォルトの名無しさん
24/02/12 13:49:21.10 3NLsFenn.net
>>662
Windowsはゴミだから個人も仕事からも排除した
しかしネットがWebベースのこの時代にWebブラウザは排除できない
DOMは取り扱わざるを得ない
とはいえRustによるWasmからの取り扱いは以前よりかなり状況が良くなってきている
まずReference Types の導入によりJavaScriptのオブジェクトをそのまま透過的にだがRust(Wasm)側でも持ったり返したりできるようになった
これはJavaScriptグルーコードの削減をもたらしている
さらにGC対応もメモリ管理のうちJavaScript側依存のものの扱いを任せられるようになりRustでも取り扱いが楽になる
Rust側の内部に閉じたデータのみメモリ管理すればよくなるからだ
674:デフォルトの名無しさん
24/02/12 15:41:26.64 QicyHe7E.net
デザインパターンはあくまで定石集なんだから、Rust用のデザインパターン作ればいいだけの話。
「Rustならこんなに簡単にできる」と自慢できるから、信者にとってもいいことかと。
あと、Rustでダックタイピングできたっけ？ 事前にTraitで定義しなきゃいけないんだったら面倒だなぁ。
675:デフォルトの名無しさん
24/02/12 15:46:26.73 FSKnAMMD.net
デザインパターンって簡単に実装できるとか
自慢するたぐいのものだっけ？
676:デフォルトの名無しさん
24/02/12 15:55:33.33 Jqge1vnq.net
単発NG推奨
677:デフォルトの名無しさん
24/02/12 15:56:29.31 9yTkyF6j.net
ドメインまわりをフレームワークと分離させる設計ならなんでもいいや
今後リファクタリングすることを考えた設計が大事
678:デフォルトの名無しさん
24/02/12 15:56:34.13 Jqge1vnq.net
ここはRustスレです消えてください
679:デフォルトの名無しさん
24/02/12 16:00:10.23 nHDMmyKy.net
>>666
ダックタイピングは動的型付け言語のためのオモチャであり
デメリットも多いためまともな言語はダックタイピングを排除して別の形を取っている
ダックタイピングは規律のない無政府状態であり可読性も下げデバッグもしにくくなり最悪となる
もちろん実行時の動的型付けの問題もはらんでおり自然の静的なチェックができない
680:デフォルトの名無しさん
24/02/12 16:11:47.85 KZYjz35/.net
ダックタイピングというゴミのような方法に対して
Rustはダックタイピングを採用せずに代わりに完璧な方法を用意した
それがtraitのrequired methodsとtrait boundsである
この二つにより全てを解決している
681:デフォルトの名無しさん
24/02/12 16:12:19.21 9yTkyF6j.net
ダックタイピングなんて荒業ではなく、ポリモーフィズムをやりましょ
682:デフォルトの名無しさん
24/02/12 16:23:13.06 cVfqqlnc.net
>>664
ない。結局まともに使えるものを用意しようと思えばああなる。
それも理解せずに馬鹿みたいに文句言ってるだけだわな。
683:デフォルトの名無しさん
24/02/12 18:20:41.31 g0MzjlGR.net
>>667
繰り返されれば飽きる
繰り返されないのはパターンではない
684:デフォルトの名無しさん
24/02/12 18:37:22.53 NJ55srXB.net
>>671
GoやTypeScriptみたいな静的片付け言語でもダックタイピング採用してるよ
nominal/structuralと動的/静的は直交
685:デフォルトの名無しさん
24/02/12 18:47:33.19 0RqNbR5g.net
Goは実行時にランタイムが動的にvtableを生成してメソッドlookupするわけだから
静的ではないでしょ？
そんなことはC++やRustでは許されない行為だよ
686:デフォルトの名無しさん
24/02/12 19:22:42.84 QavMz5Qe.net
>>676
TSはanyで型が消えてるときの話じゃないの？
687:デフォルトの名無しさん
24/02/12 20:01:03.19 uYjIYqfU.net
誰も定義の擦り合わせをしないのでどんどん意思疎通が困難になっていく
688:デフォルトの名無しさん
24/02/12 20:07:14.69 uYjIYqfU.net
一言居士の群れ
689:デフォルトの名無しさん
24/02/12 20:21:22.17 oZv/D2wt.net
ダックタイピングは一見するとお手軽に見えるけどプログラミング開発の足を引っ張る悪
Rustは排除しているので大丈夫
そしてRustではトレイト境界により確実に使えるものだけを呼び出せることを静的に保証しつつ用いる
690:デフォルトの名無しさん
24/02/12 20:24:19.09 H9LyWZwk.net
現代はデザインパターンで設計するんじゃなくフレームワークで作る時代だけどな
691:デフォルトの名無しさん
24/02/12 20:44:24.28 5CWzyU2K.net
>>682
そのフレームワークがデザインパターンで出来てるんだけど
692:デフォルトの名無しさん
24/02/12 21:02:02.43 g0MzjlGR.net
アルゴリズムはライブラリを一個作れば終わり
もう一個作ったら車輪の再発明
だがデザインのレベルではワンパターンが続いてもなぜか攻撃されない
693:デフォルトの名無しさん
24/02/12 21:59:54.43 QicyHe7E.net
>>673 >>677
c++ templateは静的ポリモーフィズムのダックタイピングの代表例だろ……
Rustのgenericsはどれくらいダックタイピングできているかね。
694:デフォルトの名無しさん
24/02/12 22:09:04.93 h7gv4DVB.net
>>685
C++の静的ポリモーフィズムはダックタイピングではない
ダックタイピングは実行時に動的に処理されるものだけを指す
例えばGoはinterfaceでダックタイピングするが実行時にランタイムが動的にitable (interface table)を生成して用いる
これは実行時に動的に処理されるためダックタイピングとなる
もちろん実行時に動的に処理するためダックタイピングはどの言語でも問題を孕んでいる
手軽さとの引き換えだ
695:デフォルトの名無しさん
24/02/12 22:14:48.84 YxZv/CkW.net
C++のtemplate（concepts無し）のダックタイピングが好きなら
genericsよりmacro_rules!の方がいいよ
696:デフォルトの名無しさん
24/02/12 22:15:23.35 JpOX7sRf.net
C++のtemplateで正しく関数を呼ぶの難しいよ……
697:デフォルトの名無しさん
24/02/12 22:30:02.58 DrV/13x2.net
>>677
静的型付けの意味から解説せなあかんのんか？
勘弁してくれよ
698:デフォルトの名無しさん
24/02/12 22:30:58.32 9yTkyF6j.net
C++はちゃんとコンセプト使わないとだめだよ
黒魔術は禁止です
699:デフォルトの名無しさん
24/02/12 22:50:06.45 kWCXoXun.net
C++のテンプレートは闇深すぎるよね
700:デフォルトの名無しさん
24/02/12 22:50:36.74 4VueJhli.net
>>686
C++ のテンプレートが受け入れる型は型同士の関係ではなくその性質に依存する。
一般的にもダッタイピングの典型例として挙げられることは多いし、静的か動的かで区別するという理屈を私が見たのはここがはじめてだ。
701:デフォルトの名無しさん
24/02/12 22:54:09.63 RSTU7X98.net
>>685
Rustのgenericsはtrait boundsにより完璧に静的に安全安心にチェックされ保証できる
702:デフォルトの名無しさん
24/02/12 23:33:02.01 g0MzjlGR.net
>>692
ダックタイピングの言い回しに前例はなくても原因はあるんだろう
そして原因はおれじゃない、あいつがやったという理屈は何度も見たことがある
703:デフォルトの名無しさん
24/02/12 23:52:54.50 Dj37TM3K.net
委譲やダックタイピングを理解してないのもどうかと思ったけど
↓これらの区別ができてないのは致命的だと思うので勉強しようね
静的型付け/動的型付け
静的ポリモーフィズム/動的ポリモーフィズム
静的処理/動的処理
704:デフォルトの名無しさん
24/02/13 00:30:00.87 xtMg5XLl.net
確固たる誰しもが認める定義のない言葉を勝手に定義してマウントとるのはやめよう？
705:デフォルトの名無しさん
24/02/13 02:23:26.95 vbRTXFPD.net
ファクトチェック界隈では事実かデマかが確固たる論点だよね
公式ルールか、ローカルルールか、という発想はそれ自体がマイノリティ
706:デフォルトの名無しさん
24/02/13 03:26:01.95 s0kRtfrq.net
オレオレ定義で擬似問題作るの止めろ。
ダックタイピングについてはWikipediaの解説でいいか。
ja.m.wikipedia.org/wiki/%E3%83%80%E3%83%83%E3%82%AF%E3%83%BB%E3%82%BF%E3%82%A4%E3%83%94%E3%83%B3%E3%82%B0
英語版が一番詳しいかね。
707:デフォルトの名無しさん
24/02/13 07:31:17.64 KlTxxkJG.net
>>683
フレームワークがデザインパターンのセオリー通りにできてるかって言ったら意外とセオリーを破って新しいムーブを作ったりするのはよくある
結局パターン通りに作る云々が論じられるのはフレームワークを使う側
708:デフォルトの名無しさん
24/02/13 08:18:01.41 EJGfS3Xj.net
>>699
アンチパターンや亜種になるだけで全部パターンだぞ
709:デフォルトの名無しさん
24/02/13 08:30:13.65 eXWviQcC.net
はじめにパターンありき、ではない
710:デフォルトの名無しさん
24/02/13 09:29:40.48 d0oThnC1.net
ダックタイピングはお手軽さを上回るデメリットだらけの悪手法
問題もなく安全で高速なRustのトレイト方式が最善策
トレイト境界により安全に呼び出せる範囲を明確にしてる点が要所
711:デフォルトの名無しさん
24/02/13 10:20:47.32 yeb3oliP.net
うちの講師が全てにおいてPythonに劣った言語って言ってるけどマ？
712:デフォルトの名無しさん
24/02/13 10:23:31.22 T85IlqBy.net
>>703
そんなわけないでしょ
713:デフォルトの名無しさん
24/02/13 10:29:29.95 iVxwtbvh.net
>>703
Pythonは遅いし本質でない実行時デバッグも大変だし
速くて実行前に静的に解決できるRustがベストな言語だよ
714:デフォルトの名無しさん
24/02/13 10:30:11.10 ep9QvdZW.net
>>703
その講師はメインでなにを教えてるん？データサイエンス？少なくともコンピュータ工学やメカトロニクスではなさそう
715:デフォルトの名無しさん
24/02/13 10:31:44.87 mnEJD8Sx.net
>>703
その講師優秀やな
716:デフォルトの名無しさん
24/02/13 11:11:21.55 mXdLEMzy.net
>>705
その講師も大概だがお前もデバッグをまともにやったことないだろ。
717:デフォルトの名無しさん
24/02/13 11:16:14.81 iVxwtbvh.net
>>708
Pythonは実行時に発覚するエラーが多すぎてプログラミング言語として辛いんよ
718:デフォルトの名無しさん
24/02/13 11:22:46.51 BKo58x30.net
ここまで俺の自演
719:デフォルトの名無しさん
24/02/13 11:32:02.27 mXdLEMzy.net
>>709
よっぽどレベル低いことしてない限りそこまでキツくはないわ。
むしろrustのビルド時間分使えばよっぽど楽にテスト構築もできるまである。
720:デフォルトの名無しさん
24/02/13 11:43:25.76 bOFev+sF.net
>>703
どーせデータ分析やデータサイエンスの講師だろ
くだらない釣りやめろ
721:デフォルトの名無しさん
24/02/13 11:46:14.62 bOFev+sF.net
まあどうせ荒らしのたぐいだろうから安価つけても無視されて無駄なんだろうな
くだらねえほんと
722:デフォルトの名無しさん
24/02/13 11:53:02.08 rA+hqhZ3.net
荒らしに構った時点でお前らの負け
723:デフォルトの名無しさん
24/02/13 11:57:48.21 qvC4XjeP.net
>>703が荒らし判定されてて草ww
724:デフォルトの名無しさん
24/02/13 12:05:17.83 n6Gkr1cM.net
>>702
trait boundはgenerics と型パラメータの相互依存が重たい気が。
c++ template & conceptみたいに、templateから型パラメータへの一方向依存になるように(型パラメータに指定される型はtemplateから独立するように)できたっけ？
725:デフォルトの名無しさん
24/02/13 12:09:09.09 IxuyFkNI.net
わかる→ Pythonで簡単なスクリプトを書く
キチガイ→ Pythonでプログラミング開発する
726:デフォルトの名無しさん
24/02/13 12:12:34.52 KvZIg8uL.net
Pythonでプログラム書くのもちゃんと型書いてlintしたら出来なくもないよ
727:デフォルトの名無しさん
24/02/13 12:15:32.69 1UgkqCq+.net
よく分からんが画像生成系のフロントエンドでrubyベースのってあったっけ？
728:デフォルトの名無しさん
24/02/13 13:03:33.72 X5Whr4lm.net
単発NG推奨
729:デフォルトの名無しさん
24/02/13 13:04:48.12 X5Whr4lm.net
単発NG推奨
連鎖あぼーん推奨
730:デフォルトの名無しさん
24/02/13 13:49:44.45 BKo58x30.net
スレNG推奨では？
731:デフォルトの名無しさん
24/02/13 14:10:44.85 q0xfm82v.net
また境界知能が暴れてんのか
いい加減諦めろよ
732:デフォルトの名無しさん
24/02/13 15:09:27.64 j+0n3+gu.net
C++20のコンセプトはゴミみたいなenable_if_tを使わなくてよくなって見やすくなったよね
まだまともに使う機会が来なくて慣れてないけど
733:デフォルトの名無しさん
24/02/13 19:22:36.57 ui4ZrT7T.net
XML大嫌い
734:デフォルトの名無しさん
24/02/13 20:34:52.16 u8WS3GIa.net
>>716
やりたいことがよく分からないけどtraitのassociation typeで解決しない？
I: Iteratorだと要素の型はI::Item（正確には<I as Iterator>::Item）になるみたいな
C++のconceptだとtypenameに相当するのかな
traitにgenericsの型パラメータ持たせるかassociation type使うかの判断は慣れるまで難しいけど
選択肢が複数あって外部から決められる ⇒ generics型パラメータ（例：AsRef<T>）
traitを実装するときに内部で自動的に決まる ⇒ association type（例：Deref::Target）
みたいに使い分けるといい
全部をgenericsの型パラメータでやろうとするとカオスになる
735:デフォルトの名無しさん
24/02/13 21:06:36.86 4D6oEUgV.net
>>716
できる
例えばこのように
URLﾘﾝｸ(docs.rs)
pub trait Service<Request> {
type Response;
type Error;
type Future: Future<Output = Result<Self::Response, Self::Error>>;
// Required method
fn call(&self, req: Request) -> Self::Future;
}
ここで型パラメタResponseとErrorはこのtraitを実装する各型に依存して決まり
型パラメタResponseは依存しない
736:"reply_link">>>726 その二種類の混合も可能
737:デフォルトの名無しさん
24/02/13 21:08:42.27 4D6oEUgV.net
ごめん
>>727はこうね
型パラメタResponseとErrorはこのtraitを実装する各型に依存して決まり
型パラメタRequestは依存しない
738:デフォルトの名無しさん
24/02/13 22:37:37.84 s0kRtfrq.net
ちょっと違うなぁ。
c++ template & conceptだと
wandbox.org/permlink/74j79ZQ3mbPb2cLO
みたいな感じでCircleはf()の影響を受けずに独立させることができる。
draw()メソッドというダックテストを満たせば他はどうでも良い。
Rustのgenericsだと
wandbox.org/permlink/CvepQKXOXaNTJoJm
みたいにCircleとf()の間にtrait Dという相互依存ができて、Circleを好き勝手に定義できなくなる。
f()が欲しいのはあくまでdraw()メソッドだけだから、双方にtrait Dが必要になるのは過剰な相互依存になる。
クラスの継承もそうだけど、余計な依存性は面倒だからできるだけ排除したいところ。
739:デフォルトの名無しさん
24/02/13 23:17:32.55 RVgq5WHA.net
それはgeneric constraintがnominalかstructuralかという違い
Rustはnominalのみでstructural generic constraintはサポートしてないよ
740:デフォルトの名無しさん
24/02/13 23:20:56.53 KlTxxkJG.net
Pythonは全てにおいてJuliaに劣った言語だな
741:デフォルトの名無しさん
24/02/13 23:28:47.57 u8WS3GIa.net
>>729
Circleを
fn f<T: Drawable>(t: &T) -> f64 { t.draw() }
に渡したいなら普通に
impl Drawable for Circle {
fn draw(&self) -> f64 { <Circle as D>::draw(self) }
}
を追加するな
コントラクトの明示を余計な依存関係だとは思わない
ちなみに
impl Circle {
fn draw() -> f64 {...}
}
みたいに本体のimplに定義するとCircleのself.draw()は全部こっちで解決されるから
impl Drawable for Circle {
fn draw(&self) -> f64 { self.draw() }
}
って書ける
１つの型に複数のtraitで同じ名前の関数を持たせるのはRustだとたまに見かける
impl Debugとimpl Displayはどっちもfn fmt()で別の実装するし
742:デフォルトの名無しさん
24/02/13 23:28:48.94 RVgq5WHA.net
>>726
>traitを実装するときに内部で自動的に決まる ⇒ association type（例：Deref::Target）
ある型に対するtrait実装をただ一つだけにしたいものや
自然と一つだけになるような性質のものはassciated typesを使う
使う側はassociated typesのほうが使いやすいので
悩んだらとりあえずassociated typesからはじめてみる
743:デフォルトの名無しさん
24/02/13 23:30:39.22 9eHJiOzP.net
>>729
そこはtrait介在させなきゃいけないところでしょ
Rustの方針が正しいと思うよ
744:デフォルトの名無しさん
24/02/13 23:32:24.97 RaqlAe+S.net
traitとかいうつまらない機能にこだわってないでPython極めろよ
時代はAIだぞ
745:デフォルトの名無しさん
24/02/13 23:35:00.89 8wj/C7pB.net
>>735
Rustをただ貶したいだけのやつは黙っとけよ雑魚
746:デフォルトの名無しさん
24/02/14 05:05:25.04 uLd8jazY.net
Pythonはスクリプト言語のクセにメソッドチェーンもロクに使えないうんこだからなぁ。
比較で持ち出すならせめてNimにしろよ。
747:デフォルトの名無しさん
24/02/14 05:28:01.52 uLd8jazY.net
>732 >734
Rustのtrait boundはあらかじめ型の方でtraitを準備しておかなきゃいけない。
これはRustが嫌っているクラスの継承みたいなもので、genericsやるごとに元の型/traitを弄くり回す必要が出てこない？
呼び出し元が真に必要なのは機能だけなんだから、同じ名前で互換性のある引数型・戻り値型ならそのまま利用できる方が良い。
まあ、ダックタイプみたいに手を抜かずにAdapter作れ、と言う方針でも良いけど、それならAdapter helperをもっと充実して欲しいところ。
AdapterパターンとかDecorator パターンて重要なのに言語側のサポート薄いよなぁ。
748:デフォルトの名無しさん
24/02/14 06:58:38.09 t2TEYrx/.net
>>738
>>これはRustが嫌っているクラスの継承みたいなもの
クラス継承は基底クラスの実装をそのまま継承する実装継承になっていることが問題点
一方でRustはトレイト境界となるトレイトに対して自分で実装を用意する
したがってRustでは実装継承とはならず問題が生じない
749:デフォルトの名無しさん
24/02/14 07:00:00.30 HWQ4xiFb.net
自演きもいなあ
750:デフォルトの名無しさん
24/02/14 07:00:27.71 523CbVaw.net
実装継承はゴミ
751:デフォルトの名無しさん
24/02/14 07:05:57.04 Uwd6Wtce.net
>>737
Ninはコンパイル時間の無駄があるからゴミ
Pythonは実行までの速度が一番早い
752:デフォルトの名無しさん
24/02/14 07:33:52.24 uLd8jazY.net
>>739
全然理解できていないね。
継承の問題点は、コンパイラ都合で早い段階で設計を固定しなきゃいけない「早すぎる最適化」。
機能とか実装の問題じゃなくて設計の問題。
753:デフォルトの名無しさん
24/02/14 08:08:30.71 b46uhNiQ.net
>>742
実運用はビルド済だから関係ないな。
754:デフォルトの名無しさん
24/02/14 08:09:58.02 t2TEYrx/.net
>>743
それは継承の問題点
Rustのトレイトは各型が自分で実装するため継承ではない
755:デフォルトの名無しさん
24/02/14 08:41:45.06 W3PM5KGQ.net
>>745
早すぎる最適化が問題なんだから、トレイトもその問題を引き継いでるぞ
756:デフォルトの名無しさん
24/02/14 08:51:32.74 t2TEYrx/.net
>>746
早すぎる最適化が問題になるのは継承
Rustのトレイトは継承ではなく合成で用いる
757:デフォルトの名無しさん
24/02/14 08:55:57.66 b46uhNiQ.net
>>745
全然理解できていないね。
>>743根は設計の問題で実装関係無いし、継承特有の問題というわけでもない。
>729というとfはDrawable以外のトレイトのdrawが使えない制限あるし、Circleも、問題領域に関する知識の少ない設計初期にtrait Drawableを実装するという仕様固定を行う必要がある。
c++のtemplate concept はあくまでdrawのみに依存するという違いがある。
758:デフォルトの名無しさん
24/02/14 09:07:35.89 L7EuZktb.net
真面目に理解したいなら>>730が正解だからstructural typingとnominal typingの意味を調べてくればいいよ
759:デフォルトの名無しさん
24/02/14 09:20:06.07 BSRmwKLd.net
>>729
C++は酷いな
struct定義の時点でdraw()宣言を要求してしまうのか
Rustなら
struct定義の時点でdraw()宣言を要求せずに済む
後からdraw()という機能(＝Drawableトレイト)が必要になった時点で
structに対してDrawableを実装すればいい
Rustの方が優れてるな
760:デフォルトの名無しさん
24/02/14 09:36:07.02 48k6rT3Y.net
>>738
複オジに毒されすぎ
オジが一つ覚えで繰り返し書いてる内容がRust開発陣の見解だと勘違いしないようにね
761:デフォルトの名無しさん
24/02/14 09:47:17.10 c6aYZ04m.net
>>738
根本的な理解がおかしいので説明すると
Rustのtraitは機能を抽象化している
各型はその機能が必要になった時にそのtraitを実装(impl)すればよい
必要な分の各機能(trait)を実装することで結果的に各機能の合成となる
762:デフォルトの名無しさん
24/02/14 09:59:07.19 YhuSf3ik.net
細かな実装上の違いはあるけど概念レベルでは Rustのトレイトも他言語のインターフェースも同じ
実装上の違いを見て異なる概念だと勘違いしてると本質を見失う
763:デフォルトの名無しさん
24/02/14 10:10:46.95 Z6/Yikm0.net
>>750
そりゃダックタイピングでdrawを使いたいんだから、drawの無い型は対象外。
>>752
もともとの話はダックタイピングでtraitじゃないよ。
Rustで静的ダックタイピング・ダックテストする方法はあるかしらん？
764:デフォルトの名無しさん
24/02/14 10:17:10.59 naKe/3pl.net
ダックタイピングという問題ありまくりのものを有り難がるのはバカだけ
765:デフォルトの名無しさん
24/02/14 10:27:45.39 s2Ev9A6j.net
>>738
言語側のサポートならマクロで十分でしょ
macro_rules! impl_drawable {
($type:ty) => {
impl $crate::path::to::Drawable for $type {
fn draw(&self) -> f64 { self.draw() }
}
}}
を定義すれば
impl_drawable!(Circle);
だけでimpl Drawable for Cirle {...}を生成できる
渡された型が同じ引数＆戻り値のself.draw()をもってないとコンパイルできないから実質ダックタイピング
Drawableに関数を追加したらマクロにも追加すればいい
draw関数の有無だけで照合するのは別の意味のdrawも対象になるから危なっかしい
impl traitだとどのモジュールのDrawableを実装するかまで指定できるから混同の心配がなくなる
766:デフォルトの名無しさん
24/02/14 10:44:54.87 AzS2pw5X.net
ダックタイピングは使う側が気をつければなにも問題ないんだよなあ
そこらへん理解してないあたり実装をやったことのないエアプなんだろうな
かわいそう
767:デフォルトの名無しさん
24/02/14 10:53:25.15 naKe/3pl.net
>>757
その「使う側が気をつければ問題ない」が最悪
ミスが入り込んだ時に気付かず問題を引き起こす
ダックタイピングを持ち上げるのはバカだけ
768:デフォルトの名無しさん
24/02/14 11:07:38.32 RfRsJx+N.net
使う側が気をつけるならC++も問題ないからな
769:デフォルトの名無しさん
24/02/14 11:17:22.43 NjTyhCIW.net
>>756
これがいわゆる実装継承の再発明
このケースはマクロよりも同じ実装継承のデフォルト実装のほうがベター
770:デフォルトの名無しさん
24/02/14 11:23:15.20 FEB+PUkj.net
>>759
そゆこと
だからRustは不要
771:デフォルトの名無しさん
24/02/14 11:28:02.15 naKe/3pl.net
ダメ人間の思想「使う側が気をつければ問題ない」によって
今まで数多のなかなか見つからないバグやセキュリティホールを生じてきたのがプログラミング言語の黒歴史
今後はそのような言語を用いてはいけない
772:デフォルトの名無しさん
24/02/14 11:51:49.92 L7EuZktb.net
ここで>>9-20の流れを振り返ってみましょう
773:デフォルトの名無しさん
24/02/14 11:52:42.46 3OoaoCBc.net
C の後置 ++ 演算子のようなことをする Rust の関数が標準で有ったりしますか？
リファレンスマニュアルをざっとみた感じでは見つけられないのですが……。
具体的に言えば
fn increment(dest: &mut u32) -> u32 {
let t = *dest;
*dest += 1;
t
}
みたいなことをしたくて、いかにもよくありそうなパターンなので標準内にあってもよさそうなもんだと思った次第です。
774:デフォルトの名無しさん
24/02/14 12:13:59.14 s2Ev9A6j.net
>>760
どこをどう曲解しても実装継承にはならんだろ
すべてのケースでマクロ使うとでも思ってるの？
〇〇の思考回路はよく分からん
>>764
Atomic系統ならfetch_addがあるけど普通のincrementは単純＆限定的すぎて逆にないな
std::mem::replace使えば
replace(&mut t, t+1)
とかできるけど+1するだけなら大袈裟すぎる気がする
775:デフォルトの名無しさん
24/02/14 12:19:27.37 Cdw7DngV.net
>>761
だから の文が全然繋がってなくてワラタw
こういう低能はプログラミングしちゃダメだよ。
776:デフォルトの名無しさん
24/02/14 12:25:13.12 b46uhNiQ.net
>>755
そうして無駄な依存関係を負の遺産として引きずるか、設計が破綻して再構築するか。
DbCとか勉強したほうがいいよ。
777:デフォルトの名無しさん
24/02/14 12:29:23.30 naKe/3pl.net
>>767
ダックタイピングが負の遺産であることは自明だが
ダックタイピングを使わないことが負の遺産だと主張する君は破綻している
778:デフォルトの名無しさん
24/02/14 12:49:07.16 b46uhNiQ.net
>>768
自明だと検証できる証明を示して頂戴。
検証可能性の無い主張は単なる疑似科学だし。
779:デフォルトの名無しさん
24/02/14 12:52:16.39 KpCwABm3.net
欠点がない言語なんて無いから言い争ってもね。
780:デフォルトの名無しさん
24/02/14 12:57:57.69 p6Tfi6cJ.net
そもそも人間自体が欠陥なんだからその人間の作った言語に欠陥があるのは自明
781:デフォルトの名無しさん
24/02/14 13:07:28.33 L7EuZktb.net
たし🦀
782:デフォルトの名無しさん
24/02/14 13:09:31.24 aR1xhX8a.net
おれたちは欠陥と共存してよりよいプログラミングスタイルを目指すべき
783:デフォルトの名無しさん
24/02/14 13:16:05.40 eD+V22zq.net
drawという名前のメソッドを作ったらそれらが全部ダックタイピングとして使われうることを想定しないといけないのきつすぎる
適当な名前つけたら想定外の使われ方をすることをケアしないといけないわけだ
784:デフォルトの名無しさん
24/02/14 13:33:10.33 Q08aEmFz.net
境界知能が可視化されてる
785:デフォルトの名無しさん
24/02/14 13:53:52.28 Z6/Yikm0.net
>>774
当たり前だろ。
インターフェイスは利用者に対する契約だからな。使わせる気が無ければ公開するな。
786:デフォルトの名無しさん
24/02/14 13:55:32.21 eD+V22zq.net
>>776
ダックタイピングはその契約書が定義されてないのが良くない
Traitは契約書の定義みたいなもんだ
ダックタイピングは白紙の契約書にサインするようなものだ
787:デフォルトの名無しさん
24/02/14 13:57:04.55 s22bd+Hs.net
>>775
お前のこと？
788:デフォルトの名無しさん
24/02/14 14:31:04.48 h4S8S2sP.net
>>777
これな
789:デフォルトの名無しさん
24/02/14 14:41:15.13 3OoaoCBc.net
>>765
replace だと借用規則に引っかかってエラーになるようです。
まあ自分で書いてもたいしたものじゃないのでなければなくても困りはしないんですが……
790:デフォルトの名無しさん
24/02/14 15:12:12.70 s2Ev9A6j.net
>>780
Copy型だから通りそうな気がしたけど無理だったか
何か技がありそうだけどそこまでするほどの問題じゃないよな
791:デフォルトの名無しさん
24/02/14 15:36:36.14 S2bQYQek.net
>>764
Rustで++は排除されている
理由はたくさんあるようだが
例えば今回のそのCコードは*dst++では動かず(*dst)++とする必要があるようにミスが増えるとか
前置と後置の間違いミスも多いことに加えて
生ポインタはsafe Rustから排除されたため*ptr++の形が出て来ないことや
move/copy問題もあったかな
792:デフォルトの名無しさん
24/02/14 16:02:27.29 3OoaoCBc.net
>>782
そんな話はしてないです。
役に立つことを言えないなら余計な茶々入れるな。
793:デフォルトの名無しさん
24/02/14 16:29:39.74 ona7PgM1.net
>>783
おまえ質問してる分際でキチガイなのか？
そういう態度を改めないなら二度と教えてやらんぞ
fn increment(dest: &mut u32) -> u32 {
std::mem::replace(dest, *dest + 1)
}
794:デフォルトの名無しさん
24/02/14 16:36:51.93 b+wxXawK.net
質問している人間相手なら関係ないことを書いて良いわけではない
795:デフォルトの名無しさん
24/02/14 16:42:22.39 3OoaoCBc.net
>>784
結果的に役に立たないことがあってもしょうがないですが、関係ないことをアンカーで書くのは正当化できない迷惑行為です。
質問者 (特に初心者？) には迷惑をかけてよいと考えているのだとしたらそれは改めるべき悪です。
796:デフォルトの名無しさん
24/02/14 16:46:13.61 L7EuZktb.net
ついに存在しないCコードの幻覚が見えるようになってしまった複製おじさん……
797:デフォルトの名無しさん
24/02/14 16:46:26.67 b+wxXawK.net
一方、質問文を誤読して解答してしまった人間に対して強く当たって良いわけでもない
798:デフォルトの名無しさん
24/02/14 16:51:03.66 3OoaoCBc.net
>>788
あれは誤読 (?) なんでしょうか。
茶化しているように受け取ったので腹立たしかったのですが、
そうだとしたら >>783 は言い過ぎですね。
ID:S2bQYQek さん、すいません
799:デフォルトの名無しさん
24/02/14 17:05:32.23 ZK4bCcm/.net
人間の注意力読解力は実際この程度なので、人間にC++を扱うことは難しい
800:デフォルトの名無しさん
24/02/14 17:06:20.11 Q08aEmFz.net
だから境界知能なんでしょ
801:デフォルトの名無しさん
24/02/14 17:19:45.82 qgmjNVo3.net
腹立てるのもわからなくはないがそんなにキレてレスするようなことではないだろ
気に入らなかったらスルーする程度には心に余裕を持っておこう
802:デフォルトの名無しさん
24/02/14 17:26:03.70 h4S8S2sP.net
tmuxよりscreen派だよ。
803:デフォルトの名無しさん
24/02/14 17:50:47.59 6CXfQ6Kw.net
個人的には後置インクリメントだけを関数化するのは微妙に感じる
fetch_addとかは必要性を理解できるけど単純なpost_addやpost_incrementは一段階上の処理を関数化するので十分でそのほうが見通しがいいように思う
804:デフォルトの名無しさん
24/02/14 19:51:05.67 7rKeAYke.net
>>762
こういう偉そうなこと散々言ってたhaskellがなぜ流行らなかったのかすら理解できてないというのが愚かだよね。
805:デフォルトの名無しさん
24/02/14 19:57:21.78 b46uhNiQ.net
>>777
c++ template conceptも碌に知らないでダックタイピングをけなしているのか。なかなか……
ダックタイピングは契約の主体・時期・範囲が違うという話だかね。
806:デフォルトの名無しさん
24/02/14 20:14:14.28 yh2p7tDo.net
>>796
C++では機能の異なる同名メソッドを区別できないから欠陥品
807:デフォルトの名無しさん
24/02/14 20:52:10.35 b46uhNiQ.net
>>797
引数・戻り値で区別できるだろ。
808:デフォルトの名無しさん
24/02/14 21:01:37.45 yh2p7tDo.net
>>798
それに依存してしまうのがC++の限界
809:デフォルトの名無しさん
24/02/14 21:18:41.79 b46uhNiQ.net
>>799
名前も引数も戻り値も区別できないんだったら、ダックタイピングで呼び出す側はそもそも区別する必要あるんですかねぇ。
810:デフォルトの名無しさん
24/02/14 21:58:58.38 H5X+9PTs.net
>>796
それだとRustでいうところのトレイト境界を課すことができないな
つまりC++では安全に呼び出すことができない
呼び出したメソッド内で出来ること出来ないことが定まらないため
811:デフォルトの名無しさん
24/02/14 22:13:29.10 uLd8jazY.net
>>801
「呼び出したメソッド内で出来ること出来ないこと」
て何？
Rustのtraitて、副作用のコントロールできたっけ？
812:デフォルトの名無しさん
24/02/14 22:26:20.82 8gvFvpJ5.net
traitのprovided methodのdefault実装で呼び出せるのはrequired methodと
trait境界がある場合はそのtraitのmethod
そしてそれらで構成された他のprovided methodのみ
って制限をC++でどうするんだろ
813:デフォルトの名無しさん
24/02/14 23:19:42.33 3OoaoCBc.net
>>803
コンセプト。
814:デフォルトの名無しさん
24/02/14 23:20:56.22 3OoaoCBc.net
>>792
毎度毎度のことで余裕を削られた最後だったんだよ。
815:デフォルトの名無しさん
24/02/15 00:20:11.01 AyUC+mx+.net
毎度毎度のことという認識を持っていながらなぜここに書き込むのか
816:デフォルトの名無しさん
24/02/15 00:23:07.31 x2y7hFPc.net
>>806
せやな。
けど日本で比較的活発な Rust コミュニティというとここなんよ。
817:デフォルトの名無しさん
24/02/15 07:06:08.60 13EQhuxe.net
>>804
concept記述が多すぎて書いててイヤになるな
普及しそうにない仕様がまたC++に増えた感じ
Rustが必要な機能を洗練して提供しているのと対照的
818:デフォルトの名無しさん
24/02/15 07:43:10.62 j4EJcuA3.net
>>808
洗練されすぎてて「早すぎる最適化」がバンバン起きるけどな。
枯れた既存プログラムの置き換え用途が無難なところかと。
コード破棄前提のプロトタイピングはコスト的にキツイか。問題領域の知識がほとんど無い開発初期で使えるのは未来を予測できる天才ぐらいだろ。
819:デフォルトの名無しさん
24/02/15 07:55:56.64 hKdVOM0D.net
>>809
Netflixの天才プログラマーが丸2年間Rustに全力費やして周りに吹聴した挙句に
RustやめてGoにする宣言してる
理由を真面目に話してるから一見の価値のあり
820:デフォルトの名無しさん
24/02/15 08:11:38.37 j4EJcuA3.net
>>810
検索したけど見つからなかった……
リンクある？
821:デフォルトの名無しさん
24/02/15 08:17:50.82 Me0Wd39H.net
[Why I Use Golang In 2024](URLﾘﾝｸ(www.youtube.com))
822:デフォルトの名無しさん
24/02/15 08:19:40.94 j4EJcuA3.net
>>812
サンクス。
家帰ったら見るわ。
823:デフォルトの名無しさん
24/02/15 08:48:36.69 UeUfm3Ct.net
>>812
見た
ほとんどの話がプログラミング言語の比較よりももっと抽象的な話で中身が薄い
そして批判されてるのはなぜかTypeScrpt
Goについてはシンプルなのが好きでジェネリックが導入されてワクワク
Rustはifに括弧がないのたスネークケースが嫌いだけどGoもifに括弧がないよ
Rustの型システムはとても素晴らしいけど、
824:デフォルトの名無しさん
24/02/15 09:52:51.93 x2y7hFPc.net
>>808
過去のコードと矛盾しない形での後付けだからな。
C++ を根本から変えるような大革新なのに (ほとんど) 互換性を損なわないように出来ているという意味ではかなり気が利いた設計ではある。
簡単に互換性を切り捨てていると資産が蓄積されないし、かといって変わらないままでもいられないのは宿命というもんだよ。
Rust だって歴史が積み重なればいずれそうなる。
「綺麗なのは使われないもの」という格言を聞いたことないか？
Rust は C++ の歴史のグダグダから学んだ反省としてエディションという概念を導入したが、これがどれくらい上手く機能するかは現時点では未知数だ。
規格策定・処理系保守のリソースは無限なわけではないしな。
825:デフォルトの名無しさん
24/02/15 09:55:25.99 LYiZEs3M.net
エディションはすでに複数あるけど
あっても無理とか問題起きるとか
実例あるの？
826:デフォルトの名無しさん
24/02/15 10:07:56.04 x2y7hFPc.net
>>816
問題が抑えられているのは問題がないように保守されているからで、
その体制を「ずっと」続けられるものかどうかはずっと続けてみないとわからない。
今問題があるとかそういう話じゃないから未知数と述べてる。
827:デフォルトの名無しさん
24/02/15 10:11:47.35 9MXGquuv.net
C++は貧弱な家を土台に増築工事をしまくって部屋数は多いが使われていない部屋だらけ
C++プログラマーの多くが知らない部屋、見たことない部屋、たどり着けない部屋が多数あるまま、さらに増築工事が進んでいる
828:デフォルトの名無しさん
24/02/15 10:21:13.40 qaCOVcST.net
まあいうてもRustも将来的には増築されたバケモノになるか途中で破壊的変更的なものを入れるかするかの選択になるのでは
Cから呼べてCを呼べる限りはどの言語を使っても良いとする立場であれば今一番使いたい言語はRustではある
829:デフォルトの名無しさん
24/02/15 10:32:36.57 LYiZEs3M.net
>>817
今は良くても未来は何が起こるかわからない論法は
何にでも使えるから意味ある話とは思えないけど…
830:デフォルトの名無しさん
24/02/15 10:37:24.02 x2y7hFPc.net
「出来る」ということを大前提として確信できて、
その上で「上手く出来る」ならより良いってのが産業的な考え方だ。
おおよその場合に上手く出来ても
ちょっとした想定外に直面したときに破綻するようでは使い物にならない。
現実の問題ってのは想定してないところから出てくるものだから
そういうことも乗り越えられることを証明するには
実績 (歴史) を重ねるしかしょうがないんだ。
C++ は上手くやったとは言えなくても、汚くても打てる手が有る道具として信頼を得た。
Rust は今の時点では実に使いやすいように見えるが、
本当の意味で現実の使用に耐えうるものなのかは現実に使い倒してみるまでわからない。
831:デフォルトの名無しさん
24/02/15 10:38:37.60 TrooctNX.net
今の時点で使いやすければなんでもいいんだYO
832:デフォルトの名無しさん
24/02/15 10:45:22.07 9MXGquuv.net
C++コンパイラが諸問題を指摘してコンパイルエラーにしてくれる状況は来そうにない
これだけ増築工事を重ねてもまだ見込みが立たないまま
833:デフォルトの名無しさん
24/02/15 11:47:28.36 olqTmpaN.net
C++の知識は大いに再利用されているので現実世界の変化は小さい
想定外かもしれないのは変化の大きさではなく
現実世界を定義できないことだ
定義できるのは理論だけ
834:デフォルトの名無しさん
24/02/15 12:02:34.79 oxTsPXaA.net
>>821
今の想定が甘いとか具体的指摘なかったら
想定外の対処ができてないから駄目は無敵論法
835:デフォルトの名無しさん
24/02/15 14:40:35.94 wvzNp0zm.net
そりゃWeb系だとGoのほうが使いやすいに決まってるでしょ
パフォーマンスもスクリプト言語よりはめちゃくちゃ速いから十分
836:デフォルトの名無しさん
24/02/15 14:47:01.34 z+RD4XEG.net
サーバーサイドは群雄割拠時代よね
Rust、Go、Java/Kotlin、C#いっぱいある
837:デフォルトの名無しさん
24/02/15 16:20:13.71 x2y7hFPc.net
>>825
駄目とは言ってない。
駄目かどうかも「わからない」ことが産業的なハードルだよねって話なんだが、わからんかな。
838:デフォルトの名無しさん
24/02/15 16:46:19.25 606b12LT.net
>>828
あなたの話相手してもrustでも他言語でもいいけど
問題回避のためにこういう仕様や実装にすべきじゃないか
みたいな議論が成り立たないのでそちらがおよそ産業的じゃないね
839:デフォルトの名無しさん
24/02/15 16:50:52.01 olqTmpaN.net
すべてを疑っても産業だけは疑いようがないって話なら
想定内と想定外の境界がどの辺にあるのかはなんとなくわかる
840:デフォルトの名無しさん
24/02/15 17:21:54.77 SzbBTI0k.net
>>814
Rustは型〇ナニーで長時間バトルだったと言ってるぞw
>>812動画の人がいくら天才でも2年間かき回したのは頂けない
841:デフォルトの名無しさん
24/02/15 17:26:25.25 BHoNDVf7.net
Rustは非同期処理がC++より扱いやすいおかげでサーバー方面に進出したのは良い
さすがにフロントでRustは微妙そうだけど、このままどんどん多方面に普及してほしい
842:デフォルトの名無しさん
24/02/15 17:31:26.55 dtRRoOMy.net
Ruby は、Go/Rust/Elixir の3大言語を超えた！
Rust の上昇は止まったか？
Stack Overflow 米国年収。2022 -> 2023
Ruby : 9.3 -> 9.9 万ドル
Elixir : 9.3 -> 9.6
Go : 8.9 -> 9.3
Rust : 8.7 -> 8.7
多くの言語 : 6.5～7 -> 7.3～7.8
PHP : 5 -> 5.9
Dart : 4.4 -> 5.6
843:デフォルトの名無しさん
24/02/15 17:35:21.87 eOw5Ad1t.net
>>832 夢見てないで現実見ては？
URLﾘﾝｸ(active.nikkeibp.co.jp)
844:デフォルトの名無しさん
24/02/15 17:41:41.98 wvzNp0zm.net
>>812
流し聞きしたけど複雑だとかしょーもない構文の好き嫌いみたいな話しかしてなくて草
845:デフォルトの名無しさん
24/02/15 17:53:07.0
846:4 ID:8jpdfcc8.net
847:デフォルトの名無しさん
24/02/15 18:08:05.70 uSGIT3N+.net
>>834
せめて用途別のプログラミング順位を挙げてくれ
…単発に言っても無駄か😭
848:デフォルトの名無しさん
24/02/15 18:08:23.00 giVh/goG.net
Goは２年も続けられるだろうか
大分前に少し使ってみたけど例外投げずにResult（タプル）で返す言語設計を採用しながら
返されたResultを無視してもコンパイラが警告出さないからやめた
Cで戻り値のエラーをスルーする事案が多発したから後発言語で例外が作られたのに
↓を見て気持ち悪さを感じる人には向かない
file, err = os.Open(path) // ← fileと一緒にエラーの受け取りを強要される
os.Chdir(path) // ←エラーしか返さないから戻り値を無視して処理を継続できる
849:デフォルトの名無しさん
24/02/15 18:11:15.85 x2y7hFPc.net
>>829
情報が充分じゃない (から議論を始めることさえできない) ことが
リスクだという話をしているつもりなんだが、伝わってないのか？
どんな問題が起こるのか事前にわかれば苦労しないよ。
起きたことに対処し続けるしか仕方がないが
可能なら自分が対処する当事者にはなりたくない。
850:デフォルトの名無しさん
24/02/15 18:19:47.46 SZiIKMeC.net
「Go」、2月のTIOBE指標で過去最高8位に
URLﾘﾝｸ(japan.zdnet.com)
URLﾘﾝｸ(japan.zdnet.com)
851:デフォルトの名無しさん
24/02/15 18:24:55.60 x2y7hFPc.net
>>838
悪いほうがよい (Worse is Better) 原則というものも知られている。
正しさと単純さを天秤にかけてどちらが良いかという点で Rust とは異なる重みづけをしたのが Go だと思う。
問題をコンパイラが検出できる設計はもちろんありがたいが、そのために持ち込む構造は人間が把握しやすいものだろうか。
正直言って Go が良いとは全然思わないが一貫した理念に基づく判断であって、不備でそうなってるわけではない。
852:デフォルトの名無しさん
24/02/15 18:31:33.80 j4EJcuA3.net
>>829 >>839
このあたりは設計の根深い問題で、「変化を抱擁する」を標語としたアジャイル開発とかインクリメンタル開発とかで色々議論されたな。
あんまり目立った成果は無かったような気もするけど、機能間の疎結合と可換性は重要な指摘だと思うわ。