HP3000-L Archives

March 1999, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Cortlandt Wilson <[log in to unmask]>
Reply To:
Cortlandt Wilson <[log in to unmask]>
Date:
Fri, 19 Mar 1999 20:54:15 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (77 lines)
Jonathan,

>The
>resulting design can be simpler, because it does not require all the
>possible combinations and sequences of incoming events to be
specified, as
>would be required in a conventional programming approach."

I don't get it.   I don't see a difference here between event driven
and conventional programming.  If the events are discrete then
combination and sequence is irrelevent -- ergo requirements are the
same.    For more complex logical events where combination or
sequencing is important then all possible paths would still have to
specified - ergo requirements are the same.

>During IPROF's VPLUS SIG, we were debating the Event based vs.
Procedural
>based paradigm.
My recollection, as one of the participants in that exchange, is the
'debate' consisted of one statement and a quick rebuttal.

Cortlandt Wilson
Cortlandt Software
www.cortsoft.com  (MANMAN 3rd party  Resources site)
(650) 966-8555

Jonathan van den Berg wrote in message ...
>Hello Tony, and list members,
>
>I listen, everyday, about the use of middleware to connect clients to
>servers, interface to databases, connect shared resources. Recently I
was
>reviewing some research from a friend of mine, Richard Pawson, who
leads the
>CSC Foundations Research Group, and came across this paragraph.
>
>Richard writes: "Instead of having programs that run periodically,
and
>execute a pre-determined process (branching and looping when
appropriate),
>the system is divided into independent chunks of code that fire or
trigger
>immediately in response to specific events  -  which may be
externally
>sensed, or internally generated.  One obvious advantage for these
type of
>systems is speed of response; another is parallelism  -  responding
to
>multiple events (of the same, or different kinds) in parallel.  The
>resulting design can be simpler, because it does not require all the
>possible combinations and sequences of incoming events to be
specified, as
>would be required in a conventional programming approach."
>
>During IPROF's VPLUS SIG, we were debating the Event based vs.
Procedural
>based paradigm. After reading the above paragraph, I just couldn't
resist
>sharing it. The biggest issue driving the demand for looser coupling
is
>business agility:  the recognition that a system that is optimized to
>today's requirements may be very difficult to adapt to future needs.
Rather
>than trying to eliminate the joints between systems, we should be
>consciously trying to build in more joints, so that the pieces can be
more
>easily separated and re-formed in future.
>
>Cheers,
>
>Jonathan van den Berg
>Premier Software Technologies
>fon: 408-257-8757
>fax: 408-253-1184
>www: www.premiersoft.com
>

ATOM RSS1 RSS2