X

TypeScript（MS） VS Swift（Apple）

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
垢版 |
2014/06/03(火) 10:20:03.13ID:Tlzh3MoL
まあ、どちらもタイプセーフJavaScriptという
似たような言語なんだから仲良くしろや。
0004デフォルトの名無しさん
垢版 |
2014/06/03(火) 11:19:20.56ID:UatVHvvj
>>3
それは文法とは関係ないだろ。

TypeScript -> JavaScript -> native
ネイティブコードへのコンパイルは可能。
0006デフォルトの名無しさん
垢版 |
2014/06/03(火) 12:44:55.01ID:9Ltabfc6
しかしどちらも中核にLLVMを使ってるからLLVM byte codeは基本的に同じ物を吐き出すんだろうな。

だからやろうと思ったら　TypeScriptとSwiftのマージも比較的簡単に出来そう。

LLVMはJavascriptに限らず、Ruby,　Phyton、Java等等色んな言語にもコンパイルできる。
0007デフォルトの名無しさん
垢版 |
2014/06/03(火) 14:48:18.77ID:9AiAEfmm
JavaScriptを介してのネイティブコードへの変換は型情報が失われちまわないか？
型情報無い状態で静的なネイティブコードに変換すると性能的にかなり劣化すると思う
0008デフォルトの名無しさん
垢版 |
2014/06/03(火) 15:12:49.72ID:9Ltabfc6
>>7 Javascriptを介してるんじゃなくてLVMMの中間コードから各種コードを生成しているから何も失われない。
0010デフォルトの名無しさん
垢版 |
2014/06/03(火) 15:57:29.78ID:9AiAEfmm
調べてみる限りTypeScriptのコンパイラーはJavaScript(TypeScript？)で書かれてるって情報しか見つからん
MS以外がLLVMバージョンを作ってるのか？
0011デフォルトの名無しさん
垢版 |
2014/06/03(火) 19:58:42.98ID:kHnJtq7G
役割的にはどう考えてもC#と比べるべきだろ
そっちが相手だと全く勝ち目ないけどw
0012デフォルトの名無しさん
垢版 |
2014/06/03(火) 20:05:20.73ID:F1xw9elh
Cocoa を呼び出すためのカジュアルな言語が Swift で .NET を呼び出すカジュアルな言語が C# だからその通りだろう。
勝ち目って何を基準にするのかねえ。 .NET の未来が明るそうには見えないけど。
0013デフォルトの名無しさん
垢版 |
2014/06/03(火) 20:10:32.12ID:9Ltabfc6
>>10 コンパイラはLLVMだよ。　LLVMからJavascriptを出してる。
LLVMは中間コードを作り、そこからJavascriptや、マシン語やJavaコードを作り出せる。
0015デフォルトの名無しさん
垢版 |
2014/06/03(火) 20:19:54.69ID:9AiAEfmm
>>13
どこに行けばその情報が手に入る？
公式見てもTypeScriptのコンパイラはTypeScript自身で書かれているようにしか見えない
使う時はnode.jsインストールしてnpmでコンパイラのパッケージをインストールしろって書いてあるし
0016デフォルトの名無しさん
垢版 |
2014/06/03(火) 20:38:37.44ID:kHnJtq7G
囲い込みをやめて開発者のことを考えるなら
JavaScriptでネイティブアプリ作れるようにするのが正解だよな
それこそTypeScriptだって使えるし
0018デフォルトの名無しさん
垢版 |
2014/06/03(火) 23:43:19.81ID:OIzVF/VN
よそでもスイフトをスクリプト言語みたいに言ってる連中いたな。
C#に型推論が入った時も、動的型とかバリアント型と区別ついてない連中いっぱいいたし。

まあ、ぱっと見が重要なんだろうな。
0021デフォルトの名無しさん
垢版 |
2014/06/04(水) 09:26:39.20ID:OMtzL7Lr
あとあとやっぱりObjective-Cの方がよかったーSwiftダメだーとなる可能性が微レ存？
0022デフォルトの名無しさん
垢版 |
2014/06/04(水) 09:39:17.82ID:WGeQMsM6
>>21 有る訳ないだろ。　そうそうたる言語のプロ達が出した結論なんだから。
それに見ればわかるが今までの言語の良い所取りをした感じで悪い感じがしない。　
0023デフォルトの名無しさん
垢版 |
2014/06/04(水) 09:45:06.59ID:lcmwMnDg
Obj-Cを敬遠していたニワカが流入してきて検索結果の質が落ちたーSwiftダメだー
0025デフォルトの名無しさん
垢版 |
2014/06/04(水) 17:09:15.70ID:Clluav0V
ObjCもデザイナー上がりのにわかプログラマだらけじゃないか…
0029デフォルトの名無しさん
垢版 |
2014/06/04(水) 22:40:27.37ID:tG9mbRWa
にわか意見だけどScalaに似てるとは感じる
Scala熟知してる方に、違いを解説するブログ執筆をお願いしたいレベル
0030デフォルトの名無しさん
垢版 |
2014/06/05(木) 18:45:42.51ID:18Wy6DPo
この言語って誰が使うの?
c,java辺りの開発者はまず使わないし、coffee script使う層は企業臭がするから使わない。
世界はもう、javascriptの一人勝ちだよ
ScalaやSwiftなんて新しい言語さわって悲しくなってこないの？
そんなもの触ったところで、コーディングスキルなんて伸びないんだよ？
0032デフォルトの名無しさん
垢版 |
2014/06/05(木) 18:51:59.24ID:CbdkWkFK
コーダーでもなければ、コーディングスキルが伸びることなんて期待しないだろ。
0034デフォルトの名無しさん
垢版 |
2014/06/05(木) 18:55:58.72ID:18Wy6DPo
新言語と成熟されてない周辺ツールなんて、何が楽しくてこんな言語さわるのか連中の気が知れないよ
0037デフォルトの名無しさん
垢版 |
2014/06/05(木) 21:14:23.42ID:lzzD+Ao8
swiftはc++に疲れて組み込みスクリプトとかに逃げてる人にも魅力ありそうな
まあまずオープンになるのか分からんが

Appleの柵の中に限って言えば、obj-cに疲れた開発者達が枚挙するのはまあ確定だろな
つかほんとobj-cでできてswiftに出来ないことが見当たらないレベルだし、将来的にobj-cをディスコンにする気満々にさえ見えてくる
0038デフォルトの名無しさん
垢版 |
2014/06/05(木) 21:17:09.67ID:KZps3rc8
オープンにしちゃうとわざわざ特に新規性のない新言語作った意味がないからね
0039デフォルトの名無しさん
垢版 |
2014/06/05(木) 21:30:16.56ID:23MIBYyX
>>38 多分動的言語としての発展性を持った言語だから普及が早いと思う。
デバッグ環境では動的言語としてインタプリタが動くから。

教育に最適
0040デフォルトの名無しさん
垢版 |
2014/06/05(木) 21:33:37.68ID:KZps3rc8
>>39
ある程度メジャーな言語なら今時そんなもんできない言語の方が珍しいぞ
EclipseのJavaとかVS上のC#/VBあたりですらできるというのに
0043デフォルトの名無しさん
垢版 |
2014/06/05(木) 21:48:33.40ID:KZps3rc8
>>42
REPLは当然できるしデバッグ実行中にコード書き換えたりとか普通にできるよ
今更特に珍しいことでもないので大して宣伝したりしないけど
0044デフォルトの名無しさん
垢版 |
2014/06/05(木) 21:48:48.87ID:W5+wneCa
インタプリタが動くって、デバッグ中に対話モードが提供されるってことじゃないの？
0046デフォルトの名無しさん
垢版 |
2014/06/05(木) 22:10:36.55ID:lzzD+Ao8
ランタイムがobj-cなら今までの通り、ネイティブコード吐いても中身は動的抽象化済みって構造でしょ
インタプリタみたいに使えてるのは、その都度ワンライナー分のバイナリ吐いて実行してるとしてもランタイムだけ共有すれば済むから軽く済むからじゃないのかしら

固定のVMシステムなしにここまでやれるというのはなんか不安になるレベルだけど、LLVMの恩恵とかフル活用してる感じだし収穫期の技術なんだろな
0047デフォルトの名無しさん
垢版 |
2014/06/06(金) 20:53:22.98ID:uAvQfS8F
>>30
>世界はもう、javascriptの一人勝ちだよ

10年前のお前らに言ってやったら鼻で笑われただろうな
0049デフォルトの名無しさん
垢版 |
2014/06/06(金) 22:41:13.01ID:vDxc/t5t
10年前からajaxは流行ってたし、MicrosoftはJScript以外は載せなかった
先見性はあるものの、市場での主導権を握れなかった哀れな連中さ
0050デフォルトの名無しさん
垢版 |
2014/06/06(金) 22:50:19.27ID:Pmgky8TD
独禁法でやられただけだよね。ドッキンドッキンされなかったら違ってたと思うよ。
0055デフォルトの名無しさん
垢版 |
2014/06/07(土) 00:28:08.45ID:jgc6Krm+
コナミの音楽のいい縦シューと
オランダのサッカーチームが混ざってたけど
いまはKPOPもいるのかよ

TypeScriptもLLVMに乗せるようになったらおもろいな
0059デフォルトの名無しさん
垢版 |
2014/06/07(土) 03:04:31.92ID:Rlb4AoSA
や、単にGoogleMapで評判になった非同期処理系にajaxって名前がついたのはjQueryより前だよって話です
今か前かとかじゃなく違和感あんのよ

JavaScript的な意味、とか言ってくれてればなんも引っかからなかったと思う、くらいの話

そもそもajaxと聞いて日本で洗剤と混同する層もいないだろうし、なんか嫌な言いがかりだったと思うわ
すまんです
0060デフォルトの名無しさん
垢版 |
2014/06/07(土) 06:56:33.45ID:2ccOrqUk
ajaxは2005年くらいからのイメージ
0062デフォルトの名無しさん
垢版 |
2014/06/14(土) 16:56:14.50ID:2ps+5Cwk
Swiftは良い所取りをしているが、他の言語とも親和性が良いと思う。解りやすい。
LLVMが、普及し始めてるから個別の言語がなんであれ強調出来そうな環境が整いつつある。

言語の強い部分はそれで書く。各々を一緒に使えれば良いんじゃ無い？
0064デフォルトの名無しさん
垢版 |
2014/06/14(土) 19:26:26.18ID:huxF3N6M
.NETもそうだけど、言語間の互換性をとる時代だな
それにたいしてJavaといったら
0065デフォルトの名無しさん
垢版 |
2014/06/14(土) 20:07:14.07ID:LJT0GoOm
LLVMでネイティブ吐くあたり、仮想マシンが無いってのが面白いね
.Netの巨大戦艦っぷりも萌えるし一概にどっちがいいでもないけど。

MSはMSでarmスマホ・タブとIntel winで同一アプリを動作させるつもりのようだし
あ、でもpNaClみたいな実装すればAppleもそういうアプローチを取れなくもないのかな

こういう夢を最初に見せてくれたのがJavaだったはずなのに、なんか後追いムードだな

>>64
JavaVM上で動く言語実装自体はいろいろあるじゃない
ネイティブ連携はめんどいけど
0066デフォルトの名無しさん
垢版 |
2014/06/14(土) 20:17:12.78ID:huxF3N6M
Javaはすぐ訴訟起こすイメージだな
このままだとAndroidも別言語に切り替えになりそうな気さえする
0067デフォルトの名無しさん
垢版 |
2014/06/14(土) 21:55:49.56ID:gViTkWWV
JVMは仕様が貧弱で、Javaと、JVMを前提にして設計された言語と、
エミュレーション的な動作のオーバーヘッドが問題にならない元々遅いスクリプト以外を動かすのには向かない
対して.NETは最初から共通言語基盤として設計されてるからね
0068デフォルトの名無しさん
垢版 |
2014/06/15(日) 03:19:25.43ID:Qhn/buVu
>>66　そのつもりだろ。　だからGDKなんてJava以外で開発して使うツールその物。
J2C　J2ObjC　なんてのも出してる。　JavaからC++やObjective-Cに変換する。

Java自体のスピードの限界も有るし。
0071デフォルトの名無しさん
垢版 |
2014/06/19(木) 19:38:11.88ID:6q/EJbCK
Googleはどっかのりんごちゃんと違ってプログラミング言語作りのセンス無いの自覚してるからな
言語作るのに関してはMSは飛び抜けて優秀
0073デフォルトの名無しさん
垢版 |
2014/06/19(木) 21:16:10.40ID:6q/EJbCK
そういうのは出してるだけで、玩具はあくまで玩具と理解してるよ
Googleはメディアを掌握してるからちょっとしたことでも話題になるけどね
Dartなんて未だにChromeに搭載されてないし、されるようになる気配もなく
特にやる気もないみたい
0074デフォルトの名無しさん
垢版 |
2014/06/20(金) 14:55:02.18ID:x5z8sn97
dartのベンチ結果は既にjavaと同程度だよ。中国なんて、golangの普及がすごいからね
特にやる気が無さそうに見えるのは、最後に自分たちのプロダクトが成功することを信じて疑わない王者の余裕だよ
0075デフォルトの名無しさん
垢版 |
2014/06/20(金) 15:58:57.41ID:ukZQYad7
dartはjavascriptへのコンパイラがあるからブラウザへの組み込みをがんばる必要ないでしょ。
コンテンツ作る側も他ブラウザを考えたらJavascriptでも作らなきゃならないのは変わらないし、その辺ちゃんとわかってる人は無理にブラウザに入れようとは思わないよ。
そんな事考えるのはswiftがJavascriptも置き換えて云々とかいうApple信者ぐらい。
0076デフォルトの名無しさん
垢版 |
2014/06/20(金) 20:21:20.60ID:M/JwZqVI
Dartは当初からブラウザに組み込まれるのが売りだったし
JSに代わって中間言語として使われるはずだったからこそ
あんなJavaモドキなガチガチ仕様にしたのにね
ただのAltJS止まりなら存在価値ゼロのJavaの出来損ない
0077デフォルトの名無しさん
垢版 |
2014/06/22(日) 00:29:13.65ID:fu9gwVHY
>>76
そんなガチガチかねぇ。
メソッドオーバーロード無いけどオペレータオーバーロードはありだし、オプショナル型だから変数の型宣言は省略できるし、
けっこうバランス取れたユルさだと思う。
0078デフォルトの名無しさん
垢版 |
2014/06/22(日) 01:02:59.67ID:41dfNV8s
ちょっと前から話題のDockerがgoで書かれてるんだよな
これで実績できればサーバー書いたりする言語として普及が進むかも
0080デフォルトの名無しさん
垢版 |
2014/06/22(日) 15:01:35.97ID:JSmk+G44
// Go
type string String
func Tag( name String ) String {
　var tag String = "<" + name + "/>"
　return tag
}

// Swift
func Tag( name :String ) -> String {
　var tag :String = "<" + name + "/>"
　return tag
}

ソックリー、ソックリー！
0082デフォルトの名無しさん
垢版 |
2014/06/22(日) 18:04:29.98ID:rW+mKnZ0
var tag = "<\(name)>"

の方が汎用性が有り美しいかも。
いろんな書き方が出来るSwiftは洗練されてる。
多分Swiftではこの書き方がメインになるのでは？ どんな型でも結合出来るし。
0083デフォルトの名無しさん
垢版 |
2014/06/22(日) 20:53:12.27ID:Cvja/8tc
>>82
現実には書式設定が必要な場合が多いのであんまり美しくなくなるんだよね
結局従来のprintf方式がスマート
0084デフォルトの名無しさん
垢版 |
2014/06/23(月) 00:26:21.67ID:k0C4cCbl
>>83 NSStringのformatは確かに美しくない。　println(NSString(format:"%5.2f", 1.2345)) //1.23
何か美しい演算子で表現できるようになると良いね。

例えば

var d = 1.234567
//operator infix ~> {}
@infix func ~> (left: Double, right: Int) -> String {
　　if right == 0 {
　　　　return "\(Int(left))"
　　}
　　var k = 1.0
　　for i in 1..right+1 {
　　　　 k = 10.0 * k
　　}
　　let n = Double(Int(left*k)) / Double(k)
　　return "\(n)"
}
println("\(d~>2)") //1.23
println("\(d~>1)") //1.2
println("\(d~>0)") //1

// 或は------------------
@infix func % (value:Double, format:String) -> String {
　　return NSString(format:format, value)
}

println( d % "%5.2f") //1.23
println( d % "%5.1f") //1.2

// 　よりは美しい
0085デフォルトの名無しさん
垢版 |
2014/06/23(月) 00:31:08.05ID:IjFKX6YY
フォーマットはセキュリティのリスクがあるからSwiftには入れてないんだ
フォーマットしたかったらNSFormatter使えって言ってたから、そういう仕様なんだよ
0086デフォルトの名無しさん
垢版 |
2014/06/23(月) 07:12:49.72ID:KA1AMTg4
多言語対応するなら全く役に立たないし
せいぜいデバッグに使う程度のおまけ機能ってこと
0088デフォルトの名無しさん
垢版 |
2014/06/23(月) 09:11:06.74ID:2Cm/+3gI
他言語化する時は結局Swift版のNSLocalizedStringを呼んでstringWithFormatに突っ込むんだろうな
0089デフォルトの名無しさん
垢版 |
2014/06/27(金) 09:35:43.36ID:xawLBmcE
◎2chスレッド勢いランキングサイトリスト◎

★+ニュース板
・ 2NN (推奨サイト)
・ 2chTimes
★+ニュース板新着
・ 2NN新着
・ Headline BBY
・ unker Headline
★+ニュース板その他
・ Desktop2ch
・ 記者別一覧
★全板
・ 全板縦断勢いランキング (推奨サイト)
・ スレッドランキング総合ランキング
・ ログ速
★全板実況込み
・ 2勢 (推奨サイト)
・ READ2CH
・ i-ikioi

※ 要タイトル検索
※ 2chブラウザ併用推奨
0091デフォルトの名無しさん
垢版 |
2014/06/28(土) 15:22:27.04ID:I8uTErQI
FormatだけならFormatterを使えば済む話。
でも正規表現的な物もあった方が良いと思う。

話は変わるが、ターミナル上でSwiftをインタプリタとして動かして見るとちょっとした感動が有った。
これでJavascriptの代わりに使えれば言うこと無いんだが。
もちろん全ての環境で動かすことは難しいだろうから、MacOS iOS環境だけで良いけど。
iOSでターミナルを解放することも無いだろうから、WebKitの中だけでも良い。これは結構実現性が高いと踏んでいる。
0094デフォルトの名無しさん
垢版 |
2014/06/28(土) 18:43:31.30ID:I8uTErQI
>>93 既にWebKitにLLVM が乗って、JavascriptのVMが動き始めてるの知ってる？ みんな次のバージョンでサポートする。スピードが30%上がる。
iPhoneだとiOS8から。今ベータが動いてる。

swiftはLLVMのLLDBでインタプリタを実現してるから、Javascripが動く環境で動かすのは容易い話であり、WebKitの主導者のAppleが入れてしまえば多分抵抗なくみんな使い始める。
最初はプラグインか何かのオプションになるだろうが。
とは言っても、1〜2年はかかるだろう。
0095デフォルトの名無しさん
垢版 |
2014/06/28(土) 18:48:52.76ID:I8uTErQI
LLVMベースが何を意味するか解るか？
Javascript の中間コードとSwiftの中間コードは同じなんだから、JavascriptのVMが動くと言うことはSwiftのVMも動くと言う事。

標準採用されるまでに時間がかかるのは当然。
0096デフォルトの名無しさん
垢版 |
2014/06/28(土) 19:20:18.14ID:zES9UvXE
いや、別言語をAppleの手の中で動かせるのは当然わかる

それが他の環境、WindowsとかAndroidにも対応しないとはやらない
移植性のよさが利点のWebの分断は批判が大きいだろう
そのためにはJavascriptを中間コードから生成せねばならないが、そこでTypeScriptやCoffeeScriptと戦って勝てるのか

WebKitのシェアはblink移行で下がってるから、ハイブリットアプリで内部て使うとかがいいとこじゃない？
0097デフォルトの名無しさん
垢版 |
2014/06/28(土) 19:23:26.17ID:zES9UvXE
直接実行できるのだけが利点なら、VBScript、Dartがすでにあるけど、どれもまず聞かないという
0099デフォルトの名無しさん
垢版 |
2014/06/29(日) 04:35:38.07ID:oBe1BEgf
>>94
見たらアグレッシブな最適化の部分だけじゃないか。
js をパースして次が LLVM IR ならともかく、話が全然違う。
聞いたことないし GC どうすんのかとかあるし、なんかおかしいと思ったんだよ。LLVM が何かわかってない発言だ。
0100デフォルトの名無しさん
垢版 |
2014/06/29(日) 08:19:56.40ID:mYSKVn4w
>>99 どんな記事をみたのか知ら無いが、LLVM IR にコンパイルして実行するんだよ。そのIRを最適化する。
第４層最適化。GCは何らかの方法で実施している模様。

AppleがLLVM JITを使用してWebKitのJSエンジンをスピードアップ
http://www.infoq.com/jp/news/2014/05/safari-webkit-javascript-llvm?utm_reader=feedly

オリジナルの発表
https://www.webkit.org/blog/3362/introducing-the-webkit-ftl-jit/

http://www.webkit.org/blog-files/ftl-jit/ftl_pipeline.png
0101デフォルトの名無しさん
垢版 |
2014/06/29(日) 09:44:26.93ID:f8exIVV0
それ以前にSwiftがオープンになることはないでしょ
そんなことしたら「あえて」特に何も新しくない新しい言語を作った意味が無くなる
意味わかるでしょ?
0102デフォルトの名無しさん
垢版 |
2014/06/29(日) 10:01:59.85ID:OApS8+mw
オープンソースにしない限り、幅広い分野でっていうのは無理だな
Microsoftはオープンソース化が多くなってるのに、appleはどうなんだ
0104デフォルトの名無しさん
垢版 |
2014/06/29(日) 12:19:42.92ID:mYSKVn4w
>>101 Objective-Cですらオープンソースにしてるのに、しない理由が解ら無い。

>>102 Apple は、言語系、Web系は殆どオープンソースだよ。
WebKitとLLVMはその要だろう。

早くオープンソースにしてLLVM実行環境だったら使えると言う状態に持って行って欲しい。

SwiftはLLVMと密接に結びついており、拡張性は高い。オープンソースにはまだなってい無いが、LLVMを軸に動いてる事は事実だし、Appleの判断次第。
使うか使わ無いかは使う側の判断。

C やObjCとも混在出来るし、LLVM IRからは既にJavascript やJavaをすら生成出来る。(一時しのぎにしかなら無いだろうが)
0105デフォルトの名無しさん
垢版 |
2014/06/29(日) 12:36:23.68ID:mYSKVn4w
TypeScriptは、確かに必要性は解るがあくまでもツール的な存在では無いだろうか。
例えば核の言語のプリプロセッサやライブラリ的な存在。
C にプリプロセッサ的に追加したObject-C の様に。
つまりなくても困ら無い。
TypeScriptがJavaScriptの拡張版と言ってもブラウザで直接実行出来無い限り本流にはなり得無い。

Swift はどうかと言うと、核の言語。 王道を歩むつもりの様だからオープンソースになり使う人が多くなれば普及も早いと思われる。
SwiftScriptが出来るかどうかは、単なる憶測の範囲。
0106デフォルトの名無しさん
垢版 |
2014/06/29(日) 13:35:06.34ID:OApS8+mw
>>105
オープンソースになっても、言語仕様的にほかより優れてるの？そうじゃないと他の環境までは、はやらない

所詮Appleの中の言語にとどまると思う

ブラウザの直接実行は、Microsoft,Apple,Google,Firefoxの4勢力が協力しない限り達成不能
そして、Web共通言語のjs以外で足並みを揃えるのは無理だし、Apple的にはほかの会社に自社言語の開発の中心に居座られたくない気がしそう

TypeScriptなんかがプリプロセッサなのはjavascriptによる過去の資源との互換性を保つためで、どの言語にもjsの置き換えを狙うのが無理そうだからだよ
0108デフォルトの名無しさん
垢版 |
2014/06/29(日) 14:57:50.22ID:mYSKVn4w
>>107 そもそも、HTML内埋め込みインタラプト言語のJavaScript系と、オールマイティーなコンパイル言語系では用途が全く違う。

だから、TypeScript と Swift を対比すること自体に無理が有るけど、Swiftがインタプリタとしても動いたりスクリプトとしての可能性も匂わせてるからこのスレに上がったんだろう。

元々は全く違う用途。
0109デフォルトの名無しさん
垢版 |
2014/06/29(日) 15:02:09.40ID:OApS8+mw
>>108
スクリプトとして動きそうというだけならC#なんかもそのうち動きそうだけど
Roslynもできたし、IOSを含め他の環境でももう動いてる
0110デフォルトの名無しさん
垢版 |
2014/06/29(日) 15:16:22.91ID:mYSKVn4w
>>106 >言語仕様的にほかより優れてるの？

そんな事は言うまでも無い。
各種言語の良い所取りした言語だから、他の言語からも反対する意見は殆ど皆無。
特に今後のコンピュータ言語教育に果たす役割は大きいと思う。

多少癖が有りそうなのは、スピードを重視した仕様 (これは認められるだろう) とC や ObjCとの相互結合を考慮した点( 現実解 )
これらも何ら足かせには成ら無いだろう。 必要ならそれなりのライブラリが出来るだけ。

プリプロセッサを排除した分、言語仕様の中で自分自身をを書き換える(オーバライド) 事が出来るのは今後の発展性を匂わせる。
0112デフォルトの名無しさん
垢版 |
2014/06/29(日) 15:31:53.02ID:mYSKVn4w
>>109 スクリプトとして動きそうと言うだけと、動く事を見据えた言語では仕様が異なる。

Swiftは動的関数な部分が大きい。 最初からそう言う言語だからスクリプトとして動かしても性能を発揮出来る。
遅延評価lazy とか。
0113デフォルトの名無しさん
垢版 |
2014/06/29(日) 16:24:07.43ID:OApS8+mw
ObjCとの比較を除けば、他言語との比較はまだ文法的に比較してここら辺似てるとか言ってる段階でなんとも言えないなあ
まだベータ版だし、Appleがどこまで公開するかと他環境への展開待ちかな
0114デフォルトの名無しさん
垢版 |
2014/06/29(日) 16:50:02.83ID:mYSKVn4w
コンピュータなんだから、どんな言語でも出来ないことはツギハギでも追加して出来る様にして行くから、出来ることは殆ど同じになるんだよね。

要は如何にスマートに実装するかどうかじゃ無いのかな。
ツギハギ言語では辛い場面が出る。

Swiftと言えど、過去のしがらみを全て捨てるわけにはいかなかったみたい。
過去の遺産を使う限り仕方ないだろうね。
生糸から紡ぎ治せれば良かったが、古着をほどいた糸で紡ぎ直したと言う感は否め無い。
011999
垢版 |
2014/06/30(月) 00:47:03.04ID:nIm5vaJz
>>100
どこをどう読んだらそんな誤解できるんだ。
一部分だけを LLVM IR を通してコンパイルするだけで、Javascript の VM が LLVM で動いているわけじゃない。
ただの JIT コンパイルであって、Javascript の VM から LLVM で JIT コンパイルしたコード小片を呼び出しているだけ。
GC は実装したんじゃなくてWebKit メモリマネージャに同居する手法を紹介してる。

つーか最初に js バイトコードになるってどっちの記事にもあるだろ。
その記事の Webkit の話なら Swift を LLVM IR に持っていく前に、最初の段階で js バイトコードにする必要があるだろ。
>94 の
> （略）Javascripが動く環境で動かすのは容易い話であり、（略）
とはならない。
Swift を js や js バイトコードに変換すれば別だが。

ほんとちゃんと読んでから言いふらしてよ。誤解する人が出て誤解が広まったらどうするんだ。

> swiftはLLVMのLLDBでインタプリタを実現してるから、
これも誤解なんじゃないか。
Playground は VS のエディットコンティニュのようなことをやってるんじゃないのか。
元々 Xcode で Obj-C/C++ の式を実行時に評価できたし、Swift なら多くの場合にセレクタの差し替えで済むわけだから、
LLDB が VM を持っててインタプリットしていると考えるのは不自然だ。
ちょっと検索してみたところでは、インタプリタとして動作していると信じている人は見つからなかった。
ソースがあれば出してくれ。
0120デフォルトの名無しさん
垢版 |
2014/06/30(月) 01:35:18.75ID:2Uifxpzh
>>119 Playgrounds はXcodeのデバッグウインドーで動くもの。　リアルタイムデバッガと言って良いだろう。

LLDBが動くのは、ターミナル上でSwiftインタプリタを動かしたとき。　インタプリタ上のデバッグコマンドはLLDBコマンド。
実際は、Xcodeがインタプリタの実権を握っているのかもしれないが動作を制御しているのはLLDB
インタプリタを動かして、 :helpを打てばLLDBのコマンドリストが出てくる。　完全なインタプリタとは言い切れないがほぼリアルタイムにコンパイル実行しているから使い勝手は全くインタプリタ。
途中でLLDBコマンドを使ってPythonを呼び出したりもできる。

1> :help

The Swift REPL (Read-Eval-Print-Loop) acts like an interpreter. Valid statements, expressions, and declarations are
immediately compiled and executed.

The complete set of LLDB debugging commands are also available

Swiftのインタプリタモードが楽しい
http://qiita.com/dll7/items/206d5bf0cb72942b3681

1> let t = 10
t: Int = 10
2> let t = 1.0
t: Double = 1
3> let t = "a"
t: String = "a"
4> t = "hello"
5> println(t)
hello
0122デフォルトの名無しさん
垢版 |
2014/06/30(月) 09:46:26.06ID:+/AeVnyE
>>120
＞The Swift REPL (Read-Eval-Print-Loop) acts like an interpreter.
「SwiftのREPLはインタプリタのように動作する」
つまり実際にはインタプリタでは無いんだよ
0123デフォルトの名無しさん
垢版 |
2014/06/30(月) 10:53:35.14ID:2Uifxpzh
>>122 だったらどうなんだ？

そもそもインタプリタの定義なんてこんなもの
https://ja.wikipedia.org/wiki/%E3%82%A4%E3%83%B3%E3%82%BF%E3%83%97%E3%83%AA%E3%82%BF
１．ソースコードを直接実行する。
２．ソースコードを何らかの効率的な中間表現に変換し、それを即座に実行する。
３．システムの一部であるコンパイラが生成し出力した、コンパイル済みの中間表現を実行する[1]。
　ソースプログラムはマシンに依存しない中間的なコードに事前にコンパイルされ、実行時にリンクされ、インタプリタで実行される

Javaなんかよりよほどインタプリタの王道に近い動きをするぞ。
Perlなんかよりも使いやすい。

REPL
https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop　
この定義では、LISPもコマンドラインスクリプトもREPLに入る。
0124デフォルトの名無しさん
垢版 |
2014/06/30(月) 11:03:44.45ID:+/AeVnyE
>>123
SwiftのREPLは逐次ネイティブコードに変換してから実行してるだろうからその1〜3に当てはまらない

REPL=インタプリタ では無いよ？
0125デフォルトの名無しさん
垢版 |
2014/06/30(月) 11:22:20.22ID:0ZRqmqkf
VSなんかILのインタプリタが搭載されてて
ダンプ情報をデバッガに読ませてエディットコンティニューなんて荒業が可能らしいよ
0127デフォルトの名無しさん
垢版 |
2014/06/30(月) 15:00:27.03ID:2Uifxpzh
>>123 のWikの中の説明では中間コードを取らないインタプリタも有る。

>バリエーション
>動的コンパイルを使っているインタプリタは、内部で実機の機械語に変換し実行する。i

Swift/REPL はこれにあたる。

Using Swift As General Purpose Scripting Language
http://www.strathweb.com/2014/06/using-swift-general-purpose-scripting-language/

-emit-assembly　Emit assembly file(s) (-S)
-emit-bc 　　　　　Emit LLVM BC file(s)
-emit-executable Emit a linked executable
-emit-ir 　　　　　　Emit LLVM IR file(s)

ここにあるようにアセンブラから、LLVM IRまで様々なファイルを作り出せる。
LLVM IRが動かない訳が無い。（REPLモードの時にIRが使えるかどうかは知らないが）

呼び方なんか何でも良い。　汎用スクリプト言語として使えると言う事実。　これが全て、　
You can use Swift as general purpose scripting language for all kinds of OS tasks or any automation scripts;
0128デフォルトの名無しさん
垢版 |
2014/06/30(月) 15:05:01.81ID:2Uifxpzh
>>127 言い忘れた。　コンパイラは、MacOS上で動かしていてもコンパイル結果をターゲットのARMとしての出力が出来るのは当然。
だからと言ってARMの機械語で動かしている訳でない事も当然。

この意味が解るか？　機械語を実行している訳じゃないんだよ。
0129デフォルトの名無しさん
垢版 |
2014/06/30(月) 15:24:33.50ID:+/AeVnyE
>>127
だからさ、LLVM使ってればLLVM-IRとか出力できるのは当たり前なんだって
だけどLLVM-IRのファイル作れてもそれを直接解釈実行する仕組みはどこにあるんだ？

現状LLVMの仕組みを利用してインタプリタの"ような"動作するものはいくつかある
上でも挙がってるSafariの最終レベルのJTTとか、ChromeのPNaClとか、AndroidのARTとか

これらは全部LLVMを使ってるけど、LLVM-IRを解釈実行する仕組みをもってるわけではなくて、
LLVM-IRからネイティブなコードまで変換してから、LLVMとは無関係な機構で実行する

Swiftがスクリプト言語のように使えるとしても、それはLLVMとは関係無い
LLVMはネイティブコードを生成するために使ってるだけ
LLVMと無理やり結びつけて煽るのを止めてくれるかな？
0130デフォルトの名無しさん
垢版 |
2014/06/30(月) 15:31:16.96ID:+/AeVnyE
>>128
コンパイラなんてただの変換処理系なんだから、
コンパイラを動かしてるマシンやOSとコンパイラが出力するコードが関係無いのは当たり前じゃないか
そんなことをいちいち説明するのに何か意味があるのか？
0137デフォルトの名無しさん
垢版 |
2014/06/30(月) 23:36:17.56ID:2Uifxpzh
驚いたな。　こんな質問が飛び出すとは。
https://ja.wikipedia.org/wiki/%E3%82%A2%E3%82%BB%E3%83%B3%E3%83%96%E3%83%AA%E8%A8%80%E8%AA%9E
アセンブラは、アセンブリ言語を機械語に変換するプログラムソフトの事。　コンパイラに対応。
アセンブリ言語の意味で「アセンブラ」または「アセンブラ言語」(Assembler Language)と呼ぶ場合も多い
assembler
0140デフォルトの名無しさん
垢版 |
2014/06/30(月) 23:45:39.62ID:2Uifxpzh
>>138 いや最近の安い辞書に　assembler と言う訳が載っていないことに驚いたんだよ。
昔はassemblerの方が一般的だったのに。
質問が出てきた意味が解った。　assemblyの語源はassembler 。

少なくともプログラムする人間は、コンパイラ、アセンブラと言う言葉位は知っておいてほしいな。
0141デフォルトの名無しさん
垢版 |
2014/07/01(火) 00:04:40.17ID:sZ99gDnh
>>140
なんでそんな自信たっぷりに適当なことを撒き散らせるんだ
普通、語源と言ったらassembleかassemblyの方だ
erを付けて〜するモノって意味になるのだよ
0145デフォルトの名無しさん
垢版 |
2014/07/01(火) 01:17:33.69ID:sZ99gDnh
フランス語のassemblerと英語のassemblerは意味がちょっと違う
>>143はフランス語のassemblerが英語のassembleになったってことだぞ
そして英語では、そのassemble+erでassembleするものって意味になるわけだ

万が一ｗ、>>140のassemblerをフランス語の意味で使ってたならすまんかったなｗ
0147デフォルトの名無しさん
垢版 |
2014/07/01(火) 02:15:49.54ID:FsIt2ttm
>>144 コンピュータ用語としてはassembly 単独では使わない。
assembly language 、assembly fileなど、修飾名詞として使われる。
assemblerは単独で使われる。

Oxford assembly
[MASS NOUN, USUALLY AS MODIFIER] Computing The conversion of instructions in low-level code to machine code.
http://i.imgur.com/FWAkUWi.jpg
0150デフォルトの名無しさん
垢版 |
2014/07/02(水) 01:21:30.49ID:W0bsvEa6
>>120
ええと、それで >94 を正当化できるの？
別に on the fly でコンパイルするシステムをインタプリタと呼んではいけないとは思わないが、
例えば CINT が JIT 積んだらほとんどそうなるわけだし、だが LLVM IR をインタプリットしないと
>94 は成り立たないだろう。

>>128
IR を実行するわけじゃなくて IR を機械語に変換するんだよ。otool とかで見てごらん。
gcc で内部的に psuedo op code を使うようなもんだよ。

だから
>>127
> 呼び方なんか何でも良い。　汎用スクリプト言語として使えると言う事実。　これが全て、　
が正しくても >94 は成り立たないんだよ。

>94 を捨てて別の主張を始めること自体は構わないけど、今度は >94 のような出鱈目を吹聴しないようにしてね。
0151デフォルトの名無しさん
垢版 |
2014/07/02(水) 02:00:05.61ID:C0tb1eHd
インタプリタではないがこれ面白いぞ。

LLVM IR をWEB上で変更して実行するデモ。
http://kripken.github.io/llvm.js/demo.html
emscriptenと言うプログラムで、LLVM IRをJavaｓｃriptに変換している。

実際に動く所を見ると興味がさらにわく。　SwiftのLLVM IRからJavascriptを吐き出せる。

Emscripten
https://github.com/kripken/emscripten/wiki
Emscripten is an LLVM to JavaScript compiler.
It takes LLVM bytecode (which can be generated from C/C++ using Clang, or any other language that can be converted into LLVM bytecode)
and compiles that into JavaScript, which can be run on the web (or anywhere else JavaScript can run).

ここに変換した後のJavascriptのデモが有る。
https://github.com/kripken/emscripten/wiki
結構それなりに動いてる。
ゲームも面白いが、　EmulatorsのClassic Mac OSも面白い。　それなりに実機のように動く。
LLVM IRと言うのが一番最初にあげたデモと同じ。

面白いな、LLVMを介して色んな言語がHTML上で動くことになる。
Swiftの応用範囲が広がるね。

LLJVM interpreter　と言うのは、LLVM IRからJava　byte code を作り出してる。
http://stackoverflow.com/questions/4934707/is-it-possible-to-transform-llvm-bytecode-into-java-bytecode
0153デフォルトの名無しさん
垢版 |
2014/07/03(木) 00:31:43.56ID:/QLPOJJ3
>>151 NaClやPNaClも一応動いてるんだな。　Chromeでサンプルが見れる。

asm.jsとかPNaClとかLLVMに興味あったので調べて回ったら少しだけ理解できた話
http://d.hatena.ne.jp/hdk_embedded/20131128/1385669904

Web周りの言語
Google----(Chrome拡張で一部デモが見れる)
任意　(NaCl　LLVMコンパイル)　機械語 　ターゲット依存
PNaCl　　　　LLVM IR >　機械語　（今は拡張機能？）
　　　　　　　LLVM IR >　Javascript(Emscripten/pepper.js　)
Dart　クロスコンパイルin ブラウザ　/　JIT？
pepper.js とPNaClのExample
http://trypepperjs.appspot.com/examples.html

Mozzila---
asm.js　　（ LLVM IR >）　Javascript(Emscripten/asm,js)

WebKit---
javascript　（LLVM IR)　JIT（一部）
（Swift　＞LLVM IR　＞ Javascriptは可能だが公式発表は無し）

Microsoft---
Typescript->Javascript
VSにEmscriptenプラグイン
--------------
LLVMがカギを握ってるみたいに見える。　すぐに実用的なのがEmscripten
（但しライブラリが機械語の物はリンク不可能）
LLVM IR実行環境の流れは時間がかかりそうだが、進みそう。
（セキュリティの問題が有る）
0154デフォルトの名無しさん
垢版 |
2014/07/03(木) 01:14:36.62ID:9OGBgTec
LLVM-IRからJavaScriptに変換できても、
元のコードが使ってるAPIからJavaScriptのAPIに変換する仕組みの実装が高難易度で不十分なせいで実用には遠い
printfで出力垂れ流す程度なら簡単なんだけどね

LLVM-IRを直接解釈して実行する仕組みを作る場合も同じような問題をクリアする必要がある

苦労してその問題をクリアできてもパフォーマンスガタ落ちは避けられないんで、真剣に取り組む人がいない
0155デフォルトの名無しさん
垢版 |
2014/07/03(木) 01:25:30.74ID:/QLPOJJ3
>>153 そのExampleの Voronoi　でベンチマークしてみた。
Emscriptenが13.681秒　PNaCl が6.723秒　倍違うね。
0156デフォルトの名無しさん
垢版 |
2014/07/03(木) 01:38:00.13ID:/QLPOJJ3
>>154 一般APIを使うとみんなダメだろ。　
Webブラウザで動けるAPIだけを使うと言うように限定しないと当然リンクエラーだよ。
あくまでもWebアプリなんだから。
Hello Worldだって、ブラウザ上に表示しないといけないんだからね。　標準出力なんか使えないよ。
HTMLダイレクトかJavascriptを通して表示させるとかやらないと。　HTMLも知らない人が使おうたってそりゃ無理だよ。
0158デフォルトの名無しさん
垢版 |
2014/07/03(木) 01:56:26.86ID:/QLPOJJ3
>>153 　Earth　ベンチマーク
Emscripten 8.6秒　0スレッド（スレッド指定不可）
PNaCl 　　0スレッド　2.5秒　　8スレッド　1.23秒
0159デフォルトの名無しさん
垢版 |
2014/07/03(木) 02:03:00.95ID:9OGBgTec
逆に元の言語でブラウザのAPIを使ってそれをJavaScriptに変換する場合は
元の言語側でブラウザのDOMにアクセスするような(仮想的な？)ライブラリを用意して
それをうまいことJavaScriptのコードに対応づけてやる必要があるだろうな
例えばEmscriptenはそういう仮想的なライブラリを各言語毎に用意してんの？
0160デフォルトの名無しさん
垢版 |
2014/07/03(木) 02:07:16.47ID:/QLPOJJ3
>>157 あらゆる言語が有るんだから全ての言語がCライブラリを利用している訳でもないし、
全てのCライブラリが変換出来る訳でもない。
コンパイル環境によってリンクされるライブラリも違うだろうし、
VSでコンパイルすれば多分エラーのオンパレードになるだろう。
0161デフォルトの名無しさん
垢版 |
2014/07/03(木) 02:09:41.14ID:vth2CvYs
最終的にC,C++を経由しないライブラリなんてあるのか？
Pythonとかも動いてんだ
何の問題もない
0162デフォルトの名無しさん
垢版 |
2014/07/03(木) 02:23:50.93ID:9OGBgTec
>>160
Emscriptenの仕組みを根本的に勘違いしてる？
これはC言語の一般的なライブラリ(libcとかSDLとかもいけるらしい)にリンクされた形式のLLVM-IRを入力にして、
JavaScriptを出力するものだと思うんだけど

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

各言語毎に用意された独自の様々なライブラリとリンクされたLLVM-IRを
漏れなくJavaScriptに変換できるとしたらそれはものすごい規模の仕組みになると思うけど
そんなの神業すぎて有り得ん
0163デフォルトの名無しさん
垢版 |
2014/07/03(木) 02:33:38.51ID:9OGBgTec
だから>>153のこれも
（Swift　＞LLVM IR　＞ Javascriptは可能だが公式発表は無し）
まだ現実的には意味が無いはず

すべてのLLVM-IRをJavaScriptに変換できるわけでは無い
変換可能なのはEmscriptenがサポートする範囲のライブラリがリンクされたLLVM-IRなわけ
今のSwiftにはまだEmscriptenがサポートするライブラリとか用意されてないよね
0164デフォルトの名無しさん
垢版 |
2014/07/03(木) 08:49:38.57ID:2Ze3kKMg
SwiftをJavaScriptに変換したところでアプリがそのまま移植できるわけではないし
(APIを移植したらAppleに訴えられるだろう)
どうせ互換性がないなら無理にSwiftやemscriptenなんか使ってコードを肥大化させる必要なんかない
それこそTypescriptやCoffeeでいい
0165デフォルトの名無しさん
垢版 |
2014/07/03(木) 12:34:47.74ID:/QLPOJJ3
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 がライブラリをエミュレートしない限りはかなり難しいだろうな。
0167デフォルトの名無しさん
垢版 |
2014/07/03(木) 17:06:52.84ID:LsDaD5j+
>>163
> すべてのLLVM-IRをJavaScriptに変換できるわけでは無い
> 変換可能なのはEmscriptenがサポートする範囲のライブラリがリンクされたLLVM-IRなわけ

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

OpenGL→WebGLみたいにJavaScriptのAPIにマッピング出来るライブラリがあるかないかと
変換出来るかどうかを一緒にしては駄目だ
0168デフォルトの名無しさん
垢版 |
2014/07/03(木) 17:10:36.81ID:/QLPOJJ3
Dartプログラミング言語をGoogleのApp Engineがサポート…ついにサーバ言語としても位置づけ
http://m.jp.techcrunch.com/2014/07/01/20140629googles-dart-programming-language-is-coming-to-the-server/

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

あまり使いたいと思わせる要素は少ないな。あるのは数の力かな。
多分この辺りの言語戦争がWebKit内で有って分裂したんじゃ無いだろうか。表面は違うが。
0169デフォルトの名無しさん
垢版 |
2014/07/03(木) 17:16:30.98ID:/QLPOJJ3
>>167 その通り、全て言語的には変換出来る。
出来ないのは、リンク結合出来るか出来ないか。
だから使えるか使えないかと言ったら、使い方次第。
無理して使う人は少ないだろうが。
0170デフォルトの名無しさん
垢版 |
2014/07/03(木) 17:18:28.55ID:9OGBgTec
>>167
少なくともEmscriptenによるJavaScriptへの変換は
マッピングされてないライブラリをリンクしてるLLVM-IRをJavaScriptのコードには変換できないだろ？
ネイティブコードへ変換する通常のLLVMのバックエンドとはちょっと事情が違う
0171デフォルトの名無しさん
垢版 |
2014/07/03(木) 17:25:03.31ID:y3Vpqy8O
>>170
Emscriptenはリンクする前にJavascriptへ変換すんだよ。あんまり半端な知識で知ったかぶりしないほうがいいぞ
0172デフォルトの名無しさん
垢版 |
2014/07/03(木) 17:26:35.21ID:9OGBgTec
>>169
だからEmscriptenは通常のLLVMバックエンドと違って実際にリンク結合するわけじゃいんだってば
リンク結合されるべき部分を無理やりEmscriptenが用意してるJavaScriptランタイムの呼び出しに変換する
その変換が用意されてないライブラリの呼び出しを見つけたらEmscriptenの変換は失敗するわけ
0173デフォルトの名無しさん
垢版 |
2014/07/03(木) 17:31:02.65ID:9OGBgTec
>>171
実際にリンクするわけじゃないだろ？
呼び出すJavaScriptランタイムがなければそれはEmscriptenにとっては変換失敗じゃないか
0174デフォルトの名無しさん
垢版 |
2014/07/03(木) 17:40:23.64ID:9OGBgTec
>>170はちょっと書き方が悪かったなライブラリをリンクしてるというかライブラリの関数を呼び出してると書くべきだった
そしてライブラリ関数の呼び出しはとりあえずJavaScriptに変換されて、
Emscriptenが用意してるJavaScriptとランタイムと一緒に実行したときに
ランタイムがそのライブラリ関数をサポートしてれば実行されるし、サポートしてなければ実行時エラーになるのか
このへんはちょっと勘違いしてた
0176デフォルトの名無しさん
垢版 |
2014/07/03(木) 17:50:05.06ID:9OGBgTec
だからとりあえずどんなLLVM-IRでもJavaScriptへの変換は可能。これは訂正しとくは

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

Cocoaに相当するランタイムは実質不可能だろう
SwiftからDOMにアクセスするランタイムは作れなくも無さそうだけど、
Swift側のAPIを決めて、それにマッピングするようランタイム作る必要があるわけだ
0180デフォルトの名無しさん
垢版 |
2014/07/06(日) 11:16:42.61ID:uI+Octwc
>>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

なんだかすごく楽しみだな。
0181デフォルトの名無しさん
垢版 |
2014/07/06(日) 12:59:26.62ID:uI+Octwc
>>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のソースの混在も可能になるだろう。
0183デフォルトの名無しさん
垢版 |
2014/07/06(日) 13:41:28.52ID:J6LM3Iar
>>181
そのリンクの先はOSX上でJavaScriptからCocoa関係にアクセスするための仕組みのように見えるんだけど違うの？
>>176とはほとんど関係無くない？
0185デフォルトの名無しさん
垢版 |
2014/07/06(日) 16:55:42.10ID:uI+Octwc
>>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に変換してるが、もし統一中間コードが決まればダイレクトにそのコードにコンパイルする様になるだろう。 その方が効率が良いはずだから。
0186デフォルトの名無しさん
垢版 |
2014/07/06(日) 17:04:40.34ID:J6LM3Iar
>>185
JavaScriptからCocoa呼び出せても、ネイティブなCocoaがあるOSでしか動かないじゃない？
そんなのは一般的なWebクライアント用言語としては使えないよ
0187デフォルトの名無しさん
垢版 |
2014/07/06(日) 17:48:41.56ID:uI+Octwc
>>186 Java Appletが、動ける範囲を制限してる様に、何らかのクラスの下でだけ動ける様にするはず。
極端な話WebKitの範囲内だけとか。要はJavaScriptが動ける範囲内だけで良いんだよ。WebKitAppクラスとか。

別に汎用のCocoaを網羅する必要は無いし動いたら却って怖い話。 そんなのセキュリティ上有り得ない。
0188デフォルトの名無しさん
垢版 |
2014/07/06(日) 17:53:53.35ID:5z9UYEB8
あんたが言ってるようなのって今現在沢山あるぞ?
どれも中途半端でイマイチ流行らないけどね
OSのAPIをひたすらラップするだけの作業だから
手間さえかければ良い物ができるよ
>>187による実装に期待
0189デフォルトの名無しさん
垢版 |
2014/07/06(日) 18:03:43.16ID:J6LM3Iar
>>187
クラスの下で動くって意味がわからないよ
そのクラスっていうのは実体が何で、世の中の一般的なブラウザはそれをどうやって利用するの？
0190デフォルトの名無しさん
垢版 |
2014/07/06(日) 18:18:44.85ID:uI+Octwc
>>186 それとクラスと言ってもそれは上位言語の話で有って、中間言語などに降りてきたらクラスなんか関係無い。
単なる汎用のマシン語が動くかどうかの世界。

ただ、まっさらなマシン語の実行を許すと大きなセキュリティの危険にさらされるから、何らかのガードの元で実行出来る様にするはず。
0191デフォルトの名無しさん
垢版 |
2014/07/06(日) 18:22:58.33ID:J6LM3Iar
>>190
だからその中間言語を一般的なブラウザでどうやって実行するつもりなんだって聞いてるんだ
プラグインか？JavaScriptランタイムか？アップルはそんなもの提供するなんて一言も言ってないだろ
0194デフォルトの名無しさん
垢版 |
2014/07/06(日) 20:13:32.73ID:uI+Octwc
>>191　一般ブラウザは中間コードじゃなくて単なるJavascriptだよ。
つまり、Native/bytecode またはJavascriptの両方出力できるようにするはず。　Dartも同じ。
多分HTML上も両方スイッチできるようにしておいてクライアントに応じてどちらかをダウンロードする形。
0195デフォルトの名無しさん
垢版 |
2014/07/06(日) 20:25:18.93ID:uI+Octwc
>>191 >JavaScriptランタイムか？アップルはそんなもの提供するなんて一言も言ってないだろ
全て妄想の範囲だよ。　だが現実味が強い。

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

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

前者はかなり大変な仕組みだからアップルが何の発表もしてない時点で現実味が全く無い
0198デフォルトの名無しさん
垢版 |
2014/07/06(日) 21:16:00.20ID:uI+Octwc
>>196 逆にJavascriptに変換すると言う事は、javascript実行環境で使うのであればJavascript内でクローズしていれば良いのだから複雑なライブラリは必要ないとも言えるのでは？
だからすべてのブラウザで動く事が出来る。
Javascriptに変換した後の環境は単にウエブブラウザのJavascriptインタプリタのみ。　
必要なランタイムライブラリはインタプリタが実装していると言える。
0199デフォルトの名無しさん
垢版 |
2014/07/06(日) 21:36:38.50ID:J6LM3Iar
>>198
そうだよ。単にDOMにアクセスするためなら複雑なランタイムは必要無い
だから>>181のJavaScriptからcocoaを呼び出す仕組みとか関係無いってことだ
0200デフォルトの名無しさん
垢版 |
2014/07/06(日) 21:44:52.63ID:c4JqBC4F
WebになるとSwift関連ツールがWindows向けに提供されない場合、Windowsでのデバッグがやりにくくなる
スマフォ用Webアプリには使われても、直ぐに後追いが出てマルチプラットホームでのツール提供をすればそれに越されそう
0202デフォルトの名無しさん
垢版 |
2014/07/28(月) 12:30:56.51ID:4XV/yzRg
emscripten使えばわかるけど、生成されたゲロみたいなjsコードのデバッグは非常に困難
極めて綺麗なJSを吐くTypeScriptとは一緒にしてはいけない
0203デフォルトの名無しさん
垢版 |
2014/07/28(月) 13:21:39.99ID:zl94e36f
>>202 どのレベルのJSを吐くかによるだろ。　EmScriptenはasm.js を吐き出すんだろ？
性能を取るか視認性を取るかの違いだろ。
asm.jsを吐き出しても元のソースコードをコメントで入れてあれば見やすいのにそれはしていないんだろうな。
そのうち成長してくるだろう。
0206デフォルトの名無しさん
垢版 |
2014/07/28(月) 14:39:54.10ID:4XV/yzRg
>>203
ジェネレータは関係ない
コンパイル時のデバッグ情報を使わない限り、IRの時点でデバッグは十分困難だから
0207デフォルトの名無しさん
垢版 |
2014/07/28(月) 15:22:21.31ID:WmVK7Shw
>>206 詳しいことは知らないんだけど、IRにまでデバッグ情報は持ち込めるんじゃ無いの？
IRを使ってLLDBでデバッグ出来るんだから。 LLDBはClangでしかデバッグ出来ないの？
0209デフォルトの名無しさん
垢版 |
2014/08/05(火) 17:59:50.13ID:DgDBu3xR
>>202 あのね、コンパイラ言語はソースでデバッグするだろ、アセンブラでデバッグする事は滅多にないよ。
0210デフォルトの名無しさん
垢版 |
2014/08/05(火) 21:08:06.58ID:ghCtuQ0N
>>209
TypeScriptと同じ土俵ってところへの突っ込みでしょ。TypeScriptにとってJSは中間言語じゃない。
あっちはデバッガ含めJS資産を完全にシームレスに活用できるのが売り。
最悪、生成されたJSコードをベースにしてJSに戻って開発を続けることも十分可能なほど。
0211デフォルトの名無しさん
垢版 |
2014/08/05(火) 21:51:55.04ID:q3/M2RFT
言語が違うんだから、デバッグ方法が異なっても当然だな
しかし、JSのデバッグはお世辞にもデバッグしやすいとは言えないだろ。
0212デフォルトの名無しさん
垢版 |
2014/09/17(水) 19:13:24.03ID:C5lp8vtK
iPhone修理の仕事してる人っている？
iPhone6とかすでに受け取ってるんかね？

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

可愛い女の子も多いし応募してみようかと思ってる
0213デフォルトの名無しさん
垢版 |
2014/11/30(日) 10:37:14.85ID:tEmwOrdq
>>211
とはいえ最近かなり環境整ってるぞ
JSソースからデバッグ用JSソースのコンパイルってのも増えてきたし
0218デフォルトの名無しさん
垢版 |
2016/11/16(水) 13:22:30.64ID:fzskfnoe
バックレScript
0220デフォルトの名無しさん
垢版 |
2018/05/23(水) 21:20:08.99ID:Au5e7VGg
僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

PPU1S
0221デフォルトの名無しさん
垢版 |
2018/07/05(木) 00:37:38.99ID:RfoszcD2
KWT
0222デフォルトの名無しさん
垢版 |
2019/01/30(水) 15:12:57.19ID:M7eOsbET
>>1 しかしなんのために　TypeScript　と　Swiftを並べてみようという気になったのかが気になる。
全く比べるようなものじゃないだろ。
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況