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

■ このスレッドは過去ログ倉庫に格納されています
2021/11/28(日) 16:59:19.16ID:gZqbEyz/
スレタイ以外の言語もok

前スレ
次世代言語22 Go Nim Rust Swift Kotlin TypeScript
https://mevius.5ch.net/test/read.cgi/tech/1629590343/
2022/03/14(月) 10:05:42.69ID:/sMe7Uy5
×使うだけの人には不要なのよ
○イテレータ使うだけの人には不要なのよ
2022/03/14(月) 18:58:59.94ID:ffXSoD1s
彼は病気なんです
すみません…
2022/03/14(月) 19:01:21.66ID:ffXSoD1s
そういえばRustマンセーの人たちはデザインパターンやDI知らん人が多いよな
業務の人じゃないんじゃないかな
2022/03/14(月) 19:33:27.88ID:vcnazuXY
rustにもデザインパターンと呼べるようなものはあると思うんだけどね
そう呼ばないだけて
2022/03/14(月) 19:36:11.36ID:qbCTDT+5
マスコミ業務の人はインターネットのことをそういう目で見ている
2022/03/14(月) 19:38:30.40ID:ffXSoD1s
DI使わないでどうやって大規模開発してるのか謎なんだがな
架空の大規模開発してるのだろうか？
2022/03/14(月) 20:31:10.63ID:lMI36uuv
DI使わず大規模開発は普通に可能でしょ
そんな頭で大規模開発してることが謎だわ
2022/03/14(月) 20:35:29.98ID:WXnM/Xv2
こんどはDIおじさんか...
2022/03/14(月) 20:52:37.91ID:+YaSNWzL
>>710
> スレッドを作らないときに遅くなる設計選択をしなかったというだけ
その通りだが、GUIでは事実上「スレッドを作らない」という選択肢がない。
メインスレッドで(確か)10秒以上のジョブを実行すると「GUIが固まるだろボケ！別スレッド起動しろ」と怒られ、
仕方なく別スレッドを起動すると、結果を表示する際に「GUIコンポーネントは別スレッドからは触れねえよボケ！Invokeしろ」と怒られる。
よって、「計算結果をprintfするだけ」のCUIアプリをGUIにするだけの為に、「別スレッド起動してInvokeする」コードが必要となる。
全く馬鹿げてるよ。
どうせ計算結果を待つしかないのだから、待つ間にGUIが固まってもどうって事無い。
それが嫌なら「別スレッド+Invoke」で、面倒で手抜きしたいのなら「GUI固まりますがどうぞ」でよかったのだが、
MSは後者の選択肢を残さなかった。
JSだとこの辺の糞っぷりが全くなく、別方法で綺麗に解決されてた、というわけ。

まあ見解の相違はおそらくそちらはCUIアプリが主だったか、真面目に実装するタイプなのだろう。
2022/03/14(月) 20:53:26.06ID:+YaSNWzL
> イテレータは抽象化されてるので密結合はしていない
イテレーターパターン推し連中の公式見解だな。
ただ、目的とどこまでやるべきかを考えれば、問題点は簡単に分かる。
俺は、

目的： 同一コードを走行させる為、コンテナ非依存にする為
どこまで： 全部

と考えてる。抽象化が「本質(共通）部分のみを抜き出す」事なら、共通部分が残っているようなら抽象化が不十分だ。
iteratorを使う際には必ず「ループの中に入れて.next()を呼び出す操作」が必要で、つまりこの部分
for (=iter.begin(); !=iter.end(); =iter.next()) {}
が共通で残っており、毎回自前で同じようなコードを書け、となってる。--- (A)
ならこの部分もついでにイテレータに入れた方がよくね？と考えれば、
itereator.each(関数ポインタ）形式になり、まんまforEachになる。 --- (B)
だからイテレータとforEachは発想としては連続的につながっており、思いつけないものではない。
敢えてイテレータ(A)で止めてるのは、当時覇権言語だったJavaが関数ポインタを使えず、(B)を記述する能力がなかったからだ。
つまり、

OOP：イテレーターパターン： for (=iter.begin(); !=iter.end(); =iter.next()){ 中身の処理 } --- (A)
関数型：ダックタイピング： container.forEach(関数ポインタ) --- (B)

であって、どちらも目的を達成出来るが、for の呪文を毎回書かなくて済む分関数型の方がいい。
だからあの関数型アゲは腐りきったデザインパターンへのアンチテーゼの意味もあると思ってて、
実際デザインパターンアゲが消滅次第、関数型アゲも消滅したろ。
2022/03/14(月) 20:54:38.73ID:+YaSNWzL
で、ついでに言うと、イテレータ自体はコンテナと必ず密結合してる。
コンテナの内部構造を変更されたらイテレータ自体も変更しないといけないだろ。（イテレータを使う側のコードは変更不要）
そして、
イテレーターパターン：オレオレコンテナにはイテレータを用意しろ --- (A2)
ダックタイピング：オレオレコンテナにはforEachメソッドを用意しろ --- (B2)
だが、イテレータの用意は共通インタフェースにする程度の設計は必要なのに対し、
forEachメソッドの用意はただ回せば済むから、A2よりもB2の方が簡単なんだよ。
ここで「簡単」で済む理由は、B2の方が「自然」だからであり、A2で切るのは「不自然」だからだ。
コンテナとイテレータは一体であり、内部処理はそれとは全く関連無いから元々疎結合。
それを(コンテナ)/(イテレータ＋内部処理）と無理に切るからおかしくなる。
(コンテナ＋イテレータ)/(内部処理)なら元々疎結合のところで疎結合にしてるから余計な手間がかからないという、ごく当たり前の話。

Javaが最初から関数ポインタを扱えれば、イテレーターパターンなんて存在せず、敢えて言うなら
・forEachパターン：コンテナは必ずforEachインタフェースを継承/実装しなければならない
とかになってたと思うぜ。(もはやパターンではなくただのコーディングルールだが）


>>711
> メモリが確保できない時（エラーを生成する余裕すらない時もある）とか
Javaの場合はもしもの時用に1MBのメモリを確保していた。
ただ、メモリで落ちた場合は「あと数KBあったら落ちずに済んだのに…」が大半だろうし、
非常用に1MBはでかすぎるだろ、という事で、最近は500KBに減らされたと聞いた。


>>714
> 必要もねえのに勉強しちゃって
それは「デザインパターンの意義は、命名した事くらいだ」の人達の意見だし、実際これも当たっているが、
もともと「頻出パターンを学んで初心者から中級者へジャンプアップする」為の物であり、学習用だ。

そして「この場合はこう実装しろ」を規定するのはコーディングルールや設計方針であって、
「頻出パターン図鑑」であるデザインパターンではない。
2022/03/14(月) 20:55:01.53ID:lMI36uuv
forEachが関数型とか信者に刺されるぞ
2022/03/14(月) 21:05:55.05ID:O5nPkwUH
外部イテレータに対し内部イテレータをこんなに有難がる奴初めて見たわ
2022/03/14(月) 21:07:05.83ID:0o62jolj
>>726
せめてreduceだよね
2022/03/14(月) 21:09:52.99ID:+YaSNWzL
>>726
そうなんだけど、じゃあ何型だ？と言われて、手続き型に入れるわけにもいかんだろ。

Cでは上級テクニックだった関数ポインタを、
スクリプト言語(Python/Ruby/JS)では初心者でも常用してる。この違いは大きい。
そして関数ポインタをカジュアルに使えばコードは単純になることを証明してしまった。

逆に、Java周りの歪みは「関数ポインタを使えない事」による物が大きい。
(だから今後は徐々に改善していくのだろうけど）
2022/03/14(月) 21:11:48.03ID:U570WKgz
>>723
別に全く苦ではなかったね

>>724
書き方だけだし、C++やJavaやC#などクラスある言語でも普通に簡単な書き方がある。Cでマクロがあるくらいなんだから当たり前だけどな。

>>725
シグニチャにiteratorしか入っていない以上密結合していようがない
2022/03/14(月) 21:15:50.98ID:0o62jolj
関数ポインタが上級テクニック！！？？
2022/03/14(月) 21:19:10.98ID:zdS58C2+
こんだけ長文書かれるとどうしても、あちこち突っ込みたくなっちゃうな
2022/03/14(月) 21:21:31.14ID:U570WKgz
>>729
Reflectionでもinterfaceでも似たようなことできるし、それが必要と思ったことがない
C#のdelegateみたいな機能は新鮮だったけど
2022/03/14(月) 21:27:54.46ID:O5nPkwUH
GoFのデザパタ本ではイテレータパターンでは
> ◎実装
> Iteratorパターンには、実装に関して多くの方法とその変形がある。(略)
> 1.どのオブジェクトがiterationをするか
> （以下、内部外部イテレータの紹介部分略）
> 外部iteratorは内部iteratorに比べてより柔軟である。
> 2つの集合が等しいことを外部iteratorを使って比べるのは容易だが、
> 内部iteratorでは実用的には不可能である。(以下略)」
つまり、内部イテレータも外部イテレータもパターンとして既出
どっちの実装もともに検討されている
2022/03/14(月) 21:40:17.81ID:vcnazuXY
スレタイの言語の中でjavaで培われたデザインパターンが効果的な言語ってあんの？
736デフォルトの名無しさん
垢版 |
2022/03/14(月) 21:41:33.54ID:ptWJKaRn
継承自体が古いからな……
2022/03/14(月) 21:43:55.10ID:U570WKgz
知らず識らずのうちに使ってしまってるのがデザインパターンだよ
名前がなかったからあえて付けて一言で通じるようにしたことがGoFの功績
2022/03/14(月) 21:46:41.46ID:O5nPkwUH
初心者のうちはデザパタに興味持たなくていいよ
必要性を感じてからはじめて手を出せばいい
興味本位だけで手を出しても何も得られない
勉強にもならない
半可通によるデザパタ乱用か
デザパタ不要論者になって暴れだすか
繰り返すが
デザパタには必要にかられてから手を出せば十分
2022/03/14(月) 21:48:26.00ID:+YaSNWzL
>>733
> それが必要と思ったことがない
それはJavaの話？なら最悪だと思うのはGUIで、

element.onclick = function(){};

が書けないものだから、
1. elementを継承したオレオレエレメントクラスを作って
2. それにonclickインタフェースを継承して、そこに処理を書く
とかやるんだろ。一応デコレーターパターンになるのか？

どう考えても頭おかしいし、最悪だろこのソリューションは。
当然JavaのGUIなんて早々に滅亡した。


ただまあ、Java作った奴が馬鹿だったわけではない。
(むしろ一番成功した言語なので、一番賢かったとも言うべき存在）
当時は関数ポインタの重要性が今程認識されていなかっただけの話。
ならさっさと入れれば良かったのに、
そこをデコレーターパターンで誤魔化してきた奴は死刑でいいよマジで。

というのもあって、俺はデザインパターンはゴミだと見ている。
そもそもそれが本当に頻出なら、簡単に書ける構文を用意しておくべきだ。
だから整備された言語なら何も意識せず自然に書いてても
結果的にデザインパターンのどれかに分類される事と同じ事をやってるはずで、
今現在はそうだと思ってる。
2022/03/14(月) 21:55:55.62ID:mIWYJMZE
>デザパタには必要にかられてから手を出せば十分

後から必要にかられることなんてあるのかね
2022/03/14(月) 21:57:36.60ID:U570WKgz
>>739
awtの頃はそんな感じでいろいろ大変だったと思うけど、JWTとか出てきてからは内部クラスでやるようになって、そこから先はJava2Dとかいろいろ出て来たけど追ってない。
今はJavaFXみたいだけど、まるで浸透してる気配はないね。
そもそもで言えばJavaでGUIはあんまりやらんけど、理由はクライアントツールならWindowsだから.NETでいいという感覚からだと思う。
個人的にはnativeと繋ぎやすいなど、.NETの方がメリットを享受できたからだと思うよ。
何度も言うけど、JavaScriptと比較するのは根本的に間違っている。
2022/03/14(月) 22:02:13.08ID:U570WKgz
うっかり用語素で間違ったｗ JWTじゃなくてSwingね
2022/03/14(月) 22:37:01.86ID:+YaSNWzL
>>741
> 何度も言うけど、JavaScriptと比較するのは根本的に間違っている。
何故？JSはGUI用の言語だが、俺がC#の糞さについて言ってるのはGUIの部分であり、
JavaもGUIの時に糞さが際だつから取り上げてる。

元々の原因は（既に言ったが）その時代には関数ポインタの重要性が認識されておらず、
また、GUIもまだこなれておらず、結果的に
C#：GUI部分がJSよりだいぶ糞だった（GUIの方針が間違ってた）
Java：関数ポインタがないのでGUIが壊滅的に糞、とても組めたものではない
というところで、逆に言えばGUI以外ならJavaは問題ないので今の地位がある。
C#も同様だが、こちらはだいぶ変化して、今のC#のGUI側面はほぼJSと同じプログラミングモデルになってる。

ちなみに739で言ったJavaのGUIは、WebAPIだ。(＝ブラウザ用。FXやSwingとかは俺は知らん)
一応2015頃まではJavaでもクライアントサイドのコードが書けるようになってたし、APIも生きてた。
(APIだけなら今でも使えるはずだが）
でも糞過ぎて誰も書かなかったので、セキュリティが云々という適当な言い訳で廃止されて現在に至る。


というわけだが、デザインパターンが言語の不備を隠蔽するバッドノウハウ的に使われてるようにしか見えなかったから、
俺はデザインパターンを全く信用していない。
とはいえ、今時の言語とフレームワークを使ってれば、それを○○パターンと呼ぶ事を知らないだけで、
普通に使っているはずであり、これが正常な状態だと思う。
2022/03/14(月) 22:52:50.90ID:0o62jolj
継承は結構GUIと相性良いので、その主張はズレてるとしか感じないな。
関数が第一級オブジェクトであるメリットはそんなGUIがどうのこうのなんて狭い範囲で語れる話じゃないし。
2022/03/14(月) 22:58:10.20ID:U570WKgz
>>743
Webの画面をGUIとは言わない…
Webであれば、基本はHTML＋JavaScript(+CSS)であり、これに最近wasmが付く程度
サーバー側の言語はいくつかあるが、最終的にクライアントに送れるのは上記であり、表現は違わない
最近は仮想DOMを使用するタイプのクライアント側でテンプレートを流し込むコンポーネントを記述するのが普通で、デファクトはJavaScriptを使用するreact
Javaで典型的なSpringは業務に使用されることが多いため、そもそもSPAである必要がなく、昔ながらのサーバー側でテンプレートを流し込むページ記述が普通だと思う
双方を比べるのはいささか不自然で、なんで比較したいのかすら分からない
C#だとBlazorがあって、これだとwasmを使うことでクライアント側も.NETで記述できる
あんまり人気ないけどね
何に対してどんな文句を言いたいのかサッパリなので、よく整理してから話すように
2022/03/14(月) 23:03:29.39ID:+YaSNWzL
>>744
エスパーするが、
> 継承は結構GUIと相性良い
これはGUIコンポーネントを『作る』側、つまりフレームワーク作成側の話だろ。
俺が言ってるのは『使う』側、つまり実際にJS同様GUIのコードを書く時についてだ。

> 関数が第一級オブジェクトであるメリット
ちなみにこれは俺は未だに理解出来ないので具体的に教えて欲しい。
実際、関数にメソッドを生やせるだけで、何かが出来るようになるわけでもないので、
全部入りのC++もまだ第一級オブジェクトとしての関数を入れてないし、多分検討もしてない。
2022/03/14(月) 23:14:29.77ID:+YaSNWzL
>>745
> 何に対してどんな文句を言いたいのかサッパリなので、よく整理してから話すように
いや文句を言うのは既に終わってて、俺のスタンスを繰り返し言ってるだけ。
だからまあ、もう終わりでいいのも確か。

> Webの画面をGUIとは言わない…
それはない。ユーザーがGUIと思えればそれはGUIだよ。
VSCodeをCUIとは言わないだろ。
WebアプリにしてもGUIだし、ガワアプリは中身がWebコンポーネントだからJSだよ。

> 昔ながらのサーバー側でテンプレートを流し込むページ記述が普通だと思う
それは表示するだけのページだね。それはWeb『ページ』と呼ばれる。
GUIだと言われるような物はWeb『アプリ』と呼ばれる。


まあしかし、合意を形成する必要もないし、
言いたい事は既に言ってるし、まあ終わりでいい。
色々ありがとう。
少なくとも当時のC#使いが全く問題を感じてなかったという事だから、
・C#はもともとGUI向けの設計ではなかった
・.NETはそもそもユーザーの想定レベルが高くて無駄に苦労する
のかもな、とは思えてきた。
2022/03/14(月) 23:34:58.46ID:tKTotEWb
>>740
自分が当たり前にやってることを他人に説明する必要が出てきた時にパターンの名前が必要になる
2022/03/14(月) 23:43:23.14ID:7sD4WO1E
>>702
データ競合はシングルスレッドでも当然起き得る

>>704
並列処理だけでなく並行処理でもデータ競合は起き得る

>>703
どんなケースでもデータ競合が起きないことを保証する初のプログラミング言語はRustで合っているのではないか
2022/03/14(月) 23:45:07.77ID:U570WKgz
>>747
> > 何に対してどんな文句を言いたいのかサッパリなので、よく整理してから話すように
> いや文句を言うのは既に終わってて、俺のスタンスを繰り返し言ってるだけ。
> だからまあ、もう終わりでいいのも確か。
じゃあ終わりで
最後にWebの画面レンダリングをGUIに持ってくるケースはある
JavaScriptのelectronやRustのtauri、古くはIEコンポーネントみたいなので非常に特殊なパターン
vscode他を除けば、ゲームとかワンチャンモバイルも狙うGUIでたまに使用されるとか、アプリでWebの画面を出したいとき稀に使用される
嵩張るために滅多に使用されないか、こっそり使用されることが多い
2022/03/14(月) 23:45:51.86ID:+YaSNWzL
>>749
とりあえず「データ競合」の意味を具体的に明確にしてくれ
2022/03/14(月) 23:47:54.88ID:U570WKgz
>>749
正確には「保証する」みたいな強い言葉だとそれだけで独り歩きするのでいかんｗ
「仮定することができる」くらいだな
2022/03/14(月) 23:57:31.30ID:7sD4WO1E
>>709
イテレータはコンテナと密結合、は間違い
そのようになってしまっている悲しい言語も存在するだけにすぎない
例えばRustなどではイテレータ連鎖に一度もコンテナが登場すらしないこともあるように
イテレータとコンテナは独立の存在

コンテナの中身を順に出すイテレータを作れるとか
イテレータが吐き出したものをコンテナに格納できるといった
端点で関連するケースがありうるだけにすぎない
754デフォルトの名無しさん
垢版 |
2022/03/15(火) 00:10:15.67ID:N7uKXWL+
>>718
どんなプログラミング言語にだってあるよ。
デザインパターンってのは似たような問題領域における対処法や設計ノウハウに共通の言葉を定義したコミュニケーションツールだからな。
2022/03/15(火) 00:13:54.20ID:YRrS4TOh
デザインパターンの時代には抽象化されたループや分岐が作られた
それを具体化するたびにクラスを作りクラスに名前をつける
まるでgotoの行き先にいちいち名前をつけるみたいに

そのあとラムダが普及して名前をつける必要がなくなった
whileやifやelseのブロックに名前がないのと同じ
2022/03/15(火) 00:35:40.32ID:lBfKiKMI
>>753
> イテレータはコンテナと密結合、は間違い
間違ってねえよ。
というか、多分「密結合＝悪」と洗脳されてるから否定したいのだろうけど、
俺が言ってるのは、

・コンテナとイテレータの関連は、
　イテレータと中身の処理の関連より100万倍くらい強い

という事。だから

・コンテナとイテレータの結合は、イテレータと中身の処理　より 100万倍密結合

であり、これを密結合と言わずに何という？という話。
そりゃイテレータで無理矢理切り離せばコード上は切り離せるけど、それやっても大してメリット無いし、
ほぼ100%の状況で「頭から全部イテレート」で済むんだからforEach（関数ポインタ）の方が筋がいい。
そしてJSのArrayなんてイテレータはないよ。実際要らんし。

forEachが遅かったからイテレータ、ならそれは「言語の不備」だよ。
C++はその辺順番を入れ替えて同速にしてしまったし、知らんがRubyでもlazyモードで同様なんだろ。
勿論イテレータの方がいい場合もあるはずだが、これは昨今のimmutableや再代入を避けるのと同様、
これまでは不要にイテレータを使いすぎてただけ。
本当にイテレータが必要なところだけイテレータにして、その他はforEach(関数ポインタ）の方がいいよ。
2022/03/15(火) 01:11:07.84ID:DajlRg+n
何度も言うが、デザインパターンのiteratorはiteratorが抽象化されている
https://ja.wikipedia.org/wiki/Iterator_%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3#:~:text=Iterator%20%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3%EF%BC%88%E3%82%A4%E3%83%86%E3%83%AC%E3%83%BC%E3%82%BF%E3%83%BB%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3%EF%BC%89,%E3%81%93%E3%81%A8%E3%82%92%E7%9B%AE%E7%9A%84%E3%81%A8%E3%81%99%E3%82%8B%E3%80%82
なので密結合にはならない。この図では
ConcreteAggregateとConcreteIteratorは蜜だが、AggregateとIteratorは疎
どうしてここまで説明しないと分からんのだ…

あと関数ポインタなどいらん
内部イテレータ方式喜ぶバカなんてお前くらいだ
2022/03/15(火) 01:43:01.13ID:DajlRg+n
Javaで関数ポインタ要らない例
// Main.java
import java.util.List;
import java.util.Arrays;
import java.util.ArrayList;
import java.util.function.Consumer;
public class Main {
public static class MyContainer<T> extends ArrayList<T> {
public MyContainer(List list) {super(list);}
public void foreach(Consumer<T> consumer) {
for(var e: this) {
consumer.accept(e);
}
}
}
public static void main(String[] args) {
MyContainer<Integer> mine = new MyContainer<Integer>(Arrays.asList(1,2,3));
mine.foreach((value)->{System.out.println(value);});
}
}
2022/03/15(火) 02:53:52.15ID:rTKg59xg
イテレーター原理主義なんじゃないの
コレクションの要素を列挙するものしかイテレーターと呼ばないと考えてるとか
2022/03/15(火) 07:48:57.53ID:zEYayVtk
>>749
シングルスレッドでデータ競合起こるコード例あんの？
2022/03/15(火) 07:58:16.07ID:zEYayVtk
void f(int*a){
int*b=a;
*a=(*b)++;
}

みたいのはただの未定義動作だから許さんぞ
2022/03/15(火) 08:44:41.02ID:dING6/Lp
>>749
保証していないよ。unsafeがあるだろ。
2022/03/15(火) 08:45:32.91ID:bERyk9+R
>>756
コンテナベースのイテレータを提供する言語もあるから誤解しているのだろうけど
本来のイテレータ自体はコンテナとは別の存在
例えばrustで以下のイテレータチェーン
(1..)
.map(|n| (n * n - n) / 2 * 3)
.take_while(|n| n < &23)
.map(|n| n % 4 + 114)
.map(char::from)
.for_each(|n| print!("{n}"))
これは「rust」と表示するけどコンテナ等は全く登場しない
2022/03/15(火) 08:52:20.69ID:bERyk9+R
>>760
シングルスレッドでデータ競合を起こす例がwikipedia及びそのソース元の言語公式仕様定義に明記されているね

https://ja.wikipedia.org/wiki/データ競合
> JavaScript (ECMAScript) において、read/writeイベントEとDが以下の条件を満たしている場合「EとDはデータ競合にある」と定義される[2]。
> ・EあるいはDに順序が定義されない（not SeqCst）
> ・EとDが重複したrangeを有する（overlapping range）
2022/03/15(火) 18:54:21.48ID:zz0oZcbP
https://ideone.com/AKsoei
javaの典型的なイベント処理はこう
多言語のようにonclick = と指定するのではなく
イベント発生元にaddListener()でリスナを追加する
その時匿名クラス式を使うのもまた大昔からのやり方
匿名クラスについては以下を参照のこと
https://docs.oracle.com/javase/tutorial/java/javaOO/anonymousclasses.html
2022/03/15(火) 18:58:10.48ID:H3mwwYQo
どの言語でも『single writer XOR multiple readers』の原則を守ればデータ競合は起こらない
逆にそれを破ればシングルスレッドでもデータ競合は発生し得る
ほとんどの言語でデータ競合が起きる

>>762
Rustは『single writer XOR multiple readers』を言語仕様で満たしている
そのためRustではメモリ安全性だけでなくデータ競合も起きないことを保証している
もちろんC/C++と同じように生ポインタを使えるunsafeを使った場合はその部分を人間が責任を持つ
2022/03/15(火) 19:21:02.60ID:DajlRg+n
>>765
匿名クラスは内部クラスの一種だけど、通常はそういう書き方だね
>>741で言ってるのもそれのこと

>>766
まあRustもunsafeまみれだから安全じゃないけどね
2022/03/15(火) 20:31:20.53ID:lBfKiKMI
>>763
配列以外の実体に対しエミュレーションして配列メソッドを使いたい場合、イテレータはインタフェースとしては有効だ。
ただそれは「イテレーターパターン」使用箇所の1%以下だろ。


>>764
それは一般的にはレーシングコンディションと言う。(wiki書いた奴が無知なだけ)
そして、その定義ならErlangは問題ない。理由は、

・変数は再代入禁止なので、定義しか出来ず、書き換えようがないから
2022/03/15(火) 20:50:33.68ID:DajlRg+n
まあシングルスレッドでも普通にコールバック多いと意図しないデータ競合はいつでも起きるけどな
言葉の定義の問題になるので俺は黙ってたけど・・・
2022/03/15(火) 20:57:03.80ID:bERyk9+R
>>768
それはwikipediaにソースが明記されているように
JavaScript(ECMAScript)の公式仕様書の記載です

ErlangはETSが共有データとなるため
留意してコードを書かないとデータ競合が発生します
2022/03/15(火) 21:19:56.63ID:lBfKiKMI
>>765
それもしかしてわざわざ書いてくれた？ならどうも。


名前からしてそれは「アダプターパターン」になるのか？まあこれはさておき、
これがデザインパターンの問題を典型的に示してるとも思う。
デザインパターンは「実際にこう書ける」であり、「こう書きたい/書ければいいのに」ではないので、
実践的ではあるが現状肯定的で、理想的では全くない。
だからどうしてもバッドパターンが混ざり、言語が酷ければ酷い程それが増える。
Javaの場合は関数ポインタを直接取り扱えない事が致命的に欠点で、結果、
関数ポインタ専用コンテナとしてクラスを用いて継承をこねくり回したパターンが多くなってるが、
それらは他言語では不要なものばかりだ。
本当は「あらゆる言語の中で一番美しい書き方」集にすれば良かったのだろう。
2022/03/15(火) 21:20:12.77ID:lBfKiKMI
上記の通り、結局それは、関数ポインタを直接扱えなかった欠点を回避する為に、
関数ポインタ専用コンテナとして「匿名クラス」を用いているだけ。
素直に関数ポインタを直接扱えるようにすれば不要だった。
勿論ラムダの代替にもなるが、結局ラムダも入れてしまってるのだから、やっぱり「クラス」に見えるのは使いづらいんだよ。
(この辺はC++も同様で、ファンクタでいいだろ、でずいぶん粘ったようだが、結局ラムダも入れてしまってる。
C++に関しては仕様の直交性なんて誰も求めてないので、粘った意味も分からないが）

Java:：匿名クラスのところを
> label.addMouseListener(new MouseListener() {
> public void mouseClicked(MouseEvent e) {}
> public void mouseEntered(MouseEvent e) {}
> public void mouseExited(MouseEvent e) {}
> public void mousePressed(MouseEvent e) {}
> public void mouseReleased(MouseEvent e) {}
> });

JS：汎用コンテナで普通にかけるので、○○パターンとかの命名なんてされない。
> label.addMouseListener({
> mouseClicked: function(e) {},
> mouseEntered: function(e) {},
> mouseExited: function(e) {},
> mousePressed: function(e) {},
> mouseReleased: function(e) {},
> });
ただしこんな書き方は普通はせず、単に
elem.onclick = function()e){};
で済まされるが。
2022/03/15(火) 21:21:54.17ID:lBfKiKMI
あとついでに言うと、Java的にあらゆるイベントを纏めて記述方式はコード的に無理があって、 --- (A)
だいたいclick系とmove系(Enterd/Exited/Pressed/Released)は別物になる。
前者はそのelemだけで完結するが、
後者はドラッグ&ドロップ等なので、大体周りのelemにも同じようなコードを走行させる事になるから。
だから「匿名クラスでその場に定義のみ」だとかなり悲惨なコピペだらけになる。
最低限、そのメソッドに直接関数を差し込める書き方、

function click(){}
function move(){}
label.addMouseListener({
mouseClicked: click,
mouseEntered: move,
mouseExited: move,
mousePressed: move,
mouseReleased: move,
});

とかが出来ないと死ねる。で、Javaはこれも出来なかったように見える,。(Java7までは)
だからJavaのGUIは完全に死んだ。

ただしイベントがバブルする場合は上記 (A) の問題は実質的にない。
(どうせ纏めて記述するに近い物になるので。
つってもJavaのGUIなんて全く整備されてないから未だにバブルしないんじゃないかとも思うが。
なお.NETはWPFからバブルする）
2022/03/15(火) 21:23:27.75ID:AHjgvQpl
>>770
ESの仕様にあるデータ競合はWeb Worker（つまり別スレッド）とSharedArrayBufferなんかでメモリ共有した場合の話であって、シングルスレッドでデータ競合すると主張しているわけではないと思うが
2022/03/15(火) 21:26:20.87ID:H3mwwYQo
シングルスレッドでもデータ競合は起きる
>>769氏も言っているように
2022/03/15(火) 21:31:28.32ID:lBfKiKMI
>>770
> https://262.ecma-international.org/10.0/#sec-data-races
race　は レースであって、競合なら confliction だよ。訳が不適切。

ただ、レーシングコンディションならRustでもいくらでも作れるはずだけど。
shared memory が出来るのだから、
同じ場所を書き換える非同期ジョブを適当に流し込めば自動的にそうなる。

Erlangでは出来ない、ってのは、上記の「同じ場所を書き換える」事が出来ないからだよ。(共有メモリも出来ない）
ETSってのは知らんが。
2022/03/15(火) 21:37:30.32ID:DajlRg+n
>>771-773
だから内部クラスで書けるっての
2022/03/15(火) 21:38:08.96ID:eZS8bXEN
>>775
>>769がコールバックの呼び出し順序が非決定的であることを言っているならそれは競合状態（race condition）
データ競合（data race）ではない
2022/03/15(火) 21:41:04.21ID:DajlRg+n
>>778
俺が言ってるのは単なる不注意だよ
順序は決定的だけど、離れすぎて分からなくなるパターン
2022/03/15(火) 21:43:51.00ID:eZS8bXEN
>>779
決定的なら競合すらしないと思うが…
単に論理バグで値を壊してしまうことはデータ競合とは言わないのでは
2022/03/15(火) 21:50:10.28ID:DajlRg+n
だから言葉の定義ｗ
関数やメソッド単位で見る人間にとっては、再入とかコールバックが輻輳してやらかす事件はとても似てるｗ
組込みの割込みとかシグナルとかのIPCも同様なので、まあ混ぜて考えてもいいと思うって人はいるんじゃないかと思ったｗ
2022/03/15(火) 21:55:39.00ID:bERyk9+R
>>776
data race(英語)⇔データ競合(日本語)です
ETS (Erlang Term Storage)はErlangが標準で持っているインメモリの領域
ETSはErlangで色々辛いところを解決する魔法の道具であり抜け道でもありGCもなくデータ共有もOK

>>778
もちろん競合状態(race condition)もあるけど
それとは別に同じデータ(対象)に対して2者以上がルールを守っていなければデータ競合が発生
例えば>>766の言う『single writer XOR multiple readers』の原則が崩れていればデータ競合が発生ありうる
2022/03/15(火) 22:10:46.08ID:eZS8bXEN
>>782
シングルスレッドでshared xor mutableで防げるバグがあるのはそう（イテレート中にイテレート元にデータ挿入しちゃうとか）だが
それはデータ競合とは言わないのでは
少なくともRust公式はdata raceの定義をマルチスレッド前提にしているし、一般的にもそうだろう
https://doc.rust-lang.org/nomicon/races.html
2022/03/15(火) 22:23:00.78ID:H3mwwYQo
>>783
それは非同期でマルチグリーンスレッドでも全く同様に起きることであるし
それは非同期コールバックのあるJavaScriptでも同じく起きることであるし
シングルOSスレッドでも発生しちゃうな
2022/03/15(火) 22:33:43.93ID:lBfKiKMI
>>782
raceは競『争』。競『合』の訳はないと思うが、
まあお前らがレーシングコンディションの意味で使ってると分かれば俺はとりあえずはいい。
（とはいえ俺はもう終わりでいいが）

あと、JSの定義は>>774が言ってるとおり、
マルチスレッドでの前提で、シングルスレッドでは発生しない。（定義されてない）

多分wiki書いた奴が全く分かってない。
何か不思議な値になるみたいな書き方だが、そうはならない。
一発書きなら当たり前だがどちらかが書いた値にしかならない。殆どの場合はこれになる。
一発書きしない場合は混ざる事があるが、
多分これを著者が理解出来てないからあやふやな書き方になってる。
2022/03/15(火) 22:36:34.90ID:Absh97Vn
データ競合(data race)という言葉の定義自体が言語によって違うんか

それならなんか人によって話が噛み合ってないのも納得

C++11だとマルチスレッドが前提になってた
https://timsong-cpp.github.io/cppwp/n3337/intro.multithread#def:data_race
2022/03/15(火) 22:50:45.74ID:MfNILggQ
ここまで出た通りES/Rust/C++はマルチスレッド前提で、Javaも確かそうだったし
シングルスレッド派の人はちゃんと定義されてるやつを示してほしい
日本語Wikipediaじゃなくて

>>785
訳が競争というのはまぁそうかもしれないけど、CS系学部の教科書レベルで競合に統一されちゃってるので、いまさらどうしようもないね…
2022/03/15(火) 22:52:23.31ID:MfNILggQ
というかよく考えたら日本語Wikipediaも間違ってはないんだな
引用した人がJSだからシングルスレッドって思い込んでただけで
2022/03/15(火) 23:02:06.12ID:DajlRg+n
ほら定義の話になってんだろ
それって正解がないので、どっちかに合わせて結論出したら終わりなんだよ
2022/03/15(火) 23:20:05.34ID:38db7Aep
データ競合(data race)だろうと競合状態(race condition)だろうと言語ごとに定義が違うなこりゃ

言葉の定義自体は規格書引っ張り出してきて殴り合うとして、
言語が別だとそもそも話し合うことすら難しいんじゃないの？
どっちかの定義に寄せることすら無理そうだし
2022/03/15(火) 23:20:45.51ID:DajlRg+n
あと>>783の定義だと、concurrentだからシングルスレッドな並行もダメかもね
非同期シグナルとかもダメだし、シングルスレッドって前提だけではデータ競合起きちゃうね
2022/03/15(火) 23:46:09.49ID:DajlRg+n
定義は両者で共有・合意するだけで問題ないよ
規格書を引っ張り出す必要もない
ただ出た結論は定義込みで語られないと意味がないだけｗ
2022/03/16(水) 00:57:59.77ID:DZO6khEt
>>787
> CS系学部の教科書レベルで競合に統一されちゃってる
よしそいつを吊そう…
と言いたいところだが、語感的に

競争：所詮どっちが先か後か程度、結果はどっちかになる
競合：ぶつかってぶっ壊れるイメージ、結果がどうなるかは分からない

だから敢えて「競合」としたのだろう。
発端はただの競争でしかないが、甘く見てると、結果は全く身に覚えのないデータになってしまう事もあるので、
教育上は「競合」の方がいいのかもしれない。

有名どころはJavaのdouble-checked lockingイディオムが実は全く役に立たず、大騒ぎしてた件とか。
http://www-06.ibm.com/jp/developerworks/java/020726/j_j-dcl.html　（多分これだがリンク切れ）

残骸はあちこちに残ってるので雰囲気だけは分かるかも。
https://atmarkit.itmedia.co.jp/bbs/phpBB/viewtopic.php?topic=31199&;forum=12
なお言い分が食い違ってるが、俺はさらに違ってて、「初期化中のクラスが他スレッドに見えてしまって、
Javaの仕様ではこれを防ぐ方法もない」だと思ったが。
他の残骸は以下とか。（全部読んだわけではないけど）
https://en.wikipedia.org/wiki/Double-checked_locking
https://stackoverflow.com/questions/1625118/java-double-checked-locking
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
2022/03/16(水) 01:28:32.65ID:0TydPa2f
別に毎回同期すればいいだけのところを無理に端折ろうとすると、複数CPU時代の現代ではインターロックが必要ってだけでしょ
volatileがないのは論外だけど…
競合を回避するには同期(ロック)しようねってだけ
2022/03/16(水) 02:53:58.81ID:jNwWVkZm
JSエアプだったからスルーしてたが >>764 の言う「順序」ってのが定義されていればデータ競合にはならんのだよな？

1スレッド内の操作で順序が定義されていないって状況がなんか想像できなかった

まさか value=value みたいのがデータ競合なんてならんだろうし
2022/03/16(水) 06:15:40.53ID:0TydPa2f
え？そこは>>788でFAでは？ECMA Scriptだしな
2022/03/16(水) 08:12:09.94ID:kgs87UnJ
>>766
もちろんC/C++と同じように生ポインタを使えるunsafeを使った場合はその部分を人間が責任を持つ

そういうのは「Rustが保証する」とは言わん。
2022/03/16(水) 21:28:41.83ID:MkjFLw2M
>>797
それはあなたが理解できていない
プログラム全体に渡り言語仕様に基づきコンパイラが安全性を保証できる
その例外部分がunsafe宣言部分でありそこだけを人間が責任を持てばよい
他の言語はプログラム全体に渡り人間が責任を持たなければならない
2022/03/16(水) 22:05:14.42ID:DZO6khEt
この際「Rustのunsafeは綺麗なunsafe」のダブスタは置いておくとして、
仮にRustではデータ競合をunsafe領域だけに局在化出来るとして、それで何が嬉しいんだ？
具体的にそれをどういうアプリに生かせるんだ？


他言語の場合はスレッドセーフにするのには細心の注意がいる。
だから一般的に最小限の部分しかスレッドセーフにしない。結果、共有も最小限だ。

対してこれがunsafe領域だけにできるとして、これだけなら
・ロック周りを記述している箇所は後から検索出来るように必ず　./// LOCK のコメントを付けとけ
程度の意味しかない。

既に言ったが他言語ではロック周りは難しいので最小限に絞られている。
これがRustで楽に書け、もっとカジュアルに使えるとして、
出来上がるアプリは「スレッド間をもっと密結合させ、共有RAMをもっとカジュアルに使うもの」になる。
共有RAM方式は昨今言われている程遅くも悪くもないが、(x86の場合は)
ハードウェアとしては従来通りの「共有RAMは最小限」の方が断然速く動く。

だから単純には、
C++ではロック周りでバグが出まくって実装するにはとても無理だが、
言語サポートがあるRustなら平気で書けるからこそこの構造に出来、断然性能がいい、
とかいうアプリ（適用領域）がないといけないが、これは何？

Go/Rustはマルチスレッドがこなれてからの言語だからその辺に独自のアイデアを突っ込んできてるのは当然として、
Rustのが「ロックをもっとカジュアルに」なら多分ハズレだ。
簡単に書けるのは正義ではあるが、ロックを最小限に絞るのは『大』正義だからだ。
(そして一般的なフレームワークを使えば、
ロックなんてそれ用のクラスを使うしかないから、検索すればすぐに見つかる。
ロックすら考慮せず野良で共有してるようなコードは見逃すが、
これを防ぐ為だとしたらRustは相当の馬鹿向け言語という事になる。
C/C++だったら「そんな奴は死刑」で誰も反対しない)
800デフォルトの名無しさん
垢版 |
2022/03/16(水) 22:10:43.48ID:1Cs5zQXI
一応確認するけど触っちゃダメな人だよね？
2022/03/16(水) 22:14:58.99ID:CXtf6yKM
>>800
スレで一番筋の悪い人が
スレで一番の長文を書いて暴れる

しかしこれは珍しいことではない
自分と他人の力量が見えないことは
こういう風景を生みがちなのである
2022/03/16(水) 22:41:00.48ID:0TydPa2f
そもそも何と何を比較したい、とか主張や前提が不明瞭だから長くなってんだよ
日記を書くなら他所にしてね
2022/03/16(水) 23:55:27.76ID:yCGU0QjC
>>799
Rustで実際に書けばわかるが
普通のプログラムでunsafeを使うことはないぜ
unsafeは特定のライブラリの中に閉じ込められていて外に影響なし
その部分を除くプログラム全体の安全性をRustコンパイラが保証
他の言語ではプログラム全体の安全性を人間が保証
804デフォルトの名無しさん
垢版 |
2022/03/17(木) 00:29:26.40ID:WcGjUzZw
銀の弾丸は無いってことを理解できない人が暴れてるみたいだな。
たぶん今までの人生全ての出来事が100点じゃないとダメな人なんだろうけど、なんでまだ生きてるんだろう？
2022/03/17(木) 00:41:54.94ID:aVeaiVtR
>>803
ユーザーがunsafeを使う必要がないのはいいが、
それが何を作る時にどう利点になるんだ？


繰り返すが、C++等でロック等を自前で書く事はほぼ無い。
最小にする為にatomicにして、atomicは通常、フレームワークが用意してる物を使うからだ。
だから「ロック等を使う必要がある」事を認識してる奴が書いたコードなら、Rustと同程度に安全だ。
なぜなら、Rustでも「ロック等を使う必要がある」と認識して、特定のライブラリを使わないといけないんだろ。

この側面についてのRustの利点は、
・「ロック等を使う必要がある」とすら認識出来ない馬鹿が書いた時に、コンパイルが通らない --- (A)
というだけのように見える。

・「ロック等を使う必要がある」と認識出来る奴が、ロック等を『うっかり』忘れる --- (B)
のを想定しているなら、はっきり言ってこれはない。
マルチスレッドを直接扱う場合、何らかのロック等が『常に』必要であり、
最初にそこを設計して、かつそれはスレッドについて「入力」「出力」側１つずつとかの最小限に絞るからだ。
つまり、目で見て分かる程度でやってる。見落として苦労する事は無い。
これをRustだとコンパイラがチェックしてくれるから、大量に出来る！見落としもない！のはいいが、
それはどういう時に利点なんだ？という話。

細かいオブジェクトを大量に共有出来たら素晴らしくパフォーマンスが上がる、なんて構造、無いだろ。
2022/03/17(木) 01:37:02.04ID:HeUHSOmZ
>>805
Rustコンパイラが保証するのは
・そういうマルチスレッド時の、狭義のデータ競合、だけでなく
・シングルスレッドでの非同期コールバックなどの、普通のデータ競合、や
・ロジックミスなどにより生じる、広義のデータ競合、に加えて
・様々なメモリ安全性、に至るまで
コンパイル時に検出が可能なことを保証
色んな言語で書いてきたプログラマーならば以上の説明で恩恵を納得できる
2022/03/17(木) 01:38:54.54ID:faeKJv0z
C++って何か理由があってピンポイントで使うことが多いと思う
だからフレームワークってあんまりないよね
間違ってる上に風呂敷広げすぎ

Rustもそんなこと保証できない
2022/03/17(木) 01:39:14.78ID:QB355J6E
もう相手すんなよ
うっかりがありえないとかまともなプログラマならそれこそありえないことを知ってるだろうし
2022/03/17(木) 01:49:00.20ID:jsnVHM5N
　:::....　　　／|＼||　　　
　　　　 ／／|'＼＼.... ...:::.. .......
　　　　|／　,'|-､ ＼＼
　　　　|／　,'|-､ ＼＼＼
　　　　|／　,'|-､ ＼＼＼|.... ...:::.. .......
　　　　|／　,'|-､ ＼＼＼|:..。..... ...:::.. .......
　　　　|／　,'|-､ ＼＼＼|__|
　　　　|／　,'|-､ ＼＼＼|:...|ヽ　.... ...:::.. .......
　　　　|／　,'|-､ ＼＼＼|::::|　|::.....　
　|￣￣￣￣￣＼､'＼＼|;;:.|_,,|＿＿＿　　　
　| □□ □□ |　|＼, ＼|;;::....　　　　　|＼
　| □□ □□ |　|　 |￣￣￣￣|＼;: . |　 |
　| □□ □□ |　|　 |□□□□|　 |::...|　 |;;:
　| □□ □□ |　|　 |□□□□|　 |::...|　 |:;:.／
　| □□ □□ |　|　 |□□□□|　 |::...|　 ／
　| □□ □□ |.._|__,,|□□□□|　 |::...|／　　
,,|￣￣￣||￣￣＼≡＼,□□□|／ ,／

今北産業 [IMAKITA INDUSTRIAL CO.,LTD]
　　　　　（1978〜　日本）
2022/03/17(木) 01:53:13.45ID:nYfWW7l3
彼は確かに色々と間違っているが
彼の言う通りロックが必要なところでうっかり忘れたとすると
Rustコンパイラはそれが引き起こすデータ競合を通さないから
結局ロックが必要な型を使うことになり結果としてそれも保証されたことになる
2022/03/17(木) 02:47:42.05ID:faeKJv0z
また保証話で嘘ついてRustの評価を地に落としているバカがいるなｗ
2022/03/17(木) 02:49:58.34ID:cD+xXa8h
>>806で保証合ってると思うぜ
違うと言うなら具体的に反論しないとな
2022/03/17(木) 02:57:11.72ID:75al4ANx
Rustを叩く連中は
長々と長文で頓珍漢なやつと
理由も言わずに嘘とか違うとか言うだけのやつがいる
2022/03/17(木) 02:58:10.57ID:faeKJv0z
昨日もう散々話したよｗ 異論があるなら昨日の話に続ければいいｗ
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況