Date: Sat, 10 Feb 2007 23:14:20 -0500
Reply-To: Don Henderson <donaldjhenderson@HOTMAIL.COM>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Don Henderson <donaldjhenderson@HOTMAIL.COM>
Subject: Re: Check it out--we're java programmers
In-Reply-To: <CA8F89971ADA9F47A6C915BA2397844201EA76F1@MAILBE2.westat.com>
Content-Type: text/plain; charset="us-ascii"
Sig,
If they did not play on old misconceptions that are patently false, then
they would have nothing to advertise or say ;-).
First let me start by repeating the observation that Java is probably one of
the slowest languages out there. That slowness (in terms of execution time)
is a trade-off that many folks think is worthwhile (portability). But if
someone were serious about replacing SAS with a faster language it would be
hard to make a worse choice than Java. I am surprised that Alan has not
jumped in yet with his thoughts on this and how C# would have been a better
choice [do you feel the jabbing yet Alan :-)].
Let me now say that it has been a while since I looked at the Carolina
project, so my information may be out-of-date. But the last time I did, it
had no support for ODS, supported only some parts of PROC SORT and PROC FREQ
and perhaps a few other PROCS. I looked at the link to see if there was any
mention of the breadth of this effort and could only find:
http://www.dullesopen.com/documents/Carolina-supported-features.pdf
which seems makes no reference to any PROCs or ODS, so maybe it does not
even support parts of FREQ and MEANS. Interesting if you look at the above
link it is amazing how many data step statements and features are not
supported. Looking at the list of formats, it seems that the number not
supported far outweighs the number supported. There is also no support for
symput and symget in the data step.
That leads me to the conclusion that there is no there there. So one of my
questions is how many "production jobs" are there that only use the DATA
STEP and only use those statements that are supported.
And last, if I were in the market for such a tool (which I am not), it would
concern me greatly that the "very senior staff" (a quote from their
web-site) of the tool did not even understand that SAS is not an interpreted
language. The data step is compiled. Once a PROC is parsed, you are
executing compiled code. Thus the overwhelming percentage of resources are
spent processing/crunching data using compiled code.
And all of the above does not even address the fact that if I were an
organization considering replacing my SAS programs with something else that
the first step should be to revisit the business problems being addressed by
those programs to determine if an entirely different approach is more
worthwhile. But most places won't do that because they would have to invest
resources and would quickly realize that the ROI would be a very long time
in coming. So they go to the alternative of a code converter that looks like
it will cost less. And of course it will. But it won't work. So the choice
is spend a lot of time and money on something that may eventually work and
may eventually (but not in my lifetime) give you a return on your investment
vs. try for a quick fix that will almost certainly fail.
I am willing to bet that if someone has a production SAS job that is
consuming too many resources, it is because it is a badly designed process
or a badly written SAS program. It is very easy to write SAS programs and so
it is incredibly easy to write very inefficient programs.
Thus there is a third choice - spend some time and maybe some money to
optimize the performance of your existing SAS applications. Far more bang
for the buck there than in any code conversion project.
Always the cynic,
-don
> -----Original Message-----
> From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of
> Sigurd Hermansen
> Sent: Saturday, February 10, 2007 6:52 PM
> To: SAS-L@LISTSERV.UGA.EDU
> Subject: Re: Check it out--we're java programmers
>
> Interesting idea ...
> I wish that the developers would avoid playing on old misconceptions about
> compiled vs. interpreted programs:
> " ... runtime speed (compiled Java runs at a significant multiple of the
> speed of interpreted Base SASR)..."
> I can't imagine that either compilation or interpretation of SAS programs
> would save substantial amounts of time in any application. No harm in
> illustrating a few examples of how compiling Java programs leads to faster
> execution times, but global claims based on flimsy technical support
> convince no one but the gullible.
> S
> ________________________________
>
> From: owner-sas-l@listserv.uga.edu on behalf of Pardee, Roy
> Sent: Sat 2/10/2007 12:08 PM
> To: SAS(r) Discussion
> Subject: Check it out--we're java programmers
>
>
>
> Happened across this this morning--a base sas -> java compiler:
>
> http://www.dullesopen.com/
>
> I want a raise now. ;-)
