00:09
こんにちは、OSSのレキシラジオです。
このポッドキャストでは、エンジニアのhentekoが毎週一つのOSSプロジェクトを取り上げて、そのプロジェクトにまつわる歴史を紹介する番組になります。
本日は番外編として、vintの作者である国明さんにゲストとして来ていただき、いろいろなお話をお聞きしました。それではどうぞ。
自己紹介と最近の出来事
はい、それでは本日はvintの作者である国明さんに来ていただき、vintについていろいろお聞きしていきたいなと思います。
国明さん、よろしくお願いします。
はい、よろしくお願いします。
はい、ありがとうございます。
まず簡単に国明さん、自己紹介の方をお願いしてもよろしいでしょうか。
はい、私は今、暗号資産関連の会社に勤めていて、品質と生産性の両方を良くする仕事みたいな感じのことをやっています。
はい、よろしくお願いします。
はい、よろしくお願いします。暗号資産関連の会社という、ちょっと濁しつつというような形ですかね。
そうですね。
はい、ちょっと軽く先に雑談したいなと思うんですけど、なんか最近あったこととかってありますかね。
ちょうど今桜とかが綺麗な季節だと思ってて、中目黒に花見に行きました。めっちゃ混んでて大変だったんだけど、やっぱりお祭り感とかがあって子どもたちも結構喜んでました。
中目黒は結構行ってたりするんですか、毎年。
ちょうどこれから話すビントとかの開発時期には、中目黒とかの辺りに住んでた時期があって、それでその頃から桜綺麗だなっていうのと、あとお祭り結構好きなんで、お祭りいいなっていうので行ってますね。
いいですね。かなり混んでました、もう人。
駅出る時とか、もう誘導員さんが何人も立ってて、そんな感じで厳重な警備態勢みたいな感じで。
実は中目黒の、目黒川の桜、すごい綺麗だって有名なんですけど、実は一回も行ったことがなくて。
なるほど。一度行くといいです。遊覧船とかもあるんで、結構ちょうど川沿いに咲いた桜を見ながら船で優雅に何かをするみたいなこととかもできるので、ぜひ行ってみてください。
ありがとうございます。ちょっと来年あたり行ってみようかなと思います。
vintとは何か？静的解析ツールの基本
そんな繰り上げさんなんですけど、今日はBintについてお聞きできたらなと思うんですけど、まずBintがどんなツールか、どんなプロジェクトかをざっくり教えていただいてもいいですかね。
Bintは、まずBintっていうのは静的解析ツールなんだけれども、まず静的解析ツールって一体何なのかの説明からします。
よく皆さんがJavaScriptとかあるいはPythonとかで開発するときにESLintとかPyflexとかっていうようなツールをよく使うと思います。
これらはLintツールっていうふうに呼ばれていて、ソースコードの隠れた問題だったりだとか、あとは一貫性に反しているとかコミュニティのガイドラインに反しているみたいな、そういうふうなところを見つけてくれるようなツールになってます。
ソースコードを試させると問題を出してくれる、そういうふうなツールですね。
BintっていうのはこれのVimスクリプト版です。VimスクリプトっていうのはVimの設定ファイルを記述する言語のことで、
例えば皆さんがVim使ってるんだったらVimRCとかにいろいろ書いてる人が多いと思います。このVimRCの記述言語がVimスクリプトです。
要するにこのVimスクリプトのコードを食べて問題を這いてくれる。これがあなたのコードはここがちょっと良くないですよってことを這いてくれる、そういうツールがBintです。
ありがとうございます。結構最近Vimを使い始めてるっていう人、AI文脈で結構多くなってきてるのかなっていうのを体感を持ってるんですけど、
そういった時に使われるようなLintとして、LintのツールとしてあるのがBintというようなところですね。
そうですね。
Lintオタクへの道とvint開発の動機
ありがとうございます。じゃあちょっとここからはですね、BintをそういったLintツールであるBintをなぜ作ったのかみたいな動機みたいなところからお話聞ければなと思うんですが、
その前にですね、そもそもなんでLintツールを作ろうと思ったのかみたいな。
国明さんのプロフィールとかにLintフリークだったりLintオタクみたいなことを書かれてるかなと思うんですけど、そうLintオタクになったきっかけみたいな背景あったりするんですか。
私は結構いろんな言語のLintを読むのが趣味ですね。趣味で、大体の言語のLintツールは目を通しました。
JavaScriptのLintって結構世代がいくつかあって、一番最初はJSLint、その次にJSHintっていうのが来て、今はESLintがいいですよね。
あとはいろいろESLintの後にもいろいろなものが来てると思います。こういうふうなLintとかっていうのを大体読んでいて、ここが良かったね、ここがちょっと良くなかったねみたいなところとかをいろいろ集めたりとかしてたんですね。
そういうことをやってるうちに、いろいろなものに静的解析機をかけるなってことを思い始めて、Lintオタクになってったっていうのかな。っていうのがLintオタクになってた理由ですね。
なんでLint読んでたのって話はどうしようかな。またもうちょっと後で話そうと思います。
ありがとうございます。Lintオタクというか、世界中にあるLintを全部読みし、Lint博士みたいな感じですかね。
それのちょっと、興味もあって、前職でLintNightっていう、DNAの時にLintNightっていうのを開催していて、今も多分第4回か第5回ぐらいが、
4月だからもう今月ですね、とかにやると思うんですけど、それの主催とかもやっていました。結構日本人にLintの作者っていうのが多くてですね、
なかなか豪華なメンバーを集めて、俺のLintはここがすごいみたいな話ができるので、とっても楽しい回です。ぜひ皆さん興味があったら聞いてみてください。
ありがとうございます。Lintの作者が結構日本人の方が多いんですね。そもそも。
多いですね。
そこを知らなかったです。
ありがとうございます。そういった背景がある中で、LintツールをいろいろLintマスターである国明さんが見ていく中で、
次のターゲットとしてVimスクリプトを選んだきっかけみたいなのってあったりするんですか?
そうですね。私がVimスクリプトにLintを作ろうと思った理由は大まかに分けて2つあって、1つは私自身が書くVimスクリプトがひどいっていう自覚があったんですね。
皆さんも実際プロダクションのコードとかを書いている時に、ここちょっと書き方わかんないけどひどいけどこうしようかなとかっていうのを書いて、
残しちゃうことあるじゃないですか。あの時のこういう罪悪感みたいなのが私はあんま好きじゃなくて、それがまず開発の一つのモチベーションになっているっていうのがあります。
あともう1つは私はLintを作れる知識があったっていうのも結構大きくて、他のLintのコードとか読んでたし、
じゃあこれ自分で作ってこの何とも言えないダメなコードを書いてしまった時のこの嫌な感じっていうのをケアできるんじゃないかなっていうのが最初の開発の動機ですね。
なるほど、じゃあ自分が書いてるやつが許せなかったから、それを正すためのツールを作りたかったっていうところが。
そうですね。
ありがとうございます。
vint開発の始まり：Python選択の理由と初期開発
じゃあそんな中でVintを作り始めることになったわけなんですけど、一番最初作っていく中で、ちょっとあのVintについての歴史を調べさせてもらったんですけど、
2014年の7月から開発の方スタートしたかなと思うんですけど、Vintは作成されている言語がPythonなんですよね。最初にPythonを選んだ理由とかってあったりしますか。
まず当初の私の構想として、こういう風な静的解析ツールっていうのはコミュニティによってメンテされるべきだという信念がありました。
なので私が得意な言語ではなく、みんなが書ける言語を選びたいっていうのがあって、あとちょっとこの後少し公文解析機の話をしていくんですけど、それで選べる選択肢がJavaScriptとかVimScriptとかPythonかの3択だったんですね。
当時一番開発者の数が多いっていう風な統計が出ていたのがPythonだったっていうのがあって、Pythonを選びました。
じゃあ自分が得意な言語ではなく、Pythonを選んでコミュニティで開発をできるようにするという目論みが最初からあったという。
そうですね。
ちなみにくにあげさんが一番得意な言語、その時何だったんですか。
その時はJavaScriptでした。
じゃあJavaScript、JavaScriptかPythonかを選択迷ってたんでしたっけ。
そうですね。VimScript自身でVimScriptの静的解析を書こうとあんまり思っていなかったですね。
ありがとうございます。
じゃあそんな中でPythonでの開発始まることになるかなと思うんですけど、一番最初の大きなリリースの転換点としてはVimConf2014で発表されている資料、
転ばぬ先の杖、Vimと発表されているかなと思うんですけど、そこに向けて怒涛の開発半年ぐらいですかね、7月から11月にかけてされているかなと思うんです。
ここら辺なんかエピソードあったりしますかね、怒涛の開発に関して。
そうですね。確か一番最初の1ヶ月はJavaScript使うかPython使うかまだ決めかねていた時期が確かあって、最初JavaScriptで1ヶ月ぐらい勝ち始めてたんじゃないかなと思います。
なんですけどやっぱり途中でPythonの方が人口が多いってことがその時分かったのかなとかでPythonに切り替えて、なのでVimとの一番最初のコミットメッセージ読むとPythonizeって書いてあるんですよ。
元はPythonじゃなかったってことを記させるコミットメッセージになっていて、確かそういうふうな形だったと思っています。
その後主に開発していったのがLintツールの基本機能なんですね。
Lintツールっていうのは主要パートがいくつか3つぐらいの部品があります。
1つは設定ファイルを読み込む部分。例えば皆さんLintツール使う時にこのスタイルのやつとかは別に警告しなくていいよとかっていうふうに設定ファイルを書くことは皆さん普通だと思います。
この設定ファイルっていうのは個人レベルのものもあればプロジェクトレベルのものもあります。
こういうふうにいくつか設定ファイルっていうのを階層的に読み込んで、どれを優先して使うかとかっていう風に優先順序を決めるルールがあります。
これが大まかに言うと設定ファイルの部分ですね。設定ファイルの部分以外は例えば公文解析っていうのをして、
コードを読みやすいような機構像のデータにしてあげるっていうのがあって、その機構像のデータをなめていきながら、
深さ優先探索とかをしていきながらだんだんと問題とかを見つけていくっていうパート、検査パートですね。
っていうのが2つ目。3つ目がその検査パートっていうのは実は細かいルールに分かれてるんですね。
例えば皆さんに分かりやすい例で言うと、まつびかんまがあると起こるみたいな感じのルールを作るとするじゃないですか。
そうするとまつびかんまルールっていうファイルを検査ルールを作りたくなるんですね。
これとまた別に例えばifの後に改良がないといけないみたいな感じのルールを作るとするじゃないですか。
そうした時にこのさっきのルールとifの改良ルールがくっついちゃうと非常に読みにくいっていうのがあって、
なので実はリントの世界っていうのは検査ルール分離型っていうのが20何年頃かな、
10年とかそのぐらいの頃から結構流行り始めて主流になっていったっていうふうな歴史があります。
それに則った小さなリントの実際の検査ルール群っていうこの3つのパートに分かれて実装していきました。
今回その一番最初にやっぱり一番注力していたのは設定ファイルの部分とその基礎の部分、
その構文解析をして実際にその構文義を舐めていくっていう部分、この2つに一番注力していたのは間違いないです。
ありがとうございます。さっきおっしゃっていただいたその3つ目のやつですかね、分離して設計をしていくっていうイベント。
統合型 vs 分離型アーキテクチャ
イベントではですね、リントのルールごとに分離して設定していくっていうような分離型にあたるんですかね、それがリントツールのアーキテクチャとして。
はい、その通りです。リント型になっておりますね。
もう一方が統合型と呼ばれるものですかね。こちらに関してはちょっと簡単に説明してもらってもいいですかね、統合型がどういったアーキテクチャなのか。
はい、まず統合型っていうのは構文解析をした後にソースコードを構文解析すると機構像のデータが出てくると先ほど言いましたね。
この機構像のデータを不可生優先探索とかで順々に訪れていくんですけど、訪れていくときに例えばif文に関するルールだったら今ifっていう木にいます。
っていうことが分かって、そっからifっていう木に行って、次に例えば条件式の部分を訪れて、次に前の部分を訪れて、次にエルスの部分を訪れてみたいにこんなふうな感じでだんだん優先探索していくんですね。
このときに例えばifに関するルールが2つあれば、このifにちょうど訪れちゃってるから2つ見ちゃおうっていうコードを書くことができるじゃないですか。
これが統合型の思想になっていて、ちょうど処理順が近いから、同じここで変数とかに今ここの状態にあるみたいなことを格納していって、
同じタイミングのものを同じような場所に置くっていう形でやっていくのが統合型のやつです。
歴史的に見るとその統合型のやつっていうのはJSLintとかJSHintとか、確かFlakeとかFiflexどっちかは統合型になっていて、結構読みづらい。
超巨大ファイルが1つあるみたいな、そんな感じのコードになっていますね。
その読みづらいっていうのはソースコード、Lintツールのソースコードが読みづらいというような。
そういうことですね。
どういう実装になっているのかの把握がしづらいっていうのが統合型で、分離型はそもそもファイルが分かれているのでルールの確認がしやすいという意味での分かりやすさ。
その通りですね。
なるほど。で、Lintは分離型を選択したと。
ちなみに統合型の用語を押しておくと、統合型の方がパフォーマンスはいいですね。
なんですけど、ほぼ誤差っていうところもちょっとあって、どうしてもカリカリにチューニングしてものすごい短くしなきゃいけないという場合は、おそらく統合型にするしかないはずです。
そこは一応用語を押しておきます。
なんとなく今話聞いている中で疑問に思ったのが、統合型だとバグみたいなものが発生しがちなんじゃないのかなっていうのをなんとなく思ったんですよ。
関心の分離じゃないですけど、やっぱしなんとなくのイメージでルールはそれごとに分離されていて、適用されるっていう形の方が単純にバグ埋め込まれづらいよなと思ってて、
統合型の場合はソースコードが見づらいというところもありつつ、全てが一体になっているので、単純にどこかぶっ壊れたら簡単に壊れそうだなという印象があるんですけど、そこら辺の差はどうなんですか。
めちゃくちゃ鋭い質問で、実際にそれがJSヒント、JSリントの衰退の原因になったと私は考えています。
JSリント、JSヒントは当時、JavaScriptのデファクトのリントだったんですね。みんなそれ使ってたんですよ。JQueryとかの時代だったと思います。
その時代にあったもう一つ歴史的なイベントがあって、JavaScriptの構文がどんどん変わっていったんですよ。
エクマスクリプトの6、今だともう2000いくつとかになってますけど、エクマスクリプトが出始めた頃になっていて、JavaScriptの構文が一回ガラッと変わったんですね。
そうすると、この一体型は非常に地獄みたいな感じになっていて、訪れる順番とかが変わっちゃったんですよ。
例えばifの前に実はちょっとだけこういうものが入るかもしれないというのが増えてしまった。
そうなってしまったがゆえに、恐らくコードをメンテできなくなくついていく速度が十分取れなかったという歴史があると思っていて、
それで他の高速DSリントとかそういうふうなものたちっていうのの対等を許してしまったところが結構あると思っていて、それがやっぱり統合型の弱さだと思いますね。
読みにくいし、バグを埋め込みやすいから開発スピードが上がらなかったと。
なので、他のより早い新しいものっていうのの対等を許してしまったというふうな歴史があると思っています。
なるほど。じゃあ、開発速度とあとはコミュニティのサポートっていうのも減らりづらくなっていったという歴史的背景がある中でのJSリントやJSヒントとかの衰退。
で、ESリントの流星みたいなところがあるってところがあるんですね。
ありがとうございます。すごい腑に落ちました。
VimConf2014での発表とコミュニティからの反響
その中でリントを開発していって、分離型で開発していって、ビームコンフ2014で発表することになるかなと思うんですけど。
こちらの発表した際の反響というかどうでしたか。何かあったりしましたか。
反響ですかね。みんな欲しがっていたのはわかっていて。
ただ、ここもちょっと難しいんですけど、ビムスクリプトってとても嫌味の多い言語になっていて、
ここは非常に悩ましいところで、要望が再現なく出てくるんですよ。
ここは危ないからこうしてほしい、ここは危ないからこうしてほしいっていうのが、それを一個一個実装していくのはやっぱりどうしても一人では大変だったっていうのをちょっとよく覚えていますね。
だからコミュニティにやってすごく多分好意的に受け止められたと思うんですけど、
それで要望が噴出して、それを個人でなかなか受け止めきれなくなってきたっていうところは結構ありましたね。
なるほど。じゃあ、好意的に受け取られたがゆえにめちゃくちゃ使われて、いろんなこれもサポートしたい、これもサポートしたいみたいなのがどんどん来てしまったと。
それによって業務量が爆発してしまったということですね。
そうですね。当時AIとかなかったですからね。
今だったらちょっと違いそうですよね。
違うと。
ここに関しては確実に。ありがとうございます。
先行するVimLintとその課題
じゃあ、かなりVintに関してリリース当初はいろんな方に使っていただいてというようなところだったんですね。
ちなみに前身というかVintをリリースする前にVimのLintとかって先行例とかってあったりしたんですか。
はい。いっぱいいくつかあって、VimLintだったかな、VimLintかっていうのがあって、VimスクリプトでPureなVimスクリプトで実装されたLintとかがありました。
これは特に外部的な依存なくVimだけで持ってくれば動くLintツールだったので、これは発想としては非常に良いやつですね。
ほとんどの言語のLintはセルフホストされています。
例えば、PythonのLintっていうのはPythonで書かれているし、JavaScriptのLintはJavaScriptで書かれているし、RubyのLintはRubyで書かれています。
こういうふうにセルフホストするっていうのは普通なんですよね。
その意味ではVimのVimLintっていうのはすごく自然な発想で作られてるんですけど、ただここにちょっと重要な事実があってですね、Vimスクリプトってめちゃくちゃ遅いんですよ。
ただでさ、よく遅い遅い言われるPythonの、それこそ何倍何百倍ぐらい遅いかもしれないっていうぐらい遅いようなものになっているので、なかなか実用的な速度で動いてくれないっていう課題がありました。
なので、やっぱりリッチなものを実装しようとすると、どうしても処理量が増えてしまうっていう、この攻めり合いの中でどうしても機能が少なくなりやすいし、何よりもそれでも遅い。
保存するたびに動かすっていうので、やっぱりどうしても固まってしまうみたいな感じの動きになってしまうので、そこが難しかったんじゃないのかなっていうのは思ってますね。
なるほど。じゃあVimスクリプトで書かれていて、使いやすくはあるんだけども、ちょっと動作上が重くて使いづらいっていう点もあったっていうところなんですね。
そのVim-Vim-Lintの作者であるシンギャンさんですかね。シンギャンさんがVimLintを発表した当初なんかブログを書いてくれてたそうなんですけど、これ覚えてますかね。
いや、あんま覚えてないですね。
ブログでこの方がもうVim-Vim-Lintはメンテしなくてもいい感じなのかなっていうようなコメントとともに、VimとのGitHubのURLと、
あとはコラボの先の2円のVimとのスピーカーデックのURLを紹介しているっていうブログが紹介されていて、かなり評価されているのかなという風に受け取られました。
そうですね。ただ、今だったら少し風向きもちょっと違うかなって気はしていて、Vimスクリプトがやっぱり遅いって問題は開発者にもすごく認知されていて、
今Vimスクリプト9って呼ばれている、Vim9スクリプトが呼ばれているものがあって、これはコンパイルとかもするみたいな感じの、結構野心的な感じのプロジェクトで、
結構早く動くんじゃないかってことは期待されていました。もしそれが実現するんだったら、復活ってことは結構あり得るのかなと思っていて、
今はあくまでVimスクリプトが遅いって時代でVim9スクリプトが人気を博したと思うんですけど、それはもしかしたら覆るかもしれないっていう点で、
結構VimLinuxは是非続けて欲しいなと思っているところですね。
なるほど。理解しました。Vim9スクリプトの前の時代というところなんですね。このVim9スクリプトを作っていた当時は。
じゃあ現在だったらVim9スクリプトの速度で問題解決してしまうかもしれないっていう。
ただVim9スクリプトまだ開発途中だったはずで、どこまでちゃんと動くのかっていうところはかなり怪しいところがあると思いますね。
でもさっきも言った通り、Lintっていうのはやっぱりその言語でセルフホストされている方が一番コミュニティを広く取れるんですよね。
なので本当はLintもVimスクリプトで開発したかったっていうのはあります。
それはVim9スクリプトで叶うといいなって本当に願ってるんですけど、まだ時間がかかりそうだなって私の印象ですね。
ありがとうございます。コミュニティみたいなところの話が出てきたんで、そこを行きたいなと思うんですけど、
メンテナンス委譲の背景と決断
Vintを開発した翌年ですね、2015年の4月に国明さん自身でVintの一周にメンテナーワンテッドっていうような意思を立てるやつかなと思うんですけど、
メンテナンスがちょっと厳しくなってきたから誰かメンテナンスできる人募集しますよみたいな話かなと思うんですけど、ここら辺の背景とかってあったりしますか。
結構皆さんが使ってくれるようになって、先ほども言った通り一周がだんだん結構増えてきたんですよね。一周が増えてくるんだけど、当時AIとかもなくて私一人でそれを全部さばかなきゃいけなくなってきたっていうのがあって、率直に言って時間が足らなかったっていうのがすごく大きかったですね。
で、時間が足らなくて自分の出したものっていうのがせっかくいいものではある、要するに誰かの労力を過ぎ込めばもうちょっといろんな要望を叶えていいものになれるってことがわかってるのに、自分自身の力でそれができないってことがわかってしまったっていうのがあって、
慣れた人だったらもっといろんな人、もっと時間を使える人とかに任せた方が、よりこのプロジェクトっていうのがもっと良くなっていくんじゃないかっていうふうなことを思ってメンテナーワンテッドっていうふうなことを出しましたね。
ぜひこれをコミュニティの共有資産としてもっと良い方向に導いてくれる人がいるんだったら、ぜひお任せしたいと思っていたっていう感じでした。
ありがとうございます。結果的にこのメンテナーっていうのはどうなったんですかね。
この結果的にメンテナーは2人ほどアクティブに開発してくださった方がいて、そのうちの1人の方にお願いをしました。
なのでその時期にリポジトリのオーガナイゼーションをトランスファーしていて、それで今ビムジャスってところにビントがあると思うんですけど、そちらに映ってます。
ブルーアイドさんって読むのかなっていう方がいらして、その方にメンテをお願いしました。
このブルーアイドさんにメンテナーを渡す権限を移情するっていう時に、見られた点とかってあったりします。
単純にOSSのメンテナンスを上げるっていうのは結構心理的もそうですし、セキュリティ面でもなんかあるのかなと、なんとなく思うんですけど。
ちょうど確かその時期にOSSの乗っ取りみたいなものがあったんですよね。
悪い人、アクターが親切なメンテナーをかかわってあげるよみたいなことを装って、マルベアを入れるみたいなことをやっていたことを騒がれていた時期で、
すごく私はオーナーを渡すことには慎重だったことを覚えています。
ただ、相手に無実の証明をさせることってできないんですよね。一定リスクっていうのは追わなきゃいけなかったんだけれども、いくつか選択肢を検討しました。
例えば、作ってるものを一旦アーカイブしてフォーク版を作ってもらって、そのフォーク版のいくつか生き残ったものの後継のどれかが次のビントになるみたいなことも考えたりはしたんですけど、
結局、そうすると今、Pythonのパッケージインデックス、PipeBIにある、ビントっていう一等値の名前っていうのが私に占有されちゃってままになっちゃって、
例えば、ビント2とかビント3とかっていう名前を取るのかどうか分からないですけど、とかっていう風になった時に、利用者の人にとってあんまり良くないよね。
ピップインストール、ほにゃららってやるんだけど、ピップインストールでビントって入れちゃって、私の古いやつがインストールされる体験って非常に良くないよねって思って、
やっぱりこれは丸ごと渡しちゃった方がいいんだという風に思って、リスクを取って、でも利便性をなるべく維持するためにオーナーを渡すって決断をしたことを覚えています。
ただやっぱ新編調査は結構しました。渡す人のどんな人なのかな、ちゃんとアクティブに開発してるかな、変なこと入ってないかな、みたいなことはちゃんときっちりチェックしたことは覚えています。
ブルーアイドさんに関しても渡す際にGitHubだったり、確認できる、オンライン上で確認できることは一応したというところですね。ありがとうございます。
vintの現在と将来性
最近結構ビムにもセキュリティー支援発生したかなとか、あとはちょっと昨日ですかね、秋オスとかに、
悪意あるパッケージがリリースされてしまうとか、そういったことがあるかなと思うんで、もう全然最近でも起き得るOSSの問題、結構かなり根深い問題かなと思いますね、そこに関しては。
ありがとうございます。ちなみにその後、Vimjassに一貫した後の開発みたいなところは、くにゃくにゃさんはもうノータッチみたいな形だったんですかね。
ほぼノータッチですね。一回だけリリースしてよみたいなコメントがずっとついてて、それはさすがにちょっと申し訳ないなと思ったので、一回だけリリースするってことだけはやった記憶がありますね。
じゃあもうそこからはブルーアイドさんたちにお任せしてという形で、どんどんVintが広がっていったというようなところですかね。
今確認するとおそらく約24名の方がコントリビューターとしてVintに参加してくれてるかなと思うんですけど、ちなみに日本のVimのコミュニティであるVimjpですかね、くにゃくにゃさんも参加されてるかなと思うんですけど、Vimjpのところのコミュニティにおられる方々ももちろんこのVintのコントリビュートとかってしてくれてたりするんですかね。
はい、でも結構してくれていて、もしかしたら一番最初のアウトサイドコントリビューターの人はマッツンさんって方がもしかしたらファーストコントリビューターだったかもしれなくて、何だったかな、パイソンか何かのちょっとこうしたらパフォーマンス良くなるよっていう部分だったか、それとも文字化けを防ぐためだったかちょっと覚えてないですけど、一個だけ小さなパッチを投げてくださったのを覚えていますね。
はい、それとかを取り込んでっていう感じでした。
ありがとうございます、もうVim界のレジェンダーの方ですね。
そうですね、Vim界のレジェンダーの方かな。
ありがとうございます。ちなみにその後ですかね、そのVintの現在の立ち位置みたいなところってどんな形になってるんですかね、もうあんまりアクティブに開発されてないかなとは思うんですけど、オーナー権を渡したくにゃくにゃさんではありますけど、その面どう見ますかね。
はい、アクティブじゃないっていうのはおそらくそうだとは思っているんですが、ただじゃあ全く使えなくなったかっていうとそんなことはないんですよ。
Vintって結構私の設計思想がいくつか入っていて、あんまり外部のパッケージ依存がないんですね。
なので脆弱性とかが基本的に出ないんですよ。脆弱性の更新とかが出ないので、今でも実用的に使えるツールではあると思ってます。
単に新しい機能予防とかが通らないだけっていうものだと思っているので、そういうちょっともどかしさはあるんだけど、まだ実用的なツールとしては振る舞えているのかなっていうのが私の印象ですね。
じゃあPythonのアップデートによって言語自体のアップデートでぶっ壊れない限りは動くよねっていう。
その通りだと思います。
ありがとうございます。ちなみにぷにわけさん今Vint、Vimローカルで使われてるかなと思うんですけど、Vint使ってるんですかね。
静的解析の意義と難しさ
それがですね、最近Vimもあんまり使えてないんですよ。
なるほど。
っていうのがあって、最近はもっぱらカーソルとかを使うことが多くて、すごく痒いんですよね、Vimモードがってあるんですけど、すごく痒くて何とかしたいなと思いながら、でも何ともできずっていう感じの生活をしていますね。
罪悪感を覚えています。良くないですね。
じゃあちょっとそこの課題化に対して何かしらの倫となり、何らかのツールもしかしたら作るかもしれないっていう。
そうですね。これは私の持論なんですけど、何か皆さんが開発してる時にクソなコード書いちゃったなみたいな感じのひけ目ってあるじゃないですか。
あれっていうのは色々な意味で良くない。例えば寝る前にあのコードクソだったなとか思ったりとか、3年後ぐらいに私がいなくなった後にこのクソコードみたいなこと言われるのかなみたいな。
ちょっと凹むじゃないですか。その凹むって気持ちは私人生の損だと思うんですよ。なのでそういう気持ちっていうのをなくすためにやっぱりそういう風なクソコードじゃない。
ここは大丈夫なんだ。最低ラインを突破してるんだみたいな自信を持つための何かが欲しい。それが私はやっぱり倫とだと思ってるんですよ。
皆さんが例えばES-Lintとか爆発的に広まって、皆さんがES-LintをRC.jsonとか書いて入れてるのって、みんなそういう気持ちがあったからだと思うんですよね。
なんか少しでもまともなコードにしたい。クソなコード書いてないんだって自信が欲しいと思って、皆さんそれを取り入れていった節が結構あるんじゃないかなと思っています。
そこにやっぱり私は静的解析機とかがすごく役に立つと思っていて、なのでぜひこういう風な不安を感じた時には何かできないかな、静的解析機書いてみようかなみたいに思えるといいんじゃないかなと思っています。
ありがとうございます。ちょっと静的解析機っていうようなワードが出てきたのでちょっとお聞きしたいんですけど、今回Bintで静的解析機を作られたかなと思うんですけど、これ実際作ってみてどうでした?
なんとなくのイメージで、僕のなんとなくのイメージなんですけど、そういう静的解析機すごい作るの難しそうなんですよ。普通のイメージで。どうでしたかね?
はい。静的解析機自体は実はそこまで難しくないというのが私の意見ですね。静的解析機で一番難しい部分っていうのは構文解析っていうのをすることで、ソースコードを機構造のデータに書いてあげた後のこの機構造のデータが何かってことを皆さんあんまり意識してないって部分だと思っています。
だけどコンパイラーを書いたりだとか、あるいは私みたいな静的解析機、Lintを書いたりとかっていうときには、この構文解析機っていうのは避けて通れないんですね。ただこれ一度いろんなウェブサイトでコードを書いたら構文解析の結果を見せてくれるサイトがあります。
JavaScriptとかだったらES3とかっていう感じの名前のサイトだったかなとかっていうところにあるんで、ぜひ貼ってみて、こんな感じのJSONオブジェクトになるんだっていうのを確認すると一瞬でわかります。それがわかってしまえば、もうあとは実装するの全然難しくないんですよ。だから静的解析機の仕組み自体は難しくないっていうのが私の意見ですね。
ただ静的解析する対象の言語は難しいことがあります。例えばPerlとかBIMスクリプトとかのLintを書く人は相当苦労すると思いますね。それは解析対象の言語がとにかく難しいというところがあります。
難しいという、ちょっと解説を上げたいなと思うんですけど、自由すぎるっていうところがありますか、言語が。
その通りです。例えばPerlか何かだと構文解析機、さっき言ったソースコードからこういうふうな構文儀っていう、記号のデータになるよっていうようなことをやる構文解析機っていうのの性能を歌うのが、99%のPerlのCPANっていうPerlのパッケージレジストリがあるんですけど、そこに入っているものを解析できますよって歌い文句なんですよ。
つまりもう構文解析自体がとってもとっても難しくて、これもう分かんないですみたいな状態になりがちだっていうのがあるんですね。特にRubyとかPerlとか結構スクリプト言語、インタープリターの言語たちっていうのは、実行時の情報を使って構文儀とかの解釈をすることができるんですね。
例えばある変数名があったときだけこれはこういう意味なんだが、変数がないときは別の意味になるとかっていうときに構文解析しようと思うと、これってどっちなのっていうのが分からないんですよ、性的なので。変数があるかどうかが分からないんですよね。なのでそういうものたちの構文解析は、構文解析っていうか性的解析は結構しばしばつらいんですね。
なるほど。ちなみに今お話しいただいたプログラミング言語だったりVimスクリプトだったり、いろんな言語かなと思うんですけど、そういう性的解析機器をプログラミング言語以外にも適用できたりとかってするんですかね。今思いつきでしゃべってるんですけど。
静的解析の応用：文書や自然言語への適用
はい、その通りです。実際私の最近の成り合いは、使用書に対してリントを入れるとか、要求文書に対してリントを入れるみたいなことをやろうとしています。結局性的解析っていうのは、成果物をインプットとして問題を吐くっていうタイプのものでしかないんですよね。これってすごく一般的なパターンで、何らかの問題を検出するものって全部そうなんですよ。
ただ、例えばソフトウェアみたいに一部動作するっていうふうなことを選択肢がある場合だけ動的なテスト、例えばユニットテストとかインテグレーションテストみたいな選択肢があって、そっちが主流になっているんですけど、でもそういう実行するってことはできないようなもの、例えば典型的には要求文書とかですね。
要求文書とか、使用に関しては一部実行できるものとかもあったりするんですけど、そういうものとかに関しては性的に検査せざるを得ない。そういうふうなツールがあるとやっぱり便利だよねっていうので、日々そういうあたりとかをこういうふうにできないかなってことをやってますね。
自然言語に対してリントツール的なものを適用するというアプローチでやっていて、その適用先として使用文書、要求文書、要件定義的な文書っていうのを今試行錯誤中というところなんですね。
それがですね、実は要求とか使用というのは自然言語じゃなくても書けるんですよ。私が今回使用書の言語として選んだのはプラントUMLのシーケンス図の基本です。今回使用をシーケンス図として選んでいるので、レンダリングすることができるんですね。
実はレンダリングできるってことはコンパイラーがあるってことなので、元になっているプラントUMLのコードを画像にコンパイルするってことをやってるわけなので、そのコンパイラーがあるわけですよ。コンパイラーがあるってことは公文解析機があるんですね。なので公文解析機があればあとは簡単だっていうのは結構あって、その性的解析機を作ろうかなっていうのは今やっているところですね。
要求の文章も似たような感じでシーケンスで書いたりもするし、いろんな書き方があるんですが、そういうことが結構スコープに入っているというような感じですね。
ありがとうございます。
はい。
どうぞどうぞ。
1点だけ付け加えると、自然言語で書くこともあると思います。自然言語で書いた場合、最近LLMが登場しているので、LLMでこういうものはダメだよみたいなルールをこうやってあげれば、多少ちょっと甘いときはあるかもしれませんが、ある程度は性的解析ができるものだとは思います。
ありがとうございます。ちょっとここに関してはもうすごい深掘って聞きたいんですけど、時間があまりにもないと思うので、次回以降どこかで聞けたらなと思います。
言語理解の近道としてのLint自作
次回予告につなげつつって感じですね。
ありがとうございます。
ありがとうございます。
じゃあそんな形でちょっと今回ですね、リントのお話をしつつ、ちょっとリントというツールについてお話かなりできたかなと思うんですけど、ちょっと何か最後にですね、ひとこと国明さんのメッセージとかあったりしますでしょう。
そうですね。私がよく言っているのは、何か言語とかものを理解したいっていうときに、一番の近道は自分でリントを実装してみることですよってよく言っています。
例えば私がビームスクリプトであんまり良いコードを書けなかったって自覚があったときに、ビームスクリプトのことをよく知ろうと思って、ビントとかをある程度開発しようとしたとかっていうように、
何か言語のエキスパートになりたければ、リントを書くってことは非常に良い選択肢だと思っているので、ぜひ皆さんもリントを書いてみてください。
はい、ありがとうございました。では、改めまして国明さんありがとうございました。
ありがとうございました。
番組からのお知らせと次回予告
さて、今回のお話は以上となります。もし少しでも今回のお話がためになったなと思ったら、お聞きのプラットフォームでの高評価とフォローの方お願いします。
また、XなどでハッシュタグOSSの歴史ラジオをつけて感想をつぶやいてもらえると、僕のモチベーションになりますので、ぜひよろしくお願いします。
また機会があれば、今回のような形でゲストをお呼びして、お話をいろいろな方にお聞きできたら面白いかなと考えていますので、
ぜひ自分も出たいという方がいましたら、何らかの形でお声掛けいただけますと嬉しいです。
さて次回はですね、パソコンで音声や画面を録画するときに絶対にお世話になるであろうOBSスタジオの歴史について見ていけたらなと思います。
それではまた次回お会いしましょう。バイバイ。