De fleste resultater for denne søgning er værktøjer, der laver Python ud af SAS-kildekode, og flere af dem gør det godt. Denne side begynder et skridt tidligere: om flytningen overhovedet er rigtig for jeres kodebase, hvad det koster at efterprøve resultatet, og hvad I gør, når svaret er nej.
Der er fire veje ud af en SAS-kodebase, ikke to: aflevere den til et automatisk værktøj, omskrive den i hånden, køre SAS-programmerne som de er på noget, der ikke er SAS, eller lade den være. Hvilken der er rigtig afhænger næsten udelukkende af to spørgsmål: hvor meget kode der er, og om nogen skal kunne genskabe det, programmerne gav før. Alt herunder er, hvad hver vej koster.
Python er oftere den bedre destination, end en side som denne plejer at indrømme. Fire betingelser gør det tydeligt: kodebasen er lille nok til, at én person læser den på en uge, holdet skriver i forvejen Python dagligt, analysen skal alligevel bygges om, og intet længere nede kræver, at de nye tal passer nøjagtigt med de gamle. Holder alle fire, er det billigere at skrive om end at lægge et kompatibilitetslag ind, og tilbage står kode, som holdet kan vedligeholde uden at slæbe rundt på et andet sprog.
Hver mulighed her er det rigtige svar for nogen. Ingen af dem er uden omkostning, og den dyre del er aldrig syntaksen.
Webværktøjer, leverandørtjenester og store sprogmodeller tager .sas-kildekode og giver Python tilbage, typisk ved at afbilde DATA-trin på pandas og de gængse procedurer på statsmodels eller scikit-learn. For et par hundrede linjers ligefrem databehandling er det en reel genvej, og I har et læsbart udgangspunkt på minutter. Regningen kommer senere: hver linje af resultatet skal læses af nogen, der kan begge sprog.
Nogen læser SAS-programmet, regner ud hvad det skulle gøre, og skriver det i Python. Det starter langsommere og er den eneste vej, der ender med kode formet som Python frem for SAS i Python-frakke. Hold, der to år senere er tilfredse med Python, kom næsten altid dertil sådan og lod som regel det gamle program køre ved siden af, indtil tallene passede.
Vejen som sammenligningssiderne springer over. Jenner er en clean room-implementering af SAS 9.4-sproget skrevet i Rust: den læser SAS7BDAT-filer direkte og kører .sas-kildekode, som den står, så der er ingen genereret kode at læse igennem og intet andet sprog for holdet at bære. Det den ikke gør, er at dække hele SAS-sproget, og dækningen offentliggøres procedure for procedure, så I kan tjekke jeres egen, før I læner jer op ad den.
At gøre ingenting er en rigtig beslutning og ofte den rette. Hvis koden er stabil, miljøet den kører i ikke forsvinder i år, og ingen beder om en ændring, giver den migrering I ikke laver det bedste afkast på hele denne side. Tag spørgsmålet op igen, når et platformsskifte, et tilsyn eller et rekrutteringsproblem tvinger det frem.
Måden en automatisk konvertering fejler på er ikke syntaksfejlen; den dukker op første gang koden kører. Det er den tavse numeriske forskel. SAS fylder tegnværdier ud med mellemrum til højre, og det gør Python ikke; SAS tæller datoer fra den 1. januar 1960, mens pandas tæller fra den 1. januar 1970; og et MERGE i et DATA-trin opfører sig ikke som et merge i pandas, når nøglen gentages i begge sider. Intet af det giver et signal. Der kommer et tal ud, som næsten passer, og det er den værste slags forkert. Derfor er den reelle pris en linje-for-linje-læsning af nogen, der behersker begge sprog, plus en periode hvor gammelt og nyt kører side om side på de samme data, indtil outputtet stemmer — og den pris vokser med mængden af kode, ikke med hvor snedig den er.
Jeres kode, jeres data og loggene side om side. Det er den sammenligning der afgør det, og ingen kan køre den for jer.
Start gratis prøveperiode