TypeScript（MS） VS Swift（Apple）

**デフォルトの名無しさん** · 2014/06/03(火) 10:20:03.13

まあ、どちらもタイプセーフJavaScriptという
似たような言語なんだから仲良くしろや。

**デフォルトの名無しさん** · 2014/07/03(木) 01:56:26.86

>>153 　Earth　ベンチマーク
Emscripten 8.6秒　0スレッド（スレッド指定不可）
PNaCl 　　0スレッド　2.5秒　　8スレッド　1.23秒

**デフォルトの名無しさん** · 2014/07/03(木) 02:03:00.95

逆に元の言語でブラウザのAPIを使ってそれをJavaScriptに変換する場合は
元の言語側でブラウザのDOMにアクセスするような(仮想的な？)ライブラリを用意して
それをうまいことJavaScriptのコードに対応づけてやる必要があるだろうな
例えばEmscriptenはそういう仮想的なライブラリを各言語毎に用意してんの？

**デフォルトの名無しさん** · 2014/07/03(木) 02:07:16.47

>>157 あらゆる言語が有るんだから全ての言語がCライブラリを利用している訳でもないし、
全てのCライブラリが変換出来る訳でもない。
コンパイル環境によってリンクされるライブラリも違うだろうし、
VSでコンパイルすれば多分エラーのオンパレードになるだろう。

**デフォルトの名無しさん** · 2014/07/03(木) 02:09:41.14

最終的にC,C++を経由しないライブラリなんてあるのか？
Pythonとかも動いてんだ
何の問題もない

**デフォルトの名無しさん** · 2014/07/03(木) 02:23:50.93

>>160
Emscriptenの仕組みを根本的に勘違いしてる？
これはC言語の一般的なライブラリ(libcとかSDLとかもいけるらしい)にリンクされた形式のLLVM-IRを入力にして、
JavaScriptを出力するものだと思うんだけど

>>159で挙げたみたいな仕組みも別に用意されているのかな？

各言語毎に用意された独自の様々なライブラリとリンクされたLLVM-IRを
漏れなくJavaScriptに変換できるとしたらそれはものすごい規模の仕組みになると思うけど
そんなの神業すぎて有り得ん

**デフォルトの名無しさん** · 2014/07/03(木) 02:33:38.51

だから>>153のこれも
（Swift　＞LLVM IR　＞ Javascriptは可能だが公式発表は無し）
まだ現実的には意味が無いはず

すべてのLLVM-IRをJavaScriptに変換できるわけでは無い
変換可能なのはEmscriptenがサポートする範囲のライブラリがリンクされたLLVM-IRなわけ
今のSwiftにはまだEmscriptenがサポートするライブラリとか用意されてないよね

**デフォルトの名無しさん** · 2014/07/03(木) 08:49:38.57

SwiftをJavaScriptに変換したところでアプリがそのまま移植できるわけではないし
(APIを移植したらAppleに訴えられるだろう)
どうせ互換性がないなら無理にSwiftやemscriptenなんか使ってコードを肥大化させる必要なんかない
それこそTypescriptやCoffeeでいい

**デフォルトの名無しさん** · 2014/07/03(木) 12:34:47.74

Emscripten は標準でEmscripten自体からC++のコンパイラclangを呼び出し直接JSを吐き出せる。
この場合はライブラリ環境はGNU ldをエミュレートしているらしい。

Emscripten で C++ の Hello World を JavaScript に変換してみた
http://tips.hecomi.com/entry/20130416/1366124901

これを見ると　 linker emulating GNU ld　と有るからこれらはHTML環境に変換してるみたい。
それ以外のライブラリを使う場合は難しそう。　Objective-Cもダメらしい。
Emscripten がライブラリをエミュレートしない限りはかなり難しいだろうな。

**デフォルトの名無しさん** · 2014/07/03(木) 13:02:22.21

>>165
なんかいろいろ勘違いしてるけど、無理だということがわかってくれればそれでいいや

**デフォルトの名無しさん** · 2014/07/03(木) 17:06:52.84

>>163
> すべてのLLVM-IRをJavaScriptに変換できるわけでは無い
> 変換可能なのはEmscriptenがサポートする範囲のライブラリがリンクされたLLVM-IRなわけ

基本的には全てのLLVM-IRをJavaScriptに変換出来るんじゃないの？

OpenGL→WebGLみたいにJavaScriptのAPIにマッピング出来るライブラリがあるかないかと
変換出来るかどうかを一緒にしては駄目だ

**デフォルトの名無しさん** · 2014/07/03(木) 17:10:36.81

Dartプログラミング言語をGoogleのApp Engineがサポート…ついにサーバ言語としても位置づけ
http://m.jp.techcrunch.com/2014/07/01/20140629googles-dart-programming-language-is-coming-to-the-server/

これでW3Cは無理が有る様に思うが、きっかけにはなりそう。

あまり使いたいと思わせる要素は少ないな。あるのは数の力かな。
多分この辺りの言語戦争がWebKit内で有って分裂したんじゃ無いだろうか。表面は違うが。

**デフォルトの名無しさん** · 2014/07/03(木) 17:16:30.98

>>167 その通り、全て言語的には変換出来る。
出来ないのは、リンク結合出来るか出来ないか。
だから使えるか使えないかと言ったら、使い方次第。
無理して使う人は少ないだろうが。

**デフォルトの名無しさん** · 2014/07/03(木) 17:18:28.55

>>167
少なくともEmscriptenによるJavaScriptへの変換は
マッピングされてないライブラリをリンクしてるLLVM-IRをJavaScriptのコードには変換できないだろ？
ネイティブコードへ変換する通常のLLVMのバックエンドとはちょっと事情が違う

**デフォルトの名無しさん** · 2014/07/03(木) 17:25:03.31

>>170
Emscriptenはリンクする前にJavascriptへ変換すんだよ。あんまり半端な知識で知ったかぶりしないほうがいいぞ

**デフォルトの名無しさん** · 2014/07/03(木) 17:26:35.21

>>169
だからEmscriptenは通常のLLVMバックエンドと違って実際にリンク結合するわけじゃいんだってば
リンク結合されるべき部分を無理やりEmscriptenが用意してるJavaScriptランタイムの呼び出しに変換する
その変換が用意されてないライブラリの呼び出しを見つけたらEmscriptenの変換は失敗するわけ

**デフォルトの名無しさん** · 2014/07/03(木) 17:31:02.65

>>171
実際にリンクするわけじゃないだろ？
呼び出すJavaScriptランタイムがなければそれはEmscriptenにとっては変換失敗じゃないか

**デフォルトの名無しさん** · 2014/07/03(木) 17:40:23.64

>>170はちょっと書き方が悪かったなライブラリをリンクしてるというかライブラリの関数を呼び出してると書くべきだった
そしてライブラリ関数の呼び出しはとりあえずJavaScriptに変換されて、
Emscriptenが用意してるJavaScriptとランタイムと一緒に実行したときに
ランタイムがそのライブラリ関数をサポートしてれば実行されるし、サポートしてなければ実行時エラーになるのか
このへんはちょっと勘違いしてた

**デフォルトの名無しさん** · 2014/07/03(木) 17:44:10.65

>>174
そんな感じやね。もちろんヘッダすらなかったらコンパイルエラーになるけど

**デフォルトの名無しさん** · 2014/07/03(木) 17:50:05.06

だからとりあえずどんなLLVM-IRでもJavaScriptへの変換は可能。これは訂正しとくは

そして、Swiftをブラウザで実行しようと思ったらSwift用のJavaScriptランタイムを用意する必要があると

Cocoaに相当するランタイムは実質不可能だろう
SwiftからDOMにアクセスするランタイムは作れなくも無さそうだけど、
Swift側のAPIを決めて、それにマッピングするようランタイム作る必要があるわけだ

**デフォルトの名無しさん** · 2014/07/03(木) 18:34:43.81

>>168
マルチすんな

**デフォルトの名無しさん** · 2014/07/03(木) 22:05:31.71

>>176
「は」と「わ」の使い分けも出来んバカだったのかお前
さもありなんだな

**デフォルトの名無しさん** · 2014/07/04(金) 00:26:10.01

初めてか？力抜けよ。

**デフォルトの名無しさん** · 2014/07/06(日) 11:16:42.61

>>176 XcodeのSwiftデバッグ情報を見ると、WebKitのJS JIT(VM/LLVM)が動いてREPLを実行してるようだ。

Xcodeが落ちた時に詳細情報を見ると、中にこんなのが見える。

VM Region Summary:
JS JIT generated code 　　　　　　　　　8K
JS JIT generated code (reserved) 　　1.0G　　　reserved VM address space (unallocated)
VM_ALLOCATE 　　　　　　　　　　　　　16.5M
WebKit Malloc 　　　　　　　　　　　　　　1232K

なんだかすごく楽しみだな。

**デフォルトの名無しさん** · 2014/07/06(日) 12:59:26.62

>>176 Javascriptライブラリは一通りそろってるはず。
こんどのOSX10.10（Yosemite）では、Javascriptがシステムオートメーション用のスクリプトとして動き始めるからJavascriptのすべてのライブラリは揃ってると見て良い。

Release Notes This is a preliminary document
https://developer.apple.com/library/prerelease/mac/releasenotes/interapplicationcommunication/rn-javascriptforautomation/index.html
This article describes JavaScript for Automation, a new feature in OS X 10.10.

当面はOSXで実績を積んでいずれSwiftとマージと言う話になると思う。
JavascriptからObjCとの相互呼び出しも可能だからとうぜんSwiftとの間の相互呼び出しも可能のはず。（WebKitで許すかどうかは別の話）

SwiftからJSへの変換は結構早い時期に発表が有ると思う。　将来的には、JavascriptとSwiftのソースの混在も可能になるだろう。

**デフォルトの名無しさん** · 2014/07/06(日) 13:30:19.96

>>180
単にXcodeが表示にWebKitを使ってるだけじゃないの？

**デフォルトの名無しさん** · 2014/07/06(日) 13:41:28.52

>>181
そのリンクの先はOSX上でJavaScriptからCocoa関係にアクセスするための仕組みのように見えるんだけど違うの？
>>176とはほとんど関係無くない？

**デフォルトの名無しさん** · 2014/07/06(日) 14:11:28.43

ID:uI+Octwc
お前さ、マルチしないでどっちかで話進めろよ

**デフォルトの名無しさん** · 2014/07/06(日) 16:55:42.10

>>184 こっちは話の流れ上Webクライアント限定。あっちは本流。

>>183 OSXのスクリプトとしてJavascriptが動き出した。
>>176のSwiftがJavascripに変換されてもクライアントのJavascripライブラリがなければ動き様が無いと言う話は、OSXでJavascriptが動き出すので殆どクライアント用ライブラリも揃ってると見て良いだろうと思う。
iOS用のライブラリはまた別になるのでそのまま全て横流しと言う訳にはいかないが、大した手間では無いだろう。
WebKit用ライブラリは既に揃ってるから、WebKitを使う他社のブラウザでもその範囲なら大丈夫だろう。

WebKitを使わないブラウザ用としては変換したJavascriptが動く様にしておけば良いだろう。
この考え方はDartでも同じ。

このスクリプトで面白いのは、スクリプトエディタでJavascriptをアプリケーションとして保存すると、Appletとして呼び出して使える事。
この保存形式は解らないが、Javascriptのソースコードで無いことは明らか。
例えば、LLVM IR がApplet用バイトコードとして使われる可能性は結構有ると思う。
Googleとは別々の道を進んでいても、バイトコードとしてLLVM IR形式を使おうと言う合意の可能性はまだ残されてるんじゃ無いかな。 LLVM IR で無くても良いが何らかの統一コードは必要だろう。
しかし何故Java中間コードでは満足出来なかったんだろう？冗長性有り過ぎ？

ネイティブコード/バイトコードのアプレットが広く普及するとは思えないが、企業などの作り込みアプリなら利用されるだろう。

このスレでこの話題を話すのは、Webクライアントソフトが今後どう言う方向に進んで行くかと言う話にマッチしてるから。

TypeScriptも今はJavascriptに変換してるが、もし統一中間コードが決まればダイレクトにそのコードにコンパイルする様になるだろう。その方が効率が良いはずだから。

**デフォルトの名無しさん** · 2014/07/06(日) 17:04:40.34

>>185
JavaScriptからCocoa呼び出せても、ネイティブなCocoaがあるOSでしか動かないじゃない？
そんなのは一般的なWebクライアント用言語としては使えないよ

**デフォルトの名無しさん** · 2014/07/06(日) 17:48:41.56

>>186 Java Appletが、動ける範囲を制限してる様に、何らかのクラスの下でだけ動ける様にするはず。
極端な話WebKitの範囲内だけとか。要はJavaScriptが動ける範囲内だけで良いんだよ。WebKitAppクラスとか。

別に汎用のCocoaを網羅する必要は無いし動いたら却って怖い話。そんなのセキュリティ上有り得ない。

**デフォルトの名無しさん** · 2014/07/06(日) 17:53:53.35

あんたが言ってるようなのって今現在沢山あるぞ?
どれも中途半端でイマイチ流行らないけどね
OSのAPIをひたすらラップするだけの作業だから
手間さえかければ良い物ができるよ
>>187による実装に期待

**デフォルトの名無しさん** · 2014/07/06(日) 18:03:43.16

>>187
クラスの下で動くって意味がわからないよ
そのクラスっていうのは実体が何で、世の中の一般的なブラウザはそれをどうやって利用するの？

**デフォルトの名無しさん** · 2014/07/06(日) 18:18:44.85

>>186 それとクラスと言ってもそれは上位言語の話で有って、中間言語などに降りてきたらクラスなんか関係無い。
単なる汎用のマシン語が動くかどうかの世界。

ただ、まっさらなマシン語の実行を許すと大きなセキュリティの危険にさらされるから、何らかのガードの元で実行出来る様にするはず。

**デフォルトの名無しさん** · 2014/07/06(日) 18:22:58.33

>>190
だからその中間言語を一般的なブラウザでどうやって実行するつもりなんだって聞いてるんだ
プラグインか？JavaScriptランタイムか？アップルはそんなもの提供するなんて一言も言ってないだろ

**デフォルトの名無しさん** · 2014/07/06(日) 18:41:08.24

swift→bit code→NativeClientは可能だろうけど。

**デフォルトの名無しさん** · 2014/07/06(日) 19:36:19.25

知ったかぶりの妄言垂れ流しｗ

**デフォルトの名無しさん** · 2014/07/06(日) 20:13:32.73

>>191　一般ブラウザは中間コードじゃなくて単なるJavascriptだよ。
つまり、Native/bytecode またはJavascriptの両方出力できるようにするはず。　Dartも同じ。
多分HTML上も両方スイッチできるようにしておいてクライアントに応じてどちらかをダウンロードする形。

**デフォルトの名無しさん** · 2014/07/06(日) 20:25:18.93

>>191 >JavaScriptランタイムか？アップルはそんなもの提供するなんて一言も言ってないだろ
全て妄想の範囲だよ。　だが現実味が強い。

１．Javascriptランタイムライブラリは殆ど揃ってる。＜－JavascriptがOSスクリプトに採用されたから。　＜－公式発表
２．SwiftからLLVM IRは今でも出力できる。　＜－既に動いてる。
３．LLVM IRからJavascriptへのコンバータは既にある。　だからライブラリさえ提供されれば可能になる。

いつごろ実現するかはわからんが1年以内だろう。

**デフォルトの名無しさん** · 2014/07/06(日) 20:35:43.02

>>194-195
LLVM-IRからJavaScriptに変換したコードを他ブラウザで実行する際に必要とするJavascriptランタイムは、
JavaScriptをOS Xのスクリプトとして利用するための仕組みに関係するものとは全然性質が違うんだよ
前者はcocoaの機能に相当する部分までなんとかしないといけないけど、
後者は単にOS Xへのラッパーにしか過ぎない
この違いが理解できるかな？

前者はかなり大変な仕組みだからアップルが何の発表もしてない時点で現実味が全く無い

**デフォルトの名無しさん** · 2014/07/06(日) 20:58:28.80

WindowsでもJScriptがつかえるよ！
やったね！

**デフォルトの名無しさん** · 2014/07/06(日) 21:16:00.20

>>196 逆にJavascriptに変換すると言う事は、javascript実行環境で使うのであればJavascript内でクローズしていれば良いのだから複雑なライブラリは必要ないとも言えるのでは？
だからすべてのブラウザで動く事が出来る。
Javascriptに変換した後の環境は単にウエブブラウザのJavascriptインタプリタのみ。　
必要なランタイムライブラリはインタプリタが実装していると言える。

**デフォルトの名無しさん** · 2014/07/06(日) 21:36:38.50

>>198
そうだよ。単にDOMにアクセスするためなら複雑なランタイムは必要無い
だから>>181のJavaScriptからcocoaを呼び出す仕組みとか関係無いってことだ

**デフォルトの名無しさん** · 2014/07/06(日) 21:44:52.63

WebになるとSwift関連ツールがWindows向けに提供されない場合、Windowsでのデバッグがやりにくくなる
スマフォ用Webアプリには使われても、直ぐに後追いが出てマルチプラットホームでのツール提供をすればそれに越されそう

**デフォルトの名無しさん** · 2014/07/28(月) 12:14:09.79

>>200 JavaScriptに変換するのならTypeScriptと同じ土俵だろ。　デバッグに心配はない。

**デフォルトの名無しさん** · 2014/07/28(月) 12:30:56.51

emscripten使えばわかるけど、生成されたゲロみたいなjsコードのデバッグは非常に困難
極めて綺麗なJSを吐くTypeScriptとは一緒にしてはいけない

**デフォルトの名無しさん** · 2014/07/28(月) 13:21:39.99

>>202 どのレベルのJSを吐くかによるだろ。　EmScriptenはasm.js を吐き出すんだろ？
性能を取るか視認性を取るかの違いだろ。
asm.jsを吐き出しても元のソースコードをコメントで入れてあれば見やすいのにそれはしていないんだろうな。
そのうち成長してくるだろう。

**デフォルトの名無しさん** · 2014/07/28(月) 13:42:07.75

>>203
Emscriptenはデバッグが完了したネイティブアプリを変換する為だけのもの

**デフォルトの名無しさん** · 2014/07/28(月) 14:35:34.32

>>204 単体デバッグ出来るんだっけ？
LLDB使って出来そうには思うけど。

**デフォルトの名無しさん** · 2014/07/28(月) 14:39:54.10

>>203
ジェネレータは関係ない
コンパイル時のデバッグ情報を使わない限り、IRの時点でデバッグは十分困難だから

**デフォルトの名無しさん** · 2014/07/28(月) 15:22:21.31

>>206 詳しいことは知らないんだけど、IRにまでデバッグ情報は持ち込めるんじゃ無いの？
IRを使ってLLDBでデバッグ出来るんだから。 LLDBはClangでしかデバッグ出来ないの？

**デフォルトの名無しさん** · 2014/07/29(火) 18:12:30.41

>>202
ソースマップではあかんのけ

**デフォルトの名無しさん** · 2014/08/05(火) 17:59:50.13

>>202 あのね、コンパイラ言語はソースでデバッグするだろ、アセンブラでデバッグする事は滅多にないよ。

**デフォルトの名無しさん** · 2014/08/05(火) 21:08:06.58

>>209
TypeScriptと同じ土俵ってところへの突っ込みでしょ。TypeScriptにとってJSは中間言語じゃない。
あっちはデバッガ含めJS資産を完全にシームレスに活用できるのが売り。
最悪、生成されたJSコードをベースにしてJSに戻って開発を続けることも十分可能なほど。

**デフォルトの名無しさん** · 2014/08/05(火) 21:51:55.04

言語が違うんだから、デバッグ方法が異なっても当然だな
しかし、JSのデバッグはお世辞にもデバッグしやすいとは言えないだろ。

**デフォルトの名無しさん** · 2014/09/17(水) 19:13:24.03

iPhone修理の仕事してる人っている？
iPhone6とかすでに受け取ってるんかね？

そういえば、ビックカメラとキタムラのiPhone修理受付の求人が入れ食い状態だとか噂を聞いたことある。確かに最近混雑して待ち時間が6時間とからしいからな

可愛い女の子も多いし応募してみようかと思ってる

**デフォルトの名無しさん** · 2014/11/30(日) 10:37:14.85

>>211
とはいえ最近かなり環境整ってるぞ
JSソースからデバッグ用JSソースのコンパイルってのも増えてきたし

**デフォルトの名無しさん** · 2015/12/05(土) 10:38:14.09

>>67
いつの話だよ
invokedynamicとか知らないのか

**デフォルトの名無しさん** · 2015/12/05(土) 10:41:02.53

>>94
根本的に理解してない

**デフォルトの名無しさん** · 2016/09/02(金) 01:28:02.86

Typescriptもdiscriminated union対応したか

**デフォルトの名無しさん** · 2016/09/10(土) 20:30:22.95

Android Studioの標準言語をTypescriptにしてくれるとだいぶ助かる

**デフォルトの名無しさん** · 2016/11/16(水) 13:22:30.64

バックレScript

**デフォルトの名無しさん** · 2017/11/07(火) 04:41:42.67

>>217
vscで良いやん。エクステンションもtsで書ける

**デフォルトの名無しさん** · 2018/05/23(水) 21:20:08.99

僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

PPU1S

**デフォルトの名無しさん** · 2018/07/05(木) 00:37:38.99

KWT

**デフォルトの名無しさん** · 2019/01/30(水) 15:12:57.19

>>1 しかしなんのために　TypeScript　と　Swiftを並べてみようという気になったのかが気になる。
全く比べるようなものじゃないだろ。

**デフォルトの名無しさん** · 2019/10/04(金) 15:53:26.51

ｋｔｋｒ
https://forest.watch.impress.co.jp/docs/news/1208784.html