Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[REBOL] RIP ifs-for-whomever Re:

From: vhirsch:metrohealth at: 13-Oct-2000 11:00

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
>>> <[joel--neely--fedex--com]> 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-