tenjuu99(天重誠二)'s avatar

tenjuu99(天重誠二)

@tenjuu99@hollo.tenjuu.net

200 following131 followers

読書、プログラミング、登山、ランニング、美術など いろいろ雑につぶやいています SPACE NOBI というアートスペースやっています

@tenjuu99@hollo.tenjuu.net · Reply to tenjuu99(天重誠二)

アレグザンダーは、アーキテクトと施工の分離をアンチパターンだと考えていた。一貫したデザインランゲージをいくつかの層に設けて、それらのランゲージによって、外形的表現と内部的表現が均衡を保つことが重要だとおもっていた。それは日本の施工習慣とはおおきくぶつかってしまったけど。

@tenjuu99@hollo.tenjuu.net · Reply to tenjuu99(天重誠二)

すくなくとも、この言論は一般的なソフトウェアデザインの方法論で聞いたことはないです(もちろんマルチパラダイムデザインもこのようなことは言っていません)。自分がこの議論で参照しているのはアレグザンダーです。

@tenjuu99@hollo.tenjuu.net

んー...。例えばいま念頭に置いているのはUMLのようなものではないし、OpenAPIもおなじ誤ちをおかしているとおもう。コードからデザインが一貫してみちびきだされるというようなことではなく、重要なのはパターンとデザインであり、それは星座をみつけだす行為である。

@tenjuu99@hollo.tenjuu.net

実装と外形的な表現に必然的な関係がアプリオリにある、といいたいわけではなく、そこに関係を作るのがパターンであり、デザインであると。これはある種の過剰な思想であることは認めるけど、外形的表現と内部表現が互いに自由であるというのは原則的にそうできるというだけのことで、それが良いデザイン指針であるとは思わないということです。

@tenjuu99@hollo.tenjuu.net

「実装は制約として機能してしまう」は、自分がそう主張したいわけではなく、「実装とデザインが切り離されると」という主張を敷衍するとそうなるということですね。ひとつには、このパターンは典型的には実装者とデザイナーの担当者の分離として現れる。この場合実装者にしか無い知識というのはデザイナーにとってはデザイン上の制約として現れる。

@tenjuu99@hollo.tenjuu.net

「そこに必然性がない」ところに関係性を構築する行為がデザインだと、ほぼそういう主張です。むしろそれこそがメタファーの機能。

@pokarim@fedibird.com · Reply to pokarim

もちろん実装者の都合とし一貫したメタファーに貫かれていることやパターンが入れ子状に現れるものは、実装とコードの関係性がわかりやすくイメージしやすいという意味で良い性質ではあり得ると思う
だけどそこに必然性はない

@tenjuu99@hollo.tenjuu.net

もうちょっと言うと、一貫したメタファーに貫かれていることは良いデザインの指針であるとアラン・ケイは考えてメッセージング/オブジェクトというパターンを考えたし、パターンが入れ子状に現れるものが良いデザインだとアレグザンダーは考えた。 ソフトウェアデザインの場合は、実装とデザインは切り離される(べきとする)言説が多くて、こういう分離のパターンはアレグザンダーなら避けたものだと思う。この場合、外形的なものの設計に対して、実装は制約として機能してしまう。 外形的な構造と内部の構造でパターンが入れ子状になっている場合、そのシステムを把握することは容易になるのはたしかだとおもう。

@pokarim@fedibird.com

内部のコードと外部の振る舞いを結びつけているのは実装者であるプログラマの先入観にすぎない

@pokarim@fedibird.com

内部でステートマシンを使っていたとして外部に現れる挙動がいかにもステートマシン的なものだったとしても、内部のコードを外部的な振る舞いとしては等価な別の記述に置き換えることが常に可能であるのがソフトウェアであると思う

@tenjuu99@hollo.tenjuu.net · Reply to tenjuu99(天重誠二)

たとえば、内部でステートマシンを使って、その現れとしてもステートマシンで表現して、みたいなことを考えれば、そういうことは実現できる。そこに反映関係をもたらすようなコードを書くことはたぶんできる。

@tenjuu99@hollo.tenjuu.net

UIと内部的なコードが偶有的関係でしかないと考えるのはどうなのかな。 というかそのように設計することができる(コードとUIを切り離して設計することができる)ようにデザインの方法論自体が発展してきているというべきじゃないかと思っていて、内部のパターンを外部のパターンとして流用するようなことは考えられる。

@pokarim@fedibird.com · Reply to pokarim

(もちろん開発環境や言語処理系といったソフトウェアについてはその限りではない)

@pokarim@fedibird.com · Reply to pokarim

自分を含むプログラマはいままでOOPとか関数プログラミングとかマルチパラダイムデザインとかについて学んで議論することに時間を費やしてきてそれには必要性があったんだけど、それらとソフトウェアのデザインの間にはほとんど実質的な関係はない

@pokarim@fedibird.com · Reply to pokarim

UIとソフトウェアは必然的な結びつきを持っていて、ソースコードとソフトウェアの間にはそのような結びつきがありそうで実はない

@pokarim@fedibird.com

ソフトウェアにおけるソースコードは絵画における画材やキャンバスのような素材もしくはそれを使って形作られたものに見えてしまいがちなんだけど実際はそれとは大きく違う

@tenjuu99@hollo.tenjuu.net

ソフトウェア批評が成立するとしたら、外形的な現れのなかに一種の内在的論理を持っていると仮定して記述が進められるはずだけど、デザインの方法論そのものが、ソフトウェア構築のロジックと現れ/見た目とかを分離しようとする・分離できるとする記述が多い。

@seki_takanao@fedibird.com

ポッドキャストを聞いていたら、ハル・フォスターが、エドワード・サイードに惹かれてコロンビア大学に行ったと話していた。へえー、と。フォスターたちの世代は『スクリーン』誌を熱心に読んでいて、フェミニズム批評が自分たちの世代にとって非常に重要だったという話も印象的。
アーティストが理論に関心がないからといって、作品が理論的ではないというわけではなく、芸術がそれ自体でいかに理論的であるかを示し、理論が芸術に影響を与え、芸術が理論に影響を与え、その緊張関係から新しい思想や実践が生まれる方法を見いだすことに、フォスターは関心があった、とも。フォスター、いいこと言っている。

@pokarim@fedibird.com · Reply to pokarim

批評がなにかいまだに何もわからないけど、ソフトウェアをゼロからせっせと生み出そうとすると自前で探索と提案と分析と批判を繰り返しながらやってくしかなくて、そこに素朴なかたちの批評のような何かが含まれてるんだと勝手に思ってる

@pokarim@fedibird.com

ソフトウェアにはデザイン批評が欠落してるって The essence of software にはっきり書いてあった

@tenjuu99@hollo.tenjuu.net