Point to learn SPSS Statistics syntax?

[Chichi Shu]

Hi, Listers,

 

I’m not a savvy SPSS statistics user mostly because I don’t know the syntax very well.

 

I figured now that SPSS Stats incorporates Python and R, and I know both of them very well and both of them are object oriented languages with concise and clean syntax.

 

Is there any point for me to even try to learn SPSS Stats inherent Syntax?

 

Thanks!

[Jon K Peck]

I would suggest that you take a look at the Programming and Data Management book available (pdf) from the SPSS Community website (www.ibm.com/developerworks/spssdevcentral) in the Books & Articles section.

The Python and R apis are designed for using these languages with Statistics.  Without a basic understanding of syntax, you will lose a lot of the power of this combination, so it really depends on what you need to do.  Typically you would use Python to build syntax and let Statistics do the heavy lifting, or you would extend its statistical capabilities with R packages.  Since there are over 100 extensions available from the Community site, and they all or almost all are designed to fit Statistics syntax and dialogs, that is another reason to have at least a basic idea of Statistics syntax.


Jon Peck (no "h") aka Kim
Senior Software Engineer, IBM
[hidden email]
phone: [phone]




From:        Chichi Shu <[hidden email]>
To:        [hidden email],
Date:        06/13/2014 08:17 AM
Subject:        [SPSSX-L] Point to learn SPSS Statistics syntax?
Sent by:        "SPSSX(r) Discussion" <[hidden email]>

---

Hi, Listers,
 
I’m not a savvy SPSS statistics user mostly because I don’t know the syntax very well.
 
I figured now that SPSS Stats incorporates Python and R, and I know both of them very well and both of them are object oriented languages with concise and clean syntax.
 
Is there any point for me to even try to learn SPSS Stats inherent Syntax?
 
Thanks!

[David Marso]

Yeah, why bother?  What do you need it for anyway?
I would hardly call R a clean syntax!
The menagerie of packages is incredibly inconsistent and the code reads like C.
Good luck with that!
--

Chichi Shu wrote

Hi, Listers,

I’m not a savvy SPSS statistics user mostly because I don’t know the syntax very well.

I figured now that SPSS Stats incorporates Python and R, and I know both of them very well and both of them are object oriented languages with concise and clean syntax.

Is there any point for me to even try to learn SPSS Stats inherent Syntax?

Thanks!

[Ruben Geert van den Berg]

I proposed a couple of reasons for working from syntax -even if pasted from the GUI- here: http://www.spss-tutorials.com/spss-syntax-six-reasons-you-should-use-it/.

I actually feel that the ability to run huge "jobs" dynamically with Python is among those reasons.

However, IMHO, reason number one is that you must be able to prove that whatever you did was correct in case doubts are expressed regarding your results. I feel that the journal file is no reasonable substitute for syntax (http://www.spss-tutorials.com/five-reasons-for-not-relying-on-the-journal-file/).

Hope this helps in making up your mind.

Ruben

[Art Kendall]

Ruben's link is very useful.

The person who is most helped by readable syntax is yourself.  As you grow in your understanding of the analysis and develop your skills you will want to re-draft your syntax. Readability helps you, your quality reviewer, help resources like this list, your clients, opposing counsel, etc.

There are a few  things I would disagree with.

Using abbreviations for procedures saves keystrokes. Yes.  However it works against readability.

using all lower case is syntactically okay.  However, many users it useful to use upper and lower case for different kinds  of words, although color coding helps in the syntax editor it is not carried over in things like posts to discussion groups.  CamelCase can be a useful technique to enhance readability.

 If you <select all> and apply the auto-indent.  This really helps communicate the logical structure.

Also try to make all your variable names communicative to people. v1 to v10 is fine for the computer to use.  People will be better off with Age, DateofBirth, Gender, Weight@Birth, Weight@6Months, Weight@1Year.  The "to" is useful for things like test items, of some sets of variables
grammar01 to gramar20, spelling01 to spelling30, PreferredFlavor1 to PreferredFlavor6, etc.


----- Hint to Python users.
SPSS syntax not case sensitive. However, it would be a boon to readability if someone who knows Python would develop an procedure that
(1)read the list of variables from the dictionary,
(2)went through the syntax looking for variations in casing and then
(3)asked the user which casing was preferred. (or at least reported the variations to the user.)

[Chichi Shu]

Thank you very much for all your replies. Even though I'm not completely
convinced with all of them, they are all very helpful. I really appreciate
your inputs.

-----Original Message-----
From: Art Kendall
Sent: Friday, June 13, 2014 1:25 PM
To: [hidden email]
Subject: Re: Point to learn SPSS Statistics syntax?

Ruben's link is very useful.

The person who is most helped by readable syntax is yourself.  As you grow
in your understanding of the analysis and develop your skills you will want
to re-draft your syntax. Readability helps you, your quality reviewer, help
resources like this list, your clients, opposing counsel, etc.

There are a few  things I would disagree with.

Using abbreviations for procedures saves keystrokes. Yes.  However it works
against readability.

using all lower case is syntactically okay.  However, many users it useful
to use upper and lower case for different kinds  of words, although color
coding helps in the syntax editor it is not carried over in things like
posts to discussion groups.  CamelCase can be a useful technique to enhance
readability.

If you <select all> and apply the auto-indent.  This really helps
communicate the logical structure.

Also try to make all your variable names communicative to people. v1 to v10
is fine for the computer to use.  People will be better off with Age,
DateofBirth, Gender, Weight@Birth, Weight@6Months, Weight@1Year.  The "to"
is useful for things like test items, of some sets of variables
grammar01 to gramar20, spelling01 to spelling30, PreferredFlavor1 to
PreferredFlavor6, etc.


----- Hint to Python users.
SPSS syntax not case sensitive. However, it would be a boon to readability
if someone who knows Python would develop an procedure that
(1)read the list of variables from the dictionary,
(2)went through the syntax looking for variations in casing and then
(3)asked the user which casing was preferred. (or at least reported the
variations to the user.)




-----
Art Kendall
Social Research Consultants
--
View this message in context:
http://spssx-discussion.1045642.n5.nabble.com/Point-to-learn-SPSS-Statistics-syntax-tp5726458p5726463.html
Sent from the SPSSX Discussion mailing list archive at Nabble.com.

=====================
To manage your subscription to SPSSX-L, send a message to
[hidden email] (not to SPSSX-L), with no body text except the
command. To leave the list, send the command
SIGNOFF SPSSX-L
For a list of commands to manage subscriptions, send the command
INFO REFCARD

=====================
To manage your subscription to SPSSX-L, send a message to
[hidden email] (not to SPSSX-L), with no body text except the
command. To leave the list, send the command
SIGNOFF SPSSX-L
For a list of commands to manage subscriptions, send the command
INFO REFCARD

[Ruben Geert van den Berg]

@Art: those are very good points, I really appreciate that. I'll think them over a bit more. A couple of considerations from my side

I think that moving from the GUI to syntax is the single best advice for SPSS users. However, it seems to be an obstacle as well (initially at least). I'm kinda scared that the somewhat intimidating looking UPPERCASE syntax may exacerbate this obstacle. Also, I'd like to demonstrate that all the upper case isn't really necessary so you can type syntax faster. Last, I see which syntax was pasted (UPPERCASE) versus what I typed manually (lowercase). However, I do use uppercase when syntax is in the middle of normal text to make it recognizable.

I feel a bit of a bad habit is trying to descibe a variable's meaning in its name instead of its variable label (gross_monthly_income_in_euros_over_2012). But indeed, v1 to v24 may be a bit too much of the other opposite and I take the middle of the road a bit more in more recent examples ("job_type", "income").

I personally feel that most SPSS syntax is perfectly readable anyway if not abbreviated excessively. However, less experienced users may disagree. I'll think this over a bit more.

Thanks again for your solid feedback!

Ruben

[Art Kendall]

I have often said that the GUI is useful to draft some syntax.  perhaps student versions should default to <paste>.  I believe that we should encourage good analysis habits right from the beginning:  Using readable syntax, making sure I can go back and do it the way I now think it should be done, being sure the data view is complete before doing any processing, reserving sysmis for situations where the software is unable to follow instructions, understanding that using syntax is like any other writing -- it goes though drafts, etc.

Whether we call it due diligence, CYA, good programming, scientific responsibility to be transparent in analysis,  making it easier on oneself, or whatever, use of syntax is necessary.

 I like most people do not recall exactly which GUI clicks I made before I was interrupted (phone call, visitors, bathroom break, end of day, meals, etc., etc.). By using syntax I can find out what I was doing.

Of course when I started in 1972 there was only syntax.  I still redraft syntax even for the brief snippets I post to this discussion list.

Wrt to cryptic variable names, I agree that variable names should not take the place of variable labels.  I have been consulting to clients in many disciplines since 1972.  One of the biggest problems that people have in quantitative methods is to relate the analysis to the substantive nature of the argument the analysis is designed for.  A middle-of-the road approach is exactly what I attempt to model.