- 【wasm】ブラウザでC++。Emscriptenを語ろう
149 ：デフォルトの名無しさん[sage]：2020/03/27(金) 04:03:07.14 ID:VaiYZBCN - Wasmアプリは次のようなことで需要がありそうだ：
・nativeアプリの場合、ストレージの容量制限でインストールできない事があるが、
Wasmならブラウザ内で動くのでその心配は少ない。
・nativeアプリの場合、インストールするのに新しいVersionのOSを要求されること
があるが、Wasmなら、余り関係ない。
|
- 【wasm】ブラウザでC++。Emscriptenを語ろう
150 ：デフォルトの名無しさん[sage]：2020/03/27(金) 04:06:39.29 ID:VaiYZBCN - >>149
nativeアプリの場合、Win7で動いていたものがWin10で動かなかったり、逆に、Win10を要求されたり
する。
Androidアプリの場合も、バージョン○○以上が必要条件などとあったりする。
ところが、Wasmアプリの場合、余りそういうことは無い。
ブラウザのバージョンが有る一定以上のものでありさえすれば、OSの種類やバージョンに関係なく動く可能性が高い。
|
- 【wasm】ブラウザでC++。Emscriptenを語ろう
151 ：デフォルトの名無しさん[sage]：2020/03/27(金) 04:51:51.87 ID:VaiYZBCN - アプリストアにはアプリが多すぎて、まみれてしまう。
ウェブアプリなら、検索エンジンからダイレクトに探せるのでアプリストアよりは、まみれる度合いがましになる。
|
- 【wasm】ブラウザでC++。Emscriptenを語ろう
152 ：デフォルトの名無しさん[sage]：2020/03/27(金) 05:08:06.41 ID:VaiYZBCN - ・WasmやPWAが、TwitterやLineなどでshareし易いことは、
企業にとってはのどから手が出るくらい価値がある。
nativeアプリだと気に入ったアプリを友達にシェアしにくいが、
WasmアプリだとURLだけですぐにシェアできる。これはアプリの普及や
宣伝にとって意義は大きい。
・PC/Mac/iPhone/Androidで見た目や使い勝手が同じであることは、
アプリのブランド価値を高める。
これは、コンビニが全国で同じレイアウトと品揃えであることで
安心感と利便性を高めることで勝ち残ってきたことと通じるものがある。
|
- 【wasm】ブラウザでC++。Emscriptenを語ろう
153 ：デフォルトの名無しさん[sage]：2020/03/27(金) 05:14:54.39 ID:VaiYZBCN - 企業にとっては、プラットフォームごとにビルドし直さないでよいことだけでも
価値は大きい。
マルチプラットフォーム対応なのに最終プログラムが1種類だけで済むことは
メンテナンス性は劇的に向上する。
nativeアプリをマルチプラットフォームに対応させる場合、OSごとにビルドされた
最終プログラムのバックアップだけでも慎重を要し、生産性が下がる。
開発時にはいちいち、各プラットフォームごとにビルドする時間と手間、
テストが必要で、その時にトラブルも出易かった。例えば、
新しいバージョンのAndroidが出てきたら、新しいAndroidSDKをインストール
しなくてはならないが、それでツールキット側のバージョンが合わなくてトラブル
が発生し、その解決のために一週間以上も無駄になることもあっただろう。
Wasmなら、最終プログラムは一度ビルドするだけで済むのでそのようなトラブルが
生じないし、テスト工数も激減する。
|
- 次世代言語18 Go Rust Elixir Kotlin TypeScript
788 ：デフォルトの名無しさん[sage]：2020/03/27(金) 12:10:19.43 ID:VaiYZBCN - >>784
本来、変数とは読んで字のごとく「変化する数」なわけだから
本質的に mutable(変更可能な)なもの。
にも関わらずRustでは、変更可能な変数には mut を指定しなければならないので
確率論的にはソースコードの量が増えてしまうことになる。
|
- 次世代言語18 Go Rust Elixir Kotlin TypeScript
789 ：デフォルトの名無しさん[sage]：2020/03/27(金) 12:14:59.14 ID:VaiYZBCN - >>788
さらにいえば、Rustでは、型を明示する場合は、
let a:TYPE = xxx; // (1), TYPE は xxx の型
と書くが、:TYPE を省略して、
let a = xxx; // (2)
のようにもaの型を書くと自動推論する機能を持っている。
C++にもあるバージョンから auto などでこれと同様の機能が入って、
一見便利だが、型がわかりにくくて問題にある可能性がある。
逆に、C++ だと型を明示する場合には、
TYPE a = xxx; // (3)
と(1)に比べて短く書けることも重要。
Rustだと:TYPEを書くのが面倒なために、(2)ように省略してしまう
人が続出する可能性がある。
これは問題だ。
|
- 次世代言語18 Go Rust Elixir Kotlin TypeScript
790 ：デフォルトの名無しさん[sage]：2020/03/27(金) 12:15:48.45 ID:VaiYZBCN - >>789
誤：のようにもaの型を書くと自動推論する機能を持っている。
正：のように型を自動推論する機能を持っている。
|
- 次世代言語18 Go Rust Elixir Kotlin TypeScript
794 ：デフォルトの名無しさん[sage]：2020/03/27(金) 12:27:10.00 ID:VaiYZBCN - 大手が採用したとかで一見目立っているが、Google Trends で見る限り
極度の低空飛行で、人気は横ばいよりも下がり気味だ。
|
- 次世代言語18 Go Rust Elixir Kotlin TypeScript
795 ：デフォルトの名無しさん[sage]：2020/03/27(金) 12:33:25.16 ID:VaiYZBCN - Rustは、去年の7月辺りをピークとして人気が下がってきている。
|
- 次世代言語18 Go Rust Elixir Kotlin TypeScript
796 ：デフォルトの名無しさん[sage]：2020/03/27(金) 12:36:17.11 ID:VaiYZBCN - >>791
非難する人を「古い人」扱いすれば切り抜けられると思ったら大間違いだ。
|
- 次世代言語18 Go Rust Elixir Kotlin TypeScript
797 ：デフォルトの名無しさん[sage]：2020/03/27(金) 12:39:35.97 ID:VaiYZBCN - >>784
しかし、C++ の場合、new の働きは明確なのに対し、
Rustは、Box::new のコードを見ても、「box」という組み込みキーワードを
使ってしまっているのでそれ以上追う事は出来ず、曖昧さが残る。
C++の場合は、少なくともC++98までだとかなり原始的なレベルまで
やっていることが明確だった。C++11あたりから異常になったが。
|
- 次世代言語18 Go Rust Elixir Kotlin TypeScript
800 ：デフォルトの名無しさん[sage]：2020/03/27(金) 13:07:03.48 ID:VaiYZBCN - >>799
C++が使いこなせる程度の適正があるプログラマにとっては、タイプ量の増加
は苦痛以外の何者でもない。
彼らは特にC++でバグに悩まされたりしてるわけじゃないのだから。
|
- 次世代言語18 Go Rust Elixir Kotlin TypeScript
803 ：デフォルトの名無しさん[sage]：2020/03/27(金) 14:09:16.05 ID:VaiYZBCN - タイプ量はとても大事だ。
頭が賢ければ、タイプする体力と時間が不要なのだよ。
頭が悪い人は、体力と時間で勝負するしかないからタイプ量が多い言語を使うしかない。
|
- 次世代言語18 Go Rust Elixir Kotlin TypeScript
805 ：デフォルトの名無しさん[]：2020/03/27(金) 14:42:32.41 ID:VaiYZBCN - let a:i32 = x;
と
int a = x;
なら、後者は短いのに分かり易い。コンパイラに伝達される情報は同じだし。
|
- 次世代言語18 Go Rust Elixir Kotlin TypeScript
806 ：デフォルトの名無しさん[sage]：2020/03/27(金) 14:54:06.18 ID:VaiYZBCN - Rustで、
let a = x; //(1)
と
let a:i32 = x; //(2)
なら、そもそもコンパイラに伝わる情報が違い、後者は記述量が多くてもバグの少ないプログラミングに役立つ。
後から読み直しても a を i32 型にしたいプログラマの意図が分かって分かり易い。
だから、記述量が増えても後者は良い面を持つ。
ところが、Cで
int a = x; //(3)
と書けば、Rustの(2)と全く同じ情報がコンパイラに伝わり、エラーチェックのレベルも同程度だから、
Cは、少ない記述量で同じ事ができると言える。
(1)と(2)の違いと、(2)と(3)の違いを混同してはならない。
前者は記述量が多くなっても安全性向上という意味で意味が有るのに対し、後者は、書くのが長くなるだけで全く意味が無いのだから。
|
- 次世代言語18 Go Rust Elixir Kotlin TypeScript
809 ：デフォルトの名無しさん[sage]：2020/03/27(金) 15:11:19.11 ID:VaiYZBCN - 型推論することで安全性が駄目になるから、Cでは型を明示して宣言するようになったんだ。
その哲学を壊す言語が増えてきているだけ。
|
- 次世代言語18 Go Rust Elixir Kotlin TypeScript
814 ：デフォルトの名無しさん[sage]：2020/03/27(金) 15:42:26.54 ID:VaiYZBCN - >>808
型推論は、C++は template が深くて複雑すぎて、templateを使っているときに、
人間側が結果や変数の本当の型が分からなくなってきたので、しょうがなく
最近になって導入された。
もしこれをちゃんと手で書くと複雑で長い型になり過ぎる。
templateはソースがあるが読んでも複雑すぎて多くのC++プログラマには型が分からない。
また、templateはRADのような簡単に機能を使いたいときに使えるように設計された
ものなのに、型が難しすぎてわからないということは本末転倒であった。
そのためにしょうがなく型推論できる機能がC++に導入された。
|
- 次世代言語18 Go Rust Elixir Kotlin TypeScript
815 ：デフォルトの名無しさん[sage]：2020/03/27(金) 15:44:18.61 ID:VaiYZBCN - >>810
型を打つこと自体は良いんだ。
>>806 を読むべし。
|
- 次世代言語18 Go Rust Elixir Kotlin TypeScript
816 ：デフォルトの名無しさん[sage]：2020/03/27(金) 15:46:21.71 ID:VaiYZBCN - >>812
そうじゃない。
nullable指定を明示的に行うことは良いと思うが、
nullを絶対悪として、NullObjectとPolymorphismで対応することで
nullを完全排除しようとしている一部の人に対して反論していただけだ。
|
- 次世代言語18 Go Rust Elixir Kotlin TypeScript
819 ：デフォルトの名無しさん[sage]：2020/03/27(金) 16:00:21.15 ID:VaiYZBCN - >>818
違う。C/C++では、
long int a = 1;
とも書けるが、typedefやusingなどを使えば、
i64 a = 1;
と非常に古くから書ける。
|
- Rust part8
305 ：デフォルトの名無しさん[sage]：2020/03/27(金) 18:57:46.96 ID:VaiYZBCN - >>304
そういう考えだから、人を馬鹿にするんだな。
ちょこっといじっただけの癖に全体を自分が造ったみたいな態度をとる。
|