Who Wants To Be a Billionaire Coder?

theodp writes "Computerworld reports that 60-year-old billionaire John Sall still enjoys cranking out code as the chief architect of JMP ('John's Macintosh Project'), the less-profitable-but-more-fun software from SAS that's used primarily by research scientists, engineers, and Six Sigma manufacturing types. 'It's always been my job to be a statistical software developer,' explains SAS co-founder Sall. So if you didn't have to work — and had more money than George Lucas and Steven Spielberg — would you be like Sall and continue to program? And if so, what type of projects would you work on?"

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Does he program in SAS, though?

[Anonymous Coward]

Macros in SAS do create sucky code, but if you want to do anything more than a simple "hello world" program you have to use macros (arrgghhhh). The SAS Institute push SAS as a statistical language, but its far more than that. SAS is great at processing data. A 2000 line 2 file merge in COBOL is 3 lines of very easy to understand SAS code. Similar with SQL, I've seen SQL developers spend days trying to code up some SQL, when its a 15min job in SAS.

The problem with SAS is that its unlike any other language out there. So someone picking up SAS not only has to learn the standard stuff (library function name, if-then-else, loops, while blocks), but they have to learn brand new concepts, which are fundamental to the language, that they have never come across before.

SAS is an interpreted language so when you use macros your code is first evaluated for macros, then the resulting SAS code is executed. But this is done at each "run" block of code, not the whole program. So the results of your SAS code, can alter how the next macro is evaluated.

So take this simple program :-

%macro fred;
    data mytable;
        set &tablename;
        if tablevariable = "hello world" then
                call symput('tablename','table2');
    run;
%mend fred;

%let tablename = table1;

%fred;
%fred;

This gets run as the following SAS code.

    data mytable;
        set table1;
        if tablevariable = "hello world" then
                call symput('tablename','table2');
    run;

    data mytable;
        set table2;
        if tablevariable = "hello world" then
                call symput('tablename','table2');
    run;

What happened (in order) was this.

%macro %mend defined macro fred.
The %let set macro variable tablename to value "table1" (Macro variables are called symbolic variables in SAS terms)
The first %fred was evaluated, macro variable tablename resolved to table1 and created..

    data mytable;
        set table1;
        if tablevariable = "hello world" then
                call symput('tablename','table2');
    run;

The above SAS code, reads table "table1" and outputs "mytable".
"table1" has a variable called "tablevariable".
When a record where tablevariable= string "hello world" is found then the SAS call routine symput sets MACRO variable tablename to "table2".

The second %fred was evaluated, but this time macro tablename resolves to table2 and creates....

    data mytable;
        set table2;
        if tablevariable = "hello world" then
                call symput('tablename','table2');
    run;

Now we are reading table2, not table1.

As you can guess this can do FAR, FAR more evil than it can good, but is a major part of how the language works.