Comments on: Anthropomorphic REBOL?

Comments on: Anthropomorphic REBOL?

At times in discussions, documentation, or error messages, REBOL may be treated as a living entity. It's not done that often, but some users find it annoying.

I remember that it was annoying in the Logo programming language. If you typed "foo", the system would respond:

I don't know how to foo

REBOL does not go that far.

On the other hand, some users find a degree of anthropomorphism to be useful. It gives them another "mind tool" to help them program REBOL.

For example, in R2.0:

>> insert 1
** Script Error: insert expected series argument of type: series port bitset

This wording was intentional. I selected that message because it put the most important element, the function name, first. However, that does make it sound a bit anthropomorphic. Just a bit.

As an experiment, in R3.0, I changed the error to:

>> insert 1
** Script Error: integer not allowed as the series argument of insert

Is that error more clear? Here the offending datatype gets first position, and the function gets the tail.

I've not gone through all the error messages and made this kind of change. The above was just a test, and right now, such changes are a lower priority over getting the system to alpha release.

But, it is something to think about. Some users care about it, others do not. I am posting this note just to get the issue into the open. I'll come back and review the comments when it comes time to revise the error messages and other documentation.

37 Comments

Comments:

Henrik
5-Sep-2006 15:59:36
integer not allowed as the series argument of insert

This doesn't specify exactly what arguments, insert can use. It says nothing about ports or bitsets, so the message is less clear, I think. More correct wording would be:
integer not allowed as the series, port or bitset argument of insert

But it sounds more like a lawyer talking to me. It would be even worse if you accepted 10 different datatypes...
I like the old method better.
Brian Wisti
5-Sep-2006 16:43:55 I share Henrik's opinion that the "not allowed" error message is not as clear as the "expected" message. Both tell me I'm using the wrong type, but the "expected" message gives me a full summary of what types I can use.
But really, so long as you never get anything like Python's "Syntax Error: Invalid Syntax", I will be pretty content.
Ladislav Mecir
5-Sep-2006 17:02:37 I prefer the R2.0 message, it is more comfortable for debugging.
J-F
5-Sep-2006 21:36:23 I also much prefer the R2.0 version. It very efficiently uses the beginning and ending position of the message. It structures the information in a very clear manner.
As a beginner programmer I need ALL the help I can get and the use of the word "expected" does that.
Beginners and casual users are very important to Rebol (or could be). Think of all those users who wished they could make their computer do what THEY want?
Keeping the R2.0 struture, I played with words like specifies, stipulates, and requires.
** Script Error: insert specifies series argument of type: series port bitset
** Script Error: insert stipulates series argument of type: series port bitset
** Script Error: insert requires series argument of type: series port bitset
As you can see, none of them give you as much information as the word "expected". Although "requires" is pretty close.
As a test I tried words with a more mecanical content: "The car expected gasoline." " The car requires gazoline." or with the ultimate inanimate object:"The rock requires..."
So, I still vote for "expected", but hey I might not be such a good judge of anthropomorphism because I live my daily life in this Orwellian Newspeak called French where everything is a he or a she ;-)
-pekr-
5-Sep-2006 22:26:01 Antropho-whatever aside - R2 aproach is simply more clear to me. Maybe it is because I am used to it already, but it just feels more right to me. R2 version imo is on pair on how arguments are laid in REBOL
insert where what vs insert what where
The 'what is at the end of R2's error message ...
Maybe we could even think of extending it by 'extended-help: [on | off], and if 'on, "help insert" would be automatically called and outputted to the console, but not sure if it would work in all cases ...
-pekr-
Norm
6-Sep-2006 0:02:46 To state that the erroneous argument is 'not allowed' is redundant to the message 'Script Error'. The error states that what was just done is not just.
To a casual programmer, and a scripting language is an attractive tool to the myriad of small tasks to do, the main quality of the language is its ease of learning. Because we do not use it daily, we repeatedly have to relearn it, not a promissing endeavor if the language spec is voluminous or error messages uninformative of what could be done. 'Not allowed' is a negative modality, it does not convey a hint on the right use of the function.
Of programming languages, Rebol is the most like natural language. Is it so bad to have fun at the way a message is turned, like we do in natural language. Rebol is not academic. It gives privilege to expressiveness. 'Expected' is the right choice to guide ALSO the casual user.
Not allowed... to 'not allow'.
Kal
6-Sep-2006 2:13:21 R2.0 method is easier to understand and provides more info
Cyphre
6-Sep-2006 4:54:16 I prefer the R2 version too.
Ladislav Mecir
6-Sep-2006 8:08:13 This error message MAKE uses looks worth considering too: >> make lit-word! 0 ** Script Error: Expected one of: word! - not: integer!
Ladislav Mecir
6-Sep-2006 8:12:35 If I combine the MAKE error report and the INSERT error report, I obtain: ** Script Error: insert expected series argument of type: series port bitset - not: integer
Ladislav Mecir
6-Sep-2006 8:57:05 When we are at it, the following does not look good:
>> 1x1 < 1x2 ** Script Error: Expected one of: pair! - not: pair!
Henrik
6-Sep-2006 9:36:46 It may not be entirely on topic, but something I'm missing is being able to see variable contents in the error message. Take Ladislav's pair example:
>> a: 1x1 >> b: 2x2 >> ... thousands of lines of code ... >> ... a and b are changing values many times throughout the code ... >> a > b ** Script Error: Expected one of: pair! - not: pair!

Now you have to probe a and b to see what the problem is.
How about being able to probe the input values and show them directly in the error message? I'm not sure how it would be formatted, but it would save a little work, not having to probe the variables manually after getting the message.
The thing is that I don't really care if the error message would be much more verbose and take up 5 console lines, if I can really get to see what is going on.
Carl Sassenrath
6-Sep-2006 13:38:59 Ladislav: yes, exactly. A similar format. Main change would be to put the "offending" datatype first, because the "expected one of" list could be quite long.
That is the main problem with the "expected" list. It can get very long.
And, we will find a better way to handle that other problem - "one of: pair! not: pair!".
Goldevil
6-Sep-2006 17:35:36 As Rebol uses a lot of common english word, maybe, for easier reading, variables and arguments can be "highlighted".
Examples:
Script Error: [insert] expected [series] argument of type: series port bitset
Script Error: INSERT expected SERIES argument of type: series port bitset
bewest
7-Sep-2006 2:19:09 how about:
Error: insert(integer) did not expect the first argument to be a
Maxim Olivier-Adlhoch
7-Sep-2006 23:20:57 unfortunately, I was hoping to reach the end of comments and find a "vitriolic" post...
but, alas, it seems so far the community is pretty unanimous or is it that anti-anthropomorphic minded users are not expressing themselves... maybe its a socialist conspiracy! ;-)
For my part, I like REBOL being friendly in the way it expresses its errors! sometimes it almost seems like it feels bad it had to report it. (we can almost read "sorry" somewhere in the message. :-)
maybe that's just Carl's kind nature filtering out the interpreter ;-)
a part from giving an extra line of info with reduced code (like henrik explains), leave the human-friendly R2 errors.. please.
Izkata
8-Sep-2006 10:39:25 I say, keep R2's format. Not only does it convey more information, but even just the word "expected"/"expects" is, in my (limited) experience, used in most C/C++/Java compilers anyway.
So for the less experienced, you'd have an error that follows natural thought easily, and for the more experienced, it more closely matches not only what they're used to, but error messages from other languages as well.
As for anthropomorphism in general - Everyone does it, whether you realize it or not: "The compiler is complaining" - "Windows is acting up" - "STUPID ALARM CLOCK!" - and so on.
Rebolek
8-Sep-2006 11:27:31 I prefer R2 format too. It may be antropomorphic, but who cares. It really doesn't matter.
Volker
8-Sep-2006 15:13:04 Its anthropomorphic to call a programming language a language. If that is ok, keep the rest too. And yes, it is easier to understand the current way.
Brian Hawley
9-Sep-2006 1:41:15 Seriously, the debate over anthropomorphism of "thinking" machines goes back to the 16th and 17th centuries. Remember that "calculator" and "computer" used to be terms that referred to humans doing much the same work, though less complex.
When it comes down to it, these machines don't "think" and are certainly not alive. But what they actually do is, within its context, not all that different from what we do in our context. This doesn't detract from what we do, far from it: Our context is so complicated and our resources so limited, the incredible hacks that our biological machines have developed over the generations to deal with this are amazing, they are deserving of respect no matter what your opinion of their origins.
Now I see the point that the actual mechanism of this computation is important, and so shouldn't be glossed over. But think of what these "anthropomorphic" terms really mean.
People have been talking about the computational processes of living beings for centuries now without really understanding the underlying mechanisms. And over the centuries we have come up with words to refer to various processes of thought (like the word "compute"). When people use these terms to refer to living beings they aren't thinking of the underlying processes, and likely don't understand them since our knowledge of that is incomplete. But we do understand the general concept that the word denotes, at least well enough to recognize it and label it.
So when we are trying to deal with a complex system, it is useful to be able to use these placeholder words that denote similar ideas in the contexts we are used to. This mental shortcut allows us to focus on the parts of the problem that matter without getting bogged down in details that are less relevant, or at least less pertinent.
When the details of the underlying implementation are important, you can bet we will be debating those too.
Pierre Johnson
9-Sep-2006 4:42:06 Past tense writing reflects an indoctrinated mind stuck in the past -- backward thinking.
"...insert expected..."
A better approach:
1. present tense
2. succinctly describe the error
3. succinctly describe the remedy

BAD: >> insert 1
** Script Error: insert expected series argument of type: series port bitset
BETTER:
>> insert 1
** Error: REBOL requires series value of type: series port bitset for INSERT
EVEN BETTER:
>> insert 1
** Error: REBOL expects series value for INSERT
allowable types: series port bitset
Robert
9-Sep-2006 5:22:17 Overall, how but just printing the arguments of the problematic word:
>> insert 1 ** Script Error: insert expected series argument of type: series port bitset ** Where: connect-to-link ** Near: insert 1 USAGE: INSERT series value /part range /only /dup count
For us advanced Rebolers this might be overkill, but for all others, that didn't remember all those Rebol words it helps a lot.
Oldes
9-Sep-2006 9:17:33 If someone has problem with the error messages (I don't have), there is still a chance how to get the error object and to provide custom user deffined error message from it:
>> if error? set/any 'err try [insert 1][probe disarm err] make object! [ code: 303 type: 'script id: 'expect-arg arg1: 'insert arg2: 'series arg3: [series! port! bitset!] near: [insert 1] where: none ] >>
Oldes
9-Sep-2006 9:23:49 I was always thinking about 'attempt function not just like a shortcut for the "error try [...]" but more like about a good place where to deal with errors how you like (for example to send the error by email if you need it, write it to log etc.)
Brian Hawley
9-Sep-2006 12:15:51 I don't know about the indoctrinated mind stuck in the past (says the guy who just brang up the 16th century :), but I agree with Pierre - present tense is better in these error messages.
John Niclasen
10-Sep-2006 8:39:15 Computer languages can be harsh and cruel to the new programmer. We're only human, and we makes mistakes, and we don't like to get hit by a hammer, when we make those mistakes. Therefore I prefer positive wording instead og negative wording in messages, and "expected" is more positive than "not allowed". Maybe it even shouldn't be called a "script error", but a "script misunderstanding" or "script confusion" or some better word. REBOL is more like a human language than other computer languages. When someone say something in a spoken language, you don't understand, you don't call it an error, do you?
Henrik
10-Sep-2006 12:06:18 John, I agree that error messages should be "positive", i.e. not a slap in the face or annoying to read. You may be reading the same message 50 times a day in different contexts. "Not allowed" has negative connotations. Although it doesn't seem so, the wordings of an error message can have a stressful, psychological impact on you. How many people see the Windows 98 "General Protection Fault" error and smile at it?
Henrik
10-Sep-2006 12:38:34 A couple of error scenarios, I usually run into:
Example 1:
>> my-add: func [a b] [add a b] >> my-add 2 5 == 7 >> my-add 2 ** Script Error: my-add is missing its b argument ** Near: my-add 2

Here you can see the context of the error, so it's relatively easy to fix.
>> all [my-add 2 t my-add 5 y] ** Script Error: add expected value2 argument of type: number pair char money date time tuple ** Where: my-add ** Near: add a b

Now you can't see the context. Where is it? Is 't defined? Is 'y? You can't tell at all. You have to dig.
I would just have liked to see:
>> all [my-add 2 t my-add 5 y] ** Script Error: add expected value2 argument of type: number pair char money date time tuple ** Where: my-add ** Near: add a b ** Parameters: my-add 2 undefined!

Or possibly dump how the input looks like in the code:
** Parameters: my-add 2 t

Another one is that REBOL asks for one input at a time where it actually requires more input. I have a tendency to forget how many arguments a function requires, so I have to fix the same bug multiple times.
Example 2:
>> / ** Script Error: / expected value1 argument of type: number pair char money time tuple ** Near: /

But this is only part of the problem. Forgetful as I am, I "fix" the bug and get another bug:
>> / 7 ** Script Error: / expected value2 argument of type: number pair char money time tuple ** Near: / 7

This could have been helped by one additional line of information:
>> / ** Script Error: / expected value1 argument of type: number pair char money time tuple ** Near: / ** Format: value1 / value2 or: / value1 value2

I was not disciplined enough to do a:
? /

so I'm just lazy right? But you can't bring up help for functions in contexts the same way with ?:
>> ? ctx-text/hilight-text ** Script Error: hilight-text is missing its face argument ** Where: ? ** Near: ctx-text/hilight-text

You can't tell that HILIGHT-TEXT requires 3 arguments. So again you have to dig.
shadwolf
11-Sep-2006 6:05:29 Anthropomofic error message
** Error: You Idiot gives an integer! to the function!/word ! [insert] While I was expecting as first argument a block! of what ever but a block!
** example -> insert [1 2] 3 ** == [1 2 3]
** End of the example.
** be more carefull next time ^^
Muahahahahaha if after that ppl still complain they just have to open a window and jump ^^ Note if rebol can detect error why he don't solve them alone and just make updates to warn the programmer ( at line 10 you forget to give a serie! so i created a blank serie and insert it on the error location before yoru given value... etc.. feeeeeeeeaaaaaaaaaaaaar that's pretty scarry)
Serriously i already find R.2.0 way pretty understandable (look at java or C/C++ compiling error message they are pretty blur...)
That's like the always in question topic about the missing debugger software for rebol wich is in my opinion absolutly not usefull since when errors comes you allways know in what function you get it so no need to get the line number to report to it.
Maybe ppl wants error message more close of all they seen before less close to the human language (this is good in my opionion for script but not applyable for on line commands)
** ERROR **
** In fonction: [Your_function]
** At line : 255
** you set an interger! as first argument of the function [insert] but i was expecting a serie!
** example: insert [1 2] 3 == [1 2 3]
Shadwolf
11-Sep-2006 6:13:10 I'm ok with henrik he shows perfectly that the main problem are not on obvious error but on the hided errors lis add a t
Maxim Olivier-Adlhoch
11-Sep-2006 23:20:20 here is the only realy issue I have with errors in general... when a mezz crashes..
in the following we get a valid "where:" value, but in some experiences, a mezz calls another one, and you are at a loss, since the where, isn't even in your code. It would be nice to have a stack trace like python does it.
we can even add molded arguments to better understand the issue...
example:
; a field [action] is defined as: [my-func face/text] ;-------------- ; my-func uses 'ATTEMPT and raises this error: ;-------------- ** Script Error: try expected block argument of type: block ** Where: attempt ** Near: if not error? set/any 'value

If I have many uses of 'ATTEMPT, many action funcs, and I have no clue what 'TRY is, then debugging this can take a hefty amount of time for such a simple thing (like Henrik points out).
my wish:
** Script Error: try expected block argument of type: block ** Where: engage > my-func > attempt > try "22" ** Near: if not error? set/any 'value

At least we have an idea where to look, and the "22" which would have been the face/text gives us an idea of what the data was in the first place.
DideC
12-Sep-2006 9:09:06 Nice though Maxim. But what happen if you try this line :
>> try system ** Script Error: try expected block argument of type: block ** Where: halt-view ** Near: try system

Should Rebol molded 'system in the error message ? Could be a bit long, couldn't it ?
Henrik
13-Sep-2006 3:32:16 Maxim, I like the Where: part really nice.
DideC, maybe there should be a limit to how much code is displayed?
Alternatively, we don't show the contents of the variable, if it's a type that has a "risk" of having large amounts of contents such as an object. I'm not sure how to display that without it becoming confusing.
Oldes
13-Sep-2006 12:34:46 The true is, that with modules there will be need to improve the information about where the error is. At least new info at which module the error is.
Scot
26-Sep-2006 21:23:25 I LOVE the R2 approach. I would like my computer to talk to me more often. Make it more anthropomorphic as far as I'm concerned.
Maxim Olivier-Adlhoch
27-Sep-2006 22:56:32 wrt where, I agree that some datatypes may generate a lot of 'noise' but a simple 20 char limit is already VERY usefull.
I usually add recognizable type: and name: attributes in many objects, which already allows me to detect what broke.
for other types, it depends, I guess... but something is always better than nothing. ;-)
Maxim Olivier-Adlhoch
27-Sep-2006 22:59:16 wrt module errors, they should at least give out %filename of module which errored. IMHO

Comments on: Anthropomorphic REBOL?

Comments:

Post a Comment: