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

**デフォルトの名無しさん** · 2021/11/28(日) 16:59:19.16

スレタイ以外の言語もok

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

**デフォルトの名無しさん** · 2022/03/12(土) 09:53:28.84

>>658
Visual studio Express Editionみたいに実用的に使えるけど無償のツールなんていくらでもあるだろ

**デフォルトの名無しさん** · 2022/03/12(土) 11:15:14.69

>>654
エンバカデロC++Builderの新しいのも無料で出してなかったっけ？

どうせ1なんて商用で使えないだろうしcommunityでいいだろ感

**デフォルトの名無しさん** · 2022/03/12(土) 11:27:47.09

お前らのPentium 133MHz メモリ16MB HDD2GBのマシンに入れたらいいじゃん
テレホタイムになったらネスケでダウソしろよ

**デフォルトの名無しさん** · 2022/03/12(土) 11:55:11.91

そんなハイエンドマシン持ってないｗ

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

Pentium 200MHz, 128MB, 6.4GB x 2 のスーパーハイエンドマシンを動態保存してる

**デフォルトの名無しさん** · 2022/03/12(土) 12:42:30.36

まじかよｗ
そんなのあってもその時間は俺のエロ画像取得perlスクリプトが忙しくしてるからテレホタイムにダウンロードは無理だなｗ

**デフォルトの名無しさん** · 2022/03/12(土) 18:49:28.45

　　　＿＿＿_∧∧　　／￣￣￣￣￣￣￣￣
　～'　＿＿__(,,ﾟДﾟ)＜　ボーランド逝ってよし！
　　ＵU 　　Ｕ U　　　＼＿＿＿＿＿＿＿＿

**デフォルトの名無しさん** · 2022/03/12(土) 19:05:16.27

>>542
読んだけど、C11にすれば防げるという話では全然無いような
勿論Rustにしても防げないし
(以下は1通目のメールの頭にあるURL)
https://www.vusec.net/projects/kasper/

>>567
なおイテレータ変数だけなら、Cのスコープ解決演算子{}は実はどこでも書けるので
(for/while/if等と合わせて書くのが一般的だが、何もないところでもブロックを開始出来る）

int main() {
{
int i;
for (i = 0; i < 10; ++i);
}
return 0;
}

とforの周りに明示的にブロックを作れば解決出来るはず
(と思うがその時代のCコンパイラだと微妙なのと、もしかしたらこれが出来るのはC++かも？)

**デフォルトの名無しさん** · 2022/03/12(土) 20:04:52.73

そもそもlinusが問題としたのはそこではなく、その問題を「解決するパッチを適用しようとした際に、該当パッチが持つ別の問題」のことｗ
つまり一通目はただのきっかけで、二通目が問題の本体ｗ

昔から文の代わりにブロックをどこでも作れたかどうかは知らないけどx86 gcc1.27では出来る模様
https://godbolt.org/z/WPz7a67fK

**デフォルトの名無しさん** · 2022/03/13(日) 03:45:28.56

rustはゲームタイトルの方が1000万人をゆうにこえてて
そっちがrustが検索で上がってきてる主要因。
プログラミング言語としてのrustはいうほど広がってない、
一時のHaskelやたらもてはやしてたのよりはマシな動きといった程度。

**デフォルトの名無しさん** · 2022/03/13(日) 04:12:00.30

>>668
最近の状況であればそういう分類はされないと思うけど…
https://trends.google.co.jp/trends/explore?date=today%205-y&;q=%2Fm%2F0zm_2_r,%2Fm%2F0dsbpg6

**デフォルトの名無しさん** · 2022/03/13(日) 09:49:34.27

>>6
> JavaScript 1650万人
> Python 1130万人
> Kotlin 300万人
> Rust 110万人
Rust110万人ってあり得ないよな？
鯖とクライアント1:1と仮定すると、JavaScriptの1/15=6.7%のサーバーシェアがあって然るべきだけど、0.0003%もない。（計測不能）
https://w3techs.com/technologies/overview/programming_language

Rust信者にしても盛りすぎで度を超してる。
サーバーシェアが0.1%以下＝JavaScriptの1/1000以下＝1.65万人以下＝日本限定なら1/10として高々1650人程度？
なおサーバーシェアから単純に比例換算すると、Goは0.0007%なので世界で115人、
Rustは計測限界のlisp(0.0003%)以下なので、世界で50人になってしまうのだけど。
（書けるという意味ではなく、毎日仕事としてゴリゴリ鯖を書いてる人数なら、この程度の気もするが）

**デフォルトの名無しさん** · 2022/03/13(日) 11:45:07.69

>>670
そのページのサーバシェアはWebページのソースから使われてるテクノロジーを推定するってやつだからバックエンドとして使われがちなGoやRustの使用率はあまり反映されてないと思うよ

Rustのライブラリ総数が8万弱だから、ライブラリのメンテナが1万くらいはいるかな
ライブラリ使うだけの人が10倍くらいいるなら10万というのは有り得なくもない
100万は確かにちょっと盛り過ぎかもね

**デフォルトの名無しさん** · 2022/03/13(日) 11:50:34.41

そのページでPHPが圧倒的なのは、要はみんなWordPressを使ってるってだけのことであって、PHPプログラマが全体の7割以上いるってことではない

**デフォルトの名無しさん** · 2022/03/13(日) 13:19:56.90

>>671-672
> 要はみんなWordPressを使ってるってだけのこと
なるほどこれはある。

> バックエンドとして使われがちなGoやRustの使用率は
「バックエンド」の使い方が間違ってるが、
ユーザー側ではなく、内部RESTAPIだから見えない、というのはあるだろうね。

なお、以下動画の最後(2019Q3)では
https://youtu.be/Og847HVwRSI?t=280
> JS 23.18%
> C++ 6.62%
> C 5.35%
だから、C++は471万人、C/C++は853万人になる。
(JSは増えて2021Q3に1650万人だから、実際はこれより1割程少ないかも）
Rustが10万人ならC++の47-85人に1人程度、
これなら「物好き」（＝イノベーター、2.5%程度）が使ってる範囲なので妥当な気もするが、
採用されたのがニュースになってる時点で1%以下じゃないとおかしい気もする。
が、まあ、C++比2桁落ち程度までは来てるって事か。

**デフォルトの名無しさん** · 2022/03/13(日) 14:21:27.61

参考情報
https://statisticstimes.com/tech/top-computer-languages.php

**デフォルトの名無しさん** · 2022/03/13(日) 14:30:14.71

数倍差まで差し迫ってるんだな

>>674
アメリカ
6.16% C/C++
1.69% Rust

ドイツ
3.89% C/C++
1.66% Rust

イギリス
7.79% C/C++
1.83% Rust

**デフォルトの名無しさん** · 2022/03/13(日) 14:54:40.15

この比較も興味深いな
アメリカで僅差
イギリスで逆転してる…

>>674
アメリカ
1.78% Go
1.69% Rust

イギリス
1.83% Rust
1.47% Go

**デフォルトの名無しさん** · 2022/03/13(日) 15:30:57.89

Rustは順位こそ上がってるもののtrendsとしては下降してるけどね

**デフォルトの名無しさん** · 2022/03/13(日) 16:15:47.56

>>674は去年のデータなのか
最新を見つけた

2022年3月
https://pypl.github.io/PYPL.html?country=US
3.34%　Swift
2.74%　Matlab
2.68%　Objective-C
2.39%　PHP
2.36%　TypeScript
2.27%　Rust
1.94%　Ruby
1.72%　Go
1.28%　Kotlin

スレタイ言語とその前後の分

**デフォルトの名無しさん** · 2022/03/13(日) 16:34:08.84

コロナでwasm利用が一時的に増えてチュートリアルなど読む人が増えただけだと思う

**デフォルトの名無しさん** · 2022/03/13(日) 16:52:54.64

>>675-676
PYPLは「googleでチュートリアルが検索された数」＝「新規に学ぶ人の割合」だよ。
これが逆転してないようでは絶対にコミュニティ規模では追いつけない。
(「RustのおかげでC/C++を学ぶ人が増えてしまった！！！」と言われてたのはこれか？
なお俺が知りたいのは新規参入者の動向ではなく今現在のコミュニティ規模。tiobeの方がまだ近い）

とはいえ、学ぶ人数が数倍になってる状態を10-20年続けられれば、
現役のコミュニティも数倍程度に近づいてくるのだろうけど。
(PYPLを40年積分すればコミュニティ規模になる気がしている）

tiobeは「今検索された数」だから、現役のコミュニティで検索を使った人達の割合になる。（それ以外も色々勘案してるみたいだが）
(ネット以前の言語はネットが無くても書けるように出来てるし、実際、情報もショボイので低めに出るはず)
Rustは2018年に18位がピークで、現在26位。
Goは2020年に10位がピークで、現在13位。
tiobeのC(11.80%, 2位)は高すぎるがJS(2.30%, 7位）は低すぎる気も。ただしPHP(1.50%、12位)とは規模が合うが。

**デフォルトの名無しさん** · 2022/03/13(日) 16:53:39.94

数を気にするの日本人らしい

でも何で日本語なんてマイナー言語使い続けるんだろ？

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

>>681
キミは日本人以外の何をどれだけ知っていて
どれほどのサンプルから有意差を見出しているの？

**デフォルトの名無しさん** · 2022/03/13(日) 17:09:56.38

典型的な日本人の実例ありがとう

**デフォルトの名無しさん** · 2022/03/13(日) 17:57:01.73

>>680
だから一時的なもんだろうと言ったんだが・・・Rust信者は日本語も読めないらしい
個人的には
tiobeは興味本位で覗く人の数、先鋭的だけど流行に敏感
PYPLは実際に学ぼうとしてる人の数、割と実態に近いけど、採用実績というよりは希望に近い
と思っている

**デフォルトの名無しさん** · 2022/03/13(日) 18:35:41.81

>>678
Goの下落が目立ちますね

**デフォルトの名無しさん** · 2022/03/13(日) 18:56:49.09

pyplのその状況は一時的なものだと思うよ
tiobeになるけどRustは割と乱高下してる
https://www.tiobe.com/tiobe-index/rust/
goだとこんな感じ
https://www.tiobe.com/tiobe-index/go/

**デフォルトの名無しさん** · 2022/03/13(日) 19:02:32.50

>>686
どちらの言語もグラフがあまりにも乱高下しすぎているため
その調査は信頼できないと思います
まともな調査であればそのように激しい乱高下は起きないはずです

**デフォルトの名無しさん** · 2022/03/13(日) 19:06:14.35

検索数なので素人が多くポインタ周りで検索しがちなCや言語仕様がクソほどでかいC++は多くなりがち。HP作るために仕方なく調べてるケースがあるJSもそういう傾向あるかな

**デフォルトの名無しさん** · 2022/03/13(日) 19:08:05.31

>>686
GoもRustも同じく2017〜2018年あたりで信じられない大急落をしている
tiobeの調査自体に問題があると思われる
tiobeのデータは信用できない

**デフォルトの名無しさん** · 2022/03/13(日) 19:08:52.30

>>686
PYPLもグラフは出せるよ。
678のページで下に行ったら言語と地域を選べる。
WorldWideなら、
Goは飽和気味、
Rustは乱高下しつつも増加中でそろそろGoを抜く、
C/C++は漸減傾向だったが復活気味。

**デフォルトの名無しさん** · 2022/03/13(日) 21:08:28.44

https://pypl.github.io/PYPL.html
↑をキャプチャした画像でこんな感じだな
https://i.imgur.com/dP6UlBz.png

**デフォルトの名無しさん** · 2022/03/13(日) 21:47:14.65

後発のGoと更に後発のRustがまだ遅れているのは仕方ないですよね

**デフォルトの名無しさん** · 2022/03/13(日) 22:01:27.76

どちらかというと、このグラフは後発ほど有利なはずなんだけどね
JavaやC#は鳴り物入りで出現してあっという間に広まった
goの良さは玄人にしか伝わりにくい面があると思うので時間かかるのは仕方ないけど
Rustは現状だとごくごく一部の信者が必死になって喧伝してるだけのマニア向け言語だからどう見るかは微妙

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

>>692
TypeScript/Kotlin/Dartを重ねると現実が見えるかも
自動的に単調増加する程甘い世界ではない(ゼロサムだから当たり前だが）

**デフォルトの名無しさん** · 2022/03/13(日) 22:11:29.32

ごくごく一部のマニア（MS,Google,Mozilla,Amazom,Meta）

**デフォルトの名無しさん** · 2022/03/13(日) 22:21:31.43

>>695
GCなし・高機能・低レベル記述可・データ競合やメモリ安全性の保証あり
というプログラミング言語がRustしかないから
IT大手企業が揃って推している特別な存在ですね

**デフォルトの名無しさん** · 2022/03/13(日) 22:29:12.10

>>695
MS,Google,Mozilla,Amazonなどは出資してるだけで喧伝などしていない
彼らの土俵に非常に狭い有用な領域があるってだけｗ
それを見て勘違いしたごくごく一部のマニアが信者化して喧伝してる

**デフォルトの名無しさん** · 2022/03/13(日) 22:32:40.90

データ競合が起きにくいからってだけだよ
それを実現するために払った代償が大きすぎて、彼らも他の領域に積極採用しようとはしていない
その代償を払ってもお釣りが来るほど、性能＋品質が重視されるニッチな領域を彼らが持ってるだけｗ

**デフォルトの名無しさん** · 2022/03/13(日) 22:36:32.94

>>693
> JavaやC#は鳴り物入りで出現してあっという間に広まった
JavaはそうだったがC#は軟派扱いだったろ。
理由は簡単で、当初はDLLを作れず、unionも使えない、プロの実用に耐えるものではなかったから。
その辺整備して2000年代中頃からMSの主力言語となり、逆にVC++は何となく見捨てられて現在に至るが。
tiobeには下の方にそれも載ってる。
> Very Long Term History
> Java 14@1997 -> 1@2002
> C# 14@2002 -> 8@2007 -> 4@2012
> https://www.tiobe.com/tiobe-index/

> goの良さは玄人にしか伝わりにくい面がある
とはどこ？
開発周りならC#の方が断然上。何も考えずにVSに任せて終わり。
DLL今更いらんやろ、は一理あるが、継承を無くしたのは多分悪手。
あれはJavaで関数ポインタがなかったために馬鹿共がデザインパターンとかいうおかしな事をやらかしまくったのが問題で、
正しく使えるなら継承は有った方が確実にいい。
（ただし、フレームワーク作成ならさておき、ユーザーレベルではあまり必要ないのも事実だが）

>>695
そいつらが入ってその程度、という事実を認識した方がいい。
Rustを選ぶ理由がないんだよ。
最速を目指すならC/C++以外にない。
GCで良ければJava/C#/Goとかでいい。
安全性とか言ってるのは開発側の都合であって、ユーザーにとってはどうでもいい事だろ。
それでC/C++では出来ないような開発速度が出せるのならまだしも、それもないし。
(売りの「安全性」と「メモリリーク無し」はほぼ全部のGC言語が持ってる機能で、
そこから無理矢理GCはがして何とかなるか、という実験としては良いが、実際その程度の意味しかない）

**デフォルトの名無しさん** · 2022/03/13(日) 22:45:53.87

>>699
Rustは並行並列時でもデータ競合が完全にないことを保証できる
初のプログラミング言語

**デフォルトの名無しさん** · 2022/03/13(日) 23:00:37.10

>>700
お前らの「データ競合」が何を意味してるのか分からんが、
試しにJavaScriptでその「データ競合」する簡単なコードを書いてみてくれ。

**デフォルトの名無しさん** · 2022/03/13(日) 23:06:43.59

シングルスレッドでは起きない系じゃないかな

**デフォルトの名無しさん** · 2022/03/13(日) 23:08:56.83

>>702
分かってて言ってる。
だから「初の」ではないね、みたいな。

まあちょっと意地悪が過ぎたね。やめよう。

**デフォルトの名無しさん** · 2022/03/13(日) 23:24:47.74

並列処理時の話だろ？

**デフォルトの名無しさん** · 2022/03/13(日) 23:43:57.20

>>699
> JavaはそうだったがC#は軟派扱いだったろ。
> 理由は簡単で、当初はDLLを作れず、unionも使えない、プロの実用に耐えるものではなかったから。
> その辺整備して2000年代中頃からMSの主力言語となり、逆にVC++は何となく見捨てられて現在に至るが。
.NETは1からBeginInvokeがあったりして非同期処理の走りだったし、P/Invokeがあったりしてnativeも簡単に扱えたし、俺もオライリー読んで、Javaの二番煎じかと思ったら、Javaよりいいじゃんって思ってすぐ飛びついたよｗ
確かに.NETは少なくとも2までは俺の周りではJavaほど盛り上がってなかったけど今のRustよりは期待されてたなｗ
1でdllが作れなかったかどうかは忘れたけど、COMのI/Fも持ってて当時便利だとは思った

> > goの良さは玄人にしか伝わりにくい面がある
> とはどこ？
goの良さは必要十分なことが実用的な範囲でコンパクトにまとまってること

> あれはJavaで関数ポインタがなかったために馬鹿共がデザインパターンとかいうおかしな事をやらかしまくったのが問題で、
デザインパターンはOOPの分かりやすい成果だと思う(関数ポインタは実装なので関係ない)
最近の言語は構造とロジックは分離してるのが主流だけど、考え方は今でも有効だと思う
構造とロジックが緊密になりすぎて少し窮屈になるきらいはあるし、そうなるくらいなら分離もありだとは思う

**デフォルトの名無しさん** · 2022/03/13(日) 23:50:49.53

なんていうか・・・飼い犬に噛まれる的なことがないのがgo言語ｗ

**デフォルトの名無しさん** · 2022/03/14(月) 00:27:52.17

>>706
それは「自分の足を撃てるか」だな
http://www.toodarkpark.org/computers/humor/shoot-self-in-foot.html

>>705
その頃から知ってるのなら教えて欲しいのだが、
俺はC#のその辺は「GUIコンポーネントを触れるのがメインスレッドだけ」という、
GUI部分をシングルスレッド『強制』にしてしまったのがそもそもの問題で、
全GUIコンポーネントをスレッドセーフにしてしまえばその辺の面倒な話は一切無しで単純に済んだと思ってる。
これは今でもそう思う。
(最終的にasyncに持って来たのはすごいが）

これについて、C#が何故そうしたのかがよく分からない。色々尋ねて回った限り、
どうやらその前にJavaのGUIでマルチスレッドのがあって、それで酷い事になったから、
その失敗を見たC#は「絶対にGUIはシングルスレッド」と決めたらしい、というところまでは分かったのだが、その先が辿れない。
この辺について何か知ってたらよろしく。

> デザインパターンはOOPの分かりやすい成果だと思う
その割には今全く聞かないだろ。トレンドもダダ下がりどころではないはず。
頻出パターンを学ぶ、というのは正しいが、考えるのを止めて暗記に走るのが多分不味い。

> 構造とロジックは分離してるのが主流だけど
というよりはCでは分離出来なかった（分離しにくかった）からその頃はそんなもんだと思ってただけで、
分離出来るのなら分離した方がいいし、今はそうなってるだけだろ。
576のリンク先、
> Linux KernelのList構造は、データと分離されており、粗結合の状態です。
何ぞそれ？と思ったけど、
なるほどCでもこうやれば分離出来るのか、マクロって本来はこう使うべきだったのか、
最初のC++なんてただのマクロ集だったってのはこういう事か、
とは思ったね。俺がCやった頃は既に「マクロは使うな」みたいになってて、
小文字マクロオンパレードのLinuxKernelにはちょっと驚くのだけど。

**デフォルトの名無しさん** · 2022/03/14(月) 01:03:13.14

>>707
> それは「自分の足を撃てるか」だな
伝わらなそう。
危害を加えられるということではなく、特別に何か出来るわけでもなく、普通に思ったことが思ったとおりに出来て、想定外のことが起こらない的な意味。

> 俺はC#のその辺は「GUIコンポーネントを触れるのがメインスレッドだけ」という、
普通に呼ばれた先がスレッドセーフじゃないからだと思うけど…
同期を取ることそのものがコストになるし、そのコストを嫌ったのが元々の非同期の発想だと思ってたから、俺は違和感なかった
実際のところはMSの中の人じゃないから知らない

> > デザインパターンはOOPの分かりやすい成果だと思う
> その割には今全く聞かないだろ。
そうでもない、GoFの初期のパターンはもう各パターンが独り歩きして日常的に使われてるからそうおもうだけだと思う

> > 構造とロジックは分離してるのが主流だけど
> というよりはCでは分離出来なかった（分離しにくかった）からその頃はそんなもんだと思ってただけで、
classがないって意味だよ

> なるほどCでもこうやれば分離出来るのか、マクロって本来はこう使うべきだったのか、
Cにはテンプレートないからな…

**デフォルトの名無しさん** · 2022/03/14(月) 02:05:45.27

>>708
> 同期を取ることそのものがコストになるし、そのコストを嫌った
そりゃそうだが、現実的にロックが必要なのはGUIコンポーネントに「書く」時だけで、
つまりGUIを実際にユーザーが操作している瞬間であって、速い必要が全くない。
そしてロック周りはメソッド内に隠蔽してユーザーからは見えない状態に出来る。
だからそうすれば良いだけなのに、
結果を画面に表示したいだけの為にInvokeとかドタバタしないといけないのは間抜けすぎ。
とはいえ当時は我慢してたが、JS知ってC#のGUIは完全にゴミだったと理解した。
そりゃJSが快進撃するはずだよ。

デザインパターンについては俺はゴミだと思ってるよ。
あれは言語機能の不足分を示してる、という奴がいるだろ。それに近い。
例えばイテレーターパターン、コンテナ/イテレータ/処理をコンテナ/(イテレータ+処理）と切るわけだが、
関数型(forEach)は(コンテナ＋イテレータ)/(処理)、で切るだろ。
イテレータはコンテナと密結合なのだから、どう考えても関数型の方が妥当。
イテレータの管理なんてしたくもないし。
当然関数型も流行るし、Javaも関数ポインタを入れないわけには行かなかった。
だから、言語機能が整備されたから聞かなくなったけど日常的に使われてる、というのならまあそうだが、
おかしなパターン作りに邁進するのではなく、不足してる言語機能をさっさと充足させれば済んだ話。
方向性を完全に間違ってる。

> Cにはテンプレートないからな…
テンプレートこそマクロで書ける、というより、
テンプレート的なマクロを追い出す為のテンプレート導入なんだけどな。

**デフォルトの名無しさん** · 2022/03/14(月) 02:23:54.25

>>709
> とはいえ当時は我慢してたが、JS知ってC#のGUIは完全にゴミだったと理解した。
スレッドセーフにすると同期処理が入って遅くなるだけ、必要な同期を外で取るか中で取るかの設計選択でしかないので、スレッドを作らないときに遅くなる設計選択をしなかったというだけでしょ
逆に言えばもしスレッドを別にするならちゃんと同期してね、という意思表示でもあるだけ
別に俺は何とも思わなかった
当時のJSはクライアント側なので何の関係もないし、そもそもスレッドがない

> デザインパターンについては俺はゴミだと思ってるよ。
言語機能の不足とは違う。OOは言語を限定しないから。

> イテレータはコンテナと密結合
イテレータは抽象化されてるので密結合はしていない

> テンプレート的なマクロを追い出す為のテンプレート導入
俺が導入したわけでもないけど、型がないこと、ただの置換では限界があることの回避だと思ってた

**デフォルトの名無しさん** · 2022/03/14(月) 06:28:43.00

デザインパターンが大々的に使われる言語ってのは抽象化能力が低いって事だと思うんだよな。まぁあんまり細かいとこまで抽象化しても使いにくいから細かいパターンは何にでもあると思うけど。

GCがあれば安全ってのもちょっと視野が狭いんじゃなかろか。メモリが確保できない時（エラーを生成する余裕すらない時もある）とか、ここでGCに動かれては困る、とか。

**デフォルトの名無しさん** · 2022/03/14(月) 06:48:39.07

大々的に使われるという認識がもうおかしい
デザインパターンというのは昔からよくある、前提が揃ったとき、こうやっとくと割と上手く行く定石みたいなもの
そもそも要件次第で適用され、実装言語で表現するだけの代物だよ

GCがあれば安全とは、二重開放やリークなどの問題からの開放を意味するだけ
一般的にはリスクなので安全の一要素ではある
GCの実装は通常最低限の動作をするのに必要なメモリを最初に確保する
ここで動かれては困るは制御できるのとできないのがあるし、そんなのは実装次第
調べれば分かる仕様であり、安全とは無関係

**デフォルトの名無しさん** · 2022/03/14(月) 07:21:56.04

概ね同意。
大々的にってのは言葉が悪かったな。パターン以外で表現できず、必然的に乱用された、一時期のJavaみたいなのはおかしいだろってだけなんだ。

**デフォルトの名無しさん** · 2022/03/14(月) 10:05:06.21

必要もねえのに勉強しちゃって
必要もねえのに乱用しちゃうのが問題
必要なひとは必要な分だけ黙って使ってんのよデザパタなんて

イテレータパターンなんて
使うだけの人には不要なのよ
イテレータを提供する側の人
ライブラリを提供する側の人が
実装前にそっと紐解くのがイテレータパターンなんよ
で、使う側の人が「イテレータパターンは不要」とか抜かしてる裏で
すでにライブラリ作者によってパターンが適用されてんのよ

**デフォルトの名無しさん** · 2022/03/14(月) 10:05:42.69

×使うだけの人には不要なのよ
○イテレータ使うだけの人には不要なのよ

**デフォルトの名無しさん** · 2022/03/14(月) 18:58:59.94

彼は病気なんです
すみません…

**デフォルトの名無しさん** · 2022/03/14(月) 19:01:21.66

そういえばRustマンセーの人たちはデザインパターンやDI知らん人が多いよな
業務の人じゃないんじゃないかな

**デフォルトの名無しさん** · 2022/03/14(月) 19:33:27.88

rustにもデザインパターンと呼べるようなものはあると思うんだけどね
そう呼ばないだけて

**デフォルトの名無しさん** · 2022/03/14(月) 19:36:11.36

マスコミ業務の人はインターネットのことをそういう目で見ている

**デフォルトの名無しさん** · 2022/03/14(月) 19:38:30.40

DI使わないでどうやって大規模開発してるのか謎なんだがな
架空の大規模開発してるのだろうか？

**デフォルトの名無しさん** · 2022/03/14(月) 20:31:10.63

DI使わず大規模開発は普通に可能でしょ
そんな頭で大規模開発してることが謎だわ

**デフォルトの名無しさん** · 2022/03/14(月) 20:35:29.98

こんどはDIおじさんか...

**デフォルトの名無しさん** · 2022/03/14(月) 20:52:37.91

>>710
> スレッドを作らないときに遅くなる設計選択をしなかったというだけ
その通りだが、GUIでは事実上「スレッドを作らない」という選択肢がない。
メインスレッドで(確か)10秒以上のジョブを実行すると「GUIが固まるだろボケ！別スレッド起動しろ」と怒られ、
仕方なく別スレッドを起動すると、結果を表示する際に「GUIコンポーネントは別スレッドからは触れねえよボケ！Invokeしろ」と怒られる。
よって、「計算結果をprintfするだけ」のCUIアプリをGUIにするだけの為に、「別スレッド起動してInvokeする」コードが必要となる。
全く馬鹿げてるよ。
どうせ計算結果を待つしかないのだから、待つ間にGUIが固まってもどうって事無い。
それが嫌なら「別スレッド+Invoke」で、面倒で手抜きしたいのなら「GUI固まりますがどうぞ」でよかったのだが、
MSは後者の選択肢を残さなかった。
JSだとこの辺の糞っぷりが全くなく、別方法で綺麗に解決されてた、というわけ。

まあ見解の相違はおそらくそちらはCUIアプリが主だったか、真面目に実装するタイプなのだろう。

**デフォルトの名無しさん** · 2022/03/14(月) 20:53:26.06

> イテレータは抽象化されてるので密結合はしていない
イテレーターパターン推し連中の公式見解だな。
ただ、目的とどこまでやるべきかを考えれば、問題点は簡単に分かる。
俺は、

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

と考えてる。抽象化が「本質(共通）部分のみを抜き出す」事なら、共通部分が残っているようなら抽象化が不十分だ。
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.73

で、ついでに言うと、イテレータ自体はコンテナと必ず密結合してる。
コンテナの内部構造を変更されたらイテレータ自体も変更しないといけないだろ。（イテレータを使う側のコードは変更不要）
そして、
イテレーターパターン：オレオレコンテナにはイテレータを用意しろ --- (A2)
ダックタイピング：オレオレコンテナにはforEachメソッドを用意しろ --- (B2)
だが、イテレータの用意は共通インタフェースにする程度の設計は必要なのに対し、
forEachメソッドの用意はただ回せば済むから、A2よりもB2の方が簡単なんだよ。
ここで「簡単」で済む理由は、B2の方が「自然」だからであり、A2で切るのは「不自然」だからだ。
コンテナとイテレータは一体であり、内部処理はそれとは全く関連無いから元々疎結合。
それを(コンテナ)/(イテレータ＋内部処理）と無理に切るからおかしくなる。
(コンテナ＋イテレータ)/(内部処理)なら元々疎結合のところで疎結合にしてるから余計な手間がかからないという、ごく当たり前の話。

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

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

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

そして「この場合はこう実装しろ」を規定するのはコーディングルールや設計方針であって、
「頻出パターン図鑑」であるデザインパターンではない。

**デフォルトの名無しさん** · 2022/03/14(月) 20:55:01.53

forEachが関数型とか信者に刺されるぞ

**デフォルトの名無しさん** · 2022/03/14(月) 21:05:55.05

外部イテレータに対し内部イテレータをこんなに有難がる奴初めて見たわ

**デフォルトの名無しさん** · 2022/03/14(月) 21:07:05.83

>>726
せめてreduceだよね

**デフォルトの名無しさん** · 2022/03/14(月) 21:09:52.99

>>726
そうなんだけど、じゃあ何型だ？と言われて、手続き型に入れるわけにもいかんだろ。

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

逆に、Java周りの歪みは「関数ポインタを使えない事」による物が大きい。
(だから今後は徐々に改善していくのだろうけど）

**デフォルトの名無しさん** · 2022/03/14(月) 21:11:48.03

>>723
別に全く苦ではなかったね

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

>>725
シグニチャにiteratorしか入っていない以上密結合していようがない

**デフォルトの名無しさん** · 2022/03/14(月) 21:15:50.98

関数ポインタが上級テクニック！！？？

**デフォルトの名無しさん** · 2022/03/14(月) 21:19:10.98

こんだけ長文書かれるとどうしても、あちこち突っ込みたくなっちゃうな

**デフォルトの名無しさん** · 2022/03/14(月) 21:21:31.14

>>729
Reflectionでもinterfaceでも似たようなことできるし、それが必要と思ったことがない
C#のdelegateみたいな機能は新鮮だったけど

**デフォルトの名無しさん** · 2022/03/14(月) 21:27:54.46

GoFのデザパタ本ではイテレータパターンでは
> ◎実装
> Iteratorパターンには、実装に関して多くの方法とその変形がある。(略)
> 1.どのオブジェクトがiterationをするか
> （以下、内部外部イテレータの紹介部分略）
> 外部iteratorは内部iteratorに比べてより柔軟である。
> 2つの集合が等しいことを外部iteratorを使って比べるのは容易だが、
> 内部iteratorでは実用的には不可能である。(以下略)」
つまり、内部イテレータも外部イテレータもパターンとして既出
どっちの実装もともに検討されている

**デフォルトの名無しさん** · 2022/03/14(月) 21:40:17.81

スレタイの言語の中でjavaで培われたデザインパターンが効果的な言語ってあんの？

**デフォルトの名無しさん** · 2022/03/14(月) 21:41:33.54

継承自体が古いからな……

**デフォルトの名無しさん** · 2022/03/14(月) 21:43:55.10

知らず識らずのうちに使ってしまってるのがデザインパターンだよ
名前がなかったからあえて付けて一言で通じるようにしたことがGoFの功績

**デフォルトの名無しさん** · 2022/03/14(月) 21:46:41.46

初心者のうちはデザパタに興味持たなくていいよ
必要性を感じてからはじめて手を出せばいい
興味本位だけで手を出しても何も得られない
勉強にもならない
半可通によるデザパタ乱用か
デザパタ不要論者になって暴れだすか
繰り返すが
デザパタには必要にかられてから手を出せば十分

**デフォルトの名無しさん** · 2022/03/14(月) 21:48:26.00

>>733
> それが必要と思ったことがない
それはJavaの話？なら最悪だと思うのはGUIで、

element.onclick = function(){};

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

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

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

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

**デフォルトの名無しさん** · 2022/03/14(月) 21:55:55.62

>デザパタには必要にかられてから手を出せば十分

後から必要にかられることなんてあるのかね

**デフォルトの名無しさん** · 2022/03/14(月) 21:57:36.60

>>739
awtの頃はそんな感じでいろいろ大変だったと思うけど、JWTとか出てきてからは内部クラスでやるようになって、そこから先はJava2Dとかいろいろ出て来たけど追ってない。
今はJavaFXみたいだけど、まるで浸透してる気配はないね。
そもそもで言えばJavaでGUIはあんまりやらんけど、理由はクライアントツールならWindowsだから.NETでいいという感覚からだと思う。
個人的にはnativeと繋ぎやすいなど、.NETの方がメリットを享受できたからだと思うよ。
何度も言うけど、JavaScriptと比較するのは根本的に間違っている。

**デフォルトの名無しさん** · 2022/03/14(月) 22:02:13.08

うっかり用語素で間違ったｗ JWTじゃなくてSwingね

**デフォルトの名無しさん** · 2022/03/14(月) 22:37:01.86

>>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.90

継承は結構GUIと相性良いので、その主張はズレてるとしか感じないな。
関数が第一級オブジェクトであるメリットはそんなGUIがどうのこうのなんて狭い範囲で語れる話じゃないし。

**デフォルトの名無しさん** · 2022/03/14(月) 22:58:10.20

>>743
Webの画面をGUIとは言わない…
Webであれば、基本はHTML＋JavaScript(+CSS)であり、これに最近wasmが付く程度
サーバー側の言語はいくつかあるが、最終的にクライアントに送れるのは上記であり、表現は違わない
最近は仮想DOMを使用するタイプのクライアント側でテンプレートを流し込むコンポーネントを記述するのが普通で、デファクトはJavaScriptを使用するreact
Javaで典型的なSpringは業務に使用されることが多いため、そもそもSPAである必要がなく、昔ながらのサーバー側でテンプレートを流し込むページ記述が普通だと思う
双方を比べるのはいささか不自然で、なんで比較したいのかすら分からない
C#だとBlazorがあって、これだとwasmを使うことでクライアント側も.NETで記述できる
あんまり人気ないけどね
何に対してどんな文句を言いたいのかサッパリなので、よく整理してから話すように

**デフォルトの名無しさん** · 2022/03/14(月) 23:03:29.39

>>744
エスパーするが、
> 継承は結構GUIと相性良い
これはGUIコンポーネントを『作る』側、つまりフレームワーク作成側の話だろ。
俺が言ってるのは『使う』側、つまり実際にJS同様GUIのコードを書く時についてだ。

> 関数が第一級オブジェクトであるメリット
ちなみにこれは俺は未だに理解出来ないので具体的に教えて欲しい。
実際、関数にメソッドを生やせるだけで、何かが出来るようになるわけでもないので、
全部入りのC++もまだ第一級オブジェクトとしての関数を入れてないし、多分検討もしてない。

**デフォルトの名無しさん** · 2022/03/14(月) 23:14:29.77

>>745
> 何に対してどんな文句を言いたいのかサッパリなので、よく整理してから話すように
いや文句を言うのは既に終わってて、俺のスタンスを繰り返し言ってるだけ。
だからまあ、もう終わりでいいのも確か。

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

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

まあしかし、合意を形成する必要もないし、
言いたい事は既に言ってるし、まあ終わりでいい。
色々ありがとう。
少なくとも当時のC#使いが全く問題を感じてなかったという事だから、
・C#はもともとGUI向けの設計ではなかった
・.NETはそもそもユーザーの想定レベルが高くて無駄に苦労する
のかもな、とは思えてきた。

**デフォルトの名無しさん** · 2022/03/14(月) 23:34:58.46

>>740
自分が当たり前にやってることを他人に説明する必要が出てきた時にパターンの名前が必要になる

**デフォルトの名無しさん** · 2022/03/14(月) 23:43:23.14

>>702
データ競合はシングルスレッドでも当然起き得る

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

>>703
どんなケースでもデータ競合が起きないことを保証する初のプログラミング言語はRustで合っているのではないか

**デフォルトの名無しさん** · 2022/03/14(月) 23:45:07.77

>>747
> > 何に対してどんな文句を言いたいのかサッパリなので、よく整理してから話すように
> いや文句を言うのは既に終わってて、俺のスタンスを繰り返し言ってるだけ。
> だからまあ、もう終わりでいいのも確か。
じゃあ終わりで
最後にWebの画面レンダリングをGUIに持ってくるケースはある
JavaScriptのelectronやRustのtauri、古くはIEコンポーネントみたいなので非常に特殊なパターン
vscode他を除けば、ゲームとかワンチャンモバイルも狙うGUIでたまに使用されるとか、アプリでWebの画面を出したいとき稀に使用される
嵩張るために滅多に使用されないか、こっそり使用されることが多い

**デフォルトの名無しさん** · 2022/03/14(月) 23:45:51.86

>>749
とりあえず「データ競合」の意味を具体的に明確にしてくれ

**デフォルトの名無しさん** · 2022/03/14(月) 23:47:54.88

>>749
正確には「保証する」みたいな強い言葉だとそれだけで独り歩きするのでいかんｗ
「仮定することができる」くらいだな

**デフォルトの名無しさん** · 2022/03/14(月) 23:57:31.30

>>709
イテレータはコンテナと密結合、は間違い
そのようになってしまっている悲しい言語も存在するだけにすぎない
例えばRustなどではイテレータ連鎖に一度もコンテナが登場すらしないこともあるように
イテレータとコンテナは独立の存在

コンテナの中身を順に出すイテレータを作れるとか
イテレータが吐き出したものをコンテナに格納できるといった
端点で関連するケースがありうるだけにすぎない

**デフォルトの名無しさん** · 2022/03/15(火) 00:10:15.67

>>718
どんなプログラミング言語にだってあるよ。
デザインパターンってのは似たような問題領域における対処法や設計ノウハウに共通の言葉を定義したコミュニケーションツールだからな。

**デフォルトの名無しさん** · 2022/03/15(火) 00:13:54.20

デザインパターンの時代には抽象化されたループや分岐が作られた
それを具体化するたびにクラスを作りクラスに名前をつける
まるでgotoの行き先にいちいち名前をつけるみたいに

そのあとラムダが普及して名前をつける必要がなくなった
whileやifやelseのブロックに名前がないのと同じ

**デフォルトの名無しさん** · 2022/03/15(火) 00:35:40.32

>>753
> イテレータはコンテナと密結合、は間違い
間違ってねえよ。
というか、多分「密結合＝悪」と洗脳されてるから否定したいのだろうけど、
俺が言ってるのは、

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

という事。だから

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

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

forEachが遅かったからイテレータ、ならそれは「言語の不備」だよ。
C++はその辺順番を入れ替えて同速にしてしまったし、知らんがRubyでもlazyモードで同様なんだろ。
勿論イテレータの方がいい場合もあるはずだが、これは昨今のimmutableや再代入を避けるのと同様、
これまでは不要にイテレータを使いすぎてただけ。
本当にイテレータが必要なところだけイテレータにして、その他はforEach(関数ポインタ）の方がいいよ。

**デフォルトの名無しさん** · 2022/03/15(火) 01:11:07.84

何度も言うが、デザインパターンの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.13

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);});
}
}