tenjuu99(天重誠二)

自分が一貫性の重要性を述べるのは、デザインの目的とは美だからだといいかえてもいいです。用具を作ることはデザインの目的ではない。

なんか話が食い違っているけど、どこで食い違っているのかはよくわからない。 建材とコードを類比的に述べていなくて、アーキテクトと施工の分離というのが類比としてあり、これは疑うべくもないことだとおもう。表層と施工の分離というのはある意味一般的なパターンそのもので、作業の構造の分解から来ている。アーキテクト(建築家)という存在が独立してあるのは、他方にゼネコンみたいなものがあったりする。この作業行程の分離パターンはソフトウェア開発でもあきらかに踏襲されていて、アーキテクトは利用者のことを考えるUXデザイナーみたいなものだと考えればよく、ゼネコンはプログラマーにあたる。それを突き崩すのにDIYという作業パターンがある。

デザインはコードと外形のうち外形のほうにある、ということではなく、コードと外形を貫くなにかとしてデザイン行為を考える必要がある、とおもっている。コードと外形の分離が、実装とデザインの分離そのもので、デザインという領域を外形性のなかに閉じこめているけど、その言論が建築にもあるし、ソフトウェアではとくに強い。

OO的なUIにたいしてOOPで書くのが良いデザインだとは言ってないとおもいます 一貫したメタファーがあるべきだと言っていて、「OOっぽいUI」と「OOP」の関係はたんなる実装の話な気がする。

アレグザンダーが「ランゲージ」という言葉を使うのは、建築物の作成者が理解可能である基準を設けるためであるし、それは建築物の使用者と同じ理解可能性が求められる。というか、理想的にはDIYであって、作られるものの細部にいたるまですべてが、使用者=設計者に対して理解可能になっているのが、おそらく一つの理想になっている。

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

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

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

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

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

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

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

どこからどこまでが迷信とされているのかがわからなかった

パターンは星座みたいなもので、偶有的に見える関係のなかに形態を見出すことだと言ってもいいとおもう。

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

この思い込みのことがパターンですよね

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

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

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

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

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

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

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

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

こいつまじで俺の名前を語ってなにやってんだよ

これめっちゃ気になるな... https://www.kaiho.mlit.go.jp/03kanku/kouhou/jcgm_yokohama/

デザインという言葉の適用範囲が、内側から分裂しているのがすでにめんどくさい。

デザインが内在的なロジックから導出されるのではなくて、偶有的なものであるならば、批評が成立する余地はたぶんない。

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

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