SPSSX Discussion

Syntax color code issues

Classic

List

Threaded

27 messages Options

HBaize

Re: Syntax color code issues

Kyle,
I didn't find your comments arrogant or dismissive.
I think you are right that the full, unabreviated syntax should be offered
in the autofill and paste functions, but the color coding should follow the
abreviations used by the parser in addition to the complete keyword.
Users will notice the color change after three characters, eventually
they'll learn that they can abreviate. As I said, the autofill and paste
with full verbose syntax is good for beginners. In the spirit of being
consistent and supporting old code, the color coding shoud follow
the code as it works. If...

freq var1.

works then the accurate feedback to the user would be proper
color coding of the syntax. In other words, it is **disinformation**
as currently programmed. As for the objection that some abreviations
are supported and other not, causing confusing, I'd say that
accurate information is less confusing than giving inaccurate feedback
concerning what code will execute.

I also strongly disagree with the suggestion that

freq var1.

is more confusing or more difficult to read than

FREQUENCIES VARIABLES=var1
/ORDER=ANALYSIS.

Not even for the novice. It is rare that a novice user needs to be
aware of the order option, certainly they don't need to include that
default everytime they run a frequencies procedure. People can easily
learn that "freq" is the same as FREQUENCIES and that most options are
default. Not even a novice needs to explicity acknowledge all the default
options. Seriously, the abreviations aren't that difficult or confusing.
Ideally users will become so familiar with the syntax (as some of us have)
that it is like a second language. Then they will type code quickly.

Documentation is important but there is no reason to repeat
"/order=analysis" over and over and over or spell out all 11 characters
of the word frequencies. That isn't documentation, it is just
verbosity and doesn't clarify anything for novice users that are
unfamiliar with the options. They would need to look in the
documentation to know what "/order=analysis" means. Since it
is default anyway, how does that help them?

Harold

Weeks, Kyle wrote

Please allow me to clarify. The term "best practice" is not meant in a judgmental way. If we were teaching someone to write syntax from scratch using abbreviated syntax would not be the method we would recommend. This behavior is implemented inconsistently throughout the system.

The thought was that if we color coded that syntax, it could be very confusing to the user about why some abbreviations are supported, while others are unsupported.

Marks, Jim

Re: Syntax color code issues

In reply to this post by Daniel Robertson

Please see page 21 of the command syntax manual v15.

"Many command names and keywords can be abbreviated to the first three
or more characters that can be resolved without ambiguity. For example,
COMPUTE can be abbreviated to COMP but not COM because the latter does
not adequately distinguish it from COMMENT".

Agree that it goes back to SPSS on mainframes, but it's hard to see the
abbreviations as "an undocumented, unsupported, idiosyncratic aspect of
SPSS syntax that hearkened back to some well-outdated release."

The core of the program-- the engine that runs the code-- reads
abbreviations. The in-line help function reads abbreviations. Some
features of the newly added syntax engine do not read abbreviations.

Seems like a reasonable enhancement for v18 (or v17.01).

--jim

-----Original Message-----
From: SPSSX(r) Discussion [mailto:[hidden email]] On Behalf Of
Daniel Robertson
Sent: Wednesday, December 10, 2008 1:59 PM
To: [hidden email]
Subject: Re: Syntax color code issues

Hmm. The original poster's complaint was that the syntax editor color
coding in V17 did not accommodate an undocumented, unsupported,
idiosyncratic aspect of SPSS syntax that hearkened back to some
well-outdated release. I too avail myself of such shortcuts -- and it
might be nice in a future release to allow the user to customize the
coloring behavior -- but I fail to see why SPSS should be expected to
support such uses of its product. The color coding and auto-complete
features may, of course, be turned off, which I find useful when looking
at old or idiosyncratic syntax.

Further, I think it's inaccurate to characterize Kyle's frequently
posted invitation to provide feedback to SPSS (of which I have availed
myself) as arrogant or dismissive. SPSS is an imperfect tool, but a
useful one -- and it's not the only tool that I use -- but there are
procedures in place for addressing problems and concerns. I hope we can
avoid turning this list into a complaint line.

Respectfully,

Dan R

Whanger, J. Mr. CTR wrote:
> Kyle,
>
> I have to say, the tone and perspective you've taken is,
unfortunately,
> typical of the way in which SPSS has responded for the last few years
to
> reasonable, appropriate, and legitimate criticisms of new versions of
> software. In addition to the example below, criticisms of changes in
> functionality have been met with denials that functionality has
changed
> and defended with illogical arguments premised upon the ridiculous
> notion that because the information or process is available elsewhere
> within the program, there was no change in functionality. What is one
> to conclude from this behavior? Either, there is a substantial lack
of
> understanding about "functionality" and/or there is a lack of concern
> for how changes impact existing customers. Although I have used SPSS
for

> a long time, this consistently arrogant, condescensing, and dismissive
> attitude has resulted in my considering using different software.
>
> Regards,
>
> Jim
>
>
> -----Original Message-----
> From: SPSSX(r) Discussion [mailto:[hidden email]] On Behalf

Of
> Weeks, Kyle
> Sent: Wednesday, December 10, 2008 12:21 PM
> To: [hidden email]
> Subject: Re: Syntax color code issues
>
> Harold, would you like to beta test future versions of SPSS
Statistics?

> Also, would you like to serve on the Customer Advisory Board? This
> would consist of answering ad-hoc questions on a variety of issues as
> your time permits.
>
> I would like to also extend these invitations to others on the list as
> well. If you are interest please let me know.
>
> Regards.
>
> Kyle
>
>
> -----Original Message-----
> From: SPSSX(r) Discussion [mailto:[hidden email]] On Behalf

Of
> HBaize
> Sent: Wednesday, December 10, 2008 11:06 AM
> To: [hidden email]
> Subject: Re: Syntax color code issues
>
> Unfortunately myself and other long time syntax users were not part of
> "great deal of customer input" perhaps because users like myself have
> felt abandoned for decades and are not actively communicating with
SPSS
> inc.
>
> My last comment in the previous post addresses the mistaken idea that
> all users are novices who formerly relied on the GUI. A syntax color
> coding and autofill use the same ugly all caps verbose syntax as the
> paste function of the GUI. I don't want that. If I did I'd type it in
> myself in that ugly format. The autofill and paste function are fine
for
> learning the syntax, but if you really know it you just type and you
> don't waste time typing default options or holding down the caps lock
> key.
>
> In my case I have hundreds of syntax files going back about 20 years.
If
> I read them into the new color coding editor only about one third of
the

> keywords will be highlighted because they're abbreviated. Why couldn't
> the editor use the same logic as the syntax parser? I'm not going to
> revert to a simple learning mode of a novice just to have color.
> Here's an example. If I want to do a simple bivariate correlation I
> type:
>
> cor var=varone vartwo.
>
> The GUI would paste:
>
> CORRELATIONS
> /VARIABLES=varone vartwo
> /PRINT=TWOTAIL NOSIG
> /MISSING=PAIRWISE.
>
> I much prefer the way I type it. If you really know the syntax the

first
> one is both easier to type and easier to read. The only advantage of
the
> verbose format of the GUI paste function is in helping novices learn
the
> syntax. The all caps is just a holdover from the mainframe days. It is
> ugly and anyone active in on-line communities considers all caps to be
> shouting. It is unnecessary. The parser is not case sensitive. On what
> basis is it "best practice" to use all caps and verbose syntax? Where
is

> the evidence?
>
>
>>> The abbreviation rules are not uniform across procedures and are
>>> really
>>>
> not best practice.<<
>
> The syntax itself is not uniform across procedures. I would argue the
> three character keyword abbreviation is one of the most consistent
> features across procedures.
>
> All that would be necessary to make users like myself happy would be

to
> program the color coding using the same rules as the syntax parser. If
> you think about it that is the right way to do it. It is inconsistent
to
> use different rules for the editor than for the syntax parser. It
would
> not take anything away from the training of new users though autofill
or

> the paste function, but it would make the color coding fit the real
> syntax of the parser and would work with old user typed syntax files
> just as well as those ugly GUI pasted files.
>
> Harold R. Baize, PhD
> Evaluations
> Butte County Behavioral Health
>
>
> I am not sure I understand the last comment. The new syntax editor

was
> a direct response to customer demand and was implemented with a great
> deal of customer input.
>
> The behavior mentioned below that originally started this thread, in
> which abbreviated syntax is not color coded, is actually by design.
The
> abbreviation rules are not uniform across procedures and are really
not

> best practice. The syntax that worked previous will continue to work,
> it just will not get color coded as well formed syntax.
>
> Regards.
>
> Kyle Weeks, Ph.D.
> Director of Product Strategy, SPSS Statistics SPSS Inc.
> [hidden email]
> www.spss.com
> SPSS Inc. helps organizations turn data into insight through

predictive
> analytics.
>
>
> -----Original Message-----
> From: SPSSX(r) Discussion [mailto:[hidden email]] On Behalf
Of
> HBaize
> Sent: Wednesday, December 10, 2008 9:44 AM
> To: [hidden email]
> Subject: Re: Syntax color code issues
>
> I'm glad it works for you. The GUI is fine for a lot of people too,
but

> logically it should work the same as the syntax parser. I think SPSS
> should provide better support for syntax users because if we all jump
> ship to R it will eventually sink SPSS inc.
>
>
>
> --
>
>
>

--
Daniel Robertson
Senior Research and Planning Associate
Institutional Research and Planning
Cornell University / irp.cornell.edu

=====================
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

Art Kendall

Re: Syntax color code issues

I concur. It would make a nice enhancement.

Since I am a strong believer in readability, I spell out the commands
and options. However, it would be a good idea if the editor recognized
"concise command language" as it is called on the VAX computers for
decades, also has a setting to automatically fill in the rest (or not)
as the user chose.

Art Kendall
Social Research Consultants

Marks, Jim wrote:

> Please see page 21 of the command syntax manual v15.
>
> "Many command names and keywords can be abbreviated to the first three
> or more characters that can be resolved without ambiguity. For example,
> COMPUTE can be abbreviated to COMP but not COM because the latter does
> not adequately distinguish it from COMMENT".
>
> Agree that it goes back to SPSS on mainframes, but it's hard to see the
> abbreviations as "an undocumented, unsupported, idiosyncratic aspect of
> SPSS syntax that hearkened back to some well-outdated release."
>
> The core of the program-- the engine that runs the code-- reads
> abbreviations. The in-line help function reads abbreviations. Some
> features of the newly added syntax engine do not read abbreviations.
>
> Seems like a reasonable enhancement for v18 (or v17.01).
>
> --jim
>
> -----Original Message-----
> From: SPSSX(r) Discussion [mailto:[hidden email]] On Behalf Of
> Daniel Robertson
> Sent: Wednesday, December 10, 2008 1:59 PM
> To: [hidden email]
> Subject: Re: Syntax color code issues
>
> Hmm. The original poster's complaint was that the syntax editor color
> coding in V17 did not accommodate an undocumented, unsupported,
> idiosyncratic aspect of SPSS syntax that hearkened back to some
> well-outdated release. I too avail myself of such shortcuts -- and it
> might be nice in a future release to allow the user to customize the
> coloring behavior -- but I fail to see why SPSS should be expected to
> support such uses of its product. The color coding and auto-complete
> features may, of course, be turned off, which I find useful when looking
> at old or idiosyncratic syntax.
>
> Further, I think it's inaccurate to characterize Kyle's frequently
> posted invitation to provide feedback to SPSS (of which I have availed
> myself) as arrogant or dismissive. SPSS is an imperfect tool, but a
> useful one -- and it's not the only tool that I use -- but there are
> procedures in place for addressing problems and concerns. I hope we can
> avoid turning this list into a complaint line.
>
> Respectfully,
>
> Dan R
>
> Whanger, J. Mr. CTR wrote:
>
>> Kyle,
>>
>> I have to say, the tone and perspective you've taken is,
>>
> unfortunately,
>
>> typical of the way in which SPSS has responded for the last few years
>>
> to
>
>> reasonable, appropriate, and legitimate criticisms of new versions of
>> software. In addition to the example below, criticisms of changes in
>> functionality have been met with denials that functionality has
>>
> changed
>
>> and defended with illogical arguments premised upon the ridiculous
>> notion that because the information or process is available elsewhere
>> within the program, there was no change in functionality. What is one
>> to conclude from this behavior? Either, there is a substantial lack
>>
> of
>
>> understanding about "functionality" and/or there is a lack of concern
>> for how changes impact existing customers. Although I have used SPSS
>>
> for
>
>> a long time, this consistently arrogant, condescensing, and dismissive
>> attitude has resulted in my considering using different software.
>>
>> Regards,
>>
>> Jim
>>
>>
>> -----Original Message-----
>> From: SPSSX(r) Discussion [mailto:[hidden email]] On Behalf
>>
> Of
>
>> Weeks, Kyle
>> Sent: Wednesday, December 10, 2008 12:21 PM
>> To: [hidden email]
>> Subject: Re: Syntax color code issues
>>
>> Harold, would you like to beta test future versions of SPSS
>>
> Statistics?
>
>> Also, would you like to serve on the Customer Advisory Board? This
>> would consist of answering ad-hoc questions on a variety of issues as
>> your time permits.
>>
>> I would like to also extend these invitations to others on the list as
>> well. If you are interest please let me know.
>>
>> Regards.
>>
>> Kyle
>>
>>
>> -----Original Message-----
>> From: SPSSX(r) Discussion [mailto:[hidden email]] On Behalf
>>
> Of
>
>> HBaize
>> Sent: Wednesday, December 10, 2008 11:06 AM
>> To: [hidden email]
>> Subject: Re: Syntax color code issues
>>
>> Unfortunately myself and other long time syntax users were not part of
>> "great deal of customer input" perhaps because users like myself have
>> felt abandoned for decades and are not actively communicating with
>>
> SPSS
>
>> inc.
>>
>> My last comment in the previous post addresses the mistaken idea that
>> all users are novices who formerly relied on the GUI. A syntax color
>> coding and autofill use the same ugly all caps verbose syntax as the
>> paste function of the GUI. I don't want that. If I did I'd type it in
>> myself in that ugly format. The autofill and paste function are fine
>>
> for
>
>> learning the syntax, but if you really know it you just type and you
>> don't waste time typing default options or holding down the caps lock
>> key.
>>
>> In my case I have hundreds of syntax files going back about 20 years.
>>
> If
>
>> I read them into the new color coding editor only about one third of
>>
> the
>
>> keywords will be highlighted because they're abbreviated. Why couldn't
>> the editor use the same logic as the syntax parser? I'm not going to
>> revert to a simple learning mode of a novice just to have color.
>> Here's an example. If I want to do a simple bivariate correlation I
>> type:
>>
>> cor var=varone vartwo.
>>
>> The GUI would paste:
>>
>> CORRELATIONS
>> /VARIABLES=varone vartwo
>> /PRINT=TWOTAIL NOSIG
>> /MISSING=PAIRWISE.
>>
>> I much prefer the way I type it. If you really know the syntax the
>>
> first
>
>> one is both easier to type and easier to read. The only advantage of
>>
> the
>
>> verbose format of the GUI paste function is in helping novices learn
>>
> the
>
>> syntax. The all caps is just a holdover from the mainframe days. It is
>> ugly and anyone active in on-line communities considers all caps to be
>> shouting. It is unnecessary. The parser is not case sensitive. On what
>> basis is it "best practice" to use all caps and verbose syntax? Where
>>
> is
>
>> the evidence?
>>
>>
>>
>>>> The abbreviation rules are not uniform across procedures and are
>>>> really
>>>>
>>>>
>> not best practice.<<
>>
>> The syntax itself is not uniform across procedures. I would argue the
>> three character keyword abbreviation is one of the most consistent
>> features across procedures.
>>
>> All that would be necessary to make users like myself happy would be
>>
> to
>
>> program the color coding using the same rules as the syntax parser. If
>> you think about it that is the right way to do it. It is inconsistent
>>
> to
>
>> use different rules for the editor than for the syntax parser. It
>>
> would
>
>> not take anything away from the training of new users though autofill
>>
> or
>
>> the paste function, but it would make the color coding fit the real
>> syntax of the parser and would work with old user typed syntax files
>> just as well as those ugly GUI pasted files.
>>
>> Harold R. Baize, PhD
>> Evaluations
>> Butte County Behavioral Health
>>
>>
>> I am not sure I understand the last comment. The new syntax editor
>>
> was
>
>> a direct response to customer demand and was implemented with a great
>> deal of customer input.
>>
>> The behavior mentioned below that originally started this thread, in
>> which abbreviated syntax is not color coded, is actually by design.
>>
> The
>
>> abbreviation rules are not uniform across procedures and are really
>>
> not
>
>> best practice. The syntax that worked previous will continue to work,
>> it just will not get color coded as well formed syntax.
>>
>> Regards.
>>
>> Kyle Weeks, Ph.D.
>> Director of Product Strategy, SPSS Statistics SPSS Inc.
>> [hidden email]
>> www.spss.com
>> SPSS Inc. helps organizations turn data into insight through
>>
> predictive
>
>> analytics.
>>
>>
>> -----Original Message-----
>> From: SPSSX(r) Discussion [mailto:[hidden email]] On Behalf
>>
> Of
>
>> HBaize
>> Sent: Wednesday, December 10, 2008 9:44 AM
>> To: [hidden email]
>> Subject: Re: Syntax color code issues
>>
>> I'm glad it works for you. The GUI is fine for a lot of people too,
>>
> but
>
>> logically it should work the same as the syntax parser. I think SPSS
>> should provide better support for syntax users because if we all jump
>> ship to R it will eventually sink SPSS inc.
>>
>>
>>
>> --
>>
>>
>>
>>
>
> --
> Daniel Robertson
> Senior Research and Planning Associate
> Institutional Research and Planning
> Cornell University / irp.cornell.edu
>
> =====================
> 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
>
>
>

Art Kendall
Social Research Consultants

Peck, Jon

Re: Syntax color code issues

While I certainly abbreviate command names when doing something ad hoc interactively, if I am building a job that will be used in the future or by others, I always spell out the full names in order to enhance readability and make sure that ambiguities are clearly resolved. (And I'll type lower case for ad hoc use but capitalize command names, subcommands, and keywords when building a job in order to set them apart from other specifications in the commands.)

I should point out that there is a new issue with abbreviations that people should be aware of. Since, starting with version 16, users can define their own commands via the extension mechanism, you won't always know how the command names will be resolved on another system. Extension commands take priority over built-in commands, but they, like most newer built-in syntax, do not permit abbreviation. So I could define an extension named FREQ. That would override FREQUENCIES if it were so abbreviated but not if it were spelled out in full. We recommend that the first word of an extension command name be the author or organization in order to minimize name collisions, but this is just a style recommendation.

This issue, of course, has always been there with macros, but they have to be loaded explicitly. Extension commands are automatically loaded, so a user may not even be aware that they have been added to the command table. Extension commands will be color coded if their xml definition has been copied to the syntax_xml subdirectory. That distinguishes them from command abbreviations.

Some rambling Saturday morning thoughts.

-Jon Peck

-----Original Message-----
From: SPSSX(r) Discussion [mailto:[hidden email]] On Behalf Of Art Kendall
Sent: Saturday, December 13, 2008 5:33 AM
To: [hidden email]
Subject: Re: [SPSSX-L] Syntax color code issues

I concur. It would make a nice enhancement.

Since I am a strong believer in readability, I spell out the commands
and options. However, it would be a good idea if the editor recognized
"concise command language" as it is called on the VAX computers for
decades, also has a setting to automatically fill in the rest (or not)
as the user chose.

Art Kendall
Social Research Consultants

Marks, Jim wrote:

=====================
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

HBaize

Re: Syntax color code issues

I don't think the full keyword improves readability. There are perhaps
two dozen keywords that make up 90% of syntax. Any user that
breaks free of the GUI and learns syntax can easily learn the
abbreviations of these keywords. I think they should learn them.

The insistence on verbose code is a mistake and one that is
pervasive and has increased since the switch to supporting the
GUI rather than syntax users. Take for example the new keyword to
set assumed string width. It is ASSUMEDSTRWIDTH. When I first ran
into that it angered me. You've got to be kidding, fifteen characters
for an option that isn't typically necessary. Of course I experimented
and discovered that there is no abbreviation for those 15 characters.

Hey why stop at 15? Why wasn't it ASSUMEDSTRINGWIDTH or
ASSUMED_STRING_WIDTH? Aren't those more "readable." No they
are not. There isn't a convention or logic behind this, it is just
a bad decision.

Whether verbose style is preferable to terse syntax is debatable,
but in either case the color coding should follow the syntax parser.
Then users will know what is necessary for their syntax to run.

Harold Baize, PhD
Butte County Department of Behavioral Health

Peck, Jon wrote

While I certainly abbreviate command names when doing something ad hoc interactively, if I am building a job that will be used in the future or by others, I always spell out the full names in order to enhance readability and make sure that ambiguities are clearly resolved. (And I'll type lower case for ad hoc use but capitalize command names, subcommands, and keywords when building a job in order to set them apart from other specifications in the commands.

-Jon Peck

Ian Martin-2

Re: Syntax color code issues

I can't comment upon the colour coding issue since V.17 is not yet
available through my institution.

However, I will say that after 30 years of using SPSS, I have now
mostly "broken free" of using the syntax editor, and now usually rely
on GUI. The use of one or the other is not necessarily the mark of
better expertise, but rather of the demands upon the user, and the
user's workflow. I have written syntax in SPSS and many other
programmes, but it is NOT always the most efficient approach. I do
not feel the GUI or those who use it -- for whatever reason -- merit
the dismissive comments I hear from time to time on this listserv.

I can quite understand that typing syntax is an efficient method for
those engaged in repetitive analyses of the same or similar datasets,
such as quarterly or monthly sales or patient data. On the other
hand, there are lots of people who get wildly different datasets at
frequent intervals, sometimes with thousands of variables, and do
different analyses on each dataset, then never see those data or
analyses again.

regards,
Ian Martin

Ian D. Martin, Ph.D.
Aquatic Ecologist

On 15 Dec, 2008, at 12:01 PM, HBaize wrote:

> I don't think the full keyword improves readability. There are perhaps
> two dozen keywords that make up 90% of syntax. Any user that
> breaks free of the GUI and learns syntax can easily learn the
> abbreviations of these keywords. I think they should learn them.
>
> The insistence on verbose code is a mistake and one that is
> pervasive and has increased since the switch to supporting the
> GUI rather than syntax users. Take for example the new keyword to
> set assumed string width. It is ASSUMEDSTRWIDTH. When I first ran
> into that it angered me. You've got to be kidding, fifteen characters
> for an option that isn't typically necessary. Of course I experimented
> and discovered that there is no abbreviation for those 15 characters.
>
> Hey why stop at 15? Why wasn't it ASSUMEDSTRINGWIDTH or
> ASSUMED_STRING_WIDTH? Aren't those more "readable." No they
> are not. There isn't a convention or logic behind this, it is just
> a bad decision.
>
> Whether verbose style is preferable to terse syntax is debatable,
> but in either case the color coding should follow the syntax parser.
> Then users will know what is necessary for their syntax to run.
>
> Harold Baize, PhD
> Butte County Department of Behavioral Health
>
>
> Peck, Jon wrote:
>>
>> While I certainly abbreviate command names when doing something ad
>> hoc
>> interactively, if I am building a job that will be used in the
>> future or
>> by others, I always spell out the full names in order to enhance
>> readability and make sure that ambiguities are clearly resolved.
>> (And
>> I'll type lower case for ad hoc use but capitalize command names,
>> subcommands, and keywords when building a job in order to set them
>> apart
>> from other specifications in the commands.
>>
>> -Jon Peck
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Syntax-color-
> code-issues-tp20918896p21017576.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

HBaize

Re: Syntax color code issues

I didn't mean to offend GUI users, but I have my opinions.
We don't need to repeat the well documented pros and cons of
GUI versus code.

As you say, nothing is "always" the most efficient approach,
but let us not miss the irony. This thread is about how
the editor has implemented support for color coding of syntax.

>>On the other
hand, there are lots of people who get wildly different datasets at
frequent intervals, sometimes with thousands of variables, and do
different analyses on each dataset, then never see those data or
analyses again. <<

I couldn't imagine a stronger argument for using syntax. If they were
wise they would save their syntax to document what they did with
those "wildly different data sets." Oh wait they can't,
they're using GUI. :-)

I can't even begin to address your dismissive attitude toward psychiatric
epidemiology or mental health service research as mere "patient data." ;-)

Ian Martin-2 wrote

I can't comment upon the colour coding issue since V.17 is not yet
available through my institution.

However, I will say that after 30 years of using SPSS, I have now
mostly "broken free" of using the syntax editor, and now usually rely
on GUI. The use of one or the other is not necessarily the mark of
better expertise, but rather of the demands upon the user, and the
user's workflow. I have written syntax in SPSS and many other
programmes, but it is NOT always the most efficient approach. I do
not feel the GUI or those who use it -- for whatever reason -- merit
the dismissive comments I hear from time to time on this listserv.

I can quite understand that typing syntax is an efficient method for
those engaged in repetitive analyses of the same or similar datasets,
such as quarterly or monthly sales or patient data. On the other
hand, there are lots of people who get wildly different datasets at
frequent intervals, sometimes with thousands of variables, and do
different analyses on each dataset, then never see those data or
analyses again.

regards,
Ian Martin

Ian D. Martin, Ph.D.
Aquatic Ecologist