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

[REBOL] Re: Antwort: Re: WYSIWYG programming

From: joel:neely:fedex at: 26-Oct-2000 22:25

Hello, Holger! Holger Kruse wrote:
> As mentioned before, this is because we are extremely busy. I'll > make an attempt at a response though. In any case, this should be > considered my personal opinion only. It does not represent the > official position of REBOL Technologies... >
I'm sure that all of us who have written and deployed code for a living can understand schedule pressure. Speaking for myself, THANK YOU VERY MUCH! for taking the time to respond. I really cannot emphasize enough how much I appreciate having someone from RT giving us the benefit of your perspective on these issues! (May I respectfully reserve the right to disagree, however? ;-) PREAMBLE TO PAIN
> First of all, I consider most of what Ladislav mentioned to be > the result of "switching pain", difficulties when switching > from one language to another one, and adjusting to a different > way of thinking... >
Having used and/or taught at least a couple of dozen languages in my career, I'll be the first to acknowledge that the phenomenon you labeled "switching pain" is a real one. I've certainly seen my share of c programs written in c++, COBOL programs written in c, FORTRAN programs written in LISP, etc... However, I think it a bit hasty to dismiss the issues discussed in this thread as being primarily due to "switching pain". For my part, if that's the way it appears, then I have failed to make myself clear. Let me try to address the "pain" issue in a way that will clarify my focus. (To do so, I must use examples. The obvious tightrope-walk danger in examples is that too simple ones make the issue appear trivial and too complex ones offer a wealth of distracting side issues. I'll try to walk the rope, but ask everyone to consciously attempt to look past the examples to the issues involved.) ON COD/E On the code-vs-data topic, I hope we can stipulate that this is not an issue for this discussion. I have been pedantic on this point with some collegues who are looking at REBOL for the first time, but try to do so only when I really think they are in imminent danger of drawing a bogus conclusion. I think that the contributors to this thread all understand that REBOL does not draw that distinction in the same way that most other languages do. We would, I believe, all concur with the statement in R/CUG (page 3-3) that, "How information is processed determines whether it is code or data." However, if pressed on the terminology, I'd point out that some REBOL expressions, such as "Hi!" or 2 * 3 + 7 may be repeatedly evaluated without consequence, while others a: 0 loop 5 [a: a + a] write %answer.txt a do, in fact, have consequences on the data within the interpreter and/or on the environment (file system, etc.) If backed into the corner on the terminology, I'd suggest labeling the latter kind of expressions as "Consequences On Data/Environment" expressions, with the acronym of CODE. Of course, I sometimes forget to hit the shift key (and REBOL is case-insensitive anyway) so I trust that we all can accept "code" as equivalent to "CODE". ;-) ON THREE KINDS OF "PAIN" A programmer feels pain when the behavior of some code differs from what was intended/expected. Of course, it is always possible to tell the programmer, "It's your fault; your expectation was faulty!" Instead of simply blaming the programmer, however, let's look a little deeper in the the causes (plural!) of the pain and possible prevention. The programmer's expectations may have been based on: A) Another programming language. B) Common concepts widely used in programming and computing science. C) Other features within the same language. In general, I believe that the further one goes down this list, the less we can simply label any unfulfilled expectations as "switching pain" or blame the programmer. The further we go (especially when we reach the third item!), the more we should look to the concepts and notation of the language, the implementation of the language, and (at the very least!) the documentation of the language as being either the cause of the pain or at least the way to prevent future pain. ON FRUSTRATION The reason that the programmer's expectations were frustrated may have been based on: 1) The programmer hasn't had sufficient experience in programming (including programmers who know only one language!) 2) The programmer hasn't had sufficient experience with the language at hand (despite general experience in programming). 3) The language does not have sufficient documentation to allow the programmer to learn the language -- without exhaustive trial-and- error experimentation. 4) The language has features whose complexity requires that the programmer keep up with more "moving parts" and exceptions to be able to use them safely. 5) The language has features that are "emergent properties" rather than "designed concepts" -- that is, they are consequences of the interactions of other features of the language which even the language designer(s) may not have intended or anticipated. 6) The implementation of the language may be faulty -- compared either to its published specifications or (absent such specs) the initial intentions of its designer(s). 7) The language "grew" rather than being "designed". Again, the further we go down this list, the more we have to shift our focus to the concepts, notation, specifications, implementation, and documentation of the language (and away from the programmer) as the causes and remedies of the frustration. Note especially on #6 that the absence of a published specification means that it is not possible, even in principle, to state definitively whether a given instance of questioned behavior is an implementation bug! AFTERWORD I'm collecting specific examples of concepts and notation that I find to be complicated, inconsistent, or confusing. (Donations welcome.) This note is long enough that I won't try to append the partial list at this point. However, I'm trying very hard to focus on things that (IMHO) belong to Expectations B and C, and to Frustrations 3 thru 7. As a single example of the kind of internal inconsistency I've mentioned, consider the relationship between the order of values and their use in retrieving data by position. We can compare integer! values:
>> 0 < 1 == true >> 0 <= 1 == true
and the results of converting integer! values to other numeric types
>> to-decimal 0 < to-decimal 1 == 1 >> to-decimal 0 <= to-decimal 1 == 1
When I use integer! values to select a value, the order of the positions of retrieved values is the same as the order of the selection values.
>> foo: ["a" "b" "c" "d"] == ["a" "b" "c" "d"] >> pick foo 1 == "a" >> pick foo 2 == "b" >> fum: 1 == 1 >> foo/:fum == "a" >> fum: 2 == 2 >> foo/:fum == "b"
Now, notice that we aren't allowed to compare logic! values????
>> to-logic 0 < to-logic 1
** Script Error: Expected one of: integer! - not: logic!. ** Where: to-logic 0 < to-logic 1
>> false < true
** Script Error: Cannot use lesser? on logic! value. ** Where: false < true However, we are allowed to convert between integer! and logic! (in either direction).
>> to-integer true == 1 >> to-integer false == 0 >> (to-integer false) < (to-integer true) == true >> (to-integer to-logic 0) < (to-integer to-logic 1) == true
This seems consistent with the forbidden comparison that would apparently have "false" less than "true". [ Note in passing that the frequently-used ordering convention of "false < true" has the benefit that the boolean (or "logical" if you prefer) operator "implies" -- as in "P implies Q" -- can be written as "p <= q". I freely admit that this is an Expectation B issue. ] On the other hand:
>> pick foo true == "a" >> pick foo false == "b" >> fum: true == true >> foo/:fum == "a" >> fum: false == false >> foo/:fum == "b"
So, we can't compare logic! values, apparently due only to some type-checking rule in the comparison operators. But if we could, the way they inter-convert with integer! values would lead us to conclude that FALSE precedes TRUE. But that is inconsistent with the fact that the TRUE-th position of a block precedes the FALSE-th position of the block! Except my passing reference to common convention, all of the above discussion has to do with completely REBOL-ish things: comparing REBOL values, converting between REBOL datatypes, and using REBOL values to pick values from a block. This is only a tiny, somewhat arbitrary, example; I hope it helps convey that the issue is not simply an inexperienced programmer complaining that REBOL is not Visual-PerlGOL-2000-Octothorp! -jn-