« 2010年12月 | トップページ | 2011年3月 »

2011年1月25日 (火)

リアルタイム処理の重要性

人生において「すぐに行動する」ということの重要さはいくら強調してもいい。
そして仕事においても「その都度リアルタイムで処理する」という行為の重要性
も同じように強調していい。
リアルタイム処理というのはバッチ処理よりも本質的に優れているのだ。

バッチ処理の方が単純で処理しやすいが、多くの欠点を持っている。
リアルタイム処理は複雑で処理が難しいが、多くの利点がある。

リアルタイム処理においては処理をするエンジンがとても重要になる。
人間においてはそれは概念セットや思考法や感覚などの内面的な
ソフトウェア全般を指す。
これらソフトウェアがリアルタイム処理のエンジンとなる。

リアルタイム処理の能力は常に研鑽し続けることが必要だし、
その見返りは必ずあるので、その価値があるといえる。

リアルタイム処理はフローを扱うが、バッチ処理はフローを一端ストックに
変換して、ストックを処理する。

フローをストックに変換せずに処理をして出力をするのがリアルタイム処理である。

ストックを別のストックに変換するのがバッチ処理だ。

人間に例えると、同時通訳がリアルタイム処理の例で、翻訳家がバッチ処理の例だ。

ジェイソン・ボーンを見れば分かるように、極限の状況ではリアルタイム処理以外は
役に立たない。

| | コメント (0) | トラックバック (0)

2011年1月10日 (月)

コメントへの返答

VBAは便利なのですがVB6の遺物のような気がするのですが。プログラミングも.NETになれるとVBAはあかぬけない感じがしてきて使いづらいし、.NETとVB6が平行して残るのはマイクロソフト的にサポートや開発効率に無駄が多い気がしますが。VBAは将来.NET系に移行していくのではと思うのですが。意見をききたいのですが

VBAは確かに.NETへの移行にとってはレガシーな資産であり問題と言えます。

ただし、MicroSoftはVB6ランタイムのサポートを継続しており、
VBAのサポートも今後も続けるでしょう。

.NETは Windows Phone 7 などのスマートフォン環境の言語環境として
本領を発揮するでしょう。
この領域はネイティブコードでない方が望ましいからです。
そして現時点でまさにそのように使われています。

VBAの問題はその言語仕様の特異性が最大の問題であると言えます。
実はVBAは言語としてはかなり強力なのです。

●VBAの言語仕様の特異性
1.VB6とほぼ同じシンプルな言語仕様
2.Win32APIに透過的にアクセス可能なので高度なアプリが作れる
3.VB6とは異なりコンパイルの必要がない
4.Office内にランタイムと高度な開発環境が含まれる
5.Officeの普及度による高いポータビリティ
6.フォームビルダーによるGUIアプリの構築容易性
7.膨大なマクロ資産があり現在も増大中

もしOfficeが.Netのアプリケーションとして配布されるようになった場合は、
VBAから脱却することになるでしょう。

Officeの.Net化は現時点でも可能でしょうが、MicroSoftがそれを実行するかは
微妙だと思われます。

.Netの実行形式は逆コンパイルによってコード内容が把握される可能性があるからです。
そうなった場合、Officeのコードが公開されることになってしまいます。

そのリスクをMicroSoftが犯すかどうか。微妙です。


●予想
1.MicroSoftはOfficeを.NET化しない
2.VBもVBAもサポートされ続ける
3..NETはスマートフォンの分野で本領を発揮する

まあこんなところですね。

| | コメント (0) | トラックバック (0)

2011年1月 3日 (月)

ハードウェアに密着した言語

ハードウェアを制御できるプログラミング言語こそが最も強いはずだ。

私が思い描くのは、ターミネーターに出てくるサイバーダイン社の技術のイメージである。

あの会社の技術を映画の中で詳細に見ていくと、ハードウェアとソフトウェアとが
完全に融合していることが分かる。

現時点ではそれはC言語ということになるが、Cではサイバーダインは無理だろう。

C++でも駄目で、Objective-Cならばなんとかなるかもと感じる。

なぜObjective-Cは組み込みに使われないのだろうか?

やはりISOやANSIやECMAの標準になっていないのが痛いのだろう。

Cに置き換わるハードウェア層を制御できる高級言語の出現は間違いなく
人類の歴史に大きな影響を与えるはずだが。。。

かといってGO言語やD言語はあまり流行る気配がない。

| | コメント (0) | トラックバック (0)

MVCは死んでいる

WebアプリケーションにおけるMVCパターンはすでに死んでいる。
ページが静的なHTMLから動的なJavaScriptを使用したページになり
状態を保持するようになった時点でMVCパターンは崩壊したのだ。
しかもそれはAjaxを使用することで余計に加速された。

Ajaxを多用するということはページが単なるViewではなく、
オブジェクトになったことを意味する。

サーバー側にもモデルというオブジェクトがあるのだから、
結局はオブジェクト同士の相互作用というのが実態に近い。

MVCとは一つのオブジェクトを3つの部分に分割するというパターンである。
複数のオブジェクト同士の関係については何も言っていない。

このオブジェクト同士の相互作用のパターンというのが現時点でも
未解決のデザイン問題として残っている。

これはかなり複雑な領域であり、容易にモデル化を許さない。
しかも相互に参照しているのではなく、相互に作用しているのである。

実は通常のGUIアプリケーション全般においてMVCは通用しないのだ。
それらは全てオブジェクト同士の相互作用のデザインの問題となる。

| | コメント (2) | トラックバック (0)

2011年1月 1日 (土)

ユニークオブジェクトの概念

システムに必ず1つのみ存在するオブジェクトをユニークオブジェクトという。
ユニークオブジェクトはただ1つのみ存在し、そしてそれ以上増やすことはできない。
生成も消滅もせず、そしてその影響はその言語の全領域に渡る。

だからユニークオブジェクトはそのプログラム言語内のパラダイムからは
ちょっと異なる存在になっている。

ただしこの場合のシステムという言葉の定義は曖昧で、OSであったりVMであったり
あるいは特定のシステム領域であったりする。

ユニークオブジェクトはプログラマが定義することは無く、
最初から存在しているとみなされる。

ExcelのVBAではWorkbookはユニークオブジェクトであり、
JavaではSystemクラスはユニークオブジェクトの例だ。

ユニークオブジェクトが特に繊細な問題として現れるのは
マルチスレッドでユニークオブジェクトにアクセスする場合だろう。

ユニークオブジェクトはプログラマが自身で定義した存在ではないため、
マルチスレッドでの取り扱いについ油断してしまう時がある。

最悪はそれがデッドロックになって現れる。

ユニークオブジェクトは明示的にスレッドでアクセスされることが
わからない場合がある。

デッドロックのバグは最悪で原因不明のハングとなって現れることが多い。

そのような場合はユニークオブジェクトにスレッドがアクセスしていないかを
確認するのも有効な検証方法の一つだ。

| | コメント (0) | トラックバック (0)

オブジェクト指向とオブジェクトという言葉の混乱


・オブジェクトとデータ
状態を持つ対象をオブジェクトという。
状態を持たない対象をデータという。

・オブジェクト指向とデータ構造
オブジェクト指向言語のデータ構造はツリー構造となる。
オブジェクト指向言語がツリー構造になる必然性は無いが、
人間にとって扱いやすいデータ構造のためであろう。
オブジェクト指向とRDBの最大の違いはオブジェクトとデータの
対立にあるのではなく、データ構造の違いにある。
それはツリー構造とテーブル構造の違いである。
RDBは最小単位は状態を持たないデータを格納するが、
テーブルはそれらの集合として状態を持っているためオブジェクトとなる。
ただしオブジェクト指向言語におけるツリーの階層が複数階層が普通
なのに対して、RDBのテーブル構造の階層は1階層のみなので現状では
RDBの方がかなり単純なデータ構造となる。
RDBが複数階層のテーブル構造を実現しないのは人間にとって複雑すぎるからだろう。

・状態指向と生成指向
一つのオブジェクトの状態変化によって対象を表現するか、
それとも複数のデータを生成することで状態を表現するのか
という違い。
後者のスタイルもオブジェクト指向言語には取り込める。
後はどちらが人間の認識にとって自然かという問題になる。
生成指向は関数プログラミングと言われている。
両社は発想が全く異なる。
生成指向では予め生成しておけば状態変化のコストが無くなる。
ただしそのためのメモリを多く必要とする。
状態指向では(以下略)。

| | コメント (0) | トラックバック (0)

« 2010年12月 | トップページ | 2011年3月 »