Re: MP, tools & algs



Eugene Miya 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


In article <v5qdnT7fn92hK6fZnZ2dnUVZ_smdnZ2d@xxxxxxxxxxx>,
David DiNucci <dave@xxxxxxxxxx> wrote:

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

8^)

Gordon and friends there on the grounds that day.)


I just saw Gordon at the Stanford 40th Annv. of the CS Dept. Founding.


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.


Abstraction is an abstract thing. What falls off the sides is a matter
of debate. Ted Nelson tends to be better for that. He's very specific
about things he wants for transclusion. Doug tends to be a bit more vague.

What did Doug in, one of the things, if you read Markoff was that Doug
didn't think (at the time), that 5,000 commands was such a bad thing.


That's just data flow, how about control flow--re my parenthesized
comment above?

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.


Well who would have thought that Unix fork(2) was the way to fork ala
Dijkstra? I am sure Nick did. ;^) BTW: I just sent out both of your
posts in c.p. Part of the problem lay in one way links. The web's
problem as well.


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.


Perhaps.
Time will tell.
I don't have a strong enough opinion either way.



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.


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.


We cannot assume the end users will handle things right.
When we try to make things idiot proof, we find out how smart idiots are.
It's in part why people still use gotos.


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.


The Gospel according to Judas.

Not a Gospel. If that is the title it should be quoted or underlined. Proper naming is very important in computers as well. Calling something what it isn't causes problems in any field. You recall the famous mark twain quote about tails and legs.



--
Del Cecchi
"This post is my own and doesn’t necessarily represent IBM’s positions, strategies or opinions.”
.



Relevant Pages

  • 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 ... alternate control states associated with data. ... "Exceptions" are only ...
    (comp.arch)
  • 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: Jon Skeets thread pooling sample
    ... >> event handlers the rest of the time, I think I'll go for something like ... That means I don't have to swallow *any* exceptions, ... the parameter array should be cloned at construction time or not.) ...
    (microsoft.public.dotnet.general)
  • 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)