Date: Sat, 13 Mar 1999 09:40:10 +1100
Reply-To: Tim Churches <tchur@bigpond.com>
Sender: "SAS(r) Discussion" <SAS-L@UGA.CC.UGA.EDU>
From: Tim Churches <tchur@BIGPOND.COM>
Subject: Let's continue the SAS, BASS,
and Linux thread on some other list...
Content-Type: text/plain; charset="iso-8859-1"
I think that the discussion over the last few days on pricing and marketing
models of SAS for Linux has been very useful, and I think that any news
about SAS for Linux should continue to be posted on SAS-L. However, I wonder
whether it might be better if detailed discussions of what an alternative
SAS for Linux (and everything else) might look moved to another list. The
sas-linux list set up by Karsten Self seems the obvious choice - Karsten, is
that OK with you? See Karsten's SAS for Linux Web pages for details of how
to subscribe:
SAS/Linux: http://www.netcom.com/~kmself/SAS/SAS4Linux.html
Cheers,
Tim Churches
-----Original Message-----
From: Karsten Self <kmself@IX.NETCOM.COM>
To: SAS-L@UGA.CC.UGA.EDU <SAS-L@UGA.CC.UGA.EDU>
Date: Saturday, 13 March 1999 8:30
Subject: Re: SAS, BASS, and Linux
>I'm not quit sure who I'm replying to as this message seems to indicate
>multiple references and was sent by personal mail, though I've received
>a copy of a reply from a third party as well. Redirected to list.
>
>I guess you could call this a rant.
>
>Kowalczyk, Andrew wrote:
>>
>> )-----Original Message-----
>> > From: Karsten Self [SMTP:kmself@IX.NETCOM.COM]
>> > Sent: Thursday, March 11, 1999 3:55 PM
>> > Subject: SAS, BASS, and Linux
>> >
>> > I just spoke with Jeff Bass of Amgen, creator of the BASS system. This
>
>> > What I'm disenchanted with are:
>> >
>> > - Macro. As much as I use and appreciate it, it is a kludge. It is
>
>> > - Disconnect with other development tools. It is relatively
>> > difficult to wed SAS with other programming tools or
>
>> > This clouds the notion of an Open Development of a SAS-like
>> > system/environment.
>
>To an unknown author: I'm not sure where you're drawing this
>conclusion. My comments were that SAS lacks a good global scripting
>language, and that it takes a self-centric view of itself vis-a-vis
>other tools -- it operates well as a controlling process, generating
>occasional calls to third-party tools, or as a server, responding to
>requests from tools. It doesn't provide the flyweight utility of, say,
>embedded perl, awk, S (or R), or gnuplot in another product, where a
>short call is made to a tool so that it may provide functionality
>missing in the parent. This is hardly a feature dependent on an
>operating system.
>
>That said, I'm partial to the Unix system of parent/child process
>relationships, pipes, stdin/stdout, and filedescriptors. Most of which,
>of course, was originally implemented in CMS, and elements of which can
>be found in DOS/Windows.
>
>> You seem to want the "look and feel" of PERL or your favorite shell
script,
>> with the addition of SAS-like PROCs that you can imbed? But if you
ported
>> this to Windows 2000 or BeOS or MacOS or MVS it would be very foreign and
>> you would have to emulate the UNIX-y stuff on the other environments.
>
>Perl perhaps as it provides the functionality I describe above: it's a
>good general purpose scripting language with a (rapidly growing) list of
>special-purpose modules. What perl doesn't provide, it can (and does)
>borrow elsewhere. Unix shell scripts are convenient for quick and dirty
>work, but lack many features useful to quantitative data analysis --
>Perl _does_ provide fundamental mathematical capabilities (and non
>fundamental abilities with modules). Note that the shells tend to refer
>back to their C roots, and Perl steals the best (or most eclectic) from
>shells, sed and awk, and other programming languages.
>
>Perl is supported on Unix, MS Windows, MVS, and VMS. You could replace
>its name in my arguments with similar full-featured scripting tools such
>as REXX, icon, python, Tcl,....
>
>As for the pluggable modules I'd like to refer to, several (S/S-Plus,
>gnuplot, TeX/LaTeX) are cross-platform as well. Emulation not require.
>
>
>The Unix environment is not new, but it has survived and evolved
>considerably over time. There are compatibility modes allowing some
>degree of Unix functionality on Windows, OS/2, VMS, and MVS, as noted
>previously. The next version of the Macintosh (OS X) will _be_ Unix --
>at least at its heart (the Mach kernel). It may even ship with
>Linux/MkLinux, if you believe everything you read.
>
>What makes Unix powerful IMO is that it addresses processes and data,
>and isn't particularly concerned with details of hardware, users,
>displays, proximity (networking), or security -- all of which are core
>to the design philosophies of other OSs (OS/360 & MVS, Mac & Amiga,
>VMS).
>
>As such, Unix is in ways a low-level OS. It provides a cleared ground
>on which to build. Most of is called "Unix" isn't the kernel but the
>layers added to it (shells, display drivers, display environments). One
>difference is that Unix makes this separation where other OSs don't.
>IMO it's added to Unix's flexibility. Open development and the
>emergence of Linux are not inconsequential either.
>
>In the same way that C is popular, despite its warts, because it is a
>low-level language and allows a great deal of control, Unix is useful in
>the degree it gets out of the way when dealing directly with data and
>processes. Kevlar footwear may be required, but you can also get your
>work done rather than fighting the tool itself.
>
>Any cross-platform development will raise issues of local compatibility,
>particularly with a tool that encourages reaching outside itself for
>support. Even if the core tool is transparently portable, the external
>utilities will have to be provided or functional replacements found.
>
>WRT the dominant operating system of the next ten years, I'm inclined to
>believe that it won't be any one system, though the best will exchange
>the best features among themselves, and will tend to play well with
>others. Development in this environment will mean making provisions for
>portability -- and facilities for portability will be provided in the
>best environments. Maybe that will be the definition of "Open" in the
>'00s -- the word that never dies and always changes....
>
>> I can remember back when each DATA step and each PROC step was its own
>> separate JCL job-step. Without the macro processor the only
communication
>> between steps is the data file created - this fits nicely with the JCL
>> environment.
>
>...which had its own set of assumptions about users, processes, memory
>space, direct and sequential storage, queues, interactivity (or lack
>thereof), JCL, etc., etc., etc..... I have to admit that my mainframe
>experience has greatly increased my understanding of SAS. It also
>highlights some key limitations.
>
>> The "core" SAS that we all know and love was heavily infuenced by the
>> thinking that went into the development of the PL/I language and by the
>> OS/360 operating environment. Both of which represented, arguably, the
>> pinnacle of large system design theory at the time when SAS was
conceived.
>
>...and where does this model fit where both the personal and server
>computing environments are increasingly decentralized. I'm not
>suggesting scrapping legacy, I am encouraging evolution.
>
>> So maybe it would be reasonable, in designing the "SAS for the next
>> Millenium" to start with a similar starting point - what is the ultimate
in
>> user environment at this point in time? (I have opinions - but not an
>> answer) Your vote seems to be for a UNIX shell.
>
>I'll make the correction one more time:
>
>No. My vote is for an extensible, open, modular (vs. monolithic),
>portable, and substitutable tool kit. Perl is an exemplar of this, it
>isn't the only choice.
>
>
>Andrew's post seems to focus on criticizing Unix because it is Unix and
>not everything else. The argument could be made of any system
>preference, and in fact is alluded to in Andrew's comments on SAS's MVS
>roots. The fact that my original points regarded strength and
>weaknesses of language and programming tool design appears to have
>escaped significant mention. While I like Unix, it's a like based on
>some breadth of experience, and on specific features of the system I
>find useful. However, I draw a broad distinction between a programming
>tool on the one hand, and the environment in which it runs on the other.
>
>--
>Karsten M. Self (kmself@ix.netcom.com)
>
> What part of "Gestalt" don't you understand?
> Welchen Teil von "Gestalt" verstehen Sie nicht?
>
>web: http://www.netcom.com/~kmself
>SAS/Linux: http://www.netcom.com/~kmself/SAS/SAS4Linux.html
| 
