Re: REST impact paper

On 9/7/17 6:38 PM, Ken Meltsner wrote:
> Patterns were good as a way to pass along otherwise tacit knowledge
> (usually) because they had a prescribed structure -- the problem
> statement, etc. -- and a somewhat vaguer imperative to be
> "generative."  The second part was usually the toughest, because you
> wrote patterns based on examples; it was more difficult to test
> whether a given pattern was truly generative until people tried to use
> the pattern to drive design.  But you ended up with a book that you
> could teach from, rules that could be applied to check how people were
> doing, etc.
>
> But all of this was built on top of a process:
>
> *  Survey of solutions, applications, whatever in a particular domain
> *  Analysis to find common elements (good and bad)
> *  Synthesis to write up those common elements into a consistent format
> *  Application of the pattern to new situations
>
> IMHO, I think the patterns community made great strides in the middle
> stages.  The writers' workshop approach was borrowed as a format for
> the analysis and synthesis efforts, so if the workshop participants
> had broad experience, they could come up with the necessary examples
> that might have been missed by the original author and through
> discussion and mutual criticism they often produced pretty good
> patterns.
>
> Application of those patterns?  That was a lot harder -- by
> generalizing from a set of examples, I think there were implicit
> boundaries for where the patterns could be applied successfully (the
> local optima), and outside of those often unstated or unknown
> boundaries, good patterns became "anti-patterns" -- counter-examples
> where a particular approach failed badly.
>
> Still, patterns at their most useful provided a common language for
> participants in a design process where there might not have been one
> before.

I came to use various techniques, software patterns really, when writing a lot of code.  Some of those overlap with the software 
patterns discovered and distilled by those pioneers.  Once I've been exposed to a software pattern, it either clarifies something 
for me, or gets added to my set.  But oddly, it remains a laborious lookup for me to list the official names for the patterns I'm 
using.  My internal system is about shapes and feels (a la smells), like choosing a tool to work on wood or metal without recalling 
the names.  Although still much different from that.  It's also a lot like instantly knowing which math transformation rule to use 
next. But math usually feels static to me while programming is live and active: I am always experiencing the code in action, or 
really some representation of the mechanisms communicated by the flat code, sometimes in multiple dimensions in some sense.  Other 
times I guess it is a little symbolic: given this type of thing and that kind of wants / constraints, this structure solves it best 
- no need to re-experience how it works; memoizing thought, something we do all the time.  Those are the patterns.  I haven't heard 
others clearly describe, much, how it feels when they develop.

If I were describing architectures to others more, I would probably sharpen the availability of my pattern language vocabulary.  But 
I would also be coining my own terms frequently.  I think it might be better to talk about things as a story, even though an 
analysis might mention a series of software patterns.

Here is a kind of funny pattern I came up with recently:  (How likely is it that web UIs require fitting polynomials?)
Dual scaling: Scaling graphics and text at the same scales is suboptimal: text tends to be far too large or small at the extremes 
while images and line art are fine.  Fit a polynomial to aesthetically pleasing and readable samples at runtime to drive dual scales.

I'll post the 35 lines of code for that soon, along with my 'panel responsive' CSS mechanism that uses it.  (There is an easy way to 
make an HTML window scale, but not for panels due to CSS limitations.  I found a reasonable, tunable way.)

Although some people want to keep looking down on Javascript, I look at web browsers as one of the most powerful tools we have.  And 
there are some nice things about Javascript, once I was over the hump on everything.  Patterns and idioms are sometimes different, 
which is mostly good by some key measures.  And recent additions to the language, CSS, HTML, etc. are very cool.  It seems like web 
development has gone from miserable to (mostly) fun in just the last few years.  A lot of that has to do with leaders in those areas 
perceiving and implementing a lot of great patterns.

>
> Patterns ended up on a continuum ranging from aphorisms and rules of
> thumb (like Postel's Law) on one end, and strict engineering codes
> ("each work box will contain no more than N wires per cubic inch...")
> on the other.
>
> I think the failure/replacement of many promising technologies (SGML
> by XML, and then by JSON and YAML) were best described by aphorisms
> like "do not repeat yourself," "you aren't going to need it," etc.
> Perhaps patterns are over-engineered just as XML was, and simpler
> mottos work better than structured rules when you're working in a very
> flexible and fluid environment?  I mean, while it can be annoying or
> expensive to refactor software, it's a hell of lot less expensive than
> correcting mistakes in traditional manufacturing.

There are definitely concise coding principles that too many don't have.  I've been impatient with boilerplate and other cruft for a 
while now.  It is surprising how clean and concise you can make things if you work at it, and can choose different languages, etc.

>
> There's probably a rule that covers this.  In the world of defense
> manufacturing, we had a chart that showed how much of a project's cost
> would be committed versus how much of the money was spent, and in
> traditional manufacturing, the slope was such that by the time you had
> spent 10% of the funds (time, materials), you had actually committed
> how you would spend about 90% of those resources.  That's why
> waterfall design makes sense when you're building  jets, houses or
> dams.  Even if you had to double the time spent on the initial
> analysis and design, it was way cheaper than making a mistake that
> wouldn't be found until much later in the project.
>
> My guess is that agile techniques try to keep the spend vs. committed
> amounts as close together as possible, which is possible given the
> extreme flexibility of most software projects.  And aphorisms probably
> work almost as well as patterns, which in turn are almost as effective
> as more structured approaches (UML?), but much, much cheaper to come
> up with and to apply.

The best way to approach solutions to problems can be just subtly different from less sophisticated solutions but far better in all 
of the *ilities.  I have my loose set of principles to avoid all of the horrors I've witnessed and sometimes coded or coded within.  
I was lucky to have less of those than were typical, but enough to have strong opinions.

One point I make on every project or discussion about waterfall vs. agile is that at the beginning of a project, you are the least 
informed and least experienced to make decisions that you will ever be on that project.  At the end of the project, you are an 
expert by comparison.  Unless you are bricklaying, not architecting / designing / engineering, it is almost impossible to make all 
the decisions up front better than making them just in time.  With most areas of computing evolving so quickly now, that is even 
more true.

Many key libraries, tools, and browser and other features that I'm using now didn't exist or certainly weren't known to me when I 
started my current project.  Each time we built an iteration, we revised the product and approach based on what we learned.

I mentioned something related to software patterns a little while ago that I'm serious about starting at some point soon:

An open source library meant to grow to include a wide range of all known application algorithms, stripped of / partitioned from UI 
and any other complexity.  It should use the clearest and simplest interfaces and integration methods yet be usable in actual 
applications.  There just isn't that much complexity in a basic payroll, double-entry accounting, scheduling, or similar applications.

> Ken Meltsner

sdw
>
> On Thu, Sep 7, 2017 at 5:59 PM, Stephen D. Williams <[email protected]> wrote:
>> On 9/7/17 5:12 PM, Joseph S. Barrera III wrote:
>>>> Each of us only knows a subset, and newbies know nothing.  A good
>>> architecture book covers a lot, but
>>>> usually without context of the turning points and their direct and
>>> indirect meaning.  It would be helpful to
>>>> have something like a Pirate Code for various branches of technology.
>>> You could call them "patterns" or something.
>>
>> That's usually used a bit more narrowly, but close enough.  Or you could
>> refer to software patterns, more generically, as concepts.  In my recent way
>> of looking at things, they are concepts that can be captured in close to the
>> same form, the same morphology.  At least in terms of metadata; the actual
>> core concept is still expressed in free form paragraphs and diagrams.
>>
>> Perhaps most of what I'm thinking about could be covered as design patterns,
>> but that isn't what people have done that I've seen so far.  Can you point
>> to a better list?
>>
>> http://www.mcdonaldland.info/2007/11/28/40/
>> http://www.dofactory.com/net/design-patterns
>> https://en.wikipedia.org/wiki/Software_design_pattern#Classification_and_list
>> https://dzone.com/refcardz/design-patterns
>>
>> That is interesting for what it is, but completely misses things like:
>>
>> Connection oriented vs. packet switching vs. RPC vs. message routing in
>> various senses.
>> TCP/IP vs everything else.
>> EDI vs. ASN.1 vs. XML vs. JSON vs. MsgPack / many.
>> Unix vs. everything else.
>> ODBC vs. JDBC vs. various modern solutions.
>> OS / VM / containers.
>>
>> For many of those, you could quantify resources wasted and/or redirected and
>> development delay for things that were local minima/maxima in some sense.
>>
>> sdw
>>
>>
>>> On Thu, Sep 7, 2017 at 4:58 PM, Stephen D. Williams <[email protected]> wrote:
>>>
>>>> Looks like a cool list.  Have to study it.
>>>>
>>>> We should consider theory vs. practice, and practice vs. commercial
>>>> feasibility / success vs. ubiquity vs. free/wide use separately.
>>>> Frequently linked, but they happen in different waves, sometimes widely
>>>> separated, so it would be even more muddled to be tracked in one
>>>> framework.
>>>>
>>>> Nothing is very clean.  But some points are clear and others clear enough
>>>> to consider.  Besides REST, there are plenty of examples, to wit: IETF,
>>>> Jon
>>>> Postel etc.  Even an idea as simple as this was a turning point
>>>> (regardless
>>>> if it was from a single person or a general consensus of the time, as
>>>> often
>>>> happens):
>>>>
>>>> "Be conservative in what you send and liberal in what you accept"
>>>>
>>>> https://tools.ietf.org/html/rfc4677
>>>>
>>>> In computing, politics, and other areas, there are plenty of singular
>>>> concepts that bifurcate groups and/or time periods.  It would be
>>>> interesting to catalog those.  A lot of successful companies started with
>>>> a
>>>> concept that was new or implemented in a new way.
>>>>
>>>>
>>>> More important than the curiosities of history would be usability as a
>>>> roadmap of concepts, plateaus of sophistication, and foibles that one
>>>> should be aware of.  I use many such principles every day, mostly as
>>>> reflex
>>>> now.  We could briefly summarize before and after for internalization
>>>> justification.
>>>>
>>>> Each of us only knows a subset, and newbies know nothing.  A good
>>>> architecture book covers a lot, but usually without context of the
>>>> turning
>>>> points and their direct and indirect meaning.  It would be helpful to
>>>> have
>>>> something like a Pirate Code for various branches of technology.
>>>>
>>>> http://mentalfloss.com/article/58900/11-rules-actual-pirate-code
>>>> http://pirates.wikia.com/wiki/Code_of_the_Pirate_Brethren  Haha
>>>> http://pirates.wikia.com/wiki/Pirata_Codex  Jaja
>>>>
>>>> Coding Codex?
>>>>
>>>> Stephen
>>>>
>>>>
>>>> On 9/7/17 12:56 PM, Gregory Alan Bolcer wrote:
>>>>
>>>>> Fill us in.  I don't think computing, science, or software is that
>>>>> clean.
>>>>>
>>>>> I grew up (professionally) with grand computing challenges.
>>>>> http://www.grids.ac.uk/Complex/grand_challenges/
>>>>>
>>>>> I don't think these are the same ones, but it's an interesting list.
>>>>> My favorite:  Exploiting division by zero;
>>>>>
>>>>> Greg
>>>>>
>>>>> On 9/7/2017 10:21 AM, Stephen D. Williams wrote:
>>>>>
>>>>>> There are some interesting problems with also capturing the temporality
>>>>>> of things, including things that sped up or held back invention /
>>>>>> adoption.  I can see a couple possibilities.
>>>>>>
>>>>> _
>>>>>

sdw

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