Re: MP, tools & algs

toEugene Miya wrote:
> DiNucci wrote:
[Englebart]


The nice discussion that I've had with him was to consider other better
tools such as Sherlock Holmes analog using a hand lense. He has just
now seen that that might be the better way to go. But last we spoke
he got some money from the NSF. A small chance I may see him tomorrow
nite at a monthly dinner.

Say "hi" from me. :-) I'm sure he'll remember, I was the one sitting in the middle of that huge audience at the "Engelbart's Unfinished Revolution" colloquium at Stanford. (I think I had a picnic lunch with Gordon and friends there on the grounds that day.)

A friend (Buzz Hill) and I tend to talk alot about "zooming" in and out regarding levels of abstraction. I don't know if that's similar.

That's just data flow, how about control flow--re my parenthesized
comment above? People like to see control dependences as well. It's
why structured control constructs utilize indentation, to add another
(partial) dimension, to allow the control points of a structured
construct to be visually related to each other (by being juxtaposed at
the same level of indentation) as well as being related to the
neighboring statements (by being juxtaposed, period). Entities which
are juxtaposed in a program trace are juxtaposed in the code (using one
definition or the other). I consider this similarity of code and trace the essence of structured programming.


I think the problem is your word: See. That's why I think Parnas and
Habermann variously considered global variables harmful.

I'm sure that's the reason. You can't *see* the associations.

The problem,
like many, became scale. Single words of memory weren't a big deal.
Arrays, array handling and inconsistent array state likely also contributed
to data flow's death.

Those are undoubtedly the trickiest things to address in a visual and/or latency-tolerant language. But I think ScalPL is on the right track there.

Once you get into parallel programming, and the dependences (both data
and control) go all over, and the program trace becomes a partial
ordering/DAG rather than a sequence, indentation isn't sufficient.
Still, if you represent data and control dependences in the program by
graphical connections (e.g. lines) and consider operations as being
proximal in both the program and the trace whenever they're
connected, you get the same essence of structured programming. (I'm sure I discuss this in some paper, too.)


You will still have problems with exception handling.

Not if you handle it right. e.g. in ScalPL, exceptions are just alternate control states associated with data. "Exceptions" are only considered exceptions because there's traditionally only one flow of control, and they're exceptions to that.

The prophet has a problem.

Smart/living messengers have learned to carry some good news with the bad.


Who is your Judas? [I just saw the news before the weekend.]

I didn't. What news? This sounds scary. I figured I couldn't get into too much trouble sitting here writing tech papers and software, for myself mostly.

-Dave
---
http://www.elepar.com/

.

Relevant Pages

  • Re: Managing a project as it scales
    ... >understanding the appropriate use exceptions. ... You don't identify the control. ... A second keystroke puts the the REQ#, ... I also introduced a bug, an a week or so later, I fixed the ...
    (microsoft.public.vc.mfc)
  • Re: Managing a project as it scales
    ... understanding the appropriate use exceptions. ... or a static control from a thread is a fairly common task I implement. ... use a documentation tool? ... Java, but you know C++ you don't need to know Java in order to follow ...
    (microsoft.public.vc.mfc)
  • Re: Real life cost of using exceptions for control flow?
    ... > I know that my view may seem a bit extreme, but it actually works very well. ... > yourself from using exception for flow control. ... I am not at all against throwing exceptions. ...
    (microsoft.public.dotnet.framework.performance)
  • Re: MP, tools & algs
    ... A computer is a physical tool to leverage intellectual tools. ... The most common ways to specify the routing of results from one transform to inputs/arguments of others are: juxtaposition of the transforms, associative matching of identifiers, and drawing lines or arrows. ... People like to see control dependences as well. ... are juxtaposed in a program trace are juxtaposed in the code (using one ...
    (comp.arch)
  • Re: MP, tools & algs
    ... What did Doug in, one of the things, if you read Markoff was that Doug ... Arrays, array handling and inconsistent array state likely also contributed ... exceptions are just alternate control states associated with data. ... "Exceptions" are only considered exceptions because there's traditionally only one flow of control, ...
    (comp.arch)