今後のVim scriptをどうするのかについて検討する

[Shougo]

現在Vim scriptには、効率やライブラリ不足の問題、オブジェクト指向・無名関数・Bool型などの近代的プログラミング言語に存在する機能の欠如の問題、Vim scriptプログラマーの不足問題があります。
これを根本的に解決するには、KoRoNさんが言うように、Vim scriptを段階的に廃止するしかないのかもしれません。

代替言語としてLuaやPythonなどが挙げられています。
特にLuaは速度も早く、組み込み用として使われているため、Vimに組み込む言語としては理想的かもしれません。

もしこれが実現するとすれば、LuaのソースコードをVimに同梱するような方式になるのではないかと思われます。
もちろん機能を無効化できますが、標準的には有効化されるのが理想です。

[koron]

廃止する必要はなくて、内部の1st classなスクリプト言語をVimL以外に変更し、
VimLからその言語へのトランスレータを実装して互換性を確保する、みたいなことができればよいかと。

私がそもそもそれを言い出した真の目的は、
その過程で内部的にVimの各機能のモジュール化とI/Fの整理を起こすことです。
それによりVim全体のメンテナンスコストを引き下げ、
本体の開発に関わるのに必要になる技術レベルが格段に引き下がる、という寸法。

別issue建てるべきか?

[Shougo]

廃止する必要はなくて、内部の1st classなスクリプト言語をVimL以外に変更し、
VimLからその言語へのトランスレータを実装して互換性を確保する、みたいなこと
ができればよいかと。

今日もう一度Luaの言語仕様を見てみましたが、Vim scriptにかなり似ているし、
endもあるしでかなり相性は良いと思われます。そこそこ有名だし、第一候補ですね。
互換性に関しては、外部インタフェース言語で行われているeval()が動く程度あれば良いと思います。

そういえば、Vimはmappingの実装もハードコーディングでひどかったですね……。

その過程で内部的にVimの各機能のモジュール化とI/Fの整理を起こすことです。
それによりVim全体のメンテナンスコストを引き下げ、
本体の開発に関わるのに必要になる技術レベルが格段に引き下がる、という寸法。

はい。Vim本体は言語を拡張するのではなくて、エディタとしての機能に専念すべき、それは私もそう思います。

別issue建てるべきか?

せっかくなので、もうちょっと深く議論してからにしましょう。
vim-jpでこの件に関して、どういう流れで進めていくか、Bram氏の説得をどうするか、などが焦点となるでしょう。

[koron]

内部的にVimの各機能のモジュール化とI/Fの整理

この意味では、別のissueで思いついたif_cでも良いわけだ。

[Shougo]

そうですね。

[Shougo]

Vim scriptの利点：
安定している
Vimに標準搭載されている
長年の実績
10年前のスクリプトが修正なしで動作するほどの高い上位互換性

Vim scriptの欠点：
Vimにしか使えない
ライブラリが少ない(Vital.vimを用いるとある程度改善できる)
Vim scriptからは使えない機能がある
他の汎用言語と比較すると言語仕様が貧弱
Pythonと比較して、20~100倍遅い
複雑で非効率な内部実装
他のプログラミング言語と異なる正規表現のパターン

最近、Vim scriptについて色々と考えることが増えてきました。
私のプラグインも完全に書きなおすときは、他の外部インタフェースを使うようにするべきなのかもしれません。

が、現在の外部インタフェースには次の問題があります。

外部インタフェース全般：
標準で有効になっていない。有効にするにしても、手順がかなり煩雑
if_lua等マイナーな外部インタフェースでは自分でビルドしない限り有効化する方法がない
Androidなど、小型の組み込み機器用のVimで有効化するのはとても難しい（不可能？）
エラーメッセージがわかりづらいため、デバッグがしづらい
クラッシュするなどの致命的なものを含めバグが多い
インタプリタのバージョンアップ時に問題が発生することが多い
外部言語の仕様変更の影響を受ける
ほとんどの外部インタフェースは一部のマニアしか使っていない

http://vim-users.jp/2013/01/vim-advent-calendar-2012-ujihisa-2/

if_gaucheなども人気ですね。実はif_luaというものもあるのですが、僕の知る限りでは、まだあまり普及していないようです。Luaという言語は他の環境に組み込まれることを強く意識されたものであるという背景から考えるに、この状況はあまり好ましくないのではないかと危惧しています。
if_luaがあまり普及していない原因の一つとして、たいていのVimパッケージがif_luaを搭載していないからというのが挙げられます。パッケージとそのオプションの選択肢の豊富さに定評ある、Vim使いに人気のLinuxディストリビューションであるGentoo Linuxですら、if_luaることができません。

[Shougo]

Pythonインタフェースの利点：
世界中において、圧倒的な知名度
他の外部インタフェースよりは導入しやすい
豊富な標準ライブラリ
外部プロセスとの通信インタフェース
スレッド
有名なプラグインでの使用実績がある(vim-powerline, UltiSnips, Conque, YetAnotherComplete)
voteでの高い要望率

Pythonインタフェースの欠点：
Python2とPython3間の断絶（Python3はいまだに普及しきっていない）
Ruby, Perlと比較すると一部の拡張正規表現が使えない
標準で組み込むにしては巨大すぎる

Luaインタフェースの利点：
スクリプト言語において圧倒的な速度
組み込み言語としての豊富な実績
C言語との親和性（外部インタフェース仕様がドキュメント化されている）
文法がVim scriptに似ている

Luaインタフェースの欠点：
一部の言語仕様に、他の言語と比較して使いづらい部分あり
もともと組み込み用の言語なのに、標準では有効になっていない
ライブラリや言語としての機能はあまり豊富でない（最近はLuaRocksでライブラリ不足はある程度解消できる？）
正規表現（のようなもの）は独自実装であり、パターンの選択等がない

mrubyインタフェースの利点：
Rubyと比較して組み込みやすい
Rubyよりも高速
プログラマにやさしい言語仕様

mrubyインタフェースの欠点：
本家のRubyより機能やライブラリは少ない
使用出来るライブラリがビルド時に決まる
パッチがVim標準に取り込まれていない（そもそもパッチが無視されている？ if_gaucheの悲劇再び？）
日本以外では知名度がない
まだ開発中

その他の言語：
そもそも、プラグインで実際に使っているのをほとんど見たことがない……。

[Shougo]

何の言語を利用するにせよ、標準で有効にすることと安定性の確保が必要不可欠となると思います。

※；ちなみに、if_luaを使っているプラグインをkaoriyaさんのもの以外で見たことがないんですよね……。

[Shougo]

この議論、一度vim_devに持っていく必要があるんでしょうかね？
Bram氏がVim scriptと外部言語インタフェースについてどういう考えなのかを知りたいです。
Vim scriptを機能強化していくつもりなのか、複雑な機能を外部インタフェースで賄うつもりなのかどうか。

[Shougo]

https://twitter.com/tyru/status/315697636554444800

本題の件については、トランスレータが一番だと思ってる。でもVimscriptのトランスレータって難しそう... kanaさんとかもGauche→Vimscriptトランスレータ作ってたけど。

https://twitter.com/kaoriya/status/315703919231791104

vimparseができたのでアレベースでluaかpythonにトランスレートするのが良いと思う。それで実行速度が数倍になれば無視できないかと。

[Shougo]

vimlparser標準同梱->Luaにトランスレート->Luaを標準で有効化(big以上？)→if_lua標準化という流れ？
それはアリですね。
https://github.com/ynkdir/vim-vimlparser

vim7.4がもうすぐみたいだし、ここの議論もそろそろ本格的にやったほうが良いような気がする。
外部インタフェースの安定化は、いろんなプラグインがどんどん使って行くことで枯れさせるしか無いでしょう。

[k-takata]

Rubyよりも高速

mrubyってそういうこと謳ってましたっけ。

その他の言語：

一応標準のものを全部列挙しておきますか。
Lua, MzScheme (Racket), Perl, Python2 & Python3, Ruby, Tcl

[Shougo]

mrubyってそういうこと謳ってましたっけ。

それが本来の目的ではないですが、機能を絞ってあるため一応CRubyより高速のようです。
とはいえ、今の状態では他のインタプリタより圧倒的に高速というわけではなかったはず。
まだ速度には改善の余地があります。

一応標準のものを全部列挙しておきますか。
Lua, MzScheme (Racket), Perl, Python2 & Python3, Ruby, Tcl

ありがとうございます。サポートしている言語の数は多いんですけどね……。今の状態ではいかんせん使いにくい。
マニアの人しか有効にはしていないですし。

[Shougo]

テストスクリプトを書いてみました。

https://gist.github.com/Shougo/5231273

結果がなかなか衝撃的です。
n = 5
Vim Language -> 0.000540
if_lua -> 0.000188
if_python -> 0.000562

n = 10
Vim Language -> 0.004698
if_lua -> 0.000241
if_python -> 0.000682

n = 15
Vim Language -> 0.020960
if_lua -> 0.000315
if_python -> 0.000699

n = 20
Vim Language -> 0.183925
if_lua -> 0.002561
if_python -> 0.005035

n = 25
Vim Language -> 1.956016
if_lua -> 0.026156
if_python -> 0.053765

結論：
Vim scriptはif_luaの25〜100倍くらい遅い。if_luaはif_pythonの2倍速い。高速な組み込みスクリプト言語は伊達じゃない。

[k-takata]

VimLだけFib内の条件式が違いません？

[koron]

@k-takata たしかにw 100倍は到底縮まらないと思いますが、フェアではないですねw

[Shougo]

if_rubyも入れて、再測定しました。条件式も修正しています。

n=5
Vim =   0.000146
if_lua =   0.000075
if_python =   0.000242
if_ruby =   0.000136

n = 10
Vim =   0.001284
if_lua =   0.000099
if_python =   0.000271
if_ruby =   0.000155

n = 15
Vim =   0.014983
if_lua =   0.000290
if_python =   0.000680
if_ruby =   0.000381

n = 20
Vim =   0.154179
if_lua =   0.003537
if_python =   0.005308
if_ruby =   0.002678

n = 25
Vim =   1.782377
if_lua =   0.029014
if_python =   0.059784
if_ruby =   0.030475

ちなみに、一度目の実行はインタプリタの起動に若干時間がかかるのでそれは除外してあります。
結果としては、Vim script >>> 超えられない壁 >>> if_python > if_ruby > if_lua となりました。
意外にも、if_rubyがかなり高速なのが驚きです。ときにはif_luaよりも高速な結果を出しています。

[Shougo]

さらにスクリプトを改造、単体で動作するようにして試しました。
結果は以下の通り。
$ vim -u fib.vim -U NONE -i NONE -c "quit" --noplugin

n = 5
Vim = 0.000129
if_lua = 0.000096
if_python = 0.000235
if_ruby = 0.000088
n = 10
Vim = 0.001247
if_lua = 0.000073
if_python = 0.000190
if_ruby = 0.000091
n = 15
Vim = 0.014269
if_lua = 0.000296
if_python = 0.008708
if_ruby = 0.000364
n = 20
Vim = 0.163489
if_lua = 0.002734
if_python = 0.005915
if_ruby = 0.002803
n = 25
Vim = 1.795778
if_lua = 0.027266
if_python = 0.057027
if_ruby = 0.028487

[k-takata]

それぞれのインタプリタのバージョンは？

結果としては、Vim script >>> 超えられない壁 >>> if_python > if_ruby > if_lua となりました。

if_luaの60倍程度の遅さですか。インタプリタそのものの性能はそんなものだとして、後はVimとの間で頻繁にデータをやりとりする場合のオーバーヘッドはどうなのかというのも気になりますね。

[Shougo]

環境は、Ubuntu 12.10のディストリビューションにて標準でインストールされるものです。
具体的には、
Vim 7.3.875
Lua 5.2
Python 2.7.3
Ruby 1.9.3p194
です。

if_luaの60倍程度の遅さですか。インタプリタそのものの性能はそんなものだとして、後はVimとの間で頻繁にデータをやりとりする場合のオーバーヘッドはどうなのかというのも気になりますね。

頻繁にやり取りをすると、文字列との変換が発生するので遅くなります。やり取りは最小限にするほかないと思いますね。
ちなみに、Luaは初回時のインタプリタ起動もかなり高速ですね。やはり組み込み向けだからかな。

[Shougo]

各インタフェースの速度比較用に、汎用的なベンチマークスクリプトは欲しいですね。
誰か作ってくれないかな……。

[Shougo]

if_luaの60倍程度の遅さですか。インタプリタそのものの性能はそんなものだとして、後はVimとの間で頻繁にデータをやりとりする場合のオーバーヘッドはどうなのかというのも気になりますね。

Dict, ListについてはLuaは直接Vim scriptとやりとりできるようなのでそこのオーバーヘッドは小さいものと考えられます。

[Shougo]

あとは、KaoriyaさんのVimがデフォルトでluaインタフェースが有効になっているといろんな人が幸せになる予感はします。

[koron]

@Shougo なってるよ。別途インストールする必要はあるけど。

[Shougo]

ふむふむ。Luaを同梱できると一番良いですね。
何も考えずに使えるのが理想です。特にWindows環境では。

[koron]

やべぇ。LuaJITにするとn=25の時、通常Luaに比べて10倍の性能がでてたwww
もうシャレにならないレベルwww

通常のLua での計測結果

LuaJIT版 での計測結果

[k-takata]

1000倍w

[koron]

とりあえず次から LuaJIT の DLL をバンドルすることに決めましたwww
1000倍はインパクトがでかすぎるwww

[mattn]

結果としては、Vim script >>> 超えられない壁 >>> if_python > if_ruby > if_lua となりました。

こういう場合、優越優劣 なので等号逆に書きませんかw

[koron]

@mattn 👍 ちなみにこの場合は 優劣 じゃないかなw

[Shougo]

こういう場合、優越優劣 なので等号逆に書きませんかw

速度の比較として書いたのですが、確かにわかりづらいですね。

とりあえず次から LuaJIT の DLL をバンドルすることに決めましたwww
1000倍はインパクトがでかすぎるwww

それは素晴らしい。vim-jpが推す、Vim scriptに代わる第二言語はif_luaで決まりですかね。
if_pythonばかりの現状を変えて行きましょう。
if_pythonはPythonのライブラリが必要なとき（Conque, clang_complete, jedi, vinarise等）に使うべきであって、
Vim scriptを高速化したい場合だけならif_luaを用いるべきだと思います。

[koron]

つまり 関数呼び出しコストだけ なら Ruby のほうが Python よりも速い?

[methane]

えぇ、pythonで定義した関数の呼び出しは遅いです。
そこがボトルネックになることはあまり無いですが。

vimスクリプトとして利用する場合に関して言えば、そこよりもスクリプトの読み込み速度が重要だと思います。
luaはそこも充分速いですが、できればpythonのpycみたいなバイトコードキャッシュを実装したい。

[koron]

文字化け修正しました。

バイトコードキャッシュを実装したい。

Lua自体はバイトコード生成&読込みできるハズなので、工夫次第ですかね。

[Shougo]

バイトコードのキャッシュで早くなるのはファイルの読み込み速度だけらしいですね。あと、キャッシュの更新処理はそれなりに遅くなります。キャッシュ化でどれだけ速度が変化するのか、まずは計測してみてはどうでしょう。
例えば、zshだと処理をキャッシュ化してもほとんど速度が変わらないようです。

[methane]

@Shougo zshをよく知らないのですが、あれって内部でオペコードにコンパイルしてるんですか？
php だと APC で性能が2倍前後になる（phpはWebリクエストのたびに全てのソースを読みなおすので）とかありますし、
Python だって効果がなければ pyc なんて面倒なものいちいち作りません。

[methane]

https://gist.github.com/methane/5268143
Python ですが、バイトコードキャッシュのあるなしで import の速度がだいたい倍になります。
これはモジュールレベルで代入している（つまりimport時に全コードが実行される）のですが、実際には
関数を定義するだけでその中は実行しない場合がほとんどで、 import 速度は倍以上変わると思います。

[methane]

でも、 vim スクリプトも読み込むときにバイトコード作ってないとは言え構文解析はしてるだろうし、
Lua なら起動速度落とさないで済むかもしれないですね。
キャッシュのことを考えるのは、ある程度のボリュームのあるコードを Lua で書いて、ロード時間が
問題になってからでも遅くないはずです。

[koron]

構文解析(白目

[methane]

@Shougo ごめんなさい、会話が食い違っていたかもしれません。
私は実行時間は（良くなるのが明白なので）気にしていません。
Vim スクリプトを Lua で置き換えた時に vim の起動速度が落ちないかどうかを気にしていました。

でも、最初にやることは if_lua でプラグインを書いた時に vim スクリプトに比べて足りない点を
見つけて if_lua にインタフェースを追加していくことだと思います。
if_luaが充実してLuaで書かれた便利なプラグインが広めることでデファクトスタンダード化を狙える

[Shougo]

Vim スクリプトを Lua で置き換えた時に vim の起動速度が落ちないかどうかを気にしていました。

起動速度は明確に落ちません。なぜなら、Luaインタプリタの起動がとても早いからです。1msかからないので誤差の範囲。
さらにVimスクリプトの解析がLuaによって早くなるならむしろ大幅に高速化しても不思議ではありません（.vimrcが巨大だったりプラグインのインストールが多い場合）。

@Shougo zshをよく知らないのですが、あれって内部でオペコードにコンパイルしてるんですか？
php だと APC で性能が2倍前後になる（phpはWebリクエストのたびに全てのソースを読みなおすので）とかありますし、
Python だって効果がなければ pyc なんて面倒なものいちいち作りません。

zshがOPコード形式なのかどうかはよくわかりません。が、zshにはスクリプトのコンパイルを行うzcompileというコマンドがあり、何らかの最適化をしているのではないかと考えています。

Python だって効果がなければ pyc なんて面倒なものいちいち作りません。

だとは思うのですが、自動的にキャッシュするインタプリタはPythonくらいしか聞かないですね。
そんなに効果があるなら他のインタプリタも採用しそうなものですが……。デメリットが大きいのかもしれません。

でも、最初にやることは if_lua でプラグインを書いた時に vim スクリプトに比べて足りない点を
見つけて if_lua にインタフェースを追加していくことだと思います。
if_luaが充実してLuaで書かれた便利なプラグインが広めることでデファクトスタンダード化を狙える

はい。それは思います。が、そういう部分は一時的にVim scriptを呼び出して解決するべき問題のような気もしていて、
難しいんですよね。例えば、ファイル操作がLuaには足りないので、置き換えを狙うならほしいところです。

[methane]

起動速度は明確に落ちません。なぜなら、Luaインタプリタの起動がとても早いからです。1msかからないので誤差の範囲。

インタプリタの起動時間じゃなくて、 Lua コードの読み込み時間を気にしています。
インタプリタが1msで起動できても、 Lua ファイルを1つ読み込むごとに数msかかっていたらトータルで
Vimの起動速度が落ちる可能性があります。
Vim 自体の起動速度が速くても、Vim スクリプトをたくさん読み込むと Vim の起動速度が落ちるのと全く同じです。

さらにVimスクリプトの解析がLuaによって早くなるならむしろ大幅に高速化しても不思議ではありません（.vimrcが巨大だったりプラグインのインストールが多い場合）。

これは、Cで書かれたvimスクリプトの解析処理を Lua に書き換えて速くなるという意味でしょうか？

だとは思うのですが、自動的にキャッシュするインタプリタはPythonくらいしか聞かないですね。
そんなに効果があるなら他のインタプリタも採用しそうなものですが……。

phpは負荷が大きいなら APC などのバイトコードキャッシュがほぼ必須になっています。
nginx の lua モジュールもデフォルトでバイトコードキャッシュを有効にしていて、 require が繰り返し
呼ばれてもパフォーマンスが落ちないようになっています。
Xyzzy も設定ファイルをコンパイルすることで起動速度が大幅に向上しています。

一般的に構文解析＆簡単な最適化＆OPコードの生成という一連の動作はかなり重いので、
OPコードを採用している言語ならほぼ確実にキャッシュで起動時間が大幅に高速化ができます。

デメリットが大きいのかもしれません。

はい、メリットはもちろんあります。
キャッシュファイルが増える。キャッシュシステムの分だけプログラムが複雑になるなどです。
なので実際に起動時間が問題になってから考えたのでいいと思います。

が、そういう部分は一時的にVim scriptを呼び出して解決するべき問題のような気もしていて、
難しいんですよね。

インタフェースを増やすとメンテナンスが大変になりますよね。
一方で2つの言語の往復は、システム的にも、人間の脳に対してもオーバーヘッドがあるので、
呼び出し頻度が高いものだけを上手く抽出できるといいと思います。

[methane]

https://gist.github.com/methane/5268614

10000行の代入文で試してみました。
結果、Lua はソースコードから実行するだけで Python のバイトコードキャッシュが効いた状態に近い速度で、
バイトコードキャッシュを使うとさらに40%高速化するようです。
（Python はグローバル変数への代入が遅いとはいえ）かなり早いですね。

さらに、 Lua JIT を使うと、ソースから実行しても lua のバイトコードキャッシュ使った状態に近い速度が出ました。
LuaJITでバイトコードキャッシュを使う方法が判らない（コマンドラインからはできない？）のですが、
ここまで速いとキャッシュなくても大丈夫そうですね。

[Shougo]

インタプリタの起動時間じゃなくて、 Lua コードの読み込み時間を気にしています。
インタプリタが1msで起動できても、 Lua ファイルを1つ読み込むごとに数msかかっていたらトータルで
Vimの起動速度が落ちる可能性があります。
Vim 自体の起動速度が速くても、Vim スクリプトをたくさん読み込むと Vim の起動速度が落ちるのと全く同じです。

実際に見てみないとわかりませんが、私はVim scriptのほうが解析が遅いと考えています。一度ベンチマークをとってみたいですね。if_luaでのLuaスクリプト読み込みと、sourceの読み込みでどちらが高速なのか。

これは、Cで書かれたvimスクリプトの解析処理を Lua に書き換えて速くなるという意味でしょうか？

いいえ。Cで書かれたVim scriptの解析処理を同じくCで書かれたLua scriptの解析処理に置き換えれば早くなるのではないかという予想です。

一般的に構文解析＆簡単な最適化＆OPコードの生成という一連の動作はかなり重いので、
OPコードを採用している言語ならほぼ確実にキャッシュで起動時間が大幅に高速化ができます。

ふーむ。その割にはデフォルトでキャッシュする処理系は少ないですよね……。メリットが大きいなら大抵の処理系で採用しそうなものですが。
バイトコードのキャッシュはバージョン間互換性がなくなるのが問題になるようです。Python3.3のようにインタプリタのバージョンごとにキャッシュディレクトリを分けるという方法を取る必要があります。

[Shougo]

インタフェースを増やすとメンテナンスが大変になりますよね。
一方で2つの言語の往復は、システム的にも、人間の脳に対してもオーバーヘッドがあるので、
呼び出し頻度が高いものだけを上手く抽出できるといいと思います。

呼び出し頻度が高いものを抽出する作業が面倒そうですね。他の外部インタフェースでは大幅に関数を追加しているのはないので、それがどれだけ受け入れられるかがわかりません。できればLua側に関数があれば良いというのには同意です。Luaインタフェースを利用する場合、Vim以外の外部のライブラリに頼ることは難しいと考えられるため。

10000行の代入文で試してみました。
結果、Lua はソースコードから実行するだけで Python のバイトコードキャッシュが効いた状態に近い速度で、
バイトコードキャッシュを使うとさらに40%高速化するようです。
（Python はグローバル変数への代入が遅いとはいえ）かなり早いですね。

ふむ。確かに、キャッシュされると読み込みは高速ですね。

ただ最近の流行だと、起動時にはそもそもスクリプトを読み込まないのが主流なんですよね。キャッシュがどれだけ効果があるのかなぁという気はしています。

[methane]

ただ最近の流行だと、起動時にはそもそもスクリプトを読み込まないのが主流なんですよね。キャッシュがどれだけ効果があるのかなぁという気はしています。

はい、私もこのベンチマークを見た限りでは、Luaのソース読み込みは充分に高速なのでキャッシュは要らないと思います。

[mattn]

ここに書くべきか迷いますが一応書かせて貰います。場違いコメントすみません。

vimは保守的なアプリケーションである事は皆さんご存知の通りで、おそらくBramはデフォルトのスクリプト言語を入れ替えるのには難色を示すと思います。ランタイムの要る処理系、バージョンアップにより互換性を失う処理系、それらはvimが欲している物ではないだろうし、それらがバージョンアップ等で動かくなる事でvimが使えなくなる事は、unixエンジニアにとって命取りになる事を意味していて、Bramがみすみす足を踏み入れる事はしないでしょう。

本件、研究課題として面白いと思っています。
僕が以下のツィートで「もし」と付けたのはそれが理由で、おそらく無いと思ってるからです。

https://twitter.com/mattn_jp/status/316948480788680704

何かしらの言語を取り入れるという事は、vimスクリプトでないvimrc(exrc)を含むvim scriptを解釈出来る処理系と、その追加言語の処理系を2重で管理する事になります。おそらく現状のvimrcが記述出来なくなる事に猛反発を食らうのは絶対で、だったらなおさらトランスレータがいいという理由にも納得は出来るのですが、それをやるのは道のりが遠すぎる気がしてならないのです。

• vim scriptを捨てて他の言語にスィッチする
• vim scriptをパフォーマンスチューニングする

前者の解決策としてトランスレータもあると思いますが、あり得る方向としては

「vim scriptは廃止する。全ユーザにvimrcの記述を時期を見計らって捨ててもらう。それまではXXX言語と併用可能とする。」

という可能性しか無いんじゃないかと思っています。それにはおそらく数年以上のスパンが必要かなと思います。そして数年経てばluaよりも良い言語が出てきても可笑しくないとも思います。

それに比べて後者は、それほど突飛な変更でなければ結構パッチウェルカムな状態にあると思っています。

[koron]

@mattn

vim scriptをパフォーマンスチューニングする

それは単に別issue立てるべきでは?

[mattn]

@koron パフォーマンスチューニング案を押したいという訳でなく、一度 vim-dev に持ち込んで議論した方がいいかもしれないと思っています。深刻に思ってるの、おそらくvim script大好きな日本人くらいしかいないんじゃないの？って気もします。
その意味で「段階的廃止」という、このissueのタイトルに対して「ちょっと待って」の意味のコメントをつけました。
別issueでは無いと思います。

[Shougo]

パフォーマンスチューニング案を押したいという訳でなく、一度 vim-dev に持ち込んで議論した方がいいかもしれないと思っています。深刻に思ってるの、おそらくvim script大好きな日本人くらいしかいないんじゃないの？って気もします。

日本人に多いのは確かですが、MarcWeber氏やYouCompleteMeの作者のVal Markovic氏、UltiSnips作者のHolger Rapp氏など現在のVim scriptに否定的な見方を持っている人は何人かいます。

最近だと、こういう記事もありました。

http://delvarworld.github.com/blog/2013/03/16/just-use-sublime-text/

Vim scriptを真面目に書いたことがある人があまりに少ないので少数派に見えるのかも知れません。

ランタイムの要る処理系、バージョンアップにより互換性を失う処理系、それらはvimが欲している物ではないだろうし、それらがバージョンアップ等で動かくなる事でvimが使えなくなる事は、unixエンジニアにとって命取りになる事を意味していて、Bramがみすみす足を踏み入れる事はしないでしょう。

はい。私もそう思います。特にPyなんとかさんはランタイムが大きすぎるし互換性の問題があるのでデフォルト言語になることはないでしょうね。言語のユーザー数は圧倒的には多いので要望は強いですが。Emacs Lispがなくならないのも同様の理由からでしょう。

前者の解決策としてトランスレータもあると思いますが、あり得る方向としては
「vim scriptは廃止する。全ユーザにvimrcの記述を時期を見計らって捨ててもらう。それまではXXX言語と併用可能とする。」
という可能性しか無いんじゃないかと思っています。それにはおそらく数年以上のスパンが必要かなと思います。そして数年経てばluaよりも良い言語が出てきても可笑しくないとも思います。

これは、何らかの原因によってBram氏がメイン開発者から降りれば可能になるかもしれません。ただ、様々な方面からの反発は避けられないことになるでしょう。Vimコミュニティが分断されてしまう気がしますね。何の言語を選ぶかはそれこそ、政治的な駆け引きがいろいろとあるでしょうし。

vim scriptをパフォーマンスチューニングする

実は私としても、速度・機能的な面でVim scriptが改良されるなら、そちらのほうが望ましいと考えています。
しかし残念ながら、そういう流れにはなっていません。
私はLua, Python, Ruby等の外部インタフェースとVim scriptの速度差を明らかにすることで問題提起がしたかったのです。

私としてはBram氏のVim scriptに対する考えを聞きたいです。今後Vim scriptをどうしたいのか。
Vim7の時のように今後も拡張していくつもりなら、後はパフォーマンスと機能の問題さえ解決すれば文句はありません。
私はVim scriptそのものを嫌っているわけではないので。

その意味で「段階的廃止」という、このissueのタイトルに対して「ちょっと待って」の意味のコメントをつけました。
別issueでは無いと思います。

タイトルは過激だったですね。「今後のVim scriptをどうするのかについて検討する」くらいが妥当であったのかも知れません。
でも私としてはVim scriptが今後パフォーマンス・機能の両面で進化しないなら、残念ながら廃止するしか無いと考えています。

[h-east]

タイトル変更しました。
「Vim scriptの段階的廃止をどうするかについて」
↓
「今後のVim scriptをどうするのかについて検討する」

[koron]

大前提として完全な廃止はVimとして無いと考えてます。なので現実的なラインとして

• Vimスクリプトの実行自体を速くする/バイトコードとか (Vim スクリプトの実行速度向上/バイトコード化 #347)
• 実行時にトランスレータ噛ませて、より高速なVMに任せる (Lua トランスレーター作ろう #340)

の2つが考えられる。

他の案がなければもうこのissueは閉じるべきだと考えますがいかがか?

[Shougo]

タイトル変更しました。
「Vim scriptの段階的廃止をどうするかについて」
↓
「今後のVim scriptをどうするのかについて検討する」

了解です。

他の案がなければもうこのissueは閉じるべきだと考えますがいかがか?

はい。それ自体は問題ないです。ただ、Bram氏の考え自体はvim_devで一度聞いておきたいのですがどうでしょうか。

[Shougo]

こんなThreadがあったので転載します。

why does VimL suck?
http://www.reddit.com/r/vim/comments/1bf672/why_does_viml_suck/

[mattn]

.oO( リンク貼るのは転載じゃないす)

[Shougo]

Oh……。

[Shougo]

itchnyさんの記事、こちらにもリンクを貼っておきます。

http://d.hatena.ne.jp/itchyny/20130402/1364867392

[koron]

議論の結果、方向性が2つに集約され、それぞれに issue が作られました。

• Vimスクリプトの実行自体を速くする/バイトコードとか (Vim スクリプトの実行速度向上/バイトコード化 #347)
• 実行時にトランスレータ噛ませて、より高速なVMに任せる (Lua トランスレーター作ろう #340)

よって本件は duplicated とします。