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

**デフォルトの名無しさん** · 2022/09/17(土) 19:05:49.83

スレタイ以外の言語もok

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

**デフォルトの名無しさん** · 2022/10/01(土) 13:02:43.96

スクリプト言語とコンパイル言語を比較する場合はランタイムのオーバーヘッドに差がありすぎるのだから
そこで差が出るようなベンチは無意味
実際のアプリケーション相当の処理を想定しないと

**デフォルトの名無しさん** · 2022/10/01(土) 13:24:49.19

>>590
はあ？
1分やっても2分やっても全く同じだけど？
もしかして平均の意味すら知らないのかな？

**デフォルトの名無しさん** · 2022/10/01(土) 13:29:50.04

>>592
偉そうにいう前にまともなベンチしろ

**デフォルトの名無しさん** · 2022/10/01(土) 13:35:05.69

>>593
いやだから10秒だろうが1分だろうが5分だろうが変わらないって
偉そうなこと言ってるのはお前だろ

あらゆるノイズを排除してここまで差が出るんだから起動時のコストなんて関係ないだろ
適当なこと言ってマウント取ってんじゃねーよゴミ

**デフォルトの名無しさん** · 2022/10/01(土) 13:42:50.86

>>594
ゴミはお前
論点ずらしするな
ただのストローマンだぞ
俺の言ったことをまずやれ
そしてそれでも差があるなら反論しろ
それが正当なやり方だろ
お前は手を動かさずに自分の意見が正しいと言ってるだけ

もしかして数分実行しただけでキャッシュができると思ってる？
しかもそんなよくわからんサンプルで？
そもそもキャッシュができる条件など仕様にはない
できない可能性もある
そういうことを含めてのベンチなんだよ

**デフォルトの名無しさん** · 2022/10/01(土) 13:44:30.12

「俺の意見が間違ってる」ことをコードで証明しろ
ストローマンの口八百で語ってもなんの意味もない
それこそただのマウント野郎だろ

**デフォルトの名無しさん** · 2022/10/01(土) 13:50:13.47

いくらなんでもNode遅すぎで気になるね
レスポンスしてるヘッダの内容とかも比べてみなよ
HTTP/1.1が使われてるのか、cookieセットされてるかとか、keep-aliveはどうかとか

**デフォルトの名無しさん** · 2022/10/01(土) 13:50:43.33

俺の意見を無視するならここに書く意味はないし
はろーわーるどのベンチでnodeは遅いね、で終わる話
ここに書かずに1人で納得しとけ
ここに書く以上何か意見を求めてるんだろ？
その意見を言ってやってるのに無視する
正しい人間の態度とは思えんな
あまりの自分勝手さに怒りさえ覚える

**デフォルトの名無しさん** · 2022/10/01(土) 13:58:44.87

とりあえず家帰ったら動かしてみる
俺のローカル環境だが

**デフォルトの名無しさん** · 2022/10/01(土) 14:07:18.89

>>597
試したけどcurl -vで複数回投げた時にconnection left intactとRe-using出るからコネクション使いまわせてるね
HTTP1.1だからデフォルトでkeepaliveになってる
wrkはHTTP1.1対応

Nodeは日付とか色々ヘッダに入ってみたいだから公平な比較にはなってないけどそれにしても差があるすぎると感じるね

**デフォルトの名無しさん** · 2022/10/01(土) 14:27:28.59

>>584
Q：なぜ何でここまで差が出るのか？
A：この場合、rust (active-web) は、asyncなどでI/O待ちを切り替え起点とした非同期処理を行うが
goは1リクエストに対してgoroutineが1つ付く。細かく言うとRustはソケットI/Oへ受・送信が終わらないと
次のリクエストは処理待ちになる。
結果はReq/Secに出て高速で(効率的な)スイッチングを行えるgo (net/http)のほうが最終的に処理できる
リクエスト数は高いが、平均処理時間avgはRustのほうがほんの少し速くなる。

goでavgが遅くなるのは、処理中にI/Oを起点としない時分割で別リクエスト処理へ切り替えるために
切り替えコスト+処理コストの合計で1つのリクエストを完了する時間は長くなる

余談だが、wrkは５秒だと並列テストなどをするには短い。より厳密な計測ができるwrk2とかあるが
この場合は並列での負荷テストではないのでそんなに変わらない。ただ最初の1秒が参考にならない
上の例はあくまで1コアだが、多コア高負荷環境(1000同時スレッド・3万リクエスト・30秒ぐらい）だと
50%はgoのほうが速くなり、Req/SecはRustのほうが多くなる

node(express)は、express自体の重厚さJS/TS自体の重さがかなり効いていると思う

**デフォルトの名無しさん** · 2022/10/01(土) 14:50:55.94

ただWSLであってもLinuxのbacklog当たりのカーネルパラメータを弄れば結果は変わるかもしれない。
並列・高負荷ではなくても4000コネクションだと標準の状態だと足りない気がする

$ sudo sysctl -a 2>&1 | grep -E 'somaxconn|tcp_max_syn_backlog'
net.core.somaxconn = 128
net.ipv4.tcp_max_syn_backlog = 512

**デフォルトの名無しさん** · 2022/10/01(土) 14:57:42.06

WSLでやってんのか、WSLってパフォーマンス的にはなんか特徴あるのか？
このあと気が向いたらおれもちょっと気になるとこのベンチ比較してみる

**デフォルトの名無しさん** · 2022/10/01(土) 15:34:25.37

とりあえずNodeは遅いゴミってのが証明されてるな

**デフォルトの名無しさん** · 2022/10/01(土) 15:59:56.14

>>597
その木なんの木。

**デフォルトの名無しさん** · 2022/10/01(土) 17:07:51.42

もう１つ言うと高負荷で比べるならrust (active-web) なら、go側はSO_REUSEPORT/SO_REUSEADDRを
効くようにするか、fasthttp系(fiber)などを使用すべきで、net/httpを普通に使っただけだと極限の性能では
無いので注意が必要です、今回は高負荷でないので関係ありませんが

**デフォルトの名無しさん** · 2022/10/01(土) 19:35:39.80

利用者数が全然違うので、今はGo言語を使うほうが良いのでは？
もしもRustが使われるようになったなら、その時使えば良い。
今はまだHaskell候補の状態。
そのうちHaskellのように誰も見向きもしなくなるんだろうなあと。

**デフォルトの名無しさん** · 2022/10/01(土) 19:44:27.68

万能言語は作れない
用途別だ

**デフォルトの名無しさん** · 2022/10/01(土) 22:06:34.84

並行プログラミングなら、関数型のElixir

**デフォルトの名無しさん** · 2022/10/01(土) 22:14:09.37

型なしのゴミ

**デフォルトの名無しさん** · 2022/10/01(土) 22:57:03.33

型連呼している奴って逆に無能なのかと思うｗ

**デフォルトの名無しさん** · 2022/10/01(土) 23:39:41.67

殊更に型の重要性を連呼する人間は、本人が有能か無能かはともかく、自分含めて人間の技能と精度を信用していないというのは確かだと思うよ

**デフォルトの名無しさん** · 2022/10/02(日) 05:56:42.85

>>611
では質問するがなぜMicrosoftはJavascriptは不十分だと認識してTypescriptを開発したの？そして普及したの？
なぜPythonなどのスクリプト言語はしきりに型ヒント機能を追加してるの？

無能は型の重要性を理解できないお前、エンタープライズでは必須

**デフォルトの名無しさん** · 2022/10/02(日) 07:31:01.25

>>610
じゃあErlangなら文句ないな

**デフォルトの名無しさん** · 2022/10/02(日) 08:25:14.53

>>611
みんな無能だよ。

たまに型無しで完璧にやれるやつはいるけど、そういう奴は他の人と一緒に仕事しても自分の高い能力を盾にルールに従ってもらえないから面倒だわ。

一人でR&Dとか調査主体の部署でやってもらうのが無難。

**デフォルトの名無しさん** · 2022/10/02(日) 09:29:20.44

無能向けのルールに従っていたらせっかくの高い能力を発揮できないじゃん
妥当じゃないの

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

>>616
ところが >>611 みたいのは能力が高いわけで無いという。

**デフォルトの名無しさん** · 2022/10/02(日) 11:45:56.93

>>594
>あらゆるノイズを排除してここまで差が出る
全然ノイズ排除できてないじゃんww
意味のないベンチだよ

**デフォルトの名無しさん** · 2022/10/02(日) 11:49:28.21

>>613
型パズルで開発者にできた感を与えられるから
で実際、型を合わせるだけで正常系は大体うまく動くからね

**デフォルトの名無しさん** · 2022/10/02(日) 11:51:59.81

>>611
100%同意
適材適所で選ぶ能力が無いだけ

**デフォルトの名無しさん** · 2022/10/02(日) 11:54:19.38

>実際、型を合わせるだけで正常系は大体うまく動くからね
ほら無能じゃんw

**デフォルトの名無しさん** · 2022/10/02(日) 11:56:25.66

>>612
テスト書かないの？

**デフォルトの名無しさん** · 2022/10/02(日) 12:04:09.63

まあ実際動的型付け言語でやるプロジェクトは
少数精鋭のチーム編成ができないと厳しいわな

メンバーが多くてコミュニケーションコストが高かったり入れ替わりが頻繁だったり下請け孫請けから最低ラインを下回るメンツが入ってくるようなら静的型付け言語のほうが楽

**デフォルトの名無しさん** · 2022/10/02(日) 12:30:18.64

>>618
どこができてない？ヘッダに多少差があるとはいえ明確な差が出てるよね
Nodeはhttpモジュール使っても遅いし言語自体がゴミとしか言いようがない

**デフォルトの名無しさん** · 2022/10/02(日) 12:34:37.19

APIに存在しうるCPU処理、IO処理を排除してミニマムな状態でもGoやRustと比べるとここまで差が出る

だからISUCONで誰もNodeなんか使わないんだよ
Goは手軽でスピードが出るから人気なのは自明だな

**デフォルトの名無しさん** · 2022/10/02(日) 18:32:39.72

>>622
このスレに居てその質問は流石に不勉強じゃないかな……

静的型付け言語での実装においてもテストはもちろん書かれるよ
当然テストに網羅性は無いわけだけど、型はそれを補ってくれて、テストで調べるべき範囲を絞ってくれる訳だ
スイスチーズモデルにしても型は理論的に一定の範囲に穴がないことを保証してくれるのでテストの良き友だよ

ランタイムやコンパイラの型の実装が間違ってるかもしれないとかいう意見は、構文解析が間違ってるとか最適化が間違ってる並の、有り得はするけど議論するレイヤーが異なる難癖なので無視するよ

**デフォルトの名無しさん** · 2022/10/02(日) 18:49:30.07

>>626
バカにされてることがわからず斜め上のレスをしちゃう無能w

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

>>627
上司に無能って言われた経験ありそうw

**デフォルトの名無しさん** · 2022/10/02(日) 19:07:31.43

アンカーを付けるときはまず無知無能異常者認定する複おじしぐさ

**デフォルトの名無しさん** · 2022/10/02(日) 20:08:45.57

Rustなら安心安全だからテストは必要ない
コンパイラーが全部教えてくれる

**デフォルトの名無しさん** · 2022/10/02(日) 20:37:15.64

>>630
Rustはプログラムを書き始めるためのcargo new --lib した時にテスト用mod testsの雛形が自動的に生成用意されるくらいテスト重視主義の言語
もちろん強力な型システムによりRustコンパイラがコンパイル時点でデータ競合を含む多くのバグを実行する前に指摘してくれるのも事実
その分だけテスト記述は本来のロジックに関するテストに対して専念できる

**デフォルトの名無しさん** · 2022/10/02(日) 20:38:45.06

>>630
それって
コンパイラが教えないバグが一部存在してもコンパイラにペナルティがないこと
を問題視しているんだよね

全部教えると断言すればきっと罰を受けるのになあってことだよね

**デフォルトの名無しさん** · 2022/10/02(日) 20:47:01.74

>>627
バカにされてる、というか煽られている部分を感じなかった訳じゃないけど、そうだとしても煽ってくる人間は、型とテストが複合的にエラーを減らす手段であって排他なものではないということを、理解していないか少なくとも認識していないので、レスの内容は変わらないよ

大体実装が早くできて楽だよね、っていう動的型付け言語の特性を私は否定するつもりはないし
技術というのはメリット・デメリットを認識した上で選定するものであって、単に煽るだけとか無能呼ばわりするような人間がそれらを認識できてるとは思わないし、もし不勉強と言われたくないならテストを書くという単一の手段がエラーを防ぐという点でどういう十分さがあるのか説明しなきゃ

あと
>>630
Rustだって基本のツールチェーンでテストが実行できるように作られてるんだからテストが必要ないなんで事は少なくとも言語開発チームは思っちゃいないよ
テキトー言わんでくれるかな

**デフォルトの名無しさん** · 2022/10/02(日) 21:05:46.88

>>633
かつての静的型付け言語は型宣言が面倒だったため動的型付け言語は型宣言が必要ない僅かな分だけ有利だった
今の静的型付け言語は自動的に型推論が行われるため動的型付け言語が有利なことはない
実行時デバッグの手間が増える動的型付け言語は劣ったプログラミング言語

**デフォルトの名無しさん** · 2022/10/02(日) 21:25:54.32

現実は違う
まるで不殺主人公みたいに動的型を殺さないし、コンパイルが通らなかった人を殺さない
検査しかしないくせに結構役に立つのが現実

**デフォルトの名無しさん** · 2022/10/02(日) 22:58:21.35

FacebookがRust使ってると自慢レスがあったけど。
それでFacebookは使いにくいのかと納得してしまった。

**デフォルトの名無しさん** · 2022/10/02(日) 23:20:02.90

c++は拡張子が規格で決まってない糞だ

**デフォルトの名無しさん** · 2022/10/02(日) 23:54:28.90

>>636
クラウド世界トップのAWSも
CDN世界トップのCloudflareも
Rust製です

**デフォルトの名無しさん** · 2022/10/02(日) 23:55:48.81

じゃあ企画委員会に入ればいいんでねーの

**デフォルトの名無しさん** · 2022/10/02(日) 23:57:50.44

>>638
アマゾンが倒産する日も近いな。

**デフォルトの名無しさん** · 2022/10/03(月) 00:04:13.05

Rust Foundationを共同設立したGoogle, Microsoft, Amazonなど各社は負け組になる可能性ありうる

**デフォルトの名無しさん** · 2022/10/03(月) 00:06:35.78

型の話はRDBとNoSQLの比較で
schema on writeがいいかschema on readがいいかという話と同じ
どちらか一方がが常に言い訳ではなくそれぞれ良し悪しがある

**デフォルトの名無しさん** · 2022/10/03(月) 00:46:15.86

根本的哲学的になぜ型というものが存在してるのか

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

>>642
NoSQLデータベースの多くはschema on readではなく、単に入れたものをそのまま出すだけだ
多くのNoSQLはオンライン性能が重要なため、Elasticsearchのようにschema on writeを使用するものもある
schema on readはむしろデータ分析用途でリレーショナルモデルとSQLで使用される場合が多い

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

OLTP用かつschema on readなNoSQL DBってあるっけ？
MongoやDynamoDBみたいなKVS+α系はキースキーマとインデックスの併用だから典型的なschema on writeだよな
インデックスなしのスキャン操作はschema on readと言えなくもないけどオンラインでは普通使わないよね

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

>>643
原始的なアセンブラはアドレスに型が無く、アドレスに何が入っているかによって人間が命令を使い分ける。
その状態より型があるほうが便利なのでC言語は支持された。

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

a[i]の順序を逆にi[a]と書くのが何故マナー違反かって質問が存在することは誰も否定しなかったので
質問が存在するゆえに型が存在する

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

>>640
判ります

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

>>646
アドレッシング用レジスタとデータ用レジスタの区別も無い罠
プログラムカウンタでさえただのレジスタと区別しないの好き

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

>>637
OSが存在しないファイルシステムも存在しない環境でどうやって拡張子を定義するんだって話

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

>>633
>型とテストが複合的にエラーを減らす手段であって排他なものではないということを、理解していないか少なくとも認識していない

めっちゃ判ります
っていうか煽るためにわざと知らない気付かないフリしてるのかと思える

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

・動的型付け言語 ←動的動作のためメモリ上に型情報が必要となる
・GCあり言語 ←GCのためにメモリ上に一部型情報が必要となる
・GCなし言語 ←基本的にはメモリ上に型情報は必要ない
　（ただし敢えて動的に型を扱いたい時は型情報をメモリ上に持たせる）

**デフォルトの名無しさん** · 2022/10/03(月) 11:43:54.89

>>644
>NoSQLデータベースの多くはschema on readではなく、単に入れたものをそのまま出すだけだ

schema on readの意味くらいは理解してからレスしろ

**デフォルトの名無しさん** · 2022/10/03(月) 11:45:28.34

>>645
おまえもschema on readの意味くらいは調べろよ

**デフォルトの名無しさん** · 2022/10/03(月) 12:09:23.06

恥ずかしいから>>654こそ調べたほうがいいぞ
schema on readというのはデータ分析や大規模バッチ処理の文脈で出てくる言葉で、Hadoopのように検索時に生に近い形式のデータを力業でフルスキャンする方式だ
データ分析においてはデータの取り込みは柔軟にしつつ読むときに工夫しろというベストプラクティスがあって、それを端的に表している
対してschema on writeってのは普通のRDBやMongoDB、Elasticsearchのような、書き込み時にスキーマ情報を使ってインデックスを作る方式を指す

**デフォルトの名無しさん** · 2022/10/03(月) 12:15:37.58

>>650
それは実行環境であって、開発ビルド環境のソースファイルは関係ねーだろ？
それともお前はOSも無いファイルシステムもない環境で開発ビルドしたことあんのかよ？あ？

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

>>656
そもそもソースがファイルかどうかもわからんのにお前は何を言ってるんだ？w

**デフォルトの名無しさん** · 2022/10/04(火) 00:52:19.50

>>657
ム板で、ソースがファイルじゃないなら何？

**デフォルトの名無しさん** · 2022/10/04(火) 06:00:39.30

>>658
ストリームとかじゃね
あるかどうかは知らんけどワンパスコンパイラなら標準入力からソースもらうとか可能なはず

**デフォルトの名無しさん** · 2022/10/04(火) 09:09:48.35

こういうとき絶対>>657本人じゃなくて
横から「○○じゃね？」っていうやつがやってくるの面白いよね

**デフォルトの名無しさん** · 2022/10/04(火) 11:43:33.67

>>660
知らんけどがついてたらモアベターだったよね。

**デフォルトの名無しさん** · 2022/10/04(火) 12:54:23.68

ファイル以外のソースがあるとしてそれがファイルの拡張子が決まってないこととなんか関係あるのか？

知らんけどw

**デフォルトの名無しさん** · 2022/10/04(火) 13:32:51.60

こういう流れで>>657本人が出てきて
最後まできっちり議論に付き合うケースって皆無よねｗ

**デフォルトの名無しさん** · 2022/10/04(火) 13:44:57.74

そんな話じゃないでしょ…
C++の規格はフリースタンディングも想定してるから、ファイルシステムなんかそもそも規約に入れようが無く、結果、ソースファイルについても何の規約も無い、みたいな話ではないの？
規約が無いかは調べてないけど。

**デフォルトの名無しさん** · 2022/10/04(火) 13:59:03.52

C言語のソースファイルは*.c
そしてヘッダファイルは*.h
決まっていて困ることはない
ファイルシステムがどうこう言い訳してるやつは屁理屈

**デフォルトの名無しさん** · 2022/10/04(火) 14:14:34.11

>>662
ストリームに名前なんて無いんだから拡張子なんてつけようがないだろ

>>664
そもそも開発環境とかを規定してる言語の方が珍しいだろ

**デフォルトの名無しさん** · 2022/10/04(火) 15:59:25.45

本人再登場ww
ファイルシステムなんて関係ねーだろw

**デフォルトの名無しさん** · 2022/10/04(火) 18:44:15.47

>>658
ソースは俺。

**デフォルトの名無しさん** · 2022/10/04(火) 18:59:59.83

規格で拡張子が決まってる言語なんてあるの？

**デフォルトの名無しさん** · 2022/10/04(火) 19:21:43.31

知ってる範囲ではc#が規格内に拡張子が書かれてるけど、確かに規定では無いな。

**デフォルトの名無しさん** · 2022/10/04(火) 21:33:50.53

javaとかは決まってるんじゃないか
知らんけど

**デフォルトの名無しさん** · 2022/10/04(火) 21:35:32.21

汎用機とかでファイル名の最大長が短くて拡張子使わないケースとかはあるわな

**デフォルトの名無しさん** · 2022/10/04(火) 21:49:54.68

>>671
javaは拡張子やフォルダー構成も決まってたような気がするけど言語仕様なのか単なる開発環境の決め事なのかはよく知らん

**デフォルトの名無しさん** · 2022/10/05(水) 00:45:16.34

誰か拡張子の歴史について調べてこい

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

俺様がベーシックやってた頃は拡張子なんて無かったぞ
誰か説明しろよ

**デフォルトの名無しさん** · 2022/10/05(水) 06:29:51.10

拡張子なんて決め事以上のものではないからなぁ。

**デフォルトの名無しさん** · 2022/10/05(水) 06:37:01.54

拡張子で言語が流行るかどうか決まる

**デフォルトの名無しさん** · 2022/10/05(水) 17:09:15.64

最近読んだC++コードの拡張子がc++だったのはたまげたな

**デフォルトの名無しさん** · 2022/10/05(水) 17:51:07.30

c++は
.cpp
.cc
.cxx
.c++
.C
.hpp
.hh
.H
とか節操無さすぎ。

**デフォルトの名無しさん** · 2022/10/05(水) 20:10:07.38

その点Rustは統一されてて安心安全
ついでにメモリも安心安全

**デフォルトの名無しさん** · 2022/10/06(木) 02:02:14.61

c言語は UNIX という OSを実装するために作られたものだから
ファイルシステムとは表裏一体だったという歴史は捨てようがない
派生した言語や OS も色々引きずっている

**デフォルトの名無しさん** · 2022/10/06(木) 02:04:08.96

拡張子なんてもんはいつからできたんだよ
誰か調べてこい

**デフォルトの名無しさん** · 2022/10/06(木) 05:32:32.78

>>681
もうC++の話はいいのか？w
C言語では *.[cC], *.[hH] でない処理系は見たことないな

**デフォルトの名無しさん** · 2022/10/06(木) 05:57:55.23

拡張子の文化が広まったのは、
８ビットマイコン時代にCP/Mが普及したのがキッカケで
CP/M→MS-DOS→windows の系譜で定着したのだろう
当初は、アセンブリ言語のソースや実行ファイルを拡張子で区別したが
高水準言語（高級言語）が次第に移植された

**デフォルトの名無しさん** · 2022/10/06(木) 08:26:06.13

拡張子の由来
https://ja.wikipedia.org/wiki/%E6%8B%A1%E5%BC%B5%E5%AD%90#%E6%8B%A1%E5%BC%B5%E5%AD%90%E3%81%AE%E7%94%B1%E6%9D%A5

拡張子は、もともとはDECのオペレーティングシステム (OS) 、たとえば、TOPS-10、OS/8やRT-11に利用されていた。
その後、CP/Mでも採用された。CP/Mのファイル名は8+3バイトの構成になっており、後ろの3バイトが拡張子と呼ばれた。
さらにCP/Mと互換性を取るため、MS-DOSやOS/2、Windowsなどに受け継がれた。現在のWindowsでは3バイトの制限はない。

**デフォルトの名無しさん** · 2022/10/06(木) 08:29:55.98

CP/Mが真似たDECのOSから普及していたが

**デフォルトの名無しさん** · 2022/10/06(木) 08:44:08.07

そりゃ、K&Rの時代から .c .hが有ったにしても
DECのミニコンを庶民はそうそう導入できない

**デフォルトの名無しさん** · 2022/10/06(木) 09:13:49.27

そりゃ当然、コンピュータを使っている人への普及の話だろ。使ってもいない人に普及するわけはないが。

**デフォルトの名無しさん** · 2022/10/06(木) 09:39:10.81

>>687
いつから庶民の話になったんだ？

**デフォルトの名無しさん** · 2022/10/06(木) 09:59:11.55

>>689
UNIXとCの話は先に書いたから、
次にマイコン時代の浸透と拡散の話に進めたけど、早かったか
それらの前、BCPL等の時代に拡張子やファイルの概念があったのかは調査中だ