Windows じゃキーロガーが仕掛けられて預金口座から金を引き出されたとか、今はそういう時代になっているのだから、かな漢字変換ならローカルのマシンですればいいのであって、それをネットワーク経由でやる実装に優位など無し。本質的にセキュリティーが確保し辛い仕様で作った物に、懸命にパッチを当て続けて使うのは徒労。
XMLらしくないというのは同意ですが、醜いというのはスタイルシートでどうとでもでき得ることでは。
ソースコードの見やすさがアスキーアートによって制御されている状況はもう古いと思います。いいかげんモデルとビューを分けるべきです。
EclipseやMathematicaやSqueakやVisualStudioのような統合開発環境がビットマップディスプレイ上に見やすく整形して表示すればいいだけの話です。実際Mathematicaは数式を綺麗に表示してくれます。それでいながら数式の構造を厳密に知りたいと思えば"関数名[引数]"の形で表示させることもできます。
C++でテンプレートの<>が入れ子になるとシフト演算子とみなされるからスペースを入れなければならないだとか、perlやrubyで f(a + b) + c が (f(a + b)) + c だか f((a + b) + c) だかわからないだとか、a + b は aとbの和 で a +b は +bという引数によるaというメソッドの呼び出しだとか、begin endの方が見やすい/いや{}の方が見やすいだとか、定数は大文字だとか、=が代入で==が等号だとか、Cのdo whileループは終了条件が後に出てくるから見にくいだとか、シェルスクリプトで\がシェルとアプリケーションの両方で解釈されるから\\\\と書かなければならないだとか、elsifラダーは最初のif(2文字)とそれより後elsif(5文字)で条件文のカラムがずれるから見にくいだとか、長い変数名だと式が見辛くなるから略語を使うだとか、桁数の多い数を3桁ごとに区切りたいけど','は使えないから'_'を使うだとか、このコメントは改行が少ないから見にくいとか、ばかばかしいです。
そんなことに頭を悩ませる前に必要最小限の記述能力を持った文法を作って(あるいはそれすらいらないかもしれない)DOMを準備して、見栄えは使う側や見る側に任せてセマンティクスの整備をしてほしいです。どうせ書きやすい上に見やすい文法なんてできっこないんですから。
そういう意味ではxmlをプログラミング言語のベースとして使うのは決っして悪いことではありません。文法は単純でパーサーは比較的作りやすいですし、木構造が表わせますし。LISPでもいいんですけどね。
争点 (スコア:1, 興味深い)
uim側の最大の不満は、IIIMFのセキュリティの弱さだったのだろうか。
（でも、IIIMFのサーバをuserで動かせば良いだけのような気がしたり）
それとも、設計の汚さ？
プロジェクトが欧米主導で進められていることに対する感情的な問題の方が、
大きかったりするんではないかと言ってみる。
Re:争点 (スコア:1)
> Bad Design賞を差し上げたいような作りになっていますが、
とゆーことで、設計の汚なさなのでは。(中を見たわけではないので、どこがどうマズいのかは判断が付きませんが)
> プロジェクトが欧米主導で進められていることに対する感情的な問題の方が、
んー、主導している人は日本人 [openi18n.org]なので、そーゆー問題ではないのではないかと。
確かに所属企業はSunとかIBMとかRedhatが多いようですが、中の人 [openi18n.org]はCJKな人の方が多いわけだし。
Re:争点 (スコア:3, 参考になる)
Re:争点 (スコア:1)
Windows じゃキーロガーが仕掛けられて預金口座から金を引き出されたとか、今はそういう時代になっているのだから、かな漢字変換ならローカルのマシンですればいいのであって、それをネットワーク経由でやる実装に優位など無し。本質的にセキュリティーが確保し辛い仕様で作った物に、懸命にパッチを当て続けて使うのは徒労。
Re:争点 (スコア:0)
>たとか、今はそういう時代になっているのだから、かな漢字変換なら
>ローカルのマシンですればいいのであって、
キーロガーってローカルマシンに仕掛けるものじゃないんですか？
Re:争点 (スコア:0)
1つ2つ危険な要素が無くなるだけで、危険度全体で見れば大して違わないでしょう。
そこだけ見るとローカルシステムの危険度を過小評価する恐れがある。
IIIMFが危険というのが事実ならば、それはクラサバが原因ではなく、IIIMFの問題と思われます。
Re:争点 (スコア:1)
とりあえず、このXMLらしきもの [gnome.org]は悪寒がしました。
あとはシンクライアントを前提としたclient/server設計になってるところとか。
具体的な問題は中身を読んでないので知らないのですが、上記の２点から、感覚的に「やばい」という印象があります。
# 最近anthyもuimも使ってないけどID
# 明日は参加します。
Re:争点 (スコア:2, 興味深い)
いい加減うんざりするので、もともとそのXML文書のもとねたとなった本人自ら
ここではっきり否定しておきます。
## 残念なことに、様々な事情もあり、いまは、IIIMFにはほとんど
## 関われなくなっていますし。
まず、あなたの思っている「悪寒の走る」という部分はEIMILでもなんでもありません。
あなたの「悪寒が走る」といっている部分は、おそらくPCEL(PCE Language)という部分の
ことを指しているんだと思います。しかも、PCELでも非常にプロトタイプのお話で、
とりあえず汎用のLWE としての機能できる適当なLisp Machineのサブセットを
作ってみましょうか、程度の話です。
EIMILの仕様など、内輪の資料しか作成していないはずなので、
外に出ている資料はほぼ皆無のはずです。
せいぜいim-sdkにに含まれている公開APIとはなっていない
試験実装が置いてあるだけです。
運が悪いことに、これが適当な形で流出して、あれやこれや尾ひれがついた解釈が
されてしまったのは、私にとっては痛恨のきわみといえます。
EIMILというのは、もともと、LEおよびLWEが、どのように連携したら、一連のIMとして
機能できるかということをevent-forward modelに従って記述することを目的として
設計されました。それが、主に element部に記述されます。EIMILは、様々な
言語や用途用にprofileを作ることが出来、そのprofileにしたがっている以上は、
IM利用者側は、どのようなLE/LWEが存在するかを意識することなくIM serviceを利用
出来、また、IM service提供者側はprofileに従って、serviceを部品として提供できる
ようにすることを意図していたのです。
IIIMFが初期の設計思想から(もう10年近く昔から)持っている、私の考える最大の長所は
以下の2点です。
(1) 真面目にIMのabstractionを設計することを試みた。
(IMが最低限必要とする非常に薄いレイヤを設計の基本としていた
つまり、preedit/lookup-choice/keyeventを基本単位として組み立てることが
基本設計となっていた。)
(2) その上で、event-forward modelによる拡張性を考えていた。
(IM_FORWARD_EVENT_WITH_OPERATIOSというmessageはある意味でその名残です。)
実際には、どうしても汎用のLWEがないと困る局面が多いだろうと考えて、とりあえず、
何でも出来る小さなLisp Machineを私が軽く作って、それがPCELの下となりました。
ただし、汎用のLWEは、Undo/SEH(構造化例外処理)が必要になるので、
それだけは無理してサポートしてあります。
そういう代物なので、PCELは、実際のところIIIMFの一部というよりも、汎用の何でも出来る
LWEの一実装に過ぎません。それも、ここで出ているXMLは、私の適当な実験の途中であり、
そんなものでIIIMFが評価されるのでは、私としてはたまらないものがあります。
これは、私が樋浦さんにお話する時に私がそういうことをちゃんと伝えてなかった、
というミスもあるのかもしれませんが、このXMLが一人歩きする主要な原因は、
おそらく別でしょう。どちらにしろ、IMのフレームワークで、ばかばかしい対立が
生じてしまったことは、真に不幸なことであったといわざるを得ません。
from himi
Re:争点 (スコア:1)
意図しなかったこととは言え、不快な思いをさせてしまったことに対してお詫びします。
> どちらにしろ、IMのフレームワークで、ばかばかしい対立が
> 生じてしまったことは、真に不幸なことであったといわざるを得ません。
この点については同意します。最終的に損をするのはユーザですから。
Re:争点 (スコア:0)
単なる疑問なのですが、何故悪寒がするのですか？
Re:争点 (スコア:2, 参考になる)
XML形式で実装してるようですが、これが酷い仕様だからです。具体的に問題点を挙げると、
・醜い
CやJavaやSchemeなどの既存の言語と比べると非常に見にくいです。
＜lt＞＜/lt＞が不等号の「＜」とかいうのは想像付くのですが、これで何かプログラムを書けと言われたらキレます。
・XMLらしくない
とりあえずプログラミング言語らしき部分は目をつぶるとしても、それ以外の箇所も酷いです。
＜deftable name="romakana" from="mtext" to="mtext"＞＜/deftable＞でローマ字→ひらがなの対応を定義してるようですが、
これがただの改行＆スペース区切り。これではXMLの意味がありません。
普通XMLを使うなら「＜key＞sya＜/key＞＜value＞しゃ＜value＞」みたいに構造化するはずなのですが。
XMLのメリットの一つに、構文が標準化されている(標準化されたAPIでアクセスできる)というのがありますが、
そのメリットを全く生かしてません。
そもそもXMLとプログラミング言語の文法は相性が悪いです。
昔XSLT [w3.org]で遊んでたことがあるのですが、これも(プログラミング言語としてみるなら)わかりにくい文法で苦労しました。
もっとも、XSLTは「XML文書を変換する」という目的のために作られたものなので、XMLであるのも十分理解できるのですが、
このEIMILについてはXMLであるデメリットはたくさんありますが、メリットはほぼ皆無です。
Re:争点 (スコア:1)
ソースコードの見やすさがアスキーアートによって制御されている状況はもう古いと思います。いいかげんモデルとビューを分けるべきです。
EclipseやMathematicaやSqueakやVisualStudioのような統合開発環境がビットマップディスプレイ上に見やすく整形して表示すればいいだけの話です。実際Mathematicaは数式を綺麗に表示してくれます。それでいながら数式の構造を厳密に知りたいと思えば"関数名[引数]"の形で表示させることもできます。
C++でテンプレートの<>が入れ子になるとシフト演算子とみなされるからスペースを入れなければならないだとか、perlやrubyで f(a + b) + c が (f(a + b)) + c だか f((a + b) + c) だかわからないだとか、a + b は aとbの和 で a +b は +bという引数によるaというメソッドの呼び出しだとか、begin endの方が見やすい/いや{}の方が見やすいだとか、定数は大文字だとか、=が代入で==が等号だとか、Cのdo whileループは終了条件が後に出てくるから見にくいだとか、シェルスクリプトで\がシェルとアプリケーションの両方で解釈されるから\\\\と書かなければならないだとか、elsifラダーは最初のif(2文字)とそれより後elsif(5文字)で条件文のカラムがずれるから見にくいだとか、長い変数名だと式が見辛くなるから略語を使うだとか、桁数の多い数を3桁ごとに区切りたいけど','は使えないから'_'を使うだとか、このコメントは改行が少ないから見にくいとか、ばかばかしいです。
そんなことに頭を悩ませる前に必要最小限の記述能力を持った文法を作って(あるいはそれすらいらないかもしれない)DOMを準備して、見栄えは使う側や見る側に任せてセマンティクスの整備をしてほしいです。どうせ書きやすい上に見やすい文法なんてできっこないんですから。
そういう意味ではxmlをプログラミング言語のベースとして使うのは決っして悪いことではありません。文法は単純でパーサーは比較的作りやすいですし、木構造が表わせますし。LISPでもいいんですけどね。
Re:争点 (スコア:1)
Re:争点 (スコア:1)
> XMLらしくないというのは同意ですが、醜いというのはスタイルシートでどうとでもでき得ることでは。
> いいかげんモデルとビューを分けるべきです。
発言が矛盾してますよ。
> 統合開発環境がビットマップディスプレイ上に見やすく整形して表示すればいいだけの話です。
> 見栄えは使う側や見る側に任せて
…どうしろと。
Re:争点 (スコア:1)
「生のXMLの文法がプログラミング言語に向いていないのでXMLでプログラムを書くアプローチは酷い仕様である」
ということに対する反論、さらに
「逆にスタイルシートを使うことを前提とすればXMLでプログラムを書くことは多くのメリットがある(『メリットはほぼ皆無』などではない)」
ということです。
>発言が矛盾してますよ。
いや、XML部分(モデル)はアルゴリズムを記述するのに専念してソースの読みやすさなどのビューの部分はスタイルシートで調整しろという意味です。
現状ではソースコードにアルゴリズムとソースコードの見栄え(インデントとか)の両方がごっちゃに書かれていて直交していないので片方だけを変えるのが難しくなっています。indentなどのツールで多少は変えられますがあまり自由には変えられません。
文法も人間が読みやすくするために複雑になっていて簡単には解析できません。
それを解決する方法を次の段落で質問への回答と共に示します。
>…どうしろと。
例えばたいていの統合開発環境は構文を見て色やフォントを変えます。さらにはブロックを折りたたんだり、関数宣言などをリストアップしたりもできます。
別の例としてC言語をテキストエディタで直接いじっている状態では複雑な数式でも
sqrt((x + y)/y * sqrt(a))
という風にしか表示されませんでしたが、Mathematicaでは√記号や分数表記を使ってきれいな数式として表示してくれます。
他にもUIデザイナでは
form1 = new Form(); form1.add(new Button("ok"));
のようなコードを実際のボタン付きウインドウとして表示して、それにマウスを使ってウィジェットを追加するとコードの方も自動的に変更するようなものもあります。
それを発展させて統合開発環境がWebブラウザのようにスタイルシートをサポートすればよいのです。ソースを書いた人は自分の見やすいと思うスタイルシートを指定しておきます。面倒くさければ特別指定せず、統合開発環境のデフォルトスタイルシートに任せます。ソースを見る人はそのスタイルが気に入らなければ自分でユーザースタイルシートを適用すればいいのです。
例えばこんな感じです。例としてXSLTとCSSを考えてみます(検証していないのでちゃんと動く保障はありません。あくまで雰囲気です)。
call-template {
display : inline;
}
call-template:before {
display : inline;
content : attr(name) "(";
}
call-template:after {
display : inline;
content : ")";
}
with-param {
display : none;
}
with-param:before {
display : inline;
content : attr(name) " = " attr(select)
}
with-param:before + with-param:before {
content : ", " attr(name) " = " attr(select)
}
とすると
<call-template name="foo">
<with-param name="a" select="10"/>
<with-param name="b" select="20"/>
</call-template>
が
foo(a = 10, b = 20)
と表示されます。
これが気に入らない人は
[foo a:10 b:20]
と表示させることも簡単です。
CSSでは単純なことしかできませんが、XSLTや(未だ存在しない)もっと強力なスタイルシートとそれをサポートした統合開発環境を使えばもっとすごいことができます。<lt><op>a</op><op>b</op></lt>をa < bと表示したりもできます。逆にa < bと入力すると<lt><op>a</op><op>b</op></lt>と構文木に追加したり、マウスを使ってコードを操作したりと入力も高水準なユーザーインターフェースを使ってできるようになるでしょう。もうインデントはスペース2つか4つか8つかタブ1つかなんて気にしなくてすみます。型名の最初にTがついているのが気に入らなければそれを表示しないようにして変わりに緑のテキストで表示させるようにすればいいのです。row_indexという変数名が長くてみづらいと思ったらiと表示させたり幅の狭いフォントで表示させたりできます。貧弱な文字集合の中で何とかするために<<->>とか:+:とかいった変な記号列を考え出さなくてすみます。LISPは括弧だらけでやだとかの不毛な争いをしなくてすみます。より良い文芸的プログラミングができます(というか文芸的プログラミングはこういうのが前提か)。
また、XMLは簡単にパースしたり構造をいじったりできるのでソースコードに対する操作も簡単です。特定の条件に合う関数定義
Re:なんというか (スコア:1)
Re:なんというか (スコア:1)
「XMLらしくないというのは同意」と最初から言ってまして、問題はXMLをベースにしたプログラミング言語が良いかどうかです。
Re:なんというか (スコア:1, 興味深い)
ずいぶんもりあがるもんですねぇ。なんだか重箱の隅という気もしますが。
## この分ならdefpatternなんて出したら、もっと大騒ぎされそう。
面白いから続けてみましょうか。
実は、私も、deftableを考えるときに、
1 ... <item><key>K</key><val>V</val></item>
2 ... <item>K V</item>
3 ... <key>K</key><val>V</val>
4 ... K V
の場合を検討してみた記憶があります。
3はまず最初に却下されることになりました。
XPathのツリーモデルでも何でもよいので、deftableの内容モデルを木構造で考えて
見ます。すると、key要素とval要素が内容モデルでリストとしてぶら下がっている形になります。
S式で書いたほうがよければ、((key . K)(val . V)...)みたいなイメージかな。
属性リストの変形みたいな感じですね。この方式のメリットは、せいぜいK, Vに型情報を
与えることができるぐらいなんですが、それなら、1のほうがよほどメリットがあるでしょう。
1, 2は、ほとんど連想リストと同じ構造です。
4は、ほとんど属性リストと同じ構造をしています。
そういうわけで、まぁ、はじめは1がよいかなと思ったわけです。
で、1で実際のテーブルを書いてみました。数千個の漢字テーブルを作って
みたところ、サイズが大きく膨れ上がってしまいました。
(XMLを採用した時点で、そんなことは諦めろとかいわれそうですが。)
ただ、deftableは、deftableは偶数番目と奇数番目の型がすべて一致する必要が(実装のために)
あるので、正直なところ1は冗長な気がします。また、keyにはidentity constraintが必要なので、
さらに、ここで一つ一つに型情報を入れたところで「正しい」deftableを構築する役には、
XMLとしての情報がそれほど有用とはいえません。結局のところ、PCEL定義の型情報を
必要としてしまうのです。
すると、一番シンプルな4を採用してもそれほど問題はないだろう。なにしろ、属性リストは
何年も利用されているリスト構造です。また、空白でリストを作るのは別にXMLでは非常に
一般的な方式で、コンセンサスも十分に得ている表現でしょう。
というわけで、4をとりあえず実験的に採用しました。
異論はあるでしょうけど、これはそれほど悪い判断でしょうか?
ちょうど偶数個を強要するリスト構造は気持ち悪い?
とはいえ、こういうパターンは、RELAX NG tutorialでも例に
挙げられているんです。
まぁ、こういう空白によるリスト構造は許せないという人はいるんですよね。
「XMLで文字列内に構造を作る」というのは確かにad-hocな側面もあります。
(RELAX NGでも、少々ややこしい扱いになってますし)
実のところ、私はそういう人の気持ちもわからないでもないです。でも結局、
重要なのは、コンセンサスを得た利用方法かどうかということですね。
「XMLらしい/らしくない」というトピックは、すさまじくcontroversialであることは、
某標準化団体を見ていれば疑問の余地はないでしょうね。
ところで、実用的な面からも、4にはdrawbackがないわけではないですね。
何だと思います?
そういうわけで、今どうするかと聞かれれば、keyやvalを属性で表現することを
選びそうです。<item key="" val=""/>というように。
from himi
Re:なんというか (スコア:1)
Re:ああいえばこういうですか？ (スコア:1)
しかし、そこまで実装にこだわるのならば部分的ながら実装をいくつか。
JEX [sourceforge.net] JVM用のプログラムをXMLで書けるようにしたものです。javaからのデコンパイラが開発中です。
Meta Environment [www.cwi.nl]言語の文法とセマンティクスを記述したり、それを使ってプログラムを評価するシステムです。プログラムは文脈自由文法のプログラミング言語からATermというツリー形式に変換されます。XMLとして出力することもできます。
また.NETではC#, VB.NET, JScript.NETとCodeDOMとコモンランゲージ間で相互変換を行うことができます。
>まあ醜い云々は仕様の良し悪しを決める要素の一つに過ぎないでしょうし、他の要素を考慮に入れて判断する必要もあるかもしれません。あるいはそもそも本当に文法的に醜いのだろうかという疑問もあるかもしれません。ですが、少なくともここまでのところ、あなたはそれらについては何も言及していません。
XMLの生の文法がプログラミング言語として醜いかどうかは人と場合によります。私がXSLTのスタイルシートを書く場合はemacsのxml-lite-modeのおかげもありストレス無く記述できます。XSLT1.0のセマンティクスの不備から来るストレスはありますがXMLであるということに起因するストレスはありません。しかしXMLで複雑な数式を書くのは骨が折れそうです。そして読むのはもっと骨が折れるでしょう。まだ使ったことのないXML専用エディタを使えばまた良いのかしれませんが。
そして文法が人と場合によっては醜いという点がスタイルシートによって制御できる以上仕様の良し悪しは別の要素によります。そしてXMLを使うことの利点は何度も言っているようにXMLならば簡単に扱うことができるという点です。lispやCodeDOMやATermなどの同等のものでも良いのですが。
Re:ああいえばこういうですか？ (スコア:1)
図言語としてのUML2において、UML表記はUML MOF
モデルの1表記法にすぎず、他にテキスト表現もある。
UMLのアクションセマンティクスはセマンティクスのみが
定められた言語でシンタックスはベンダが独自に決めていい。
古くはlispのM式とS式のちがいみたいなもんで、
新しいアイデアでもない。金物表現ってのもあったな。
AppleScriptは日本語でも表記できるんだっけ。
XMLをその種のモデルの交換形式に用いるのも
ごく自然な考え方だ。
しかし、その交換形式にスタイルシートを適用するで表示できるとか、
emacsのxmlモードで手で編集するだのは、
いいアイデアとはぜんぜん思わない。
XMLを隠蔽した専用の編集モードがあるならいいけど、
そうなるとXMLであることがなんなのか。
DOMで操作できることがそれほど便利かにゃ？
交換形式としてはXMLが便利だけど、
それは当たり前の話じゃない。
Re:なんというか (スコア:1)
PCELの仕様が良くないこと自体は同意しています。
しかしPCELの仕様が良くないことの根拠としてXMLであることが上げられている点へは同意していません。そこに反論しているだけです。私が擁護しているのはXMLやそれと同等のものをベースにしたプログラミング言語(や環境)です。
Re:ああいえばこういうですか？ (スコア:1)
そういうのがあるとアスペクト指向的なことも簡単にできてしまいます。
emacsのxmlモードなどはあくまで例で使う側が勝手に使いやすいものを使えばいいです。そして使いやすいものを選べるというのが利点です。
ある人はXMLを直接扱いある人はXMLを完全に意識せずに使うことができます。
また、スタイルシートは表示だけでなく入力系も制御できる(スタイルシート言語の仕様と実装によりますが)ので完全にXMLを隠蔽することも可能です。
Re:ああいえばこういうですか？ (スコア:1)
その編集が元のツリーに反映されるようなものはありますか？
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を使う」ということの意味が意味不明だけどね。
Re:争点 (スコア:0)
まぁ、そのXMLでしか Language Engine が記述できないという訳ではないのが救いですね。
Re:争点 (スコア:0)
Lispの括弧がタグになったようなもんでしょ。
宣言型/関数型言語には十分適用可能と思います。
ただ、手続きフローを書こうとすると発狂しそうになりますな。
Re:争点 (スコア:1)
> Lispの括弧がタグになったようなもんでしょ。
> 宣言型/関数型言語には十分適用可能と思います。
あ、なるほど。それは気づきませんでした。関数型言語にはなじみがないので。
まあ、苦労はしましたがXSLTは良い経験だったと思います。
# Schemeは一時期やろうとしたけど挫折orz
あと、見直してみるとEIMILもLisp風の匂いがしますね。tとかnilとかあるし。
どちらにしても酷いという評価には変わりませんが…。
Re:争点 (スコア:0)
Re:争点 (スコア:0)
適当に書いてすみません。
以前uimに近いところにちょこっと関わっていたんですが、uimの中の人って「IIIMFはアピールが上手で、Redhatなどの事情を知らない欧米人は騙されているんだ」「奴らはソースも汚いが、やり方も汚い」的なことを平然と口にするので、なんだかなあと思ったことがあります。
中心メンバーはそれで良いんでしょうけど、ユーザから見た
Re:争点 (スコア:1, 参考になる)
で、IIIMFのセキュリティ話については前にtabataさんが日記に書いていたのですが、「IIIMFについては変換エンジンと組み合わせるのが難しいということが私にとって主張すべき内容であり、セキュリティに関しては正確な議論に進めることが難しいので消しています。」 [srad.jp]ということで消されています。「変換エンジンと組み合わせるのが難しい」というのもいまいちよくわからないのですが、過去のコメントを見てみると、おそらく「変換エンジンの作者として、クライアントサーバ方式によってもたらされるオーバヘッド(マルチユーザ対応によるデータ構造の複雑さ、各個人のデータの安全な保存やアクセスの手間)に耐えることができずにuimの開発もやっています。」 [srad.jp]のことなのだと思います。
Re:争点 (スコア:0)
のリンク先に飛んでいって iso-8859-1 で FireFoxがレンダリングした瞬間
「コレはダメだ」と感じました。
分かり辛いたれこみですね。 (スコア:1, すばらしい洞察)
分かる人にだけ分かればいいのだろうけど、もうちょっと範囲を広げる記事を書いてもらえると助かります。
Re:分かり辛いたれこみですね。 (スコア:4, 参考になる)
とりあえずリンク先にあった説明を抜粋。
uim: 「uimは現在開発が進行中の多言語入力ライブラリです」
uim conference: 「uim conferenceは、uimを中心とし、そこに隣接するレイヤのソフトウェアの開発者の方々の発表により、フリーな文字入力環境に関して理解を深める事を目的としたカンファレンスです」
anthy: 「Anthy はフリーでセキュアな日本語入力システムです」
prime: 「PRIME は POBox のような予測入力システムです」
m17n-lib: 「汎用多言語ライブラリ」
タレコミも親コメントも言葉がひとつ足りないんだよな…。
Re:分かり辛いたれこみですね。 (スコア:2, すばらしい洞察)
ただ、/.j界隈だと、知らない専門用語に出会うと
嬉々としてググるひとたちのほうが多いと思うぞ。
Re:分かり辛いたれこみですね。 (スコア:1, 興味深い)
しかも、それぞれにWMやアプリケーションとの相性があったり、
ディストロ側でも力の入れ具合が違っていたり。
選択肢があるのは良い事ですが、時に「何でもいいから一本化してくれ」と
思うこともあり。
#自分が今どれで入力しているのか分からなくなることもしばしば。
Re:分かり辛いたれこみですね。 (スコア:0, オフトピック)
正直どうかと思う。
Re:分かり辛いたれこみですね。 (スコア:1)
MOD PARENT UP (スコア:0)
親コメントは丁寧な言葉で、いい所ついているじゃないですか。
「XIM にかわる InputMethod」なんて本当に解る人にしかわからない文章ですし、「覇権を争っている(?)」という言葉遣いは何か争点があるらしいことを仄めかすだけで説明しようともしていないですね。せめて「覇権を争う」をリンクにして典拠を示すべきでした。
Re:MOD PARENT UP (スコア:0)
「解る人にしかわからない」のは当たり前ですね。
少なくともコメントを書く人は日本語を入力しているのですから、「解る人」でしょう。
Re:MOD PARENT UP (スコア:0)
分からない事は自分で調べるなり、質問するのが筋かと。
# タレコミがわかんねーよ ではなくて
そもそも人によって前提知識が違うんですから、どこに合わせるかはタレコミ人なり編集者の判断ですし
Re:MOD PARENT UP (スコア:0)
Re:分かり辛いたれこみですね。 (スコア:0)
某巨大掲示板が、ということですか:-P
Re:分かり辛いたれこみですね。 (スコア:0)
あなたのリテラシー不足。
「ほっちゃん」でも「2ch ほっちゃん」でもそれなりの結果は出ましたよ？
Re:分かり辛いたれこみですね。 (スコア:0)
インターネットというか、hacker文化ですな。
向上心無い人は技術開発の場からは排除されます。
Re:分かり辛いたれこみですね。 (スコア:0)
など聞きたい事はいろいろあるけどどうせ「ぐぐれ」で終わるんだろうな。
とりあえず「技術者として大切なスキルとしてコミニュケーション能力が
ある」とだけ言っておこう。タレコんだ目的にもよるけど誰かに伝えるのが
目的なら想定される相手のレベルに合わせた説明も必要だよね。
# 聞き手の努力を求めるだけで書き手については不問と
Re:分かり辛いたれこみですね。 (スコア:1, 興味深い)
コミュニケーション能力が大切であることに異論はありませんが、それは技術力に代わるものではない、と指摘します。
引用はSE本などに多用される文句ですね。単に読者を満足させる商売文句なだけなんですが、真に受けて技術力も向学心も無いことの言い訳に使う似非技術者が多くて困ります。
まぁ、純粋に技術者を使うだけの人間なら、コミュニケーション能力だけで渡るのもいいと思いますよ。でも技術自体について発言するならやはり技術力は必要なのです。
>タレコんだ目的にもよるけど誰かに伝えるのが目的なら想定される相手のレベルに合わせた説明も必要だよね。
想定される相手のレベルに合わせてませんか？
簡潔によくまとまってると思いますよ。
理解できないということは相手の説明が悪いんじゃありません。
むしろ、想定されるレベルに達してないという明らかな証拠です。
こんな明らかな証拠を前にしながらなお自分が想定内であると思い込むのは、呼ばれてないのにパーティに来るようなもので、相手の意図を察するという「コミュニケーション能力が足りてない」と言えるでしょう。
Re:分かり辛いたれこみですね。 (スコア:0)
むしろ「ある程度のレベルで書く事によって、ワケの分からん奴が来るのを防ぐ」という努力をしたのかもしれないよ？ ；）
プログラ
Re:分かり辛いたれこみですね。 (スコア:0)
いちばん上で「すばらしい洞察」もらってるアホに言ってやったら？