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

**デフォルトの名無しさん** · 2022/08/05(金) 08:26:38.87

スレタイ以外の言語もok

前スレ
https://mevius.5ch.net/test/read.cgi/tech/1655771266/

**デフォルトの名無しさん** · 2022/08/21(日) 23:38:38.83

>>743
使い勝手の問題に矮小化すんなよ
根本的に使えないじゃん

**デフォルトの名無しさん** · 2022/08/21(日) 23:43:44.98

>>742
確かに5行目に関係ないprintln!入れるだけでもエラーになる
何で？？

**デフォルトの名無しさん** · 2022/08/21(日) 23:46:14.60

>>751
関数型言語らしい観点からの拡張だね
Haskell側でもRustのborrow checkerについて言及してる点も興味深い
でもそのHaskellの拡張で今回のfinalize未呼び出し検知を静的に実現できるの？

**デフォルトの名無しさん** · 2022/08/21(日) 23:54:38.26

そもそものアプローチが間違ってるから
他の言語でどうこう言っても意味がない

**デフォルトの名無しさん** · 2022/08/21(日) 23:59:27.31

>>753
そこで関数呼び出しなどがあると
panicなどで巻き戻される時にfooを解放する必要があるためdropを必要とするからかな
コンパイラが直接サポートすればそこは区別できるしリンク方式を取らなくてもよいから大丈夫じゃないかな

**デフォルトの名無しさん** · 2022/08/22(月) 00:06:59.32

でもコンパイラはお前のこと嫌いって言ってたしサポートしないんじゃない？

**デフォルトの名無しさん** · 2022/08/22(月) 00:20:24.88

そもそものアプローチというか
エラーが起きない時か気にしなくてよい時　→　デストラクタによる自動処理任せでOK
エラーやその有無を必ず欲しい時　→　flushやcloseなど自分で呼べばエラー取得できる

とはいえそれさえ書くのを忘れた時に
Rustコンパイラがコンパイルエラーとする機能も持てそうだとわかったから
さらなる機能向上に期待

GC言語はデストラクタによる自動処理すらないからそれ以前の問題だし
後始末の処理や指示を忘れてもエラーとならないし
忘れてクローズされていないファイルディスクリプタが多数溜まっていくこともよくあるｗ

**デフォルトの名無しさん** · 2022/08/22(月) 01:49:28.39

>>758
>Rustコンパイラがコンパイルエラーとする機能も持てそうだとわかったから
持てそうじゃないって
Drop Obligationとは全く異なるフロー解析が必要になるからゼロから作る新機能だよ

**デフォルトの名無しさん** · 2022/08/22(月) 07:51:24.23

>>756
その仮説で正しそうだが念のため確認してみた

まず>>741の通りだとdrop()を呼び出さずに当然コンパイルが通るので
何でもいいから関数呼び出し(演算含む)するものを間に挟んでみた
　let foo = Foo::new("Hello, World!");
　println!("test"); // ←ここに挿入
　foo.finalize()?;
するとこの形はdrop()を呼び出ように変化するようでリンクエラーとなる
この関数呼び出しはfooの参照を使うか否かに関係なく同じ結果

ところがfoo生成前に置くとコンパイルが通る
　println!("test");
　let foo = Foo::new("Hello, World!");
　foo.finalize()?;

さらにfoo消滅後に置いてもコンパイルが通る
　let foo = Foo::new("Hello, World!");
　foo.finalize()?;
　println!("test");

したがってfooが有効な期間に何か関数呼び出しがそこで起きる時のみ
drop()が呼ばれるコードが用意されてリンクエラーとなっている
これはRustがpanic時もメモリ解放をきちんと扱う話とも合致する
つまりpanic時の巻き戻し時のfoo解放をコンパイラが用意している仮説で正しいようだ

**デフォルトの名無しさん** · 2022/08/22(月) 08:10:55.66

>>759
そのような別のフロー解析は不要

Rustコンパイラは常に正しくメモリ解放を行うために所有権が尽きてdropを呼び出すべきところを全て把握している
それとは区別する形で>>760のようにpanic時の巻き戻し時のdrop呼び出しも正解に把握している
したがって以下のように検出できる

・finalize()をどのパスでも常に忘れずに呼び出しているコード
　　→　非panic時のdropは必ずfinalize()内のみで起こる

・finalize()を呼び忘れているパスが存在するコード
　　→　非panic時のdropがfinalize()以外で起こる　→検出

よってRustコンパイラは新たな仕組みを必要とせずに
現在把握している情報のみでfinalize()呼び忘れを検出可能
容易に対応できることが確認された

**デフォルトの名無しさん** · 2022/08/22(月) 10:01:20.83

つまり現状はできないってことw

**デフォルトの名無しさん** · 2022/08/22(月) 17:26:44.21

>>760
これってつまりリソース確保してから通常想定されるdropの位置までの間にある
すべての関数呼び出しの panic の可能性を考慮しないといけないから実用不可って事にならんか。

まだ try ... finally ... の方が実用的やないか。

**デフォルトの名無しさん** · 2022/08/22(月) 19:22:34.50

正解

**デフォルトの名無しさん** · 2022/08/22(月) 20:08:33.05

>>763
大きな誤解をしているようだが
C++やRustなどは関数(正解にはブロックスコープ)を抜ける時に常にデストラクタ(dropなど)を呼んでいる
これが即座のメモリ解放でありC++やRustが高速に動作するな理由
ただしC++でもRustでも所有権が移動したときにはそのデストラクタを呼ばず移動先に委ねられる

以上の基本事項の上でC++の例外やRustのpanicなどが起きたときには
関数呼び出しを自動的に多段に巻き戻して各々のメモリ解放つまりデストラクタ呼び出しをする
これは所有権が移動する場合でも移動する前に例外やpanicが起きればデストラクタが呼び出される
それが>>760のfooの生成と移動の間に挟まれたときのみデストラクタ(drop)が呼び出される仕組み

これらは全てコンパイル時点で静的に簡単に確定するため複雑さはなく実行時の余分なコストも発生しない
ここまでの話は現状のC++/Rustコンパイラがやっている普通のことである

>>761のfinalize記述忘れをコンパイルエラーとする新機能の話は
上述した現状の仕組みをそのまま活用できるため
その新機能を付加することがたやすいというだけの話だろう

**デフォルトの名無しさん** · 2022/08/22(月) 21:09:18.36

複製おじさんがまーた嘘ついてる

Rustが所有権(=dropする義務)をどう管理してるか知りたければ
“Drop Obligations”でググるといいよ

**デフォルトの名無しさん** · 2022/08/22(月) 21:19:17.98

>>763
try ... finally ... を書かなきゃいけない時点で大きく負けてるやん
RAII言語は何も書かずともデストラクタで自動処理される
そのデストラクタでエラーが発生する可能性がある時にfinalize呼び出しを強制させる選択肢も用意する話が今のテーマ

**デフォルトの名無しさん** · 2022/08/22(月) 21:21:32.89

>>765
それってコンパイラがどのAPIがfinalizeが必要か必要ないか全て把握してないといけないよね。
OS毎に低レベルAPIなんて異なるし組込み向けだってあるだろうし、無理じゃね？

**デフォルトの名無しさん** · 2022/08/22(月) 21:33:37.66

>>766
Drop obligationsはその話と関係ないじゃない？
RustコンパイラDevelopment Guideを見ても "Drop obligations" は変数の構造つまりenumやstructの中身とそのフィールド連鎖などについての話

**デフォルトの名無しさん** · 2022/08/22(月) 21:47:48.22

>>765
いや、その付加した機能が実用にならないねという話をしたんだが。

**デフォルトの名無しさん** · 2022/08/22(月) 21:49:45.94

>>768
みんなが一貫してずっと型の話をしているのに唐突にAPIとか場違いの話を出すのはヤバいな
finalize呼び出しを義務付ける型は>>713の方式ならばFinalize trait実装型と書かれている
あるいは>>743のManuallyDropのようにラッピング方式での指定の可能性もありうる
いずれも明白に宣言を伴うためコンパイラにとってもプログラマーにとっても明瞭に区別できる

**デフォルトの名無しさん** · 2022/08/22(月) 21:56:10.02

>>770
実用的じゃないとはどういう意味だ？
現行でも実用的になっているコード（明示的に書けばエラーを捕捉できて、書き忘れてもデストラクタで自動実行される）に対して
書き忘れを防止できる選択機能を新たに用意しよう、という話だろ

**デフォルトの名無しさん** · 2022/08/22(月) 21:57:46.65

>>769
関係ないわけないやん複オジw

**デフォルトの名無しさん** · 2022/08/22(月) 22:01:34.61

>>773
複オジって何

**デフォルトの名無しさん** · 2022/08/22(月) 22:32:14.28

finalize強制の話は7年前から線形型として提案はされてる
具体的なユースケースとしてFinalizeトレイトなんかも出てるし

https://github.com/rust-lang/rfcs/issues/814

ただまぁ大改造だし他にやることもたくさんあるから当分検討されることはないだろうな

**デフォルトの名無しさん** · 2022/08/22(月) 23:20:29.01

zenは急げ

**デフォルトの名無しさん** · 2022/08/22(月) 23:32:48.78

>>772
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=f27f2dc5668cded5f61f8f23e030df61

本当はこういうことがやりたかったんだろ？
newとfinalizeの間に一切コードが書けないんじゃ使い道が皆無

もともと「スコープ終端でのdropまでに特定の関数を呼び出していない場合コンパイルエラー」にしたいだけだったのが
「newした直後に特定の関数を呼び出していない場合コンパイルエラー」という厳しすぎる条件になってるのが問題

**デフォルトの名無しさん** · 2022/08/22(月) 23:35:51.97

>>775
そこに書いてる実現方法でも現実的だけどそれでも相当大変そうだね
各種API変更まで考慮すると費用対効果的に無さそう

**デフォルトの名無しさん** · 2022/08/22(月) 23:43:22.53

>>777
間に別の処理を入れてもエラーが起きないようにしたコードかと思って試しちゃったじゃないかw

**デフォルトの名無しさん** · 2022/08/22(月) 23:47:06.94

費用の問題というのも間違い
安くすれば需要がどんどん増えると思ったら大間違いだよ

**デフォルトの名無しさん** · 2022/08/23(火) 00:19:09.94

>>777
> newとfinalizeの間に一切コードが書けないんじゃ使い道が皆無

なぜそんな自虐的な設定を勝手に設けているの？
この話の発端は>>686だと思うけどそんな制限ないし
ここ最近に出ているコンパイラ拡張提案でもそんな制限した案はないよ

**デフォルトの名無しさん** · 2022/08/23(火) 00:38:06.00

そういえばHaskellのLinearTypesのやつ自分で試してから貼ろうと思ってたけど
実際hCloseを消したり2回呼んだりして出てきたエラーメッセージで検索したら
同じことやってた記事があったんでもうこれ貼ればいいやってなった

https://scrapbox.io/mrsekut-p/%E7%B7%9A%E5%BD%A2%E5%9E%8B%E3%81%A7%E3%83%AA%E3%82%BD%E3%83%BC%E3%82%B9%E7%AE%A1%E7%90%86%E3%82%92%E3%81%99%E3%82%8B%E4%BE%8B

**デフォルトの名無しさん** · 2022/08/23(火) 00:51:58.53

>>781
>>741に聞けば？

**デフォルトの名無しさん** · 2022/08/23(火) 01:09:26.07

>>783
それは未対応の現在のコンパイラでの話だよね
そんなことも区別つかないの？

**デフォルトの名無しさん** · 2022/08/23(火) 01:19:05.91

>>784
うん区別付いてない
その「対応」は具体的に何を指して言ってる？
>>775の線形型のpre-RFCのこと？

**デフォルトの名無しさん** · 2022/08/23(火) 01:31:34.47

>>783
ヒント: 781 == 741

**デフォルトの名無しさん** · 2022/08/23(火) 02:13:39.19

現状ではどの言語でも実現できていない話と、
新たに新機能追加／拡張を考えようという話の、
区別がついていないというよりも、
現状では出来ていないと叩いたり制限があると叩いたり、
ものごとの理解ができないキチガイか文句をつけて叩ければいいアンチのどちらか

**デフォルトの名無しさん** · 2022/08/23(火) 02:47:14.79

SFCエミュを2ヶ月くらいで組んでるから
Rustの生産性が低いって事はなさそうね
https://zenn.dev/tanakh/articles/nes-and-snes-emulator-in-rust

**デフォルトの名無しさん** · 2022/08/23(火) 02:49:40.76

いや1ヶ月か

**デフォルトの名無しさん** · 2022/08/23(火) 07:50:29.67

やっと出てきたのがファミコンのエミュかあ

**デフォルトの名無しさん** · 2022/08/23(火) 08:28:00.41

つまり複オジは反省しない嘘つき常習犯

**デフォルトの名無しさん** · 2022/08/23(火) 11:42:15.69

>>782
さすがHaskellさん

**デフォルトの名無しさん** · 2022/08/23(火) 12:20:50.32

この人何回もゲーム機エミュ書いてるからこの人の事例で言語の生産性は測れないよ。

絵師()みたいな人がよく言う
「これまでの人生+10分なんです」
と同じ。

**デフォルトの名無しさん** · 2022/08/23(火) 12:30:30.94

>>793
何回も書いてるなら
他の言語で書いた時と比較すれば多少は参考になりそうだけど

**デフォルトの名無しさん** · 2022/08/23(火) 12:39:54.59

>>794
書くたびに習熟度が上がるからダメ
記憶をリセットしないと

**デフォルトの名無しさん** · 2022/08/23(火) 12:40:44.01

Rustの生産性が高い原因はプログラミングの書きやすさとコンパイル時点で確定保証されることの多さ

**デフォルトの名無しさん** · 2022/08/23(火) 12:43:43.35

ISUCONでGoに匹敵するぐらい入賞チーム増えてきたらどんな用途でも生産性が高いと証明されるな

**デフォルトの名無しさん** · 2022/08/23(火) 12:57:16.80

>>797
限られた時間内で場当たり的な対応をどれだけこなすかを競うISUCONは現実と離れすぎていてあまり意味がない
もちろん欠陥だらけのシステムの数々の問題点を見抜いて各々に対応する能力は非常に重要
現実にはその能力は安全かつ高速なシステム設計開発に使うものであり短時間での場当たり的な対応に競うものではない

**デフォルトの名無しさん** · 2022/08/23(火) 13:33:30.00

時間は正しく計測できるという仮定の下で
「時間が短過ぎる」等の判断をすることもまた現実から乖離していることがよくある

数年前の過去問と同じ問題がテストに出れば、時間は数年間あってもそれを計測する時計はない

**デフォルトの名無しさん** · 2022/08/23(火) 13:45:48.88

知識を問うテストじゃないはずなのに、ある特定の知識を知ってる人だけがサクッと解けるようなテストだったら、それは問題が悪問なだけ
出題者が悪い

**デフォルトの名無しさん** · 2022/08/23(火) 13:55:00.75

良問を出すべきというのは道徳か？
富裕層は貧困層に寄付するべきと言ってるのと同じ？

**デフォルトの名無しさん** · 2022/08/23(火) 14:07:44.30

ISUCONでRustチームがいっぱい参加して優勝まで取ってたら真逆のこと言いそう

**デフォルトの名無しさん** · 2022/08/23(火) 14:30:22.22

性格や適性の問題じゃないかな
ボトルネックの調査と解消を正しく真面目にやれるタイプのエンジニアにとっては、
言語なんかシステムにおける無数のファクターの一つとして相対的に評価されるものでしかないのだろう
Rust信者だったら自分好みにリファクタリングを始めて時間切れになりそうだ
もちろん後者のタイプの人間のほうが適しているタスクもあるだろうけどね

**デフォルトの名無しさん** · 2022/08/23(火) 14:39:05.74

ISUCONのステマかなんかなの？
参加人数少なくて困ってんのかな

賞金を最低でも1000万以上にしたり
グローバル展開してあらゆる国の開発者を集めたほうがいいんじゃないの？
今は実質日本人学生用のコンテストになってるから

**デフォルトの名無しさん** · 2022/08/23(火) 14:46:37.67

俺もまずはリファクタリングから手を付ける
見やすさ追加改変のしやすさ品質に速さなどあらゆることでリファクタリングが基礎になる
あとシステムアーキテクチャに問題があるときは場当たり的な対応より根本設計からやり直した方が長期的に得と分かっている

**デフォルトの名無しさん** · 2022/08/23(火) 14:58:48.56

どこも小学生の自由研究のノリだよなｗ

**デフォルトの名無しさん** · 2022/08/23(火) 15:34:20.38

ディズニーを超えたいと思えばまあ小学生っぽくなるわな

**デフォルトの名無しさん** · 2022/08/23(火) 17:09:38.21

youtubeの中学受験の図形関係の問題みたいなもんでパターンを覚えるみたいな感じで
競技プログラムって何かつまらないんだよねぇ

**デフォルトの名無しさん** · 2022/08/23(火) 18:30:00.47

>>808
クイズやパズルと一緒
ワンパターンだから飽きるのは仕方がない

**デフォルトの名無しさん** · 2022/08/23(火) 20:26:06.49

ギャンブルならつまらないリスクから逃げるのは常識
だがリスクがない場合、つまらないという理由だけで逃げるのは逆に難度高い

**デフォルトの名無しさん** · 2022/08/24(水) 09:30:33.86

据膳でも感染リスクあるし

**デフォルトの名無しさん** · 2022/08/24(水) 09:31:10.38

>>808
めっちゃ判りますω

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

根源にある感情は「だからなに？」ってことなんだよ
できてもできなくても大差ないということ

**デフォルトの名無しさん** · 2022/08/24(水) 11:01:24.29

ManuallyDrop<T>を知る事と
それを知ってたら何になるかを知る事を区別しないと混乱が起きる

**デフォルトの名無しさん** · 2022/08/24(水) 13:47:39.28

>>808
結局そのアルゴリズムを反復練習で書けるかみたいになっちゃうんだよな

**デフォルトの名無しさん** · 2022/08/24(水) 15:20:22.21

>>804
参加者はめちゃくちゃ多いよ
ぶっちゃけ業務としてやってる会社が多いけど
俺が参加してた初期の頃はみんな趣味だったんだよね

**デフォルトの名無しさん** · 2022/08/24(水) 15:32:52.45

>>816
年1回の1500人程度の参加でめちゃくちゃ多いというの？？
比べる対象じゃないのかもしれんが競プロは毎週万単位での参加者がいるぞ

**デフォルトの名無しさん** · 2022/08/24(水) 15:49:29.31

だから？
どうした？

**デフォルトの名無しさん** · 2022/08/24(水) 16:22:02.33

>>818
辛辣w

**デフォルトの名無しさん** · 2022/08/24(水) 17:08:00.62

実務に役立たない競プロよりは
まだISUCONのほうがマシ
なぜならISUCONはサーバーなど含めたシステム全体のアルゴリズム相当も含むため
しかしそれを限られた時間内にその場しのぎの対応を多数こなす競技ISUCONも実務とかけ離れすぎていて単なるゲーム
ちなみに競プロの人口の方が多いのはISUCONの方がより現実に近くて桁違いの知識を必要とするため

**デフォルトの名無しさん** · 2022/08/24(水) 18:35:33.50

参加者めちゃくちゃ少ないけどなw
しかも半数以上は新人研修や社内勉強会での参加者で本気で決勝目指してるような奴等ではない

**デフォルトの名無しさん** · 2022/08/24(水) 21:44:22.89

ISUCONなんてもともと「いい感じにスピードアップコンテスト」みたいな雑な名前で、
そういうのが好きな運用者のガチ余興から始まったもんだろ。
ベンチマーカーの特性読んで穴見つけて異常点数取ったやつを「スゲェw」みたいに言うお祭り。

なんか箔をつけたい学生さんに目を付けられてからなんかへんな感じになってるけど。

**デフォルトの名無しさん** · 2022/08/25(木) 02:43:34.63

>>822
最近はそういうの無くなってるよ
そもそもお題のサンプル実装の時点ですげーよくできたものが出来上がってくる
仕事としてやってる会社も増えたからそうなるんだろう
昔はめちゃくちゃやっつけで雑だったから
やりようがいくらでもあったのにさ

**デフォルトの名無しさん** · 2022/08/25(木) 10:35:08.58

ISUCONを仕事としてやる会社って何なんだよ

**デフォルトの名無しさん** · 2022/08/25(木) 11:17:57.47

Rustより難しい疑問だが
その辺にある石ころのように誰にも気付かれない悪問

**デフォルトの名無しさん** · 2022/08/25(木) 11:44:01.01

運動会を業務時間にやる会社もある

**デフォルトの名無しさん** · 2022/08/25(木) 11:49:35.28

夏休みの自由研究
運動会
学芸会
発表会

楽しそっすね～ｗ

**デフォルトの名無しさん** · 2022/08/25(木) 12:32:16.39

研修とかトレーニングとしてってことだろ？

もしかして会社の箔を付けるためなのか？
うちはISUCON決勝進出したんですw的な

**デフォルトの名無しさん** · 2022/08/25(木) 12:33:42.97

業務時間扱いで技術大会の運営準備とか練習させてくれるの、わりとどんな業界でも普通だと思うが…。

従業員を工数としか扱わない会社に所属してるなら御愁傷様。

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

>>828
そういう面は大きいよ
特に採用面ではかなり優位だろう
まともなエンジニアがあることがわかってるし

**デフォルトの名無しさん** · 2022/08/25(木) 14:32:09.78

そろそろ学びやすく美しい言語が完成してもいい頃

**デフォルトの名無しさん** · 2022/08/25(木) 15:34:35.21

Pascalだな

**デフォルトの名無しさん** · 2022/08/25(木) 15:39:13.49

RustとLispであらゆる用途をカバーすべき

**デフォルトの名無しさん** · 2022/08/25(木) 15:47:59.73

Lispはカッコばかりつけてるナルシストだからダメです

**デフォルトの名無しさん** · 2022/08/25(木) 18:25:49.89

そもそもプログラミング言語って本当に必要なのか？

**デフォルトの名無しさん** · 2022/08/25(木) 18:38:47.49

>>829
「仕事としてISUCONに参加する会社」と
「ISUCON参加を業務時間扱いしてくれる会社」は全然違うやろ

前者は半ば強制の指示命令ありき
後者は任意の研鑽を会社が支援するもの
「仕事としてやってる会社」という表現は完全に前者を念頭にしてるよね

まぁぶっちゃけどうでもいいけど

**デフォルトの名無しさん** · 2022/08/25(木) 19:19:03.77

>>835
言語がなきゃどうやってプログラミングするんだよ

**デフォルトの名無しさん** · 2022/08/26(金) 03:56:04.98

>>836
いや、後者を念頭にしても不自然ではないよ

**デフォルトの名無しさん** · 2022/08/26(金) 09:47:57.02

>>835
全てをアセンブラで書くのは無理だぞ

**デフォルトの名無しさん** · 2022/08/26(金) 10:03:42.99

>>822
>ISUCON=いい感じにスピードアップコンテスト
>ベンチマーカーの特性読んで穴見つけて異常点数取ったやつを「スゲェw」みたいに言うお祭り

へー勉強になったω
まじありがとう

**デフォルトの名無しさん** · 2022/08/26(金) 10:05:33.66

>>839
アセンブラも機械語という言語で方言もある

**デフォルトの名無しさん** · 2022/08/26(金) 10:40:28.46

>>841
アセンブラはセーフだと思ってたwww
まさかELFをバイナリエディタで手打ちしない限りは言語を使ってないことにならないのか.....

**デフォルトの名無しさん** · 2022/08/26(金) 11:09:48.80

>>842
それは機械語という言語だな

**デフォルトの名無しさん** · 2022/08/26(金) 11:11:30.63

>>843
何もできなくて草

**デフォルトの名無しさん** · 2022/08/26(金) 11:12:24.53

>>841
アセンブリ言語と機械語は違うよ
アセンブリ言語は機械語に厳密に変換できるがループや条件分岐などをマクロ定義できる
ニーモニックは機械語と言っていい

**デフォルトの名無しさん** · 2022/08/26(金) 11:14:37.08

>>844
何を言ってるんだ
フローチャートを書いてそれを頭の中で直接バイナリに変換して打ち込むくらい昔は珍しくなかったぞ

**デフォルトの名無しさん** · 2022/08/26(金) 12:29:43.43

一度でいいからパンチカードでFizzBuzzみたいな簡単なプログラムを作って動かしてみたいな

**デフォルトの名無しさん** · 2022/08/26(金) 13:56:53.79

>>837
言語じゃなくて"プログラミング言語"ね
コメントからコード生成する技術も出てきているし、将来的にはプログラミング専用言語が必要な場面がより少なくなるのではと思った
画像生成AIに食わせる文章に工夫が必要なように、コード生成AI向けに自然言語をうまく書くような工夫が必要で、それがプログラミング言語と呼ばれるのかもしれないけど

**デフォルトの名無しさん** · 2022/08/26(金) 14:02:54.19

>>835
仮に不要だとしてもどうせ
清濁併せ呑むべきという話になって必要な物と不要な物が混ざり合う

**デフォルトの名無しさん** · 2022/08/26(金) 14:03:10.59

>>848
さすがにそれは無理
プログラミングしたことないやつにはわからんだろうけど

**デフォルトの名無しさん** · 2022/08/26(金) 14:57:53.05

>>850
無理というのは、特定用途でプログラミング言語を代替するものすら現れることはないということ？
なんでそう言い切れるのかが分からない