Arbitrary limits are everywhere. You create a string variable and by =
default its length is limited to 8. You assign something to it and it =
gets silently truncated. You import a file and the line length is =
limited to 256. Of course you can change it by using the lrecl=3D =
option, but why can't SAS do it?=20
________________________________
How would one create a string variable that has a default length? =
Working from memory I can't recall seeing a default assignment of a =
character variable length, such as the eight-byte default for numeric =
variables. Setting the 'first instance' length when an INPUT process =
doesn't have the length specified may cause problems, but I wouldn't =
call it 'arbitrary'. The same goes for a default line length in a file =
import.
Proc sql is just like SQL, but not always.=20
... neither is any other implementation of SQL exactly like an ANSI SQL =
standard, or any other flavor of SQL.
GROUP BY a variable works as expected.=20
But can you guess what GROUP BY any expression does?=20
Nothing!!!=20
I'd have to see an example of this quirk. SAS allows more flexibility in =
GROUP operations than other SQL dialects.
________________________________
Error messages are not always helpful in identifying the problem. If =
logistic regression fails to provide any output except for cryptic=20
"Error: There are no valid observations",=20
what exactly does it mean? Why not just say=20
"Warning: all values of variable FOO are missing"
exclude it from the list of predictors, and go on?=20
=20
... perhaps because other patterns of missing values could make all obs =
invalid and SAS/Stat would be changing the specification of the model. I =
can't think of a situation where an analyst would prefer to see a model =
reduced automatically.
________________________________
Proc sql again. Guess what will be the name of the second variable in =
the new_table:=20
proc sql;
CREATE TABLE new_table AS
SELECT foo,=20
COUNT(*) "cnt"
FROM old_table
GROUP BY foo;
quit;
Of course it's _TEMA001, because cnt is the label, not the variable =
name. Bizarre, but you can make it work with
proc sql;
CREATE TABLE new_table AS=20
(SELECT * FROM=20
(SELECT foo,=20
COUNT(*)
FROM old_table
GROUP BY foo
) x ( foo, cnt )
);
quit;
________________________________
The query is creating a SAS dataset in which column variables have =
specific properties, such as variable labels. Again, each flavor of SQL =
has variations in syntax.
=20
You can see more telling critiques of the SAS System in the SAS-L =
Archives. I'd say that SAS is evolving at a rate consistent with a =
programming environment of its scope and depth.
S
=20
=20
=20
________________________________
From: owner-sas-***@listserv.uga.edu on behalf of toby dunn
Sent: Tue 5/8/2007 5:58 PM
To: ***@GMAIL.COM; SAS-***@LISTSERV.UGA.EDU
Subject: RE: SAS language idiosyncrasies
Hmmm SAS has plenty of problems and we often yell about them even on th
elist, you need to do your search better.
From yoru web page:
There are two ways to write comments in SAS:
/* C-like */* and Fortran-like (with trailing semicolon);
Neither of those can be nested. To comment out a block of code, one =
needs to
resort to the following trick:
%macro skip;
Stuff here is not executed
%mend skip;Why?
Well you missed one commenting type which is limited to with in a %Macro
which is the %* comment.
I would yo ulike the comments to work? Seems to me they work perfectly =
fine
the way they are.
2.) "There's a concept of NULL (missing value) in SAS" There is? Well =
now
would you like to show us an example of a Null value in a data set. As =
far
as I know if we limit ourselves to the Data Set a value is either =
missing or
has a value.
3.) "The notion of naming convention seems to elude SAS language =
designers.
Compare Proc import and Proc export: "
I wont copy all the code.... well lets see one imports a file and =
exports a
data set. So if you wanted to make any changes I would suggest:
proc import
File=3D'/somewhere/myfile.csv'
Out=3Dmydataset
dbms=3Dcsv;
run;
proc export
Data=3Dmydataset
Out=3D'/somewhere/myfile.csv'
dbms=3Dcsv;
run;
The rest of the Proc Import rant is well just stupid in my eyes as I =
hate
both and well only use them if and only if I am moding someone elses =
code,
just for the sake of fluidity in the program.
5.) Arbitrary limits are everywhere. You create a string variable and by
default its length is limited to 8. You assign something to it and it =
gets
silently truncated.
Well how long it is depends on how loose you want to make your code. =
SAS
allows you do do a lot of things whether or not you do so intelligently =
or
stupidly is well up to you. You have to live with the consequences.
6.) Proc sql is just like SQL, but not always.
GROUP BY a variable works as expected.
But can you guess what GROUP BY any expression does?
NO I repeat NO 2 languages have the same implementation of SQL.... so =
get
the hell over it already.
7.) Error messages and I would add Warnings.... yeah I agree here they =
could
use some improvement in this area.
see there I did agree with one thing you said.
8.) Proc sql again. Guess what will be the name of the second variable =
in
the new_table:
proc sql;
CREATE TABLE new_table AS
SELECT foo, COUNT(*) "cnt"
FROM old_table
GROUP BY foo;
quit;
Hmmm should SAS read your mind also.... look you dont give it a Key word =
AS
and then a unquoted hunk of text to use as a name well it does what it =
has
to do so the code will run correctly well as close as it can to correct
since You the Programmer screwed up. What I did find funny is that it =
does
use the quoted string as the label. That should at the very least =
generate
a warning or error.
Now if you want to beat the hell out of SAS do it on the correct level =
like
on its really really crappy reporting ability.... Now your talking.
Toby Dunn
You can see a lot by just looking. ~Yogi Berra
Do not seek to follow in the footsteps of the wise. Seek what they =
sought.
~Matsuo Basho
You never know what is enough, until you know what is more than enough.
~William Blake, Proverbs of Hell
From: "***@gmail.com" <***@GMAIL.COM>
Reply-To: "***@gmail.com" <***@GMAIL.COM>
To: SAS-***@LISTSERV.UGA.EDU
Subject: SAS language idiosyncrasies
Date: Tue, 8 May 2007 13:47:00 -0700
Bjarne Stroustrup once said that there are only two kinds of
programming languages:
* those people always bitch about and
* those nobody uses.
I searched SAS-L for any criticism of SAS and found almost none!
That's kind of strange since I know that SAS is widely used.
I have used SAS since it came out on the market in the early 70's. At
the time, I was delighted with the DATA step which saved me from
writing silly little FORTRAN programs to manipulate my data into the
form expected by BMDP. That DATA step is the main reason SAS blew all
its competitors out of the water. The rest, as the saying goes, is
history. Alas, when a product becomes dominant, it often endows its
developers with an undesirable arrogance and a tendancy to respond
"That's the way we do it!" to all suggestions for improvement.
I only realized the problem with SAS many years later when I studied
closely other programming languages:
SAS is probably among the worst widely used languages I
know of.
The bulk of the examples that I offer as evidence are better
formatted, hence
easier to read on my blog than they can be in this e-mail:
http://arrowmodel.com/cgi-bin/blosxom.cgi/jc/index.html#sas
.. . .
I can go on like this for a while, but I think you get the idea.
The strange thing is that people who use SAS on a day to day basis
tend not to see how unnatural it is. It looks like the Sapir-Whorf
hypothesis in action.
( http://en.wikipedia.org/wiki/Sapir-Whorf_hypothesis )
But isn't it true that all the old languages have their quirks?
No! While it s true that Cobol and Basic will rot your brain because
of the paucity of their features, many old languages were either done
right from the start, or evolved into coherent ones: LISP, for
instance, SQL, C or R (an interesting alternative to SAS for doing
statistics). Together with more recent languages like Java, or Ruby,
they are much more consistent than SAS.
_________________________________________________________________
Now you can see trouble...before he arrives
http://newlivehotmail.com/?ocid=3DTXT_TAGHM_migration_HM_viral_protection=
_0507