Why SAS programmers need to be aware of perl and R
in [SAS]
|
From: oloolo on 5 Mar 2010 14:42 partly agree with the EG part. Just like when SAS wants to use EM to break in data mining industry, many practitioners insist on using SAS/STAT for their goods. From my own interview experience, hiring managers value most the data miner who can do real programming, rather than those relying on shipped packages and drag icons. Which, like in the EG case, is good. With many users switch to low end skill sets, those possess the high end skill sets stand out On Fri, 5 Mar 2010 10:52:22 -0500, Keintz, H. Mark <mkeintz(a)WHARTON.UPENN.EDU> wrote: >XLR82SAS said: > >> -----Original Message----- >> From: SAS(r) Discussion [mailto:SAS-L(a)LISTSERV.UGA.EDU] On Behalf Of >> xlr82sas >> Sent: Thursday, March 04, 2010 5:22 PM >> To: SAS-L(a)LISTSERV.UGA.EDU >> Subject: Re: Why SAS programmers need to be aware of perl and R >> >> On Mar 4, 11:01 am, stringplaye...(a)YAHOO.COM (Dale McLerran) wrote: >> > --- On Thu, 3/4/10, Jonathan Goldberg <jgoldb...(a)BIOMEDSYS.COM> >> wrote: >> > >> > >> > >> > >> > >> > > From: Jonathan Goldberg <jgoldb...(a)BIOMEDSYS.COM> >> > > Subject: Re: Why SAS programmers need to be aware of perl and R >> > > To: SA...(a)LISTSERV.UGA.EDU >> > > Date: Thursday, March 4, 2010, 8:55 AM >> > > Three little points: >> > >> > > 1) >> > > Dale: >> > > You're not really taking exception; I wrote: >> > > >>that's why the R interface in in IML; OTHER PARTS OF SAS don't >> > > >> have any data type that loosely corresponds to an R frame. >> > > In other words, I agree that an R frame and a SAS data set are >> > > very similar; it's just that only IML has any facilities for >> > > manipulating SAS data sets as entities. (Unless perhaps you >> > > count the table processing language). >> > >> > Jonathan, >> > >> > Can you elaborate on the facilities in IML for manipulating data >> > sets as entities. I'm afraid that I don't understand your >> > argument. >> > >> > Also, why must a SAS data set be mapped into an R data frame as >> > an entity? >> > >> > Dale >> > >> > --------------------------------------- >> > Dale McLerran >> > Fred Hutchinson Cancer Research Center >> > mailto: dmclerra(a)NO_SPAMfhcrc.org >> > Ph: (206) 667-2926 >> > Fax: (206) 667-5977 >> > ---------------------------------------- Hide quoted text - >> > >> > - Show quoted text - >> >> Hi Sas-Lers, >> >> Proc matrix was part of base SAS and had a couple of nice properties >> on big IBM mainframes. >> >> 1. It had limited but useful 128bit numeric capabilites(way >> ahead of its time) >> 2. It used IBM's separate 'hardware vector engine' for fast >> parallel vector operations (way ahead of its time) >> >> SOAPBOX ON: >> >> I made heavy use of 'proc matrix' and when SAS decided to rip it out >> of base and charge very high fees for large two sided 8 way >> mainframes, my management was not pleased. >> >> SAS did provide a translator from Matrix to IML. >> >> Here is what scares me at SAS: >> >> 1. It looks like Enterprise Guide is the window to future SAS >> and SAS_SAP. Also it looks like EG is somehow in bed with Microsoft's >> proprietary .NET. Suppose Microsoft comes out with a Starship >> Enterprise Version of .NET and decides to charge $500,000 dollars for >> Startship Enterprise .NET. SAS is also prety good at playing this >> game. >> >> 2. I worry about EG as a poison pill for programmers and >> companies. Suppose programmers get sucked into the givaway EG. SAS >> throws in IOM, metadata servers, stored processes, data architechure >> tools .. low cost at first. Then comes the 'proc matrix' hammer and >> programmers and companies have to pony up with massive spending >> increases or massive reprogramming to move away from SAS-SAP. For >> instance if the once free components of EG, like proc matrix, are now >> enterprise versions at extra cost. >> >> I think EG should reflect the future costs now. It should be >> priced at least 2x Windows Base SAS + SAS-Connect. Companies need to >> take a close look at future IT costs and SAS's revenue strategy with >> respect to EG. Just look at the costs asssociated with SAP. I also >> don't like it when SAS gives away 'ODS GRAHICS' and then charges for >> it later. I know this in not strickly bait and switch, but it smells. >> >> I also find it very hypocritical for SAS to complain openly about >> an inefficient interface to Oracle, when SAS does not even have a >> silient ODBC product. >> >> SOAPBOX OFF: > >XLR8: > >Of course, the pricing practices that you are criticising are shared >by many, if not most, marketers of high cost products. SAS has >successfully used an analogous technique by charging schools about >$100 for what private enterprises pay (in at least one instance) >$15,000. It's just a smart way of creating price-inelastic demand >for a product. Wouldn't most of us think SAS stupid to charge the >commerical price to institutions where many future SAS users are >generated? > >To request that EG be priced to reflect future costs now would be >very unpersuasive for any entity trying to introduce a significant >new feature/product. This is how companies take risks. In fact, >you could argue that companies offering high-end products are >virtually forced to take risks via (1) invest a lot in development, >(2) create low introductory prices, and (3) hope to recover the >investment when the product gets priced closer to true costs. >If users balk, then the research and development investment failed >(and such an event would be an opportunity for IBM/SPSS to develop >and distribute a bridge to their putatviely competing prodcut). > >And I don't think the question is whether "programmers" are sucked >into using free EG. This product is targetted instead at sas USERS. >As a progammer, I doubt that EG will forseeably provide the >flexibility that I need from SAS, but I can see where it might >become desirable, and even essential, for many of our users. >These are people (and future decision-makers) who only occasionally >need SAS, and who want fewer barriers to defining and implementing >a data processing and analysis task. Many of these are "one-off" >tasks, where program efficiency takes second place to programmming >efficiency. > >In short, I think it's hard to criticize the thinking behind the >strategic product development and pricing strategy that SAS EG >represents, even though it doesn't help me one bit. > > >Regards, >Mark
From: Nathaniel Wooding on 5 Mar 2010 17:00 While they don't post public replies, SAS Institute employees do read these posts so your comments have most likely been noted and SAS often takes note of what the community needs. Some requests are not practical and some take a long time -- like the first implementation of a pc but with the machines of the day, the capabilities were similar to those of a 1920's aircraft trying to do the work of one from the 1940s or 1950s. Another good way to get your message across to the Institute is to go to http://support.sas.com/contact/software_comments.html and submit a suggestion. Also, watch for the announcement of the annual SASWare Ballot (it is usually announced on SASL) and vote for items that are dear to your heart. Nat Wooding -----Original Message----- From: SAS(r) Discussion [mailto:SAS-L(a)LISTSERV.UGA.EDU] On Behalf Of oloolo Sent: Friday, March 05, 2010 2:32 PM To: SAS-L(a)LISTSERV.UGA.EDU Subject: Re: Why SAS programmers need to be aware of perl and R I hope SAS could continuously improving its Java.Obj interface to JAVA. I think this is the way to go. Nowadays, Java is powerful enough for some serious numeric crunching work and there are plenty of open source Java packages for statistical and data mining algorithms which I want to leverage. On Wed, 3 Mar 2010 10:27:44 -0500, Jonathan Goldberg <jgoldberg(a)BIOMEDSYS.COM> wrote: >I agree with xlr82sas. Doing a SAS-R or SAS-Perl interface is SI's job, >because they have a closed product with a proprietary data format. >Reading and writing SAS data sets can only be done reliably with SAS >tools, which are not redistribuable. > >It must be said that SAS has interfaces to both; remember the Perl data >step object. > >The problem with building interfaces is with data type translations. I >assume that's why the R interface in in IML; other parts of SAS don't have >any data type that loosely corresponds to an R frame. Likewise with Perl; >SAS functions cannot return arrays (and other data types). > >To my mind this is an arguement for moving IML to Base. > >So, while I think it's SI's job, that job presents problems with no >obvious (at least to me) solutions. CONFIDENTIALITY NOTICE: This electronic message contains information which may be legally confidential and or privileged and does not in any case represent a firm ENERGY COMMODITY bid or offer relating thereto which binds the sender without an additional express written confirmation to that effect. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you.
From: Alan Churchill on 6 Mar 2010 01:19 Never going to happen on the .NET front and SAS was right to choose it (they should do more .NET, not less). Also, name a product where Microsoft charges outrageous fees for underlying code? .NET is required to run Windows so it is core technology and most of the code base has been released to the public. Java, BTW, is solely owned by Sun. What other technology is proposed for creating UIs? Alan Alan Churchill Savian www.savian.net Office: (719) 687-5954 Cell: (719) 310-4870 -----Original Message----- From: SAS(r) Discussion [mailto:SAS-L(a)LISTSERV.UGA.EDU] On Behalf Of xlr82sas Sent: Thursday, March 04, 2010 3:22 PM To: SAS-L(a)LISTSERV.UGA.EDU Subject: Re: Why SAS programmers need to be aware of perl and R On Mar 4, 11:01 am, stringplaye...(a)YAHOO.COM (Dale McLerran) wrote: > --- On Thu, 3/4/10, Jonathan Goldberg <jgoldb...(a)BIOMEDSYS.COM> wrote: > > > > > > > From: Jonathan Goldberg <jgoldb...(a)BIOMEDSYS.COM> > > Subject: Re: Why SAS programmers need to be aware of perl and R > > To: SA...(a)LISTSERV.UGA.EDU > > Date: Thursday, March 4, 2010, 8:55 AM Three little points: > > > 1) > > Dale: > > You're not really taking exception; I wrote: > > >>that's why the R interface in in IML; OTHER PARTS OF SAS don't > > >>have any data type that loosely corresponds to an R frame. > > In other words, I agree that an R frame and a SAS data set are very > > similar; it's just that only IML has any facilities for manipulating > > SAS data sets as entities. (Unless perhaps you count the table > > processing language). > > Jonathan, > > Can you elaborate on the facilities in IML for manipulating data sets > as entities. I'm afraid that I don't understand your argument. > > Also, why must a SAS data set be mapped into an R data frame as an > entity? > > Dale > > --------------------------------------- > Dale McLerran > Fred Hutchinson Cancer Research Center > mailto: dmclerra(a)NO_SPAMfhcrc.org > Ph: (206) 667-2926 > Fax: (206) 667-5977 > ---------------------------------------- Hide quoted text - > > - Show quoted text - Hi Sas-Lers, Proc matrix was part of base SAS and had a couple of nice properties on big IBM mainframes. 1. It had limited but useful 128bit numeric capabilites(way ahead of its time) 2. It used IBM's separate 'hardware vector engine' for fast parallel vector operations (way ahead of its time) SOAPBOX ON: I made heavy use of 'proc matrix' and when SAS decided to rip it out of base and charge very high fees for large two sided 8 way mainframes, my management was not pleased. SAS did provide a translator from Matrix to IML. Here is what scares me at SAS: 1. It looks like Enterprise Guide is the window to future SAS and SAS_SAP. Also it looks like EG is somehow in bed with Microsoft's proprietary .NET. Suppose Microsoft comes out with a Starship Enterprise Version of .NET and decides to charge $500,000 dollars for Startship Enterprise .NET. SAS is also prety good at playing this game. 2. I worry about EG as a poison pill for programmers and companies. Suppose programmers get sucked into the givaway EG. SAS throws in IOM, metadata servers, stored processes, data architechure tools .. low cost at first. Then comes the 'proc matrix' hammer and programmers and companies have to pony up with massive spending increases or massive reprogramming to move away from SAS-SAP. For instance if the once free components of EG, like proc matrix, are now enterprise versions at extra cost. I think EG should reflect the future costs now. It should be priced at least 2x Windows Base SAS + SAS-Connect. Companies need to take a close look at future IT costs and SAS's revenue strategy with respect to EG. Just look at the costs asssociated with SAP. I also don't like it when SAS gives away 'ODS GRAHICS' and then charges for it later. I know this in not strickly bait and switch, but it smells. I also find it very hypocritical for SAS to complain openly about an inefficient interface to Oracle, when SAS does not even have a silient ODBC product. SOAPBOX OFF:
From: Jack Hamilton on 6 Mar 2010 13:12 The problem with .NET is that it restricts programs to being run on Windows. In theory, some programs could run on other platforms using Mono, but I'll believe that when SAS Institute gives us the Mac version of Enterprise Guide. -- Jack Hamilton jfh(a)alumni.stanford.org Caelum non animum mutant qui trans mare currunt. On Mar 5, 2010, at 10:19 pm, Alan Churchill wrote: > Never going to happen on the .NET front and SAS was right to choose it (they > should do more .NET, not less). > > Also, name a product where Microsoft charges outrageous fees for underlying > code? .NET is required to run Windows so it is core technology and most of > the code base has been released to the public. > > Java, BTW, is solely owned by Sun. What other technology is proposed for > creating UIs? > > Alan > > Alan Churchill > Savian > www.savian.net > Office: (719) 687-5954 > Cell: (719) 310-4870 > > > -----Original Message----- > From: SAS(r) Discussion [mailto:SAS-L(a)LISTSERV.UGA.EDU] On Behalf Of > xlr82sas > Sent: Thursday, March 04, 2010 3:22 PM > To: SAS-L(a)LISTSERV.UGA.EDU > Subject: Re: Why SAS programmers need to be aware of perl and R > > On Mar 4, 11:01 am, stringplaye...(a)YAHOO.COM (Dale McLerran) wrote: >> --- On Thu, 3/4/10, Jonathan Goldberg <jgoldb...(a)BIOMEDSYS.COM> wrote: >> >> >> >> >> >>> From: Jonathan Goldberg <jgoldb...(a)BIOMEDSYS.COM> >>> Subject: Re: Why SAS programmers need to be aware of perl and R >>> To: SA...(a)LISTSERV.UGA.EDU >>> Date: Thursday, March 4, 2010, 8:55 AM Three little points: >> >>> 1) >>> Dale: >>> You're not really taking exception; I wrote: >>>>> that's why the R interface in in IML; OTHER PARTS OF SAS don't >>>>> have any data type that loosely corresponds to an R frame. >>> In other words, I agree that an R frame and a SAS data set are very >>> similar; it's just that only IML has any facilities for manipulating >>> SAS data sets as entities. (Unless perhaps you count the table >>> processing language). >> >> Jonathan, >> >> Can you elaborate on the facilities in IML for manipulating data sets >> as entities. I'm afraid that I don't understand your argument. >> >> Also, why must a SAS data set be mapped into an R data frame as an >> entity? >> >> Dale >> >> --------------------------------------- >> Dale McLerran >> Fred Hutchinson Cancer Research Center >> mailto: dmclerra(a)NO_SPAMfhcrc.org >> Ph: (206) 667-2926 >> Fax: (206) 667-5977 >> ---------------------------------------- Hide quoted text - >> >> - Show quoted text - > > Hi Sas-Lers, > > Proc matrix was part of base SAS and had a couple of nice properties on > big IBM mainframes. > > 1. It had limited but useful 128bit numeric capabilites(way ahead > of its time) > 2. It used IBM's separate 'hardware vector engine' for fast > parallel vector operations (way ahead of its time) > > SOAPBOX ON: > > I made heavy use of 'proc matrix' and when SAS decided to rip it out of > base and charge very high fees for large two sided 8 way mainframes, my > management was not pleased. > > SAS did provide a translator from Matrix to IML. > > Here is what scares me at SAS: > > 1. It looks like Enterprise Guide is the window to future SAS and > SAS_SAP. Also it looks like EG is somehow in bed with Microsoft's > proprietary .NET. Suppose Microsoft comes out with a Starship Enterprise > Version of .NET and decides to charge $500,000 dollars for Startship > Enterprise .NET. SAS is also prety good at playing this game. > > 2. I worry about EG as a poison pill for programmers and companies. > Suppose programmers get sucked into the givaway EG. SAS throws in IOM, > metadata servers, stored processes, data architechure tools .. low cost at > first. Then comes the 'proc matrix' hammer and programmers and companies > have to pony up with massive spending increases or massive reprogramming to > move away from SAS-SAP. For instance if the once free components of EG, like > proc matrix, are now enterprise versions at extra cost. > > I think EG should reflect the future costs now. It should be priced at > least 2x Windows Base SAS + SAS-Connect. Companies need to take a close look > at future IT costs and SAS's revenue strategy with respect to EG. Just look > at the costs asssociated with SAP. I also don't like it when SAS gives away > 'ODS GRAHICS' and then charges for it later. I know this in not strickly > bait and switch, but it smells. > > I also find it very hypocritical for SAS to complain openly about an > inefficient interface to Oracle, when SAS does not even have a silient ODBC > product. > > SOAPBOX OFF:
From: xlr82sas on 6 Mar 2010 16:36
On Mar 6, 10:12 am, j...(a)STANFORDALUMNI.ORG (Jack Hamilton) wrote: > The problem with .NET is that it restricts programs to being run on Windows. > > In theory, some programs could run on other platforms using Mono, but I'll believe that when SAS Institute gives us the Mac version of Enterprise Guide. > > -- > Jack Hamilton > j...(a)alumni.stanford.org > Caelum non animum mutant qui trans mare currunt. > > On Mar 5, 2010, at 10:19 pm, Alan Churchill wrote: > > > > > Never going to happen on the .NET front and SAS was right to choose it (they > > should do more .NET, not less). > > > Also, name a product where Microsoft charges outrageous fees for underlying > > code? .NET is required to run Windows so it is core technology and most of > > the code base has been released to the public. > > > Java, BTW, is solely owned by Sun. What other technology is proposed for > > creating UIs? > > > Alan > > > Alan Churchill > > Savian > >www.savian.net > > Office: (719) 687-5954 > > Cell: (719) 310-4870 > > > -----Original Message----- > > From: SAS(r) Discussion [mailto:SA...(a)LISTSERV.UGA.EDU] On Behalf Of > > xlr82sas > > Sent: Thursday, March 04, 2010 3:22 PM > > To: SA...(a)LISTSERV.UGA.EDU > > Subject: Re: Why SAS programmers need to be aware of perl and R > > > On Mar 4, 11:01 am, stringplaye...(a)YAHOO.COM (Dale McLerran) wrote: > >> --- On Thu, 3/4/10, Jonathan Goldberg <jgoldb...(a)BIOMEDSYS.COM> wrote: > > >>> From: Jonathan Goldberg <jgoldb...(a)BIOMEDSYS.COM> > >>> Subject: Re: Why SAS programmers need to be aware of perl and R > >>> To: SA...(a)LISTSERV.UGA.EDU > >>> Date: Thursday, March 4, 2010, 8:55 AM Three little points: > > >>> 1) > >>> Dale: > >>> You're not really taking exception; I wrote: > >>>>> that's why the R interface in in IML; OTHER PARTS OF SAS don't > >>>>> have any data type that loosely corresponds to an R frame. > >>> In other words, I agree that an R frame and a SAS data set are very > >>> similar; it's just that only IML has any facilities for manipulating > >>> SAS data sets as entities. (Unless perhaps you count the table > >>> processing language). > > >> Jonathan, > > >> Can you elaborate on the facilities in IML for manipulating data sets > >> as entities. I'm afraid that I don't understand your argument. > > >> Also, why must a SAS data set be mapped into an R data frame as an > >> entity? > > >> Dale > > >> --------------------------------------- > >> Dale McLerran > >> Fred Hutchinson Cancer Research Center > >> mailto: dmclerra(a)NO_SPAMfhcrc.org > >> Ph: (206) 667-2926 > >> Fax: (206) 667-5977 > >> ---------------------------------------- Hide quoted text - > > >> - Show quoted text - > > > Hi Sas-Lers, > > > Proc matrix was part of base SAS and had a couple of nice properties on > > big IBM mainframes. > > > 1. It had limited but useful 128bit numeric capabilites(way ahead > > of its time) > > 2. It used IBM's separate 'hardware vector engine' for fast > > parallel vector operations (way ahead of its time) > > > SOAPBOX ON: > > > I made heavy use of 'proc matrix' and when SAS decided to rip it out of > > base and charge very high fees for large two sided 8 way mainframes, my > > management was not pleased. > > > SAS did provide a translator from Matrix to IML. > > > Here is what scares me at SAS: > > > 1. It looks like Enterprise Guide is the window to future SAS and > > SAS_SAP. Also it looks like EG is somehow in bed with Microsoft's > > proprietary .NET. Suppose Microsoft comes out with a Starship Enterprise > > Version of .NET and decides to charge $500,000 dollars for Startship > > Enterprise .NET. SAS is also prety good at playing this game. > > > 2. I worry about EG as a poison pill for programmers and companies. > > Suppose programmers get sucked into the givaway EG. SAS throws in IOM, > > metadata servers, stored processes, data architechure tools .. low cost at > > first. Then comes the 'proc matrix' hammer and programmers and companies > > have to pony up with massive spending increases or massive reprogramming to > > move away from SAS-SAP. For instance if the once free components of EG, like > > proc matrix, are now enterprise versions at extra cost. > > > I think EG should reflect the future costs now. It should be priced at > > least 2x Windows Base SAS + SAS-Connect. Companies need to take a close look > > at future IT costs and SAS's revenue strategy with respect to EG. Just look > > at the costs asssociated with SAP. I also don't like it when SAS gives away > > 'ODS GRAHICS' and then charges for it later. I know this in not strickly > > bait and switch, but it smells. > > > I also find it very hypocritical for SAS to complain openly about an > > inefficient interface to Oracle, when SAS does not even have a silient ODBC > > product. > > > SOAPBOX OFF:- Hide quoted text - > > - Show quoted text - I am not a lawyer but the details of licenses and contracts is in the fine print. SUN Java -- GNU GPLv2 License I believe Java is licensed under popular GNU GPLv2 terms. Everything associated Java language, Java class libraries .... is open Code isolation is required, my drop downs are ok because I do not interact with R, perl or Java with changes at JAVA source code level. I don't think you can make changes to Java code and stick it in your software and charge $500,000 dollars. Microsoft .NET is under the Apache license. Apache license: it allows use of the source code for the development of proprietary software as well as free and open source software. Apache is preferred by coporations because it imposes few restriction on source code usage. This is why SAS uses .NET instead of Java. It has nothing to do with software quality. I don't think everthing is open in .NET, ie certain key stacks - beyond the scope of my knowledge. As far as windows 'open source' minimally it would be nice if Microsoft made available the source code for all the crtical APIs, like windows explorer. I think there are even more issues with C# and its relation to .NET. (Microsoft charging for C##) I don't see why a company cant develop an Enterprise .NET(usng .NET code) along with C## and charge for it. SOAPBOX ON: I couple of lines in a license or contract/license can make all the difference. Microsoft is where it is because of a few lines in a contract/ license with IBM that allowed MS to develop the MS-DOS operating system. There used to be an IBM-DOS and a MS-DOS. What microsoft did was put some horrible GUI on 16bit DOS and sucker the public into using it. With the GUI as an anchor microsoft developed inferior MS-WORD(Wordperfect was much beter) and excel(lotus was better). SAS is now using the EG GUI to sucker executives and bean counters to eliminating Windows and SAS-connect. It's al about the almighty dollar. SAS seeks the SAP fortune, however along with SAS-SAP comes a much lower quality SAS. SOAPBOX OFF: SOAPBOX ON; Microsoft did change the .NET from a weaker 'Community License' to the Appache license a couple of years ago. Users often tend to be supecious of Microsoft because it does things like issue fixes to operating systems like Vista and then has the nerve to charge for Windows 7. Also Microsoft has the best lawyers in the business. |