Comparing logic! [was Re: WYSIWYG programming]
[1/6] from: joel:neely:fedex at: 28-Oct-2000 17:42
Hi, Brett,
[rebol-bounce--rebol--com] wrote:
> Hi Joel,
>
> > That sounds good. However, natural language and the common-sense
> > expectations of 'normal' people (or even programmers when they're
> > not programming) are notorious for their ambiguity and fuzziness.
>
> Important qualities that traditional computing cannot deal with.
>
This is not really an issue of "legacy" computing versus new-age
computing (or whatever one would call it ;-). Rather it is an issue
of whether it is important to be able to reliably state what will
happen. Consider all the various sciences, engineering, software
requirements, contracts, treaties, and all the branches of law.
It's A Good Thing if a line of poetry has multiple interpretations.
It's funny when an actor utters a line that has multiple meanings,
and then the plot takes various twists when different characters
act on those differences. But when I'm buying a house, applying
for health insurance, signing an employment contract, driving over
a newly opened bridge, reading the warranty on a product I just
bought, or using a programming language, I most definitely do not
want any surprises due to hidden meanings, fine print, ambiguity,
or obscurity.
I recall a conversation involving a lawyer and some non-lawyers who
were razzing him about how unreadable most contracts are. His
reply was, "You're absolutely right. But the purpose of contract
language is not to be readable; it is to be unambiguous."
> >
> > I humbly propose that the need for precision in programming means
<<quoted lines omitted: 9>>
> until recently I would have seconded your proposal for Rebol to
> follow this goal.
Let me state clearly, in case I have miscommunicated my view, that
I am NOT proposing nor advocating any radical changes to REBOL. I
am assembling a list of areas in which I feel the details could use
some polishing, and have attempted to explain my motivations for
that effort. I have also discussed some areas in which REBOL is
sufficiently unique (compared to the general field of prog. lang.)
or subtle (in and of itself) that special care may be needed in
documenting and explaining it.
However, I do not suggest that there's anything fundamentally "wrong"
with REBOL -- if I held that view, I simply wouldn't bother. There
are, after all, plenty of other programming languages.
> Now I think otherwise.
>
> 1) If feel that "rigorous", "elegant" and "minimalist" are from
> the Mathematical space of thinking.
>
Speaking as someone with a bit of familiarity with Mathematics (2+
degrees and 12 years teaching Math and Comp Sci), I agree. I must
add in passing that most folks find my definition of Mathematics
very different from what their academic experience has led them
to believe.
> Paradoxically, I think these concepts are very subjective.
>
If by "subjective" you mean "simply a matter of opinion" then I
disagree emphatically. If you mean "sufficiently subtle that they
cannot be defined in a 15-second sound bite" or "unlikely to be
assessed reliably by someone without significant experience", then
I wholeheartedly agree.
I don't want to sound elitist here, but let me give a couple of
analogies that I believe are valid.
A master carpenter can walk into a house that is at the stud-wall
level of construction and almost instantly spot a flaw in the
framing. However, it might take him several minutes to explain
exactly what's wrong -- and the negative consequences that could
occur -- to a someone who is a ignorant of house framing as I am.
It is quite possible, in fact, that my background is so limited
that I simply won't understand his concern no matter how carefully
he explains it (although that is probably very unlikely, not
because I know much about carpentry, but because most of the good
carpenters I've been around can explain what they do fairly well).
I've also had the experience of taking a car with one or two fairly
subtle symptoms to an expert mechanic who could almost interrupt me
before I finished my description and tell me what was wrong.
So it is with elegance in Mathematics (of which Computing Science
is a close relative).
> 2) I believe one of the main aims of Rebol is to be a useful
> language. Its practical and pragmatic approach has been the
> selling factor for me to invest my time in it. That said, I do
> agree with you (and others) that it needs a more detailed
> supporting documentation set on the language, but I can accept
> that the language itself is still stabilising.
>
Agreed on all points. Actually, some folks are surprised that I
consider one of the most endearing properties of Perl that it is
conceptually much closer to natural (human) languages than it is
to most programming languages.
> 3) "precision in programming" reminded me of the often heard
> "Arrgghh! It did what I said, not what I meant!". I'm hoping
> that Rebol will succeed in reducing the occurrence of this
> phrase via dialecting.
>
Dialecting is a nice device -- and REBOL is not the only language
that uses such a device. However, it's just a device, and poor
design can afflict dialects as well as entire languages.
> I hope you don't find my comments frustrating - I am deliberately
> "coming in from a different angle". They are meant to invite the
> questioning of perhaps long held "truths". In the Rebel fashion ;)
>
Quite the contrary! Probing such a topic from as many angles as
possible is one of the most effective ways to understand it, IMHO.
I certainly spend enough time inviting questioning of perhaps more
recently held positions! (One of my favorite quotations says,
There are two kinds of fool in the world. One kind says,
"This is good because it's old." The other kind says,
"This is better because it's new."
> One last thing which has perplexed me with this whole thread.
> Your example of the ordering of logical values. Why?
>
The issue was not about an burning need for logic! values to be
considered as an ordered set. I was simply demonstrating an
inconsistency in how data values are handled. However, I admint
that this inconsistency is annoying to me, for reasons which I
illustrate below, following your next question.
REBOL lets me convert back and forth between logic! and integer!
data, with the correspondence that FALSE <-> 0 and TRUE <-> 1.
It also lets me compare/sort integer! values, but refuses to let
me compare logic! values, even though the correspondence above
clearly (to me, at least) is consistent with the interpretation
that FALSE < TRUE.
If I have two number! values, they compare in the same way as
their integer! equivalents. Two character! values also compare
in the same way as their integer! equivalents. Converting to
and from integer! preserves the ordering of these values.
It seems odd to allow ordering to be preserved over all the other
types that can interconvert with integer! and yet refuse to allow
that for logic! values.
> What do you use such a thing for?
>
Let me give a tiny example of how one could use that capability,
and why I view the inconsistency as too costly. Consider the
function defined as
tally: func [b [block!] /local c t v n] [
c: sort copy b
t: copy []
while [not tail? c] [
v: first c
n: 0
while [all [not tail? c v = first c]] [
n: n + 1
c: next c
]
append/only t reduce [v n]
]
t
]
This function just tallies up the number of occurrences of each
value in a block. If I have a block containing the ages of a
second-grade class,
ages: [7 6 7 7 8 6 8 7 7 6 6 7 7 8]
I can say
>> tally ages
== [[6 4] [7 7] [8 3]]
and learn that there are 4 six-year-olds, 7 seven-year-olds, and
3 eight-year-olds.
Bear in mind that the block could have been the result of user
input, or could have been extracted from data in a disk file, or
calculated from birthdates... it doesn't matter where the data
came from.
Sorting is a convenient way to group data for a variety of reasons,
and (depending on your application domain) Tally might be a handy
addition to your toolkit.
ALSO... We could write another function (using "ASCII art" in
/Core or /Command, or the graphical features of /View) which
would take an argument block, call Tally to get a summary, and
then draw a bar graph of the results, something like
6: ####
7: #######
8: ###
I won't bore everyone with the bar-graphing code, but my point is
that once we have Tally, we may use it either stand-alone, or
build on it to define other additions to our re-usable library.
Our little Tally function can also handle other data. Suppose
I have the home states of a group of people.
homestates: ["TN" "CA" "NY" "CA" "TN" "WA" "CA" "WA" "AR" "TN"]
>> tally homestates
== [["AR" 1] ["CA" 3] ["NY" 1] ["TN" 3] ["WA" 2]]
Now, suppose I have a block that tells me whether each of a group
of people are going on the company picnic.
>> picnic: reduce [yes no no yes yes no yes yes yes no yes yes]
== [true false false true true false true true true false true true]
(Remember, that 'yes 'no 'on 'off 'true 'false are just words that
are predefined to REBOL logic values TRUE and FALSE. I reduced the
literal block in this example to get "real" logic! data, which we
would have gotten if we were producing the true/false values from
other code.)
>> tally picnic
== [[false 4] [true 8]]
Notice: REBOL SORTS LOGIC! VALUES, using the same implied order that
we would infer from the corresponding integer values -- FALSE < TRUE.
Now, back to our Tally function... Suppose I have some student test
scores...
scores: [90 95 90 100 85 90 90 80 95 90 100 95 100]
...and I am mostly interested in the top performers. I can certainly
use Tally for that purpose...
>> tally scores
== [[80 1] [85 1] [90 5] [95 3] [100 3]]
...but wouldn't it be nice if I could see them in highest-to-lowest
order as well?
Guess what? Sort lets me supply a comparison function to cause the
ordering to be whatever I want. Let's take advantage of that to
make a nicer Tally.
tally: func [b [block!] /compare f [function!] /local c t v n] [
c: copy b
either compare [
sort/compare c :f
][
sort c
]
t: copy []
while [not tail? c] [
v: first c
n: 0
while [all [not tail? c v = first c]] [
n: n + 1
c: next c
]
append/only t reduce [v n]
]
t
]
Now I can say
>> tally/compare scores func [a b] [a > b]
== [[100 3] [95 3] [90 5] [85 1] [80 1]]
as well as
>> tally/compare homestates func [a b] [a > b]
== [["WA" 2] ["TN" 3] ["NY" 1] ["CA" 3] ["AR" 1]]
but if I try to say
>> tally/compare picnic func [a b] [a > b]
** Script Error: Cannot use greater? on logic! value.
** Where: a > b
So, I ask you, what sense does it make for REBOL to allow sorting
of values that it refuses to compare???? Doesn't common sense
(using either your sense or mine... ;-) lead us to believe that
sorting is just repeated comparison and shuffling among a bunch
of data values? Grumble, grumble, grumble...
SO NOW... In order for Tally to be as re-usable as possible, we
either need to complicate Tally with a check on the data in the
argument block (and have it ignore any custom comparison in the
case of logic! values), or we have to remember never to use
custom comparison functions with logic! values ... WAIT A MINUTE!
Remember our imaginary bar-graphing function that could be based
on Tally? Now we have to worry about whether it may call Tally
with custom comparisons as well...
Oh, what a tangled web we weave
When first we practice inconsistency!
Inconsistency puts all kinds of sand in our shoes when we start
trying to write general, reusable code. Hence my strong personal
preference for rooting it out as early as possible!
Hope this helps put my grumpiness into perspective! ;-)
-jn-
[2/6] from: brett:codeconscious at: 29-Oct-2000 14:49
> > 1) If feel that "rigorous", "elegant" and "minimalist" are from
> > the Mathematical space of thinking.
<<quoted lines omitted: 12>>
> assessed reliably by someone without significant experience", then
> I wholeheartedly agree.
Sort of. In the mathematical space yes they can be defined without
subjectivity. Outside of that space where the 15-second sound bite and
attention-deficit disorder reign supreme, a space where Rebol needs to
communicate - they are subjective. One aspect of that subjectivity is for
example the Rebol send function. This function seems minimalist to many, yet
those who know how to deconstruct that functionality will not consider it to
be part of a minimalist set of functions. That's the feel I was trying to
get at with the reference to Mathematical space and subjectivity. It depends
on your context.
...
> Guess what? Sort lets me supply a comparison function to cause the
> ordering to be whatever I want. Let's take advantage of that to
> make a nicer Tally.
>
....
> but if I try to say
> >> tally/compare picnic func [a b] [a > b]
<<quoted lines omitted: 5>>
> sorting is just repeated comparison and shuffling among a bunch
> of data values? Grumble, grumble, grumble...
Ok that is something concrete, obvious and submittable to [feedback--rebol--com]
:)
Brett.
Ps. Thanks for the other material I snipped from the post.
[3/6] from: joel:neely:fedex at: 29-Oct-2000 7:48
Hi, Brett,
[
warning: enthusiastic praise for REBOL, mixed with non-specific
philosophical rambling ahead ;-)
]
[rebol-bounce--rebol--com] wrote:
> > If by "subjective" you mean "simply a matter of opinion" then I
> > disagree emphatically. If you mean "sufficiently subtle that they
<<quoted lines omitted: 5>>
> and attention-deficit disorder reign supreme, a space where Rebol
> needs to communicate - they are subjective.
I disagree. They are not "subjective"; they are simply "not yet
learned" or "not thought through". The whole of Donald Norman's
book _The_Design_of__Everyday_Things_ is about how poor design makes
things that APPEAR simple on the surface too complicated to use.
This applies even in the most non-technical of devices and systems.
Norman gives an example illustrated with a photo, but it's such a
good one that I'll bet it'll work in words only (credit to him).
Imagine approaching a glass door with identical (mirror-image)
handles on both sides. How do you open the door? Well, most of
us have probably had this experience, and have either pushed or
pulled initially, only to find out that we guessed incorrectly
and had to stop and reverse our action to get the door open.
Now, suppose you're approaching a glass door with a vertical
handle on one side, and a flat horizontal panel across the
corresponding area on the other side. Regardless of which side
you're on, you'll probably understand immediately and intuitively
that you pull on the handle and push on the flat panel.
Same problem, same number of "moving parts", yet everyone with
whom I've discussed this illustration has immediately recognized
the second solution as more elegant.
Sometimes designers create artifacts that INITIALLY SEEM more
elegant to your "attention-deficit" general audience, simply
because there are fewer "moving parts". However, an experienced
designer may be able to use the same number of moving parts to
create something which is in the long run simpler to understand
and may be used by Joe Sixpack with more ease, accuracy, and
efficiency. Even if it takes one or two MORE moving parts, I
think we'd both agree that increased comprehensibility and utility
are the true measures.
It may require experience to predict subtle consequences of early
design decisions, and an experienced designer may very well "feel
that something's wrong" before he thinks it through in sufficient
detail to verbalize the negative consequences in concrete terms.
But Joe Sixpack usually WILL figure out over time which solution
is more elegant -- it's just that he may have to bruise his
knuckles a few more times to get the point.
As professional information systems designers, all of us have the
duty to be watching out for his knuckles!
> One aspect of that subjectivity is for example the Rebol send
> function. This function seems minimalist to many, yet those who
> know how to deconstruct that functionality will not consider it to
> be part of a minimalist set of functions. That's the feel I was
> trying to get at with the reference to Mathematical space and
> subjectivity. It depends on your context.
>
Well, let's do a touch more analysis of this example. Instead of
the function
let's consider that a function has has two aspects:
its interface and its implementation.
REBOL's INTERFACE to network protocols IS elegant and minimalist,
even though the IMPLEMENTATION is (necessarily) a bit complicated
to shield the user from all the details of socket programming.
By abstracting away from the implementation details of all of the
various network protocols to give the user a streamlined, obvious,
and consistent interface
foo: read %/export/home/mydata.text
foo: read http://www.rebol.com/
foo: read ftp://ftp.boxname.dom/pub/path/file.Z
...etc...
REBOL makes it possible for "the rest of us" to use the power of
the 'Net and concentrate on WHAT we want to do without having to
get tangled up in complex issues of HOW it is done at some low
level of protocol detail.
That's both EXCELLENT and ELEGANT, IMHO.
(And that excellence is actually why I react so strongly to the
kinds of inconsistencies we've discussed in this thread -- they
seem so out of character for such an otherwise great language!)
I think we're actually in agreement -- comprehnensibility and
utility are the true measures. Experience and lots of reading
and study on design have taught me that "simple-looking" may be
only skin deep, but true elegance goes all the way to the bone.
-jn-
[4/6] from: brett:codeconscious at: 30-Oct-2000 22:59
I liked reading your post. Its theme is basically is in accord with the
time I've spent trying to convey through design, the right paradighms to
users of my GUIs. How one design makes a function obvious to a user and
another creates such subtle confusion that the user battles on thinking they
should know but in fact only achieves to "bruise knuckles" and the integrity
of the system.
I was also reminded of Phaedrus' search for Quality in "Zen and the Art of
Motorcycle Maintenance". If I remember correctly, it basically drove him
mad. *grin*
> I think we're actually in agreement -- comprehnensibility and
> utility are the true measures.
We are. I think you have focussed for me the reason I initially responded.
Exagerating for illustration, I feared that "rigourous, elegant and
minimalist" as first priority would "raise the bar" of entry to the
language.
Anyway, back to Rebol.
Brett.
[5/6] from: rishi:picostar at: 31-Oct-2000 22:55
Hi Joel. I was wondering what subject you teach and where you teach it. Are you a professor
at a university?
Rishi
Previously, you (Joel Neely) wrote:
[6/6] from: joel:neely:fedex at: 1-Nov-2000 9:49
Hi, Rishi,
[rebol-bounce--rebol--com] wrote:
> Hi Joel. I was wondering what subject you teach and where you teach it.
> Are you a professor at a university?
>
Not currently. I have several years' experience teaching Mathematics
and Computing Science at the college/university level, but am doing
software and information design in "the real world" at this time.
-jn-
--
; Joel Neely [joel--neely--fedex--com] 901-263-4460 38017/HKA/9677
REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip
do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] {
| e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted