言語設計と文字列API

Kazuho Oku @kazuho

言語設計論では、基本「書くコスト」と「保守（読む）コスト」の２種類にわけて考えればいいと思ってる / 言語のAPI仕様を最小にするのには正規表現リテラルの導入が有効というのが僕の論 / “プログラミング言語内の正規表現リテラルにつ…” http://t.co/whvioxMAII

MURAOKA Taro @kaoriya

@kazuho だったら正規表現なんて完全に外に出しちゃったほうが「言語のAPI仕様は最小」なのでは? あとその2つのコスト、優先順位を付けるならどっち?もしくはその優先順位が変わる条件でも良いけど。

Kazuho Oku @kazuho

@kaoriya 正規表現を完全に外に出すと、そのぶん文字列処理関数でカバーする必要がある範囲が広がるということです。「言語処理系がどのような目的で、どのような開発者に使われるのか、処理系開発者のバランス感覚によって決まる問題」かと

MURAOKA Taro @kaoriya

@kazuho 文字列操作そのものも言語仕様外で良いのでは。Javaのように文字列に対する操作はシンタックスシュガー扱いで。

MURAOKA Taro @kaoriya

@kazuho あと私の後半の疑問はその「処理系開発者のバランス感覚」が何を元にしているかを知りたい、というところです。

Kazuho Oku @kazuho

.@kaoriya そう、そこの話も面白いんですよね（言語設計者のはしくれとしての自分には）。20年前は、文字列型を言語処理系のコアに入れるべきか、が結構判断の分かれるところだったと思うけど、最近は普通に入るようになりつつあるのかなみたいな。さまざまな要因があると思いますが

Kazuho Oku @kazuho

.@kaoriya 言語がどの程度文字列処理に利用されるのか、正規表現に対して利用者がどの程度習熟しているかand/or拒否感をもっているか、あたりですかねぇ。また、書きやすさを重視するなら両方サポートしてもいいんだし、rubyは実際そういうアプローチなのかなと感じています

MURAOKA Taro @kaoriya

@kazuho え。「元々はコア系に入ってた(メモリ操作だったからw)のにJavaあたりで分離した」のかと思ってた。

MURAOKA Taro @kaoriya

あー文字列、私の認識が間違ってるな。シェルスクリプトとかPerlあたりでコア文法に文字列操作が入ったんだ。で、それを文法と実装とで分離したのがJavaなんだな。

MURAOKA Taro @kaoriya

@kazuho ruby君は書きやすければなんでも有り感w 読みやすさはプログラマのセンスに任せてひどいことになってる…いやプログラマじゃない人が書いてるというのが実情かもですが。

Kazuho Oku @kazuho

.@kaoriya perlが息しないレベルの酷評ですねわかります。言ってることはわかるんですが、そういうのが人それぞれのバランス感覚なんだろうなと。自分の足を撃ち抜く自由は与えつつ適宜自制して使え、みたいなアプローチはある（例えばCもそう）なので、一概に否定すべきとは思いません

Kazuho Oku @kazuho

@kaoriya Unicodeが普及するまでは、そもそも「文字型」が何かから揉めてましたし、C言語のように文字型はあっても文字列型はなかったりとか

MURAOKA Taro @kaoriya

@kazuho 「業務で使う&長く続くビジネスを構築するなら」否定はできますw

Kazuho Oku @kazuho

.@kaoriya そこはコード片の独立性の問題もあって、たとえばウェブプログラミングだと、互いに独立した小さなコントローラを大量に作るので、あまりグループ作業とかないんですよね。縛りを入れるのは多人数で長期間作業する場合ほど重要になりますが、そうでない現場もある

MURAOKA Taro @kaoriya

@kazuho そう思うでしょ。ところが小さなコントローラ同士が密結合してとんでもないことになってる業務Webアプリ(Rails+Backbone)が私の目の前に横たわっているのです。ルータとかほとんど使ってないでやんの。 (´・ω・`)

Kazuho Oku @kazuho

@kaoriya あー心中お察しします (-人-) 自分たちで作って自分たちで使わないものの場合は、品質を強制する仕組みがないと辛いですよね