Fwd: [xml-dev] Transformative Programming: Flow-based, functional,and mo

[Dimitre Novatchev <dnovatchev@gmail.com>]

---------- Forwarded message ----------
From: Dimitre Novatchev <dnovatchev@gmail.com>
Date: Wed, Oct 16, 2013 at 10:43 AM
Subject: Re: [xml-dev] Transformative Programming: Flow-based,
functional, and more
To: "Simon St.Laurent" <simonstl@simonstl.com>


The XPath Visualizer 2 (not  yet made public), is a visual environment
that allows the human user to import a variety of stylesheet modules
and then use/evaluate the functions defined in these, connected in any
(unpredictable) expressions. Initially I wrote this to use as an
interpreter for FXSL -- also as a quick way to glue together the
necessary functions and see if the expected results are produced --
before putting this code within an XSLT program.

I believe this come close to the "human link" in the FBP ?

Cheers,
Dimitre

On Wed, Oct 16, 2013 at 8:57 AM, Simon St.Laurent <simonstl@simonstl.com> wrote:
> On 10/16/13 11:40 AM, Peter Hunsberger wrote:
>>
>> Simon's been pretty clear that data interchange via XML is all well and
>> good and that rigid standards can be a problem.  However, that does get
>> to the essence of my question, where does the line between these two
>> divergent views get drawn?  In particular, XSLT and XProc are useful
>> precisely because of the standardization and structure of their
>> particular XML formats (imperative or not)...  Their very utility comes
>> with the cost that Simon often seems to disapprove of.
>
>
> I suspect the reality is that Uche is right that I (at least think I) am
> still consistent with my earlier position, but a quick read of flow-based
> programming might seem to lead right back to the excessively structured data
> models I regret.
>
> The easiest way to explain this is that different transformations can have
> different requirements, different levels of expected precision, and
> different capabilities for handling variation.
>
> If a transformation is a simple mathematical function, it's reasonable for
> it to break if given textual arguments.  On the other hand, if it's an input
> cleaner that we regularly train to handle new situations, it's probably a
> lot more flexible.  In particular, if (as I suggest at the end) that
> transformation is actually relying on a human rather than a microprocessor,
> there may be far far more flexibility available.
>
> A flow makes it fairly easy to put more flexible transformations at the
> beginning and end of the flow, or generally anywhere a "border crossing"
> might happen.  Transformations with more rigid expectations will likely lurk
> in the middle of such flows, hidden away from communications challenges to
> the extent possible.
>
> That allows a mix of styles and expectations to coexist.  Code that requires
> predictable inputs to work can have it, without demanding that everything
> around it have the same expectations.  Code that needs to interact with
> humans or other chaotic systems can have its own flexibility.
>
> Perhaps most important, though, mapping how and where these interactions
> take place should become much much easier.
>
> Does that tell the story any better?  It leads to the next round or two or
> what I'm planning to write, so I'd love to find weaknesses in it sooner
> rather than later.
>
> Thanks,
> Simon
>
>> On Wed, Oct 16, 2013 at 10:11 AM, Uche Ogbuji <uche@ogbuji.net
>> <mailto:uche@ogbuji.net>> wrote:
>>
>>     On Wed, Oct 16, 2013 at 8:41 AM, Peter Hunsberger
>>     <peter.hunsberger@gmail.com <mailto:peter.hunsberger@gmail.com>>
>> wrote:
>>
>>         Nice write up Simon.  This seems more accepting of structured
>>         XML data management approaches than I've come to expect from you
>>         recently.  Something going on or is this just an anomaly?
>>
>>
>>     I think you might have misread Simon in his posts challenging the
>>     XML community. He has never that I've seen put down XML's basic
>>     usefulness for semi-structured, open data expression. Your
>>     characterization as "structured XML data management approaches,"
>>     however, is another kettle of fish, and not a way of putting it that
>>     I think communicates XML's strengths.
>>
>>     Simon's main complaint has been with the culture of rigid
>>     schematics, and with the bleed-in of the imperative programmer's
>>     mindset into XML (notice that he gives a positive mention of XSLT
>>     and XProc, which at least in their initial forms stayed away from
>>     imperative style). It seems to me that this article continues his
>>     points consistently.
>>
>>     --
>>     Uche Ogbuji http://uche.ogbuji.net
>>     Founding Partner, Zepheira http://zepheira.com
>>     Author, Ndewo, Colorado http://uche.ogbuji.net/ndewo/
>>     Founding editor, Kin Poetry Journal http://wearekin.org
>>     Editor & Contributor, TNB
>>     http://www.thenervousbreakdown.com/author/uogbuji/
>>     http://copia.ogbuji.net http://www.linkedin.com/in/ucheogbuji
>>     http://twitter.com/uogbuji
>>
>>
>
>
> --
> Simon St.Laurent
> http://simonstl.com/
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php



--
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
Never fight an inanimate object
-------------------------------------
To avoid situations in which you might make mistakes may be the
biggest mistake of all
------------------------------------
Quality means doing it right when no one is looking.
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play
-------------------------------------
Facts do not cease to exist because they are ignored.
-------------------------------------
Typing monkeys will write all Shakespeare's works in 200yrs.Will they
write all patents, too? :)
-------------------------------------
I finally figured out the only reason to be alive is to enjoy it.


-- 
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
Never fight an inanimate object
-------------------------------------
To avoid situations in which you might make mistakes may be the
biggest mistake of all
------------------------------------
Quality means doing it right when no one is looking.
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play
-------------------------------------
Facts do not cease to exist because they are ignored.
-------------------------------------
Typing monkeys will write all Shakespeare's works in 200yrs.Will they
write all patents, too? :)
-------------------------------------
I finally figured out the only reason to be alive is to enjoy it.