Hi, Chris. Great article, thanks for sharing! I've had to think about this a lot over the years, as I always have to be prepared to answer the question "Why should we use SAS to solve this problem?"

I see SAS slightly differently than you do. I see:

1. A programming language (SAS data step and the macro language): a general-purpose language, BUT highly optimized to be used for data management and statistical requirements. For example, if anyone ever offered to pay me to use SAS to:
- develop a video game
- code an operating system
- design a real-time system to manage an automobile's functions
- run my pacemaker

I would run away as fast as I could. SAS doesn't have the features to optimize the coding of these types of systems, whereas it is superbly optimized for data management and statistics.

Not to say I couldn't do it...just for fun, I once developed a working analogue clock in Excel. And as we've seen from the Sudoku application in SAS, I'm not the only crazy person out there. But I would inform my "client" that this would cost WAY too much money, and they should go find a C / Java / Python expert (COBOL?).

2. A series of macro / subroutines / functions (I'm not quite sure which term I like) that allow you to solve a particular problem by providing parameters. I'm of course talking about the SAS procedures. I differentiate them from the programming language on the basis that the programming language features are general-purpose (ie they can be strung together to do a wide variety of things), but the procs pretty much all do one thing and one thing only. The COBOL language implemented something similar for sorting data, and for writing reports. Python has a lot of similarity with some of it's packages.

3. Everything else. Not sure what to call it. Back in the 80's, we were starting to see what were called 4GLs (fourth generation languages), which simplified a lot of functions, and provided a nice user-friendly interactive interface. This is where I'd put EG, Studio, DIS, and even Viya. The tradeoff is that a less-experienced user can get useful stuff quickly from these tools, but the range of possible solutions is much less than using a programming language. I can do everything that can be done with these tools using just Base SAS and the procs, but it'll take a LOT longer (and I'll probably make a bunch of mistakes!)

BUT, what I consider the secret sauce with SAS is that as long as my EG user can get 90% plus of what they need from EG, we're laughing. What they can't get from EG I can write using Base SAS "primitive code". The subject matter expert next door, using Excel as their 4GL, is going to have to find someone to write Visual Basic / C# code for them. And I'm going to run rings around that programmer, because Base SAS is optimized for solving this kind of problem.

I'm eager to hear what other SAS users think!
Tom