次世代言語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/02(水) 09:26:05.15

>>440
温故知新ですな

**デフォルトの名無しさん** · 2022/03/02(水) 09:36:25.73

>>449
unsafeは無くすことできないから閉じ込めるってことなんだが。
unsafeあったらダメ原理主義者ですか？

**デフォルトの名無しさん** · 2022/03/02(水) 10:24:25.41

>>432
結局データの配列として持つことになるのはわかるけど、それって指す先が存在するか分からないから実質ポインタとやってること同じだし、途中で要素削除があるとインデックスの整合性保つのに一苦労するじゃん

まあ君にとっては「レアケース」であり「現実に必要となることが存在しない」のかもしれんが、実際に存在するとだけは言っておくわ

あと、配列とインデックスの方がメモリアクセスも速いってのはわからんかった。配列とインデックスの方がポインタより速いってなんでだろ

**デフォルトの名無しさん** · 2022/03/02(水) 10:28:21.60

まあベルマンフォードする前に配列とインデックスの形式に変換するくらいのことは出来るけど、結局その前段階のミュータブルなグラフを配列とインデックスで管理するのはキツい
アリーナでオレオレ世代型GCモドキを作った方がまだマシ

**デフォルトの名無しさん** · 2022/03/02(水) 10:32:20.03

あとは配列とインデックスの代わりにHashMapとkeyにするとかかな？

**デフォルトの名無しさん** · 2022/03/02(水) 10:38:44.95

配列とインデックスってすげーunsafeなコードだよな
unsafeブロックの外側でunsafeな処理をしている分余計性質が悪い

**デフォルトの名無しさん** · 2022/03/02(水) 11:04:57.08

>>455
配列indexでグラフ構造表現する場合、インデックスが変わるような方法で要素を削除することはしないのでは
要素ごとに削除フラグを立てるとか、free listで未使用要素のインデックスを管理するとかが普通だと思う

>>458
ここで言うunsafeってどういう意味のunsafeなの？
rustの定義のunsafeとは違うことを言っているようにみえる

**デフォルトの名無しさん** · 2022/03/02(水) 11:42:21.29

>>456
＞その前段階のミュータブルなグラフを配列とインデックスで管理するのはキツい
＞アリーナでオレオレ世代型GCモドキを作った方がまだマシ

同意

**デフォルトの名無しさん** · 2022/03/02(水) 12:43:54.27

グラフなどのノード構成において
他のノードを指す方法として「idを用いる」のと「ポインタを用いる」のは完全に同型
というのがプログラミングでの常識です
同型というのは通常の管理からダングリングの発生やその防止も含めて同型です

配列に格納してそのインデックス方式も「idを用いる」方式の一種ですから
これも当然「ポインタを用いる」のと完全に同型です
どちらか片方の管理方法がキツイと言ってる人は完全に間違っています

これはGCを考慮した場合についても完全に同型です
誰もそのポインタを指さなくなったことと誰もそのidを指さなくなったことが対応します
したがって配列とインデックスで管理することで管理がキツくなることはありません
そしてGCをする場合も全く同型なので同じ方式同じアルゴリズムで互いに行うことができます

**デフォルトの名無しさん** · 2022/03/02(水) 12:50:37.42

常識かあ

**デフォルトの名無しさん** · 2022/03/02(水) 13:01:35.27

>>452
標準のをそのまま使えと？
想定ケース次第だと思うけど、どういうのが多いんだろうね

>>454
主旨が伝わってない...
まあ標準ライブラリ以外でunsafeを使ったら、それをcrateごとに分かるように名前にunsafeを付けるなりはしてほしいね

>>461
循環参照の回避はできてんだろ何言ってんだ…

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

あと主旨は>>451だぞ

**デフォルトの名無しさん** · 2022/03/02(水) 13:23:30.55

>>461
それは全て正しいが
現実にはそこに付け加えるべき重要な事項がある
GCのコードを書くとわかるが使われたidの一覧が必ず必要となる
ポインタ方式ならば使われたポインタの一覧が必ず必要となる
インデックス方式ならば使われたインデックスの一覧が必要となる

すると『使われたポインタの一覧を管理するコスト』よりも
『使われたインデックスの一覧を管理するコスト(＝最大インデックスまで)』がはるかにコストが低い
つまりGCをする場合でもインデックス方式が有利となる
もちろんそれ以外のアルゴリズムなどは同型なので同じという点には同意

**デフォルトの名無しさん** · 2022/03/02(水) 13:37:04.28

循環参照がレアケースとかいう人はもう発言しないでいいと思う
数年間は黙ってみんなの意見を読んで勉強しましょうね

>>423
> 循環参照が必要な時にやれることが「プログラマが注意して管理しましょう」しかない

それがGCなし言語
それがRustの選んだ道
メモリ管理はプログラマが手動でなんとかするしかない

>>445
> 各分野で日々回避方法が研鑽されている

心静かに同意だわ

>>458
> unsafeブロックの外側でunsafeな処理をしている分余計性質が悪い

キミは賢いね

**デフォルトの名無しさん** · 2022/03/02(水) 13:59:21.59

>>465
その点についてはおっしゃる通りです
ポインタ一覧を管理するコストとインデックス一覧を管理するコストは同型か否かの枠外です
ダングリング防止やGCアルゴリズムなどは同型となるでしょう

>>466
あなたはRustにおけるunsafeとは異なる意味でunsafeという単語を用いているようです
もちろんRustと無関係な場においてunsafeの意味を独自に用いるのはあなたの自由です
しかしあなたはRustという単語を出していますからRustにおけるunsafeの意味に従う必要があります
勉強して出直してくることをお勧めします

**デフォルトの名無しさん** · 2022/03/02(水) 14:08:49.30

だんだん話がオレオレGCになってきたな
結局GCは必要なんだよ
必ずしも標準に入ってる必要はないが、優秀はGCライブラリが存在しないのはかなり痛い

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

>>468
いいえ、GCは必ずしも必要あるわけではありません
GCが必要になるのは少なくとも以下の2点を満たす必要があります
・継続して動作させる必要がある
・使われていないメモリが有意に存在している
例えばGC言語であっても前者の継続動作が必要なければGCさせないモードで動かすケースもあります
一方で後者はGC言語であれば常に使われていないメモリが溜まっていきます
しかし非GC言語ではたいていの場合はメモリ開放をすることができるためGCは不要です
どうしても循環強参照を起こしたいというかなり特殊な状況でなければGCが必要になることはないでしょう

**デフォルトの名無しさん** · 2022/03/02(水) 14:32:11.16

あ、循環参照はかなり特殊な条件派のひとだったか
じゃあ話すことはないや

**デフォルトの名無しさん** · 2022/03/02(水) 14:34:46.39

>>468
C++に謝れ

**デフォルトの名無しさん** · 2022/03/02(水) 14:44:37.86

C++用のGCライブラリは実在してるだろ

**デフォルトの名無しさん** · 2022/03/02(水) 14:56:29.68

>>470
循環強参照を起こしたいかなり特殊な状況であっても
プログラムを継続して動作させる必要がなければGCは不要です
これは広義にはプログラム自体は継続してもその構造が長期継続しなければ成り立ちます
例えばRustならばtyped_arenaなどを用いればその構造の利用を終える際に一気に全体を消去可能です
また別の視点からはデータが単調増加ならば不要部分が発生しないのでこれもGCは不要です
これら全ての条件を相反するような条件が全て揃った時のみGCが必要となるでしょう
もしそのような具体的なケースが頻繁に多数有るならば教えていただけると勉強になりますのでよろしくお願いします

**デフォルトの名無しさん** · 2022/03/02(水) 15:05:14.83

なんで特殊な条件派を説得しにかからず初手会話放棄するかというと、仕事で使っていておいそれとネットに晒せないからですね
なので秘密を打ち明けなくても前提に同意してくれている人とのみ話す訳ですよ

**デフォルトの名無しさん** · 2022/03/02(水) 15:13:30.85

>>474
一般的な用途ならば仕事に関係なくその一般的な用途だけ話せばよい
そうでないのならば
君も一般的な用途でGCが必要となる具体例は無い派ということになる

**デフォルトの名無しさん** · 2022/03/02(水) 15:16:36.71

>>475
一般的な話をすると増えたり減ったりする双方向グラフを更新し続けて持ち続けるという要件になるな
それ以上の説明を求められると何に使うのかという話をすることになり、俺の仕事の説明をすることになる

**デフォルトの名無しさん** · 2022/03/02(水) 15:18:35.45

「一般的な用途」というのがどういう定義なのかしらんが、「Rustで簡単に出来る範囲を一般的と呼ぶ」と恣意的に定義するのであれば俺もその派に入れてくれて良いよ

**デフォルトの名無しさん** · 2022/03/02(水) 15:32:26.52

>>476
それならばその双方向グラフの安全な型を作るのがベストソリューションです
ちなみになぜそのような一般的なライブラリがないかというと各々で求められる条件が異なるからです
あなたの場合は求められる条件が確定しているのですからそれを満たす双方向グラフの安全な型を実装できます
例えばノードが削除される場合もその際の条件やその後の処理が独自に確定しているはずです
したがってそれを元に双方向グラフの安全な型を実装して安全なインタフェースのみ提供すればいいのです
そうすればRustのコンパイラに対してもプログラム全体が安全に通るでしょう
そして循環参照についてもその双方向グラフの安全な型が責任を持って取り扱えばよいのです
汎用的なGCは不要でその状況に特化したものを用意すればいいだけなので容易に実現できると思います

**デフォルトの名無しさん** · 2022/03/02(水) 15:45:33.96

>>478
まあできるかどうかで言えば出来ますけどね。容易とは思わないけど。
結局>>423なんだよな。そもそも頑張って安全なインターフェースを提供するだけならCでもできるし（>>478には容易かも）

まあ汎用GCついてる言語ならこんな面倒なことしないでいいのでGC言語使おうってことだろうな

**デフォルトの名無しさん** · 2022/03/02(水) 15:46:04.46

$ cat hoge.sh
cat >hoge.rs <<EOF
// unsafeって宣言に出てこないし安全に決まってるよ！
fn read_address_4byte(address: usize) -> i32 {
unsafe {
*(address as *const i32)
}
}
// 流石Rust安全だな！
fn main() {
read_address_4byte(0);
}
EOF
rustc hoge.rs && ./hoge
$ bash hoge.sh
hoge.sh: 13 行: 124161 Segmentation fault (コアダンプ) ./hoge
$

**デフォルトの名無しさん** · 2022/03/02(水) 15:58:09.24

>>479
いいえ、C言語にはここでいう「安全な」の定義がないので無意味です
一方でRustでは「安全な」インターフェースを提供する型を作れば
それを用いてコンパイラによりプログラムの安全性を保証することが可能です

>>480
「unsafe」の勉強をして出直して来ることを勧めます
そのread_address_4byte関数は条件を満たせていないので
unsafe fn read_address_4byte(address: usize)と宣言しなければいけません

**デフォルトの名無しさん** · 2022/03/02(水) 15:59:49.43

>>481
あー。まあそれはそうね外側でもunsafeなのは頂けないたしかに

**デフォルトの名無しさん** · 2022/03/02(水) 16:02:47.42

あれぇ・・・コンパイル通ってないと実行できないんだけどなぁｗｗｗｗ
エラーも何も出てこないんだけどなぁｗｗｗｗ
安全とは？？？
Rustが安全！？
何をご冗談をｗ

**デフォルトの名無しさん** · 2022/03/02(水) 17:00:29.10

教官「GC無しで手動メモリ管理してきた言語だ、面構えが違う」

C/C++/Rust「（ﾟωﾟ）」

**デフォルトの名無しさん** · 2022/03/02(水) 17:26:12.32

おじさん来た？
スレの質が一気に下がるな

**デフォルトの名無しさん** · 2022/03/02(水) 17:53:39.61

>>482
そう
外側ではunsafeを使わない
その上で今回のケースはその独自仕様の双方向グラフの「安全な」型を作れば、Rustではプログラム全体の安全性が保証されます
そして「安全な」型を作るには
・型が外へ提供する「安全な」インターフェイス群を用いる限り、それらをどのように用いても、型の内部に矛盾や危険な状態を生じさせないこと
・たとえ型の内部でunsafeな操作が存在していても、型の外へは影響せずに内部に封じ込められていること
このような形で新たな型を実装することで全体を安全に解決できるところが他の言語にはないRustの特徴でしょう

**デフォルトの名無しさん** · 2022/03/02(水) 18:05:00.35

まあGCライブラリさえあれば双方向グラフも簡単に作れるんですけどね
Javaくらいの出来のGCライブラリがついたら最強

**デフォルトの名無しさん** · 2022/03/02(水) 18:30:26.52

Rustには静的型付けがあるすげー　←　スクリプトから来た人
Rustは強力な型推論がある　←　スクリプトかC++から来た人

こういう主張をする人は世間知らず
つまり雑魚

**デフォルトの名無しさん** · 2022/03/02(水) 18:40:10.58

関数型言語以外の型推論は大体が変数の型や戻り値型の推論で、HM型推論採用してる言語ってあまりない気がする
もしそうならば非関数型言語にしてはRustは型推論が強力と言っても良いのでは

**デフォルトの名無しさん** · 2022/03/02(水) 18:42:57.57

お猿さんは『「安全な」型を作れば、Rustではプログラム全体の安全性が保証されます』などと宣っているが、それは言語で保証しているのではなく、プログラマが手で保証しているに過ぎないｗ
つまりunsafeなブロックを少しでも含むものはC/C++と変わらないわけで、それを使っている部分も、どこでどう使うものなのか分からない限りC/C++と変わらないということｗ
さらに悪質なのは、Rustの外のライブラリなどunsafeな何かを呼び出しているわけでもないのに、自前で破壊的なコードを内包できる仕組みｗ
こうなると、もう外面だけでは分からないわけで、Rustの安全神話は完全に崩壊するｗ

またこのような状況に拍車をかけているのが自前で破壊的なコードを内包する動機になりやすい所有権の概念ｗ
安全性の根幹をなす部分であるにも関わらず、双方向参照への例外なく簡単に適用可能な安全かつ高速な対応方法が存在していないｗ
これはプログラマに対してunsafeへの誘惑を助長する形で、逆に安全神話の崩壊を招いているｗ

まあRustは数ある実装言語の1つとして今後も使っていくとは思うけど、何でもRustに肩入れするお猿さんとはちゃんと線を引いていきたいｗ

**デフォルトの名無しさん** · 2022/03/02(水) 18:47:26.04

https://www.thecodedmessage.com/posts/unsafe/
> “If you have to use unsafe to write good Rust, then Rust isn’t a safe language after all! It’s a cute effort, but it’s failing at its purpose! Might as well use C++ like a Real Programmer!”
このブログでstrawmanとして挙げられてる主張そのまんまじゃん
まずは議論のベースラインとしてこの記事読もうぜ

**デフォルトの名無しさん** · 2022/03/02(水) 18:57:48.03

>>490
全然違いますよ
CやC++ではunsafeなコードがプログラム全体に散らばってしまうため複雑になればなるほど人間にはどうしようもなくなります
一方でRustではunsafeなコードを各ライブラリや各型の中に封じ込めて外へはその影響を及ぼさないことを保証するだけでいいのです
あとはプログラム全体がどんなに大きく複雑になろうともコンパイラが安全性を保証してくれます

**デフォルトの名無しさん** · 2022/03/02(水) 19:01:56.37

Rustの推論はプログラム追記で破綻する
後方で馬鹿が型を間違えて追記した場合予想した結果と異なる結果になる
しかもエラーが出ない

仕様が悪い

**デフォルトの名無しさん** · 2022/03/02(水) 19:05:48.62

>>493
Rustは孤児ルールがあるからそんなことは無理だぜ

**デフォルトの名無しさん** · 2022/03/02(水) 19:16:11.77

>>492
それが実際に違ってなくて同じという主張だろｗ日本語読めないのかよｗ

**デフォルトの名無しさん** · 2022/03/02(水) 19:31:49.02

会社でいたら距離置きたいな…

**デフォルトの名無しさん** · 2022/03/02(水) 19:39:09.37

>>491
クソ長い英文読まされた上に被ってる部分が全くなかった悲しみ

**デフォルトの名無しさん** · 2022/03/02(水) 20:09:18.80

>>487
javaの出来は良くないぞ
ヒープのサイズかなり引き上げないとすぐメモリ不足になります

**デフォルトの名無しさん** · 2022/03/02(水) 20:11:07.76

底辺プログラマにunsafeを使わせないってことで安心安全になる仕組みなんだね

**デフォルトの名無しさん** · 2022/03/02(水) 20:20:58.51

より正確には底辺プログラマや広範囲な用件にRustを勧めないことで、双方向参照要件などの対応に破壊的なコードを混入させない/混入しても経験豊富なC/C++プログラマが書くコードに匹敵する品質にさせることで、安心安全になる仕組みｗ

**デフォルトの名無しさん** · 2022/03/02(水) 20:25:05.11

>>498
その程度で出来ってなんだよｗｗｗｗ

**デフォルトの名無しさん** · 2022/03/02(水) 21:26:39.54

>>497
読んでくれてありがとうございます。

**デフォルトの名無しさん** · 2022/03/02(水) 22:40:07.92

Rustはお馬鹿さんには使えない
それが一番の参入障壁

**デフォルトの名無しさん** · 2022/03/02(水) 22:42:38.46

>>458
確かにimmutableな配列とインデックスは整合性を保って更新される保証が無いから別の仕組みでラップする必要がある
それってunsafeをラップするのと変わらないかもな

**デフォルトの名無しさん** · 2022/03/02(水) 23:57:29.40

out-of-boundsとsegmentation faultは違うｗ
前者はsafeかつ検出可能な実装ミスで、後者は検出可能か不明な未定義動作ｗ

**デフォルトの名無しさん** · 2022/03/03(木) 00:22:39.48

rustがむずかしいお陰で仕事あるからその点はありがたいね

**デフォルトの名無しさん** · 2022/03/03(木) 00:47:10.38

え、そう？
まだRustの案件少なすぎひん？

**デフォルトの名無しさん** · 2022/03/03(木) 02:41:24.89

ないこともないが限りなく地雷くさい

**デフォルトの名無しさん** · 2022/03/03(木) 08:01:02.29

>>503
プログラミングできます→馬鹿の可能性あり
Rustできます→馬鹿でない
ステータスになるな

**デフォルトの名無しさん** · 2022/03/03(木) 09:55:48.59

プログラミングできます→馬鹿の可能性あり
Rustできます→ステータスになると勘違いした馬鹿確定

**デフォルトの名無しさん** · 2022/03/03(木) 10:16:01.15

実際問題、言語知識の有無なんかよりもそういう無駄なプライドのがよっぽど開発の邪魔をするからな。

**デフォルトの名無しさん** · 2022/03/03(木) 11:35:08.39

アマチュアがステータス目的で手を出す言語：C++, Haskell, Scheme
ドカタが生きるために手に取る言語：Java, JS, php
情報系出身が身につけていがちな言語：C, C++, Pascal, Prolog, Emacs Lisp
電気屋さんが必要にかられて手を出す言語：C
測定機器に囲まれてる人が手を出しがちな言語：matlab, LabVIEW

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

ゲーム開発で使う言語　C++ C#
その他の人向けの言語　Python

**デフォルトの名無しさん** · 2022/03/03(木) 18:29:13.09

PrologとLispくらいは簡素なわりに他言語と差があり
学習しておくと各言語を客観視しやすくなって役立つね

**デフォルトの名無しさん** · 2022/03/03(木) 18:57:00.77

Prologは果たしてプログラミング言語なのかと言う疑問は置いといて

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

いろいろ違ってるｗ

**デフォルトの名無しさん** · 2022/03/03(木) 19:43:03.78

>>512
電気屋ってクソワロタ

**デフォルトの名無しさん** · 2022/03/03(木) 19:48:09.63

業界用語だろ

電気屋さん
電子屋さん
はかり屋さん

現場に色々いる

**デフォルトの名無しさん** · 2022/03/03(木) 19:54:47.77

電気屋さんも馬鹿にできないんだぞ
日頃ハンダゴテ握ってるような人も
PICやFPGA触ってたりするんだもん

**デフォルトの名無しさん** · 2022/03/04(金) 11:39:05.33

馬鹿にしてるのは馬鹿だけだから気にすることはない。

**デフォルトの名無しさん** · 2022/03/04(金) 12:49:38.60

>>515
さすがにチューリング完全をプログラミング言語じゃないと疑うのは不勉強。
brain f*ckですらプログラミング言語言われているのに。

**デフォルトの名無しさん** · 2022/03/04(金) 13:23:54.20

よくチューリング完全を引き合いに出す人いるけど、その定義だと感覚的に合わないものまでプログラミング言語の枠に収まるし、prologはそんなこと考えるまでもなくプログラミング言語だろ
しかも(俺は>>515ではないが)515が言いたいのは自然言語に近いと言いたいだけだと思う
実際中身は手続き型の言語と大差ないんだけどｗ

**デフォルトの名無しさん** · 2022/03/04(金) 14:11:55.85

>>522
自然言語は形式言語じゃないから、もしそうならもっと勉強不足だな。

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

お前の頭が固いだけ

**デフォルトの名無しさん** · 2022/03/04(金) 14:49:04.72

自然言語は全く関係ないな
手続き型言語しかやったことのない似非プログラマーには宣言型言語がそう見えるのか

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

頭固いねｗ例えば、

親(ひろし,ももこ).
親(友蔵,ひろし).
親(友蔵,すみれ).
親(すみれ,ももこ).
男(ひろし).
男(友蔵).
女(すみれ).
女(ももこ).
祖父(X,Y):-男(X),親(X,Z),親(Z,Y).
?-祖父(X,Y).
X = 友蔵, Y = ももこ

みたいなことができるってこと
二個出るけどｗ

**デフォルトの名無しさん** · 2022/03/04(金) 16:28:33.22

プロログはパターンマッチ型データベースに見える
あと同じのが二つ出るのは近親相姦してるからだ

**デフォルトの名無しさん** · 2022/03/04(金) 20:48:14.68

prologのノリがどの言語にも持ち込まれてないのも問題だ

**デフォルトの名無しさん** · 2022/03/04(金) 21:08:30.47

サーバのバックエンドでwebsocketやるのに一番いいのはGoだよね？

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

そんなのなんでもいいのでは？

**デフォルトの名無しさん** · 2022/03/04(金) 21:24:03.32

>>528
あ、Prologが話題に出たのでFlixを勧めておきます。 https://flix.dev/

**デフォルトの名無しさん** · 2022/03/04(金) 21:28:27.24

>>529
JavaScriptからRustまで何でもサポートしてるから好きな言語を使えばいい
速さや省メモリを求めるならRust

**デフォルトの名無しさん** · 2022/03/04(金) 21:35:37.03

最速を求めるならアセンブラで書けｗ

**デフォルトの名無しさん** · 2022/03/04(金) 21:37:10.95

"Flix is inspired by OCaml and Haskell with ideas from Rust and Scala."ってどこにもprologさんいないんだがｗ

**デフォルトの名無しさん** · 2022/03/04(金) 21:40:05.97

>>533
それはコンパイラを舐めすぎ

**デフォルトの名無しさん** · 2022/03/04(金) 21:40:43.17

>>534
"First-class Datalog Constraints"!

**デフォルトの名無しさん** · 2022/03/04(金) 21:45:34.71

>>535
お前本当にアセンブラで書いたことないだろｗ
手でプロセッサやキャッシュを最適にするように書くと、最速ロジックの-O3からさらに数倍速くなるよｗ

>>536
論理型なら今はPrologでいいと思う

**デフォルトの名無しさん** · 2022/03/04(金) 21:53:49.99

今時プロセッサ決め打ちとかあるもんなの？

**デフォルトの名無しさん** · 2022/03/04(金) 21:57:30.37

アセンブラにするならその辺ある程度は諦めてたな
要件次第だけどｗ

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

>>528
if文をどの節で処理するかで表現するとか
ループを再帰で書くとか癖が強いからなあ
再帰を理解してくれない人も多いし

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

日本はPrologまだ使われてる国とかwikipediaか何かに書いてあったよｗ
世界でどういう状況かは推して知るべしｗ

**デフォルトの名無しさん** · 2022/03/04(金) 23:28:26.59

C11こそ真の次世代言語だ

トーバルズ氏、Linuxカーネルを「C89」から「C11」コードに移行する準備
https://japan.zdnet.com/article/35184296/

**デフォルトの名無しさん** · 2022/03/04(金) 23:37:07.33

>>542
理由が興味深いね
ブロック内スコープ変数宣言をの有用性に気付いたみたい

> Linus Torvalds氏はLinuxカーネルメーリングリスト（LKML）に
> 「この種の非投機的なバグが発生する理由は、C99スタイルの
> 『ループ内での変数宣言』という選択肢をわれわれが今まで持ち合わせてこなかったためにほかならない。
> つまり、list_for_each_entry()といったものすべては基本的に常に、最後のHEADエントリーをループ外にリークさせる。
> というのも、ループ本体内でイテレーター変数を宣言できないためだ」と記している。

**デフォルトの名無しさん** · 2022/03/05(土) 00:50:53.23

>>543
なにがそんなに有効なのかわからんわ
どこでも変数宣言できたら、どこで宣言されてるかわかりづらいだろ
変数宣言は一番最初って決まってたほうがよくね？

**デフォルトの名無しさん** · 2022/03/05(土) 00:56:06.36

>>544
イテレーター変数（ループ内だけで使う変数）をわざわざ関数の一番上で宣言するのは
すごく古臭いスタイルって気がする

**デフォルトの名無しさん** · 2022/03/05(土) 01:08:06.36

CPUの投機実行関係のバグに関するやつだから結構めんどい話だな

**デフォルトの名無しさん** · 2022/03/05(土) 01:31:43.43

>>542
いつまでC使うの？

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

Cに回帰しようよ

**デフォルトの名無しさん** · 2022/03/05(土) 08:41:45.95

>>547
おすすめの言語は何？

**デフォルトの名無しさん** · 2022/03/05(土) 09:49:50.73

大変興味深いよな
世の中の色々大事なソフトウェアってやっぱCで書かれてんのよね
Linuxの恩恵はC89の恩恵
他のどんな言語でこれがなし得るというのよ
そう考えると世の中ゴミ言語ばっかだな

**デフォルトの名無しさん** · 2022/03/05(土) 10:54:16.91

その理論ならCOBOLもいい言語だな

**デフォルトの名無しさん** · 2022/03/05(土) 10:59:24.96

>>550
まるで大事なソフトはLinuxカーネルしかないみたいな言いぶりだな。
こうやって捏造されてくのか。