LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (May 2010, week 3)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
Date:         Sun, 16 May 2010 11:03:35 -0700
Reply-To:     jfh@stanfordalumni.org
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Jack Hamilton <jfh@STANFORDALUMNI.ORG>
Subject:      Re: Alternative for "goto" in do loop
Comments: To: Joe Whitehurst <joewhitehurst@gmail.com>
In-Reply-To:  <AANLkTimpULTCJaZlUGMc__WEBVqqeSBMulybPplifj20@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"

Shaw: he is a barbarian, and thinks that the customs of his tribe and island are the laws of nature.

On Sun, 16 May 2010 13:20 -0400, "Joe Whitehurst" <joewhitehurst@gmail.com> wrote:

Yes, this is precisely my point. The word "intuitive" is bandied about as though it were an attribute of something be it a software interface, programming code or a remote control for some electronic equipment or some other piece of machinery to be used by humans without regard for who those humans might be nor what their prior experiences might have been nor what the context or circumstances of their encounter with the thing being described as "intuitive" or not might be.

On Sun, May 16, 2010 at 1:03 PM, Jack Hamilton <[1]jfh@alumni.stanford.org> wrote:

"Intuitive" is one of those words that has both a general meaning and several domain-specific meanings. And since it is not always clear, even in context, which of those meanings is intended, "intuitive" may not be the best word to use. I suspect that the intended meaning in software is something like the "principle of least surprise" - the behavior is whatever surprises an experienced user of the language (or interface) the least. See:

[2]http://en.wikipedia.org/wiki/Principle_of_least_astonishmen t

[3]http://www.economicexpert.com/a/Principle:of:least:astonish ment.html The creator of Ruby had an interesting comment: Everyone has an individual background. Someone may come from Python, someone else may come from Perl, and they may be surprised by different aspects of the language. Then they come up to me and say, 'I was surprised by this feature of the language, so Ruby violates the principle of least surprise.' Wait. Wait. The principle of least surprise is not for you only. The principle of least surprise means principle of least *my* surprise. And it means the principle of least surprise after you learn Ruby very well. For example, I was a C++ programmer before I started designing Ruby. I programmed in C++ exclusively for two or three years. And after two years of C++ programming, it still surprises me. [4]http://en.wikipedia.org/wiki/Ruby_(programming_language)

Joe Whitehurst wrote:

Sid, I did not experience any irritation whatsoever at your use of the word "intuitive", and I applaud your efforts to understand SAS code. Keep up your efforts. I think you will find your efforts will pay off. I apologize if my statements make you experience any unease at all. I have an entirely different agenda and my attention to your use of "intuitive" was merely a pretext to help me pose the questions I did. So, let me withdraw my questions to you. I still hope that others in SAS-L-Dom will offers some answers to the two questions I posed to you. Joe On Sun, May 16, 2010 at 3:16 AM, Sid N <[5]nsid31@gmail.com> wrote:

Joe, First, I did not intend to irritate any one when I said that the alternative code suggested to my question in using the GOTO loops was more intuitive. What I meant to say was that my understanding of the (original) code was not spontaneous when I first came across that sequence of GOTO statements. As Arthur put it, the code did not provide the "quick insight." Does it make it an attribute of the code? I don’t actually know. When I looked at some of the other code submitted by SAS-Lers, I could make out immediately what the code is aiming for, and I could at least think of what the output would be like. This has more to do with the limited data step coding experience, and more familiarity with some of the SAS functions that I have had in the past. I am not a native English speaker. Therefore, I am not completely sure if "intuitive" is the right word to mean what I described above. May be the usage of the word was just superfluous. However, I did not quite understand your persistence in knowing what I actually meant when I used the term "intuitive." I am interested in knowing why it is annoying when someone uses the word “intuitive”? When is it actually acceptable to use that word? Couldn’t a block of code be termed intuitive in nature? Sid On Sat, May 15, 2010 at 7:35 PM, Joe Whitehurst <[6]joewhitehurst@gmail.com

wrote: Dear SAS-Lers, Sid N has not answered the questions I put to him regarding his use of

the

pesky adjective "intuitive" and one of the finest minds in all of

SAS-L-Dum

admits he has "nothing interesting or intelligent to say on the subject". Yet, we all see this pesky adjective applied not only in marketing super-hype but in many

serious

discussions about software including coding practices within the SAS

System.

Can and will any SAS-Lers venture answers to the two simple questions I

put

to Sid N? The whole nation (in Colbert's terms) is awaiting the answers. Joe On Fri, May 14, 2010 at 11:46 AM, Joe Whitehurst <

[7]joewhitehurst@gmail.com>wrote:

Sid, Your use of the word "intuitive" prompts me to ask: "Just specifically what do you mean by intuitive"? Are you asserting that "intuitive" is

an

attribute of the code? Joe Whitehurst Personal Construct Psychologist To learn more about this 21st century psychological science click any of the following links: By George Kelly Himself: A Brief Introduction to Personal Construct Psychology<

[8]http://70.88.183.165/A%20Brief%20Introduction%20to%20PCP.pd f>

Ontological Acceleration<

[9]http://70.88.183.165/Ontological_Acceleration.pdf> (superb

ideas, marginal quality media) By others: Introduction to PCP <[10]http://pages.cpsc.ucalgary.ca/~gaines/pcp/> Constructivist Psychology Network <[11]http://www.constructivistpsych.org/> Cognitive Mapping Tools<

[12]http://www.coachingnetwork.org.uk/ResourceCentre/ProductsA ndServices/RepGrid.htm

BUDDHIST MEDITATION AND PERSONAL CONSTRUCT PSYCHOLOGY<

[13]http://serendip.brynmawr.edu/bb/Pilou.html>

THE INTERNET ENCYCLOPAEDIA OF PERSONAL CONSTRUCT PSYCHOLOGY<

[14]http://www.pcp-net.org/encyclopaedia/main.html>

On Fri, May 14, 2010 at 11:31 AM, Sid N <[15]nsid31@gmail.com> wrote:

I have never thought such an innocuous post (as the original) would elicit so much discussion. Thank you everyone for sharing his/her inputs.

That's

what I like the most about SAS-L -- not just answering the question,

but

also providing some amazing perspective and background. So much here to learn! Personally, I have not felt comfortable working with the original code with that sequence of GOTO statements. I have tried other alternatives suggested in this thread; they are easily understandable and much more intuitive. Sid On Fri, May 14, 2010 at 9:24 AM, toby dunn <[16]tobydunn@hotmail.com>

wrote:

Ahhh well we will have to agree to disagree on this. I am a stright

up

GOTO hater. Can't help myself I guess, I beleive that if you have to

write

a GOTO statement (other than in extreme rare circumstances), you need

to go

back and redesign your code. There is almost always a better

approach

than

to use a GOTO. Thats just my opinion on the subject so take it for

what

ever it is worth. Reminds me of Macro Arrays. Yeah we should teach people about them,

so

that when they come across them they can rewrite the suckers in to

either

Macro list processing or one of couple oter methods that are easier

and

more

efficient. Toby Dunn "Don't bail. The best gold is at the bottom of barrels of crap." Randy Pausch "Be prepared. Luck is where preparation meets opportunity." Randy Pausch

Date: Fri, 14 May 2010 00:59:24 -0400 From: [17]s.lassen@POST.TELE.DK Subject: Re: Alternative for "goto" in do loop To: [18]SAS-L@LISTSERV.UGA.EDU Toby, In terms of pure efficiency, gotos are sometimes needed, as long as

SAS

does not have a statement to leave an outer loop. (could possibly

be

implemented as "leave <n>" where n is the number of levels you want

to

escape, 1 being the default). Even when efficiency is not paramount, I think gotos sometimes make programs easier to write, read and maintain. Regards, Søren On Thu, 13 May 2010 16:11:10 +0000, toby dunn <

[19]tobydunn@HOTMAIL.COM>

wrote:

Søren, Yes in general GOTO's are never needed. Proper loop construction,

haveing

no more than 3 levels of nesting, using proper branching, and in

SAS

coding

the proper exit condtion at the beggining of the loop. SAS does

have

Leave

and Continue statements. These aren't bad so long as the level of

nesting

and Looping is relatively simple. Th more omplex the Do-Loop the

less

one

wants to use these as they just add unneeded code complexity.

Toby Dunn "Don't bail. The best gold is at the bottom of barrels of crap." Randy Pausch "Be prepared. Luck is where preparation meets opportunity." Randy Pausch

Date: Thu, 13 May 2010 12:05:57 -0400 From: [20]s.lassen@POST.TELE.DK Subject: Re: Alternative for "goto" in do loop To: [21]SAS-L@LISTSERV.UGA.EDU Perusing Knuths execellent paper [22]http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth. pdf (Thank you, Michael!), I stumbled upon this little gem: "Of course, event indicators are not the only decent

alternatives

to

go

to

statements that have been proposed. Many authors have suggested

language

features which provide roughly equivalent facilities, but which

are

expressed in terms of exit, jumpout, break, or leave statements.

Kosaraju

[57] has proved that such statements are sufficient to express

all

programs

without go to's and without any extra computation, but only if

an

exit

from

arbitrarily many levels of control is permitted." Which seems to vindicate my personal GOTO policy quite

adequately,

namely

that GOTOs can be used instead of LEAVE when you need to break

out

of

several

levels of nested loops, and (in SAS) STOP or DELETE(/RETURN) is

too

drastic.

Thanks to you all for an entertaining and enlightening

discussion!

Søren

______________________________________________________________ ___ Hotmail is redefining busy with tools for the New Busy. Get more

from

your

inbox.

[23]http://www.windowslive.com/campaign/thenewbusy?

ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2

______________________________________________________________ ___ Hotmail is redefining busy with tools for the New Busy. Get more from

your

inbox.

[24]http://www.windowslive.com/campaign/thenewbusy?ocid=PID283 26::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2

References

1. mailto:jfh@alumni.stanford.org 2. http://en.wikipedia.org/wiki/Principle_of_least_astonishment 3. http://www.economicexpert.com/a/Principle:of:least:astonishment.html 4. http://en.wikipedia.org/wiki/Ruby_(programming_language) 5. mailto:nsid31@gmail.com 6. mailto:joewhitehurst@gmail.com 7. mailto:joewhitehurst@gmail.com 8. http://70.88.183.165/A%20Brief%20Introduction%20to%20PCP.pdf 9. http://70.88.183.165/Ontological_Acceleration.pdf 10. http://pages.cpsc.ucalgary.ca/~gaines/pcp/ 11. http://www.constructivistpsych.org/ 12. http://www.coachingnetwork.org.uk/ResourceCentre/ProductsAndServices/RepGrid.htm 13. http://serendip.brynmawr.edu/bb/Pilou.html 14. http://www.pcp-net.org/encyclopaedia/main.html 15. mailto:nsid31@gmail.com 16. mailto:tobydunn@hotmail.com 17. mailto:s.lassen@POST.TELE.DK 18. mailto:SAS-L@LISTSERV.UGA.EDU 19. mailto:tobydunn@HOTMAIL.COM 20. mailto:s.lassen@POST.TELE.DK 21. mailto:SAS-L@LISTSERV.UGA.EDU 22. http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf 23. http://www.windowslive.com/campaign/thenewbusy 24. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2

-- Brevis esse laboro, obscurus fio.

Jack Hamilton Sacramento, California jfh@alumni.stanford.org


Back to: Top of message | Previous page | Main SAS-L page