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

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