ロジック プログラミング言語「デカルト言語」の開発者に聞く 44
Pascalとは関係ありません 部門より
SourceForge.JPでは、同サイトを利用するオープンソース・プロジェクトを毎月1つピックアップし、その開発者にインタビューする「今月のプロジェクト」というコーナーを設けています。今回は、ロジック プログラミング言語「デカルト言語」を開発しているhniwaさんにお話をうかがいました。
プロジェクトの概要
- プロジェクト名: デカルト言語 - ロジック プログラミング言語
- 登録日: 2009-01-07 01:32
- URL: http://osdn.jp/projects/descartes/wiki/FrontPage
- プロジェクトホーム: http://osdn.jp/projects/descartes/
- 動作環境: コンソール(テキストベース), Win32 (MS Windows), Linux
- ライセンス: GPLv2
- 主要対話語: 日本語
- プログラム言語: C++
- プロジェクト管理者: hniwa
デカルト言語とはどんな言語ですか？
変な言語です。
狙っているのは、強力な論理的推論・探索機能があり、関数プログラミング機能を持つオブジェクト群が、人間に近い構文のI/Fによって動く知的なシステムです。
厳密ではないのですが、簡単に言うとデカルト言語のアイデアは、述語論理+関数+拡張バッカス記法+オブジェクト指向です。
まずは、prologのように、バックトラック機構を持った述語論理言語がベースになっています。例えば、prologのリスト処理プログラムは、構文を書き直すだけでそのまま動きます。
しかし、prologとは異なり、引数の中にさらに述語を書くことができる関数述語機能を持ちます。これは、述語の中の引数に述語を記述するとその第一引数を返り値と見做して実現しています。
また、拡張バッカスナウア記法のオア | , 省略可[], 繰り返し{}のような制御構造を拡張しています。そのため、文脈自由文法の生成規則をデカルト言語で記述すると、それが構文解析のパーサになります。
●例3：Tiny Rubyコンパイラの作成, 続Tiny Rubyコンパイラの作成(2)
さらに、オブジェクト指向プログラミングの機能を持ち、継承やポリモフィズムおよびカプセル化の機能をサポートします。
●例4：デカルト言語による論理的なA.I: 自然言語による論理, デカルト言語のプログラム：サルとバナナ
使い方のマニュアルは以下にあります。
http://osdn.jp/projects/descartes/wiki/Manual
デカルト言語は、誰でも簡単に使える言語は目指していません。この言語の利用者が深く理解し習熟し工夫を重ねることにより、素晴らしい結果が得られるような言語にしたいと考えています。
だから、ちょと分かり難いし、ちょっと書き難いかもしれませんが（笑）
今までのコンピュータサイエンスは、20世紀末に叫ばれたソフト開発者の不足に対応するために、開発言語や開発手法など、おまりに簡単で大勢に使えることばかりに注力してきたように思えます。しかし、現状を見ればわかるとおり、すでにコンピュータはコモディティな存在となり、そのような目的はもう達成されてしまったように感じます。人を集めてちょっと教育して大量投入すればなんとかなる仕事は現状でもう十分です。
今後のコンピュータサイエンスは、多少扱いが難しくても、より高度でより困難な問題が解決できるような方向に前進すべきではないでしょうか。
ちょっと変な喩えなのですが、大勢を載せた快適な大型旅客船ばかりではなく、キーンと甲高いジェット音を鳴り響かせ、操縦には高度なテクニックが必要ではありますが、高速で高機動な超音速戦闘機が必要なのではないかと考えています。のんびりとした船旅をしている間に、何者にも邪魔されずに地球の反対側まで超音速で到達できるのです。(デカルト言語では、まだその域には達していませんが。)
プロジェクトを始めた動機は？ また、どうやって始めましたか？
最近のコンピュータの飛躍的な性能向上と容量拡大により、実現可能な状態になったと感じたからです。
デカルト言語は、とても重い言語になると予想できました。まさにHeavyweight Languageです。前からいろいろとアイデアは持っていたのですが、最近の高性能大容量PCで、ようやく多少の富豪プログラムでも平気で動く環境が整いました。これなら、いけると思ったのです。
影響を受けたプログラミング言語はありますか？
昔の第五世代コンピュータ計画で開発されたGHC（Guarded Horn ClausesでHaskellではない）言語の本を見つけて読んで衝撃を受けました。
デカルト言語とはずいぶん異なるのですが、30年も前の容量も少なく性能も低いコンピュータで目指す目標が壮大なのです。今からもう一度、第五世代コンピュータプロジェクトをやり直したら、今度は結果が異なるのではないでしょうか。
GHCと似た系統のガード節やユニフィケーション機能を持つ、HaskellやErlangが最近脚光を浴び始めているのも、やっと時代が追いついてきたということではないでしょうか。
このソフトウェアのターゲット・ユーザーは？
いろいろな人に使ってもらいたいです。
- awk代わりに、入力ファイルを読み込んで、結果を出力するようなスクリプト言語を使いたいユーザー
- 業務用のエンタープライズ処理を行いたいユーザー
- オレオレ・プログラム言語のインタプリタやコンパイラを作りたいユーザー
- 大規模な科学技術計算を行いたいユーザー
- 自分のオリジナルの人工無脳を作りたいユーザー
- 未来世界の支配を企むAIを実現したいユーザー ：－）
特に、今までのコンピュータではできなかったようなことを、停滞することなく前向きに実現できる人に使ってもらいたいです。
プロジェクトがうまく行っていると感じるのはどんなときですか？
デカルト言語のアイデアがいろいろと次々と思い浮かぶときです。そんなときには、ごりごり書いたプログラムがコンパイルエラー無しで一発でコンパイルできます。
このプロジェクトをやっていて最も驚いた出来事は？
あまり驚くようなことは無かったように思えます。
毎日淡々と機能拡張していくことが楽しみです。
このプロジェクトで最も苦労している点は？
やはり、ドキュメント整備です。
私の頭の中にしかない仕様や機能をドキュメントにしなければならないので、誰かに頼むわけにもいきませんし。
できる範囲で順にドキュメントを書いてきました。
今後のプロジェクトの方向性は？
デカルト言語本体も拡張していくのですが、今後はドキュメントとアプリを増やしていきたいと考えています。
ソースコードは、割りとどんどんと書けるのですが、マニュアルや関連ドキュメントがなかなか整備しきれません。
また、アプリケーションを書いていきたいですね。言語を創っただけではあまりにも意味がないので、デカルト言語で動くアプリケーションを増やしていきたいと考えています。
それと、本体の拡張としては、コンパイラを作り性能を改善したいですね。また、加えてWWWアプリのサーバーサイドやクライアントサイドとしても使えるようにしたいとまだ漠然としてはいますが考えています。
また、マルチコアにも対応しないといけないですね。
このソフトウェアあるいはプロジェクトについて誇れるところは？
他のプログラミング言語とは異なる毛色になっているじゃないかと思えるところでしょうか。
このプロジェクトでどこかやり直せるとしたら、どこを変更したいですか？
デカルト言語という名前が英字では"descartes"と、長くて打ちにくくて覚えにくいので後悔することがあります。
しかし、デカルトには、心身２言論や普遍言語および機械論的世界観など、デカルト言語と無関係とは思えないような思想や哲学があるので、おそらく名前を変えたりすることは将来もないでしょう。
あなたの本業は何ですか？
IT系メーカーの開発者です。
あなたの開発環境は？
Windows Vista上のcygwin環境と、自分でカーネルとコマンドを入れ替えて元が何かわからなくなったLinuxです。VMware上でUbuntu Linuxも使っています。
バージョン・ヒストリー：
プロジェクト開始から４ヶ月ほどです。開発状況はαです。
-
2009-04-29：descartes-0.10.0リリース
- オブジェクト指向の機構の改善 -
2009-04-08：descartes-0.9.0リリース
- list、matrix、cursesモジュールの追加 -
2009-03-15：descartes-0.8.0リリース
- 述語関数の引数の評価範囲の拡大 -
2009-02-24：descartes-0.7.0リリース
- 複素数のサポート -
2009-02-15 descartes-0.6.0リリース
- printf述語の追加 -
2009-02-08：descartes-0.5.0リリース
- 動的なオブジェクト指向の機構の追加 -
2009-02-01：descartes-0.4.0リリース
- 浮動小数点数の精度をlong doubleに変更 -
2009-01-25：descartes-0.3.0リリース
- 構文解析機能を強化 -
2009-01-17：descartes-0.2.0リリース
- 整数を32bitから64bitの精度に変更 -
2009-01-10：descartes-0.1.0リリース
- 最初のリリース - 2009-01-08：プロジェクト開始
このプロジェクトに貢献するには？
デカルト言語を使っていろいろなアプリケーションを書いて公開してください。
また、プロジェクトのwikiのページにあるドキュメントは、転用して知らない人に説明する資料として使ってください。
http://osdn.jp/projects/descartes/wiki/FrontPage
SourceForge.jpへの要望をお聞かせください
特にはないのですが、強いて言えば、具体的には言えなくて申し訳ないのですが、何かドキュメントを書きたくなるような動機付けがあると良いのではないかと思います。
他のプロジェクトの方の面白そうなプロジェクトがあっても、あまりドキュメントが整備されていなくて結局、内容がよくわからないことが多いような気がします。
パーミッション (スコア: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税なのでしたｗ
このスレは伸びない (スコア:1, すばらしい洞察)
お前らのプログラミングの話題ってやたら言語に偏るくせに、論理型言語にはまるで興味ないのな。
Re:このスレは伸びない (スコア:1, おもしろおかしい)
そらまさに、
> 20世紀末に叫ばれたソフト開発者の不足に対応するために、開発言語や開発手法など、おまりに簡単で大勢に使える
> ことばかりに注力してきたように思えます。しかし、現状を見ればわかるとおり、すでにコンピュータはコモディティな
> 存在となり、そのような目的はもう達成されてしまったように感じます。人を集めてちょっと教育して大量投入すれば
> なんとかなる仕事は現状でもう十分です。
といったことがズバリ当てはまる人たちが集うサイトですから。
Re: (スコア:0)
そうではなくて、この言語に興味をもてない。
Prolog IVなどには多少興味はあるけど。
Re: (スコア:0)
だってさ、
> 今後のコンピュータサイエンスは、多少扱いが難しくても、より高度でより困難な問題が解決できるような方向に前進すべきではないでしょうか。
と言っているけどさ、
今までだって頭のいい人は世の中に沢山居て、
既存の言語を使って色々な問題を解決して来たでしょう。
それに対して、今まで不可能だった高度で困難な問題を解決できるように
すると言うためには、新しいパラダイムを備えた言語を提示する必要があるよね。
たとえば、往年のLispやPrologやSmalltalkとかのようにね。
でも、論理型言語と関数型言語（この二つはパラダイム的には大差な
Re:このスレは伸びない (スコア:2)
パラダイムを変えたくて処理系を作るのではなく、
発明がしたいから処理系を作るのではありません。
成果とかそういうのじゃなく、単に言語処理系を作るのが面白いから作るのに決まってます。
# ターゲットユーザが散漫な感じがするのは気のせいか？
Re: (スコア:0)
馬鹿でも語れる好みの問題と違って、それなりに知識も経験も必要な話題だから下手な事は言わず大人しくしてるだけですが何か？
それともなんでもいいから馬鹿みたいにマンセーしたり叩いたりすれば満足ですか？
Re: (スコア:0)
本気でそう思ってるならその態度を貫けばいいのに、なんでブレてるの？ｗ
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)
発明者本人とその他の、２通りの立場で意味が変わってくる言葉だと思います。
それと、既に存在している車輪の技術と所有権がどれだけシンプルなのか。
(1)
まず、発明者自身が言っている場合は、発明後に気がついてorzとなった無駄骨感、
もしくは発明前から解っていながら敢えて再検討する自分のワガママさに
自分自身呆れている…というような自嘲的なニュアンスを表しています。
大体、コンピュータサイエンス系の学校を出ていれば、自前でMD5やZIPなどの
符号化アルゴリズムを再実装した事がある人が殆どではないでしょうか。
学習の場であれば推奨されるような、学生的な作業を社会人に
Re:車輪の再発明はちょっとかわいそう (スコア:0)
Re: (スコア:0)
私は車輪の再発明が常に悪い事だとは思ってませんから、
車輪の再発明と断定することが酷だとは思えません。
Re: (スコア:0)
大事なところは言語が違うかどうかではなく、ユーザーにとってどう違うか、それをちゃんとアピールできているかということ。
車輪を再発明したら多少違うのができました、ではねえ。
Re: (スコア:0)
この辺りの例を挙げて説明してもらえますか？
私は、モジュールをベースとしたオブジェクトの定義など実現方法が似ていると思いました。ちなみにデカルト言語ではオブジェクトのインスタンス化、継承、仮想関数などが見当たりませんね。単なるドキュメントの不足でしょうか。
車輪の再発明と断定したつもりはありませんが、他の車輪の存在を知った上でより優れたものを再発明するのであれば全く問題だと思っていません。