Date: Wed, 18 Dec 2002 14:08:46 -0500
Reply-To: Ian Whitlock <WHITLOI1@WESTAT.COM>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Ian Whitlock <WHITLOI1@WESTAT.COM>
Subject: Re: SQLheads (was RE: new "clashvars" macro)
Content-Type: text/plain; charset="iso-8859-1"
Quentin,
In part you wrote:
>>>>>>>>>>>>
While I appreciate Sig's compliment, I think in my case the emphasis should
be placed on "SQLhead **in the making** ". In the fraternity of SQLheads
(which of course includes too many listers to mention), I'm nothing but a
pledge, or even just a potential pledge.
I think part of what holds me back from pursuing SQL more (besides
laziness), is that I'm still troubled that I don't give "directions" to SQL.
That is, when I write a DATA step I feel like I am communicating directions
to SAS. When I write SQL, it feels less like I'm writing directions, and
more like I'm writing a "goal". That is, in SQL, the communication seems to
be "here is what I want, now do whatever it takes to make it". So in SQL I
may not know what is actually happening (a sort? a hash table a ...?) to
give me what I want. So I imagine it would be hard for me to debug SQL
code, since each line is not really an instruction (in some awkward sense).
I can understand how many folks enjoy this aspect of SQL, i.e. you don't
*have* to know what it's doing under the hood, and if you really want to
know, there are ways to find out. But there's some part of me (inner
control freak?) that likes the communicating explicit control of the
process, rather than just describing the desired outcome.
That said, when every once in a while I play with a SQL step to replace a
handful of DATA/PROC steps, or see some of the SQL solutions posted on the
L, I can definitely see the attraction. So I imagine I won't make it too
long without making a serious effort to expand my toolbox accordingly.
<<<<<<<<<<<<<<
You gave up control a long time ago, when you decided to write programs and
get your meat in a grocery store, instead of running it down and killing it
with a rock.
When you write
x = 2 * x ;
do you care which register(s) the work is done in? Do you care whether it
was accomplished by shifting the bits or some other means? Do you care
whether the number was stored in data memory or instruction memory?
Whatever control you feel is an illusion. Moreover, it doesn't matter,
because you are more interested in the fact X is doubled than how it go that
way. Are you not?
You have pinpointed the greatest roadblock to learning SQL, your history and
the feeling of control. Why do you care whether a sort or a hash table was
used? Well maybe the files are too big for your machine, then you have to
care. Otherwise, why? How often is the speed of you machine the limiting
factor in the problems you solve? the method may be interesting, but why
should you care in terms of solving the problem? Are you more interested in
knowing how a problem got solved, or in knowing how to solve it? You may
have to give up one to make progress with the other.
You know that it is dangerous in solving a problem to take advantage of
accidents in the data. Now think how much easier it is to control that urge
when the solution doesn't involve the method and therefore cannot take
advantage of data accidents.
Just as the DATA step has rules, so SQL has rules. In SQL, it is still a
matter of knowing what rules produce what results. Notice I say "produce
what results" not how the results were produced. Some day you will say,
"What I like about SQL, is that I have control over the results." But then
the question may be, why do you care about the details of the results? It
will then be knowing how to manipulate the agents that determine the results
that will be important.
At every stage you have to give up control of the details of the method to
get better control over solving harder problems. Striving to understand the
details is only important in that helps to provide the rules for obtaining
the solution. When the knowledge fails to help in providing the rules,
consider it intellectual entertainment or decide whether you want it.
If it helps, look at history. The first programming engineers felt like
they lost control when they could no longer flip the switches setting the
program. The 0/1 programmers felt like they lost control with the simple
mnemonics of assembly language. The assembly programmers fought losing
control to the Fortran and COBOL compilers. The C programmer fights losing
control to the SAS compiler. Now you fight losing control to an SQL
compiler that will decide the method of solution. You belong to an
illustrious line of losers, but I doubt if you stay there much longer. When
you start to solve SAS-L problems with SQL you have already committed
yourself. You just don't know it yet.
IanWhitlock@westat.com
