Re: REST impact paper
"Stephen D. Williams" <[email protected]>
| Newsgroups | gmane.culture.people.rohit-khare |
|---|---|
| Message-ID | <[email protected]> |
On 9/8/17 11:56 AM, Gregory Alan Bolcer wrote: > No, they are techniques to increase the chance of reuse, but not necessary and sufficient criteria to guarantee. I might call them meta software patterns: What should the meta goals be and how should a result feel. They didn't anticipate the web and a zillion other things, but they saw that you could factor things for maximum reusability. Some of the things they created took the concept of a reusable function or library up a level or two into composable programs and services. And Unix as a whole was as flexible as they could make it. That spilled over into the design of protocols and services on the Internet. > > I think you are confusing your timeline by conflating successful effects with design at the time. I thought we were talking about the root concepts and decisions and their impact on everything that followed. They identified goal/meta-goals and strategies then that still mostly seem to fully apply today. Most of the successes today can be seen as applications. Their implementation then was limited, but solid for what they were working with. > > Greg > > On 9/8/2017 11:30 AM, Stephen D. Williams wrote: >> Are you saying that the reusable tools, interfaces, and techniques in Unix were all an accident? You said: "I think the design pattern of resuse came out of things that people didn't expect to get reused". I disagree: Those Unix guys, and everyone who bought into their philosophy, always attempted to build things that use the "design pattern of reuse". They may not always be clever enough to find the ultimate solution right away, but they always have had that goal in mind. Your statement seems to indicate that you assign a lot of insight on reuse to some later person or group. For instance: When I was (briefly) CTO of Jabber.com, Inc. in 2000, I tried to convince the CEO and team to push for use of Jabber as an overlay network for events, app communications, RPC, etc. in corporate environments they were selling to. Just like Slack is doing now. Nobody else was interested in pursuing it. But it was a clear generalization of the design. Didn't your work in that era have a lot of that generalized reuse too? sdw _______________________________________________ FoRK mailing list http://xent.com/mailman/listinfo/fork