Kodai Matsumoto

GitHub がリポジトリ毎に言語統計を生成するために使用している、linguist という Ruby 製のツールが言語一覧の生成に使えそうです。 https://github.com/github/linguist gem でコマンドラインツールが提供されています。 実際に僕の環境で動かしてみると、現状の master ブランチではこんな結果になりました。(`--json` オプションを指定して、結果を JSON 文字列で出力させています) ```bash $ github-linguist --json > result.json ``` `result.json` : ```bash {"AppleScript":["RADWIMPS.applescript"],"Shell":["RADWIMPS.bash","RADWIMPS.dash"],"C":["RADWIMPS.c"],"Clojure":["RADWIMPS.clj"],"C++":["RADWIMPS.cpp","RADWIMPS.h"],"Crystal":["RADWIMPS.cr"],"C#":["RADWIMPS.cs"],"D":["RADWIMPS.d"],"Dart":["RADWIMPS.dart"],"Emacs Lisp":["RADWIMPS.el"],"Elixir":["RADWIMPS.exs"],"F#":["RADWIMPS.fs"],"Forth":["RADWIMPS.fth"],"Go":["RADWIMPS.go"],"Groovy":["RADWIMPS.groovy"],"Hack":["RADWIMPS.hack"],"Haskell":["RADWIMPS.hs"],"HTML":["RADWIMPS.html"],"Haxe":["RADWIMPS.hx"],"Java":["RADWIMPS.java"],"Julia":["RADWIMPS.jl"],"JavaScript":["RADWIMPS.js"],"Kotlin":["RADWIMPS.kt"],"Common Lisp":["RADWIMPS.lsp"],"Lua":["RADWIMPS.lua"],"Objective-C":["RADWIMPS.m"],"OCaml":["RADWIMPS.ml"],"Nim":["RADWIMPS.nim"],"PHP":["RADWIMPS.php"],"Perl":["RADWIMPS.pl"],"PowerShell":["RADWIMPS.ps1"],"Python":["RADWIMPS.py"],"Ruby":["RADWIMPS.rb"],"Reason":["RADWIMPS.re"],"Racket":["RADWIMPS.rkt"],"Rust":["RADWIMPS.rs"],"Scala":["RADWIMPS.scala"],"Scheme":["RADWIMPS.scm"],"Swift":["RADWIMPS.swift"],"TeX":["RADWIMPS.tex"],"TypeScript":["RADWIMPS.ts"],"V":["RADWIMPS.v"],"Vim script":["RADWIMPS.vim"]} ``` こんな風に、キーが言語名の文字列で、対応する値がソースファイル名の配列になっているオブジェクトが返ります。...

もうひとつ考えられる方法としては、そもそもソースファイルを言語ごとに異なるサブディレクトリにわけて配置して、それぞれのディレクトリ名が言語名と対応するようにする(今後言語を追加する際にもそのルールに従わせる)、という方法があると思います。 これなら linguist が対応できてないような言語でもスクリプトで柔軟に対処でき、なおかつ (Node.jsでの `package.json`, TypeScript での `tsconfig.json`, Rust での `Cargo.toml` のように) 別途設定ファイル等が必要な言語のプログラムでも管理しやすくなります。 ディレクトリツリーがそのまま言語一覧のような見た目になるので、この方法を採用するなら言語一覧自体生成する必要もないかもしれません。

無理に単一のソースファイルでコミットさせるメリットもあんまりない気がしてきました… 単にソースコードが並んでいるのを見て楽しむために始まったプロジェクトだということは理解していますが、 正直拡張子だけ見たところで何の言語で書かれてるか分かりづらい(いちいち中身のコメントを確認するのも面倒)ですし、 このままだとプログラムを読みたい人も、動かしたい人も、書きたい人も不便を強いられる状態だと思います。 やっぱり言語ごとにディレクトリを作ることだけをルールとして、 あとは個々のディレクトリで良しなに設定ファイル・`.gitignore`・README等を配置してもらうのが、 レビューする側・言語一覧を作成する側に対しても合理的で良いと思います。 ※ 揉め事の原因を作った僕に意見の一貫性がないのは本当に申し訳ないです

I'm also in favor of proceeding with the implementation of the interpreter in TypeScript. I have started to implement it in my repository. By the way, there are many parts...

とりあえずヘッドレス CMS には Contentful を採用してみることにします (無料枠で十分使えて多機能なので)

僕の issue の書き方がマズかったです。まず、Google のコーディングスタイルを盲目的に推しているわけではないです。一旦最初に導入してみるコーディングスタイルの一例として Google C++ Style Guide を挙げてみました。 C++ は表現力が高くいろいろな書き方ができるため、今後他人が Paraphrase にコントリビュートする際にコーディングスタイルが全く明文化されていないと、プルリクエストの承認/拒否の決定が過度に属人化してしまい、ソースコードの管理が煩雑になり、ひいてはバグの温床にもなると思います。僕はそういう状態のことを「品質が悪い」と呼んでいます。 個人的にはとにかく何かしらコーディングスタイルが示されていれば良く、「最初にどのコーディングスタイルを導入するか」はあまり問題ではないと思います。最初使っていたコーディングスタイルに問題があるなら、このプロジェクトではどう修正するのかを明文化しておくと良さそうです。プルリクエストの承認/拒否の基準がきちんと示されていると、投げる側もレビューする側も労力を削減でき、ソースコードの品質を一定以上に保つことに繋がります。Google でなくとも LLVM や Mozilla のコーディングスタイルを最初に導入するのもいいと思います。 本来この issue は「コーディングスタイルを明文化してはどうか」というタイトルにすべきでした。言葉足らずですみません。 具体的にどのコーディングスタイルがどう優れているか、という議論は別の issue で進めたいです。