次世代言語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/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
無理というのは、特定用途でプログラミング言語を代替するものすら現れることはないということ？
なんでそう言い切れるのかが分からない

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

>>851
プログラミング言語が必要かどうかの話をしてる時に特定場面でプログラミングを代替できるものが生まれるかどうかの話にすり替えてたのか

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

>>852
最初の投稿が言葉足らずというか大げさな表現だったね。申し訳ない

どんなケースでもプログラミング言語が必要ということはなくて、新たな何かで置き換えられる領域はある
その新たな何かこそが次世代言語なんじゃないか、という話をしたかった

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

ローコ－ドやらノーコードやらは定期的にブームになるけど
結局は定着しないんだよね

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

そんなん昔は全部ユーザーが自分でプログラムしてやってたのが今では完成済みが売られてるんだから今さらだろ

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

コードより正確に情報残す方法なんてほぼないわ。

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

4GLとかあったなあ
使ったことないけど

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

ノーコード/ローコードはもっとUIだけにフォーカスしたツールが欲しいわ
マウスポチポチでWebUI作ったらAPIにデータ投げてくれるだけでいいのに、今時のSaaSはだいたい余計な中途半端なDB機能がついてきやがる
まあ一気通貫で提供しないとユーザー企業に直接売れずSIerに主導権握られることになるから、SaaSビジネスとしては面白くないんだろうな

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

PCのUIはスマホ大勝利により失脚してるし
UIにも言語と同様の権力闘争があるのは自明の理

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

>>847
っ https://www.masswerk.at/keypunch/
http://www.kloth.net/services/cardpunch.php
https://www.youtube.com/watch?v=vBSVIJsSux4

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

>>853
そんなもの既にある

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

>>861
じゃあこれ以上の発展は見込めないわけ？

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

現代だとどの言語も言語仕様の更新をしているわけだし新しい言語じゃなくても言語の新しいバージョンを使うってのでもいい気もするけどね

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

言語の仕組みなんてLISP、Java、Haskellらへんでほぼ出揃ってて、目新しいものなんてほとんどない
使いやすくこうしてみましたー、とか、いいとこ取りしてみましたー、みたいなのばっり

**デフォルトの名無しさん** · 2022/08/27(土) 00:11:23.77

新しいものなんて何もないといいつつ、新たなものを求めて次世代言語スレへやってきてしまう人々
若い頃に出会ったものは相対的にキラキラして見えるだけで、そんな出会いは二度とないので諦めましょう

**デフォルトの名無しさん** · 2022/08/27(土) 00:58:29.99

今の時代はコアの理論や機能だけじゃ広まらない。
ライブラリやビルド・パッケージ等のエコシステムも揃ってさらにはGAMAあたりのサポートもないと中々広まらない時代になってる気がする。

**デフォルトの名無しさん** · 2022/08/27(土) 04:05:38.65

>>864
21世紀になってからも唯一Rustが画期的な言語として登場したくらいかな

差異は所有権の借用とライフタイムという概念の導入だけだがその効果が革命的で
GCなくても常に安全な即時の自動メモリ解放とC言語並の速度の両立を実現したことに加えて
データ競合(シングルスレッド時のmutual aliasingを含む)が全く無いことも実現

高速と安全という従来相容れない二者を静的にコンパイル時点で保証したインパクトは大きく
世界のIT大手たちが揃って共同でRust Foundation設立するまでに到った

**デフォルトの名無しさん** · 2022/08/27(土) 08:35:20.66

>>864 程度で新しい仕組みと言えちゃうなら実行中に一時停止しないことに命かけてるponyの方が余程新しい仕組みになっちゃう
標準入力をそのまま返すだけで新しいクラスを作成させられるからな

**デフォルトの名無しさん** · 2022/08/27(土) 09:26:47.49

>>865
>新たなものを求めて次世代言語スレへやってきてしまう人々

新たなものを求めてるんじゃなく
自分がマウント取れるネタを探しにやってきてるだけ
隔離スレと呼ばれる所以

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

心理学や行動経済学は新たなものを作らない
マウントに限定しなくても心理学全体がそういうものだ

**デフォルトの名無しさん** · 2022/08/27(土) 11:51:54.64

>>867
rust-analyzerがバカスカメモリ食うのなんとかして

**デフォルトの名無しさん** · 2022/08/27(土) 12:19:45.38

所有権もC++のムーブが元なんだけどな
あれをデフォルトにしたらRustになったと言うだけ

**デフォルトの名無しさん** · 2022/08/27(土) 13:34:38.00

ITの新しいところは二つある
低級言語からボトムアップで作るところ
無意識にバグを作ってしまうところ

**デフォルトの名無しさん** · 2022/08/27(土) 14:02:19.73

所有権とlifetimeは元ネタがあったとはいえ、そこからshared xor mutableへと発展させたのは大きな発明だと思うよ

**デフォルトの名無しさん** · 2022/08/27(土) 14:25:45.41

>>874
shared xor mutableも元ネタあるよ
トランザクションを使った同時実行制御の常識
それを所有権やライフタイムの考えと融合させて実用可能なものを作ったところが新しい

**デフォルトの名無しさん** · 2022/08/27(土) 19:24:10.69

研究用プロトタイプとか言語の一部で適用可能にしたレベルで終わりそうなものを基盤にした処理系をいちから作り上げてメインストリームに持ってきたのはホントすごいと思うわ。

**デフォルトの名無しさん** · 2022/08/27(土) 19:57:46.81

組み込みとか低水準で使えるようなシステムプログラミング向けの言語って、候補と呼べるものすら新しい言語はなかなか登場してなかったと思うんだけどなんでだろな

C/C++の存在感がでかすぎて言語開発者の興味が失われてたんかね、GCを贅沢に使った言語はめちゃくちゃたくさん登場してるのに
今となってはRustが成功しつつあるけど、Rustが登場しなかったらずーっとC/C++の天下だったんかな、いやだな

**デフォルトの名無しさん** · 2022/08/27(土) 20:29:15.90

>>872
C++はライフタイムを言語(コンパイラ)が把握管理できないため
ダングリングの発生を検知してコンパイルエラーとできず
セキュリティ含む深刻なバグを未だに量産し続けていることに問題がある

**デフォルトの名無しさん** · 2022/08/27(土) 22:12:41.90

>>877
C++の時点で難易度がもう非常識なレベルになってるから
それ以上先に進むのは常識的にはできなかった

だが偶然その時にC++と関係ない人々の日常会話も非常識で過激になって行った
その結果、難解過ぎることの何が悪いのかと開き直るのを誰も止められなくなった

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

>>878
いやだからC++にムーブができたんでしょ
std::moveとムーブコンストラクタとムーブ代入演算子を勉強しな？

**デフォルトの名無しさん** · 2022/08/27(土) 23:22:25.52

>>880
それは所有権
Rustは借用とそのライフタイムを言語の制御下に置いたことで初めて安全なメモリ自動解放を実現した
C++がいかにダメな言語なのかをもう少し勉強したほうがいい

**デフォルトの名無しさん** · 2022/08/27(土) 23:38:25.67

安全なメモリ管理ってｗ
単に関数でnewしたものを保存してスコープが切れたら解放するだけでしょｗ
それC++でFile file;のように宣言したのと概ね同じなんじゃね？ｗ

**デフォルトの名無しさん** · 2022/08/27(土) 23:43:33.94

Rustはオワコンだからあんま使いたくないな

**デフォルトの名無しさん** · 2022/08/27(土) 23:45:55.57

>>882
まずC++がメモリ管理バグを生産し続けている仕組みを学習すべきだな
それまでこのスレに出入り禁止

**デフォルトの名無しさん** · 2022/08/28(日) 00:56:35.98

C++にはtemplate反対派もいるから
バッファ<T>の代わりにtemplateを使わないやつを再発明することで
オーバーランも再発し続ける

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

>>881
Rustの解説にもある通りRAIIがベースで、自動変数の応用例だけどな。

C++は元々cをコンパイルできるという大原則があって、その原則からスマートポインタ強制とかは行っていない。Rustはそのあたりのしがらみを捨てているんだからああなるだろ。
RustもC++の複雑さに加えてHaskellの難しさも取り込んでいるから、絶壁の学習曲線問題は悪化している。置き換えが進むのはc/c++の一部の領域のみで、Javaの領域とか食えないと思うわ。

**デフォルトの名無しさん** · 2022/08/28(日) 06:06:08.65

>>886
その件でRAIIや自動変数と言い出してる時点で把握不足
それは以下の非常に大雑把に分けた3段階のうちの最初の(1)の部分でしかない

(1) RAIIとデストラクタ
(2) 所有権とその移動
(3) 借用とライフタイム

>>882も(1)止まり
>>880は(2)止まり
(1)と(2)だけではダングリングポインタの発生を防げない

**デフォルトの名無しさん** · 2022/08/28(日) 07:28:26.48

>>886
Rustの難しさがC++の難しさを引き継いでいるのかは疑問に少し疑問だし、Haskellの難しさに至っては全く受け継いでないと思うぞ
型に対する要求は小さいし、関数が純粋であることも求めてないし、遅延評価をベースにしてもいない

**デフォルトの名無しさん** · 2022/08/28(日) 10:48:45.36

サブスクやリボ払いじゃないんだから
よく似た難しさに10回出くわしたら1回あたりのコストは1/10になるんだよ

まあそうなると「コスト」とは何かを定義するのが極めて困難になるんだけど

**デフォルトの名無しさん** · 2022/08/28(日) 12:11:47.01

RustやC++やHaskellの難しいポイントってそれぞれ具体的にどういうところを指してるの？
単に難しさと言われても人によってイメージするもの違うのでは

**デフォルトの名無しさん** · 2022/08/28(日) 12:52:57.69

Haskellの難しさは対象ドメインの一般的理解よりも一段二段高い抽象度を意識したプログラミングが必要なところ

**デフォルトの名無しさん** · 2022/08/28(日) 13:12:40.64

Lisp世代とErlang世代の間に暗黒時代がある
モナドと型推論のプロトタイプもその時代にある
検索しても多分辿り着けないのは検索エンジンが原因でしょ

**デフォルトの名無しさん** · 2022/08/28(日) 13:38:45.23

トレイトとライフタイムが難しい

**デフォルトの名無しさん** · 2022/08/28(日) 14:28:30.61

>>893
トレイトはシンプルで分かりやすいけど
クラスが非常に難しい

例えば複数の型に共通する機能性質とメソッド群を用意したいことはプログラミングでよく発生する場合
トレイトだと複数の型々に関係なく独立してそのまま用意して各型に実装するだけだけでいいけど

クラスだと継承でやるにはその型自身に継承しなきゃいけなくて多重継承になったり継承ピラミッドが複雑化
あるいは継承は破綻するからメソッドを増やす別の方法を拡張して使い何のためにクラスを使っているのか本末転倒になる
結局クラスと型が分離できていないことにも問題が多い

Rustでは型とトレイトという二つの直交した概念だけで全てが済むからシンプルで分かりやすい
クラスも継承もないのはRustだけでなくGoでもそうだけど今までクラスと継承で遠回りしてきたプログラミング言語の到達点かなと思う

**デフォルトの名無しさん** · 2022/08/28(日) 15:06:53.82

>>894
インターフェースも知らんのか？

**デフォルトの名無しさん** · 2022/08/28(日) 15:17:26.17

トレイトも型なのに何言ってんだこいつw

**デフォルトの名無しさん** · 2022/08/28(日) 15:26:53.46

>>895
Linusを怒らせたのはそういう所だな
C++を知っていても使わない自由があると言いながら
実際に使わない者が現れれば「知らんのか？」とミスリードしてくる

**デフォルトの名無しさん** · 2022/08/28(日) 15:34:27.90

>>897
C++にはインターフェースが無いことも知らんのか？
そりゃリーナスも怒るわw

**デフォルトの名無しさん** · 2022/08/28(日) 15:39:21.95

C++も素のままならまだいいのだが
やっぱり癌はSTLなどのライブラリや例外だな
内部で勝手に動的にメモリ確保したりとかするなよってｗ

**デフォルトの名無しさん** · 2022/08/28(日) 15:57:21.77

>>895
そのインターフェース等を批判してることを読み取れないのか？
クラスとインターフェースの2種類が必要となってしまっている
トレイトだけで済むRustがシンプルで分かりやすいことを認めたわけだな

**デフォルトの名無しさん** · 2022/08/28(日) 16:07:51.94

分かってなさそう

**デフォルトの名無しさん** · 2022/08/28(日) 16:15:35.13

>>896
トレイトは型ではない
例えばCopyトレイトやDisplayトレイトなどの既存のものから自作のものまで自由にトレイトを作れるが
それらトレイトはもちろん型ではなく機能や性質を示すだけである
ある型を作ったときにそれら任意のトレイトを実装するか否かは自由であり
あるトレイトを作ったときにどの型に対して実装するか否かも自由である

**デフォルトの名無しさん** · 2022/08/28(日) 16:21:02.87

スパゲティーは苦手だからCarbonに期待

**デフォルトの名無しさん** · 2022/08/28(日) 16:22:01.22

Rustでは型とトレイトという二つの直交した概念だけで全てが済むからシンプルで分かりやすい

クラスとインターフェースの2種類が必要となってしまっている

ほーん

**デフォルトの名無しさん** · 2022/08/28(日) 16:33:32.30

つまりクラスとか継承とかそんな複雑なものは要らないよな
型とインターフェースだけがあればいい
Goは実際にそうなっている

**デフォルトの名無しさん** · 2022/08/28(日) 16:33:43.64

>>893
ライフタイム以前よりはかなり簡単になったけどまだ引っかかりどころは残ってる感じ？

**デフォルトの名無しさん** · 2022/08/28(日) 16:44:44.59

>>900
Rustの公式リファレンスにもトレイトはインターフェースって書いてあるんですがww

**デフォルトの名無しさん** · 2022/08/28(日) 16:48:30.90

>>900
Rustはstructとimplとtraitの3種類が必要としまってますねwww

**デフォルトの名無しさん** · 2022/08/28(日) 16:52:01.49

>>907
そうだよ
インターフェース自体を問題にはしていない
クラスに加えて結局インターフェース等も必要としている状態を批判している
それならばGoやRustのように最初からクラスは無い方がシンプル

**デフォルトの名無しさん** · 2022/08/28(日) 17:01:29.35

C++20でconceptというのがあるんだな
これは知らんかったわ
C++も大変だねー

**デフォルトの名無しさん** · 2022/08/28(日) 17:27:57.92

rust は使ったことないがエラーメッセージが c++ より親切と聞いておる。

**デフォルトの名無しさん** · 2022/08/28(日) 17:42:22.67

ここに書き込んでるヤツのせいで本当にrustが嫌いになったわ

**デフォルトの名無しさん** · 2022/08/28(日) 17:47:23.10

>>912
他人の意見ばかり気にしてないで、自分で判断したらいいのに

**デフォルトの名無しさん** · 2022/08/28(日) 18:01:38.50

>>897
別にリーナス怒ってはないやろ
mallocで失敗したくらいで強制終了するしかないポンコツは流石に使えんわって言っただけで

**デフォルトの名無しさん** · 2022/08/28(日) 18:04:31.62

>>911
C++と言うより原理的にテンプレート絡みのエラーメッセージはわかりにくいわな
まあそこは言語組込のrustに軍配上げるしかない

**デフォルトの名無しさん** · 2022/08/28(日) 18:12:18.75

> クラスとインターフェースの2種類が必要となってしまっている

class に加えて interface があるのは救いなんだがｗ
実装ではなくてインタフェースに対してプログラミングせよ
ってのを実践するのに丁度いい潔い言語機能なんだが

**デフォルトの名無しさん** · 2022/08/28(日) 18:24:29.65

interfaceでできることは (多重継承禁止しなければ) classでもできる
この客観的事実を、鬼滅棒みたいに振り回す人
と仲良くなるところまでがC++の難易度です

**デフォルトの名無しさん** · 2022/08/28(日) 18:31:25.88

個人的にはC++でIFooとか涙ぐましいことやってんのも受け入れられるよ
問題は、言語ユーザが実装とインタフェースを分離したいという発想を持ってるかどうかだから

もちろんそうなったとき、よりスッキリすんのは言語として interface があるほうだよねって話

**デフォルトの名無しさん** · 2022/08/28(日) 18:34:20.72

そもそもC++はオブジェクト指向言語ではないのでインターフェースは必要ない。

**デフォルトの名無しさん** · 2022/08/28(日) 18:36:05.49

>>903
Rustを使えば避けられるよ

>>908
implは単なる接着剤だよ
Goのように接着剤なしで書く方式もあるように
接着剤であるimplはそこで言う種類じゃないよ

**デフォルトの名無しさん** · 2022/08/28(日) 18:39:21.55

そもそもRustは仕事がないのでimplは必要ない。

**デフォルトの名無しさん** · 2022/08/28(日) 18:40:17.57

>>918
うん
インタフェースは必要でむしろクラスが要らないよね
そのわかりやすい道を選んだのがGoとRust

**デフォルトの名無しさん** · 2022/08/28(日) 18:44:55.39

Rustは仕事がない。
Goは仕事がある。
この差は大きい。

**デフォルトの名無しさん** · 2022/08/28(日) 18:45:28.11

雇われ仕事はな

**デフォルトの名無しさん** · 2022/08/28(日) 18:46:02.45

>>913
自分の判断ではrustはスパゲッティだから

**デフォルトの名無しさん** · 2022/08/28(日) 18:47:05.71

ていうか、Rustって使ってる人少なすぎじゃね？

**デフォルトの名無しさん** · 2022/08/28(日) 18:48:13.72

メソッドが無いってんならともかく、クラスが無いと言っても明示的なクラス定義に比べてソースコードの物理的レイアウトの自由度が高いというくらいの話でしかないでしょ
そんなドヤ顔で語るほどのことでもない

**デフォルトの名無しさん** · 2022/08/28(日) 19:04:58.89

>>925
少なくとも他の言語と比べたらスパゲティになりにくいね

>>927
メソッド自体はクラスと関係なくてクラスベースのプログラミング言語でなくても存在するものだよ
クラスを特徴付けるものはクラスの親子関係を示す継承だね
GoとRustに継承はないからクラスとは明確に異なるよ

**デフォルトの名無しさん** · 2022/08/28(日) 19:06:04.35

クラスに継承は必須ではないよ
VBAのクラスに継承は無いぞ？

**デフォルトの名無しさん** · 2022/08/28(日) 19:06:48.27

Rust、Haskellは仕事がない。

**デフォルトの名無しさん** · 2022/08/28(日) 19:07:23.94

>>920
implは操作の定義
structはデータの定義

この2つを分けたことの意味が分からないようならRust辞めたほうがいいよ

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

始めても居ないだろ。

**デフォルトの名無しさん** · 2022/08/28(日) 19:16:42.43

Goのimplicitなインターフェース実装よりも
Rustのexplicitなトレイト実装のほうが断然いい

ただJavaと違ってC#やSwiftならExtensionで後からクラスにインターフェース実装追加できるからGoやRustの方式が特に優れてるわけでも無いと思うけどね

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

>>929
VBAは他にもできないことや制限されることが色々とあるから置いときましょ

>>931
違うよ
implは『実装』の定義だよ
structは(構造体の)『型』の定義だよ

**デフォルトの名無しさん** · 2022/08/28(日) 19:32:34.36

>>933
優れてるかどうかは誰も言っていなくて
元々の話はRustはトレイトがあるから複雑で難しいとかいう批判に対して始まった議論やろ
実際にはクラスとそれに纏わる諸々がないからGoもRustもクラスのある言語より簡単でわかりやすくなってる

**デフォルトの名無しさん** · 2022/08/28(日) 19:39:33.75

importしないと使えないメソッドがあるのが理解できない

**デフォルトの名無しさん** · 2022/08/28(日) 19:45:44.96

問題はクラスではなく副作用だよ
勘違いするなよ
クラスのメンバーが途中で書き換えられたりしなければ問題はないのよ

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

rustはstructのフィールドごとにmut設定できないので欠陥言語

**デフォルトの名無しさん** · 2022/08/28(日) 19:53:38.21

次スレのタイトルは

次世代言語28 Rust

にしとこうか？

**デフォルトの名無しさん** · 2022/08/28(日) 19:55:42.04

仕事がない言語に未来はない。

**デフォルトの名無しさん** · 2022/08/28(日) 20:11:14.04

仕事があっても未来がない言語の方が多い件

**デフォルトの名無しさん** · 2022/08/28(日) 20:17:59.03

RustはPHPより優れているんだ！！といくら主張しようとも。
Rustは仕事が無くてPHPは仕事があるんだから仕方がない。