「将来しなくても良くなるコーディングテクニック」記事へのコメント

codingそのものが無くなるんじゃないの？

[June Co. (27038)]

オブジェクトをお絵かきソフトのように組み合わせればもうソフトウェアの完成・・・って時代が来るのかと思ってたけど，先は遠いのかなぁ。

# アセンブラのようなANSI C codingから未だ離れられないロートルより

Re:codingそのものが無くなるんじゃないの？

[Anonymous Coward]

Max/MSPとかYahoo Pipeみたいな方向性はどうですか？

(てきとうにぐぐったYahoo Pipeの絵→ http://chikura.fprog.com/PIX/1208233725_blogsearch.png [fprog.com] )

これが便利かどうかは、モンダイの形態に依存します。
上記はUNIX PIPEの延長みたいなものでして、
つまり入力→処理→出力を数珠繋ぎ「すれば解決できる」ような形態のモンダイに特化しています。
そういう問題なら解けます、そうでないならまたヨソを当たってください、と。

入れ子、つまり複数の部品とその配線の組み合わせを新たな部品として登録する仕組み、があれば、
それなりに大規模化もできますし。

UNIX PIPEとの違いは、入出力が複数ありえる(ノードごとに自由に用意できる)って点ですね。
しかも、それこそビジュアルに作るスタイルであることのメリットを最大限いかして、
どのアウトとどのインを繋ぐか？をビジュアルに表示＋操作できるようになってます。
そのぶんスケーラビリティ(大規模化やコーディング量当たりのラクさ)は犠牲になるかも知れませんが。

>オブジェクトをお絵かき

「オブジェクト」(今言うOOPとかのことだとして)の厳しい点は、
なんでもかんでもオブジェクトだと強弁できてしまう点です。
上記のように「ある用途というかメタ形態に限ればヤレル」というケースと
どう折り合いをつけるかが、色々悩みどころです。

まあそれこそフレームワークなので、
それ(たとえば上記だとPIPEスタイル)用のクラスを作ってそのサブクラスをユーザが描く、
というルールにすればある程度はいけますけど。

いずれにせよ、
与えられた問題がそのフレームワークの合うかどうか「判断」したり、
許容できる範囲で問題をフレームワークに合わせるよう「変形」したり、をするのは、
やっぱり人間の仕事ですね。

>codingそのものが無くなる

それもまたcodingだ、というだけのことだと思うし、思いたいです。

思いたいというのはなにかというと、
現状のように人間(だけ)可読なDOCを偉い連中が無責任に書き散らし、
それを機械可読に翻訳する(翻訳可能かどうかも不明なのに…)、
という無理難題を押し付けられるのがいわゆるコーダーである
というスタイルは、どうにかなってほしいんで。

EndUserComputing(苦笑)は、理想的にいえば、
偉い連中が書いたDOCがそのまま機械可読になる、という世界でしょう。
ということは、
その書き散らしにどれくらい論理的穴があるかが機械的に測定(=バグ出し)可能だ、ということです。

つまり「論理に穴が有るのの責任を書いた奴がとってくれ」ってことです。

ただ、そういう時代になってもどうせ、
「このDOCの穴をふさいでくれ。ただし論旨はいっさい変更せずにな！」
というやっぱり無理な命令を下す偉いやつらは
絶滅しないだろうなとも想像されますが。