パスワードを忘れた? アカウント作成
12765927 journal
日記

dotkuwaの日記: 手続き型言語とエンタープライズ分野のイベント 1

日記 by dotkuwa

手続き型言語とエンタープライズ分野のイベント

エンタープライズ分野で最も必要とされるイベントは、
業務承認フローの処理です。
業務承認フローの処理とは、
・複数の同時に動く人間で、
・持ち寄った処理結果(いろいろ事務処理をした結果、
 それを元に次の処理をして良いという品質になった
 情報の集まり)を同期させる(実際にその値を元に
 次の処理を始める)
処理です。
 
さて、フレームワークで、宣言的で分かり易いとされて
いるものは(便利機能のツール集にとどまらず、枠組み
までサポートするタイプのフレームワーク)、
同期するイベントの数をごく制限しています。
だから分かり易く、宣言的(テーブル表現で全てを表現
出来るので一覧性に優れる)で書けるのです。
 
しかし、
業務承認フローで必要とされるイベントは、
・1つ1つが違い、名前を付けて区別すべき、1つ1つが
 (エンタープライズ分野では)第一級の存在。
・1つ1つが余りに違い、テーブル表現で書きにくい。
イベントです。
テーブル表現で書きにくい場合、関数表現で書く事も
し難いはずです。(表現出来る範囲が似ている為)
そうすると手続き型言語で(静的に)書くのが普通です。
 
前に、
手続き型言語は、
・たまたま同時に動く
・複数の
・計算(関数)の例示を
・並べた
言語です。
とも、
手続き型言語は、
・純粋な計算(関数)を並行/並列で実行する上で
 最も障害となる同期を、例示を並べて書く事で
表現している
とも、
書きました。
 
要するに手続き型言語の「手続き」とは、何を隠そう
「業務承認フロー」と表裏一体
だったのです。
 
よく、非プログラマーの方々が、
・「業務承認フロー」に関して、宣言的で分かり易い
 フレームワーク。
を聖杯の如くに探していらっしゃいました。しかし、
完全に全く何の成果も無かったと思います。
それは、その探し求めていた物が、手続き型言語と
(少なくとも)同等で無ければならなかった(今でも
そう)からです。
 
つまり、「業務承認フロー」を実装するには手続き型
プログラムを書く(か更に難しいプログラムを書く)
のが運命
なのです。テーブル表現で分かり易く、実装
まで可能というのは、理論的にペテンです。
テーブル表現では「業務承認フロー」に関しては、
ポンチ絵段階の別紙資料以上の表現力が欠落している
からです。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 業務承認フローの処理(
    ・複数の同時に動く人間で、
    ・持ち寄った処理結果(いろいろ事務処理をした結果、
     それを元に次の処理をして良いという品質になった
     情報の集まり)を同期させる(実際にその値を元に
     次の処理を始める))
    は、人間にとって容易です。その様な事は小学生(高学年)
    でも解ります。だから、熊をいくら動かして見せても
    心の底では軽蔑すると思います。
     
    ただ人間が容易に行う業務承認フローの処理には欠点が
    有り、(新聞のどこかに書いてありましたが)100が
    処理の限界だそうです。
     
    いやしくも「エンタープライズ分野」と呼ばれる為には、
    少なくとも万単位、IoTともなれば億兆以上になるので、
    その為に、エラい理屈を付けて熊を動かしているのです。
     
    ですので、将来100超の要素を扱う見込みの無い小学生
    にプログラムを教えるのは、当人にとっても良くない事だと
    思います。必修になっても、その辺は考慮すべきだと思い
    ます。

typodupeerror

UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア

読み込み中...