[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-
