アカウント名:
パスワード:
ソースからビルドしてみました。configureに実行権限がないのでsh configureでconfig。こんなんで大丈夫かな〜と思いつつmakeすると、案の定
missing: Permission denied make: *** [aclocal.m4] エラー 126
と叱られました。その後は無事ビルド完了。ドキュメントを読まずにとりあえず入力するとresult -- unknownばっかりで面喰ったけど言語仕様がてんこ盛りで面白そう。こういう言語は自分でも一度作ってみたかったョ。
プログラミング言語の文法は所詮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つに想定していると開発者が言ってますので。
#もしこれが手軽にバックトラックが書けるところに焦点を置いていると書かれていれば#パフォーマンスだ最適化だと大人げない無粋なコメントは私もしなかったと思います。
Prolog使っていましたが、処理系の実装を把握してなくても問題ありませんでした。まあ大規模なコードをかいたわけではないですが。コードが簡潔に書けるのは一つの利点でしょう。Prolog処理系が行っているようなユニフィケーションを一々実装するのは面倒です。
処理系を完全に理解していないと一体どういう場面で困るのか、具体例を教えてください。
奥義は一子相伝(一社独占)なので、熾烈な継承争いが繰り広げられたのでありました。そして我々を待ち受けていた結末は重いAdobe税なのでしたw
お前らのプログラミングの話題ってやたら言語に偏るくせに、論理型言語にはまるで興味ないのな。
そらまさに、
> 20世紀末に叫ばれたソフト開発者の不足に対応するために、開発言語や開発手法など、おまりに簡単で大勢に使える> ことばかりに注力してきたように思えます。しかし、現状を見ればわかるとおり、すでにコンピュータはコモディティな> 存在となり、そのような目的はもう達成されてしまったように感じます。人を集めてちょっと教育して大量投入すれば> なんとかなる仕事は現状でもう十分です。
といったことがズバリ当てはまる人たちが集うサイトですから。
だってさ、
> 今後のコンピュータサイエンスは、多少扱いが難しくても、より高度でより困難な問題が解決できるような方向に前進すべきではないでしょうか。
と言っているけどさ、今までだって頭のいい人は世の中に沢山居て、既存の言語を使って色々な問題を解決して来たでしょう。
それに対して、今まで不可能だった高度で困難な問題を解決できるようにすると言うためには、新しいパラダイムを備えた言語を提示する必要があるよね。たとえば、往年のLispやPrologやSmalltalkとかのようにね。
でも、論理型言語と関数型言語(この二つはパラダイム的には大差な
馬鹿でも語れる好みの問題と違って、それなりに知識も経験も必要な話題だから下手な事は言わず大人しくしてるだけですが何か?
それともなんでもいいから馬鹿みたいにマンセーしたり叩いたりすれば満足ですか?
本気でそう思ってるならその態度を貫けばいいのに、なんでブレてるの?w
だってさ、正直いって既存の言語のsyntaxをちょっと変えた位にしか見えないけれどそう言ったらダメ出しにしかならないじゃない新規に言語を作るのは応援したいけれど、適切な言葉が見つからないんだから黙るしかない
# 記号と言うか、"あるふぁべっと" の選択がイマイチだなぁ…
>新規に言語を作るのは応援したいけれど、適切な言葉が見つからないんだから黙るしかない貴方が言語を作る時にはウィトゲンシュタイン言語と名付けると良いでしょう。
Heavyweightな言語でパワフルな処理をしたい、という目的が第一だと語っておられる様子。マルチコア対応は真っ先に処理しなきゃいけない課題なんじゃないかな?
自分が仕事で使わされるんじゃないんだからさ、無粋な茶々言わないで、設計者のやりたい順にやってもらえばいいんでないかな。
それで、いつの日にか美味しい言語になったら、その後で楽しめばいいでしょう。
課題っつー言い方は悪かったですね。インタビューを読んでいる途中は最近の高速多コアCPUでゴリゴリ! って妄想にわくわくしてたのでマルチコア対応がこれから、ってところで、ちょっとアリャって思ったというだけです。
その分野は素人なのでわからないんだけど、マルチコア対応って処理系の改造としては面白いのかしらん、面白くないのかしらん。もちろん人それぞれだろうけど。
できるような気もする。メモリ領域の拡張でしか無い気もする。
まだ、ドキュメント読んでる途中だけど。SQLでできることじゃつまらないよね。
>人を集めてちょっと教育して大量投入すればなんとかなる仕事は現状でもう十分です。
そんなシゴトは(滅多に)ありませんorz
(多数派として)存在するのは「人を集めてちょっと教育して大量投入するばかりではなんともならずデスマになる仕事」です。
デカルト言語に価値が無いなんてことは無いと思います。ただ、その発想に基づいて言語仕様を決定なさったのだとしたら、「頼む、こっちも助けてくれ」とお願いしたい次第ですorz
まあ、素晴らしい言語を作れる人は、逆に凡庸言語は作れない、ということも有りますので、お手を煩わせることが必ずしも凡庸プログラマを救えるという保証も無いのですが…
#自称素晴らしいプログラマ、でも実際凡庸なのでAC
デカルト言語の特徴として
厳密ではないのですが、簡単に言うとデカルト言語のアイデアは、述語論理+関数+拡張バッカス記法+オブジェクト指向です。
と挙げているが、このうちEBNF以外はCiao Prolog [fi.upm.es]という処理系で既にサポートされているのをこの作者は知らないのだろうか。Prologをある程度やっている人には結構有名だと思っていたのだが。こちらの方は制約プログラミングをサポートしていたり、上記ウェブサイトもPrologで自動生成されている位モジュールが揃っている。
もちろん、他にもほぼ同様の事を実現している言語がある上でやっているのなら良いですが、新規性と言っても変なシンタックスとEBNFサポート程度だと思います。
車輪の再発明って悪口として良く聞くけど、一体何なんだ?改良も立派な発明だろう。
発明者本人とその他の、2通りの立場で意味が変わってくる言葉だと思います。それと、既に存在している車輪の技術と所有権がどれだけシンプルなのか。
(1)まず、発明者自身が言っている場合は、発明後に気がついてorzとなった無駄骨感、もしくは発明前から解っていながら敢えて再検討する自分のワガママさに自分自身呆れている…というような自嘲的なニュアンスを表しています。大体、コンピュータサイエンス系の学校を出ていれば、自前でMD5やZIPなどの符号化アルゴリズムを再実装した事がある人が殆どではないでしょうか。学習の場であれば推奨されるような、学生的な作業を社会人に
私は車輪の再発明が常に悪い事だとは思ってませんから、車輪の再発明と断定することが酷だとは思えません。
その実装も表現も機能もデカルト言語では随分違うように見えます。
この辺りの例を挙げて説明してもらえますか?私は、モジュールをベースとしたオブジェクトの定義など実現方法が似ていると思いました。ちなみにデカルト言語ではオブジェクトのインスタンス化、継承、仮想関数などが見当たりませんね。単なるドキュメントの不足でしょうか。
車輪の再発明と断定したつもりはありませんが、他の車輪の存在を知った上でより優れたものを再発明するのであれば全く問題だと思っていません。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
パーミッション (スコア:4, 興味深い)
ソースからビルドしてみました。
configureに実行権限がないのでsh configureでconfig。
こんなんで大丈夫かな〜と思いつつmakeすると、案の定
missing: Permission denied
make: *** [aclocal.m4] エラー 126
と叱られました。その後は無事ビルド完了。
ドキュメントを読まずにとりあえず入力するとresult -- unknownばっかりで面喰ったけど
言語仕様がてんこ盛りで面白そう。
こういう言語は自分でも一度作ってみたかったョ。
大事なのは最適化 (スコア: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つに想定していると開発者が言ってますので。
#もしこれが手軽にバックトラックが書けるところに焦点を置いていると書かれていれば
#パフォーマンスだ最適化だと大人げない無粋なコメントは私もしなかったと思います。
論理的推論・探索機能 (スコア:2)
Prologでもそうだったが、処理系でどこまで面倒みてくれて
こちらで、どこまで面倒みないといけないのか、
処理系を完全に理解していないと使えない。
開発者の思考に合わせるくらいうなら、余計な機能なんか
ない方がよっぽど使いやすい。
ソースが短くなるとか言っても、結局、処理系に負荷をかけているだけなので
速度が上がるわけでもないし。
Re:論理的推論・探索機能 (スコア:1)
Prolog使っていましたが、処理系の実装を把握してなくても問題ありませんでした。まあ大規模なコードをかいたわけではないですが。コードが簡潔に書けるのは一つの利点でしょう。Prolog処理系が行っているようなユニフィケーションを一々実装するのは面倒です。
処理系を完全に理解していないと一体どういう場面で困るのか、具体例を教えてください。
こういう意見の人たちが増えてきて…… (スコア:0)
そして言語が面白くなくなってただの仕事の道具になり下がってしまった感が……
ワクワクを取り返せっと叫びたくなる今日この頃
愛を取り戻せ! (スコア:0)
199X年世界は核の炎に包まれた
人々は歯車の様に扱われ、ちょっと適当な仕事をすると「汚物は消毒だぁ」
そんなプログラミング世紀末の救世主が「(Youは)Shock」Waveだったんですね!
Re: (スコア:0)
奥義は一子相伝(一社独占)なので、熾烈な継承争いが繰り広げられたのでありました。
そして我々を待ち受けていた結末は重いAdobe税なのでしたw
このスレは伸びない (スコア:1, すばらしい洞察)
お前らのプログラミングの話題ってやたら言語に偏るくせに、論理型言語にはまるで興味ないのな。
Re:このスレは伸びない (スコア:1, おもしろおかしい)
そらまさに、
> 20世紀末に叫ばれたソフト開発者の不足に対応するために、開発言語や開発手法など、おまりに簡単で大勢に使える
> ことばかりに注力してきたように思えます。しかし、現状を見ればわかるとおり、すでにコンピュータはコモディティな
> 存在となり、そのような目的はもう達成されてしまったように感じます。人を集めてちょっと教育して大量投入すれば
> なんとかなる仕事は現状でもう十分です。
といったことがズバリ当てはまる人たちが集うサイトですから。
Re: (スコア:0)
そうではなくて、この言語に興味をもてない。
Prolog IVなどには多少興味はあるけど。
Re: (スコア:0)
だってさ、
> 今後のコンピュータサイエンスは、多少扱いが難しくても、より高度でより困難な問題が解決できるような方向に前進すべきではないでしょうか。
と言っているけどさ、
今までだって頭のいい人は世の中に沢山居て、
既存の言語を使って色々な問題を解決して来たでしょう。
それに対して、今まで不可能だった高度で困難な問題を解決できるように
すると言うためには、新しいパラダイムを備えた言語を提示する必要があるよね。
たとえば、往年のLispやPrologやSmalltalkとかのようにね。
でも、論理型言語と関数型言語(この二つはパラダイム的には大差な
Re:このスレは伸びない (スコア:2)
パラダイムを変えたくて処理系を作るのではなく、
発明がしたいから処理系を作るのではありません。
成果とかそういうのじゃなく、単に言語処理系を作るのが面白いから作るのに決まってます。
# ターゲットユーザが散漫な感じがするのは気のせいか?
Re: (スコア:0)
馬鹿でも語れる好みの問題と違って、それなりに知識も経験も必要な話題だから下手な事は言わず大人しくしてるだけですが何か?
それともなんでもいいから馬鹿みたいにマンセーしたり叩いたりすれば満足ですか?
Re: (スコア:0)
本気でそう思ってるならその態度を貫けばいいのに、なんでブレてるの?w
Re: (スコア:0)
だってさ、正直いって既存の言語のsyntaxをちょっと変えた位にしか見えないけれど
そう言ったらダメ出しにしかならないじゃない
新規に言語を作るのは応援したいけれど、適切な言葉が見つからないんだから黙るしかない
# 記号と言うか、"あるふぁべっと" の選択がイマイチだなぁ…
Re: (スコア:0)
>新規に言語を作るのは応援したいけれど、適切な言葉が見つからないんだから黙るしかない
貴方が言語を作る時にはウィトゲンシュタイン言語と名付けると良いでしょう。
改善の順番が間違っているような (スコア:1)
Heavyweightな言語でパワフルな処理をしたい、という目的が第一だと語って
おられる様子。
マルチコア対応は真っ先に処理しなきゃいけない課題なんじゃないかな?
Re:改善の順番が間違っているような (スコア:2, すばらしい洞察)
自分が仕事で使わされるんじゃないんだからさ、無粋な茶々言わないで、
設計者のやりたい順にやってもらえばいいんでないかな。
それで、いつの日にか美味しい言語になったら、その後で楽しめばいいでしょう。
Re:改善の順番が間違っているような (スコア:1)
課題っつー言い方は悪かったですね。
インタビューを読んでいる途中は最近の高速多コアCPUでゴリゴリ! って妄想にわくわくしてたので
マルチコア対応がこれから、ってところで、ちょっとアリャって思ったというだけです。
その分野は素人なのでわからないんだけど、マルチコア対応って処理系の改造としては
面白いのかしらん、面白くないのかしらん。もちろん人それぞれだろうけど。
Re: (スコア:0)
Re: (スコア:0)
「自分なりの切り口で解釈し直してみました。」みたいな。
そんな取り組みでも理系がやればそこそこ面白いものも出てくるんだけど、
文系揃いのプログラマーじゃ、自慰行為以上のものはなかなか提示できないんだな。
データベースをつないだら (スコア:1, 興味深い)
Re: (スコア:0)
できるような気もする。
メモリ領域の拡張でしか無い気もする。
まだ、ドキュメント読んでる途中だけど。
SQLでできることじゃつまらないよね。
ありがとうございます。 (スコア:1)
いろいろとご意見ありがとうございます。こんなにコメントが付くとは思ってもいませんでした。
感激です。手厳しいご意見もありますが、参考とさせていただきたいと思います。
多様な中での進化に進歩があると信じていますので、コンピュータ世界の枝の一つとして、デカルト言語は今後も続けていきます。(上のほうで書かれている方が言いました通り、自分が一番面白がっているのが本当の理由ですが。)
Re: (スコア:0)
はいはいデカルチャー デカルチャー (スコア:0)
来なかった近未来 (スコア:0)
Amigaにまつわるエッセイというか単なる実話集のタイトルなんですが、
なぜか思い出しました。
底辺からの便り (スコア:0)
>人を集めてちょっと教育して大量投入すればなんとかなる仕事は現状でもう十分です。
そんなシゴトは(滅多に)ありませんorz
(多数派として)存在するのは
「人を集めてちょっと教育して大量投入するばかりではなんともならずデスマになる仕事」
です。
デカルト言語に価値が無いなんてことは無いと思います。
ただ、その発想に基づいて言語仕様を決定なさったのだとしたら、
「頼む、こっちも助けてくれ」
とお願いしたい次第ですorz
まあ、素晴らしい言語を作れる人は、逆に凡庸言語は作れない、ということも有りますので、
お手を煩わせることが必ずしも凡庸プログラマを救えるという保証も無いのですが…
#自称素晴らしいプログラマ、でも実際凡庸なのでAC
わかりました。で、 (スコア:0)
車輪の再発明 (スコア:0)
デカルト言語の特徴として
と挙げているが、このうちEBNF以外はCiao Prolog [fi.upm.es]という処理系で既にサポートされているのをこの作者は知らないのだろうか。Prologをある程度やっている人には結構有名だと思っていたのだが。こちらの方は制約プログラミングをサポートしていたり、上記ウェブサイトもPrologで自動生成されている位モジュールが揃っている。
もちろん、他にもほぼ同様の事を実現している言語がある上でやっているのなら良いですが、新規性と言っても変なシンタックスとEBNFサポート程度だと思います。
Re:車輪の再発明 (スコア:1)
車輪の再発明って悪口として良く聞くけど、一体何なんだ?
改良も立派な発明だろう。
the.ACount
Re: (スコア:0)
「車輪の再発明」は過程に意味があることがありますが、成果物には意味がありません。
成果物を評価してもらいたいのに「車輪の再発明」と言われたのであれば、新規性が足りないということです。ただ、裏を返せば、新規性に対する期待でもあります。
ダメ出しするにしても、理由が付いているというのは良心的です。
Re: (スコア:0)
でも、やっぱり、たぶん、これは、ちょっとひどすぎだねー。
車輪の再発明とは (スコア:0)
発明者本人とその他の、2通りの立場で意味が変わってくる言葉だと思います。
それと、既に存在している車輪の技術と所有権がどれだけシンプルなのか。
(1)
まず、発明者自身が言っている場合は、発明後に気がついてorzとなった無駄骨感、
もしくは発明前から解っていながら敢えて再検討する自分のワガママさに
自分自身呆れている…というような自嘲的なニュアンスを表しています。
大体、コンピュータサイエンス系の学校を出ていれば、自前でMD5やZIPなどの
符号化アルゴリズムを再実装した事がある人が殆どではないでしょうか。
学習の場であれば推奨されるような、学生的な作業を社会人に
Re:車輪の再発明はちょっとかわいそう (スコア:0)
Re: (スコア:0)
私は車輪の再発明が常に悪い事だとは思ってませんから、
車輪の再発明と断定することが酷だとは思えません。
Re: (スコア:0)
大事なところは言語が違うかどうかではなく、ユーザーにとってどう違うか、それをちゃんとアピールできているかということ。
車輪を再発明したら多少違うのができました、ではねえ。
Re: (スコア:0)
この辺りの例を挙げて説明してもらえますか?
私は、モジュールをベースとしたオブジェクトの定義など実現方法が似ていると思いました。ちなみにデカルト言語ではオブジェクトのインスタンス化、継承、仮想関数などが見当たりませんね。単なるドキュメントの不足でしょうか。
車輪の再発明と断定したつもりはありませんが、他の車輪の存在を知った上でより優れたものを再発明するのであれば全く問題だと思っていません。