{希哲15年5月の一日一文}{抽象画}{パソコン音痴}{モノ}{大きな壁}{具象性}{悪い意味}{一日一文}{相性が良い}{立体階層構造}...=}(91)

{デライトはなぜ“抽象的”なのか K#F85E/A-E74C-AECA}

デライトに触れた多くの人が,デライトは“抽象的”だと言う。それもそのはず,我々認知しうる物事関連性徹底的抽象化することにより,あらゆる物事の関連性を一つの原理で捉えられるようにしたのがデライトの基礎にある「輪郭法」なのだから。

日常的会話の中で「抽象的」と言うと,捉え所が無いとか曖昧といった悪い意味に受け止められることが多い。しかし,抽象化という能力は,数学はもちろん,情報工学世界でも無くてはならないものだ。

工学における抽象性は,「汎用性」に近い意味を持っている。個別のものに共通する性質を取り出し,それらを一つの仕組みで捉えられるようにする。これが上手く出来ないと,論組プログラミングすら難しい

……などと御託を並べても,実際問題,デライトを多くの人に使ってもらうには,この抽象性が大きな壁であることに変わりはない。抽象的に物事を捉える能力には個人差が大きく,それも得意だという人の方が珍しい。当然ながら,これは市場戦略上の課題になる。

これを上手く解決する方法があるのか,実は開発者の中でも答えは出ていない。探せばあるのかもしれないし,結局無いのかもしれない。無いとしても,この抽象性がデライトにとって必要なものなら,無理にでも壁を乗り越えるしかない。


デライトは,これまで勘報機コンピューターでも多く利用されてきた単純な階層構造ネットワーク構造限界を越えるべく開発されたものだ。

特に「フォルダ」などとして広く使われている階層構造は,抽象性反対具体性具象性)と非常に相性が良い。いくら欠点があっても,人類が階層構造から離れられなかった大きな理由だ。

個人機(PC)の普及に大きく寄与したのが「デスクトップ メタファー」であったように,具体的モノ同士の関係として表現した方が多くの人は理解しやすい。その一方で,具体的なモノにはモノゆえの限界がある。

我々は,頭の中で多くの概念を縦横無尽に結び付けている。A にも B にも含まれている C という概念を頭の中では当たり前に扱えるが,フォルダのような物理的入れ物 A と B に同時に入っている C というファイル想像することは難しい。

こうした限界を越えようと様々な技術が開発されてきたが,フォルダのような“具体的”表現に頼っている限り,どうしても不自然で気持ちの悪いものになってしまう。「パソコン音痴」な人は,Windowsショートカットですら実体と区別出来ず混乱してしまうことがある。

それならいっそのこと,こうしたメタファーを廃してしまった方がいいのではないか。デライトの設計はそんな考えに基いている。だから,モノに喩えるのではなく,頭の中を直接表現した抽象画のようになっている。これをデスクトップならぬ「マインドトップ(mindtop,念頭と表現したこともある。

下図のように,デライトにおける「輪郭」は,視点によって一つの中身を共有出来る入れ物になっている。立体階層構造とでもいうべきこの構造を「輪郭構造」と呼ぶ。

この輪郭構造が,階層構造とネットワーク構造を統合し,真に人間の認知機能調和するものになっている。大分長くなってしまったので,これについては後日改めて解説しよう。

=}
{ハイブリッド式}{遊画用語}{割り切り}{Markdown 研究}{Dex::buf_T}{buf_T}{デライトの AutoPagerize 対応}{希哲15年3月13日}{HTML 部区}{次ページ}...=}(79)

{希哲15年3月13日の開発 K#F85E/A-E74C-AE84}

デラング整備,特に Dex 実装作業没頭した。

28時までかけ,何度も書き直した Dex_T基本設計が一応の完成をみた。

模動応付を持てるバッファbuf_T)のスタックを中心に,模動切り替えながら処理振り分けていく。これにより部区入れ子も上手く扱うことが出来る。

最初はこのバッファを HTML 部区抽象化したものとして扱おうとしたが,杓子定規にすると非効率に,効率的に扱おうとすると不自然な部分が出てくるため,あくまで作業用バッファと割り切り柔軟に使えるようにした。

Dex::buf_T というのも語呂が良く,遊画用語っぽくて面白い


デラング研究一環として Markdown 研究も進み,Markdown利点欠点がよく見えてくるようになった。特に欠点の部分に関しては,最近 Markdown.pl をざっと読んでみて,技術的制約もあっただろうと推察する。

希哲前2年2004年)の Perl といえば,ちょっとしたサブルーチン呼び出しコストすら考えなければならない言語で,そこまで複雑なことは出来ない。

今の C++ 相当)に比べて,その遅さは軽く100倍を越えるだろう。

当時における見通しの良さ効率性バランスをとった結果が Markdown だったわけだ。


ある描出をきっかけに,デライトの AutoPagerize 対応を考え始めた(10歩)。

デライト上でも AutoPagerize検索してみるといくつか言及があった。

もともと無限スクロール導入は考えていたが,用合い広告SEO の様々な懸念から現状の全知検索ページャーになっている。

実際に試してみると,やはりこれはこれで便利で,検索演心でもあり SNS 的でもあるデライトにはハイブリッド式が向いていると確信した。

最近,次ページ輪結を押すとその場で追加されるという折衷案を考えていたが,これを体験すると中途半端霞む

独自の無限スクロール導入した場合,この種の拡張機能干渉しないように対策も考えておく必要がある。

{自我アイコン}{希哲15年1月4日の開発}{img.icon}{希哲15年1月4日の進捗時限}{希哲15年1月4日の進捗}{希哲15年1月4日}{相振り}{領当て}{進捗記録}{進捗時限記録}...=}(26)

{希哲15年1月4日3歩 K#F85E/A-E74C-ADE3}

自我アイコン実装続き。

途中で終了。

自我アイコンの URIKNEST抽象化するという案はスクリプト相性が良いため,相振り側で URI を出力するのではなく img.icon などとしてスクリプト側で展開してしまうことにした。

と思ったが,現状,自我アイコンが領当てに与える影響はほぼ無い(上位の a 要素高さを指定)ため img 要素 すら必要ないかもしれない。

=}
{希哲14年8月27日}{希哲14年8月27日のツイスト}{検索結果がリストになるようにする}{箇条書き}{粒度}{司組}{デライト}{輪郭}{ツイスト}{一覧性}...=}(21)

{あれK#F85E/A-5B28-8005}

検索結果がリストになるようにする」というのは私の感覚に近いです。輪郭というのは,箇条書きでいうところのビュレット抽象化したもの,という見方も出来ます。

現時点でもうちょっと一覧性をよくしたいとかデライト側の課題もありますが,デライトのような司組を突き詰めていけば,手書きリストの役割は限られてくると思います。例えば,順序範囲を一覧とは別の基準で固定したい時などですね。

ただ,デライトでは自分の頭の中の連想関係を自然に描き出していけばいいので,最適な粒度は人それぞれになると思います。最初は大雑把にまとめて,後で分割していく,ということもしやすいように設計しています。

=}(1){あれ}
{函数化}{希哲13年12月29日}{希哲13年12月29日のツイスト}{交度}{ツイスト}{考え方}{見通し}{再利用性}{抽象化}{コード}...=}(12)

{あれK#F85E/A-5B28-43C3}

あと,「函数再利用のためにあるもの」という考え方もちょっと語弊がある。一箇所からしか参照されない函数でも適切な粒度であれば見通し抽象化に貢献するし,そもそも再利用性というのは,交度コード)を分割していく過程で気付いたりするものなので,函数化出来そうなものは片っ端からするくらいでいい。

=}
{希哲13年12月29日}{希哲13年12月29日のツイスト}{出場}{DGDBI}{概念化}{柔品開発}{デライト開発}{KNEST}{ツイスト}{物作り}...=}(16)
{最適化}{希哲13年10月13日のツイスト}{希哲13年10月13日}{輪郭}{ツイスト}{操作}{精度}{体系化}{行動}{世界}...=}(14)
{柔品}{「テクノロジーとリベラル・アーツの交差点」}{あれ}{希哲13年9月14日のツイスト}{希哲13年9月14日}{初代 iPhone}{ソフトウェア}{Apple}{デライト}{テクノロジーとフィロソフィーの結合}...=}(14)

{あれK#F85E/A-5B28-B34A}

久しぶりに「テクノロジーとフィロソフィーの結合」という言葉を書いて改めて思ったが,いま私がやりたい事は,「テクノロジーとリベラル・アーツの交差点」と言っていたジョブズ時代の Apple をもっと抽象化したような企業の創出なのだろう。デライトが目指すべきはやはり柔品ソフトウェア)における初代 iPhone みたいなものか。

=}
{抽象化}
{}