5 ms·

I work as a SAS programmer for state government. I find it funny that anyone would set out to emulate the jumbled late 1960s hodge podge of yuck that is SAS syn

I work as a SAS programmer for state government. I find it funny that anyone would set out to emulate the jumbled late 1960s hodge podge of yuck that is SAS syntax. (I use SAS because I like data analysis and my pension plan and governments don't do open source, not because I like SAS...)

secant 9y ago
What system could governments use to replace SAS if they were so minded?
- RSZC 9y ago
  Used to work for federal healthcare contractor, primarily in SAS. File conversion was a pain, but working in Stata would generally yield runtimes roughly an order of magnitude faster.
- deleted 9y ago
  [deleted]
- dredmorbius 9y ago
  It helps a lot to think of SAS a as a set of tools, and then recognise what provides equivalent capabilities. The DATA step follows conventions very similar to awk, though what SAS offers by way of data conversion (especially from mainframe formats) is hard to provide. The fundamental concept of iterating over the input stream is useful to keep in mind. I've also found that awk is useful for writing SAS programs themselves. I bumped into this dealing with large data dictionaries and trying to make sense of them. Parsing those and generating the corresponding SAS statements, then seeing if the results made sense was far easier than coding by hand. (The dictionary, of course, failed to correspond entirely to the actual datasets, requiring mods, but the dev/test/modify cycle was far faster, and far more repeatable.) For data storage, an RDBMS backend or SQLite is probably good, though you can also use various structured files (CSV, other delimited, column-formatted, etc.) Columnar + compression buys you much of the advantages of a SAS data set in terms of size. For the various statistical and graphics capabilities, R, gnuplot, the JS plotting library, and some related bits. I'd really like to see what tools for generating dyamic SVG there are these days, as that's a graphics format that seems exquisitely suited to data-driven rendering. For advanced quantitative programming: Python or related languages and libraries. For report generation: these days I'd probably head to a lightweight markup language and Pandoc to create whatever format(s) I wanted. Or you could wire up dynamic Web output with the application engine of your choice. For application design or creating commandline / back-end tools: whatever tools you prefer, ranging from scripting languages to compiled langauges. It's been a long time since I've worked with SAS, but its Macro and app development language (which I can't even remember the name of now) are both quite crufty. The key advantage to SAS as I noted in an earlier comment is that many of the tool choices are made for you, in that that's what SAS offers you. You can go outside that set, though back in the day, few shops really seemed to be much interested in that. The problem is that the tool choices are limited, and any additional tools have significant costs. Going with free/open options liberates you, but also means you've got to litigate the tool-choice battle. That seems to be a problem mostly at shops that continue to use SAS in part -- I don't know if it's sunk-cost fallacy or other dynamics, but there's quite often resistance at both management and developer/analyst levels to going to other tools (or had been in my experience). I found that and other dyanmics sufficiently frustrating that I largely stopped using the tool decades ago, with occasional (and regrettable) relapses.
DenisM 9y ago
Funny, I just used SAS Studio for constrained optimization tasks (linear programming), for my Supply Chain Management classes, and I rather liked it. I was told I could use Python instead for the same tasks, but I liked the single-mindedness of SAS, the program pretty much writes itself.
analogic 9y ago
Gotta be the most archaic language still in common use. I mean not saying it doesn't have legitimate uses, fast well tested and a few procs with the right options can accomplish a the equivalent of a lot of Python, and I only ever learned enough to run a few datasets and port some old code to python/r/vba, but observing the crazy ass shit people did to implement any kind of logic or data transformation was enlightening. Many many "wait people actually do this" moments. Like an entire ancient programming paradigm I never knew existed.
- forkandwait 9y ago
  SAS actually combines several useful things in one seamless environment : statistics, plotting, ETL, and data management. For any one of those functions, there is some better system (R, R, perl, sql respectively), but integration can be hard. Also, it is a single purchasing decision with a standard product. Plus, a good SAS programmer can build fairly big processes and avoid brain dead IT bureaucracies. Not that I love it, but it's a niche no other single environment serves.
  - dredmorbius 9y ago
    It's not so much that integration is hard, but that any given site tends to integrate differently. The problem I've encountered with SAS specifically is that the more powerful tools are hard to gain access to (or proficiency with) given the licensing costs. I have literally been told by SAS regional sales staff that I would be better off pirating a copy of the software to gain access to it. I politely declined.
- dredmorbius 9y ago
  Antecedents from, as noted, mainframes, and APL specifically.
z29LiTp5qUC30n 9y ago
SAS Supports R, so simply write R scripts and replace the proprietary crap piece by piece. Then use cost and security issues to kick them to the curb (A newspaper article about wasted Millions usually works if you can't get management to listen to reason and a researched cost-benefit analysis)
ConceptJunkie 9y ago
I think you just answered your own question. SAS makes a lot of money, so competitors want a chance to make their own cut.

secant 9y ago

What system could governments use to replace SAS if they were so minded?

RSZC 9y ago
Used to work for federal healthcare contractor, primarily in SAS. File conversion was a pain, but working in Stata would generally yield runtimes roughly an order of magnitude faster.
deleted 9y ago
[deleted]
dredmorbius 9y ago
It helps a lot to think of SAS a as a set of tools, and then recognise what provides equivalent capabilities. The DATA step follows conventions very similar to awk, though what SAS offers by way of data conversion (especially from mainframe formats) is hard to provide. The fundamental concept of iterating over the input stream is useful to keep in mind. I've also found that awk is useful for writing SAS programs themselves. I bumped into this dealing with large data dictionaries and trying to make sense of them. Parsing those and generating the corresponding SAS statements, then seeing if the results made sense was far easier than coding by hand. (The dictionary, of course, failed to correspond entirely to the actual datasets, requiring mods, but the dev/test/modify cycle was far faster, and far more repeatable.) For data storage, an RDBMS backend or SQLite is probably good, though you can also use various structured files (CSV, other delimited, column-formatted, etc.) Columnar + compression buys you much of the advantages of a SAS data set in terms of size. For the various statistical and graphics capabilities, R, gnuplot, the JS plotting library, and some related bits. I'd really like to see what tools for generating dyamic SVG there are these days, as that's a graphics format that seems exquisitely suited to data-driven rendering. For advanced quantitative programming: Python or related languages and libraries. For report generation: these days I'd probably head to a lightweight markup language and Pandoc to create whatever format(s) I wanted. Or you could wire up dynamic Web output with the application engine of your choice. For application design or creating commandline / back-end tools: whatever tools you prefer, ranging from scripting languages to compiled langauges. It's been a long time since I've worked with SAS, but its Macro and app development language (which I can't even remember the name of now) are both quite crufty. The key advantage to SAS as I noted in an earlier comment is that many of the tool choices are made for you, in that that's what SAS offers you. You can go outside that set, though back in the day, few shops really seemed to be much interested in that. The problem is that the tool choices are limited, and any additional tools have significant costs. Going with free/open options liberates you, but also means you've got to litigate the tool-choice battle. That seems to be a problem mostly at shops that continue to use SAS in part -- I don't know if it's sunk-cost fallacy or other dynamics, but there's quite often resistance at both management and developer/analyst levels to going to other tools (or had been in my experience). I found that and other dyanmics sufficiently frustrating that I largely stopped using the tool decades ago, with occasional (and regrettable) relapses.

DenisM 9y ago

Funny, I just used SAS Studio for constrained optimization tasks (linear programming), for my Supply Chain Management classes, and I rather liked it. I was told I could use Python instead for the same tasks, but I liked the single-mindedness of SAS, the program pretty much writes itself.

analogic 9y ago

Gotta be the most archaic language still in common use. I mean not saying it doesn't have legitimate uses, fast well tested and a few procs with the right options can accomplish a the equivalent of a lot of Python, and I only ever learned enough to run a few datasets and port some old code to python/r/vba, but observing the crazy ass shit people did to implement any kind of logic or data transformation was enlightening. Many many "wait people actually do this" moments. Like an entire ancient programming paradigm I never knew existed.

forkandwait 9y ago
SAS actually combines several useful things in one seamless environment : statistics, plotting, ETL, and data management. For any one of those functions, there is some better system (R, R, perl, sql respectively), but integration can be hard. Also, it is a single purchasing decision with a standard product. Plus, a good SAS programmer can build fairly big processes and avoid brain dead IT bureaucracies. Not that I love it, but it's a niche no other single environment serves.
- dredmorbius 9y ago
  It's not so much that integration is hard, but that any given site tends to integrate differently. The problem I've encountered with SAS specifically is that the more powerful tools are hard to gain access to (or proficiency with) given the licensing costs. I have literally been told by SAS regional sales staff that I would be better off pirating a copy of the software to gain access to it. I politely declined.
dredmorbius 9y ago
Antecedents from, as noted, mainframes, and APL specifically.

z29LiTp5qUC30n 9y ago

SAS Supports R, so simply write R scripts and replace the proprietary crap piece by piece. Then use cost and security issues to kick them to the curb (A newspaper article about wasted Millions usually works if you can't get management to listen to reason and a researched cost-benefit analysis)

ConceptJunkie 9y ago

I think you just answered your own question. SAS makes a lot of money, so competitors want a chance to make their own cut.