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

tenjuu99(天重誠二)
@tenjuu99@hollo.tenjuu.net
200 following131 followers
読書、プログラミング、登山、ランニング、美術など いろいろ雑につぶやいています SPACE NOBI というアートスペースやっています
- SPACE NOBI
すくなくとも、この言論は一般的なソフトウェアデザインの方法論で聞いたことはないです(もちろんマルチパラダイムデザインもこのようなことは言っていません)。自分がこの議論で参照しているのはアレグザンダーです。
んー...。例えばいま念頭に置いているのはUMLのようなものではないし、OpenAPIもおなじ誤ちをおかしているとおもう。コードからデザインが一貫してみちびきだされるというようなことではなく、重要なのはパターンとデザインであり、それは星座をみつけだす行為である。
実装と外形的な表現に必然的な関係がアプリオリにある、といいたいわけではなく、そこに関係を作るのがパターンであり、デザインであると。これはある種の過剰な思想であることは認めるけど、外形的表現と内部表現が互いに自由であるというのは原則的にそうできるというだけのことで、それが良いデザイン指針であるとは思わないということです。
「実装は制約として機能してしまう」は、自分がそう主張したいわけではなく、「実装とデザインが切り離されると」という主張を敷衍するとそうなるということですね。ひとつには、このパターンは典型的には実装者とデザイナーの担当者の分離として現れる。この場合実装者にしか無い知識というのはデザイナーにとってはデザイン上の制約として現れる。
「そこに必然性がない」ところに関係性を構築する行為がデザインだと、ほぼそういう主張です。むしろそれこそがメタファーの機能。
もちろん実装者の都合とし一貫したメタファーに貫かれていることやパターンが入れ子状に現れるものは、実装とコードの関係性がわかりやすくイメージしやすいという意味で良い性質ではあり得ると思う
だけどそこに必然性はない
どこからどこまでが迷信とされているのかがわからなかった
パターンは星座みたいなもので、偶有的に見える関係のなかに形態を見出すことだと言ってもいいとおもう。
もうちょっと言うと、一貫したメタファーに貫かれていることは良いデザインの指針であるとアラン・ケイは考えてメッセージング/オブジェクトというパターンを考えたし、パターンが入れ子状に現れるものが良いデザインだとアレグザンダーは考えた。 ソフトウェアデザインの場合は、実装とデザインは切り離される(べきとする)言説が多くて、こういう分離のパターンはアレグザンダーなら避けたものだと思う。この場合、外形的なものの設計に対して、実装は制約として機能してしまう。 外形的な構造と内部の構造でパターンが入れ子状になっている場合、そのシステムを把握することは容易になるのはたしかだとおもう。
この思い込みのことがパターンですよね
内部のコードと外部の振る舞いを結びつけているのは実装者であるプログラマの先入観にすぎない
内部でステートマシンを使っていたとして外部に現れる挙動がいかにもステートマシン的なものだったとしても、内部のコードを外部的な振る舞いとしては等価な別の記述に置き換えることが常に可能であるのがソフトウェアであると思う
たとえば、内部でステートマシンを使って、その現れとしてもステートマシンで表現して、みたいなことを考えれば、そういうことは実現できる。そこに反映関係をもたらすようなコードを書くことはたぶんできる。
UIと内部的なコードが偶有的関係でしかないと考えるのはどうなのかな。 というかそのように設計することができる(コードとUIを切り離して設計することができる)ようにデザインの方法論自体が発展してきているというべきじゃないかと思っていて、内部のパターンを外部のパターンとして流用するようなことは考えられる。
(もちろん開発環境や言語処理系といったソフトウェアについてはその限りではない)
自分を含むプログラマはいままでOOPとか関数プログラミングとかマルチパラダイムデザインとかについて学んで議論することに時間を費やしてきてそれには必要性があったんだけど、それらとソフトウェアのデザインの間にはほとんど実質的な関係はない
UIとソフトウェアは必然的な結びつきを持っていて、ソースコードとソフトウェアの間にはそのような結びつきがありそうで実はない
ソフトウェアにおけるソースコードは絵画における画材やキャンバスのような素材もしくはそれを使って形作られたものに見えてしまいがちなんだけど実際はそれとは大きく違う
これめっちゃ気になるな... https://www.kaiho.mlit.go.jp/03kanku/kouhou/jcgm_yokohama/
デザインという言葉の適用範囲が、内側から分裂しているのがすでにめんどくさい。
デザインが内在的なロジックから導出されるのではなくて、偶有的なものであるならば、批評が成立する余地はたぶんない。
ソフトウェア批評が成立するとしたら、外形的な現れのなかに一種の内在的論理を持っていると仮定して記述が進められるはずだけど、デザインの方法論そのものが、ソフトウェア構築のロジックと現れ/見た目とかを分離しようとする・分離できるとする記述が多い。
ポッドキャストを聞いていたら、ハル・フォスターが、エドワード・サイードに惹かれてコロンビア大学に行ったと話していた。へえー、と。フォスターたちの世代は『スクリーン』誌を熱心に読んでいて、フェミニズム批評が自分たちの世代にとって非常に重要だったという話も印象的。
アーティストが理論に関心がないからといって、作品が理論的ではないというわけではなく、芸術がそれ自体でいかに理論的であるかを示し、理論が芸術に影響を与え、芸術が理論に影響を与え、その緊張関係から新しい思想や実践が生まれる方法を見いだすことに、フォスターは関心があった、とも。フォスター、いいこと言っている。
批評がなにかいまだに何もわからないけど、ソフトウェアをゼロからせっせと生み出そうとすると自前で探索と提案と分析と批判を繰り返しながらやってくしかなくて、そこに素朴なかたちの批評のような何かが含まれてるんだと勝手に思ってる
ソフトウェア批評宣言... うっ頭が
ソフトウェアにはデザイン批評が欠落してるって The essence of software にはっきり書いてあった
Why designing in code makes you a better designer https://adamsilver.io/blog/why-designing-in-code-makes-you-a-better-designer/

adamsilver.io
Why designing in code makes you a better designer
Adam Silver – interaction designer - London, UK

