|
|
|
|
|
by opensandwich
4484 days ago
|
|
Since SAS is a relatively simple language, why can't someone just write a transcompiler that supports a subset of SAS and move it to R? That way you have the best of both worlds (sort of). The most difficult thing about that is how you would treat "by" statements (SAS) vs the split-apply-combine (R). Self-plug: I sort of made a quick hack about a month ago for SAS-Python, I'm sure someone with more programming experience than me
could produce something much better (I come from a maths background). http://nbviewer.ipython.org/gist/chappers/8747253/stan_examp...
https://github.com/chappers/Stan |
|
SAS isn't a language. It's a suite of (semi-integrated) products featuring numerous languages. Key among these are the SAS DATA step (analogous to awk), the SAS Macro language (which shares terms but is in fact distinct), a number of other global languages, a number of domain-specific languages (TABULATE, LOGISTIC, GRAPH, etc.), and some proprietary implementations of general standards (SAS SQL).
The best model for mapping from SAS to R is not to try to support all of SAS's functionality within R, but to use multiple tools. When UNIX was first created, with the awk and S languages ('R' is iterated 'S', Splus is the proprietary extension of S), awk was seen as the data pre-processor for S. Today you'd likely use R (statistical analyses, graphics, matrix language), awk, Perl, Python, Ruby, or C (general programming / data manipulation), a database tool such as sqlite or Postgresql (both of which have their own considerable analysis capabilities), and other tools as appropriate.
Trying to do everything in a single tool is a domain/application mismatch.