[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2ch.scのread.cgiへ]
Update time : 08/09 11:00 / Filesize : 267 KB / Number-of Response : 1050
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

TypeScript part3



1 名前:デフォルトの名無しさん [2018/04/26(木) 21:48:23.07 ID:mMDBzDaB.net]
www.typescriptlang.org/

JavaScript that scales.
TypeScript is a typed superset of JavaScript that compiles to plain JavaScript.
Any browser. Any host. Any OS. Open Source.

part1
https://peace.5ch.net/test/read.cgi/tech/1349187527/
part2
https://mevius.5ch.net/test/read.cgi/tech/1430386649/

570 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 00:24:04.47 ID:n4TOsjKe.net]
Pythonは 機械学習関連のライブラリが充実していて 最強の地位は10年後も20年後もおそらく変わらないだろう とプログラミングに詳しい知り合いが言ってました。 マシンスペックも上がってきているので Python のようなスクリプト言語でも 十分に実行速度が発揮でき益々 需要が伸びる可能性が高いと聞きましたが。

571 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 00:25:02.84 ID:vIhtxp0O.net]
>>547
mypyというものがあってだな

572 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 00:34:52.32 ID:y3zg5lZo.net]
スレチ

573 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 00:49:43.03 ID:rXA2CZZq.net]
>>551
ならその知り合いに聞けよ。ただそいつはヘボだと思うが。

Pythonが強いのはライブラリが揃っているからだが、今のところ実行速度が致命的に遅い。
それはCPUやGPUの性能向上程度では何ともならない。
機械学習なら結局のところは何回回せるかが勝負で、C比80-800倍遅いのだから話にならない。
だからCythonなんて物も出てくる。

ただしアルゴリズムを頻繁に書き換えるとなると違う。
ちゃっちゃと書き換え、夜流して朝結果を回収、夕方までにプログラムを変更してまた夜流す、
という繰り返しなら、「新しいプログラムがいつ出来るか」が勝負となり、当然スクリプト言語の方が有利だ。
ただ、これが出来る学生なんてなかなかいないと思うし、そこまで行くのなら多分Cも普通に使える。
そもそも機械学習ならそんなにアルゴリズムも変えないはずだし。

だから今でもガチの計算機工学科ではCもやってるだろ。
Cだと1時間で結果が出るのにPythonだと3日かかります、では研究の進捗も全然違ってしまう。
だから用途に合わせて使い分けることが必要で、
はっきり言ってCも大して難しくもないからそういう奴等はCを最初から学ぶようになってる。

PythonやRuby界隈が高速化を目指さないのは俺には完全に疑問だ。
何だかんだで今後とも速度は重要であり、正義だ。
Rubyなんて死にかかってるが、JSと同程度の速度が得られれば、復活するとも思っている。
ただ、Matzもその周りもそれをしようとしないんだな。クソ言語なんてもう要らないのに。

TSはその点、JSの実行速度と、スクリプト言語の弱点、
「調子乗って書いてたらグダグダになってきてヤバイっす」を型付加により多少は緩和出来る、という点でかなり立ち位置はいい。
しかもJSも今のところ死ぬ感じはないから、TSも勿論死なない。
一般的にはJSerは次第にTSerになっていくと見られているが、これも概ね正しいだろう。
確かにTSは駄目な点がない。
(界隈の駄目な点をJSからモロに受け継いでいるが)

574 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 00:50:50.85 ID:vIhtxp0O.net]
型無し糞言語は死あるのみ
型推論でスマートに型サポートを受けるのが今のトレンドだよ

575 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 01:01:08.81 ID:sfgrEAk/.net]
質問ですが
interface IPoint {
 x: number;
 y: number;
}
があるとして、(例えば)一致判定関数を書く場合、
function isequal(p1: IPoint, p2: IPoint) { return (p1.x == p2.y && p1.y == y2.y); }
function isequal<T extends IPoint>(p1: T, p2: T) { return (p1.x == p2.y && p1.y == y2.y); }
はどっちが良いの?
どっちもプロパティー{ x: number, y: number }を持つ任意のオブジェクトを受け入れるので同等に見えまつ、

576 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 01:02:20.20 ID:sfgrEAk/.net]
戻り値を忘れたorz
: boolean

型推論って便利ですよね、、、

577 名前:539 mailto:sage [2020/10/11(日) 01:27:53.11 ID:B+MSoWxK.net]
YouTube で有名な雑食系エンジニア・KENTA は、
初心者が進む道を、サーバー側言語のRuby → Go を王道としてる

Python, PHP, JavaScript などを絶対に言わない

初心者のfirst choice としては難しすぎる。
挫折確率が高すぎる

ただ年末に、Ruby 3.0 で型推論が入るから、
KENTA も、この方針を変えるかも知れない

大事件勃発!
Ruby on Rails に頼っている、すべての学校の方針が変わってしまう

ただ、first choice がGo と言うのは、絶対に無理

578 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 01:46:46.27 ID:+wOaiLh4.net]
>>556
この場合は多分同等なのでシンプルな前者で良い
後者はTを他の箇所(戻り値やコールバック関数の引数など)でも使う場合に適していることがある
例えば
function double<T extends IPoint>(p: T): T {
p.x *= 2;
p.y *= 2;
return p;
}
とか
function check<T extends IPoint>(p: T, validator: (p: T) => boolean): void {
if (!validator(p)) { throw new Error('...'); }
}
とか
ただしこれらの場合でも必ずしもextendsが適しているとは限らないので注意(特に上の例はかなり適当なので)



579 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 06:43:46.76 ID:vDn4Pmub.net]
Pythonは型を書いてもインタプリタがそれを無視して実行してくれる
高速に実行したければPyPy使えばネイティブコードに近い速度で実行出来るしmypyで型チェックも出来る
JavaScriptで型を書くと単に構文エラーになるだけだが、その内無視して実行してくれる様になるだろう
そうなったらTypeScriptは要らなくなる

580 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 07:10:15.21 ID:qONvW7Si.net]
妄想おつ

581 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 07:22:42.40 ID:vDn4Pmub.net]
Pythonみたいに動的型言語に型アノテーションを追加する事が主流になるだろう
Union型は動的型だから出来る事で、完全に静的型にするとC++みたいになってしまう
動的型+型アノテーションは良いとこ取りで、プロから初心者まで皆が満足出来る

582 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 07:34:29.67 ID:6reX+khV.net]
Pythonは10年前にやったときは凄い言語機能だと思ったけど、それからあんまり進化しなくて今はJSにすら言語機能的には劣ってる。Pythonの良いとこ他の言語も取り込んじゃったからね。
でもそれとライブラリが充実してるってのは別問題で、このライブラリの充実っぷりがJS|TSにもあったら天下取れるのになぁと思う。
機械学習はライブラリの最適化がキモで言語の速度なんてほとんど関係ないし

583 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 08:43:37.68 ID:AhI6YFfN.net]
なんどもコードの書き換えが必要な機械学習において
Pythonのような可読性にすぐれ、少ないコードで実行できる言語はが必要不可欠なのよ。
Cythonを使えば実行速度もC/C++と変わらないしね。
JavaScriptはTypeScriptとして生き残ると思われる。

584 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 08:44:44.80 ID:AhI6YFfN.net]
>>558
そのYouTubeはPythonとJavaScriptで作られているという皮肉

585 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 08:59:02.53 ID:rXA2CZZq.net]
>>562
最近の初心者がすぐ「俺がやってる言語スゲー、俺スゲー」なポジショントークに走る理由が分からん。
Pythonが良かろうが悪かろうが、お前の実績でもなかろうに。
結局のところ、「○○言語スゲー」をやってる奴は、「他言語なんて絶対学びたくないマン」であって、
それを正当化する為に言い訳をしているようにしか見えん。
それは549の「知り合い」も同じ。

ただ>>556が典型的な「型の問題点」で、
規模的に「見りゃ分かるだろ」な場合でも、型あり言語は型を書くことを強制され、
結果的に煩雑なコードになってしまっていた。
それ、JSで
function isEqualPoint(p1,p2) { return (p1.x === p2.x && p1.y === p2.y); }
だったら、悩む必要もなく、その先にさっさと進めてただろ、という話。(※)
普通の頭してたらこれで十分だ。

ちなみに(メソッドではない関数で)isEqualは短すぎ。
isEqualPointはお前らが大嫌いなハンガリアンだが、どう見てもPointを受け取る前提で、そうじゃなきゃエラーだと分かる。
それを型を書いてコンパイラにやらせるのがTSで、目で見て落とすのがハンガリアン。
ただ、コードの精度を上げたいなら併用すべきで、
形無しのisEqualというのは.NETみたいにisEqualインタフェースを全部の型に対して供給し、
isEqualを持っている型はこれ使えます、てな事をやるために使う。
ただこれは.NETは世界の全てがOOP前提だから出来るのであって、JS界隈ではかなり無理。

そしてそれ以前に、isEqualはPointのメソッドとして実装すべき。
メソッドであればそもそもPoint以外を与えようがなくなるし、見た目もハンガリアン同様にエラーを検出出来る。
そしてインタフェースへの拡張も見えてくる。
どうしても野良関数にしたければ、ハンガリアンにしておく方が無難だと思うが。

なおOOPの問題点は根本的にここら辺で、
この程度のどうでもいい規模しか書けない初心者にも無駄にいちいち考えることを強いて手を止めてしまう。
このレベルならグダグダ言わずに何とでも書いてどんどん先に進んだ方がいい。
どうせ今書いてるコードなんてゴミで、後から使える事はない。

586 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 08:59:27.04 ID:rXA2CZZq.net]
少し遠回りしたが話を※の時点に戻すと、
だから「全部について型を書け」というのは少々煩雑で、型あり言語は型推論で

587 名前:型を書かなくて良い方向に動いてる。
逆に、形無し言語は型をアノテートすることで、コンパイル時に落とせる方向に動いてる。
結果的に、どっちも同じような状況になりつつある。
落としどころは多分、C#の「ローカルは型推論、それ以外は型を書け」がまあ妥当なラインなのだろう。
だから初心者でこの辺の塩梅が分からないのなら、C#から入るのもありだと思うけど。
現実的にバランスが取れた仕様にはなってる。


>>563
JSが取り込んだPythonの良い所って何?
そんなの初耳だが。
そもそもPythonが褒められてる点なんてマジで何一つないと思うが。
(ただし俺は10年も使ってないので歴史的経緯はほぼ知らんが)

JS|TSが天下を取る為に必要なのは「同期」だよ。
asyncとかじゃなくて、普通の「同期」の方が分かりやすいし、実際スクリプト言語が担当する分野ではほぼそれでいい。
c10k問題等には非同期が有利なのは事実だが、見た目の分かり易さは「同期」の方が断然いい。
「それ、同期だったらそもそも理解する必要すらなくて、上から順に実行される、で済みますよね?」が多すぎる。
ただ、「非同期」は最早宗教だから、「同期」を入れることはないのだろうけどね。

「同期」が入れば、CPUリソースが厳しいサーバ側のPHP/Ruby/(ほぼいないが)Pythonの半分ほどはNodeに移行するだろう。
(実際、Goがその界隈で流行ってるのも、大した手間をかけずに快速が得られるからであって)
また、普通のスクリプト業務、つまりPythonが蔓延っている分野でも、
Python同様に簡単に書け、速度は16倍なのだから、当然普段使いする奴が出てくる。(というか俺がそれ欲しい)
そうすれば、ライブラリも充実していく。
「同期」がないから普段使いしにくいのがとにかく問題。

逆にPythonは実行速度が問題で、現実的な文句はほぼこれに尽きる。
だから彼等が何故高速化を目指さないのかは俺には本当に謎。
[]
[ここ壊れてます]

588 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 09:13:49.37 ID:/RVlCgv+.net]
このおっさん長文書く割に知識浅いな



589 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 09:15:26.14 ID:xz6PduLx.net]
>>565
あれPythonで作られてるから進化が遅いんだぞ
外向きにはPythonで問題ないって強弁してるが完全に負債化しちゃってる

Pythonで作ったWebサービスあるある

590 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 09:29:24.51 ID:AhI6YFfN.net]
時代についていけない老害エンジニアがC/C++を必死に推してるように思うのだが

591 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 09:29:47.66 ID:vIhtxp0O.net]
>>568
浅いというか個人 or 小規模開発しかしたことなさそう

592 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 09:36:16.20 ID:AhI6YFfN.net]
Pythonの速度が遅いと言ってるのは情弱
Cで書いたライブラリに受け渡せばC言語の速度で実行できるし
Cython使えばPythonのコードほぼそのままC言語の速度がでる
Pythonで困るのはGUIくらいだろ?

593 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 09:40:52.87 ID:sfgrEAk/.net]
継承とジェネリクスが役割が被る領域において
TypeScriptではどっちの書き方がメジャー(もしくは効率的)とされているのかわからなかったのです><!

>>559
レスdクス、
わかりた、

594 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 09:45:09.23 ID:sfgrEAk/.net]
次の質問なのですが、
タイプガードとか書くときにクラス(やハッシュ)にプロパティーが有るのか無いのか調べると思うのですが
つぎのどっちの書き方が良さげ?
 (1) 'someProperty' in foo
 (2) foo.someProperty != undefined

595 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 09:45:54.29 ID:sfgrEAk/.net]
なんとなく(2)の方が早いのではないか、という気がするのですが気のせい??

596 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 09:57:22.72 ID:rXA2CZZq.net]
>>572
俺もCのDLLをスクリプト言語から呼ぶ、というのが現実的な解だとは思う。
ただ、Pythonの問題はそこじゃない。

演算を変えたい場合は結局Cを書く羽目になるから、結局Cも出来ないと駄目。
そしてCは仕様が小さいので、本気で正しく学べば簡単な部類だ。
GUIは今は現実的にHTMLがダントツで良く、何から何までWebアプリ化してる。
なら今ならElectronの方が相性がいい。当然JS/TS。
サーバ用途でPython使ったら大体は速度の問題にブチ当たるが、
これは「お気楽に書ける分遅い」というスクリプト言語の特有の問題であり、Rubyも同様で、回避手段がない。
(Nodeはgoogleの努力で例外的に異常に速いだけ)

だからPythonは「何一ついいところはないが、何も悪くもない」という、ある意味「絶対的な2番手」だ。
だからこそ「絶対他言語を学びたくないマン」はこれに拘り、ポジショントークを繰り返す。

ただ、今時の言語なんてどれも似たようなもので、実際そこに拘る理由もなく、普通の奴は易々と言語の壁なんて飛び越えていく。
普通はこちらを目指すべきだと思うけど。
PHPもクソと言われて久しいが、いまだに蔓延っているのは、あの用途では絶対的に便利だから。
それはjQueryも同じ。

597 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 09:59:21.79 ID:vIhtxp0O.net]
>>574
無料相談所じゃねえんだぞ調子に乗るな
(2)にしろ
(1)は型の保証までしてないから最後の手段
あとinterfaceはライブラリなど汎用的なコードに使うもの、普段はtypeを使え

598 名前:572 mailto:sage [2020/10/11(日) 10:02:33.58 ID:sfgrEAk/.net]
ていうか自己解決しますた、
e: Event を e: MouseEvent として扱ってよいか(ダウンキャスト可能か)どうかを
確認するとき、(1)の書き方でないと
MouseEventにあってEventに無いプロパティー
(e.offsetXやe.offsetY())の有無の判定が書けませんぬ、



599 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 10:15:47.58 ID:AhI6YFfN.net]
>>576
機械学習の勉強してみ。演算やアルゴリズムなんて二の次 三の次だから。
とにかく何度もコードを書き換えてひたすらパラメーターと変数の調整作業になる。
言語の実行速度よりコードの記述速度の方が大事になる。
この時はじめて「Pythonさん。なめててごめんなさい」って言いたくなる。

600 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 10:30:46.60 ID:rXA2CZZq.net]
>>579
パラメータの変更しかしないのならそうだろうとしか。

俺は別にPythonを使うことが悪いとは言ってないぞ。
俺はJSを大変気に入っているが、それは「手抜きで書けるわりに速い」からだ。
だから俺はJSからCのDLLを呼びたいんだよ。
それがお前の場合はPythonなだけだろ。別に不思議でもないよ。

601 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 10:37:24.45 ID:AhI6YFfN.net]
>>580
PythonはCythonを使えば
ほぼPythonコードのままCのライブラリが作れるんだよ
速度はCで記述したものとほとんど変わらん

602 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 10:42:41.64 ID:rXA2CZZq.net]
>>574
それはJSでは議論し尽くされた質問。多分ググッた方がいい。

会社で書く場合は多分コーディングルールでどっちにするか決まってる。
プロパティのありなしのチェックだけなら(1)の方が原理的に速い。
ただしJSの場合はundefinedという値を設定出来るので、その場合は(1)も(2)もアウトだが。
これはJSの仕様バグだが、この辺含めてJSは厳密な型管理には向いてない。
そもそも型無しなので当然だが。


>>578
そもそもダウンキャストが必要となってる時点でOOP的には邪道。
多分それは無駄にアップキャストしてるから。
OOP初心者あるあるの、張り切って無駄にOOPして余計に複雑になってるケースだと思うよ。
それも含めて頑張れでしかないが。

603 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 10:52:20.91 ID:rXA2CZZq.net]
>>581
ならお前はPython/Cythonで一生暮らすでいいだろ。

俺はC使えるからCythonを使うことはないし、
Pythonも色々糞だからJSで

604 名前:マむところはJSで行く。
だからCscriptはそこそこ良かったのだが、MSはこれを捨ててPowerShellという別糞言語押しなのは残念。
[]
[ここ壊れてます]

605 名前:デフォルトの名無しさん [2020/10/11(日) 10:59:25.49 ID:kZXFoyze.net]
>>549
>俺はPythonやってないが、最近かじろうとして、止めた。
>String.replace(regexp)がなくて、RegExp(str)しかなく、ああこりゃ駄目だ、と思った。
>なるほどPythonではクソコードしか書けない、というのは納得だ。

馬鹿ですね判ります

606 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 11:08:21.39 ID:kZXFoyze.net]
>多分それは無駄にアップキャストしてるから。

型消去が必要な場面なんていくらでもあると思うが。
そもそもダウンキャストって動的な型判定でしかないんでOOPとは直交する概念だよな。

607 名前:576 mailto:sage [2020/10/11(日) 11:23:42.67 ID:sfgrEAk/.net]
自己解決しますた、2
e: EventのMoveEventへのダウンキャスト可能性判定は
 if (e instanceof MoveEvent) { ... }
で逝けるっぽい
こう書いたとき、VSCodeではブロックの中でe: MuseEventとしてのインテリセンスがばっちり利くスゲー;;

さらにいうと、
https://developer.mozilla.org/ja/docs/Web/API/Element/mousedown_event
の書き方をすると、addEventHandler()の宣言とラムダ式から型推論するらしく
イベントハンドラ内に入った時点で勝手にMouseEventとして扱われる(スゲー)^2

608 名前:576 mailto:sage [2020/10/11(日) 11:25:20.20 ID:sfgrEAk/.net]
>>582
>そもそもダウンキャストが必要となってる時点でOOP的には邪道。
HTML5とかを決めているmozilla.orgに言って、
ホスイ



609 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 11:26:44.35 ID:rXA2CZZq.net]
>>584
String.replaceとRegExp.exec(str)は明確に用途が異なる。
だからそのどちらを使ったかで何を目的にしてるかをコード上に残せる。
Pythonはそれが出来ないから糞、というだけ。

どうやらPython教の「そのやり方は一つであるべき」が根本的にある。
これが「数ある中からそれを選んだ、それを持って意図を残す」俺と決定的に合わない。
なおRubyも同様に「いろんなやり方があるべき」であり、Pythonはプログラミング言語の中ではかなり異端だと思う。
だからこそ受けている、というのはあるらしいが。

なおJS、String.search と Regexp.test 等、大体においてその状況では交換可能なメソッドは多々あるし、
Array.map/forEach/filter/reduceも、無理矢理やれば大体交換可能だ。
これについては俺は => はクロージャ無し、つまり外変数を掴めない仕様にするべきだったと思う。
そうすれば => で与えている限り「無理矢理交換」は出来なくなり、コードも読みやすくなるし、エラーも文法的に落とせた。

現状では「無理なことをしてないか目で確認」するしかなく、これは型アノテーションではどうにもならない。
だから目で落とすハンガリアンを馬鹿にしていて、でも => の仕様不備には全く文句を言わないのは、
同様にお前らも単なる馬鹿かポジショントークでしかないからだよ。
実際、 => で与える関数で外変数を掴まなければならないケースなんて半数以下だし、
その場合は function と長々と書く、でよかった。

610 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 11:37:03.05 ID:rXA2CZZq.net]
>>587
それはその通りだが、そもそもHTMLの仕様がOOP前提ではないので継承構造が綺麗になってない。
それを無理矢理それっぽく見せかけているのがHTMLElement(というかDOM)だが、
ちょこちょこ例外的なのがあって統一的に扱いきれない。
多分割と早い段階で無理だと諦めると思うよ。それも含めて頑張れだが。

mozallaが悪いわけではなく、OOP前提で作られてない物を載せ直そうとしてるから無理があるんだ。
なら不整合な古い仕様はばっさり切っていった方がいいと思うが、それは互換性の問題で切れないらしい。
だから、今後とも直ることもないよ。

611 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 11:39:39.85 ID:ZGWQTXgj.net]
>>572
PythonはOO機能が中途半端で型システムも貧弱だからアプリケーションのコアとなるドメインモデルの実装には使われない
Cythonでドメインロジック書くのはもっと非現実的

機械学習やデータ分析のようにコアとなる部分を汎用的にCでライブラリ化できるような用途には適してる

NetflixやUberのようなテクノロジ先進企業がアプリのコアからPython外して
機械学習を含むデータ分析系かシステム管理系に絞って使ってる理由

612 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 12:42:35.57 ID:6reX+khV.net]
>>588
外変数を掴まないArray関数?
センス無いなぁ。やっぱあんたOOPしかできないでしょ

613 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 12:57:09.09 ID:AhI6YFfN.net]
>>563
記述が簡単。ライブラリが充実。これが最強の所以だよ。
コードの学習コストと記述に時間がかからない分、他に時間をさける。
機械学習、データ分析、科学系でPythonの最強はしばらく続くだろう。
今話題のディープラーニングにおいてもPyTorchが最強の座に着こうとしている。
大企業が多額の資金を投入してね。

JavaScriptもネットでは必須なのでPythonと肩を並べる言語になるだろう。
この2つを極めたものだけが将来生き残れる。jabaは10年後には消えてるだろうな。

614 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 12:58:10.87 ID:AhI6YFfN.net]
Javaねw

615 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 13:01:56.22 ID:rXA2CZZq.net]
>>591
外変数を掴む前提ならreduceは全てforEachで代替出来る。
逆に言うと、わざわざreduceを入れたのは、見た目immutableにしたいだけ。(戻り値をconstで受けられる)
しかし現状では与えた関数が外変数を変更していない、という確証が「文法的には」ない。
つまり、「見て判断」するしかない。
この辺がハンガリアンを馬鹿にしているお前らが理解出来てないところだ。

=> がクロージャ無しなら、
const tmp = arr.reduce( => );
において、tmp以外の変数に変更がないことを文法的に保証出来た。
これをせずに、immutableだあ、型でエラーが落とせるだあ、なんて言ってる時点で意味ねえ、というだけ。
もっと効率的にエラーを落とせる仕様は有ったって事だよ。

616 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 13:11:49.27 ID:6reX+khV.net]
>>592
多分そのとおりなんだけどTS使いがPython使うとイライラするぜw
型情報もジェネリクスも貧弱だし、多少トリッキーでも短くて副作用のないコードを書くTS使いに対して、Python界隈は助長で副作用も使う簡易なコードを書く。
どっちが優れてるとは言わないけど。文化がかなり違うように感じる

617 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 13:22:19.94 ID:rXA2CZZq.net]
>>592
Javaが10年後に消えることは原理的にない。
Javaが使われているインフラとかは10年更新だが、そのまま問題ないとかで20年とかに伸びたりしてる。
そして更新時、Javaのままにするか、思い切って他言語(C++等)にするかが問われるわけだが、
今現在はJavaのまま更新されているのが普通だと思う。
だから10年後も「今更新している案件」が更新案件として出てくる。
これはガチで20年分ほど積み上がっているから、書くかどうかはともかく、読める必要は10年後も確実にある。

Pythonは今のところ「何でも出来る」という意味で安牌だが、速度が遅いのがとにかく致命的。
何度も言ってるが、俺はPython陣営がここに消極的な理由がさっぱり分からない。
原理的にはJSと同程度までは行けるはずで、そうなれば完全に天下を取れる。

対してJSは勝手に速くしてもらえただけの棚ぼたではあるが、
そもそもGUIのHTMLとダントツに相性が良く、(元々JS用だから当たり前だが)
非同期が超絶ウザイながらもデスクトップアプリケーションまでに進出してきた。
Pythonが遅いままなら、JSが「同期」を出したらPythonを普通に殺せると思う。
少なくとも、今現在の言語としての出来は、JSの方が数段上だ。
それも分かってか、Python使いはPythonの「言語として」良い点なんて絶対に挙げな

618 名前:いだろ。
ここでも無視されてる。実際、ないと思うし。
彼等にとっては使っている人数が多いこと自体が武器であり、それを目指しているからだ。
勿論これもありだが、Javaもそうだったが、これだとどうしても古くなっていく。
だから、仮にJavaが死ぬなら、同様に「古い」とされて死ぬのはPythonだろうね。
[]
[ここ壊れてます]



619 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 13:40:29.31 ID:kiEWpQjt.net]
>>595
30年前のレガシー言語と比べて言語機能的に優秀じゃなければ存在価値ないよね

PythonがTSに比べて優秀なのは今まで使われてきた歴史があるところ

620 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 13:42:20.42 ID:AhI6YFfN.net]
>>596
PythonはJavaScriptの”中途半端”な速度を切り捨てて自由を手にしたのだ。
そもそも、処理速度がネックになるなんて単純計算を繰り返す場合がほとんどで
そんなもんライブラリに任せればいいんだよ。Pythonを使ってるのはプログラマだけじゃない。
科学者、数学者など他業種も多い。記述の簡単さ。ライブラリという遺産。大企業の投資。
すべてがPython最強を示している。

GUIはJavaScriptに軍配があがる。これに異を唱える奴はいないだろ。
JavaScriptはWEBで棲み分けができていて最強言語の一つだ。
そんなにPythonを逆恨みする必要はないよ。

621 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 13:52:30.76 ID:AhI6YFfN.net]
>>597
言語の記述が簡潔。これが一番だな。
パソコンよりスマホ。FLASHよりYouTube。マニュアル車よりオートマ。
人間は楽な方にながれる生き物。

処理に時間のかかるものはライブラリになげてスクリプト言語で記述。
これがこれからの流れだと思う。生産性もあげていかないと。

622 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 13:57:45.46 ID:AhI6YFfN.net]
「ワシもCで苦労したんだから、お前ら若者も苦労せい」

こんな考えの老害が生産性を著しく低下させてる

623 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 14:21:59.35 ID:rXA2CZZq.net]
>>598
綺麗なだけのコードを書くことは実は簡単なんだよ。ただしそれは通常遅い。
だから処理系がそもそも速いって事がコードの美しさを保つ上でも重要ではある。
実際、Pythonから書き換えを迫られる場合はほぼ全て処理速度の問題だろ。

だから、
> 多少トリッキーでも短くて副作用のないコードを書くTS使いに対して、Python界隈は助長で副作用も使う簡易なコードを書く。 (>>595)
これの遠因もそこにある。トリッキーだが短いコードってのは通常、実行速度が遅い。
だからこれを許容出来るのは、速い処理系があるからこそ。
Pythonの場合はそもそも書けない可能性もあるが、書けたとしても遅いから使えない可能性もある。

トリッキーとは言わないが典型的なのは正規表現だ。
今現在正規表現は速いとは言えない状況で、「バックトラックを理解して速い正規表現を書く」という本末転倒なことをやらかしてるだろ。
あれも本来は「糞速い正規表現ルーチン」と「一番分かりやすい正規表現」で済むことでしかない。
ただ、今は現実的にそれが出来ないわけでさ。
同様に、正規表現で書けば至極単純なのを、indexOfやforとかで自前で探索してたりするのもそのため。
処理系の速さがコードの簡潔さ/美しさを下支えするものではあるんだよ。

だからつまり、「単純簡潔で分かりやすいが遅いコード」を許容する為には速度が不可欠で、
Pythonも速度対策すればこの辺が使えるようになって現実的な利用価値が上がるんだけどね。
それ以前に速度なんて考えてないコードばかりだから全体的に糞遅いのかもしれんが。


ただそれ以前に、JSもPythonと比べて難しい言語ではない。
Python界隈の戦略的には「Pythonこそ最易言語」であり、それ以外の意見は認められないのだろうけど、
いわゆるLL言語はどれもこれも簡単だし、大差ない。
JSにおいては「非同期」が無駄に嵌りポイントになってるから、
これさえなくなれば難易度はPythonよりもむしろ簡単になる。(文法が超絶簡素だし)
(ただし、無くなることはないとも思うが。非同期宗教酷すぎ)

624 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 14:40:59 ]
[ここ壊れてます]

625 名前:.26 ID:rXA2CZZq.net mailto: >>598
>>600
ちなみにお前は何か勘違いしているようだが、俺はPythonを嫌っているわけでもないし、Cを強いているわけでもない。
そもそも俺はCに苦労もしてない。そう思えるのは、お前がCに苦労しているからだ。

既に言ったが、俺がJSを気に入ってるのは、「手抜きの割には速いから」だ。
速く動かす為にはこう書いた方がいい、と分かっていても、面倒なのが大半で、
どうでもいいところから完全に手が抜けるからいいのだ。
だから「JS」というよりは「JSの処理系の速さ」が好きなのであって、逆にJSが遅くてPythonが速ければ、俺はPythonを使っていただろう。
その程度の話でしかない。
それとは別に、JSも言語的にはかなり面白いので気に入ってはいるが。

なおC、あれは難しいのではなくて、理解するのにPCの物理的構造の理解が不可欠なだけだ。
実はそれを知っている奴は最初からつまずかない。
そして仕様はJSやPythonよりも単純な為、覚える範囲だけなら多分1週間もあれば例のK&Rは読めてしまう。
似ているのは物理で、ma=Fが全ての力学も、最初から理解して使いこなせる奴と、1年経っても全然理解出来ない奴と綺麗に別れたろ。
あれは理解力/思考力の問題だが、とにかく、「理解出来る奴は最初から苦労もせずに理解出来てしまう」というのはCと同じ。

君はCがとても難しくて、若者がPythonしか使えず、Pythonしか使えない自分が置き去りにされない世界を望んでいるのだろうけど、
それはない。
Cは他言語と比べたら「ドハマリする奴は絶対に抜け出せない」だけで、仕様としてはかなり簡単な言語だ。
そして計算機工学なら普通に授業してるし、実際、彼等は普通に使えていると思うよ。
ただ、データサイエンティストみたいな、計算機を使うことが主目的ではなく、単純に計算だけしたい奴等はまずはPythonからだろうさ。
そこもしばらくは変わらないとは思う。
Python使えば生産性が高いと思ってるのはお前が馬鹿なだけ。
生産性が高い奴は、その時々に応じて最適の手法を選択するだけ。
それがPythonならそうだろうし、どうせ速度が問題になると分かり切っているのなら最初からCもありだろうさ。
[]
[ここ壊れてます]

626 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 14:50:27.97 ID:wajrVZJ7.net]
このクソ冗長な駄文書く奴が簡潔なコード書けると思うかい?

627 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 14:54:59.49 ID:xjaVw/rp.net]
無理だなw

628 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 15:00:02.75 ID:AhI6YFfN.net]
要約するとPythonが憎いってことかw



629 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 15:06:05.60 ID:dKH8Tkfs.net]
どうでもいいがいい加減スレチ

630 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 15:45:06.69 ID:eAcRpNge.net]
>>603
ありえないよね

631 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 15:57:00.97 ID:N5blIWED.net]
長文書きたいなら別サービスいきゃいいのにw

632 名前:デフォルトの名無しさん [2020/10/11(日) 17:55:24.83 ID:n5rbjmiV.net]
せっかく丁寧に説明したのに今の若者は長文が読めないとかキレ出すのに1票

633 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 18:12:49.10 ID:rXA2CZZq.net]
>>605
お前はCが出来る奴が憎くて憎くて仕方ないのは分かった。

ただ、何度も言ってるが、Cも大して難しくはない。
昔だったらプログラミングなんてしなかった馬鹿連中も最近はプログラミングするようになってきてるから、
大勢の比較的馬鹿から見たら同じ物が難しく見えるだけ。

当たり前だがCなんて昔から変わって無いし、(というか変わらな過ぎだが)
今はIDEのサポートもありネットでも情報を探せるから、昔よりは断然簡単に学べる。
同じ理系学科で比較すれば、脱落率は劇的に改善しているはずだよ。
そもそも昔は1人1台PCでもなく、家で予習/復習すら出来なかったわけでさ。
F12押せばIDEモドキがいきなり出てくる今とは全然違う。

634 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 18:38:20.01 ID:6reX+khV.net]
Cの仕様は確かに小さいよ、しかしだからといって小さいイコール簡単な世界じゃない。
メモリパズルしたりガチで

635 名前:立つマクロ組んだりSIMDで最適化したり未定義動作と戦ったりしてみると良いよ []
[ここ壊れてます]

636 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 18:47:48.52 ID:lHUSyjod.net]
いい加減にしろ。

637 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 18:57:19.02 ID:iumhQK0o.net]
マロックできないやつがおりゅってマ?ww

638 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 19:25:10.03 ID:rXA2CZZq.net]
>>611
未定義動作以外はもちろんやってるぞ。

ただJSでもTypedArrayは導入されたし、メモリパズルや最適化はCだけの話でも無いけど。
むしろそれをやる気がなければ最高速は目指せない。
numjsとか使ってる奴はJS/TSでそれやってると思うよ。

あと、お前もそうだが、最近の若い奴は使いこなす=全機能を使う、と勘違いしている。
Cのマクロなんて深入りしたら余計に生産性が落ちる。あれはぱっと見て分かる範囲で使うべき物。

プログラミング言語なんてアプリを作る道具であって、道具を使い倒すのが目的ではない。
分かる範囲で使い、希望の動作をするアプリが出来るのなら、それでいい。
全く使って無い機能があったとしても、関係ない。



639 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 19:27:09.39 ID:6reX+khV.net]
別にここTSスレなんだからmallocできん奴おってもええやろ。今は細分化の時代だし。

640 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 20:54:24.48 ID:rXA2CZZq.net]
>>611
613読んで気づいたが、別人であったか。

Cにはもうこりごりなら、それもいいと思うけどね。
一応Nodeからffi経由でCのDLLは呼べるらしい。
それなりにオーバーヘッドはあるらしいけども、普通に使ってる分にはほぼ誤差だと思われる。
JSの数値はdouble相当だし、一応32bitのビット演算もあるし、
環境自体がそこそこ速いから、事前準備はJS側でやっても大して問題ないだろう。
単発の演算でオーバーヘッドがでかいのは問題だから、そこを何とかできれば、
科学技術計算からPythonを駆逐できる可能性がある。
ただ、PythonのCのDLLコールも同様にそれなりに遅いらしいので、マーシャリングであればどうにもならないけどね。

641 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 21:21:39.97 ID:CIdPEDg5.net]
>>602
>C、あれは難しいのではなくて、理解するのにPCの物理的構造の理解が不可欠なだけだ

PCの物理的構造とやらが理解できたところで void (*signal(int sig, void (*func)(int)))(int) なんて宣言を読めるようになるとはとても思えないんだが

642 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 21:58:54.02 ID:rXA2CZZq.net]
>>617
それは慣れだね。
ただ、俺もあの文法はかなり謎で、正直、仕様がよくないと思う。
それはカーニハンも文句言われてて、言い訳は多分ググッたらヒットする。
確か、曰く、この形式ならマクロにしても入れ子でも動く、らしいが、
俺が試した限りはGoみたいな分かりやすい形式でも普通に出来た。

ただ、それ以前に実は当時のCでは関数ポインタをそんなに使わなかった。
正確に言うと、sortとかでは必要とされていたが、単発で使う分には呪文扱いでよく、
勿論熟練者はそれでも使ってたのだろうけど、今ほどカジュアルには使われてなかった。
K&Rでも、「関数ポインタも出来るよ」とさらっと触れられている程度でしかない。

それがJavaで関数ポインタが存在しなかった理由だし、
C#でも最初は採用されなかった理由だ。(C#は確か2,.0から)
当時はOOPで全て行ける、継承すれば関数ポインタを直接扱う必要も無い、と思われていた。(のだと思う)

ただその後、おそらくJSのブレークにより、クロージャ/ラムダの有用性がプログラミング界隈で認識された。
勿論Lisperはそれ以前からずっと呟いていたのだろうが、今も昔もLisperなんて空気だ。
そしてあまりにも感化された連中がClosure言語をリリースする始末。

だから、今のC初心者がいきなり関数ポインタを使おうとしているのなら、
それは確かに昔のC初心者より難しいことをやってる。
ただそれは呪文扱いで

643 名前:「いと思うよ。
自分が望むアプリを作ることが目的であって、呪文使いになることが目的ではない。

まあ確かに、ここ20年でプログラミング回りもだいぶ変わったから、
C言語自体は確かに変わって無いけども、学ぶべきことが明らかに増えてるのは事実だ。
関数ポインタも、OOPも、クロージャも、並列も、昔の学生には必要なかったから。
[]
[ここ壊れてます]

644 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 22:21:00.46 ID:6reX+khV.net]
思ったよりは詳しいみたいだし、その長文書くエネルギーでTypeScriptもっと使い込んで?
批判するならその上で批判して。ここTSスレだから。
使うまでも無いとか技術者らしからぬ事言わないでね。

645 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 22:30:53.12 ID:KPje/k62.net]
長い、3行で

646 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 22:42:52.59 ID:rXA2CZZq.net]
>>619
TSについては、今のところ使う予定無いからね。
理由は既に言ったとおり、「スモークテストまでだけの為に記述が増えすぎ」だから。

ただTSは確かに立ち位置は悪くない。
型のおいしいところだけつまみ食いしよう、という意図が明確でいい。
そもそも使って無いから細かい粗も知らんし、批判しようも無い。
JSが糞な点は多々あるけど、それはTSでどうにかなるものでも無いし。

647 名前:デフォルトの名無しさん mailto:sage [2020/10/11(日) 23:10:58.87 ID:pHYX9F42.net]
>>618
>C#でも最初は採用されなかった理由だ。(C#は確か2,.0から)

Delegateは1.0からあるよ

648 名前:デフォルトの名無しさん mailto:sage [2020/10/12(月) 02:32:07.80 ID:ay8eu3sV.net]
スレチは3行もいらん



649 名前:デフォルトの名無しさん mailto:sage [2020/10/12(月) 06:56:35.72 ID:MB2VBDRV.net]
>>622
確認してみたがどうやらそのようだ。
なんだかんだでC#はマトモだな。

650 名前:デフォルトの名無しさん [2020/10/12(月) 08:01:12.80 ID:D7FMyxf4.net]
実際のところ、皆さんtsを仕事で使ってたりするの?

651 名前:デフォルトの名無しさん mailto:sage [2020/10/12(月) 08:49:35.94 ID:sR+xz/oc.net]
うん

652 名前:デフォルトの名無しさん mailto:sage [2020/10/12(月) 08:51:37.03 ID:wrjLnlZW.net]
使ってるよ。
元々JS使いだから最初は型と戦ってばかりで時間かかって生産性下がって辛かったけど、慣れればむしろ早いし、リリースした後の安心感が段違い。
小規模開発でもこれだから規模が大きいとさらに影響は大きいだろうね

653 名前:デフォルトの名無しさん mailto:sage [2020/10/12(月) 08:55:55.53 ID:g334XhqZ.net]
フロントエンドエンジニアやってるけど、React + TypeScriptが鉄板過ぎる
これ以外でUI組む気になれん

654 名前:デフォルトの名無しさん [2020/10/12(月) 10:31:14.01 ID:lIqFO5mi.net]
サーバーサイドでも使ってる人いるのかな
typescriptとサーバーサイドでググると
サーバーサイドでもtypescript 最高たぜ〜みたいな記事出てくるけどほんまかいなと。

Java,や.NET使った上でそう判断してる現場もあるんだろうか。
いま.NETしか経験がないメンバーにtsを習得させるか、思い切ってBlazorに手を出しちゃうか悩み中。

655 名前:デフォルトの名無しさん [2020/10/12(月) 10:41:40.32 ID:pl0L2hmu.net]
鯖サイドってOSコロコロ変わるイメージ無いんだけど、JVMにしろ.netにしろVMで動かす意味ってあるの?
GoとかRustで良いんじゃ無いかって思うんだが。

656 名前:デフォルトの名無しさん mailto:sage [2020/10/12(月) 10:56:21.63 ID:sR+xz/oc.net]
>>629
.NET Core使っとけ

657 名前:デフォルトの名無しさん mailto:sage [2020/10/12(月) 11:29:41.17 ID:CsRHImZw.net]
Ruby on Rails では、Bootstrap, React だけど、
JavaScript(JS) に、Ruby の式を埋め込む、ERB を使って、JSへ変換する。
a.js.erb

<%= Rubyの式 %>

$( "body" ).append( "<%= j(render partial: 'example_partial') %>" );

こういう書き方で、TypeScript を使えるかな?

658 名前:デフォルトの名無しさん mailto:sage [2020/10/12(月) 11:39:26.90 ID:tosLr/AM.net]
>>630
むしろVM使ってるかどうかで言語を選択するケースのほうが稀



659 名前:デフォルトの名無しさん mailto:sage [2020/10/12(月) 11:47:16.30 ID:wrjLnlZW.net]
>>629
TSに手を出すのとBlazorに手を出すのでは冒険度合いが違いすぎない?

660 名前:デフォルトの名無しさん [2020/10/12(月) 12:34:06.06 ID:lIqFO5mi.net]
>>634
だよね…
こんなところで聞くことじゃないかもしれないんだけど、
サーバーサイドに記述されてるクラスって、フロントでも使えるの?
それともフロント側でもtypescriptで同じクラスを宣言しないといけない?
Blazorはクラスを共有できるくさくて…それはメリットとしてかなりでかいなあと。

661 名前:デフォルトの名無しさん mailto:sage [2020/10/12(月) 12:38:53.86 ID:gBcZoQLz.net]
>>630
サーバーは言語何を使うとしても仮想化前提だろ。

662 名前:デフォルトの名無しさん mailto:sage [2020/10/12(月) 12:49:06.93 ID:wrjLnlZW.net]
>>635
同じ言語だからクラス書いたファイルを両方から参照すれば良くない?
そういう意味でなくてサーバとクライアントでシームレスにインスタンスをやり取りしたいとかであればフレームワークが居るのでは?

663 名前:デフォルトの名無しさん mailto:sage [2020/10/12(月) 13:00:28.44 ID:tosLr/AM.net]
>>635
両方同じ言語なら共有ライブラリとしてそれぞれから参照すればいいけど
言語が違ってもOpenAPIみたいの使ってコード生成すればいいから
2度手打ちする必要はないかも

664 名前:633 [2020/10/12(月) 13:15:11.55 ID:lIqFO5mi.net]
ごめんごめん
サーバーサイドはasp.net coreです
OpenApiとやらを使えば、クラスの生成が楽ちんてことね…
しかし二度手間感はすごいあるな…
でもBlazorに手を出すリスクを考えるとまだマシか…

665 名前:デフォルトの名無しさん mailto:sage [2020/10/12(月) 13:38:59.49 ID:sR+xz/oc.net]
Blazorも使ってるけど、まだ.NET5対応のツール周りが全然だめなんだよね…業務なら素直にTypeScriptでいいと思うよ

666 名前:デフォルトの名無しさん mailto:sage [2020/10/12(月) 15:15:45.91 ID:1F5XaUKJ.net]
over knight blazorくらいになってからが本番。

667 名前:デフォルトの名無しさん [2020/10/12(月) 15:31:28.54 ID:TNFvs/DR.net]
>>633,636
だよね。
なのに何でJavaとC#何だろ?って思った。

668 名前:デフォルトの名無しさん [2020/10/12(月) 15:34:05.12 ID:TNFvs/DR.net]
>>636
特に仮想化前提で遅くなるのに何で言語をネイティブコンパイラ言語にしないんだろ?と。
昔は実質C++しか無かったなら仕方ないとして、今なら選択肢はもっとあるのに・・・。



669 名前:デフォルトの名無しさん mailto:sage [2020/10/12(月) 15:46:11.22 ID:YFC4n48A.net]
Goのコードは高機能でファットなランタイムに依存している
ランタイムとアプリを分離できないだけで、実質VM言語みたいなものだ
一方、.NET Coreはアプリとランタイムを実行ファイルに全部ぶっこんで配布することも可能
従来のVM言語という線引きは曖昧になりつつある

670 名前:デフォルトの名無しさん mailto:sage [2020/10/12(月) 16:22:11.38 ID:DGsDArLw.net]
C#だとジェネリクス関連はJITに任せたほうが速かったりできるし、
.NET CoreはReady to Runでネイティブコンパイルされたコードを同梱することもできるぞ。






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<267KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef