Re: how to extend a capability on a data source?

On Sun, Nov 3, 2013 at 1:16 PM, Rob Withers <[email protected]> wrote:

>
> Allow me a moment to lament the desire by various parties, near and far to
> protect us from ourselves.  In this case, static typing, particularly
> stupid static typing <SST>.
>

I know the feeling. Static typing, like many things, can be done reasonably
well (ML, Haskell) or done poorly (Java, Scala, C++).

I'd say similar of "structured programming". Structured programming became
popular after Dijkstra's famous paper (Goto considered harmful), but has
hindered language flexibility and resulted in a lot of boiler-plate. Forth,
Factor, PostScript and other concatenative languages are known (among their
users) for easy metaprogramming, ability to easily absorb paradigms,
abstract away boiler-plate, and model problem-specific vocabularies. That
language flexibility is achieved by rejecting structured syntax.

The problems that structured programming helps us reason about - i.e. that
every loop has a single exit, that every function returns a value - could
easily be expressed in a substructural type system. I.e. we can have all
the benefits of structured programming, without any of the costs, and all
it requires is learning about affine/relevant/linear types (which are super
simple, but not supported by traditional languages today).


> Why would asking non-deteministic questions be bad?
>

Because complexity is bugs. :)

Every time we introduce new states or conditions we must reason about,
reasoning becomes harder. We should be avoiding state - both implicit and
explicit - as much as possible. There is a certain, minimal amount of
'essential' state that an application requires - e.g. you can't have a text
editor without statefully managing text. Beyond that, state is what Fred
Brooks would call "accidental complexity", a place for bugs to hide. (
http://en.wikipedia.org/wiki/Accidental_complexity)

So if we need non-determinism for a problem (e.g. to make constraint
solving tractable), that's one thing. If we're using it as a hack on
semantics that can observe a lot of intermediate states or implementation
details, that's another.


> Stopping the message would be best effort.  More like monitoring, through
> the event registrations, for stalls and such.  If we kick off 3
> computations across the same data, a la Hadoop, then only 1 wins during
> reduce.
>

It seems to me what you really want is a model for incremental computations
that can be stopped at well-defined increments. Alternatively, you might
look into approaches for speculative evaluation and retroactive correction
for parallel and distributed systems (PADS). Have you read about
Lightweight Time Warp (LTW)?
http://cell-devs.sce.carleton.ca/publications/2008/LW08/


> we live in an eventful world
>

No we don't. Nothing in physics is eventful. Almost every sensor you use
(mouse, keyboard, camera, microphone) is inherently time-series data
without any real notion of 'events'. Even a snapshot camera image is,
under-the-hood, technically an integral of light information over the
duration that an aperture is held open. At even lowest levels, quantum
interactions seem to occur in a timeless, stateless geometry (
https://www.simonsfoundation.org/quanta/20130917-a-jewel-at-the-heart-of-quantum-physics/),
and topology seems to be a fundamentally better basis for comprehending the
world than events.

And even if by 'world' you're talking about human communication, that is
not eventful. What's eventful about a book? or webpage? or a recorded
movie? Isn't an "event" something we typically infer in hindsight, by
comparing before and after states? Maybe you should be considering state
fundamental, and understand update-events as just incidental. Which
particular organization of state changes we wish to emphasize by calling an
'event' seems to be very ad-hoc and hand-wavy.

Events are a human abstraction, a way we might understand or explain some
aspects of the world. Like many human intuitions, events break down at the
small scales and the large ones. It's unfortunate that, like many concepts
people have internalized, the necessity of 'events' is rarely ever
questioned.


> a shared, replicated non-deterministic state machine, with eventual and
> snapshot consistency
>

I do like those properties, and I use them. (
http://awelonblue.wordpress.com/2011/10/06/vat-model-for-rdp/)


>
> One of the pages on that blog, on declarative state machines:
> http://awelonblue.wordpress.com/2013/03/27/declarative-state-machines/,
> suggests to adding a discrete clock signal.  I do not know if it is meant
> to mean distinct or prudent, but either way, that certainly sounds like an
> event to me.
>

A discrete clock signal can be modeled operationally, imprecisely, and
informally using messages/events. The problem here is that messages
triggered on the same time or clock event aren't delivered or received
simultaneously. A discrete clock signal can also be modeled declaratively,
precisely, and formally using temporal logic or an infinite list. As an
example:

  tickTockClock :: Time -> DeltaTime -> Bool -> [(Time,Bool)]
  tickTockClock t dt b = (T,b):(clock (t+dt) dt (not b))

Given that the article is about declarative programming, I would have
thought it obvious to assume a declarative representation for a clock
signal. OTOH, I'm the author, and what's obvious to me isn't always clear
or well communicated to my readers.

Best,

Dave

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk