Difference between revisions of "Talk:Architecture Working Group"
Jump to navigation
Jump to search
Seg Baphomet (talk | contribs) (New page: I'm not sure where to put this in the wiki, but I would advise awareness of "The Art of Unix Programming". In particular, "Separate policy from mechanism" should be rule #1: http://catb.o...) |
Rob Linden (talk | contribs) (→Separate policy from mechanism: - Response) |
||
Line 1: | Line 1: | ||
{{Talk}} | |||
== Separate policy from mechanism == | |||
I'm not sure where to put this in the wiki, but I would advise awareness of "The Art of Unix Programming". In particular, "Separate policy from mechanism" should be rule #1: | I'm not sure where to put this in the wiki, but I would advise awareness of "The Art of Unix Programming". In particular, "Separate policy from mechanism" should be rule #1: | ||
Line 4: | Line 8: | ||
[[User:Seg Baphomet|Seg Baphomet]] 23:14, 21 September 2007 (PDT) | [[User:Seg Baphomet|Seg Baphomet]] 23:14, 21 September 2007 (PDT) | ||
:This is as good a place as any. It's not altogether clear that X is a fantastic example to use to make this point. The line between "policy" and "mechanism" is rarely clear cut. For example, cut and paste between X applications is still a crapshoot (even in 2007) because I guess "how to handle the clipboard" was a policy (?) rather than a mecahnism. At the same time, "all applications must be network transparent" was baked in as mechanism, not policy (which, in the 1980s, was a pretty dubious choice, and creates optimization challenges to this day). | |||
:I'll freely admit I could be very wrong about these specific deficiencies in X. My point is merely that I'm not sure that this provides a great rule, and I worry that being too orthodox on this point can lead us to [http://c2.com/cgi/wiki?PrematureGeneralization premature generalization]. -- [[User:Rob Linden|Rob Linden]] 13:03, 22 September 2007 (PDT) |
Revision as of 12:03, 22 September 2007
Separate policy from mechanism
I'm not sure where to put this in the wiki, but I would advise awareness of "The Art of Unix Programming". In particular, "Separate policy from mechanism" should be rule #1:
http://catb.org/~esr/writings/taoup/html/ch01s06.html#id2877777
Seg Baphomet 23:14, 21 September 2007 (PDT)
- This is as good a place as any. It's not altogether clear that X is a fantastic example to use to make this point. The line between "policy" and "mechanism" is rarely clear cut. For example, cut and paste between X applications is still a crapshoot (even in 2007) because I guess "how to handle the clipboard" was a policy (?) rather than a mecahnism. At the same time, "all applications must be network transparent" was baked in as mechanism, not policy (which, in the 1980s, was a pretty dubious choice, and creates optimization challenges to this day).
- I'll freely admit I could be very wrong about these specific deficiencies in X. My point is merely that I'm not sure that this provides a great rule, and I worry that being too orthodox on this point can lead us to premature generalization. -- Rob Linden 13:03, 22 September 2007 (PDT)