Semaphors began as a way to solve a tricky, dynamic GUI layout problem
which arose during work on an arithmetic tutorial, viz, allowing the
student to type easily things like long addition problems with addends
as big as they like and as many addends as they like. Also decimals
should align themselves automatically if entered.
Semaphors solved that almost trivially. Curious, we then applied
semaphors to a trivial problem to see if they were too much trouble for
simple problems. My thinking was, maybe semaphors would be worth the
trouble only for complex problem. The problem I chose was maintaining a
radio group, and semaphors not only solved the simple problem simply,
but when coding the solution i forgot about getting the radio group
initially set to a starting value--but the semaphoric approach happened
to take care of that...i took that as a Sign.
Since then semaphors have come to permeate my applications, and a
semaphor-based GUI framework is part of that. As I mentioned earlier, we
even managed to endow persistent instances with semaphors so views of
persistent data automatically get updated as that data becomes
associated with other persistent data.
The impression I get is that programming is much easier with semaphors:
more functionality gets built in less time with fewer bugs and more fun.
Indeed, the productivity improvement was so great I was led to meditate
on why exactly they were so beneficial. Lots of things have come to mind
over the five-six years I have lived with semaphors.
First, obviously a big win is knowing one's program state is guaranteed
to be self-consistent, and with semaphors this is done for you with near
transparency. Makes me wonder how many bugs could be categorized as
inconsistent-state errors. But this alone did not seem to be enough to
explain the benefit I was enjoying.
My next thought was that any application is a model. Without an
automatic state-propagation (dataflow) engine, the effort of making that
model work falls on the programmer. "OK, that selects some text, now I
have to enable the "Cut" menu item." With a dataflow engine, the model
works by itself. I think of semaphors as animating application models
which programmers generally have to animate by hand, if you will. This
is a grander take on the preceding observation in re self-consistent
state.
Another idea i had was that semaphors conquer the complexity of
applications by decomposing the total complexity into manageable pieces.
Again the spreadsheet is a good example. As a child (before even
calculators) I watched my father work paper spreadsheets by hand. Every
time he made a 'what-if" change he had to propagate that state from cell
to cell to cell. And because A depends on B depends on C, there is I
think some combinatorial explosion of application complexity as the
number of interesting state variables increase.
But even in the most complex spreadsheet, no one cell in a spreadsheet
has a formula tapping more than a few other cells. And semaphors give us
the same benefit in programming: semaphor rules generally access just a
few other semaphors. But in a sense this complexity i am talking about
is that of keeping program state internally consistent.
On our current project, I can see another benefit: semaphors help OO
deliver on reuse. Our classes are generic, low-level, all-purposes...we
get specific behavior by attaching different semaphors to different
instances of the same class, not by subclassing. This means we do not
get into situations where the only way to avoid or get some particular
behavior is to create yet another class...I can code any semaphor I want
for some special circumstance.
Finally, hey, semaphors make feasible a declarative, functional style of
programming, and those are well-understood improvements over other
paradigms.
Anyway, that's the best I can do to explain why it might be, but all I
know is, semaphors are great to program with.
kenny
Kenny Tilton <·······@nyc.rr.com> wrote:
> Anyway, that's the best I can do to explain why it might be, but all I
> know is, semaphors are great to program with.
What do you call semaphores ? Is it something like 'make' utility,
which uses dependency information for smart recompiling only
few files instead of full rebuild ? If so, you're right, they
are great. I'm using it in my main project in C++ and main
dependency declaration seems like this
//result(key) datatype desc dependencies
{SC_S1S2, DCT_DOUBLE, "S1/S2", SC_DIFF,SC_R1, SC_R2, ...
{SC_MOM1, DCT_DOUBLE, "1st mom", SC_DIFF,SC_DGPRO, SC_R1,
{SC_MOM2, DCT_DOUBLE, "2nd mom", SC_MOM1I,SC_NIL, SC_NIL,
{SC_SQUARE, DCT_DOUBLE, "Int square", SC_INT, SC_R1, SC_R2,
In Lisp it can be done more naturally because of 1) - dynamic
type variables 2) - lists can be used for dependency declaration.
Hey, Arseny...
God, yes, I loved 'make' when I first came upon it, but Semaphors are
different, basically just slot values which are functions instead of
literals...the value returned is the result of executing the function.
The similarity with 'make is that Semaphors are smart enough to reuse
the last value calculated if calling the function would return the same
value (takes a little plumbing).
The effort to avoid unnecessary calculation just makes Semaphors
efficient. The power comes from the declarative style of programming it
supports, as well as heightened class reuse.
cheers, kenny
Arseny Slobodjuck wrote:
>
> Kenny Tilton <·······@nyc.rr.com> wrote:
>
> > Anyway, that's the best I can do to explain why it might be, but all I
> > know is, semaphors are great to program with.
>
> What do you call semaphores ? Is it something like 'make' utility,
> which uses dependency information for smart recompiling only