TypeScript（MS） VS Swift（Apple）
まあ、どちらもタイプセーフJavaScriptという
似たような言語なんだから仲良くしろや。
複雑すぎる
比べる相手違うだろｗｗｗ
Swiftはネイティブコードへのコンパイルだぞ
>>3 それは文法とは関係ないだろ。
TypeScript -> JavaScript -> native
ネイティブコードへのコンパイルは可能。
>>4 nativeを吐き出せるのか？ 単にJITが動くだけだろ？
しかしどちらも中核にLLVMを使ってるからLLVM byte codeは基本的に同じ物を吐き出すんだろうな。
だからやろうと思ったら TypeScriptとSwiftのマージも比較的簡単に出来そう。
LLVMはJavascriptに限らず、Ruby, Phyton、Java等等色んな言語にもコンパイルできる。
JavaScriptを介してのネイティブコードへの変換は型情報が失われちまわないか？
型情報無い状態で静的なネイティブコードに変換すると性能的にかなり劣化すると思う
>>7 Javascriptを介してるんじゃなくてLVMMの中間コードから各種コードを生成しているから何も失われない。
TypeScriptってLLVMの中間コードへ直接変換できるの？MSが提供してるの？
調べてみる限りTypeScriptのコンパイラーはJavaScript(TypeScript？)で書かれてるって情報しか見つからん
MS以外がLLVMバージョンを作ってるのか？
役割的にはどう考えてもC#と比べるべきだろ
そっちが相手だと全く勝ち目ないけどw
Cocoa を呼び出すためのカジュアルな言語が Swift で .NET を呼び出すカジュアルな言語が C# だからその通りだろう。
勝ち目って何を基準にするのかねえ。 .NET の未来が明るそうには見えないけど。
>>10 コンパイラはLLVMだよ。 LLVMからJavascriptを出してる。
LLVMは中間コードを作り、そこからJavascriptや、マシン語やJavaコードを作り出せる。
>>12 あんたの愛するiPhoneのアプリにもC#で書かれてるものが沢山あるんだぜ
>>13 どこに行けばその情報が手に入る？
公式見てもTypeScriptのコンパイラはTypeScript自身で書かれているようにしか見えない
使う時はnode.jsインストールしてnpmでコンパイラのパッケージをインストールしろって書いてあるし
囲い込みをやめて開発者のことを考えるなら
JavaScriptでネイティブアプリ作れるようにするのが正解だよな
それこそTypeScriptだって使えるし
>>15 ごめん勘違いしてた。 おっしゃるとおり。
18 ：
デフォルトの名無しさん：2014/06/03(火) 23:43:19.81 ID:OIzVF/VN
よそでもスイフトをスクリプト言語みたいに言ってる連中いたな。
C#に型推論が入った時も、動的型とかバリアント型と区別ついてない連中いっぱいいたし。
まあ、ぱっと見が重要なんだろうな。
型推論を動的型付けとか言っちゃうやつは黙ってRuby(笑)に帰れよって思う
明らかなゴミであるObjective-Cを置き換えられるなら何でもいいという暴論
あとあとやっぱりObjective-Cの方がよかったーSwiftダメだーとなる可能性が微レ存？
>>21 有る訳ないだろ。 そうそうたる言語のプロ達が出した結論なんだから。
それに見ればわかるが今までの言語の良い所取りをした感じで悪い感じがしない。
Obj-Cを敬遠していたニワカが流入してきて検索結果の質が落ちたーSwiftダメだー
25 ：
デフォルトの名無しさん：2014/06/04(水) 17:09:15.70 ID:Clluav0V
ObjCもデザイナー上がりのにわかプログラマだらけじゃないか…
そこにJavaScript上がりのにわかWebプログラマーが入ってきます
私がにわかです
つかこれ Scala やん。
にわか意見だけどScalaに似てるとは感じる
Scala熟知してる方に、違いを解説するブログ執筆をお願いしたいレベル
この言語って誰が使うの?
c,java辺りの開発者はまず使わないし、coffee script使う層は企業臭がするから使わない。
世界はもう、javascriptの一人勝ちだよ
ScalaやSwiftなんて新しい言語さわって悲しくなってこないの？
そんなもの触ったところで、コーディングスキルなんて伸びないんだよ？
>>30 ぶっ！ Javascriptしか知らない奴がコーディングスキルなんてよく言うよ。
コーダーでもなければ、コーディングスキルが伸びることなんて期待しないだろ。
>>31 そもそも、javascriptの他は、関数型以外、どれも同じパラダイムでしょ
新言語と成熟されてない周辺ツールなんて、何が楽しくてこんな言語さわるのか連中の気が知れないよ
関数型の特性が取り込まれてるだけで、手続き型言語じゃん
swiftはc++に疲れて組み込みスクリプトとかに逃げてる人にも魅力ありそうな
まあまずオープンになるのか分からんが
Appleの柵の中に限って言えば、obj-cに疲れた開発者達が枚挙するのはまあ確定だろな
つかほんとobj-cでできてswiftに出来ないことが見当たらないレベルだし、将来的にobj-cをディスコンにする気満々にさえ見えてくる
オープンにしちゃうとわざわざ特に新規性のない新言語作った意味がないからね
>>38 多分動的言語としての発展性を持った言語だから普及が早いと思う。
デバッグ環境では動的言語としてインタプリタが動くから。
教育に最適
>>39 ある程度メジャーな言語なら今時そんなもんできない言語の方が珍しいぞ
EclipseのJavaとかVS上のC#/VBあたりですらできるというのに
C#なんかはRoslynで本格的にスクリプト言語として使えるようになりそう
>>40 それは単にデバッガが動くだけでインタプリタとは言えない気がする。
>>42 REPLは当然できるしデバッグ実行中にコード書き換えたりとか普通にできるよ
今更特に珍しいことでもないので大して宣伝したりしないけど
インタプリタが動くって、デバッグ中に対話モードが提供されるってことじゃないの？
>>44 それはイミディエイトウィンドウという名称で20年前から広く普及している機能だ
ランタイムがobj-cなら今までの通り、ネイティブコード吐いても中身は動的抽象化済みって構造でしょ
インタプリタみたいに使えてるのは、その都度ワンライナー分のバイナリ吐いて実行してるとしてもランタイムだけ共有すれば済むから軽く済むからじゃないのかしら
固定のVMシステムなしにここまでやれるというのはなんか不安になるレベルだけど、LLVMの恩恵とかフル活用してる感じだし収穫期の技術なんだろな
>>30 >世界はもう、javascriptの一人勝ちだよ
10年前のお前らに言ってやったら鼻で笑われただろうな
今言っても鼻で笑われるけどね
10年前からajaxは流行ってたし、MicrosoftはJScript以外は載せなかった
先見性はあるものの、市場での主導権を握れなかった哀れな連中さ
独禁法でやられただけだよね。ドッキンドッキンされなかったら違ってたと思うよ。
10年前にAjaxなんて言葉あったっけ
1947年発売だよ
洗剤の方のajaxのことかしら
マジかよ
そんな洗剤あったのかよ
逆にその洗剤と掛けた可能性はあるな
コナミの音楽のいい縦シューと
オランダのサッカーチームが混ざってたけど
いまはKPOPもいるのかよ
TypeScriptもLLVMに乗せるようになったらおもろいな
jQuery的な意味でのAJAXは10年前くらいかな
へえ、最近はjQuery的とかで括られるんだ
……
10年前指して言ったつもりなんだけど
や、単にGoogleMapで評判になった非同期処理系にajaxって名前がついたのはjQueryより前だよって話です
今か前かとかじゃなく違和感あんのよ
JavaScript的な意味、とか言ってくれてればなんも引っかからなかったと思う、くらいの話
そもそもajaxと聞いて日本で洗剤と混同する層もいないだろうし、なんか嫌な言いがかりだったと思うわ
すまんです
60 ：
デフォルトの名無しさん：2014/06/07(土) 06:56:33.45 ID:2ccOrqUk
ajaxは2005年くらいからのイメージ
Swiftの対戦相手はC#だろ
Swiftは良い所取りをしているが、他の言語とも親和性が良いと思う。解りやすい。
LLVMが、普及し始めてるから個別の言語がなんであれ強調出来そうな環境が整いつつある。
言語の強い部分はそれで書く。各々を一緒に使えれば良いんじゃ無い？
>>62 LLVMの設計者が、効率的に動く様に作ったのがSwiftだからなぁ。
.NETもそうだけど、言語間の互換性をとる時代だな
それにたいしてJavaといったら
LLVMでネイティブ吐くあたり、仮想マシンが無いってのが面白いね
.Netの巨大戦艦っぷりも萌えるし一概にどっちがいいでもないけど。
MSはMSでarmスマホ・タブとIntel winで同一アプリを動作させるつもりのようだし
あ、でもpNaClみたいな実装すればAppleもそういうアプローチを取れなくもないのかな
こういう夢を最初に見せてくれたのがJavaだったはずなのに、なんか後追いムードだな
>>64 JavaVM上で動く言語実装自体はいろいろあるじゃない
ネイティブ連携はめんどいけど
Javaはすぐ訴訟起こすイメージだな
このままだとAndroidも別言語に切り替えになりそうな気さえする
JVMは仕様が貧弱で、Javaと、JVMを前提にして設計された言語と、
エミュレーション的な動作のオーバーヘッドが問題にならない元々遅いスクリプト以外を動かすのには向かない
対して.NETは最初から共通言語基盤として設計されてるからね
>>66 そのつもりだろ。 だからGDKなんてJava以外で開発して使うツールその物。
J2C J2ObjC なんてのも出してる。 JavaからC++やObjective-Cに変換する。
Java自体のスピードの限界も有るし。
今、androidの公式言語をdartにすれば、Java+Oracleを潰せる
がんがれ
Googleはどっかのりんごちゃんと違ってプログラミング言語作りのセンス無いの自覚してるからな
言語作るのに関してはMSは飛び抜けて優秀
自覚してんのにdartとかgoとか出してんのかよ
そういうのは出してるだけで、玩具はあくまで玩具と理解してるよ
Googleはメディアを掌握してるからちょっとしたことでも話題になるけどね
Dartなんて未だにChromeに搭載されてないし、されるようになる気配もなく
特にやる気もないみたい
dartのベンチ結果は既にjavaと同程度だよ。中国なんて、golangの普及がすごいからね
特にやる気が無さそうに見えるのは、最後に自分たちのプロダクトが成功することを信じて疑わない王者の余裕だよ
dartはjavascriptへのコンパイラがあるからブラウザへの組み込みをがんばる必要ないでしょ。
コンテンツ作る側も他ブラウザを考えたらJavascriptでも作らなきゃならないのは変わらないし、その辺ちゃんとわかってる人は無理にブラウザに入れようとは思わないよ。
そんな事考えるのはswiftがJavascriptも置き換えて云々とかいうApple信者ぐらい。
Dartは当初からブラウザに組み込まれるのが売りだったし
JSに代わって中間言語として使われるはずだったからこそ
あんなJavaモドキなガチガチ仕様にしたのにね
ただのAltJS止まりなら存在価値ゼロのJavaの出来損ない
>>76 そんなガチガチかねぇ。
メソッドオーバーロード無いけどオペレータオーバーロードはありだし、オプショナル型だから変数の型宣言は省略できるし、
けっこうバランス取れたユルさだと思う。
ちょっと前から話題のDockerがgoで書かれてるんだよな
これで実績できればサーバー書いたりする言語として普及が進むかも
比較対象はどう見てもgoだろ
// 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
}
ソックリー、ソックリー！
string を + で結合するスタイルはどうも好きになれない
var tag = "<\(name)>"
の方が汎用性が有り美しいかも。
いろんな書き方が出来るSwiftは洗練されてる。
多分Swiftではこの書き方がメインになるのでは？ どんな型でも結合出来るし。
>>82 現実には書式設定が必要な場合が多いのであんまり美しくなくなるんだよね
結局従来のprintf方式がスマート
>>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
// よりは美しい
フォーマットはセキュリティのリスクがあるからSwiftには入れてないんだ
フォーマットしたかったらNSFormatter使えって言ってたから、そういう仕様なんだよ
多言語対応するなら全く役に立たないし
せいぜいデバッグに使う程度のおまけ機能ってこと
倍角文字がね
他言語化する時は結局Swift版のNSLocalizedStringを呼んでstringWithFormatに突っ込むんだろうな
89 ：
デフォルトの名無しさん：2014/06/27(金) 09:35:43.36 ID:xawLBmcE
◎2chスレッド勢いランキングサイトリスト◎
★+ニュース板
・ 2NN (推奨サイト)
・ 2chTimes
★+ニュース板新着
・ 2NN新着
・ Headline BBY
・ unker Headline
★+ニュース板その他
・ Desktop2ch
・ 記者別一覧
★全板
・ 全板縦断勢いランキング (推奨サイト)
・ スレッドランキング総合ランキング
・ ログ速
★全板実況込み
・ 2勢 (推奨サイト)
・ READ2CH
・ i-ikioi
※ 要タイトル検索
※ 2chブラウザ併用推奨
Swiftって正規表現による置換は無いの？
Formatはそれで代用できるでしょ
FormatだけならFormatterを使えば済む話。
でも正規表現的な物もあった方が良いと思う。
話は変わるが、ターミナル上でSwiftをインタプリタとして動かして見るとちょっとした感動が有った。
これでJavascriptの代わりに使えれば言うこと無いんだが。
もちろん全ての環境で動かすことは難しいだろうから、MacOS iOS環境だけで良いけど。
iOSでターミナルを解放することも無いだろうから、WebKitの中だけでも良い。これは結構実現性が高いと踏んでいる。
interpeter風実行はgoでもできなかったっけ？
>>91 Javascriptへのコンパイルを可能にしない限りWebサイトに使えることはないだろう
>>93 既にWebKitにLLVM が乗って、JavascriptのVMが動き始めてるの知ってる？ みんな次のバージョンでサポートする。スピードが30%上がる。
iPhoneだとiOS8から。今ベータが動いてる。
swiftはLLVMのLLDBでインタプリタを実現してるから、Javascripが動く環境で動かすのは容易い話であり、WebKitの主導者のAppleが入れてしまえば多分抵抗なくみんな使い始める。
最初はプラグインか何かのオプションになるだろうが。
とは言っても、1～2年はかかるだろう。
LLVMベースが何を意味するか解るか？
Javascript の中間コードとSwiftの中間コードは同じなんだから、JavascriptのVMが動くと言うことはSwiftのVMも動くと言う事。
標準採用されるまでに時間がかかるのは当然。
いや、別言語をAppleの手の中で動かせるのは当然わかる
それが他の環境、WindowsとかAndroidにも対応しないとはやらない
移植性のよさが利点のWebの分断は批判が大きいだろう
そのためにはJavascriptを中間コードから生成せねばならないが、そこでTypeScriptやCoffeeScriptと戦って勝てるのか
WebKitのシェアはblink移行で下がってるから、ハイブリットアプリで内部て使うとかがいいとこじゃない？
直接実行できるのだけが利点なら、VBScript、Dartがすでにあるけど、どれもまず聞かないという
やろうと思えばそんなにかからんのじゃね
Emscriptenなんてのもあるし
>>94 見たらアグレッシブな最適化の部分だけじゃないか。
js をパースして次が LLVM IR ならともかく、話が全然違う。
聞いたことないし GC どうすんのかとかあるし、なんかおかしいと思ったんだよ。LLVM が何かわかってない発言だ。
それ以前にSwiftがオープンになることはないでしょ
そんなことしたら「あえて」特に何も新しくない新しい言語を作った意味が無くなる
意味わかるでしょ?
オープンソースにしない限り、幅広い分野でっていうのは無理だな
Microsoftはオープンソース化が多くなってるのに、appleはどうなんだ
>>101 全然意味分からないのでもっと詳しく具体的に説明してください
>>101 Objective-Cですらオープンソースにしてるのに、しない理由が解ら無い。
>>102 Apple は、言語系、Web系は殆どオープンソースだよ。
WebKitとLLVMはその要だろう。
早くオープンソースにしてLLVM実行環境だったら使えると言う状態に持って行って欲しい。
SwiftはLLVMと密接に結びついており、拡張性は高い。オープンソースにはまだなってい無いが、LLVMを軸に動いてる事は事実だし、Appleの判断次第。
使うか使わ無いかは使う側の判断。
C やObjCとも混在出来るし、LLVM IRからは既にJavascript やJavaをすら生成出来る。(一時しのぎにしかなら無いだろうが)
TypeScriptは、確かに必要性は解るがあくまでもツール的な存在では無いだろうか。
例えば核の言語のプリプロセッサやライブラリ的な存在。
C にプリプロセッサ的に追加したObject-C の様に。
つまりなくても困ら無い。
TypeScriptがJavaScriptの拡張版と言ってもブラウザで直接実行出来無い限り本流にはなり得無い。
Swift はどうかと言うと、核の言語。 王道を歩むつもりの様だからオープンソースになり使う人が多くなれば普及も早いと思われる。
SwiftScriptが出来るかどうかは、単なる憶測の範囲。
>>105 オープンソースになっても、言語仕様的にほかより優れてるの？そうじゃないと他の環境までは、はやらない
所詮Appleの中の言語にとどまると思う
ブラウザの直接実行は、Microsoft,Apple,Google,Firefoxの4勢力が協力しない限り達成不能
そして、Web共通言語のjs以外で足並みを揃えるのは無理だし、Apple的にはほかの会社に自社言語の開発の中心に居座られたくない気がしそう
TypeScriptなんかがプリプロセッサなのはjavascriptによる過去の資源との互換性を保つためで、どの言語にもjsの置き換えを狙うのが無理そうだからだよ
AltJSじゃだめな理由って何がある？
>>107 そもそも、HTML内埋め込みインタラプト言語のJavaScript系と、オールマイティーなコンパイル言語系では用途が全く違う。
だから、TypeScript と Swift を対比すること自体に無理が有るけど、Swiftがインタプリタとしても動いたりスクリプトとしての可能性も匂わせてるからこのスレに上がったんだろう。
元々は全く違う用途。
>>108 スクリプトとして動きそうというだけならC#なんかもそのうち動きそうだけど
Roslynもできたし、IOSを含め他の環境でももう動いてる
>>106 >言語仕様的にほかより優れてるの？
そんな事は言うまでも無い。
各種言語の良い所取りした言語だから、他の言語からも反対する意見は殆ど皆無。
特に今後のコンピュータ言語教育に果たす役割は大きいと思う。
多少癖が有りそうなのは、スピードを重視した仕様 (これは認められるだろう) とC や ObjCとの相互結合を考慮した点( 現実解 )
これらも何ら足かせには成ら無いだろう。 必要ならそれなりのライブラリが出来るだけ。
プリプロセッサを排除した分、言語仕様の中で自分自身をを書き換える(オーバライド) 事が出来るのは今後の発展性を匂わせる。
ID:mYSKVn4w
↑ただの知ったかぶりにしか見えん
>>109 スクリプトとして動きそうと言うだけと、動く事を見据えた言語では仕様が異なる。
Swiftは動的関数な部分が大きい。 最初からそう言う言語だからスクリプトとして動かしても性能を発揮出来る。
遅延評価lazy とか。
ObjCとの比較を除けば、他言語との比較はまだ文法的に比較してここら辺似てるとか言ってる段階でなんとも言えないなあ
まだベータ版だし、Appleがどこまで公開するかと他環境への展開待ちかな
コンピュータなんだから、どんな言語でも出来ないことはツギハギでも追加して出来る様にして行くから、出来ることは殆ど同じになるんだよね。
要は如何にスマートに実装するかどうかじゃ無いのかな。
ツギハギ言語では辛い場面が出る。
Swiftと言えど、過去のしがらみを全て捨てるわけにはいかなかったみたい。
過去の遺産を使う限り仕方ないだろうね。
生糸から紡ぎ治せれば良かったが、古着をほどいた糸で紡ぎ直したと言う感は否め無い。
ID:mYSKVn4w からkenokabe臭がする
>>114 計算モデルを間違わない限りは、なんでも追加などしない。
119 ：
99：2014/06/30(月) 00:47:03.04 ID: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 を持っててインタプリットしていると考えるのは不自然だ。
ちょっと検索してみたところでは、インタプリタとして動作していると信じている人は見つからなかった。
ソースがあれば出してくれ。
>>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
>>120 PlaygroundもLLDBが動いてる。
>>120 ＞The Swift REPL (Read-Eval-Print-Loop) acts like an interpreter.
「SwiftのREPLはインタプリタのように動作する」
つまり実際にはインタプリタでは無いんだよ
>>123 SwiftのREPLは逐次ネイティブコードに変換してから実行してるだろうからその1～3に当てはまらない
REPL=インタプリタ では無いよ？
VSなんかILのインタプリタが搭載されてて
ダンプ情報をデバッガに読ませてエディットコンティニューなんて荒業が可能らしいよ
>>123 > Javaなんかよりよほどインタプリタの王道に近い動きをするぞ。
何を言ってるんだお前は
>>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;
>>127 言い忘れた。 コンパイラは、MacOS上で動かしていてもコンパイル結果をターゲットのARMとしての出力が出来るのは当然。
だからと言ってARMの機械語で動かしている訳でない事も当然。
この意味が解るか？ 機械語を実行している訳じゃないんだよ。
>>127 だからさ、LLVM使ってればLLVM-IRとか出力できるのは当たり前なんだって
だけどLLVM-IRのファイル作れてもそれを直接解釈実行する仕組みはどこにあるんだ？
現状LLVMの仕組みを利用してインタプリタの"ような"動作するものはいくつかある
上でも挙がってるSafariの最終レベルのJTTとか、ChromeのPNaClとか、AndroidのARTとか
これらは全部LLVMを使ってるけど、LLVM-IRを解釈実行する仕組みをもってるわけではなくて、
LLVM-IRからネイティブなコードまで変換してから、LLVMとは無関係な機構で実行する
Swiftがスクリプト言語のように使えるとしても、それはLLVMとは関係無い
LLVMはネイティブコードを生成するために使ってるだけ
LLVMと無理やり結びつけて煽るのを止めてくれるかな？
>>128 コンパイラなんてただの変換処理系なんだから、
コンパイラを動かしてるマシンやOSとコンパイラが出力するコードが関係無いのは当たり前じゃないか
そんなことをいちいち説明するのに何か意味があるのか？
>>127 どうしてassemblyって書いてあるのに、
あせんぶらっていうの？
ブリよりもブラのほうが言いやすいだろ
>>132 クロマトグラフィーを、クロマティと読んじゃうオッさんなんだろう。
いちいちWikipediaで調べるなよｗｗｗ
ｱｾﾝﾌﾞﾘ
斡旋鰤
>>138 いや最近の安い辞書に assembler と言う訳が載っていないことに驚いたんだよ。
昔はassemblerの方が一般的だったのに。
質問が出てきた意味が解った。 assemblyの語源はassembler 。
少なくともプログラムする人間は、コンパイラ、アセンブラと言う言葉位は知っておいてほしいな。
>>140 なんでそんな自信たっぷりに適当なことを撒き散らせるんだ
普通、語源と言ったらassembleかassemblyの方だ
erを付けて～するモノって意味になるのだよ
なんだこいつ
>>137 -emit-assembly
のassemblyをアセンブラーって書いたコトにつっこまれてんだけど
フランス語のassemblerと英語のassemblerは意味がちょっと違う
>>143はフランス語のassemblerが英語のassembleになったってことだぞ
そして英語では、そのassemble+erでassembleするものって意味になるわけだ
万が一ｗ、
>>140のassemblerをフランス語の意味で使ってたならすまんかったなｗ
Sports Music Assemble People
>>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
-emit-assembly file
>>120 ええと、それで >94 を正当化できるの？
別に on the fly でコンパイルするシステムをインタプリタと呼んではいけないとは思わないが、
例えば CINT が JIT 積んだらほとんどそうなるわけだし、だが LLVM IR をインタプリットしないと
>94 は成り立たないだろう。
>>128 IR を実行するわけじゃなくて IR を機械語に変換するんだよ。otool とかで見てごらん。
gcc で内部的に psuedo op code を使うようなもんだよ。
だから
>>127 > 呼び方なんか何でも良い。 汎用スクリプト言語として使えると言う事実。 これが全て、
が正しくても >94 は成り立たないんだよ。
>94 を捨てて別の主張を始めること自体は構わないけど、今度は >94 のような出鱈目を吹聴しないようにしてね。
>>150 汎用言語(General-purpose)＜― ―＞制御言語(Script)
>>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実行環境の流れは時間がかかりそうだが、進みそう。
（セキュリティの問題が有る）
LLVM-IRからJavaScriptに変換できても、
元のコードが使ってるAPIからJavaScriptのAPIに変換する仕組みの実装が高難易度で不十分なせいで実用には遠い
printfで出力垂れ流す程度なら簡単なんだけどね
LLVM-IRを直接解釈して実行する仕組みを作る場合も同じような問題をクリアする必要がある
苦労してその問題をクリアできてもパフォーマンスガタ落ちは避けられないんで、真剣に取り組む人がいない
>>153 そのExampleの Voronoi でベンチマークしてみた。
Emscriptenが13.681秒 PNaCl が6.723秒 倍違うね。
>>154 一般APIを使うとみんなダメだろ。
Webブラウザで動けるAPIだけを使うと言うように限定しないと当然リンクエラーだよ。
あくまでもWebアプリなんだから。
Hello Worldだって、ブラウザ上に表示しないといけないんだからね。 標準出力なんか使えないよ。
HTMLダイレクトかJavascriptを通して表示させるとかやらないと。 HTMLも知らない人が使おうたってそりゃ無理だよ。
>>156 何言ってんだ
Emscriptenは標準Cライブラリをサポートしてる
>>153 Earth ベンチマーク
Emscripten 8.6秒 0スレッド（スレッド指定不可）
PNaCl 0スレッド 2.5秒 8スレッド 1.23秒
逆に元の言語でブラウザのAPIを使ってそれをJavaScriptに変換する場合は
元の言語側でブラウザのDOMにアクセスするような(仮想的な？)ライブラリを用意して
それをうまいことJavaScriptのコードに対応づけてやる必要があるだろうな
例えばEmscriptenはそういう仮想的なライブラリを各言語毎に用意してんの？
>>157 あらゆる言語が有るんだから全ての言語がCライブラリを利用している訳でもないし、
全てのCライブラリが変換出来る訳でもない。
コンパイル環境によってリンクされるライブラリも違うだろうし、
VSでコンパイルすれば多分エラーのオンパレードになるだろう。
最終的にC,C++を経由しないライブラリなんてあるのか？
Pythonとかも動いてんだ
何の問題もない
>>160 Emscriptenの仕組みを根本的に勘違いしてる？
これはC言語の一般的なライブラリ(libcとかSDLとかもいけるらしい)にリンクされた形式のLLVM-IRを入力にして、
JavaScriptを出力するものだと思うんだけど
>>159で挙げたみたいな仕組みも別に用意されているのかな？
各言語毎に用意された独自の様々なライブラリとリンクされたLLVM-IRを
漏れなくJavaScriptに変換できるとしたらそれはものすごい規模の仕組みになると思うけど
そんなの神業すぎて有り得ん
だから
>>153のこれも
（Swift ＞LLVM IR ＞ Javascriptは可能だが公式発表は無し）
まだ現実的には意味が無いはず
すべてのLLVM-IRをJavaScriptに変換できるわけでは無い
変換可能なのはEmscriptenがサポートする範囲のライブラリがリンクされたLLVM-IRなわけ
今のSwiftにはまだEmscriptenがサポートするライブラリとか用意されてないよね
SwiftをJavaScriptに変換したところでアプリがそのまま移植できるわけではないし
(APIを移植したらAppleに訴えられるだろう)
どうせ互換性がないなら無理にSwiftやemscriptenなんか使ってコードを肥大化させる必要なんかない
それこそTypescriptやCoffeeでいい
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 がライブラリをエミュレートしない限りはかなり難しいだろうな。
>>165 なんかいろいろ勘違いしてるけど、無理だということがわかってくれればそれでいいや
>>163 > すべてのLLVM-IRをJavaScriptに変換できるわけでは無い
> 変換可能なのはEmscriptenがサポートする範囲のライブラリがリンクされたLLVM-IRなわけ
基本的には全てのLLVM-IRをJavaScriptに変換出来るんじゃないの？
OpenGL→WebGLみたいにJavaScriptのAPIにマッピング出来るライブラリがあるかないかと
変換出来るかどうかを一緒にしては駄目だ
>>167 その通り、全て言語的には変換出来る。
出来ないのは、リンク結合出来るか出来ないか。
だから使えるか使えないかと言ったら、使い方次第。
無理して使う人は少ないだろうが。
>>167 少なくともEmscriptenによるJavaScriptへの変換は
マッピングされてないライブラリをリンクしてるLLVM-IRをJavaScriptのコードには変換できないだろ？
ネイティブコードへ変換する通常のLLVMのバックエンドとはちょっと事情が違う
>>170 Emscriptenはリンクする前にJavascriptへ変換すんだよ。あんまり半端な知識で知ったかぶりしないほうがいいぞ
>>169 だからEmscriptenは通常のLLVMバックエンドと違って実際にリンク結合するわけじゃいんだってば
リンク結合されるべき部分を無理やりEmscriptenが用意してるJavaScriptランタイムの呼び出しに変換する
その変換が用意されてないライブラリの呼び出しを見つけたらEmscriptenの変換は失敗するわけ
>>171 実際にリンクするわけじゃないだろ？
呼び出すJavaScriptランタイムがなければそれはEmscriptenにとっては変換失敗じゃないか
>>170はちょっと書き方が悪かったなライブラリをリンクしてるというかライブラリの関数を呼び出してると書くべきだった
そしてライブラリ関数の呼び出しはとりあえずJavaScriptに変換されて、
Emscriptenが用意してるJavaScriptとランタイムと一緒に実行したときに
ランタイムがそのライブラリ関数をサポートしてれば実行されるし、サポートしてなければ実行時エラーになるのか
このへんはちょっと勘違いしてた
>>174 そんな感じやね。もちろんヘッダすらなかったらコンパイルエラーになるけど
だからとりあえずどんなLLVM-IRでもJavaScriptへの変換は可能。これは訂正しとくは
そして、Swiftをブラウザで実行しようと思ったらSwift用のJavaScriptランタイムを用意する必要があると
Cocoaに相当するランタイムは実質不可能だろう
SwiftからDOMにアクセスするランタイムは作れなくも無さそうだけど、
Swift側のAPIを決めて、それにマッピングするようランタイム作る必要があるわけだ
>>176 「は」 と 「わ」 の使い分けも出来んバカだったのかお前
さもありなんだな
初めてか？ 力抜けよ。
>>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
なんだかすごく楽しみだな。
>>180 単にXcodeが表示にWebKitを使ってるだけじゃないの？
>>181 そのリンクの先はOSX上でJavaScriptからCocoa関係にアクセスするための仕組みのように見えるんだけど違うの？
>>176とはほとんど関係無くない？
ID: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に変換してるが、もし統一中間コードが決まればダイレクトにそのコードにコンパイルする様になるだろう。 その方が効率が良いはずだから。
>>185 JavaScriptからCocoa呼び出せても、ネイティブなCocoaがあるOSでしか動かないじゃない？
そんなのは一般的なWebクライアント用言語としては使えないよ
>>186 Java Appletが、動ける範囲を制限してる様に、何らかのクラスの下でだけ動ける様にするはず。
極端な話WebKitの範囲内だけとか。要はJavaScriptが動ける範囲内だけで良いんだよ。WebKitAppクラスとか。
別に汎用のCocoaを網羅する必要は無いし動いたら却って怖い話。 そんなのセキュリティ上有り得ない。
あんたが言ってるようなのって今現在沢山あるぞ?
どれも中途半端でイマイチ流行らないけどね
OSのAPIをひたすらラップするだけの作業だから
手間さえかければ良い物ができるよ
>>187による実装に期待
>>187 クラスの下で動くって意味がわからないよ
そのクラスっていうのは実体が何で、世の中の一般的なブラウザはそれをどうやって利用するの？
>>186 それとクラスと言ってもそれは上位言語の話で有って、中間言語などに降りてきたらクラスなんか関係無い。
単なる汎用のマシン語が動くかどうかの世界。
ただ、まっさらなマシン語の実行を許すと大きなセキュリティの危険にさらされるから、何らかのガードの元で実行出来る様にするはず。
>>190 だからその中間言語を一般的なブラウザでどうやって実行するつもりなんだって聞いてるんだ
プラグインか？JavaScriptランタイムか？アップルはそんなもの提供するなんて一言も言ってないだろ
swift→bit code→NativeClientは可能だろうけど。
知ったかぶりの妄言垂れ流しｗ
>>191 一般ブラウザは中間コードじゃなくて単なるJavascriptだよ。
つまり、Native/bytecode またはJavascriptの両方出力できるようにするはず。 Dartも同じ。
多分HTML上も両方スイッチできるようにしておいてクライアントに応じてどちらかをダウンロードする形。
>>191 >JavaScriptランタイムか？アップルはそんなもの提供するなんて一言も言ってないだろ
全て妄想の範囲だよ。 だが現実味が強い。
１．Javascriptランタイムライブラリは殆ど揃ってる。 ＜－JavascriptがOSスクリプトに採用されたから。 ＜－公式発表
２．SwiftからLLVM IRは今でも出力できる。 ＜－既に動いてる。
３．LLVM IRからJavascriptへのコンバータは既にある。 だからライブラリさえ提供されれば可能になる。
いつごろ実現するかはわからんが1年以内だろう。
>>194-195 LLVM-IRからJavaScriptに変換したコードを他ブラウザで実行する際に必要とするJavascriptランタイムは、
JavaScriptをOS Xのスクリプトとして利用するための仕組みに関係するものとは全然性質が違うんだよ
前者はcocoaの機能に相当する部分までなんとかしないといけないけど、
後者は単にOS Xへのラッパーにしか過ぎない
この違いが理解できるかな？
前者はかなり大変な仕組みだからアップルが何の発表もしてない時点で現実味が全く無い
WindowsでもJScriptがつかえるよ！
やったね！
>>196 逆にJavascriptに変換すると言う事は、javascript実行環境で使うのであればJavascript内でクローズしていれば良いのだから複雑なライブラリは必要ないとも言えるのでは？
だからすべてのブラウザで動く事が出来る。
Javascriptに変換した後の環境は単にウエブブラウザのJavascriptインタプリタのみ。
必要なランタイムライブラリはインタプリタが実装していると言える。
>>198 そうだよ。単にDOMにアクセスするためなら複雑なランタイムは必要無い
だから
>>181のJavaScriptからcocoaを呼び出す仕組みとか関係無いってことだ
WebになるとSwift関連ツールがWindows向けに提供されない場合、Windowsでのデバッグがやりにくくなる
スマフォ用Webアプリには使われても、直ぐに後追いが出てマルチプラットホームでのツール提供をすればそれに越されそう
>>200 JavaScriptに変換するのならTypeScriptと同じ土俵だろ。 デバッグに心配はない。
emscripten使えばわかるけど、生成されたゲロみたいなjsコードのデバッグは非常に困難
極めて綺麗なJSを吐くTypeScriptとは一緒にしてはいけない
>>202 どのレベルのJSを吐くかによるだろ。 EmScriptenはasm.js を吐き出すんだろ？
性能を取るか視認性を取るかの違いだろ。
asm.jsを吐き出しても元のソースコードをコメントで入れてあれば見やすいのにそれはしていないんだろうな。
そのうち成長してくるだろう。
>>203 Emscriptenはデバッグが完了したネイティブアプリを変換する為だけのもの
>>204 単体デバッグ出来るんだっけ？
LLDB使って出来そうには思うけど。
>>203 ジェネレータは関係ない
コンパイル時のデバッグ情報を使わない限り、IRの時点でデバッグは十分困難だから
>>206 詳しいことは知らないんだけど、IRにまでデバッグ情報は持ち込めるんじゃ無いの？
IRを使ってLLDBでデバッグ出来るんだから。 LLDBはClangでしかデバッグ出来ないの？
>>202 あのね、コンパイラ言語はソースでデバッグするだろ、アセンブラでデバッグする事は滅多にないよ。
>>209 TypeScriptと同じ土俵ってところへの突っ込みでしょ。TypeScriptにとってJSは中間言語じゃない。
あっちはデバッガ含めJS資産を完全にシームレスに活用できるのが売り。
最悪、生成されたJSコードをベースにしてJSに戻って開発を続けることも十分可能なほど。
言語が違うんだから、デバッグ方法が異なっても当然だな
しかし、JSのデバッグはお世辞にもデバッグしやすいとは言えないだろ。
iPhone修理の仕事してる人っている？
iPhone6とかすでに受け取ってるんかね？
そういえば、ビックカメラとキタムラのiPhone修理受付の求人が入れ食い状態だとか噂を聞いたことある。確かに最近混雑して待ち時間が6時間とからしいからな
可愛い女の子も多いし応募してみようかと思ってる
>>211 とはいえ最近かなり環境整ってるぞ
JSソースからデバッグ用JSソースのコンパイルってのも増えてきたし
