SAS code works after 43 years: that's great or that's horrible?

[mcarniello]

I'm working on an idea for a paper at SGF 2020, and it's based off the first paper in the proceedings of the first SUGI meeting in 1976.

In that paper, some guy named Goodnight describes the beta release of a new procedure called PROC GLM.

He writes:

The general form of these statements is as follows:

PROC GLM; CLASSES list;

MODEL dependent list = independent list I options;

The PROCEDURE statement has no options or parms. The CLASSES list contains classification variables (if any) just as with PROC REGR in SAS 72.

So ... is it wonderful that the same code works, as is, today? Isn't SAS great?

Or .... have we not moved on from this? Adherence to old structures/languages have hindered the product's advancement!

I'm not sure where I've landed on this, and I'm interested in the community's take on this question.

I may post elsewhere, to generate a discussion - but not sure where.

Thanks,

Mike Carniello

Astellas Pharma Global Development

[SJSlaughter]

@mcarniello Mike,

This is a cute idea for a paper. I like it and I'm sure you are going to get lots of responses.

But I want to point out right away that this is a false dichotomy. Just because the same code runs now does NOT mean that we have not moved on. To start with, the output from GLM is totally different now than it was way back when. We have ODS Graphics now (God bless Bob Rodriguez) and all the stat procs produce sophisticated graphics that could never have been dreamed of in the 70s. Ever seen a pen plotter? It's an experience not to be forgotten, in the same class as using punch cards, or (heaven help us!) a teletype (hard to believe, but there were things worse than punch cards). GLM produces plots now, and it's not sending them to a 70s pen plotter.

The fact that SAS works so hard to make our code backwards compatible is ABSOLUTELY FANTASTIC.

So guess what? I have recently run into a situation where basic SAS code is not backwards compatible. This statement runs in SAS 9.4M3:

ODS HTML BODY = 'C:\MyHTMLFiles\report.html';

But it won't run in SAS 9.4M6. (I'm not sure if it changed in M4, M5 or M6.) Now you have to write this:

ODS HTML PATH = 'C:\MyHTMLFiles' BODY = 'report.html';

You call this "moving on;" I call it a "pain in the whatzit."

Happy SASsing!

Susan

[ballardw]

---

@SJSlaughter wrote:
 Ever seen a pen plotter? It's an experience not to be forgotten

Yes and used from SAS. And the real pain is when the operator that had to set the plotters parameters misread the color order for the pens and/or the paper size. I had a map that was supposed to be about 15 inches across plotted at 1.5 inches...

class as using punch cards

Done that

 a teletype (hard to believe, but there were things worse than punch cards)

Done that too. And Not necessarily worse. You could punch a tape of commands that would not get out of order as box of dropped punch cards could. But the teletype couldn't make an automatic duplicate the way you could set a key punch machine to. (Backups you know)

But it won't run in SAS 9.4M6. (I'm not sure if it changed in M4, M5 or M6.) Now you have to write this:

ODS HTML PATH = 'C:\MyHTMLFiles' BODY = 'report.html';

I have a 'cheat sheet' note on the PATH/ Body syntax from SAS 9 that is old enough the ink is fading. So this might just be a case of finally settling down on a single syntax option.

[SJSlaughter]

@ballardw 

Thanks for the memories. I got a good laugh out of your story about the 15 in. plot that came out 1.5 in.

I did not mean to imply that the PATH= option is new. I should have been more clear. What is new is that it is required.

I like the PATH= option. I have nothing against it as an option, but it's a shame to loose backward compatibility. Also I do wish that the ODS destinations were more consistent. For ODS HTML you MUST use PATH=; for most other destinations you MUST NOT use PATH=. Thus we see that computers are not always logical.

[ballardw]

---

@SJSlaughter wrote:

@ballardw 

Thanks for the memories. I got a good laugh out of your story about the 15 in. plot that came out 1.5 in.

I did not mean to imply that the PATH= option is new. I should have been more clear. What is new is that it is required.

I like the PATH= option. I have nothing against it as an option, but it's a shame to loose backward compatibility. Also I do wish that the ODS destinations were more consistent. For ODS HTML you MUST use PATH=; for most other destinations you MUST NOT use PATH=. Thus we see that computers are not always logical.

---

It has been awhile since I made that note but I believe the reason I did was because the BODY="C:\path\file.html" did not actually work at that time and install. Or at least I couldn't get it to work when I thought it should. Learning ODS output through the basic examples in the base documentation is not a trivial task IMHO.

[mcarniello]

Yes, I remember pen plotters - and other graphing software like Tell-A-Graf. This discussion is interesting, thanks!

[Kurt_Bremser]

---

@ballardw wrote:

---

@SJSlaughter wrote:

 a teletype (hard to believe, but there were things worse than punch cards)

Done that too. And Not necessarily worse. You could punch a tape of commands that would not get out of order as box of dropped punch cards could. But the teletype couldn't make an automatic duplicate the way you could set a key punch machine to. (Backups you know)

---

Using two (US army) teletypes, you could make a copy. Have the one "send" it and the other "receive". We often did that on our AN/GRC 26, AN/GRC 46 and MFF 3 sets (Austrian army, signal corps).

[Vince_SAS]

This is the cause of the misbehaving PATH option:

Usage Note 61280: The ODS HTML statement generates errors in the SAS® 9.4 TS1M5 windowing environment when the FILE= option includes a fully qualified path
http://support.sas.com/kb/61/280.html

Vince DelGobbo

SAS R&D

[SJSlaughter]

@Vince_SAS Thanks for the explanation. Actually I like the PATH= option, but I wish the destinations were consistent. You can't use PATH= with PDF, for example, even though it makes sense. Maybe I should suggest that.

[Vince_SAS]

Definitely worth suggesting, Susan.

[JuanS_OCS]

Hi Mike, @mcarniello ,

good to see you around in the Communities. I feel highly interested about that paper for next year.

Powerfull topic to start a discussion, indeed. You will find defenders of both sides, easily.

For the new post, what about the SAS Programming community https://communities.sas.com/t5/SAS-Programming/bd-p/programming

Or perhaps in the recently open for Architecture https://communities.sas.com/t5/Architecture/bd-p/architecture

Or maybe in the Community Matters https://communities.sas.com/t5/Community-Matters/bd-p/community_discussion

It all depends on the kind of insights you would like to listen and the people you would like to bring together.

I personally think it is great that the SAS code is upwards compatible (and upwards more efficient), and, still, in every version of SAS, you will find an amazing set of new functionalities, new procedures, new options, and even capabilities to launch non-SAS code or to code absolutlely out from SAS and let SAS be the engine to do your calculations (where SAS algorithms make a difference in so many areas). This also means to me, that the code from newer versions, would be only partially compatible for lower versions.

There are certain areas, for the underlying technology, that certnainly from time to time require important updates, major versions, and so this is the pattern I see in SAS, as good example, CAS, or the concept of where SAS Metadata is stored and how. Or the DS2 procedure, a game changer. But the fact that, even with those important changes, even in SAS Viya - a complete change of architecture/framework-, you can run your "oldie" SAS Code, it is a feature that is definetely welcome, to me.

I have also seen languages (or any kind of technological product) just dying around in History, just because of their not frequent updates - and therefore not keeping up the new demanded features available for the new programs - or with too many changes to a certain point where upwards compatibility is a pain - and hence making extremly expensive or non-doable any migration.

So, for me at this moment, the best indicator that a language or any product is in the right path, it is its commercial continuity across the crazy demand life-cycles.

And this is something that you look for in any decent technological product out there, right?

Best regards, and "see" to you around!

Juan

[mcarniello]

Thanks for the notes, Juan ... And I just learned much about Viya at PharmaSUG 2019 ... ready for the relaunch of The CAS Institute!

[TomKari]

I love the idea of basing a paper on the PROC GLM paper from 1976!

If we're wandering down memory lane, here's a picture of me with my SAS 1979 manual (the last time the SAS documentation fit into one volume)

and an example of the "high res" graphics in it from PROC GLM. Who says you have to know ODS?

Maybe we need an "old codgers" forum, where us old-timers can reminisce about punched cards and IBM Selectrics!

Best,
   Tom