TypeScript（MS） VS Swift（Apple）

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

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

**デフォルトの名無しさん** · 2014/06/06(金) 23:03:52.33

10年前にAjaxなんて言葉あったっけ

**デフォルトの名無しさん** · 2014/06/06(金) 23:13:25.32

1947年発売だよ

**デフォルトの名無しさん** · 2014/06/06(金) 23:31:09.27

洗剤の方のajaxのことかしら

**デフォルトの名無しさん** · 2014/06/07(土) 00:19:43.55

マジかよ
そんな洗剤あったのかよ
逆にその洗剤と掛けた可能性はあるな

**デフォルトの名無しさん** · 2014/06/07(土) 00:28:08.45

コナミの音楽のいい縦シューと
オランダのサッカーチームが混ざってたけど
いまはKPOPもいるのかよ

TypeScriptもLLVMに乗せるようになったらおもろいな

**デフォルトの名無しさん** · 2014/06/07(土) 02:17:25.67

jQuery的な意味でのAJAXは10年前くらいかな

**デフォルトの名無しさん** · 2014/06/07(土) 02:22:54.93

へえ、最近はjQuery的とかで括られるんだ
……

**デフォルトの名無しさん** · 2014/06/07(土) 02:26:43.57

10年前指して言ったつもりなんだけど

**デフォルトの名無しさん** · 2014/06/07(土) 03:04:31.92

や、単にGoogleMapで評判になった非同期処理系にajaxって名前がついたのはjQueryより前だよって話です
今か前かとかじゃなく違和感あんのよ

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

そもそもajaxと聞いて日本で洗剤と混同する層もいないだろうし、なんか嫌な言いがかりだったと思うわ
すまんです

**デフォルトの名無しさん** · 2014/06/07(土) 06:56:33.45

ajaxは2005年くらいからのイメージ

**デフォルトの名無しさん** · 2014/06/14(土) 15:56:47.95

Swiftの対戦相手はC#だろ

**デフォルトの名無しさん** · 2014/06/14(土) 16:56:14.50

Swiftは良い所取りをしているが、他の言語とも親和性が良いと思う。解りやすい。
LLVMが、普及し始めてるから個別の言語がなんであれ強調出来そうな環境が整いつつある。

言語の強い部分はそれで書く。各々を一緒に使えれば良いんじゃ無い？

**デフォルトの名無しさん** · 2014/06/14(土) 19:24:32.09

>>62
LLVMの設計者が、効率的に動く様に作ったのがSwiftだからなぁ。

**デフォルトの名無しさん** · 2014/06/14(土) 19:26:26.18

.NETもそうだけど、言語間の互換性をとる時代だな
それにたいしてJavaといったら

**デフォルトの名無しさん** · 2014/06/14(土) 20:07:14.07

LLVMでネイティブ吐くあたり、仮想マシンが無いってのが面白いね
.Netの巨大戦艦っぷりも萌えるし一概にどっちがいいでもないけど。

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

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

>>64
JavaVM上で動く言語実装自体はいろいろあるじゃない
ネイティブ連携はめんどいけど

**デフォルトの名無しさん** · 2014/06/14(土) 20:17:12.78

Javaはすぐ訴訟起こすイメージだな
このままだとAndroidも別言語に切り替えになりそうな気さえする

**デフォルトの名無しさん** · 2014/06/14(土) 21:55:49.56

JVMは仕様が貧弱で、Javaと、JVMを前提にして設計された言語と、
エミュレーション的な動作のオーバーヘッドが問題にならない元々遅いスクリプト以外を動かすのには向かない
対して.NETは最初から共通言語基盤として設計されてるからね

**デフォルトの名無しさん** · 2014/06/15(日) 03:19:25.43

>>66　そのつもりだろ。　だからGDKなんてJava以外で開発して使うツールその物。
J2C　J2ObjC　なんてのも出してる。　JavaからC++やObjective-Cに変換する。

Java自体のスピードの限界も有るし。

**デフォルトの名無しさん** · 2014/06/19(木) 15:56:47.41

今、androidの公式言語をdartにすれば、Java+Oracleを潰せる

**デフォルトの名無しさん** · 2014/06/19(木) 16:09:20.93

がんがれ

**デフォルトの名無しさん** · 2014/06/19(木) 19:38:11.88

Googleはどっかのりんごちゃんと違ってプログラミング言語作りのセンス無いの自覚してるからな
言語作るのに関してはMSは飛び抜けて優秀

**デフォルトの名無しさん** · 2014/06/19(木) 20:18:07.97

自覚してんのにdartとかgoとか出してんのかよ

**デフォルトの名無しさん** · 2014/06/19(木) 21:16:10.40

そういうのは出してるだけで、玩具はあくまで玩具と理解してるよ
Googleはメディアを掌握してるからちょっとしたことでも話題になるけどね
Dartなんて未だにChromeに搭載されてないし、されるようになる気配もなく
特にやる気もないみたい

**デフォルトの名無しさん** · 2014/06/20(金) 14:55:02.18

dartのベンチ結果は既にjavaと同程度だよ。中国なんて、golangの普及がすごいからね
特にやる気が無さそうに見えるのは、最後に自分たちのプロダクトが成功することを信じて疑わない王者の余裕だよ

**デフォルトの名無しさん** · 2014/06/20(金) 15:58:57.41

dartはjavascriptへのコンパイラがあるからブラウザへの組み込みをがんばる必要ないでしょ。
コンテンツ作る側も他ブラウザを考えたらJavascriptでも作らなきゃならないのは変わらないし、その辺ちゃんとわかってる人は無理にブラウザに入れようとは思わないよ。
そんな事考えるのはswiftがJavascriptも置き換えて云々とかいうApple信者ぐらい。

**デフォルトの名無しさん** · 2014/06/20(金) 20:21:20.60

Dartは当初からブラウザに組み込まれるのが売りだったし
JSに代わって中間言語として使われるはずだったからこそ
あんなJavaモドキなガチガチ仕様にしたのにね
ただのAltJS止まりなら存在価値ゼロのJavaの出来損ない

**デフォルトの名無しさん** · 2014/06/22(日) 00:29:13.65

>>76
そんなガチガチかねぇ。
メソッドオーバーロード無いけどオペレータオーバーロードはありだし、オプショナル型だから変数の型宣言は省略できるし、
けっこうバランス取れたユルさだと思う。

**デフォルトの名無しさん** · 2014/06/22(日) 01:02:59.67

ちょっと前から話題のDockerがgoで書かれてるんだよな
これで実績できればサーバー書いたりする言語として普及が進むかも

**デフォルトの名無しさん** · 2014/06/22(日) 14:44:46.69

比較対象はどう見てもgoだろ

**デフォルトの名無しさん** · 2014/06/22(日) 15:01:35.97

// 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
}

ソックリー、ソックリー！

**デフォルトの名無しさん** · 2014/06/22(日) 17:35:57.18

string を + で結合するスタイルはどうも好きになれない

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

var tag = "<\(name)>"

の方が汎用性が有り美しいかも。
いろんな書き方が出来るSwiftは洗練されてる。
多分Swiftではこの書き方がメインになるのでは？どんな型でも結合出来るし。

**デフォルトの名無しさん** · 2014/06/22(日) 20:53:12.27

>>82
現実には書式設定が必要な場合が多いのであんまり美しくなくなるんだよね
結局従来のprintf方式がスマート

**デフォルトの名無しさん** · 2014/06/23(月) 00:26:21.67

>>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

// 　よりは美しい

**デフォルトの名無しさん** · 2014/06/23(月) 00:31:08.05

フォーマットはセキュリティのリスクがあるからSwiftには入れてないんだ
フォーマットしたかったらNSFormatter使えって言ってたから、そういう仕様なんだよ

**デフォルトの名無しさん** · 2014/06/23(月) 07:12:49.72

多言語対応するなら全く役に立たないし
せいぜいデバッグに使う程度のおまけ機能ってこと

**デフォルトの名無しさん** · 2014/06/23(月) 07:58:15.78

倍角文字がね

**デフォルトの名無しさん** · 2014/06/23(月) 09:11:06.74

他言語化する時は結局Swift版のNSLocalizedStringを呼んでstringWithFormatに突っ込むんだろうな

**デフォルトの名無しさん** · 2014/06/27(金) 09:35:43.36

◎2chスレッド勢いランキングサイトリスト◎

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

※ 要タイトル検索
※ 2chブラウザ併用推奨

**デフォルトの名無しさん** · 2014/06/28(土) 13:32:22.99

Swiftって正規表現による置換は無いの？
Formatはそれで代用できるでしょ

**デフォルトの名無しさん** · 2014/06/28(土) 15:22:27.04

FormatだけならFormatterを使えば済む話。
でも正規表現的な物もあった方が良いと思う。

話は変わるが、ターミナル上でSwiftをインタプリタとして動かして見るとちょっとした感動が有った。
これでJavascriptの代わりに使えれば言うこと無いんだが。
もちろん全ての環境で動かすことは難しいだろうから、MacOS iOS環境だけで良いけど。
iOSでターミナルを解放することも無いだろうから、WebKitの中だけでも良い。これは結構実現性が高いと踏んでいる。

**デフォルトの名無しさん** · 2014/06/28(土) 16:03:57.22

interpeter風実行はgoでもできなかったっけ？

**デフォルトの名無しさん** · 2014/06/28(土) 17:57:36.41

>>91
Javascriptへのコンパイルを可能にしない限りWebサイトに使えることはないだろう

**デフォルトの名無しさん** · 2014/06/28(土) 18:43:31.30

>>93 既にWebKitにLLVM が乗って、JavascriptのVMが動き始めてるの知ってる？みんな次のバージョンでサポートする。スピードが30%上がる。
iPhoneだとiOS8から。今ベータが動いてる。

swiftはLLVMのLLDBでインタプリタを実現してるから、Javascripが動く環境で動かすのは容易い話であり、WebKitの主導者のAppleが入れてしまえば多分抵抗なくみんな使い始める。
最初はプラグインか何かのオプションになるだろうが。
とは言っても、1～2年はかかるだろう。

**デフォルトの名無しさん** · 2014/06/28(土) 18:48:52.76

LLVMベースが何を意味するか解るか？
Javascript の中間コードとSwiftの中間コードは同じなんだから、JavascriptのVMが動くと言うことはSwiftのVMも動くと言う事。

標準採用されるまでに時間がかかるのは当然。

**デフォルトの名無しさん** · 2014/06/28(土) 19:20:18.14

いや、別言語をAppleの手の中で動かせるのは当然わかる

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

WebKitのシェアはblink移行で下がってるから、ハイブリットアプリで内部て使うとかがいいとこじゃない？

**デフォルトの名無しさん** · 2014/06/28(土) 19:23:26.17

直接実行できるのだけが利点なら、VBScript、Dartがすでにあるけど、どれもまず聞かないという

**デフォルトの名無しさん** · 2014/06/28(土) 20:08:05.04

やろうと思えばそんなにかからんのじゃね
Emscriptenなんてのもあるし

**デフォルトの名無しさん** · 2014/06/29(日) 04:35:38.07

>>94
見たらアグレッシブな最適化の部分だけじゃないか。
js をパースして次が LLVM IR ならともかく、話が全然違う。
聞いたことないし GC どうすんのかとかあるし、なんかおかしいと思ったんだよ。LLVM が何かわかってない発言だ。

**デフォルトの名無しさん** · 2014/06/29(日) 08:19:56.40

>>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

**デフォルトの名無しさん** · 2014/06/29(日) 09:44:26.93

それ以前にSwiftがオープンになることはないでしょ
そんなことしたら「あえて」特に何も新しくない新しい言語を作った意味が無くなる
意味わかるでしょ?

**デフォルトの名無しさん** · 2014/06/29(日) 10:01:59.85

オープンソースにしない限り、幅広い分野でっていうのは無理だな
Microsoftはオープンソース化が多くなってるのに、appleはどうなんだ

**デフォルトの名無しさん** · 2014/06/29(日) 11:26:00.71

>>101
全然意味分からないのでもっと詳しく具体的に説明してください

**デフォルトの名無しさん** · 2014/06/29(日) 12:19:42.92

>>101 Objective-Cですらオープンソースにしてるのに、しない理由が解ら無い。

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

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

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

C やObjCとも混在出来るし、LLVM IRからは既にJavascript やJavaをすら生成出来る。(一時しのぎにしかなら無いだろうが)

**デフォルトの名無しさん** · 2014/06/29(日) 12:36:23.68

TypeScriptは、確かに必要性は解るがあくまでもツール的な存在では無いだろうか。
例えば核の言語のプリプロセッサやライブラリ的な存在。
C にプリプロセッサ的に追加したObject-C の様に。
つまりなくても困ら無い。
TypeScriptがJavaScriptの拡張版と言ってもブラウザで直接実行出来無い限り本流にはなり得無い。

Swift はどうかと言うと、核の言語。王道を歩むつもりの様だからオープンソースになり使う人が多くなれば普及も早いと思われる。
SwiftScriptが出来るかどうかは、単なる憶測の範囲。

**デフォルトの名無しさん** · 2014/06/29(日) 13:35:06.34

>>105
オープンソースになっても、言語仕様的にほかより優れてるの？そうじゃないと他の環境までは、はやらない

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

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

TypeScriptなんかがプリプロセッサなのはjavascriptによる過去の資源との互換性を保つためで、どの言語にもjsの置き換えを狙うのが無理そうだからだよ

**デフォルトの名無しさん** · 2014/06/29(日) 13:39:07.70

AltJSじゃだめな理由って何がある？

**デフォルトの名無しさん** · 2014/06/29(日) 14:57:50.22

>>107 そもそも、HTML内埋め込みインタラプト言語のJavaScript系と、オールマイティーなコンパイル言語系では用途が全く違う。

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

元々は全く違う用途。

**デフォルトの名無しさん** · 2014/06/29(日) 15:02:09.40

>>108
スクリプトとして動きそうというだけならC#なんかもそのうち動きそうだけど
Roslynもできたし、IOSを含め他の環境でももう動いてる

**デフォルトの名無しさん** · 2014/06/29(日) 15:16:22.91

>>106 >言語仕様的にほかより優れてるの？

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

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

プリプロセッサを排除した分、言語仕様の中で自分自身をを書き換える(オーバライド) 事が出来るのは今後の発展性を匂わせる。

**デフォルトの名無しさん** · 2014/06/29(日) 15:23:53.16

ID:mYSKVn4w
↑ただの知ったかぶりにしか見えん

**デフォルトの名無しさん** · 2014/06/29(日) 15:31:53.02

>>109 スクリプトとして動きそうと言うだけと、動く事を見据えた言語では仕様が異なる。

Swiftは動的関数な部分が大きい。最初からそう言う言語だからスクリプトとして動かしても性能を発揮出来る。
遅延評価lazy とか。

**デフォルトの名無しさん** · 2014/06/29(日) 16:24:07.43

ObjCとの比較を除けば、他言語との比較はまだ文法的に比較してここら辺似てるとか言ってる段階でなんとも言えないなあ
まだベータ版だし、Appleがどこまで公開するかと他環境への展開待ちかな

**デフォルトの名無しさん** · 2014/06/29(日) 16:50:02.83

コンピュータなんだから、どんな言語でも出来ないことはツギハギでも追加して出来る様にして行くから、出来ることは殆ど同じになるんだよね。

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

Swiftと言えど、過去のしがらみを全て捨てるわけにはいかなかったみたい。
過去の遺産を使う限り仕方ないだろうね。
生糸から紡ぎ治せれば良かったが、古着をほどいた糸で紡ぎ直したと言う感は否め無い。

**デフォルトの名無しさん** · 2014/06/29(日) 16:53:33.37

ID:mYSKVn4w からkenokabe臭がする

**デフォルトの名無しさん** · 2014/06/29(日) 16:59:42.98

>>112
動的関数って何？

**デフォルトの名無しさん** · 2014/06/29(日) 21:50:03.17

>>114
計算モデルを間違わない限りは、なんでも追加などしない。

**デフォルトの名無しさん** · 2014/06/30(月) 00:46:05.49

>>116
https://www.youtube.com/watch?v=jrjfZ2ltvgE

99 · 2014/06/30(月) 00:47:03.04

>>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 を持っててインタプリットしていると考えるのは不自然だ。
ちょっと検索してみたところでは、インタプリタとして動作していると信じている人は見つからなかった。
ソースがあれば出してくれ。

**デフォルトの名無しさん** · 2014/06/30(月) 01:35:18.75

>>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

**デフォルトの名無しさん** · 2014/06/30(月) 02:18:56.74

>>120 PlaygroundもLLDBが動いてる。

**デフォルトの名無しさん** · 2014/06/30(月) 09:46:26.06

>>120
＞The Swift REPL (Read-Eval-Print-Loop) acts like an interpreter.
「SwiftのREPLはインタプリタのように動作する」
つまり実際にはインタプリタでは無いんだよ

**デフォルトの名無しさん** · 2014/06/30(月) 10:53:35.14

>>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に入る。

**デフォルトの名無しさん** · 2014/06/30(月) 11:03:44.45

>>123
SwiftのREPLは逐次ネイティブコードに変換してから実行してるだろうからその1～3に当てはまらない

REPL=インタプリタでは無いよ？

**デフォルトの名無しさん** · 2014/06/30(月) 11:22:20.22

VSなんかILのインタプリタが搭載されてて
ダンプ情報をデバッガに読ませてエディットコンティニューなんて荒業が可能らしいよ

**デフォルトの名無しさん** · 2014/06/30(月) 12:15:26.35

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

何を言ってるんだお前は

**デフォルトの名無しさん** · 2014/06/30(月) 15:00:27.03

>>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;

**デフォルトの名無しさん** · 2014/06/30(月) 15:05:01.81

>>127 言い忘れた。　コンパイラは、MacOS上で動かしていてもコンパイル結果をターゲットのARMとしての出力が出来るのは当然。
だからと言ってARMの機械語で動かしている訳でない事も当然。

この意味が解るか？　機械語を実行している訳じゃないんだよ。

**デフォルトの名無しさん** · 2014/06/30(月) 15:24:33.50

>>127
だからさ、LLVM使ってればLLVM-IRとか出力できるのは当たり前なんだって
だけどLLVM-IRのファイル作れてもそれを直接解釈実行する仕組みはどこにあるんだ？

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

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

Swiftがスクリプト言語のように使えるとしても、それはLLVMとは関係無い
LLVMはネイティブコードを生成するために使ってるだけ
LLVMと無理やり結びつけて煽るのを止めてくれるかな？

**デフォルトの名無しさん** · 2014/06/30(月) 15:31:16.96

>>128
コンパイラなんてただの変換処理系なんだから、
コンパイラを動かしてるマシンやOSとコンパイラが出力するコードが関係無いのは当たり前じゃないか
そんなことをいちいち説明するのに何か意味があるのか？

**デフォルトの名無しさん** · 2014/06/30(月) 19:45:48.79

>>122
インタープリターだもんな

**デフォルトの名無しさん** · 2014/06/30(月) 19:47:58.85

>>127
どうしてassemblyって書いてあるのに、
あせんぶらっていうの？

**デフォルトの名無しさん** · 2014/06/30(月) 19:55:11.52

ブリよりもブラのほうが言いやすいだろ

**デフォルトの名無しさん** · 2014/06/30(月) 22:19:13.64

>>132
クロマトグラフィーを、クロマティと読んじゃうオッさんなんだろう。

**デフォルトの名無しさん** · 2014/06/30(月) 22:49:24.44

>>132　形容詞と名詞の違い。

**デフォルトの名無しさん** · 2014/06/30(月) 22:59:40.40

>>135
どっちも名詞すよ

**デフォルトの名無しさん** · 2014/06/30(月) 23:36:17.56

驚いたな。　こんな質問が飛び出すとは。
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

**デフォルトの名無しさん** · 2014/06/30(月) 23:39:44.51

いちいちWikipediaで調べるなよｗｗｗ

**デフォルトの名無しさん** · 2014/06/30(月) 23:45:21.80

ｱｾﾝﾌﾞﾘ
斡旋鰤

**デフォルトの名無しさん** · 2014/06/30(月) 23:45:39.62

>>138 いや最近の安い辞書に　assembler と言う訳が載っていないことに驚いたんだよ。
昔はassemblerの方が一般的だったのに。
質問が出てきた意味が解った。　assemblyの語源はassembler 。

少なくともプログラムする人間は、コンパイラ、アセンブラと言う言葉位は知っておいてほしいな。

**デフォルトの名無しさん** · 2014/07/01(火) 00:04:40.17

>>140
なんでそんな自信たっぷりに適当なことを撒き散らせるんだ
普通、語源と言ったらassembleかassemblyの方だ
erを付けて～するモノって意味になるのだよ

**デフォルトの名無しさん** · 2014/07/01(火) 00:05:01.02

なんだこいつ

**デフォルトの名無しさん** · 2014/07/01(火) 00:42:27.49

>>141
http://i.imgur.com/pjOBAo2.jpg

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

>>137
-emit-assembly
のassemblyをアセンブラーって書いたコトにつっこまれてんだけど

**デフォルトの名無しさん** · 2014/07/01(火) 01:17:33.69

フランス語のassemblerと英語のassemblerは意味がちょっと違う
>>143はフランス語のassemblerが英語のassembleになったってことだぞ
そして英語では、そのassemble+erでassembleするものって意味になるわけだ

万が一ｗ、>>140のassemblerをフランス語の意味で使ってたならすまんかったなｗ

**デフォルトの名無しさん** · 2014/07/01(火) 01:38:08.58

Sports Music Assemble People

**デフォルトの名無しさん** · 2014/07/01(火) 02:15:49.54

>>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

**デフォルトの名無しさん** · 2014/07/01(火) 06:56:44.45

>>147
-emit-assembly

**デフォルトの名無しさん** · 2014/07/01(火) 09:06:53.93

-emit-assembly file

**デフォルトの名無しさん** · 2014/07/02(水) 01:21:30.49

>>120
ええと、それで >94 を正当化できるの？
別に on the fly でコンパイルするシステムをインタプリタと呼んではいけないとは思わないが、
例えば CINT が JIT 積んだらほとんどそうなるわけだし、だが LLVM IR をインタプリットしないと
>94 は成り立たないだろう。

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

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

>94 を捨てて別の主張を始めること自体は構わないけど、今度は >94 のような出鱈目を吹聴しないようにしてね。

**デフォルトの名無しさん** · 2014/07/02(水) 02:00:05.61

インタプリタではないがこれ面白いぞ。

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