Poll: EG for programmers or not?

[SAS_Doctor]

Rant or not he's right. All of the SAS editors are in need of upgrades. I just started in a new shop that uses EG 4.2 and the editor is not making SAS look good in the user base. They are hurting themselves by not making drastic changes. Programmers have been complainging about this for years. And programmers are the ones that sell the product for them. GET WITH IT SAS!!! Make it more like the Eclipse or visual studio type environment... Please.

[ChrisHemedinger]

Jim,

Check out this paper to see how the development team *has* made strides towards making EG more like Visual Studio, especially within the program editor:

http://support.sas.com/resources/papers/proceedings10/137-2010.pdf

Chris

[nrose]

Hi,

I am a programmer, both SAS programmer and other high level computer languages.

I love SAS EG. I have a two screen set up, and this is a very efficient set up to make the most out of SAS EG. It sounds like you have picked out all the negatives of SAS EG, but since moving over (voluntarily), I have never looked back. Sure, it is buggy, it has shortcomings, but the improvement coming up for coders in SAS EG 4.3 look great. I work in a business environment where not everyone is experienced at using SAS. I have to work in the same environment as end users to make it easy to accomodate their needs rather than mine. As programmers, we have to stop living inside our high horse shell.

You have to put it in context - name me another statistical package that offers the features, flexibility and customisation (e.g. custom tasks) that SAS EG offers? And I am not sure why you are writing 1000 to 2000 line SAS programs? Sounds like you should be modulating your code a bit better - which is what EG encourages.

NIck

[nrose]

Sorry Chris,

It is hard to take your criticisms seriously when you consider what you describe a 'complex' program, and when you abstract your program into the steps you have, and not say that you can't modularize it. I hope your program is seperated into seperate SAS files, otherwise, go back to programming 101.

Do yourself a favour - learn how to use SAS EG, create a process flow for each of the steps in your program, and, within each process flow, build up your program using tasks or your own code, create an ordered list to run the program, and then see how easy it is to debug. You will find that being able to see your datafiles created for each step easy to keep track of, that the individual log windows for each step allows you to isolate errors, and if you ever have to go back to it in the future, how the visual representation of your program makes understanding it easier. And, if you know any .NET programming, create your own custom tasks, and see how user friendly your programs can become for others. It is precisely for serious programming, that users should adopt EG.

Nick

[ChrisNZ]

Hi nrose,

Thanks for your input. Don't be too hasty in judging me please, I know EG quite well actually (which why I can list what I think is not adapted to advanced developers compared to the DMS which I also know well), having been responsible for supporting the company's metadata server and the EG environment, users and data sources in a previous life. The program described does simple enough things (after all how complex can a single step get?), it is how all is linked together that makes the complexity. Each step is often short (though the merge statement alone would be 1k lines for 5 years' worth of data, and the merge data step over 20k lines if not coded via macro loops, think about it: loops are 60 observation months times 24 months to look at), but what the steps do/are is not always known in advance, depending on the data. Speed is also a major consideration for this kind of volume, and imposes choices where ease of development/simplicity is sacrificed. It would be *a lot* easier to develop and maintain each report separately, but it would take several hours instead of a few minutes to run them all.

Anyways, once again, let's try to stick to the points raised.

You are right, giving EG to statisticians who can then create processes without having to code is excellent.

This is a crowd different than developers who know all the tools sas offers, and have to create efficient applications. Typically, the latter will provide the statisticians with their cleansed, consolidated, coherent, easy-to-use EG data in fact.

2 crowds, 2 sets of skills, 2 tools. I don't expect said statisticians to write data steps, and I don't like developers to use a tool where many useful features are missing whereas they have been asking for extra ones for some time now. Message was edited by: Chris@NewZealand

[Peter_C]

Hi Nick/Chris

in responses to the 4 questions
Q1=>What on earth pushes sas to want programmers to use EG?

my A1
it might be more manageable to build a new IDE than re-devevelop the old one.

Q2=>How can they believe that populations as different as end users and coders have similar needs and should use the same tool?

my A2
excel serves all sorts of people even through the transition to office 2007, so why should SAS Enterprise Guide (EG) not serve a diverse audience

Q3=>Why cripple an already limited coding interface? How can these shortcomings be seen as acceptable? Do sas Institute developpers use EG?
my A3
specifically that is what they are not doing, by creating EG as something new

Q4=>What do you think?

my A4
I hope my prejudices are not based on anything like a "first love" of my first SAS environments 😉 That was old SAS on a mainframe before display manager (DM). When new, DM came with its own particular difficulties (very much needing the "-altlog" feature to help discover where it had broken and destroyed my log 😉 but sadly that altlog option didn't turn up until SAS6 through which all the SAS software improved greatly. Switching to DM from my own contrived user-interface+batch-SAS came through time and the attraction of some of the peculiar benefits of that platform. For me now, switching to SAS Enterprise Guide (EG) has not been so quick nor eager - for a range of reasons.
For now "anything that gets the job done" is a satisfactory environment.
Highlighting one of Nick's points if you know any .NET programming, create your own custom tasks, and see how user friendly your programs can become for others. It is precisely for serious programming, that users should adopt. I was able to apply my base SAS knowledge to extend SAS DI studio for the benefit of others. With SAS/AF I was able to extend the effectiveness of SAS Display Manager for may benefit and the benefit of others. Even without SAS/AF, the SAS Explorer interface is able to be extended to be more effective for others.
So now it seems to step forward to the (no longer new) SAS Enterprise Guide world, I have to take some backward steps to learn .net (or maybe java? ) so that it cann achive the basics I expect of wizards in EG - like building an informat where I can set special missing values for dates = like "age not admitted" or "?" or 00/00/00 - which was my first ajor disappointment in EG - that the (weak) customising of code generated by wizards, left me back in a code window

so now it's back to class - to learn a nerw language - to re-establish my relationship with SAS development in the new environments - (remembering that just like we need batch to be available still, I think we can hope always to be able to run fat SAS clients for data step debugger

[twocanbazza]

Hi Chris.

"and it doesn't even have line numbers for goodness' sake!"

ummmm yes it does, you can turn them on....

"-No access to OS (call system, x, %sysexec, pipes, named pipes)

Ummmm yes you do, this can be set, just happens to be set to off by default...

-Library property does not indicate path

Ummmm depends on how and where the library is assigned (why do you as a programmer need to know this anyway? I know I'll get some comments about this one 😉 )....


Don't get me wrong I agree with you in certain cases but some (above) of your rants relate to how your system has been set up and administered rather than the functionality of the tool. Learn the tool, look outside the old programmers mindset, just cause you could do it in old school SAS doesn't mean it is right.

There are a few issues relating to the quality of the GUI ie window re-sizing etc but SAS will get this right in future releases

Bring on 4.3

Cheers

Barry

Message was edited by: twocanbazza Message was edited by: twocanbazza

[Robert_Bardos]

quote on
... just cause you could do it in old school SAS doesn't mean it is right.
quote off

Similarly: just cause you can't do it anymore in new school SAS doesn't mean it is/was wrong or less productive.

Still loving the 3270 type editors where it's been just these last days that I brought a "wow, I didn't even think about such a possibility" expression on the face of one of our younger (than me) programmers. Later on I realized that his astonishment was due to the Windows based mindset he had come to adopt earlier in his career.

Robert

[Patrick]

Hi Chris

What made me use EG as coding interface was the possibility to reset an environment simply by disconnecting/connecting to the server. No more closing everything only because there was some unbalanced quotation mark in the code.


Talking about EG 4.2:

I agree with you that EG still let's a few wishes open - others can be solved by undoing the default preferences (i.e. NOT to open a data set when added to the project).

There are also these little things like that I can't choose in a stacked window where the code window goes and where the log - and that I first have to run the code before stacking is possible. I sure prefer the old DMS in this regard. Also toggling between windows is rather cumbersome, there are no shortcuts (or they are not intuitive).

There are just still too many things which need too many clicks:
I.e. creating a new code node: Program is not such a good name. But I first have to open it this way (no prompt giving me the possibility right away to give a catchy name) and then go to the process flow tree, click carefully on the name - and then I can change it. A lot of people don't bother doing this and then get lost in Program to Program100.

I also agree with you that debugging capabilities are rather limited. I strongly hope that EG will get some inspiration from what has been done in SAS DIS 4.2.

Little annoying and missing things like this are many more in SAS EG (i.e. trying to save EG code in a PDS member) - which makes new releases always exciting.

But then look at all the advantages EG has to offer. I.e. if I analyse some data and want to deliver the result as Excel then I wouldn't even think about using "PC SAS".

I'm actually right now working for a customer where I try to convince them to use EG instead of PC SAS and rsubmit.
It's not that easy as people always see first what they loose. Still: I think overall EG is the better choice and I can't wait that EG 4.3 brings changes which make it even more attractive for coders.

Cheers
Patrick

[darrylovia]

As an old school SAS programmer, when we went to EG i didn't like it. But after using it for about 3 years, it is starting to growing on me. Remember EG is just an interface to a server side installation of the SAS System.

Pluses
1) easy to make a stored process that other applications can use. .NET etc.
2) the point/click wizards generate code in the SAS log so I can see what the heck SAS GRAPH is doing 😉
3) you can still code old school with %includes and not use tasks or link code if you choose.

Cons
-1) OS commands are disabled no more X cmd ;(. But there are work arounds, ? Luckily it is possible to run external DLLs from SAS under Windows by using the SASCBTBL Attribute table and MODULE family of call routines and functions.
-2) Running batch needs to be done on the server, so getting the network adminstrators attention can be fun (not).
-3) DDE doesn't work. There is no way that I know of to code around this.

For me as a developer having the same tool as the user, gives me insite into what the user needs.

Darryl

[ChrisNZ]

Hi everyone,

Good to see the discussion is getting more constructive.

I was afraid it would turn out to be like some Office 2007/2010 or Vista/W7 forum discussions where the proponents could only conclude: stop thinking/whining, get on with it, it is the future, move on. There is a fair share of that, but there are also good real-life comments; thanks all for the good points raised and experiences shared.


>excel serves all sorts of people even through the transition to office 2007, so why should SAS Enterprise Guide (EG) not serve a diverse audience

Yes, except excel has everything an excel wiz needs, and then people can use it as a photo holder if they want. Not so here. SAS didn't start with best-in-class IDE and added a GUI-for-end-users on top, they started with an end-user app, and are trying to gear it towards programmers.


> DDE doesn't work. There is no way that I know of to code around this.

Have you tried writing out a VB file?
Users then load an empty excel sheet that you always keep there and that just points to the VB file, and excel is your slave. I did this pre-office 2007 so users would load a CSV file from the sas web reports and excel would present them with a pivot table. Unsure about newer excel versions' behaviour.


> None of the capabilities that you mention are inherently limited in SAS Enterprise Guide.

It seems to me that many still are, Chris.
Some restrictions in my list seem to have been lifted, or there might be workarounds, but many also remain, and many others exist, as pointed out by Patrick or darrylovia for eg.

In any case, wide gaps exist compared to real IDEs (source code management and graphical debugging are my main 2) and compared to what users requested (cf sasware ballot 2009: macro line numbers, etc).

Simple things like a log summary at the end of a run (how many errors, warnings, of what type?) are also missing. One doesn't need this in simple EG projects as each step has its own log. But in my world, if a macro runs a bunch of steps 200 times, and some generate funny messages, it should be a lot easier to track down.



> you can still code old school with %includes and not use tasks or link code if you choose.

Yes, this is good when one has well-behaved, optimised code. Getting there in EG might be the pain.


I suppose my main issue is that I seldom use procedures (except for deriving stats), as the bulk of my work is data processing, and this is mostly done in data steps where I can get the efficiency of features like hash tables, arrays, funny merges, macros, multiples outputs, row delete or duplication, etc.

Incidentally, this is also what I was doing when I was feeding tables for my EG users in my previous life.
By then, the data was denormalised, clean, and complete and they could use SQL and procedures and build easy-to-follow EG processes.
Do you guys know where your EG tables come from?

And when I do use procedures these days (mostly to create graphs), they are always heavily customised, so no point-and-click here either.


I have learnt more good things EG *can* do, like using the MODULE* functions or packaging processes in .NET containers, and I reckon process legibility and ease of handover are important pluses. But so far, probably because of the type of work i do, it still seems that if I have to use EG some day to do what I am doing now, my karma, morale and productivity will take a huge hit. Please keep the comments coming, both for and against EG for programmers.

[darrylovia]

Great thread.

The place where I consult only uses SAS Enterprise Guide 4.1 on the desk top and has 9.1.3 on the server side. SAS is used to get data from a variety of sources, Oracle DB, SQL Server, MS/Access, and a plethora of legacy flat files.

I mostly use SAS to create the SAS datamarts from those data sources. We use SAS EG for heavy data processing work and use the Code window for the vast majority of the processes.

Also, it is very convient for the non-programmer to have a link to the SAS Datamart, Oracle DB, and SQL Db and join away in a single application, versus toggling through TOAD, etc.

So with the same tool, I (the developer) uses SAS EG mostly for ETL work. While the operations research staff uses it to run analysis (statistical analysis, reporting, etc.). One cool feature is the use of macro parameters. With a simple drop down the analysts can run a variety of scenarios without coding a single peice of code.

As I mentioned before using the same interface as the end-users makes my life as a developer a bit easier.

Darryl

[deleted_user]

>
> What made me use EG as coding interface was the
> possibility to reset an environment simply by
> disconnecting/connecting to the server. No more
> closing everything only because there was some
> unbalanced quotation mark in the code.
>

I found the text-only display manager in SAS version 6 much more responsive than the "graphical" interfaces that have come since. If you got your SAS session hung up you could close it and re-open in a flash. You could (can if you still have SAS 6.12 running!) browse a dataset in a flash.

And that was running a machines with a tenth or hundredth of the CPU power that is available now.

Not that I object to the improvements in interfaces over the years, but I really feel that not enough attention is paid to power users that want the GUI to get out of their way when they already know what to do.

[Peter_C]

abernt

in your message you remembered speedy access to data

> flash. You could (can if you still have SAS 6.12
> running!) browse a dataset in a flash.
>

You don't need to maintain SAS6!

To open in a flash
, not only SAS6 data and xport tables
, but also base SAS8 format data (SAS9 without long format names)
, use SAS SYSTEM Viewer as default for .sas7bdat files
* change grid filter option from "load table until memory full" to open table in 1000 row blocks, and then enjoy opening GIGAbyte-size tables in a flash
not sure yet that SAS(9) universal viewer is as quick

peterC

[art297]

Peter,

I agree with your advice about SAS Viewer. But, as I think you implied, the Universal Viewer serves as an excellent case in point for the current argument. When I loaded it I was expecting something that was going to deprecate my old SAS Viewer. I found the exact opposite.

Nick appears quite willing to let the rest of us lose as long as he gets what he wants. My point is that what many of us like about SAS are some of the older features and SAS should have enough developmental monies to still enhance the old while developing the new.

And, Nick, yes, .NET programmers are a lot easier to find but, in my case, not .NET programmers who are also statisticians and who understand insurance. Sure, the .NET programmers could put together a GUI interface a lot faster (and one that would probably even look better), but my use of SAS/AF has nothing to do with building GUI interfaces. We are using a language that the staff understand and are able to easily develop fairly complex iterative processes, yet still know what is happening and why and how to test and, when necessary, change a process in a defensible manner.

If you don't need such capabilities, and I presume there are many who fall into that category, then of course you don't need it. All I ask is that SAS keeps in mind that you don't represent all the rest of us. I have no problem paying SAS to develop things I don't need, but do have a problem if I don't see enough of those monies being spent on the things I do need.

Art