アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
争点 (スコア:1, 興味深い)
uim側の最大の不満は、IIIMFのセキュリティの弱さだったのだろうか。
(でも、IIIMFのサーバをuserで動かせば良いだけのような気がしたり)
それとも、設計の汚さ?
プロジェクトが欧米主導で進められていることに対する感情的な問題の方が、
大きかったりするんではないかと言ってみる。
Re:争点 (スコア:1)
> Bad Design賞を差し上げたいような作りになっていますが、
とゆーことで、設計の汚なさなのでは。(中を見たわけではないので、どこがどうマズいのかは判断が付きませんが)
> プロジェクトが欧米主導で進められていることに対する感情的な問題の方が、
んー、主導している人は日本人 [openi18n.org]なので、そーゆー問題ではないのではないかと。
確かに所属企業はSunとかIBMとかRedhat
Re:争点 (スコア:1)
とりあえず、このXMLらしきもの [gnome.org]は悪寒がしました。
あとはシンクライアントを前提としたclient/server設計になってるところとか。
具体的な問題は中身を読んでないの
Re:争点 (スコア:0)
単なる疑問なのですが、何故悪寒がするのですか?
Re:争点 (スコア:2, 参考になる)
XML形式で実装してるようですが、これが酷い仕様だからです。具体的に問題点を挙げると、
・醜い
CやJavaやSchemeなどの既存の言語と比べると非常に見にくいです。
<lt></lt>が不等号の「<」とかいうのは想像付くのですが、これで何かプログラムを書けと言われたらキレます。
・XMLらしくない
とりあえずプログラミング言語らしき部分は目をつぶるとしても、それ以外の箇所も酷いです。
<deftable name="romakana" from="mtext" to="mtext"></deftable>でローマ字→ひらがなの対応を定義
Re:争点 (スコア:1)
ソースコードの見やすさがアスキーアートによって制御されている状況はもう古いと思います。いいかげんモデルとビューを分けるべきです。
EclipseやMathematicaやSqueakやVisualStudioのような統合開発環境がビットマップディスプレイ上に見やすく整形して表示すればいいだけの話です。実際Mathematicaは数式を綺麗に表示してくれます。それでいながら数式の構造を厳密に知りたいと思えば"関数名[引数]"の形で表示させることもできます。
C++でテンプ
Re:争点 (スコア:1)
> XMLらしくないというのは同意ですが、醜いというのはスタイルシートでどうとでもでき得ることでは。
> いいかげんモデルとビューを分けるべきです。
発
Re:争点 (スコア:1)
「生のXMLの文法がプログラミング言語に向いていないのでXMLでプログラムを書くアプローチは酷い仕様である」
ということに対する反論、さらに
「逆にスタイルシートを使うことを前提とすればXMLでプログラムを書くことは多くのメリットがある(『メリットはほぼ皆無』などではない)」
ということです。
>発言が矛盾してますよ。
いや、XML部分(モデル)はアルゴリズムを記述するのに専念してソースの読みやすさなどのビューの部分はスタイルシートで調整しろという意味です。
現状ではソースコードにアルゴリズムと
なんというか (スコア:0)
それとXMLでプログラムを書くアプロー
Re:なんというか (スコア:1)
Re:なんというか (スコア:0)
>> どうかです。
現状では「酷い仕様」といわざるを得ないよ。
だってあなたのいうそのPCEL用の素敵な統合環境なんて、
今は存在してないんだから。
Re:なんというか (スコア:1)
ああいえばこういうですか? (スコア:0)
Re:ああいえばこういうですか? (スコア:1)
しかし、そこまで実装にこだわるのならば部分的ながら実装をいくつか。
JEX [sourceforge.net] JVM用のプログラムをXMLで書けるようにしたものです。javaからのデコンパイラが開発中です。
Meta Environment [www.cwi.nl]言語の文法とセマンティクスを記述したり、それを使ってプログラムを評価するシステムです。プログラムは文脈自由文法のプログラミング言語からATermというツリー形式に変換されます。XMLとして出力することもできます。
また.NETではC#, VB.NET, JScript.NETとC
Re:ああいえばこういうですか? (スコア:1)
図言語としてのUML2において、UML表記はUML MOF
モデルの1表記法にすぎず、他にテキスト表現もある。
UMLのアクションセマンティクスはセマンティクスのみが
定められた言語でシンタックスはベンダが独自に決めていい。
古くはlispのM式とS式のちがいみたいなもんで、
新しいアイデアでもない。金物表現ってのもあったな。
AppleScriptは日本語でも表記できるんだっけ。
XMLをその種のモデルの交換形式に用いるのも
ごく自然な考え方だ。
しかし、
Re:ああいえばこういうですか? (スコア:1)
そういうのがあるとアスペクト指向的なことも簡単にできてしまいます。
emacsのxmlモードなどはあくまで例で使う側が勝手に使いやすいものを使えばいいです。そして使いやすいものを選べるというのが利点です。
Re:ああいえばこういうですか? (スコア:1)
その編集が元のツリーに反映されるようなものはありますか?
XMLを完全に隠蔽した状況で。
いや、私の主張は
-XMLは人間が書くもんではない。
-プログラミング言語は人間と機械(もしくは人間同士)の
意思疎通のための死活的に重要なインターフェースである。
-そのためXMLを前面に出したり存在を意識させるような言語は、
プログラミング言語ユーザとしてのプログラマに対して失格。
XMLが完全に隠されていればまあ許す。
-隠すことを前提に内部データ構造や、
処理系内部で受け渡す中間表現として、
あるいは処理系をカスタマイズする際に見せるデータ構造として、
XML(および関連技術)を選ぶのはあるかも。
GCCのRTLのように。でも、便利に思えないな。
XSLTでオプティマイザ書きますか?いずれにせよ、実装方式の
問題であって比較的閉じた問題。
-プログラミング言語に個人ごとに自分用のスタイルシート
をカスタマイズして使うほどの、表記がぜんぜん変わるほどの
自由度を持ったカスタマイズ性は過剰で不要。
レビューはどうするんだ。メールに引用もできんぞ。
マニュアルや教科書を書くためにもまずある程度無難な
(フォントとかの細部はいいとしても根幹部についての)
標準表記/標準スタイルシートが必要。
んで、私だったらその標準表記以外は使わん。
です。
Re:ああいえばこういうですか? (スコア:1)
重要なのは必要な時に比較的簡単に使えるということです。
内部表現に簡単に触れる言語や環境の例としてMathematicaや.NETの他にMaximaがあげられます。MaximaはLispで書かれていますが通常それは隠蔽されていて普段使うときにLispを意識することはありません。しかしいざとなればすぐにアクセスすることができます。これならばLispをガリガリ書ける人でも「Lispは人間が書くもんではない。」「Lispを前面に出したり存在を意識させるような言語は、プログラミング言語ユーザとしてのプログラマに対して失格」という人でもだいじょうぶです。
>任意のXSLTで変換後のものに対してGUI編集し、
>その編集が元のツリーに反映されるようなものはありますか?
>XMLを完全に隠蔽した状況で。
そのXSLTというのはコード変換のためのXSLTですか? それともスタイルのためのXSLTですか?
コード変換のためであればマクロ展開と同じようにマクロを展開した後のコードをいじって元のコードをいじろうとは普通しません。確かにできないこともないですしできれば嬉しいことも多いのですがそのときは逆変換を行う変換を書くかXSLT変換後の言語にまかせることになります。
スタイルのための変換であれば入力系の制御はXSLT変換後の言語の範疇です。
>プログラミング言語に個人ごとに自分用のスタイルシートをカスタマイズして使うほどの、表記がぜんぜん変わるほどの自由度を持ったカスタマイズ性は過剰で不要。
開発チーム内で共通のスタイルを使えば良いはずです。今でも言語やコーディングスタイルは統一しているはずです。
C言語やPerlだって読みづらいコードのコンテストが行われるぐらい自由に書けますが普段そんなコーディングはしません。
しかもアルゴリズムとスタイルを分離しておけば古いコードを受け継いだとかでチームのコーディングスタイルが変化した時でも柔軟に対応できます。
メールへの引用もXMLコードとスタイルシートを渡せば良いだけでは? そのスタイルシートを使うかどうかは読み手次第ですし。
VBによるGUIデザインについてのメールであればフォーム定義ファイルを添付して受け手側のVBでフォームとして表示して見るなりエディタで直接見るなりするでしょう?
標準のスタイルは確かに重要です。.NETであればそれはC#になるでしょう。でも問題によっては別の言語を使った方がよいこともあります。
そしてスタイルシートでカスタマイズするということは言語全てを変えてしまうという使い方以外にも「関数の定義をリストアップする」とか「ループを折り畳む」とか「データーをグラフにして表示する」とか「関数の呼び出し関係をグラフにする」とか「式の型を表示させる」とか「特定の条件にあった式をハイライトする」とか「関数を一時的にインライン展開して表示する」とか「例外処理を一時的に隠す」と言ったコーディングの補助も含みます。
Re:ああいえばこういうですか? (スコア:1)
> それともスタイルのためのXSLTですか?
あなたが「(プログラミング言語の表現として)XMLが便利だ、
その根拠(の一つ)としては、XSLTが使えるからだ」と主張し
ていますが、その便利に使えるといるXSLTの使い道におい
て使っている範囲のXSLTです。
ちなみに私はモデルにXMLを使うこと以外の方法でモデルとビュー
を分けることについては良いと思っていますよ。
「モデルにXMLを使う」ということの意味が意味不明だけどね。