kmizuの日記

プログラミングや形式言語に関係のあることを書いたり書かなかったり。

ちょっと行列作りますね言語Matlikeを作りました

注:この記事は、2020年1月にQiitaに投稿した自作言語Matlikeについての記事のリメイクです。アカウントを消して元の記事が全部消えたので、移植ではなくリメイクです。

はじめに

 私は、2019年12月から、1か月1言語計画というのを始めています。要はどんなダメダメぽい石ころみたいなアイデアみたいでも、中には原石もあるかもしれないということで、思い浮かんだアイデアをどんどん言語として実装していこうというものです。悲しいことに、2020年2月分、3月分が出来ていないままですが、その辺は今週にえいやっとなんかテキトーなものを作るつもりです。この記事は、2019年12月分の言語として作成したMatlike言語の紹介です。

Matlikeを作った動機

 Matlikeのキーワードは「行列」です。皆さんが普段から使ってるJavaやらPythonやらJavaScriptやら、大半の言語には何らかの形で行列を扱うライブラリがついています。行列計算を必要とする分野とは案外多いものなので、シェアの多い言語は自然とそういうライブラリを備えるようになるのでしょう。そこからさらに一歩進んで、行列を扱う言語機能を持った言語もあります。たとえばMatlabやそのOSS実装(ぽいもの)であるGNU Octaveとか、あるいはJuliaもそういう言語に含めてもいいかもしれません。

 さて、既存の大抵のプログラミング言語では行列を扱えるわけですが、既存の言語の行列の扱いには少し不満がありました。

  • 誤った行列同士の演算を静的に検出できない

 たとえば、行列積としては、

[1 2 3]  *  [4
                 5
                 6]

 というのはOKでも、

[1 2 3] * [4 5 6]

 というのは未定義なのではじいて欲しいのですが、こういうのを静的に検出できる言語が案外ないのです。実のところ、研究レベルではそういう話はままあるでしょうし、C++のテンプレートを使って依存型モドキを使えばそういう機能を実現できるでしょう。しかし、フルスペックの依存型を使うのはいかにも大げさです。なんかいい感じに行列のを型パラメタとして持つちょうどいい感じの言語が作れないかな、というのが一つです。

 皆さん、数学で習う行列って

[1 2 3
 4 5 6]

 て書きますよね(?)いや、もっと専門の分野では違うのかもしれませんが、まあ少なくとも行列を書き下したいときは、こんな風に二次元上に行列の要素を書きたいことは多いはずです。しかし、残念ながら、既存の言語で、こういう感じのレイアウトを良い感じで解釈して(上の例なら 3 * 3 行列として扱って欲しい)くれる言語はあまりありません。Juliaはそのような数少ない言語の一つですが、静的型付き言語ではないので、たとえば、

[1 2 3
 4 5]

 みたいな、型検査の段階ではじいて欲しいリテラルをはじけないのでダメということにします。

 これはやや無理くりなんですが、たとえば、以下のような行列リテラルMatrix<Int, 2, 2> て感じで型がついて欲しいなと私は思うのです。

[1 2
 3 4]

 しかし、そういう都合のいい言語は知る限りでは、ほとんどありません。

 という感じで、多少無理やりですが、理由をこじつけて、以上の要件を満たすプログラミング言語Matlikeを作ってみました。

Matlikeの機能

 というわけで、機能紹介です。

 実は、行列リテラルのパーザをいい感じに書いてみたいというのが一番大きな理由でしたので、これについてはかなり凝っています。

 たとえば、以下のように行列リテラルを書くと、 Matrix<Int, 2, 3> という型が付きます。

 [
 1 2 3
 4 5 6
] // Matrix<Int, 2, 3>

 ちなみに、これを見ればわかる通り、空白が要素間のセパレータになれる上に、改行が行セパレータになれるという仕様です。おかげで結構パーザを作るのに苦労したのですが、後述する型推論との兼ね合いで、たとえば、

val m = [
 1 2 3
 4 5 
]

 のような、行列としてなんかおかしいリテラル型推論の段階で、 2 != 3 みたいなメッセージが出て、はじかれます。

 さて、Matlikeでは行列をファーストクラスとして扱っています。ここでいうファーストクラスとは、行列を引数として渡したり、返したり、無名の行列が作れる程度の意味です。それに加えて、Matlikeの行列を表すMatrixMatrix<E, Row, Col>という形を取ります。RowColが整数であるというのがポイントで、そのおかげで依存型モドキぽいものが実現できています。

 たとえば、Matlikeで行列同士の積を表す演算子_*_ ですが、これを使って、以下のような関数を定義することができます。

def mult(x, y) = x _*_ y

 文法がなんだかScala風味ですが気にしないでください。このmult関数の型は以下のように推論されます。

def mult<A, B, C, D>(x: Matrix<A, B, C>, y: Matrix<A, C, D>): Matrix<A, B, D> = x _*_ y

 ここで、xyの内、要素型がAで一致していて、xの列数とyの行数も一致しているのがポイントです。Matlikeの型推論器はHindley-Milner型推論をテキトーに拡張したものなのえで、型注釈が一切なくても、こんな感じでいい感じで型を推論してくれます。型推論万歳(いや、現実問題、これでいいのかは微妙ですが)。

  • 誤った行列同士の演算を静的に検査できる

 これは機能というより、そういう型システムを作ったことによる恩恵なわけですが、上の方で例に出た

[1 2 3] * [4 5 6]

 なんて例は、1 != 3 て感じのメッセージが出て、型検査を通りません(現在の実装だと、unificationに失敗しただの何だのといったメッセージが出ますが、それはおいておきます)。

まとめ

 Qiitaに書いた記事の方はもうちょっと色々書いた気がするのですが、こんな感じで行列をなんかうまいこと取り扱えるプログラミング言語を作ってみたのでした。Qiitaの記事にも書いたのですが、これからは、こんな感じで(いや、私のはいい加減ですが)、ドメイン特化型の型システムをがんがん作っていくと色々恩恵が大きいのではないかと思う今日この頃です。

 ではでは。

Scalaを学ぶと何が嬉しいかを考えてみる

まえがき

Scalaを学んで何が嬉しいか」ていうのは、人によって様々な答えがあると思いますが、最近ようやく自分なりの答えが出た気がするので書いてみます。

Scala採用企業で働くのに手っ取り早い

 多くの人の言語を学ぶ動機は、就職や転職に役立つというものだと思います。この点においては、当然、JavaRubyPythonPHPといったメジャーな言語には劣るものの、こと東京であればScalaを採用している会社は少なくなく、むしろScala人材が不足している状況です。もちろん、そういう案件では、ただ、Scala言語でプログラムが書けるだけでは駄目で、JVMについての知識なども必要になりますが、特に都内ならそういう企業に就職するためにScalaを学ぶというのもありかと思います。

 ちなみに、Scala採用企業マップ(これで全部ではないです)をshinharadさんが作成されていますので、参考までに。

www.google.com

 特に、ふつーの人でも知っていそうな企業でいうと

 あたりでしょうか。念のため書いておきますと、これらの企業で全面的にScalaを採用しているとは限らない(一部チームで利用の事例もある)ので、詳細については個別に聞いてみるのが無難だと思いま)。

プログラミング言語に強くなる

 この観点は最近見出したものなのですが、Scalaはアカデミック発(当初は、スイル連邦工科大学ローザンヌ校のMartin Odersky教授の研究室で開発。現在はLightbend社がメインで開発)ということもあってか、日々いろいろな実験がされています。特に、マクロを使ったライブラリが多いのがScala界隈で特徴的なところかと思いますが、マクロというのはとどのつまり、プログラムからプログラムへの変換を行うプログラムなので、Scala界隈で色々触っていると、自然とScalaに限らず「プログラミング言語一般」に思いを馳せるようになる……のではないか、と思っています。Lispを学ぶといいよ論と似ているかもしれません

強力な型システムを使ったプログラミング体験ができる

 私見ですが、現在実用で利用されているプログラミング言語の中では、Scalaの型システムによって実現できる制約はかなり強いので、それを生かした設計も(場合によっては)学ぶことができると思います。特に、DDD界隈で一部Scala推しがあるのは、このあたりなんではと思っていたりします。

DSLを作りやすい

 これは、最近の言語だと多かれ少なかれ意識している点かと思いますが、特にScalaはマクロを利用したDSL的ライブラリが豊富なように思います。そのあたりのテクニックは、他の言語にも輸出可能なものがあるだろうと思うので、どういうDSLがあるのかという観点でScalaを学んでみるのも良いことだと感じます。

Kotlinもすぐ習得できる

 最近は、AndroidアプリではKotlnを使った開発が一般的になって来ましたし、サーバーサイドKotlinの事例もちらほら見かけるようになってきました。KotlinはScalaの文法をかなり継承しているので(キーワードとか除けば、文法はかなり近い)、Scalaを学んでおけばKotlinは割と簡単に学べるというのもある意味メリットかもしれません。

楽しい

 これに関しては個人の主観なのですが、Scalaは、一見した印象と反対に、できるだけ直交した比較的少数の機能を組み合わせることで色々なことが実現できるので、創意工夫の余地はかなりあると思います。そのことが、書き方が分裂して、コードの品質を統一しづらいという意見につながるのかもしれませんが、ともあれ試してみて損はないと思います。

 というわけで、主観ばりばりですが、いくつか思いつく点を書いてみました。いくつかの点については、Haskellを学ぶのでもいいという話はありそうですが、特にJavaな人にとってはHaskellよりハードル低いんではないかなあと思っています。

Twitterのkmizuアカウントが(たぶん)誤爆でサスペンドされたので、kmizu_v2アカウント作りました

 今日の深夜に、「自分はもうちょい(Twitterと)距離置いた方がいいのかな」(精神衛生的な意味で)という感じのツイートを kmizuアカウントで行ったのですが、その直後から他の人のツイートをLikeとかできなくなりまして、Twitterルールを犯しているうんたらかんたらというメッセージが出るようになりました。「これがアカウント凍結ってやつかー」と思いつつ、Twitter社の方には、「多分誤爆なので、解除してくれ」的なメッセージを送っときました。で、それは良いのですが、なんか凍結されているということで心配している知人/友人の方がいるようなので、

twitter.com

を新しく作っときました。Twitter社がいつ対応してくれるかわからないし、誤爆ではなくて、どなたかの通報による可能性も否定しきれない(前後関係からはなさそうと思ってますが)ので、当面はこっちのアカウントで運用しようと思います。

 しかし、connpassとかのイベント周知に kmizu アカウントを思いっきり活用してたので、直近では型システム祭りオンラインの告知とかで不便になりそうなことだけが、めんどくさいです。Twitterアカウントに依存することのリスクを改めて考えるきっかけになったのでした。

Scalaを手っ取り早く学ぶのに適したリソースを紹介する(2020年版)

はじめに

 こんにちは。水島です。例のQiita炎上の件で、「ああ、これはもう自分向きのサービスじゃないな」と思ってサックリとアカウント消して退会したわけですが、ちょっとこれくらいはレスキューしておけば良かったな…と思った記事があったので、リライトしてみました。

 昨今、Scalaは色々なところで使われている一方で、特に日本語でScalaを学習したい人には、どこから手をつけていいやらさっぱり、という状況があります。特に、古い書籍だと現状のScalaのエコシステムを反映していませんし、Webサイトでも、古い情報のままということがあります。というわけで、今、日本語でScalaを学習したい人にとって適切なリソースをご紹介したいと思います。

オンライン講座

N予備校 プログラミングコース Scala基礎

www.nnn.ed.nico

 オンライン学習サイトの一つである、N予備校にはプログラミングコースというのがあって、その中でScala基礎という講座があります。実は、制作の初期段階で私がちょびっと関わっていたのですが、それはおいといても、Scalaを学ぶためのサイトとしては非常に品質が高いです。良いところを挙げると

  • Scalaのバージョンアップにキャッチアップしている
  • Scalaの基礎的な部分を丁寧に説明している
  • ある程度実践的なWebアプリ(ニコ動ぽいもの)を作る演習がある
  • 演習問題の解答をGitHub経由で提出して、講師がコメントをくれるシステムがある
    • これは、今もあるかは未確認

 といったところでしょうか。N予備校は月額1000円のサービスですが、今は無料で公開されているので、Scalaの実践的な知識を身に付けたい人にお勧めです。

書籍

実践Scala入門

実践Scala入門

実践Scala入門

 私を含む、5名による共著のScala書籍です。この本のコンセプトは、「コンパクトなコップ本」というものでして、コップ本の重厚長大さを軽減しつつ、実践に必要な知識を身に付けられるようになっています。

  • Scala 2.12対応(現状、主に現場で使われているバージョン)
  • Scalaを使う上で必須なsbtの解説がある
  • 同様に必須な、コレクションフレームワークの解説がある
  • テスティングフレームワークの解説がある

 といった点で、お勧めできます。なお、Scala作者のMartin Odersky教授らが執筆した、Programming in Scalaの邦訳である

Scalaスケーラブルプログラミング第3版

Scalaスケーラブルプログラミング第3版

 (いわゆるコップ本)は、その重厚長大さもあって、初学者には勧めづらいなと思うに至りました。ただ、言語仕様書以外でScalaについて網羅的に解説している書籍はこれがほぼ唯一のものですし、Scalaの設計思想についても語られているので、リファレンスとして持っておいて損はありません。

Scalaをはじめよう! ─マルチパラダイム言語への招待─ (技術の泉シリーズ(NextPublishing)

 インプレスR&Dから出版されたScala本です。

  • Kindle Unlimitedに入っていれば無料で読める
  • お値段も安い
  • コンパクト
  • Scala 2.12対応
  • Scalaの基本構文だけでなく、周辺のエコシステムにもある程度追従している

 といった特徴があります。特に、お値段やコンパクトさ(実践Scala入門と比べても)という点から、お手軽にScalaを始めたい方にお勧めできます。

ゼロから学ぶScala

ゼロから学ぶScala

ゼロから学ぶScala

 この本は、主にScala言語自体の習得に重きが置かれていますが、演習問題などがちゃんとあることや、内容についても誤りは少ないことから、とりあえずScalaの概観をつかむのには適しています。ただし、情報についてはやや古い部分も見受けられるので、その点については注意してください。また、この書籍ではsbtなどのエコシステムについての記述はほとんどないので、あくまでScala言語を学ぶためのものだと割り切るのが良いです。

Webページ

Scala研修テキスト

scala-text.github.io

 私が前職の時に、当時の同僚とともに書き上げた、新卒向けScala研修テキストです。

blog.scalamatsuri.org

 という経緯があって、今はJapan Scala Association(JSA)に寄贈されています。現在は、xuwei-kさんが主にメンテナンスをしており、特に、xuwei-kさんの尽力によって、最新バージョンへの追従などが継続して行われています。このテキストは、実際にドワンゴ社でのScala研修に使われたものであり、正確さにも最大限注意を払っているので、広くお勧めできます。ただし、現状はJava言語の利用経験がある人向けの説明になっているので、その点は注意が必要です(今後、Java言語の経験を前提としない、より初学者向けのテキスト改良を考えています)。

 CC BY-NC-SA 3.0で公開されていますが、企業内での研修用途では自由に利用可能という例外条項が入っていますので、企業の研修でも自由にご利用いただくことができます。なお、営利目的で利用する場合も、JSA側で個別に許諾を与えることは可能ですので、研修以外の営利目的で利用されたい場合はご相談いただければと思います。

 このテキストは、実際にScalaを使った開発をしている企業様複数に利用されていますから、どしどし利用していって、改良のためのフィードバックをいただければと思います。

Scalaメモ(Hishidama's Scala Memo)

www.ne.jp

 ひしだまさんによる、Scalaメモです。メモとはいうものの、インストールの仕方から、サンプルコード、ひしだまさんが使う上でハマった落とし穴など、実際の経験に基づいて書かれています。特に、Scalaの落とし穴にはまった人が参照するとよいのではないかと思います。ただし、更新された年月が全般的に古いので(Scala 2.10~Scala 2.11くらいのものが多い?)、その点は注意が必要です。 

その他

 その他にも、色々なScala書籍が出ているのですが、全般的に出版された年代が古いことが多く(特に、Scala 2.9以前やScala 2.10時代に書かれたものが多い)、2020年現在、お勧めできるものがあまりありません。ただ、その中でも読んでおくと面白いかもしれない本をいくつか挙げておきます。

Scala関数型デザイン&プログラミング―Scalazコントリビューターによる関数型徹底ガイド

Scalazのコントリビュータ(当時)の人たちによって書かれた、Scala徹底して関数型プログラミングを行うための本です。注意して欲しいのは、この書籍で解説されている技法は、Scalaの現場では一般的ではないので、あくまで、純粋関数型プログラミングに近いやり方をScalaで学ぶための本だと割り切ってください(重要)。

Akka実践バイブル アクターモデルによる並行・分散システムの実現

 Scala界隈で非常に一般的につかわれている、並列・分散ミドルウェアであるAkkaの解説書です。ScalaのWebアプリケーションフレームワークであるPlayでもAkkaが内部的につかわれており、Akkaを活用するためにはこの本を読んでおいて損はありません。

Scalaパズル 36の罠から学ぶベストプラクティス

Java界隈で有名な(?) Java Puzzleに影響を受けたと思われる本です。Scalaの落とし穴や罠など、言語仕様について探求してみたい人には面白いかもしれません(あくまで読み物として楽しむくらいが良いです)

というわけで、Scalaを学ぶのに良い書籍やサイトを紹介してみました。Qiitaで書いたときにもちょろっと言及した、竹添直樹さんによる『Scala逆引きレシピ』は良書なのですが、出版年代が古く、sbtやScalaのバージョンが上がって、Scalaのエコシステムが色々変わった現在はそのまま使えない点があるのでお勧めしづらい感じです。

 リライトするときに抜け落ちてしまった情報があるかもしれないのですが、だいたい復元できただろう、と思います。

コード履歴書とかいうものを書いてみた

巷ではやっているらしい。想い出話を含めて書き起こしておくと、後の自分の役に立つかもと思ったので、書いてみる。

この他に、大学1年からプログラムを書くバイトをしてたので、C++で書かれたCORBA処理系をいじくったり、Ethernet層に相当する何かの実装をしたり、カーネルをいじったりとか、低レベル方面のプログラムも書いていた。あとは、Swingを使ったリッチクライアントフレームワークの開発に関わったりも(この言葉はもう死語だけど)。

社会人1年目に至っては、お仕事で主に使っていたのはCだった(Cじゃないと書けない系プログラムのお仕事)。

  1. 高校2年の頃のお話。私は生物部だったのだけど、文化祭の出し物で、3択クイズゲームを作ることになった。当時の同級生がまずDelphiでプロトタイプを作ったのだけど、何故か私がC++ Builderで作りなおすことに。今、このときのコード見たら憤死するんじゃないかというくらいコピペの嵐だった。
  2. 高校3年の頃、なんとなくJava Appletの勉強がてらテトリスぽいものを作った。ロジックは難しくないものの、当時はどうアニメーションさせるかで苦闘してた記憶がある。
  3. 同じく高校3年の頃、なんとなくJava Appletの勉強がてらぷよぷよもどきを作った。何故かはわからないけど、ぷよぷよもどきの判定ロジックを組むことを通じて再帰を体得できた。大学に入学した後に、同期にぷよの顔グラが「不気味」と言われたのを覚えている。
  4. 同じく高校3年の頃、プログラミング言語作りの第一歩として数式解釈して表示するJava Appletを作った。当時は、BNFという概念も、それをコードに落とし込む技術も頭の中になかったので、どうすればいいのか頭を悩ませた記憶がある。
  5. 大学2年の頃、JavaCCを使って、おもちゃ言語をいくつか作った記憶がある。授業でtinycの処理系を作るというのがあったのだが、あえてyaccではなくJavaCCで、しかも、Javaで書いてたりした。
  6. 大学3年の頃、プログラミング言語Onionを作成。クラスベースで静的型ありと、今残っているOnionの原型はだいたいあった。それに加えて、暗黙の変数宣言、クラス委譲とかのちょっぴり独自な要素を盛り込んだ。ちなみに、情報特別演習という、プチ卒論みたいな授業の一環。この時はバイトコード生成系を作る能力がなかったので、Javaへのトランスレータとして実装。
  7. 大学4年の頃、プログラミング言語Onionをバイトコード生成系としてリライト。生成したコードをバイトコードベリファイアががんがんはじくので、オペランドスタックとか、オペランドスタック上の型をベリファイアがどう認識してるかとかの、JVM層の知識が一気についた。同じく情報特別演習の一環で作成。
  8. M1-M2の頃は、何か作った気がしているのだけど、あまり印象に残っていない。
  9. D1-D3の頃は、Scalaで遊びまくって、色々なプログラムを実験的に食わせて挙動を観察したりjavapしたりしていた。
  10. D3の頃、pegexをネタで作ってみた。ついでに、talkが何故かScala Days 2010を通ったので、スイスに行くことに。アイスランドの凄い長い名前の火山が噴火したり、それで日本に帰れなくなったり色々。
  11. 社会人1年目、Scalaに関する書籍を書いたりとか色々していた。ネタ言語toysを作ったりしていた。
  12. 社会人2年目、なんか色々書いた気がするのだけど、あまり記憶にない。
  13. 社会人3年目、Scala Conference in Japan 2013を立ち上げたりとかしてた。この年で印象に残ってるのは、ISO Rubyの試験実装パーザ(by 中田育男先生)の実装のお手伝いをしたこと。ヒアドキュメントとか配列リテラルとか、Rubyの文法は凄まじいことをこの経験を通して、実感(修士の頃から問題意識はあったのだけど)。これ、リライトして最新版Rubyに対応させてみたいとふと思った。
  14. 社会人4年目、ScalaMatsuri 2014とか色々。PPL 2014で、中田育男先生が、ISO Rubyについての講演をされたのだけど、その中で自分の名前が出たらしい(Twitterで見た記憶が)。
  15. 社会人5年目、Klassicの開発を開始したり、Macro PEGを思いつきで提案してみたりした。Macro PEGは何故か、何名かの知り合いに興味を持ってもらえたようで、実装に落としこむ方法とかセマンティクスについて議論をした。
  16. 社会人6年目、Macro PEGについて第110回プログラミング研究発表会(SWoPP 2016)で発表(査読なし)。パーザコンビネータscombを開発。Kotlin用パーザコンビネータkotbinatorを開発。パーザばっかり。
  17. 社会人7年目、プログラミング言語ハンズオンのために、教育用プログラミング言語nubを設計・実装。今思うと、教育用としては筋が悪かったなと思う部分が多々あり。
  18. 社会人8年目、Dartをいじってみたり、色々な言語のパーザコンビネータを書いたり、などなど。
  19. 社会人9年目、やっぱり、やたらパーザを書いていた記憶。GitHubとかTwitter掘り起こせば色々出てきそうだけど。あと、初めてお仕事関係でOCaml使ったのが印象に残っている。
  20. 社会人10年目、今年はプログラミング言語元年、というわけじゃないけど、1か月1言語企画始動。MatlikeContinuerを開発。2月分、3月分がまだ出来てないので、そろそろ手をつけないと。

大学院以降は、思い返せば趣味ではプログラミング言語とかパーザばっかり書いてた気がする。お仕事では結構多種多様なものを作ってきたのだけど、根本的には趣味だとプログラミング言語とかパーザを作りたくなってしまうのが自分の性ぽい。

「素人ですが…」と前置きする質問に関する所感

この話題、定期的に出るのですが、最近もまた盛り上がっていた(?)ようなので、私の実感をまとめておきたいと思ってエントリを書くことにしました。

参考:

私の経歴

という感じです。博士号取得時の査読付き論文は国際会議1本、国内論文誌2本で、自分で言うのもなんですが、「最低限」の条件を満たした程度だと思っています。詳しくは、このあたり

ただ、どこから評価されたのかはわからないのですが、情報処理学会プログラミング研究会(PRO)で編集委員を務めたり(任期4年)、いくつかの国内会議で運営委員に携わったりしています。あと、特定の研究会で座長をお願いされたりとか。今の自分が研究者であるとは自称してはいけないと思っていますが、研究コミュニティについては継続的に関わっている、という感じです。最近、論文書いていて、「復帰」を目指していますが、それはおいといて。

注意

あくまで、私の経験であって、CS界隈でも分野によって流儀が異なると思いますし、その外だとさらに事情は変わるだろう、というのは前置きしておきます。

「素人ですが…」を言いたくなる気持ち

この言葉や、そのバリエーションは、凄い色々な人がよく使っています。で、なんでそういう言葉出るのか、というのを私の専門分野にからめて説明してみます。

まず、私の大学院時代にやっていたことは、Parsing Expression Grammarという形式文法に関する研究です。もうちょっと細かくは、PEGの最適化実装である、Packrat Parsingの話なのですが、Packrat ParsingとPEGってのはぶっちゃけ、メモ化するかしないか程度の違いしかないので、だいたい同じようなものです。

その研究のためには、Parsing Expression Grammarに関して抑えておくことはもちろんのこと、その他の構文解析手法(非自然言語)に関しても抑えておく必要があります。PEGの応用ってのは主に非自然言語構文解析なので、既存の構文解析手法ってのが関連研究になるわけです。

というわけで、専門は、凄い狭義にはPEGだと思っています。ただ、近傍の研究者の方からの認識は、「構文解析屋さん」って感じではなかろうかと思います。

この、「私の専門はここまでで、それ以外はそこまででもない」って自意識が、自分では重要だと思っているし、研究をやってきた人間にある程度共通するものではないかと思います(専門の広さは人に依存するので、もっと専門領域が広い方もいます)。

私は、Twitter界隈では型システムに詳しいとか思われてそうですが、本当に型システムは素人です。口が裂けてもそれが専門ですとか言っちゃいけない。本当に型システム専門の先生に比べれば私の型システムに関する認識なんて雑魚です。ぶっちゃけ。なので、型システムに関する発表があって「なんか違うような気がする」と思っても「その専門分野ではよく知られた話を省略されたのに気づいてないだけなのでは」という疑問はつきまとうわけです。本当に。型システムじゃなくても、プログラム解析でも(さすがにごく初歩的な議論だったら、ある程度はわかると思いますが)、もっと他の話でも。

そういうときに、「素人ですが…」「門外漢なんですが…」って前置きが割と自然に出てきてしまいます。「自信はないんだけど、疑問はある」ってニュアンスを込めたい感じです。もうちょっと違うニュアンスを込める人もいるかと思いますが、「自分が誤ってるかも」みたいな部分を表明しときたいって気持ちがある人は多いと思います。

なので、そういう言葉に対して、「フルボッコにするための呪文」みたいなとらえかたをされるとさすがにちょっと違うだろう、と思います。

もちろん、世界的な研究者だと、めっちゃ細かい分析を即座にできるので、「結果的に」的を射た指摘になってしまう可能性はそこそこありますが、自分みたいな雑魚だと、割と的を射ていない指摘になることもしばしばです。

というわけで、自然と前置きがしたくなる、というのが率直な気持ちです。

前置きなんて要らないのでは?という意見に関する感想

いや、そこで前置きなんてしないで率直に質問すればいいのでは?って意見がありますが、あんまり直接的に批判的な言い方をすると、いきなり大上段から専門でない分野の研究を批判するみたいなニュアンスになりかねない、ということはあると思います。

前置きがいるかはおいといて、「相手を尊重する」という態度を何らかの形で表明しておかないと、凄まじく殺伐とした場になりかねないので、それはあんまりよくないのでは、と感じます。

なんで、こんなねじれが発生したのか

実際、なんでこういうことになったのかはわからないのですが、一つは、「初めての対外発表で、研究の欠点を指摘されて傷つく」という学部4年生の学生の気持ち、というのがあるのかなと思います。

私自身、初めて学部(学類)4年で対外的な研究発表をしたとき、「労力をかけたのはわかるけど、研究としての新規性って何なの?」的ツッコミを大勢の方からもらいましたし、その当日は割と精神的にきつかったです。ただ、実際研究としては未熟(というか、研究の体をなしていなかったと思う)だったので、しゃあないと思います。

私自身は負けん気が強い方なので、「欠点を直してちゃんとやってやる」と奮起する材料になったのですが、そういうので心折れちゃう学生さんってのは少なからずいるのだろうなあと。ただ、心折れた学生さんや傷が癒えなかった学生さんが、後輩に、「あの先生は怖い人だから」みたいな話をして、それが伝承されて…とかいうことがあったのではないかなあ、と憶測しています。

変に勘ぐられないためにどうすればいいのか

言い回しをどうしようが、結局、未熟だったり根本的に変な研究が批判されるのは必然なので、言葉をどうにかすればいいという問題ではないだろうと思います。変てこな研究発表が批判されずにそのまま通っちゃうのは、それこそもっとまずいことなので、どうしようもない。

ただ、指導教員の方が、初めて発表する学生さんに関しては、事前に予稿集や資料をチェックして、根本的な誤りは事前に指摘してあげると、発表会場で結果的にめった切りにされるような事態は避けられてベターかなあと思うことがあります。もちろん、その辺ちゃんとされている教員の方が多いとは思いますが、「この先生の研究室、あんまりちゃんと学生に指導してないのでは?」と思ってしまう事例は時々目撃してしまうので、「ちゃんと学生を指導しない」あるいは(フォローしない)先生が、問題の一因だったりはするのかなと思うところです。

もちろん、大学の先生ってのはだいたい多忙なので、時間の問題とかはありますし、「するべき」とか言えるものではないですけど、心折れる学生さんを減らす方策としてはその辺になるのかなあと。

ただ、この辺は、あくまで「できるとベターかなあ」って話で、個別には「とてもそんな余裕ないよ」って話はあるかもなので、難しいところです。

てな感じで、結論はないのですが、研究界隈に関わる一人の人間として、思うところを書いてみました。

こういう話が色々集積されると有意義な議論になると思うのですが、どうなんでしょうね。

今までの事に関する反省とか色々

 このエントリをあえて書こうと思ったきっかけなんですが、先日の、とあるQiita記事です。この中で、

もちろん全員ではなくいい人もいるが、一部の人がKotlinやGoをディスっていて、かつその人が日本のScalaの第一人者的存在のため 誰も咎めることができず感じ悪い印象を与えることがあった。

と名指しで(訂正されて過去形になっていますが、読んだ時点では、現在形でした)中傷されたことがきっかけでした。というのは、この条件に当てはまる人は日本で私以外存在しないわけなので。

で、何が中傷かというと、日本のScalaの第一人者的存在のため誰も咎めることができずという辺りです。KotlinやGoをディスっていたのは事実なんでいいんですが、自分が偉い人だから誰も注意できなかった、みたいな物言いは端的に事実に反しますし、私を諭してくれた方々にも失礼なことです。

ただ、それは中傷ということで自分の中では決着がついているのですが、それはそれとして、私の発言=Scalaの偉い人の発言、みたいな受け取られ方をして、Scalaコミュニティに悪印象が続いているとしたら良いことではないですし、私自身、その辺を含めて過去の行いを振り返って反省しておきたかったのでした。というのがこの記事をかいたきっかけです。

 また、反省というのもありますが、それとは別に、自分のあんまり人の気持ちを考えない物言いで人を傷つけてきたかなと思うところもあり(別になかったことにしたいわけではないものの)、お詫びの気持ちも含んだ記事です。

 特に、義憤が行き過ぎて人格攻撃になったり、特定の言語コミュニティを揶揄したりしたこともそこそこあり、そういった言動によって、特定言語コミュニティや特定個人に不快な思いをさせたことがあるのは素直に申し訳ないと思っているところです。

 具体的には:

  • Rubyと型に関して、Matzさんの「能力」や「理解」について貶めるような書きぶりをしたこと(この辺は、ぐぐればいくつか出てきます)
  • Scala「コミュニティ」への批判に対して過剰反応して、攻撃的になったこと(これは結構な回数)
  • Go「コミュニティ」の人への揶揄(信者といった表現)
  • Kotlinそのものだけでなく、「製作者サイド」への疑念の表明
    • 故意に、Scalaをクレジットしなかった、みたいな
  • ...

 という感じです。私の信条として、言説は批判しても、人格や能力を攻撃するのは基本的にはご法度というのがあります(最近は、言説そのものを批判しても人は傷つくので、慎重にしようというスタンスです)。で、その辺を守れてなかった事例がいっぱいあるなあというところでしょうか。

 技術的な批判は訂正する必要はないと思いますが、その中に時折含まれていた「人」への攻撃に関しては本当に申し訳ないと思っているところです。

 上記に挙げた話に心当たりがある方は、この記事が謝罪も含んでいるということで読んでいただければと思います。

 今後も、うっかり、そういうことを言ってしまう可能性はありますが、出来る限りないように努めたいと思いますし、そうしてしまった場合は速やかに訂正ないしは削除したいと思います。

 ということで、よろしくお願いします。


2020/02/06追記

そもそも何がきっかけなのか辺りがわかりにくかったようなので、わかりやすいように追記・修正しました。