Not too long ago I used FORTRAN to do a Clarify-type analysis for a
model that Clarify did not support; it was easy to program with the IMSL
routines supplied with my compiler. I could have probably struggled
through to do it in Stata, or I could have learned R, but I took what
for me was the quickest and easiest out, which was FORTRAN.
I learned FORTRAN close to 40 years ago (it was taught as part of a
statistics course I took!), and I find it easy to work with as long as I
don't want to create fancy output. If I were doing a significant amount
of programming, I would switch over to C or C++ but the learning curve
does not pay for the amount I still do.
BTW, I think the SAS scripting language is based on the old PL/1
language (SAS was originally written in PL/1) not FORTRAN.
My bottom-line on stat packages is use whatever will get the job done.
Stata is good for lots of things (and relatively cheap unless you need
to buy the manuals); there are a few things that work better in SPSS,
and still others that work better in SAS, plus there are a variety of
specialized programs for particular methods that can't readily be
duplicated in the larger packages. Fortunately programs such as
Stat/Transfer make moving data among such packages easy. Regardless of
which system you use, coding commands is crucial because it lets you
easily go back and fix the inevitable errors that you will make. Some
people feel that they need to prove their knowledge by using packages
that require programming; that's fine, but I'd rather concentrate on my
substantive work and let others deal with the programming. This is a
major reason I haven't taken up R which sounds extremely powerful, but
not so powerful that it would be worth the time to learn how to do
things in R that I can do in a couple of minutes with Stata or SPSS.
Most importantly, be prepared to change packages as they evolve and
improve. I have used over the years
BMD
BMDP
OSIRIS
Microcase
Minitab
SPSS
SAS
Stata
Bass
Shazam
(and others I don't remember)
as well as programs I wrote myself many years ago (in FORTRAN and
Assembly Language) to run on systems that the then current packages did
not support, or that provided methods not available in packages.
Bert Kritzer
Robert W. Walker wrote:
> Hi All,
>
> Continuing and expanding the off-topic: BTW, it is COBOL (Common
> Business Oriented Language).
>
> I thought it silly that I had to take FORTRAN in college. In
> retrospect, I view it as one of the best forced choices that I have
> ever [sort of] made because I can always fall back on it when the
> clunky [though easier] R program that I write frustrates me. Recall
> that most of the errors that computers make are sitting in the chair
> staring at the screen!
>
> I think this is related to the original question, though. The answer
> depends on what you wish to use this package for. R expands at an
> alarming rate and tends to make it hard, though not impossible, to do
> things that you do not understand [for free]. At a minimum, it takes
> some effort! Stata has made this process ridiculously easy; indeed,
> I remember reading something recently about internal debates within
> Stata Corp. about the extent to which they should protect users from
> themselves. R does not even try [BTW, someone earlier made a comment
> about importing data to R. This is one of the easy things, try the
> \texttt{foreign} package]! But, if you know what you are doing,
> Stata makes many things quite fast and easy [at considerable cost for
> both the software and the manuals to assist you in figuring it out].
>
> Philosophically, I like the R idea because it creates incentive
> compatibility in the development of data analytic techniques and
> making such developments freely available.
>
> My $.02 is to learn statistics; this will give you a decided
> advantage! Once you know exactly what you are trying to do,
> programming is the easy part [even in C, C++, or FORTRAN].
>
> Best,
> RWW
>
> On Oct 5, 2006, at 3:28 PM, Dan Williams wrote:
>
>> Fortran still exists? I thought it remained only in the scripting
>> language
>> of SAS (and, I suppose, SPSS). Next you will tell me that COBAL is
>> still
>> used for development. With small to medium size datasets you can do
>> ANYTHING in a spreadsheet (I am talking thousands or even tens of
>> thousands
>> of observations these days). But the advantage of commercial or
>> widely
>> examined open source software is that you don't have to conduct a
>> tedious
>> audit of your math to be sure that your results are correct.
>>
>>
>>
>> -----Original Message-----
>> Hi All,
>>
>> Somewhat off topic, but something I've been wondering about.
>>
>> What do you think of this:
>>
>> "Stats packages may come and go but you can always come home to
>> Fortran(C)."
>>
>> It seems to me that entire computing environments change radically
>> every decade or so, and particular optimized ways of interacting with
>> data and instantiating current statistical practice also change
>> around that fast. Since most of us hope to have multi-decade careers,
>> I often wonder if it would be better for graduate students to learn
>> two programming languages upon arriving at graduate school (or
>> hopefully earlier): (1) one that can do most or all of what we
>> currently think are best practices in data analysis (say, R or Stata
>> now, or in earlier years, SPSS or SAS or CSA or OSIRIS (unfortunately
>> I have never used OSIRIS although I hear it was great)) AND (2) a
>> lower level programming language like fortran or C that will probably
>> exist in some way or another for the entire data-analytic life of a
>> given scholar.
>>
>> This way, when, say, us old guys don't want to install neural
>> interfaces in order to analyze our data (say, our brains are not
>> plastic enough for them to be effective or we don't want holes in our
>> heads), and R is no longer supported and doesn't do what we need (not
>> because of lack of flexibility but because in this future we only do
>> enormous genetic and MCMC and permutation style estimation with
>> billions of operations and R is at its core a slow memory hog) ----
>> then we can roll our own using good old Fortran or C --- since the
>> neural operating systems will still be written in versions of those
>> languages.
>>
>> Anyway, this post does not answer the question of exactly which
>> specialized package to learn. Jim Battista put my point of view more
>> elegantly that I could have done: "You win the jackpot -- you get to
>> learn them all." I do wonder, however, whether ensuring that folks
>> know something more enduring and lower level would allow for greater
>> adaptability and flexibility as we try to get work done while we
>> watch the fads flow by.
>>
>> Best,
>>
>> Jake
>>
>>
>> Jake Bowers
>> currently:
>> Robert Wood Johnson Health Policy Scholar, '05-'07
>> Institute for Quantitative Social Science
>> Harvard University
>>
>> on leave:
>> Assistant Professor of Political Science
>> Faculty Associate in the Center for Political Studies, ISR
>> University of Michigan
>>
>> http://www.umich.edu/~jwbowers
>>
>>
>>
>>
>> On Oct 5, 2006, at 10:04 AM, Walt Borges wrote:
>>
>>> Gosh, everyone's going to have a different opinion on this,
>>> especially
>>> on the relative value of preparing tables and graphs for publication
>>> submissions.
>>>
>>>> From an analysis standpoint, and as someone who learned all these
>>> programs over the last two years, I would list the pros and cons
>>> thus:
>>>
>>> SPSS -- pro: Good point and click features
>>> Relatively easy to work with data
>>> con: Expensive on a students' budget
>>> Program coding is not intuitively based
>>>
>>> STATA -- pro: Intuitive and simple program coding
>>> Decent point and click
>>> Simple, logical command structure
>>> You can create "do-file" programs that
>>> process
>>> data and run analytical programs;
>>> these
>>> can be assembled into master do-files that
>>> allow you to work off the
>>> original
>>> data set each session, rather than saving
>>> modified data sets (which can quickly become
>>> confusing, especially when several team members are
>>> working with the data)
>>> Decent graphics.
>>> Relatively inexpensive for students
>>>
>>> con: Inevitably you will need to deal with a data or
>>> graphics issue that will send you to
>>> the
>>> seven-volume manual. Someone in the
>>> department better have one you can use,
>>> because it's real expensive. The good news is
>>> that you will probably find the instructions there
>>> and understand them.
>>> In-program help files are incomplete and
>>> often
>>> not helpful. Example: The STATA
>>> typeface makes the percent sign,
>>> which is used in graphics commands,
>>> look like a capital N on screen. I
>>> spent
>>> four hours using the on-screen help in
>>> trying unsuccessfully to format a graph
>>> before going to the manual and discovering
>>> this
>>> annoying little problem.
>>> The program for time-series analysis is not
>>> fully developed, but the
>>> alternative
>>> software is far more expensive.
>>>
>>>
>>> R -- pro: Price: freeware.
>>> Exceptionally versatile: you do the
>>> programming,
>>> so your abilities are the limits of
>>> its
>>> capabilities. Library of add-on
>>> components for
>>> specialized analysis.
>>> Easy access to outside modules (such as
>>> WinBugs
>>> for Bayesian analysis)
>>> Excellent graphic capabilities.
>>>
>>> con: Non-intuitive, object-based programming
>>> structure (however, if you are
>>> familiar with computer programming
>>> structures, this is not too much of a
>>> problem).
>>> Importing data sets (major pain in the butt).
>>>
>>> Personally, although I learned SPSS first, I prefer Stata for most
>>> projects, although time series analysis is easier in E-Views and RATS
>>> (both very expensive). The trick is learning how to format data in
>>> sets
>>> in Stata using do-files. Once you learn that, Stata is a cheap, quick
>>> and easy way to conduct most basic analysis. For advanced analysis
>>> and
>>> Baysian, R is really the only choice.
>>>
>>> Walt Borges
>>> Doctoral candidate
>>> University of Texas-Dallas
>>>
>>>
>>> -----Original Message-----
>>> From: Political Methodology Society
>>> [mailto:[log in to unmask]] On
>>> Behalf Of Michael Plenty
>>> Sent: Wednesday, October 04, 2006 4:42 PM
>>> To: [log in to unmask]
>>> Subject: [POLMETH] R vs. Stata vs. SPSS
>>>
>>> My name is Mike and I work as an intern for a major consulting
>>> firm in
>>> Washington,DC.
>>>
>>> My company uses SPSS, as most undergraduate programs and companies,
>>> however,
>>> now that I'm beginning the thinking process for graduate school, most
>>> schools, in particular Northwestern, UChicago, and Yale, all
>>> recommend I
>>> become familiar with Stata and R.
>>>
>>> Are there any major differences between the three programs?
>>>
>>> If so, what? and what resources are out there to help me adjust?
>>>
>>> Michael Plenty
>>>
>>> **********************************************************
>>> Political Methodology E-Mail List
>>> Editor: Karen Long Jusko <[log in to unmask]>
>>> **********************************************************
>>> Send messages to [log in to unmask]
>>> To join the list, cancel your subscription, or modify
>>> your subscription settings visit:
>>>
>>> http://polmeth.wustl.edu/polmeth.php
>>>
>>> **********************************************************
>>>
>>> **********************************************************
>>> Political Methodology E-Mail List
>>> Editor: Karen Long Jusko <[log in to unmask]>
>>> **********************************************************
>>> Send messages to [log in to unmask]
>>> To join the list, cancel your subscription, or modify
>>> your subscription settings visit:
>>>
>>> http://polmeth.wustl.edu/polmeth.php
>>>
>>> **********************************************************
>>>
>>>
>>
>> **********************************************************
>> Political Methodology E-Mail List
>> Editor: Karen Long Jusko <[log in to unmask]>
>> **********************************************************
>> Send messages to [log in to unmask]
>> To join the list, cancel your subscription, or modify
>> your subscription settings visit:
>>
>> http://polmeth.wustl.edu/polmeth.php
>>
>> **********************************************************
>>
>> **********************************************************
>> Political Methodology E-Mail List
>> Editor: Karen Long Jusko <[log in to unmask]>
>> **********************************************************
>> Send messages to [log in to unmask]
>> To join the list, cancel your subscription, or modify
>> your subscription settings visit:
>>
>> http://polmeth.wustl.edu/polmeth.php
>>
>> **********************************************************
>>
>
> Robert W. Walker
> Assistant Professor
> Department of Political Science
> Program in Applied Statistics and Computation
> Washington University in Saint Louis
> Campus Box 1063
> One Brookings Drive
> Saint Louis, Missouri 63130-3899
> rww at wustl.edu
> http://rww.wustl.edu
>
> **********************************************************
> Political Methodology E-Mail List
> Editor: Karen Long Jusko <[log in to unmask]>
> **********************************************************
> Send messages to [log in to unmask]
> To join the list, cancel your subscription, or modify
> your subscription settings visit:
>
> http://polmeth.wustl.edu/polmeth.php
>
> **********************************************************
**********************************************************
Political Methodology E-Mail List
Editor: Karen Long Jusko <[log in to unmask]>
**********************************************************
Send messages to [log in to unmask]
To join the list, cancel your subscription, or modify
your subscription settings visit:
http://polmeth.wustl.edu/polmeth.php
**********************************************************
|
