無差別に技術をついばむ鳥

私はずっと前から既存言語と進化の方向性にある違和感を感じていました。それは、言葉にし辛いものです。開発は「オブジェクト分析→オブジェクト設計→オブジェクト指向言語で実装」の流れで作業が進みます。その実装段階でその違和感は強いものとなります。どこで感じるのかをもっと具体的に書けば伝わりやすいのでしょうが、契約上それを提示する事は出来ません。非常にもどかしいものです。
最近はアスペクト志向という概念がオブジェクト指向を補完する形で登場し、既存の「オブジェクト指向言語」がそれを属性などに定義され、それでも足りないものはメタデータとしてコンセプトなどの形で実装されております。しかし、元を正せばプログラミング言語の予約語はコンパイラに対するメタデータです。メタデータと一言で言っても色々あり、それら全てをコンセプトや属性などの形で行うのは乱暴すぎるやり方に私は思えてなりません。既存の予約語を見直してみると、「表現力不足なだけじゃないのか？」と感じるところが多々あります。そのうちの一つがアクセス修飾子です。
知らない人が居るかもしれませんので軽く説明しておきます。アクセス修飾子とは、型のメンバの可視性とアクセス制御に関するルールです。アクセス修飾子が比較的多い.NETのMSILの例を挙げますと、private、family、family and assembly、assembly、family or assembly、publicがあります。これらのアクセス修飾子を考えてみてください。アセンブリと継承に終始しているのが分かってもらえると思います。でも改めて定義を良く見てください、「型のメンバの可視性とアクセス制御に関するルール」はその程度のキーワードで実現できるのでしょうか？
オブジェクト設計を行った人ならば実感していると思うのですが、メンバの可視性は継承だけではなく関連もあります。アクセス制御に関するルールについても、見えるor見えないではあまりに杜撰です。アクセス制御とはセキュリティを伴うものであり、そのほかにも色々な要件があります。ルールが見えるor見えないの2択だけならばシステム構築は簡単でしょう。しかし、そのルールがそんなに単純じゃないから皆苦しいのです。その分実装で苦労せねばなりません。それが楽しい時もありますが、誰しも楽になりたいときがある筈です。
またもう一つの事に私は気付きました。メンバといっても、クラス、プロパティ、メソッドなどの要素は全て共通のアクセス修飾子です。私はこれに納得できません。アクセス制御のルールがクラスとメソッドで同じという発想はオブジェクト指向ではなくプロセス思考の考え方では無いでしょうか？オブジェクト指向が優れた技法と呼ばれているのは、今まで開発されたプロセス指向とデータ指向を包含する優れた概念だからです。クラスとメソッドが同列でいいのならばオブジェクト指向はなりたちません。それにも関わらず共通のアクセス修飾子である現状は非常に不満です。この2つのアクセス修飾子は別に扱うべきです。
では、別に扱うと何の利点があるのでしょうか？それは色々ありますが、一言で表現するのならば、クラスやメソッドの特性をより詳しく記述できる点です。もともとある共通項的なアクセス修飾子では表現できなかった事が簡潔に記述できるのです。これは無限の可能性を秘めております。でもそれはただの序曲にしか過ぎません。アクセスという概念をもっと深く考えれば、現在の見えるor見えないという単純なものではなく、もっと広い可能性がそこにあります。
これらから先PCは搭載プロセッサ数が飛躍的に増えるでしょう。また、セマンティックWebなどの分散環境の進化があるでしょうし、他にも色々な可能性があります。そうなれば、どの様にアクセスできるクラスかという点が非常に重要になります。そのほかにも、セキュリティ技術の向上の為には誰がアクセスできるクラスかなどの情報も不可欠となります。その時、現在の不完全オブジェクト指向言語では非常に私は心細いです。私も一応プロなので、今まで何とかしてきましたが、これからもこれらの開発対象の進化を考慮すれば、これらからも仕事を達成できると断言できません。この状態はオブジェクト指向言語が誕生した時や構造化プログラミングが提唱された時期を連想させます。構造化プログラミングの必要性が叫ばれた時GoTo有害論が激論されました。オブジェクト指向が提唱された時も構造化プログラミングで十分だと言う意見が多くありました。両者の言い分はもっともです。Goto有害論にしても機械語マスター達にはありえない話しです。オブジェクト指向反対派のハッカー達も、オブジェクト指向言語でなくともどのようなものでも作れます。しかし、全ての開発者が機械語や非オブジェクト指向言語の神にはなれません。そこで平均値を上げる必要があります。それが構造化プログラミングであり、オブジェクト指向なのです。
昨今のプログラミング言語はラムダ式の追加などの関数型言語の機能の追加が目立ちます。私はLISP好きですし、プログラミング言語の表現力UPは大歓迎です。しかし、アクセス修飾子などの一見単純な既存概念を見直さなくていいのでしょうか？灯台下暗しと思うのは私だけでしょうか？機能の追加に躍起になるのではなく、少し立ち止まって落穂拾いする必要があると私は考えます。

　うーん。メンバのアクセス制御が共通で困ったことがないのでいまいち後段の論旨が掴めないです。具体的に困るケースってどんな感じなんですか？
　むしろ凪瀬さんが http://blogs.wankuma.com/nagise/archive/2009/01/07/165863.aspx で書いているような「アクセス制御がクラス内で閉じている」問題のほうが大きい気がします。オブジェクトの群は表現できるのに群のアクセス制御が出来ないのは片手落ちですよね。
　前段の「表現力が足りない」の部分は後段で述べられる部分以外は同意でホルダクラスからのみ参照可能なアクセス制御とか任意のレベルを設定できるアクセス制御とか夢は広がる一方なんですが、言い出すとキリがないので現状で我慢の方が却って平和かもしれないとも思います。
　多分この話題鬼門だなーｗ

MSILはnativeにおけるアセンブラ(機械語)なんだからアクセス修飾がショボいのはアッタリマエ。
private/public以外はすべてコンパイル時にprivate/publicのどちらかに倒すんだから。

高位の言語レベルで論じないと意味ないんとちゃう?

エントリとは少しずれる内容ですが。

人のブログではピヨピヨ読みづらい書き方しといて、自分のブログではまともな文体ってのはどうなんですかね。
普通逆じゃないですか？

とりあえず、やりたいことは COM+ の role-base access control みたいなこと？

これなら、interface 単位で access control できますからね。

> とりあえず、やりたいことは COM+ の role-base access control みたいなこと？
そのようですね。でも、COM+は勿論Kernel/Device Driver/Subsystem(Framework等を含んで言ってます)は言語からは独立しているものだからそれらを*使わずに*言語で何とかしようとしているんじゃないかな？

ある言語で作られたApplication内で閉じている話ならキーワードを増やされても「使う」「使わない」は実装者次第なので別にいいけど、「言語」が「実行環境」に機能を要求するのであればC/C++では無理な話ですね。OSの無い環境もありますし。

みんな有難う♪意見を頂けると嬉しいです♪
まず、MSILを選んだわけですが、それはC#やC++/CLIよりも多いからです。
アクセス修飾子が多い言語でも足りないという点を指摘したかったのです。
それで、アクセス指向な考えはどこで必要になるかという点なんですが、同期処理などで重要となります。
どのオブジェクトがどのタイミングでどのようにアクセスされるのかを考える事により、クラスの要求を明確化できます。
私はプログラミング言語とは思考ツールだと思うのです。
それが正しく認識されていないから、設計は偉いという誤解が蔓延していると私は感じています。
あと、見えるor見えないという簡単なルールでObject間の関係を定義できるとは私は思わないのです。
そんなオブジェクトの構成は単純なものではなく、
もっと多くの情報を含むべきです。
その様な情報がないから保守時に困るのです。
それに、その様な情報があればよりコーディングが強力になります。
コーディング力を強化して設計を動かすのが私の望みです。
私はとにかく言語に強力さを求めます。
だからLISPとC++が大好きなのです。
C++は細かい単位での制御が魅力的です。
その細かさをもっと言語は追求するべきです。
それを追求する事によりより高い生産性を得られます。
一見細かさと生産性は結びつきませんが、言語は既に開発環境を意識して作る時代になっていますので、逆に細かい情報があるからこそ高い生産性が開発環境によりもたらされるのでは無いでしょうか？

最後に組み込み系のプログラミングの事なんですが、それについては現段階で使えなくてもハードウェアの進歩により可能なんでは無いでしょうか？

　情報が多いとあとで見て助かるのは確かなんですけど。情報をたくさん管理するとミスが増えるから記述しない (正しくは隠す/隠しやすくする) 方向に進化してるわけで。。。
　それと組み込みの話はパワーの問題ではなくC++では思想的に言語自身で完結できない事情を持ちたがらないと言う話ですね。

あおいたん。そうだよね。
C++の場合は思想的にそういう面もあるし、だからこそボクも好きなんだよね♪
C++のアクセス修飾子は増えて欲しいけども、もしそれが不可能ならば違う言語でもいいとボクは考えているピヨ。
それにしても、管理の大変さから逃げるのは本当に言語の進化のためになるのかな？
管理の煩雑さから逃げているという指摘はその通りで、今までの技術ではそれしか無い部分もあるよね。
ただ、現在はもう逃げなくてもいい技術があるとボクは思うんだよね。
現にボクは研究の副産物で、製品ジェネレータを作ってしまったから、その技術力があれば何とかなるんだよね。
ボクに出来るならばハッカー達に出来ない理由はないよね？

仮にC++でアクセス修飾子を増やすとすれば・・・
ボクならば・・・
「名前空間アクセス修飾」
「クラスアクセス修飾子」
「メソッドアクセス修飾子」
「プロパティアクセス修飾子」
「インスタンスアクセス修飾子」
「コンセプトアクセス修飾子」
とかかな？
これぐらいならば実装される可能性はあると思うピヨ。

この点逆に聞きたいのですが
> 最後に組み込み系のプログラミングの事なんですが、それについては現段階で使えなくてもハードウェアの進歩により可能なんでは無いでしょうか？
どのような進歩を指していますか？
高速化？大容量化？
上記の様なプロセス技術に伴う進化で解決するならi7やPhenomに同様な技術若しくはそれに向かっていると思われる技術は実装されていますか？
高速化や大容量化により現在OSの無い環境にOSを載せる事が可能になったとしてもそれはOSによって補われる機能であり言語とは別ですよね？
（大容量化はCPUコアとは関係ないけど）
また、CPU以外のハードという話であればデバイスドライバを経由することになり、これも言語レベルでは対処しようがないことになると思うのですが？

インドリさんがどれかひとつ言語を例に挙げて、その言語にどのようなキーワードを追加すればどのように良くなるかという具体例を出すと理解が得やすくなると思います。

たとえば「メソッドアクセス修飾子」
いまある public/protcted/private とは
意味が異なるんですよね?

たとえばどんなアクセスを制御するんすか?

あんどちんさんへ
ボクは組み込み系をした事が無いので思わず聞いてしまいました。
なので少し現場の意見とずれるかもしれませんが、ボクが知っている限りの範囲で頑張って答えます。
ボクが読んだOSやトランザクションの名著では、ハードウェアには高度なCPUが付属していき、記憶容量も急激に上がると書いてありました。
さらには現在のOSと同等のOSが搭載される可能性も十二分にあるそうです。
それで、組み込み形にしても現在のPCの様に、今では考えられないぐらいのハードウェアの進歩が生じ、現在のPCと大差ないぐらいに（下手すればそれ以上に）進化するのではないかと推測しました。
そうなると、現在のPCで実装可能だとボクが思うアクセス修飾子ぐらいは何とかなると考えたのです。
真実と違ったら教えてください。
言語については頭が整理されていないので書くのは長すぎるのでちょっと待ってください。


επιστημη #さんへ
C++ハッカーのεπιστημη さんから質問が来ると嬉しくもあり同時に緊張しています。
C++についてεπιστημη さんほどの知識を持ち合わせていないので、おかしな点があったら優しく突っ込んでください。
ボクが現段階で想像したメソッドアクセス修飾子は大体以下のものです。


一、どのような資格（コンセプトで記述）を持つクラスから呼び出し可能なのかを表します。例え子クラスであっても資格の条件を満たさないクラスからは呼び出せません。これは、あるクラスを緩い条件で公開したいけども、危ないメソッドは厳重にしたいなどの要望がある時使います。
こうする意味は、自分が予期しないクラスが親クラスとして自身を定義して欲しくない状況や、便利なクラスの一部メソッドを使用したい状況があるが、だからといってクラスのフル機能を使用して欲しくない状況などに対応するためです。
あと、自社専用のクラスのメソッドをアドレス指定などで無理やり呼び出せない様にしたいと感じた時必要だと思いました。


一、どのような状態の時呼び出せるのかを記述します。例えば、あるフィールドのインスタンスの初期化が成功している場合呼び出せるとか、インスタンスの状態がある一定の条件を満たす時のみ起動できるとかです。
C++でプログラミングしている時、うっかり不適切なタイミングでクラスが保持するフィールドを開放した時だとか、厳重なテストをしている際に必要だと感じました。


一、並列処理に関する情報。そのメソッドがどのようなリソースにアクセスするのかだとか、並列処理について考えられて設計されているかなどの情報です。


現在のところ直ぐに思いつくのはこの3点です。
メソッドアクセス修飾子の方向性としては、メソッドはプロセス（機能）なので、機能のアクセス可能性、可視性およびそのレベル、起動条件、実行の並列性、アクセスするリソースなどに情報を明示するものだと考えております。

コンパイル時に確定しない要因に基づくものは基本的に却下。
# コンパイル時にチェックできんからｱｯﾀﾘﾏｴ。

なのでふたつめは×。みっつめはｸﾞﾚｲっぽ。
ひとつめはｱﾘに思えるけど、アクセス修飾じゃない形で実現できそうな希ガス。

επιστημη さん返信有難うございます♪
非常に嬉しいです♪


>コンパイル時に確定しない要因に基づくものは基本的に却下。
# コンパイル時にチェックできんからｱｯﾀﾘﾏｴ。

このことについてそれに関連した質問があります。
仰る通りなので2番について変更します。
少し冗長な表現となりますが、チェック関数を併せて記述
アクセス修飾子　関数名
の様な形式にして、コンパイラがメソッド呼び出し時の場所へ自動的にコードを指定関数のコードを埋め込む事は実現可能でしょうか？

できるとしたらどんなコードになるんでしょ。
例示してくださいな。

先ず、PCだろうとスパコンだろうと組み込みだろうと言語の提供するアクセス修飾子を使うという事に大差ないと思います。

プロセス技術の向上でCPUの速度と搭載メモリの増量は可能なので組み込み環境へPCと遜色ないOSを載せる事は可能ですし、それは先の発言でも述べた通りです。PC+PC用OSで開発されたシステムでも「組み込みシステム」に含んで語られるものもありますし、組み込みLinuxやWindows Mobile(Windows CE)やEmbedded Windowsを使用している機器も既に沢山ありますね。
ただ、OSが載ってプロセス間通信にアクセス制限をかけたり、MMUの機能を使用してプロセス内スレッドの違反アクセスに対して例外を出すことが出来るようになったとしてもそれは「OSを経由して提供される機能」をAPIなりを使って使用しているだけなので、それを言語の拡張機能として追加するくらいならAPIを使えばよいでしょう。そのようなことで言語を使用できる環境を制限する利点が感じられません。OS用にフレームワークを提供すれば済むと思います。
# どれだけCPUの速度が上がろうがOSの使用を嫌う場合もありますが

先の書き込みはインドリさんの主張があくまでも言語の枠の範囲内だと思いましたので、あのように書いた次第です。OSの有無は主旨ではありませんが、誤解を招く書き込みをしてしまったことは申し訳ありません。
例えば、
Winodws/Linux/Mac OS/T-Kernel(ITRON)/OS無し
こういった異なる環境であってもC/C++であれば実行環境に対しての制約が無いから開発は可能ですし、言語思想がそうなっています。故にC/C++に対して実行環境を制限するキーワード追加はありえないと思った次第です。それにC/C++の場合、OS開発でも使用される言語ですし、その言語がOSのある環境を要求するのはおかしいと思います。

特定環境用コンパイラの独自拡張なら有り得るかもしれませんが（C++/CLIのようなものになるのかな？）、それならヴェンダーが独自にやってもいいと思います。使用する必要が無い場合独自拡張機能を使用しなければよいだけですから。

蛇足ですが、CPU自体は速度が上がり（特定処理の速度向上のための）命令も増えています。そして扱うことが可能なメモリ量も増えていますが出来ること自体はこの数十年それほど変わっていないと思います。結局は演算してるだけですから。
# 勿論20年前のCPUでH.264のHD動画をリアルタイム再生するのは無理ですけど、それを実現したのは上記要因です
x86仮想CPUの連載もされているインドリさん相手なので、釈迦に説法かもしれませんが（僕はx86に疎い）、x86系で言うと今後の進化もマルチコア化とSIMD命令の追加・高速化のような方向になるのではないでしょうか？メモリアクセス制限は純粋なCPUコアではなくMMUの機能ですし（x86のプロテクトモードだとCPUコアとも言えるのかな）、セキュリティ的に追加されたのはNxビット程度ではないでしょうか？但しNxビットもデータ領域実行を禁止するだけでインドリさんの望むアクセス制限を実現するものでは無いでしょう。Ring0〜3による保護はアプリケーション開発においては関係ないですね。アプリケーションはRing3で動作しますし。
AMD-VやIntel-VTによるヴァーチャライゼーション拡張も仮想マシン内の高速化を促すので、各実行環境を独立した仮想マシン内で動作させればセキュリティ上効果がありますが、これも言語外での話ですし。
このことからインドリさんが指摘する機能をCPUを含めて考える必要は無いと思います。あくまでも言語の枠の中で語らないと話が分散して収集がつかなくなりますし。

> 言語については頭が整理されていないので書くのは長すぎるのでちょっと待ってください。
気長に待ってみます

あんどちんさん返信有難うございます♪
仰る事はよくわかります。
確かに言語としては不適切かもしれませんね。
その辺も含めてよく考えて見ます。


>気長に待ってみます

有難うございます。
このネタは情報処理技術的に面白いので、アクセス指向として考えて書いて見ます。
お楽しみに♪

επιστημηさんへ
επιστημηさん相手にC++のコードを書くのは非常に緊張します。
頑張って書きます。
ボクが想像しているのは次のコードです。

//定義部分の抜粋
class Foo {

private int i;
public int get_field() { return i; }

checkFunction IsBar() {
if ( get_field() < 0 ) throw new ZeroException();
}

public < checkFunction IsBar > void Method() {
//省略
}

}


//コンパイル前のコード
fooObj.Method();

//コンパイル後のコード
if ( fooObj.get_field() < 0 ) throw new ZeroException();
fooObj.Method();


こんな風に自動的にチェックプログラムをコンパイラに生成したいと考えております。
発想としてはテンプレートかマクロです。

> どのような資格（コンセプトで記述）を持つクラスから呼び出し可能なのかを表します。

その「資格」というのをコード上にどう表現して、どう担保するんですか？　自己申告じゃだめですよね。

> 自分が予期しないクラスが親クラスとして自身を定義して欲しくない状況

閉じた環境ならともかくとして、親クラスを不特定多数が使うライブラリとして公開する場合、どのように「予期」するんでしょうか？

> 自社専用のクラスのメソッドをアドレス指定などで無理やり呼び出せない様にしたい

極論、コンパイル後のコードが x86 のマシン語で書かれている以上、そのアドレスに jmp してやればどんなチェックもかいくぐれると思いますが、それも阻止できるんですか？

コードが制御すべき領域、実行環境が制御すべき領域、ドキュメントが制御すべき領域、チーム管理が制御すべき領域というのが各々あるのに、全部コードで何とかしようという発想にしか見えません。

public void Method() {
　IsBar(); // ここに一行追加
　...
}

ではダメなんですか?

その構文を必要とする理由がわからんす。

> その構文を必要とする理由がわからんす。

記述不足で済みません。
こうする理由は・・・

１、子クラスが呼び出す保証が無い。
２、共通した処理を纏められます。例えば、Method2、Method3も同じチェック処理をする場合、チェックコードを共通化したほうがいいです。
３、チェックコードと本体の記述を別にした方がコードの可動性がアップする場合があります。

>コードが制御すべき領域、実行環境が制御すべき領域、ドキュメントが制御すべき領域、チーム管理が制御すべき領域というのが各々あるのに、全部コードで何とかしようという発想にしか見えません。

その通りです。その発想で書いております。
偉大なるLISPハッカーのポール・グレアム氏が「コードは最大のドキュメントである」と主張しております。
私はその考えに大賛成です。
ドキュメント類とコードが結びつかないから知識が足りないSEが居る余地があるんでしょね。
そんなドキュメントさえ飾ればいいという考えは、職人気質の私は納得できません。
それに、コードにより制御する事により、様々な可能性が生まれます。
ドキュメントなどの情報分散状態では進化の道はありません。
よりコードがプロジェクトを制御するやり方を私は望みます。

あのさぁ。。。

「コードが制御すべき領域」とドキュメントが「制御すべき領域」だけで語られても。「その他の実行環境が制御すべき領域」はどこにいってしまったんですか？

そのことを分かってもらうために blog entry 立ち上げたんですが。。。

> よりコードがプロジェクトを制御するやり方を私は望みます。

一般的に作成される application って何らかの platform (OS, processor 等) にのっかったものが多いですよね。その platform にのっかっている以上、否が応でもその platform の影響を受けるわけです。

ということを突き詰めると、その platform に合わせたやり方が必要になってきます。そういう意味では coding は万能ではありません。

もっとも、platform まで理想化された環境を用意するというなら別ですがね。

ちなみにあったらいいかな？っと思ったこと

> 一、並列処理に関する情報。

これは結構イケてるかも。

> １、子クラスが呼び出す保証が無い。
> ２、共通した処理を纏められます...
> ３、チェックコードと本体の記述を...

今のままでもコーディングスタイルで対処可能
なので僕は要らん思います。

# 好みの問題なら平行線なのでこれでおしまい。
# アクセス制御とは何の関係もないのでやっぱりおしまい。

> > １、子クラスが呼び出す保証が無い。
> > ２、共通した処理を纏められます...
> > ３、チェックコードと本体の記述を...
>
> 今のままでもコーディングスタイルで対処可能
> なので僕は要らん思います。
>
> # 好みの問題なら平行線なのでこれでおしまい。
> # アクセス制御とは何の関係もないのでやっぱりおしまい。

了解いたしました。
話しに付き合ってくれて有難うございます。
επιστημηさんのお陰でより仕様が固まりました。
面白いコンパイラの機能を数多く思いつきましたので、今後作るネタ指向コンパイラに実装します♪

ちゃっぴさんへ返信。

>「コードが制御すべき領域」とドキュメントが「制御すべき領域」だけで語られても。「その他の実行環境が制御すべき領域」はどこにいってしまったんですか？

これはaetosさんに対する返信です。
もう一度aetosさんの質問と共に読んでいただければ分かると思いますが、私は制御するべき領域はプロジェクトの全てでという旨の返事を書いております。
ソフトウェア工学を改めて考えてみてください。
ソフトウェア開発を工業化するために様々な努力が行われております。
さらに言うと、UMLからコードを作るような例は枚挙に暇がありません。
これの技術は何を意味するのでしょうか？
全てをコーディング（コード）で行う、もしくは駆動するという事ではないでしょうか？
ソフトウェア工学を「誰でもソフトウェアを作くるための学問」だと考えていませんか？
そういった面はありますが、よく考えるとソフトウェア製作のプロたちが、制御するべき領域の拡大と、より効率化を図る方法論も考えられているのです。
ソフトウェアを工業化するにはこうするのがベストです。
技術者であるからには、より力を求める気持ちは同感していただけると思います。


>もっとも、platform まで理想化された環境を用意するというなら別ですがね。

それについては、既にSmalltalkを例に挙げていますし、「どんな手段を使ってでも生産性と制御性を上げる」と私は何度も言ってきたはずです。
しつこいようですが、私は技術者なので、より拡大と進化を目指しております。
それに、コンパイラ技術を少し考えてください。
私が書いてある事は、大半は既存のコンパイラ技術でが何とかなるものです。
私は自分のコンパイラ作成経験を元に出来る範囲で発言しております。
おそらく無いと思いますが、出来ない範囲はOS実装技術で何とかなる範囲のものです。
機械語の命令を直接扱う必要はありません。
違う言語でラップしてやる方法もあります。
それはcfrontやEiffelという実例があります。

最後に・・・
あんどちんさんから既に思慮深い「既存言語がやるべきことか。全ての処理系でその様なことをする価値があるか」という深い問題提起がなされています。
その事ならば、ネタつつきで考察していきます。
なんにせよ、知的遊戯だと思って気楽に楽しんで下さい♪

> ちなみにあったらいいかな？っと思ったこと
>
> > 一、並列処理に関する情報。
>
> これは結構イケてるかも。

有難うございます♪
より魅力的な事が出来ないか考えます♪

> UMLからコードを作るような例は枚挙に暇がありません。
> これの技術は何を意味するのでしょうか？
> 全てをコーディング（コード）で行う、もしくは駆動するという事ではないでしょうか？

え? UMLですべてを表現できるんですか?
UMLから吐かれたコードがいかに穴だらけか、ご存じではないのですか?
仕様記述言語がそれによってコードを吐くのが目的ではないのはご存じでしょう?
そもそもUMLってすべてを記述するためのものなんですか?

これに限らず、賛同/同意以前に理解が得られんのですけど...

> > UMLからコードを作るような例は枚挙に暇がありません。
> > これの技術は何を意味するのでしょうか？
> > 全てをコーディング（コード）で行う、もしくは駆動するという事ではないでしょうか？
>
> え? UMLですべてを表現できるんですか?
> UMLから吐かれたコードがいかに穴だらけか、ご存じではないのですか?
> 仕様記述言語がそれによってコードを吐くのが目的ではないのはご存じでしょう?
> そもそもUMLってすべてを記述するためのものなんですか?
>
> これに限らず、賛同/同意以前に理解が得られんのですけど...

いいえ。全部出来ないのでメタデータが足りないと主張している次第です。
しかしながら、現状はただ技術が未発達なだけで、方向性としては設計と実装の差異を如何にして埋めようかと色々工夫されているといいたいのです。

私の目標はポールグレアム氏が言っているようなコード＝仕様書の状態にしたいと言う事なのです。
この状態になれば無駄な動きはなくなります。
επιστημηさんのレベルともなると、設計は脳内に出来上がり、殆どの事はC++で解決できる事かと思います。
ですが現状ではそれを開発チームで共有できません。
実際のところチーム開発はハッカーの足をひっぱる状況が頻発しているでしょう。
επιστημηさんはきっと、チームが自分の能力に追いつかず、歯がゆい思いを何度もした事と思います。
例えば、先ほどεπιστημηさんが指摘したようにUMLは余りにも不完全であり、それに関連した開発ツールも未成熟なので、結局はドキュメントとコードの乖離は防げません。
こういった事が開発の生産性を落としています。
そのための方策として、既存の概念を発展し、プログラム言語のメタデータを充実させるしかないと私は思うのです。

でも「できるって言うならやって見せろ」って言うと「パクられるからヤダ」って言うんですよね。きっと。

> でも「できるって言うならやって見せろ」って言うと「パクられるからヤダ」って言うんですよね。きっと。

どこからその様な発言になったか分かりませんが、自分がこの文章から受けた印象に基づき真面目に答えます。
先ず最初に私は「ネタ指向コンパイラに実装してみる」と言っております。
私も一応仕事がありますので、コンパイラを直ぐに実装できるとはいいませんが、いつかは実装するつもりなのです。
次に何故そんな挑戦的な事を言われるのかがわかりません。
aetosさんは自分の特許や発明が盗られた事ありますか？
もしかしたら、aetos さんは全てが無料奉仕で良いと言う聖人君主なのかも知れません。
しかし、私は食事もままなら無いほどに困窮しているのです。
下手すれば餓死するかもしれません。
その状態の時に無料奉仕をしろと言われても素直に出来るでしょうか？
私が報酬を貰わずに何かの仕事をせねばならない理由はあるのでしょうか？
どこからその文章が出てくるのかは分かりませんが、もう少し丁寧な文章を書いていただきたいです。

× 聖人君主
○ 聖人君子

> しかしながら、現状はただ技術が未発達なだけで、

僕は違うと思う、いや断言する。
仕様を全部食わせればちゃんとしたコードを吐くだろう。
ところが"仕様を全部食わす"のはハンド・コーディングよりしんどいのだよ。

あなたが足りないというメタデータの量が半端じゃなく、コード書いた方がまだマシってこと。

また、それが可能だとしても誰がそんな大量のドキュメントを読める/書けるの?
仕様書から(完全な)コード吐くなんて愚策よ。

> もう少し丁寧な文章を書いていただきたいです。

ヒトのblogに主軸を無視して己の主張を書き散らすあなたに言われたくないなぁ。

# 少なからず腹立ててるのよ? わかる?

> > もう少し丁寧な文章を書いていただきたいです。
>
> ヒトのblogに主軸を無視して己の主張を書き散らすあなたに言われたくないなぁ。
>
> # 少なからず腹立ててるのよ? わかる?

申し訳ありません。そういうつもりはありませんでした。
以後気をつけます。

老婆心ながら
事あるごとに下記のようなことを書かれていますね、そのような目にあった事はありませんので（手柄を取られた程度ならあるかもしれませんが）お気持は察しかねますし、同じような目に合ってもどう受け取るかは人それぞれですよね。気に入らなければ削除する、無視するなどした方が荒れずに済むと思います。
# ここはご自分のblogなので好きな事を書かれても良いとは思いますが、少なくとも他所では無視した方が良いと思います。

> aetosさんは自分の特許や発明が盗られた事ありますか？
> もしかしたら、aetos さんは全てが無料奉仕で良いと言う聖人君主なのかも知れません。
しかし、私は食事もままなら無いほどに困窮しているのです。
> 下手すれば餓死するかもしれません。
そのような状況であれば暫くの間はまともに稼げる仕事をしながらプライベートで勉強した方が良いと思います。生活にゆとりが生まれなければ心のゆとりも生まれないと思います。
# 仕事でやるとしがらみをより強く感じますしね。2番目に好きな事を仕事にしろと言う人もいますし。

> その状態の時に無料奉仕をしろと言われても素直に出来るでしょうか？
こう書いてはaetosさんが書かれたことが当たっていると認めるのと同じになってしまいませんか？

偉そうなことを書いて申し訳ありません。

> 偉そうなことを書いて申し訳ありません。
いえいえ、滅相もございません。
仰る通りなので教えていただいたアドバイス通りにします。


>こう書いてはaetosさんが書かれたことが当たっていると認めるのと同じになってしまいませんか？
言われて見ればそうも取れます。
なので単刀直入に一言書いておきます。
【ネタ指向コンパイラで実装する予定です。】

トラックバックURL

FC2ブログユーザー専用トラックバックURLはこちら

re: interfaceに物申す(3) …

Access を制御するものはどこに置くべき？ …

Access を制御しているように見えても強度は異なる …