To Joel,
Thank you for another interesting essay. For a self-described
"Bear of Small Brain" you write well in both English and in REBOL..
I've enjoyed almost all of your thoughtful postings even when I wasn't
able to follow the REBOLish details.
Thanks also for mentioning Richard Gabriel. His "Patterns of Software"
sat unread on my shelf for two years until you mentioned him earlier
this week. Now I wish I'd picked it up sooner.
Can you explain what you mean by "a von Neumann language"?
Do you have a reference? I'm familiar with the notion of a von Neumann machine
(von Neumann architecture, von Neumann model) but a google search for
"von Neumann language" wasn't helpful. I assume you mean something
more than a programming language which runs on a von Neumann machine
since COBOL satisfies this description.
Finally, what's EWD?
Thanks again!
Vic Hirsch
>>> <[EMAIL PROTECTED]> 10/13/00 09:52AM >>>
As an avid reader of EWD, I assure you that I consider termination
to be a crucial part of algorithm correctness. (I toyed with adding
an additional argument to UNRAVEL as a bound on the number of
iterations before UNRAVEL would give up on an argument as being too
knotted to unravel. I chose, perhaps unwisely, not to include that
in the open discussion, thinking that it would complicate things
too much.)
However, your concern will apply WHENEVER we attempt to define new
control structures or higher-order functions! DO, REDUCE, WHILE,
and even the lowly IF all have the property that I can hand them
arguments whose evaluations fail to terminate. If, for example,
a function such as MAP (per earlier discussion on this list) gives
me the privelege of handing it an arbitrary chunk of code to be
executed under its control, then it simultaneously imposes on me
the responsibility of dealing with the termination of that code.
I know no way around this.
And (if I may have your ear just a moment longer...) there is a
negative historical precedent which is quite fascinating (to me,
at least).
The publication of Benoit Mandelbrot's _The_Fractal_Geometry_of_
_Nature_ (copyright 1977) was a great shock to many people
(including, unfortunately, some mathematicians) who perceived
the ideas (and pictures!) of that book to be an entirely new way
of looking at the world. Subsequently there has been a flurry of
excitement and activity regarding how fractal formulae and
thinking can give us powerful new models with which to work.
HOWEVER... in the introduction, Mandelbrot himself dates the
roots of fractal geometry to 1875, over a century earlier!
Why then did so many (including scientists and mathematicians)
perceive fractal geometry to be so startlingly new?
Because the mathematical establishment had dismissed earlier
investigations into "monstrousities" (such as the continuous,
non-differentiable function reported in 1875) as frivolous or
wrong-headed. My point here is not about the individuals
involved (then or now, including members of this list!), but
about how ideas become mainstreamed or marginalized.
Fractal geometry "took off" only after some really hard work to
show interesting and useful applications. Since then, a number
of powerful techniques for mastering the apparent complexity
(and detecting it in otherwise simple-looking formulae) have
been developed and put to use.
REBOL (as a von Neumann language in the company of Lisp, PROLOG,
etc.) gives us the ability to indulge in what I'll call "logical
fractals" whose behavior is *SEVERELY* unobvious if we aren't
aware of what we're getting into. Now, please hold that thought
for a moment, while I draw in one other connection...
In an essay (the ninth chapter of his book _Patterns_of_Software_,
Rich Gabriel suggests four characteristics which a programming
language must have to survive:
* Languages are accepted and evolve by a social process,
not a technical or technological one.
* Successful languages must have modest or minimal
computer resource requirements.
* Successful languages must have a simple performance
model.
* Successful languages must not require users [to] have
"mathematical sophistication."
REBOL succeeds admirably on #2, and we're all working on #1 via
this mailing list.
#3 is more problematic. I've never seen an "official" model of
REBOL semantics, but throughout my involvement with it I've
been trying to come up with pieces of one (e.g., my earlier
essays on SERIES! values). I still believe that there are many
parts of REBOL that could be explained precisely and simply,
but others that are not so clear. (Either in my poor head or
in fact -- witness the differences in behavior when mutations
are applied to BLOCK! versus LIST! values.)
#4 is the most "dangerous" to REBOL, in that *EVERY* vNL of
which I'm aware -- REBOL included -- requires at some point a
fair bit of sophistication to understand, or at least to
recognize when one is getting into deep waters.
TYING IT ALL TOGETHER (at last!)
I suspect that what we (computing folk in general) need before
vNL languages in general -- and REBOL in particular -- will be
widely accepted is the beginnings of a real grasp on "logical
fractals" that let us use their power effectively and (mostly)
safely. Of course, one approach is to say "Don't do that at
all!" If I take that approach, I begin to wonder why I don't
just stick to COBOL!
OTOH, if I can begin to get a grip on when and how to use such
"monsters" as:
* mezzanine-level control constructs,
* higher-order functions,
* self-modifying, stateful values,
* ...etc...
I may be able to take advantage of REBOL's power -- using it
more effectively -- and be able to explain/communicate its
benefits more persuasively -- promoting its success more
effectively.
To that end, I'm profoundly grateful to the members of this
list for their challenges, discussions, and inspiration!
-jn-
