Re: REST impact paper

On 9/8/17 4:16 PM, J. Andrew Rogers wrote:
>> On Sep 8, 2017, at 1:46 PM, Stephen D. Williams <[email protected]> wrote:
>>
>> 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.
>
> The history of the Internet and much software is many things being reused that probably never should have been, except perhaps as a dodgy short-lived one-off. Most of the reuse that happened was laziness, not any kind of thoughtful design. The craptastic mess that is the modern web ecosystem or mountain of hyper-modular mediocrity that is open source data stacks is the product of profligate reuse without any investment in design for reusability except at the level of “quick and dirty”.

Agreed, most current front and back end web development is run-away-screaming bad, out of date, and otherwise painful.  But some 
ways of building apps and services are clean, lean, sophisticated, and relatively fun.  A lot of things sound that way until you get 
into it, but there are some nice choices to be found if you refuse to go along with the first 100 terrible options.

Maybe we would make better progress if people would abandon obsolete methods faster.  We seem to avoid hurting
>
> An ecosystem designed for reuse would have far higher architectural standards than is commonly seen in practice. A reasonable argument could be made that it is not worth the effort, as evidenced by the lack of people writing such software. It isn’t just writing reusable code but using it as well. High-quality reusability puts far more onus on the programmer code to semi-formally specify the behavioral details at the interface, which is real work that you don’t have to do with quick-n-dirty.

I suspect that we'll substantially solve this kind of thing when we reach a level of sophistication where solving it feels right.  Until then, we're likely to end up with Ada2.

There are a few areas where it feels on the verge of being solved. This is a nice example:
https://github.com/d3/d3/wiki/Gallery


sdw

_______________________________________________
FoRK mailing list
http://xent.com/mailman/listinfo/fork