TypeScript（MS） VS Swift（Apple）

TypeScript（MS） VS ..

183:デフォルトの名無しさん
14/07/03 17:50:05.06 9OGBgTec.net
だからとりあえずどんなLLVM-IRでもJavaScriptへの変換は可能。これは訂正しとくは

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

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

184:デフォルトの名無しさん
14/07/03 18:34:43.81 Q4dDnky3.net
>>169
マルチすんな

185:デフォルトの名無しさん
14/07/03 22:05:31.71 PZTUxxNC.net
>>177
「は」と「わ」の使い分けも出来んバカだったのかお前
さもありなんだな

186:デフォルトの名無しさん
14/07/04 00:26:10.01 SkdUVSJA.net
初めてか？力抜けよ。

187:デフォルトの名無しさん
14/07/06 11:16:42.61 uI+Octwc.net
>>177 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

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

188:デフォルトの名無しさん
14/07/06 12:59:26.62 uI+Octwc.net
>>177 Javascriptライブラリは一通りそろってるはず。
こんどのOSX10.10（Yosemite）では、Javascriptがシステムオートメーション用のスクリプトとして動き始めるからJavascriptのすべてのライブラリは揃ってると見て良い。

Release Notes This is a preliminary document
URLﾘﾝｸ(developer.apple.com)
This article describes JavaScript for Automation, a new feature in OS X 10.10.

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

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

189:デフォルトの名無しさん
14/07/06 13:30:19.96 J6LM3Iar.net
>>181
単にXcodeが表示にWebKitを使ってるだけじゃないの？

190:デフォルトの名無しさん
14/07/06 13:41:28.52 J6LM3Iar.net
>>182
そのリンクの先はOSX上でJavaScriptからCocoa関係にアクセスするための仕組みのように見えるんだけど違うの？
>>177とはほとんど関係無くない？

191:デフォルトの名無しさん
14/07/06 14:11:28.43 pBYyLByM.net
ID:uI+Octwc
お前さ、マルチしないでどっちかで話進めろよ

192:デフォルトの名無しさん
14/07/06 16:55:42.10 uI+Octwc.net
>>185 こっちは話の流れ上Webクライアント限定。あっちは本流。

>>184 OSXのスクリプトとしてJavascriptが動き出した。
>>177の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に変換してるが、もし統一中間コードが決まればダイレクトにそのコードにコンパイルする様になるだろう。その方が効率が良いはずだから。

193:デフォルトの名無しさん
14/07/06 17:04:40.34 J6LM3Iar.net
>>186
JavaScriptからCocoa呼び出せても、ネイティブなCocoaがあるOSでしか動かないじゃない？
そんなのは一般的なWebクライアント用言語としては使えないよ

194:デフォルトの名無しさん
14/07/06 17:48:41.56 uI+Octwc.net
>>187 Java Appletが、動ける範囲を制限してる様に、何らかのクラスの下でだけ動ける様にするはず。
極端な話WebKitの範囲内だけとか。要はJavaScriptが動ける範囲内だけで良いんだよ。WebKitAppクラスとか。

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

195:デフォルトの名無しさん
14/07/06 17:53:53.35 5z9UYEB8.net
あんたが言ってるようなのって今現在沢山あるぞ?
どれも中途半端でイマイチ流行らないけどね
OSのAPIをひたすらラップするだけの作業だから
手間さえかければ良い物ができるよ
>>188による実装に期待

196:デフォルトの名無しさん
14/07/06 18:03:43.16 J6LM3Iar.net
>>188
クラスの下で動くって意味がわからないよ
そのクラスっていうのは実体が何で、世の中の一般的なブラウザはそれをどうやって利用するの？

197:デフォルトの名無しさん
14/07/06 18:18:44.85 uI+Octwc.net
>>187 それとクラスと言ってもそれは上位言語の話で有って、中間言語などに降りてきたらクラスなんか関係無い。
単なる汎用のマシン語が動くかどうかの世界。

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

198:デフォルトの名無しさん
14/07/06 18:22:58.33 J6LM3Iar.net
>>191
だからその中間言語を一般的なブラウザでどうやって実行するつもりなんだって聞いてるんだ
プラグインか？JavaScriptランタイムか？アップルはそんなもの提供するなんて一言も言ってないだろ

199:デフォルトの名無しさん
14/07/06 18:41:08.24 vf+otpu+.net
swift→bit code→NativeClientは可能だろうけど。

200:デフォルトの名無しさん
14/07/06 19:36:19.25 os3e/Xgk.net
知ったかぶりの妄言垂れ流しｗ

201:デフォルトの名無しさん
14/07/06 20:13:32.73 uI+Octwc.net
>>192　一般ブラウザは中間コードじゃなくて単なるJavascriptだよ。
つまり、Native/bytecode またはJavascriptの両方出力できるようにするはず。　Dartも同じ。
多分HTML上も両方スイッチできるようにしておいてクライアントに応じてどちらかをダウンロードする形。

202:デフォルトの名無しさん
14/07/06 20:25:18.93 uI+Octwc.net
>>192 >JavaScriptランタイムか？アップルはそんなもの提供するなんて一言も言ってないだろ
全て妄想の範囲だよ。　だが現実味が強い。

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

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

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

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

204:デフォルトの名無しさん
14/07/06 20:58:28.80 c4JqBC4F.net
WindowsでもJScriptがつかえるよ！
やったね！

205:デフォルトの名無しさん
14/07/06 21:16:00.20 uI+Octwc.net
>>197 逆にJavascriptに変換すると言う事は、javascript実行環境で使うのであればJavascript内でクローズしていれば良いのだから複雑なライブラリは必要ないとも言えるのでは？
だからすべてのブラウザで動く事が出来る。
Javascriptに変換した後の環境は単にウエブブラウザのJavascriptインタプリタのみ。　
必要なランタイムライブラリはインタプリタが実装していると言える。

206:デフォルトの名無しさん
14/07/06 21:36:38.50 J6LM3Iar.net
>>199
そうだよ。単にDOMにアクセスするためなら複雑なランタイムは必要無い
だから>>182のJavaScriptからcocoaを呼び出す仕組みとか関係無いってことだ

207:デフォルトの名無しさん
14/07/06 21:44:52.63 c4JqBC4F.net
WebになるとSwift関連ツールがWindows向けに提供されない場合、Windowsでのデバッグがやりにくくなる
スマフォ用Webアプリには使われても、直ぐに後追いが出てマルチプラットホームでのツール提供をすればそれに越されそう

208:デフォルトの名無しさん
14/07/28 12:14:09.79 zl94e36f.net
>>201 JavaScriptに変換するのならTypeScriptと同じ土俵だろ。　デバッグに心配はない。

209:デフォルトの名無しさん
14/07/28 12:30:56.51 4XV/yzRg.net
emscripten使えばわかるけど、生成されたゲロみたいなjsコードのデバッグは非常に困難
極めて綺麗なJSを吐くTypeScriptとは一緒にしてはいけない

210:デフォルトの名無しさん
14/07/28 13:21:39.99 zl94e36f.net
>>203 どのレベルのJSを吐くかによるだろ。　EmScriptenはasm.js を吐き出すんだろ？
性能を取るか視認性を取るかの違いだろ。
asm.jsを吐き出しても元のソースコードをコメントで入れてあれば見やすいのにそれはしていないんだろうな。
そのうち成長してくるだろう。

211:デフォルトの名無しさん
14/07/28 13:42:07.75 /uFLkIvt.net
>>204
Emscriptenはデバッグが完了したネイティブアプリを変換する為だけのもの

212:デフォルトの名無しさん
14/07/28 14:35:34.32 WmVK7Shw.net
>>205 単体デバッグ出来るんだっけ？
LLDB使って出来そうには思うけど。

213:デフォルトの名無しさん
14/07/28 14:39:54.10 4XV/yzRg.net
>>204
ジェネレータは関係ない
コンパイル時のデバッグ情報を使わない限り、IRの時点でデバッグは十分困難だから

214:デフォルトの名無しさん
14/07/28 15:22:21.31 WmVK7Shw.net
>>207 詳しいことは知らないんだけど、IRにまでデバッグ情報は持ち込めるんじゃ無いの？
IRを使ってLLDBでデバッグ出来るんだから。 LLDBはClangでしかデバッグ出来ないの？

215:デフォルトの名無しさん
14/07/29 18:12:30.41 jgexYzWF.net
>>203
ソースマップではあかんのけ

216:デフォルトの名無しさん
14/08/05 17:59:50.13 DgDBu3xR.net
>>203 あのね、コンパイラ言語はソースでデバッグするだろ、アセンブラでデバッグする事は滅多にないよ。

217:デフォルトの名無しさん
14/08/05 21:08:06.58 ghCtuQ0N.net
>>210
TypeScriptと同じ土俵ってところへの突っ込みでしょ。TypeScriptにとってJSは中間言語じゃない。
あっちはデバッガ含めJS資産を完全にシームレスに活用できるのが売り。
最悪、生成されたJSコードをベースにしてJSに戻って開発を続けることも十分可能なほど。

218:デフォルトの名無しさん
14/08/05 21:51:55.04 q3/M2RFT.net
言語が違うんだから、デバッグ方法が異なっても当然だな
しかし、JSのデバッグはお世辞にもデバッグしやすいとは言えないだろ。

219:デフォルトの名無しさん
14/09/17 19:13:24.03 C5lp8vtK.net
iPhone修理の仕事してる人っている？
iPhone6とかすでに受け取ってるんかね？

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

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

220:デフォルトの名無しさん
14/11/30 10:37:14.85 tEmwOrdq.net
>>212
とはいえ最近かなり環境整ってるぞ
JSソースからデバッグ用JSソースのコンパイルってのも増えてきたし

221:デフォルトの名無しさん
15/12/05 10:38:14.09 bXwpd8hP.net
>>68
いつの話だよ
invokedynamicとか知らないのか

222:デフォルトの名無しさん
15/12/05 10:41:02.53 bXwpd8hP.net
>>95
根本的に理解してない

223:デフォルトの名無しさん
16/09/02 01:28:02.86 D4RF+Hn1.net
Typescriptもdiscriminated union対応したか

224:デフォルトの名無しさん
16/09/10 20:30:22.95 vL431mpn.net
Android Studioの標準言語をTypescriptにしてくれるとだいぶ助かる

225:デフォルトの名無しさん
16/11/16 13:22:30.64 fzskfnoe.net
バックレScript

226:デフォルトの名無しさん
17/11/07 04:41:42.67 G20ApN4s.net
>>218
vscで良いやん。エクステンションもtsで書ける

227:デフォルトの名無しさん
18/05/23 21:20:08.99 Au5e7VGg.net
僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』
PPU1S

228:デフォルトの名無しさん
18/07/05 00:37:38.99 RfoszcD2.net
KWT

229:デフォルトの名無しさん
19/01/30 15:12:57.19 M7eOsbET.net
>>1 しかしなんのために　TypeScript　と　Swiftを並べてみようという気になったのかが気になる。
全く比べるようなものじゃないだろ。

230:デフォルトの名無しさん
19/10/04 15:53:26.51 JXWhYfPM.net
ｋｔｋｒ
URLﾘﾝｸ(forest.watch.impress.co.jp)

231:過去ログ ★
[過去ログ]
■ このスレッドは過去ログ倉庫に格納されています