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

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

スレタイ（順番はRedMonk準拠）以外の言語もok

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

**デフォルトの名無しさん** · 2022/05/20(金) 09:05:30.63

純粋アルゴリズムにrustは不向きだとなぜ気づかんのかな。。

**デフォルトの名無しさん** · 2022/05/20(金) 09:31:27.55

>>595
なかなかゴミみたいな様相だよ
フィボナッチ数列の第n項はメモ化しなくても線形オーダー、あるいは対数オーダーで計算できるのに、メモ化にこだわりのある人が「そのやり方はmainのループと合わせて計算量はn^2だ」とか言い出して散々

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

>>596
個人的にはむしろ抽象化と両立が難しいところに新しい道ができたように思えた
（過剰なメモ化なら言語関係なくやられがちな気がする）

**デフォルトの名無しさん** · 2022/05/20(金) 16:45:27.87

フィボナッチ数列計算するのにあそこまでする必要はないわ

**デフォルトの名無しさん** · 2022/05/20(金) 17:32:46.13

スレ見てないけどベクトル演算した方が速いんじゃないの知らんけど

**デフォルトの名無しさん** · 2022/05/20(金) 17:36:21.53

Rustのスレなんだし、アルゴリズムで計算量を改善したりする話じゃなくて、Rustのベストプラクティスについて話してほしい

**デフォルトの名無しさん** · 2022/05/20(金) 17:49:16.78

Rustのスレじゃねーんだなこれが

**デフォルトの名無しさん** · 2022/05/20(金) 17:58:31.56

数値計算はやっぱりJuliaかFORTRANが実行速度最速なのかしらん。

**デフォルトの名無しさん** · 2022/05/20(金) 18:17:57.67

>>597
nが与えられた時に
『フィボナッチ数 F_n』を求めるのは単純にO(n)あるいは工夫してO(log n)で合っている

ところがその『F_n』を求める関数を「ループでn回」用いて
『フィボナッチ数列 F_0, F_1, F_2, ..., F_n』を求めると当然n倍でO(n^2)またはO(n・log n)となってしまう
それが後半の「そのやり方はmainのループと合わせて計算量はn^2だ」という話だと思うのでそれも合っている

ところが『フィボナッチ数列 F_0, F_1, F_2, ..., F_n』を生成するイテレータを作ると全体がlog(n)で済む
つまり計算量を大きく節約できる
この二つの区別を出来ているかどうかが重要なポイントかな

**デフォルトの名無しさん** · 2022/05/20(金) 18:30:54.17

ごめん1箇所だけ記述ミスを訂正
>>604
× ところが『フィボナッチ数列 F_0, F_1, F_2, ..., F_n』を生成するイテレータを作ると全体がlog(n)で済む
○ ところが『フィボナッチ数列 F_0, F_1, F_2, ..., F_n』を生成するイテレータを作ると全体がO(n)で済む

**デフォルトの名無しさん** · 2022/05/20(金) 19:27:34.87

>>605
コテハン付けろよ。
NGにするから。

**デフォルトの名無しさん** · 2022/05/20(金) 19:32:41.44

頭おかしくなっちゃった！
　　－＝≡ ∩ 彡⌒ミ　∩
　－＝≡　　.ヽ(´・ω・｀) /
－＝≡　　　　(　　　　/
　－＝≡　　（　　 ⌒)
　　－＝≡　　し　し'

**デフォルトの名無しさん** · 2022/05/20(金) 20:02:33.19

>>604
そうそう、こんな感じで論点をどんどん変えてくんだよね
フィボナッチ数列のはずがフィボナッチ数列の1~n項の計算にすり替えられちゃう

**デフォルトの名無しさん** · 2022/05/20(金) 20:07:15.27

『フィボナッチ数 F_n』を求めるアルゴリズム・計算量と
『フィボナッチ数列 F_0, F_1, F_2, ..., F_n』を求めるアルゴリズム・計算量は当然異なるからね
前者は繰り返し二乗法で1個の算出がO(log n)がベストだけど
後者で前者の方法を使ったら遅くなる
後者は単純に前二つを足していけばn個の算出がO(n)で済みそれがベスト

**デフォルトの名無しさん** · 2022/05/20(金) 20:33:10.89

スレの流れとしては前者なのに一人だけ「数列だから初項からn項までの計算量を考えろ」とか頓珍漢なこと言ってるのよね

**デフォルトの名無しさん** · 2022/05/20(金) 20:52:13.48

スレ見たけど最初から全員がフィボナッチ数列を列挙させているから
>>609で言うところの後者だな
そして今日書かれた2種類のコード共に後者のイテレーター

>>610
たぶん君だけが勘違いしている可能性が高いｗ

**デフォルトの名無しさん** · 2022/05/20(金) 20:52:49.34

フィボナッチ数列自体はただの例題なのに異様な執着心見せる人が居るよね
なんかのコンプレックスこじらせてるのかな

**デフォルトの名無しさん** · 2022/05/20(金) 20:59:42.21

>>610
フィボナッチ数列といったら F_0, F_1, F_2, ..., F_n, ... だよ
それはともかく前者と後者でベストなアルゴリズムが異なるから前者だけの話をすることはありえないと思う
そして後者のイテレータはそのまま前者をO(n)で求めることが出来るから
どちらもO(n)で十分とするならばイテレータをプログラミングするのが自然じゃないかな

**デフォルトの名無しさん** · 2022/05/20(金) 21:04:10.39

職業マは生暖かい目で見守ってるよ
初学者・学生・無職・アマチュアプログラマが必死になれるのは
自転車置き場の議論だけだからね
昼間必死に書き込んでるやろ彼らは

**デフォルトの名無しさん** · 2022/05/20(金) 21:07:40.93

フィボナッチってO(1)では？（ビネ並感）
流れはよくわからないが、とりあえず本スレは盛り上がっているようで何よりだね

**デフォルトの名無しさん** · 2022/05/20(金) 21:15:10.30

各項のオーダーはO(1)可能だが複素数(行列)でムダに計算量多いだろw
結局一覧を列挙するなら足し算していくのが一番速い

**デフォルトの名無しさん** · 2022/05/21(土) 00:28:12.49

スレタイ読めよアスペども

**デフォルトの名無しさん** · 2022/05/21(土) 07:47:11.09

>>616
複素数じゃないよ、実数の範囲で計算できるよ

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

Qitaベンチマークで、フィボナッチとかドヤァってるドアホ見るけど、片方の言語がoverflowチェックなどが入ってる演算を
使ってるのに、もう片方はチェックが入らない言語を使って比較してることがよくある。とんでもねえアホ
さらにいうなら最適化レベルも、ループアンロールをデフォルトで勝手に行う言語と、明示しない限り行わない言語で
比較してたりメチャクチャなアホ。お前の推しの言語がチェック付き演算行ったら、お前の推しじゃない言語と変わらんからな

**デフォルトの名無しさん** · 2022/05/23(月) 01:37:17.26

当該ページを示さずに愚痴られても…

**デフォルトの名無しさん** · 2022/05/23(月) 02:12:19.04

標準的なコンパイル方法・プログラムの書き方をした場合の比較になっているのなら意味はあるのでは

**デフォルトの名無しさん** · 2022/05/23(月) 05:59:53.99

確かにCheckedAddとかで書いてるQita記事のフィボナッチベンチなんて見たこと無いね、逆に言うとそれしか意味がない。ベンチとは名ばかりのフワッとした自己満足オナニーだ、100mハードルと100m走くらべてるようなもんさ

**デフォルトの名無しさん** · 2022/05/23(月) 07:01:43.76

>>619
Rust本スレのフィボナッチはoverflowチェック入っているぜ
https://mevius.5ch.net/test/read.cgi/tech/1652347700/181

>>622
それはその個人の問題点であってプログラミング言語の問題ではない

**デフォルトの名無しさん** · 2022/05/23(月) 09:56:36.54

顔真っ赤でコピペして来てるｗ
書いたどうだという話じゃない、それでベンチマーク取ってみろという話だよ。この流れが分からない奴は個人の問題点ｗ
いちいちオーバーフローがセーフな演算をchecked_addなんて冗長な書き方しか出来ないのだから、言語の問題でしょう？
標準的なコンパイル方法・プログラムの書き方をした場合、危険でズルなんだからｗ

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

>>623
うわっ、何このダサいコード

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

フィボナッチが居ついちまったじゃないかよ。

お前ら責任取ってフィボナッチの話題禁止な。

**デフォルトの名無しさん** · 2022/05/23(月) 12:30:43.66

フィボナッチ呼ばわりはフィボナッチさんへの風評被害になるからやめな

**デフォルトの名無しさん** · 2022/05/23(月) 13:17:40.25

>>625
口だけ番長定期
これだから世界から糞バカ中世ジャップランド土人とか呼ばれるんだよ

**デフォルトの名無しさん** · 2022/05/23(月) 15:35:29.13

>>624
それはあまりにも無知な発言
RustではC/C++やCPUでの同じ動作となっているにすぎない

例えばC/C++では (正確には未定義だが通常動作)
int main() {
char x = 127;
x = x + 1;
printf("%d\n", x); // 出力結果: -128
}

Rustでは (普通にrelease modeの場合)
fn main() {
let mut x: i8 = 127;
x = x + 1;
println!("{x}"); // 出力結果: -128
}
ちなみにdebug modeではpanicで知らせる
release modeでもコンパイラに指定でpanicで知らせることも可能

**デフォルトの名無しさん** · 2022/05/23(月) 15:38:27.39

>>629に加えてRustでは
let n: i8 = 126;
の時、

println!("{:?}", n.wrapping_add(1)); // 出力結果: 127 // 溢れていないならその値
println!("{:?}", n.wrapping_add(2)); // 出力結果: -128 // 溢れたらラッピング(一周して)その値

println!("{:?}", n.overflowing_add(1)); // 出力結果: (127, false) // 溢れていないならばオーバフローフラグfalseが返る
println!("{:?}", n.overflowing_add(2)); // 出力結果: (-128, true) // 溢れたらオーバフローフラグtrueが返る

println!("{:?}", n.checked_add(1)); // 出力結果: Some(127) // 溢れていないならばOption型のSome(値)が返る
println!("{:?}", n.checked_add(2)); // 出力結果: None // 溢れたらOption型のNoneが返る

println!("{:?}", n.saturating_add(1)); // 出力結果: 127 // 溢れていないならその値
println!("{:?}", n.saturating_add(2)); // 出力結果: 127 // 溢れたらその型の上限の値

といったようにRustでは求められている状況に応じて容易に多様な対応を取ることが可能
Rustよりも用意周到なプログラミング言語があればその動作を教えて欲しい

**デフォルトの名無しさん** · 2022/05/23(月) 15:44:29.35

顔真っ赤ｗｗｗｗｗｗｗｗ

**デフォルトの名無しさん** · 2022/05/23(月) 15:45:47.88

ここ2週間くらいRustスレずっとこんな調子だったんですよ
勘弁してほしい

**デフォルトの名無しさん** · 2022/05/23(月) 15:58:24.00

某R言語のユーザーは本当に気持ち悪いな

**デフォルトの名無しさん** · 2022/05/23(月) 16:13:42.23

何が用意周到なんだか。言語のことを言ってるんじゃなく、「あくまでそれでベンチマーク比較すんなよド素人」という話だけなのに、ムキになって言語機能の紹介書いちゃうオジサン
蛇足的に言語のことを言うなら、RustよりまともなのはC#でcheckedキーワードの明示による算術のオーバーフローをチェックかな？安全に足し算したいだけで毎回checked_addなんて書くのは勘弁願いたいのは本音。C#もデフォルトで安全に倒すという思想からも逸脱してるとも言えるが

**デフォルトの名無しさん** · 2022/05/23(月) 16:24:56.03

>>625
Rustスレでも満場一致で同じ意見だからご心配なく

**デフォルトの名無しさん** · 2022/05/23(月) 16:33:53.72

CPU・C・C++・C#・Rust全てにおいてオーバフロー時は一周回った結果になるってことか
じゃあそれが標準的な振る舞いなのだろう

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

>>634
演算子オーバーロードできる言語なら a + b が Option<T> 返すような型を実装できるから言語組み込みでキーワード用意する必要もないのでは

例えばRustだとそういうライブラリもある
https://docs.rs/checked/latest/checked/

**デフォルトの名無しさん** · 2022/05/23(月) 20:07:10.01

>>636
Goもそれらの言語と同じ
int8(127)に1を足すと-128となる
標準でオーバフローチェックしなくてズルい！と発狂している人はどんな言語を使っているのだろう

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

実装が処理速度に与える影響を論じるのなら浮動小数点数の話で語り始めるべきだったなｗ

**デフォルトの名無しさん** · 2022/05/24(火) 01:58:49.24

Pythonなどは(無限にではないが)演算で型拡張が行われるから、それらと同列でベンチマークすべきではないのは同意
Rustを愛しすぎて、顔にウンコ付いてて冗長で気持ち悪い書き方を擁護して発狂する用意周到オジサン

**デフォルトの名無しさん** · 2022/05/24(火) 02:20:04.04

Rustでの標準挙動は>>636や>>638により他の主要なプログラミング言語と同じ
その上で>>637など演算毎にチェックも可能
このような状況でとなおRust叩きをしている人は頭がおかしいのかそれとも

**デフォルトの名無しさん** · 2022/05/24(火) 04:56:32.72

Rustスレ過疎ってル訳でもないのにどこでもRustの話始めるのなんでなん?

**デフォルトの名無しさん** · 2022/05/24(火) 10:26:14.04

頭がおかしいから
反応したら負け

**デフォルトの名無しさん** · 2022/05/24(火) 10:43:26.98

言語は一つに統一したらええに。
言葉も英語だけなら良かったに。

**デフォルトの名無しさん** · 2022/05/24(火) 11:54:32.13

Swiftってわかりにくいね
Objective-Cもクソだったし林檎嫌いだわ

**デフォルトの名無しさん** · 2022/05/24(火) 12:46:51.04

それでも Swift >>> 越えられない壁 >>> Go、つまり林檎 >>>>>> Google

**デフォルトの名無しさん** · 2022/05/24(火) 12:47:47.67

>>645
> Objective-Cもクソ

具体的にはなにがどうクソなの？

**デフォルトの名無しさん** · 2022/05/24(火) 13:19:16.27

まずxcodeが糞
糞というか狂気
犯罪と言っても過言でないと思う

**デフォルトの名無しさん** · 2022/05/24(火) 13:40:19.38

3行使って情報量がほぼゼロ

**デフォルトの名無しさん** · 2022/05/24(火) 16:13:05.56

1 + 1 = 2 レベルの内容すら理解できんとかガイジ？ホイ卒？

**デフォルトの名無しさん** · 2022/05/24(火) 16:25:30.71

Swiftやってると某こんスレにいるアホ言語初心者のような参照カウントの悪辣性に気付くんだわ。その言語の機能解説ずーとしてるバカたち
1つでもスマートで無いと言えば「自分たちが攻撃された」と思い込み、べたコード貼り付けて得意満面に機能解説しだす

**デフォルトの名無しさん** · 2022/05/24(火) 16:38:55.79

>>650
1 + 1 = 2は定義上そうなっているだけなので理解できるかどうかという話じゃないんだぞ（クソリプ）

**デフォルトの名無しさん** · 2022/05/24(火) 16:39:22.08

「Swiftになってよかったこと」で調べればobjective-cの駄目なところはいくらでも出てこない？

**デフォルトの名無しさん** · 2022/05/24(火) 17:03:32.22

Swiftは言語だけみれば結構いいけどね
エラーハンドリング機構はメジャー言語の中では一番進んでる

objective-cは名前空間がなくて衝突回避のためにどうしても長い名前になるのがよくなかった
Swiftにも引き継がれてるメソッド名が引数名込みになるルールも分かりにくい
あとは動的ディスパッチなので速度が必要ならCかC++で書かないといけないのが面倒だったかな

**デフォルトの名無しさん** · 2022/05/24(火) 18:08:59.87

>>653
ビチグソが固形ウンコになったくらいのレベルでよかったとかいうxcodersは頭がおかしい定期

**デフォルトの名無しさん** · 2022/05/24(火) 18:11:41.40

ごめん、うんこに失礼だった
うんこは体にとって大事だけど
xcodeは世界の敵、環境破壊兵器、サリン、AntiSDGs、人工地震5Gだったわ
世界平和のために早く殺すべき

**デフォルトの名無しさん** · 2022/05/24(火) 18:32:36.39

>>654
同意

**デフォルトの名無しさん** · 2022/05/24(火) 18:44:18.42

具体的なレスを聞かせてくれた>>654すこ

**デフォルトの名無しさん** · 2022/05/24(火) 18:49:32.82

>>655
日本語読める？

**デフォルトの名無しさん** · 2022/05/24(火) 19:00:38.09

業務でストレス貯まってるのかな

**デフォルトの名無しさん** · 2022/05/24(火) 21:33:55.54

匿名掲示板でうんこレスしこたま投稿するの楽しいにゃん♪

**デフォルトの名無しさん** · 2022/05/24(火) 22:38:22.80

Xcodeが嫌ならVS CodeかAppCode使えば良くね？何が問題なの？

**デフォルトの名無しさん** · 2022/05/26(木) 19:00:46.30

次スレから
スレタイに Julia も追加すべき

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

どうぞ

**デフォルトの名無しさん** · 2022/05/26(木) 20:19:19.19

旧世代言語は去れ

**デフォルトの名無しさん** · 2022/05/28(土) 09:48:31.36

kotlinのチュートリアル的なのみたらif式は変数に代入してコールできるとかあったけどいつ実行されるの？コールしたとき？それとも代入された変数には既にif式の実行結果が入ってる？

**デフォルトの名無しさん** · 2022/05/29(日) 16:30:35.70

・フリーエンジニアが年間3,600万円の売上を上げた方法を解説する
・26歳で独立して月収150万になった元引きこもりエンジニアの物語
・ブラック企業から退職し、独立後11ヶ月で“月収300万円超え”になるまでの軌跡を
　デザイナー社長船越良太に聞いてみた！
・ITフリーランスで月額単価150万円！万が一の就業不能に備える無料の保険もある「クラウドテック」
・フリーランス時代に月収4万円→最高340万円を達成した船越さんに、「お金」との向き合い方を聞いてみる
・フリーランスSEってどれくらい稼げるの？月単価160万円の案件を扱う定番エージェント
・フリーランスの仕事や職業の種類って何があるの？独立5年目で月収200万の僕が詳しく解説

**デフォルトの名無しさん** · 2022/05/29(日) 16:46:50.81

>>667
嘘くさ
情報商材とかに騙されてそう

**デフォルトの名無しさん** · 2022/05/29(日) 18:49:03.61

>>668
君は年収３００でRustで組み込みでもしてるのが実力だからねｗ

**デフォルトの名無しさん** · 2022/05/29(日) 20:21:54.98

ムキになってて草

**デフォルトの名無しさん** · 2022/05/29(日) 20:29:03.30

年収800万超えエンジニア注目するプログラミング言語、第1位は？
https://news.mynavi.jp/techplus/article/20210802-1936893/
https://news.mynavi.jp/techplus/article/20210802-1936893/images/001.jpg

**デフォルトの名無しさん** · 2022/05/29(日) 23:44:19.76

>>671
こういうの鵜呑みにしちゃうんだ
変な壺とか買ってそう

**デフォルトの名無しさん** · 2022/05/30(月) 00:09:02.12

Goとかいうウンコオブウンコのそび糞

**デフォルトの名無しさん** · 2022/05/30(月) 08:59:04.28

>>663
このようにマジキモRust信者が24時間張り付いて、他言語の悪口を言うスレです

**デフォルトの名無しさん** · 2022/06/01(水) 05:40:50.61

そんな書き込みは見かけないね

**デフォルトの名無しさん** · 2022/06/01(水) 07:00:10.40

（俺以外の）そんな書き込みは見かけないね

**デフォルトの名無しさん** · 2022/06/01(水) 11:51:48.67

（自演して）クソクソ言っとけば悪口になると思ってそう

**デフォルトの名無しさん** · 2022/06/01(水) 17:27:50.52

>>671
高収入になるほどRustを好む傾向がはっきりデータに出ているな
この状況でRustを叩いてる連中はどういう人たちなのだろう？

**デフォルトの名無しさん** · 2022/06/01(水) 17:43:20.57

あからさまにRustを叩いている人はごく一部を除いていない
ほとんどはRust信者を生暖かい目で見ているという立ち位置

**デフォルトの名無しさん** · 2022/06/01(水) 21:28:30.53

Rust信者に香ばしい人が多いのはなんなんだ？

**デフォルトの名無しさん** · 2022/06/01(水) 23:51:24.24

信者は香ばしいもんだろ

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

>>678
叩きもなにも、もはや誰も言語仕様の話はしていない。汚物連呼程度の煽りならスルーするのが賢明だ

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

Rustは素晴らしい言語ではあるが
頭が悪い側の一部のプログラマーが理解できない可能性ないのか？

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

>>683
そう考えるRust狂信者は多そうだな。
Haskellの二の舞だわ。

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

むしろ駄目プログラマーを上手く排除できるからありがたい
理想的な社会になる

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

駄目プログラムがRustに置き換わるだけで何の解決にもなっていないのでは？

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

一番排除できてありがたいのは、癖のあるC++プログラマーw

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

例えば駄目プログラムの典型として
「データ構造スパゲティ」

GC言語だとそれでも動いてしまうがメンテしにくい、バグ入り込みやすい、デバッグしにくいなど、当然問題ありまくり
C/C++だと解放忘れや解放後利用や多重解放などが入り込みがちで難解になるため普通は避けるが、避けない人も出てきてはまる
Rustだとコンパイルが通らないことで、それら諸問題を避ける形になることが多い

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

スパゲッティか～
おいしそうだねえ～

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

>>688
データ構造がスパゲッティでも、Rustのルールに則っていれば、動いてしまうんじゃないの？

Rustだって、設計の良し悪しまで判断できないと思うんだが。

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

何でもRcで囲めば簡単にスパゲッティデータ構造作れそう

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

>>685
まぁ確かに
Ruby募集すればスクール卒が集まるし、PHP募集すれば障害者雇用枠が集まるしな
そういうこと

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

>>692
そういうのはRuby募集するときにRustスキル必須にすればいいけど、そんなことをしたらコスト上がるだろ。
コスト以上の売上を上げられるのかね？

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

>>693
何当たり前のこと言ってるんだ？
便所掃除に大卒雇うわけないだろ？
そういうこと

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

>>687
C++ はひどい言語だ。これは、多くの平均以下のプログラマーが使ってるために
さらに輪をかけてゲロゲロになっていて、どうしようもないゴミが
簡単に生産されるようになってる。正直いって、C を選ぶ理由が C++ プログラマーを
追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。

C++ はトンでもなく悪い設計の元になりうる。どうせこの言語ではいつも STL やら
Boost やら、その他ゲロゲロベロベロの「素敵な」ライブラリの機能を使って、
それがあんたのプログラムに「役立つ」んだろうが、以下のことが起きる:

- うまく動かないときにもたらされる際限のない苦痛 (あと STL とか、特に Boost が
安定してるとか移植性があるとかいう奴は、どいつもこいつも大ウソつきで、
もはや笑えるレベルを超えている)

- 非効率な抽象プログラミングモデルで、2年たった後にこれらが実はそんなに
効率的じゃなかったことに気づくケース。でもそのときにはすでに全部の
コードがその素晴らしいオブジェクトモデルに依存していて、直すためには
アプリ全体を書き直さなきゃなんない。

言いかえれば、唯一まともで、効率がよくて、システムレベルで使えて、移植性がある
C++ ってのは、基本的に C で使える機能だけに限ったときなんだ。そして C だけに
限定するってことは、他の人がそれをめちゃくちゃにしないってことで、
ついでに沢山のプログラマが実際に低水準の問題を理解することができて、アホらしい
「オブジェクト・モデル」のたわごとを持ちこまないってことだ。

＞正直いって、C を選ぶ理由が C++ プログラマーを追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。
＞正直いって、C を選ぶ理由が C++ プログラマーを追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。
＞正直いって、C を選ぶ理由が C++ プログラマーを追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。
＞正直いって、C を選ぶ理由が C++ プログラマーを追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。
＞正直いって、C を選ぶ理由が C++ プログラマーを追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。
＞正直いって、C を選ぶ理由が C++ プログラマーを追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。
＞正直いって、C を選ぶ理由が C++ プログラマーを追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。
＞正直いって、C を選ぶ理由が C++ プログラマーを追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。
＞正直いって、C を選ぶ理由が C++ プログラマーを追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。
＞正直いって、C を選ぶ理由が C++ プログラマーを追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。