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.