Re: Question: How does one move from SAS to Java?

On Thu, 18 Nov 2004 20:53:01 -0500, Christopher Amherst
<camherst@MISER.UMASS.EDU> wrote:

>Quoting "David L. Cassell" <cassell.david@EPAMAIL.EPA.GOV>:
>
>> Sure. Program in SAS. You can then write Java code and integrate
>> it into your SAS code. (Take a look at Richard Devenezia's website
>> to see some examples.) Now you can count your time as:
>> [1] SAS programmer
>> [2] Java developer
>> [3] AND systems integrator.
>
>It's likely the only option I have, other than jumping ship entirely.
>Just wish there was a better sense of projects that integration is better
>suited for.

Hi,

Seriously, the more I think about it, the more it makes sense to follow
David's advice - be patient and stay employed as a SAS programmer and
learn java, and then apply your java skills whenever it makes sense to use
java.

I can give you at least several places where I saw java working very
nicely with SAS now (in 9.1) or very soon (in 9.2).

At the NESUG2004 futures forum (which was two days ago), I heard that the
data step java object (and using user-defined functions written in proc
fcmp in a data step) will be in production soon (in 9.2). Wait and see
what kinds of original idea comes out of the amazing people at sas-l using
this route of integrating SAS and java.

I've also seen WebAF - which is strongly promoted by SI -- is all java and
nothing but java (OK. java and SAS). The possibility for getting both the
java and sas experience is limitless here.

(I am sorry to report that, at the forum, the SI developers were not very
enthusiastic about SAS/AF, though. Still, they told us that AF and SCL
will continue to be supported. One developer also mentioned that it is the
case that when they add a new function to the data step, it is
automatically (or with little work) added to SCL, too.)

SI is also into "solutions" business now a days. I attended one session at
NESUG2004, where a "solution" was demonstrated. Behind the pretty graphs
and menus, I realized that a "solution" consists of nothing but (1) sas
macros that calls various existing sas products or modules for heavy
lifting; (2) an xml file, which documents the parameters for those macros;
(3) and a pretty user interface written in java that takes parameter
values from user and pass them on to macros and run them. (on the form the
meta information stored in xml document is used as field labels and the
like).

Here I see a lot of opportunities -- this can be done by anybody who knows
sas and java -- and also a substantive knowledge and skills in some topic
area that your "solution" would be useful. Think of something that you
know how to do with sas -- write parameterized macros -- wrap your macros
with a java/swing or other nice user-interface. Voila -- you have
a "solution" package to sell. Don't you have enough motivation to learn
both sas and java yet?

As far as I can see, si is really committed to java and there is no way of
turnning back. SAS and Java will be more and more closely integrated and
there will be ample chance to utilize both SAS and Java codes. In this
regard, the fact that they are so different *is* the blessing in disguise.
Unless they are so different, integration would mean little.

HTH.

Cheers,
Chang