Re: Occam-Tau anyone???

[Michael <sparks.m@xxxxxxxxx>]

On 5 October 2012 19:18, Fred Barnes <F.R.M.Barnes@xxxxxxxxxx> wrote:
...
> Agreed!  We had plans for similar some years ago (2003), which I wrote up
> here:
>
>     http://frmb.org/oscript.html
>
> implementations welcome!  (I started but never finished..)

>From your page, this example here:

    stream a, b
    par {
        exec ("cat input.file", null, a!, null)

        # delta and merge pipe-lines
        pipeline (< ("grep '^X'" || "sed -e 's/xxx/yyy/g'"), \
            ("grep -v '^X'" || "sed -e 's/foo/bar/g'")>, \
            a?, b!, null)

        # remaining process pipeline
        pipeline ("sort" || "uniq" || write (_?, "output.file"), b?, null, null)

Reminds me of the sort of things we do in Kamaelia (a python library).
    Pipeline(
       PAR(
           Button(caption="Next", msg="NEXT", position=(72,8)),
           Button(caption="Previous",msg="PREV", position=(8,8)),
           Button(caption="First", msg="FIRST", position=(256,8)),
           Button(caption="Last", msg="LAST", position=(320,8)),
       ),
       Chooser(items = files),
       Image(size=(800,600), position=(8,48)),
    ).run()

(bolts together the components for a presentation tool)

Or this:

Graphline(
    FILES = Pipeline(
                Find(path=args["path"],walktype="f"),
                Sort(),
                Grep(pattern=args["exclude-pattern"], invert = True),
            ),
    SPLIT = TwoWayBalancer(), # Would probably be nicer as a chassis,
or a customised PAR chassis
    CONSUME1 = Pipeline(
                    Transcoder(),
                    Uploader(username=args["username"],  # Would be
better to pass to a single uploader really
                             password=args["password"],
                             hostname=args["server"]),
               ),
    CONSUME2 = Pipeline(
                    Transcoder(),
                    Uploader(username=args["username"],  # Would be
better to pass to a single uploader really
                             password=args["password"],
                             hostname=args["server"]),
               ),
    linkages = {
        ("FILES","outbox"):("SPLIT","inbox"),
        ("SPLIT","outbox1"):("CONSUME1","inbox"),
        ("SPLIT","outbox2"):("CONSUME2","inbox"),

        ("FILES","signal"):("SPLIT","control"),
        ("SPLIT","signal1"):("CONSUME1","control"),
        ("SPLIT","signal2"):("CONSUME2","control"),
    }
).run()

The biggest barriers to adoption of this sort of thing incidentally
that I've found are:
  * The creation of components themselves is a hurdle - in particular
there is an impedence mismatch between standard sequential code and
concurrent/parallel. This is arguably where something derived from
Occam could work well.
  * Syntax (and in particular prettiness) matters to people
  * You really need to act as a programmers exoskeleton (ie library)
rather than a robot/host (framework/language)
  * A good syntax for arbitrary graph-pipelines is less than obvious.

These four are a much harder balance to get right that's palatable to
developers. (I'm currently working on an alternative since I now view
Kamaelia as old tech having proved itself useful.)

By contrast, people really like the idea of composing pipelines (and
graphlines as I've tended to term non-linear pipelines). It's
impressive the complexity of reliable system that inexperienced
developers can build with this approach IME.


Michael.