LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (March 1999, week 2)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
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...
Comments: To: Karsten Self <kmself@IX.NETCOM.COM>
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


Back to: Top of message | Previous page | Main SAS-L page