アカウント名:
パスワード:
プログラミング言語の文法は所詮UIでしょう。UIが実作業において生産性に影響を及ぼすのは間違いないし、UI談義がそれ自身気楽で楽しいことも否定しませんが、現代のプログラミング言語処理系として大事なのはその「UI」を介して表された抽象的なモデル(オブジェクトであれ、論理規則であれ)を高速に実行するための最適化の能力を備えることでしょう。(あるいはそういう最適化に有用なヒントを提供しつつ、かつ記述能力を高めるような抽象化方式の発見。)
(UIが大事な言語ももちろんありましょう。例えばスクリプト言語はしばしば「糊(グルー)」と評されるようにプログラム相互間、人-プログラム間のインターフェースを提供するものなので生産性を高められるようなUIがまさに第一の課題ですが、デカルト言語はソコを目指すものではないようですから。)
例えば論理型系の宣言型言語で構文規則がルール・ベースで記述できるのはむしろ当たり前。それがEBNFだとしてもそこはシンタックス・シュガー以上のものではないように思われます。(それはそれで洒落た仕組みがあれば楽しいものではありますが、そうは言っても…)問題は記述した内容がどの程度効率のよいコードになるかどうかではないかと考えます。
例えばパーザの作成でしばしば利用されるパーザ生成系(yacc, antlr, ...etc.のようなもの)は単にパーザ記述のための宣言型インターフェースを提供することのみが目的ではありません。それらは一々生の構文規則から推論しながら構文解析動作をするのではなく、トークンを読んでテーブルを引いて状態遷移し、さらにそのテーブルのサイズや引き方を最適化するといったような最適化を施したプログラムを生成するところに意味があります。その上、昨今の言語処理系の課題は文法記述によるパーザそのものの作成ではなくその後、例えばコンパイラ/インタプリタであれば最適化、エディタなどの開発ツールであれば構文を理解した支援機能(例えばリファクタリングや補完など)の開発に中心が移っているわけです。
また多くのアルゴリズムは対象の数学的性質を解析したり(例えば多くの決定的な動作をする数学的アルゴリズム)、統計的サンプリング処理をしたり(遺伝的アルゴリズム、シミュレーテッド・アニーリングなど)することで、バックトラックに代表されるような深い探索の試行をいかに避けるかに注意を払うことで高性能化を図っているわけで、そのようなアルゴリズムの記述にはむしろ論理型言語は不向きであるとさえいえます。このような高効率アルゴリズムはリアルでヘビーな問題でまさに求められるものです。
例えば私が昔、「門前の小僧」をしていた数式処理システムが、論理型言語を中心とした第五世代コンピューティングの枠組みからドロップアウトしてC言語で書かれる様になったきっかけは、論理型言語(Prologベースのものだったと聞いています)の備えるバックトラック動作を抑止するために必要な「カット」の記述があまりに頻繁で数式処理のアルゴリズム記述に当たって却って煩雑であったからだと聞きました。
もちろん対象の性質上探索が避けがたい場合もあるのでそれをサポートする枠組みは依然として必要ですが、その場合でもヘビーな処理に求められるのは目先の記述容易性よりはやはり処理性能、あるいはそれを実現する助けとなる最適化性能でしょう。
デカルト言語に関するこのインタビューではそこいらへんの最適化への具体的な取り組み(「高速で高機動な超音速戦闘機が必要」といった抽象的な夢の表明はありましたが)やアイディアがあまり感じられないのが気になりました。
「バックトラックがあかん」としても(これにも異論があるけど、別の話になるのでここでは書きません)、それでいえるのは、だから Prolog はあかんであって、論理型言語はあかんにはなりません。 Prologの性質を論理型言語一般の性質と混同してはいけません。バックトラックしない論理型言語も多数あります。
ロジックプログラミングの理論的基礎である導出原理は非決定性アルゴリズムなので、そのままでは実装できません。そこで、バックトラックを使って代用しているのがPrologです。要するに、非決定性探索ができないから、かわりに深さ優先探索を採用したのです。しかし、深さ優先探索だけが探索アルゴリズムではありません。幅優先探索もあります。Or並列を使えば幅優先探索を非決定性探索の代用として導出を実装することも可能であり、実際、そのような論理型言語も多数存在します。デカルトの作者さんが衝撃を受けたというGHCも、その系統に属します。
ところで、探索では適切な枝刈りが威力を発揮します。Prologで探索の枝刈りを実現しているのがカットですが、どの枝が刈られているのか、いまひとつわかりにくい欠点があります。その問題は、Parlog, Concurrent Prolog, GHC など committed-choice 系論理型言語では解決されています。これらの言語ではガードと呼ばれる機能を使って探索の枝刈りを実現しますが、それは、いったん枝分かれした後でこの枝を残してあとは刈るという形で書けるので、どの枝が刈られるのかをわかり易く書くことができます。
結論としては、Kandoさんの主張を認めるとしても、それからいえるのは「Prologはあかん」であって、それを論理型言語すべてに拡げることはできない、したがって、デカルト言語に適用できるかどうかは不明、ということです。
いつもの大量の随想は読み飛ばしているんだが、これは珍しく単位当たりの内容が充実している。印象値上昇。
>現代(中略)大事(中略)高速に実行するための最適化の能力を備えること
そうですか?RubyやJavaScriptみたいなLispの末裔、つまりUIをいかに整理するかに重点をおいた言語が最近は注目され主流になってるような気がする。むしろ速度はインフラ任せで。
コレにしても、バックトラックつきの「重い」言語が「重い」処理狙いの言語であるとは、もともと思いにくいのですけども…
>スクリプト言語はしばしば「糊(グルー)」と評されるようにプログラム相互間、人-プログラム間のインターフェースを提供するものなので
もともとScript言語をつかまえてグルーという呼び方には引っかかりを
エンド・ユーザ寄りの立場からはUIこそがコンピュータであるので、UIに注目が集まるのは仕方ないし、成熟期に入ったと思われる現代のコンピュータ産業ではインフラ構築に携わる人よりユーザーの方が多くなるのは自然なことでもあるでしょう。ですから人口ベースで言えばUI記述の難易に注目が集まるのは自然ではありましょう。
しかしそうなった今でもインフラは維持・追加、改良や再構築され続ける必要があり、人口ベースで従事している人の割合は減ったとしても基盤技術として重要性は相変わらずあります。
特にこの言語では大規模科学技術計算などインフラ実現寄りの想定ユーザを視野に入れている(とはいえオレオレ言語の実装だの人工無能だのあまり演算能力に重きを置いているとは思えない想定もあるのが解せません。開発者自身ターゲットに迷いがあるのかもしれませんが…。)のでパフォーマンスに関する責任をさらに自身のインフラへ丸投げするのはどうかと思います。(とはいうものの、「最近の高性能大容量PCで、ようやく多少の富豪プログラムでも平気で動く環境が整いました。これなら、いけると思ったのです。」などパフォーマンス面は丸投げする気満々に見える記述もあるのですが…。)
うまい数学的性質がまだ発見されていないため、事実上総当たり(力づく、ブルート・フォース)で探索を行うしか手がない分野というのはあります。そのジャンルの人でないので今の状況はどうだか知らないのですが、10数年前ならばゲノム解読やタンパク質の構造のパターンマッチングかなんかについてPrologでルール記述して総当たりしているという研究紹介を見たことはあります。
そのようなジャンルの改良に遺伝的アルゴリズムやシミュレーテッドアニーリングといったような統計的手法を利用したりする場合や、ヒューリスティックスや適用範囲が部分的な数学的性質しか発見されていない場合で、改良部分以外のプログラムの基本構造がやっぱりルールベースの総当たり探索という事例はありそうです(すぐ例が上がらないのですがゲームで手を探索する場合とかにあるような気がします)。
そういった場合はバックトラック機構を備えた言語処理系は便利でしょうし、規模も小さくないのでそれなりのパフォーマンスが求められることになるでしょう。
もともとScript言語をつかまえてグルーという呼び方には引っかかりを覚えています。それいったらあらゆる言語がプログラム間やマンマシン間を繋ぐグルーですから。繋がないならそれは言語ではない。(というか言語ってもともとInterfaceでしょ)
ここでは機能を利用するための最低限のインターフェース(しばしばテキストベースの)を備えた既存プログラム間をつなぐ。それもしばしば運用の場において、ad-hocでもいいし、多少性能が落ちてもいいから手早くつなぐことを主要な目的とした言語を想定しています。狙いの違い、重視するところの違いによる言語の設計方針の違いを考えたいわけなので、インターフェースするんだからみな同じでしょという立場では一般的すぎると思います。(グルーの語感もボルトや溶接といったより手間がかかるけれど堅固な構造の代わりにボンドでペタリと手軽にというところから取られているように思います。くっつけるんだからなんでも同じでしょとは言えないわけで適材適所が求められます。)
狭い意味で糊という言葉を使うのだとしても、じゃあScript言語で「アプリケーション(のコアロジック)」を書かないのか?といえば、(それこそ速度重視な一部場面を除けば)そんなこたぁ無いわけです今時は。コアロジックじゃなく速度が必要な一部…ドライバ的な…を低級言語に振ることは有りますが。
「アプリケーション」自身が多様ですからね。ゴリゴリ数値計算、カリカリ組み込み機器制御、サクサク伝票処理、etc.ではそれぞれ求められるものが違います。それにあった言語も当然違うでしょう。
Script言語といえども近頃は簡易言語というわけでもないのは確かで、基本的な制御機構やデータ構造は備えており(というかしばしば結構リッチな制御機構やデータ構造を基本構文や基本データ型として備えている)、書くだけなら理論上は大概のものは書けるでしょう。でもそれで十分な性能(実行性能、堅牢性、メンテナンスしやすさ、再利用性、相互運用性などなど)が見合ったコストで達成できるかどうかは別の問題です。
もちろんいずれも程度問題なのですが、
まさにその程度問題を問題にしたいわけなので皆一緒でしょというわけにはいきません。
少なくともインフラのほうは年々高速化してるため、「言語のほうで速度を稼ぐ必要性」は年々減っているのも事実。
冒頭にも書いたように人口ベースで関心を持つ人の割合が減ってるのはおそらくそうなのでしょうが、インフラを作らなくて良くなったわけではありませんし、ここで話題になっている言語は大規模科学技術計算という、どっちかといえばインフラ寄りの要求がある種類のアプリケーションの記述をターゲットの1つに想定していると開発者が言ってますので。
#もしこれが手軽にバックトラックが書けるところに焦点を置いていると書かれていれば#パフォーマンスだ最適化だと大人げない無粋なコメントは私もしなかったと思います。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
大事なのは最適化 (スコア:3, すばらしい洞察)
プログラミング言語の文法は所詮UIでしょう。
UIが実作業において生産性に影響を及ぼすのは間違いないし、UI談義がそれ自身気楽で楽しいことも否定しませんが、現代のプログラミング言語処理系として大事なのはその「UI」を介して表された抽象的なモデル(オブジェクトであれ、論理規則であれ)を高速に実行するための最適化の能力を備えることでしょう。(あるいはそういう最適化に有用なヒントを提供しつつ、かつ記述能力を高めるような抽象化方式の発見。)
(UIが大事な言語ももちろんありましょう。例えばスクリプト言語はしばしば「糊(グルー)」と評されるようにプログラム相互間、人-プログラム間のインターフェースを提供するものなので生産性を高められるようなUIがまさに第一の課題ですが、デカルト言語はソコを目指すものではないようですから。)
例えば論理型系の宣言型言語で構文規則がルール・ベースで記述できるのはむしろ当たり前。それがEBNFだとしてもそこはシンタックス・シュガー以上のものではないように思われます。(それはそれで洒落た仕組みがあれば楽しいものではありますが、そうは言っても…)問題は記述した内容がどの程度効率のよいコードになるかどうかではないかと考えます。
例えばパーザの作成でしばしば利用されるパーザ生成系(yacc, antlr, ...etc.のようなもの)は単にパーザ記述のための宣言型インターフェースを提供することのみが目的ではありません。それらは一々生の構文規則から推論しながら構文解析動作をするのではなく、トークンを読んでテーブルを引いて状態遷移し、さらにそのテーブルのサイズや引き方を最適化するといったような最適化を施したプログラムを生成するところに意味があります。その上、昨今の言語処理系の課題は文法記述によるパーザそのものの作成ではなくその後、例えばコンパイラ/インタプリタであれば最適化、エディタなどの開発ツールであれば構文を理解した支援機能(例えばリファクタリングや補完など)の開発に中心が移っているわけです。
また多くのアルゴリズムは対象の数学的性質を解析したり(例えば多くの決定的な動作をする数学的アルゴリズム)、統計的サンプリング処理をしたり(遺伝的アルゴリズム、シミュレーテッド・アニーリングなど)することで、バックトラックに代表されるような深い探索の試行をいかに避けるかに注意を払うことで高性能化を図っているわけで、そのようなアルゴリズムの記述にはむしろ論理型言語は不向きであるとさえいえます。このような高効率アルゴリズムはリアルでヘビーな問題でまさに求められるものです。
例えば私が昔、「門前の小僧」をしていた数式処理システムが、論理型言語を中心とした第五世代コンピューティングの枠組みからドロップアウトしてC言語で書かれる様になったきっかけは、論理型言語(Prologベースのものだったと聞いています)の備えるバックトラック動作を抑止するために必要な「カット」の記述があまりに頻繁で数式処理のアルゴリズム記述に当たって却って煩雑であったからだと聞きました。
もちろん対象の性質上探索が避けがたい場合もあるのでそれをサポートする枠組みは依然として必要ですが、その場合でもヘビーな処理に求められるのは目先の記述容易性よりはやはり処理性能、あるいはそれを実現する助けとなる最適化性能でしょう。
デカルト言語に関するこのインタビューではそこいらへんの最適化への具体的な取り組み(「高速で高機動な超音速戦闘機が必要」といった抽象的な夢の表明はありましたが)やアイディアがあまり感じられないのが気になりました。
バックトラッキングはロジックプログラミングに本質的でない(Prologには本質的だけど) (スコア:2)
「バックトラックがあかん」としても(これにも異論があるけど、別の話になるのでここでは書きません)、それでいえるのは、だから Prolog はあかんであって、論理型言語はあかんにはなりません。 Prologの性質を論理型言語一般の性質と混同してはいけません。バックトラックしない論理型言語も多数あります。
ロジックプログラミングの理論的基礎である導出原理は非決定性アルゴリズムなので、そのままでは実装できません。そこで、バックトラックを使って代用しているのがPrologです。要するに、非決定性探索ができないから、かわりに深さ優先探索を採用したのです。しかし、深さ優先探索だけが探索アルゴリズムではありません。幅優先探索もあります。Or並列を使えば幅優先探索を非決定性探索の代用として導出を実装することも可能であり、実際、そのような論理型言語も多数存在します。デカルトの作者さんが衝撃を受けたというGHCも、その系統に属します。
ところで、探索では適切な枝刈りが威力を発揮します。Prologで探索の枝刈りを実現しているのがカットですが、どの枝が刈られているのか、いまひとつわかりにくい欠点があります。その問題は、Parlog, Concurrent Prolog, GHC など committed-choice 系論理型言語では解決されています。これらの言語ではガードと呼ばれる機能を使って探索の枝刈りを実現しますが、それは、いったん枝分かれした後でこの枝を残してあとは刈るという形で書けるので、どの枝が刈られるのかをわかり易く書くことができます。
結論としては、Kandoさんの主張を認めるとしても、それからいえるのは「Prologはあかん」であって、それを論理型言語すべてに拡げることはできない、したがって、デカルト言語に適用できるかどうかは不明、ということです。
Re: (スコア:0)
いつもの大量の随想は読み飛ばしているんだが、これは珍しく単位当たりの内容が充実している。印象値上昇。
Re: (スコア:0)
>現代(中略)大事(中略)高速に実行するための最適化の能力を備えること
そうですか?
RubyやJavaScriptみたいなLispの末裔、つまりUIをいかに整理するかに重点をおいた言語が
最近は注目され主流になってるような気がする。
むしろ速度はインフラ任せで。
コレにしても、バックトラックつきの「重い」言語が
「重い」処理狙いの言語であるとは、
もともと思いにくいのですけども…
>スクリプト言語はしばしば「糊(グルー)」と評されるようにプログラム相互間、人-プログラム間のインターフェースを提供するものなので
もともとScript言語をつかまえてグルーという呼び方には引っかかりを
Re:大事なのは最適化 (スコア:1)
>現代(中略)大事(中略)高速に実行するための最適化の能力を備えること
そうですか?
RubyやJavaScriptみたいなLispの末裔、つまりUIをいかに整理するかに重点をおいた言語が
最近は注目され主流になってるような気がする。
むしろ速度はインフラ任せで。
エンド・ユーザ寄りの立場からはUIこそがコンピュータであるので、UIに注目が集まるのは仕方ないし、成熟期に入ったと思われる現代のコンピュータ産業ではインフラ構築に携わる人よりユーザーの方が多くなるのは自然なことでもあるでしょう。ですから人口ベースで言えばUI記述の難易に注目が集まるのは自然ではありましょう。
しかしそうなった今でもインフラは維持・追加、改良や再構築され続ける必要があり、人口ベースで従事している人の割合は減ったとしても基盤技術として重要性は相変わらずあります。
特にこの言語では大規模科学技術計算などインフラ実現寄りの想定ユーザを視野に入れている(とはいえオレオレ言語の実装だの人工無能だのあまり演算能力に重きを置いているとは思えない想定もあるのが解せません。開発者自身ターゲットに迷いがあるのかもしれませんが…。)のでパフォーマンスに関する責任をさらに自身のインフラへ丸投げするのはどうかと思います。(とはいうものの、「最近の高性能大容量PCで、ようやく多少の富豪プログラムでも平気で動く環境が整いました。これなら、いけると思ったのです。」などパフォーマンス面は丸投げする気満々に見える記述もあるのですが…。)
コレにしても、バックトラックつきの「重い」言語が
「重い」処理狙いの言語であるとは、
もともと思いにくいのですけども…
うまい数学的性質がまだ発見されていないため、事実上総当たり(力づく、ブルート・フォース)で探索を行うしか手がない分野というのはあります。そのジャンルの人でないので今の状況はどうだか知らないのですが、10数年前ならばゲノム解読やタンパク質の構造のパターンマッチングかなんかについてPrologでルール記述して総当たりしているという研究紹介を見たことはあります。
そのようなジャンルの改良に遺伝的アルゴリズムやシミュレーテッドアニーリングといったような統計的手法を利用したりする場合や、ヒューリスティックスや適用範囲が部分的な数学的性質しか発見されていない場合で、改良部分以外のプログラムの基本構造がやっぱりルールベースの総当たり探索という事例はありそうです(すぐ例が上がらないのですがゲームで手を探索する場合とかにあるような気がします)。
そういった場合はバックトラック機構を備えた言語処理系は便利でしょうし、規模も小さくないのでそれなりのパフォーマンスが求められることになるでしょう。
スクリプト言語とグルー (スコア:1)
>スクリプト言語はしばしば「糊(グルー)」と評されるようにプログラム相互間、人-プログラム間のインターフェースを提供するものなので
もともとScript言語をつかまえてグルーという呼び方には引っかかりを覚えています。
それいったらあらゆる言語がプログラム間やマンマシン間を繋ぐグルーですから。
繋がないならそれは言語ではない。
(というか言語ってもともとInterfaceでしょ)
ここでは機能を利用するための最低限のインターフェース(しばしばテキストベースの)を備えた既存プログラム間をつなぐ。
それもしばしば運用の場において、ad-hocでもいいし、多少性能が落ちてもいいから手早くつなぐことを主要な目的とした言語を想定しています。
狙いの違い、重視するところの違いによる言語の設計方針の違いを考えたいわけなので、インターフェースするんだからみな同じでしょという立場では一般的すぎると思います。
(グルーの語感もボルトや溶接といったより手間がかかるけれど堅固な構造の代わりにボンドでペタリと手軽にというところから取られているように思います。くっつけるんだからなんでも同じでしょとは言えないわけで適材適所が求められます。)
狭い意味で糊という言葉を使うのだとしても、
じゃあScript言語で「アプリケーション(のコアロジック)」を書かないのか?といえば、
(それこそ速度重視な一部場面を除けば)そんなこたぁ無いわけです今時は。
コアロジックじゃなく速度が必要な一部…ドライバ的な…を低級言語に振ることは有りますが。
「アプリケーション」自身が多様ですからね。ゴリゴリ数値計算、カリカリ組み込み機器制御、サクサク伝票処理、etc.ではそれぞれ求められるものが違います。それにあった言語も当然違うでしょう。
Script言語といえども近頃は簡易言語というわけでもないのは確かで、基本的な制御機構やデータ構造は備えており(というかしばしば結構リッチな制御機構やデータ構造を基本構文や基本データ型として備えている)、書くだけなら理論上は大概のものは書けるでしょう。でもそれで十分な性能(実行性能、堅牢性、メンテナンスしやすさ、再利用性、相互運用性などなど)が見合ったコストで達成できるかどうかは別の問題です。
もちろんいずれも程度問題なのですが、
まさにその程度問題を問題にしたいわけなので皆一緒でしょというわけにはいきません。
少なくともインフラのほうは年々高速化してるため、
「言語のほうで速度を稼ぐ必要性」は年々減っているのも事実。
冒頭にも書いたように人口ベースで関心を持つ人の割合が減ってるのはおそらくそうなのでしょうが、インフラを作らなくて良くなったわけではありませんし、ここで話題になっている言語は大規模科学技術計算という、どっちかといえばインフラ寄りの要求がある種類のアプリケーションの記述をターゲットの1つに想定していると開発者が言ってますので。
#もしこれが手軽にバックトラックが書けるところに焦点を置いていると書かれていれば
#パフォーマンスだ最適化だと大人げない無粋なコメントは私もしなかったと思います。