Hej, Habr! Jeg præsenterer for din opmærksomhed en oversættelse af Stephen Wolframs indlæg .
Forudsætninger for konsistensen af Wolfram-sproget
I dag står vi på tærsklen til store præstationer sammen med programmeringssproget . For bare tre uger siden lancerede vi for at hjælpe vores brugere med at integrere Wolfram-sproget i deres store softwareprojekter. I dag lancerer vi , for at give en koordineret platform for funktioner skabt til at udvide Wolfram-sproget, og vi åbner også et lager af funktioner for alle, der kan bidrage til udviklingen af vores softwareprodukt.
Wolfram Function Repository er noget, der er muliggjort af Wolfram-sprogets unikke natur, ikke kun som programmeringssprog, men også som et . I traditionelle programmeringssprog indebærer tilføjelse af væsentlig ny funktionalitet normalt oprettelse af hele ekstra biblioteker, der måske eller måske ikke fungerer, når de bruges sammen. Dog på Wolfram-sproget , at det er muligt at udvide dens funktionalitet markant ved blot at tilføje nye funktioner, der umiddelbart integreres i hele sprogets holistiske struktur.
For eksempel indeholder Wolfram-funktionsopbevaringen allerede struktureret i 26 tematiske kategorier:
Ligeledes mere end , indbygget i Wolfram-sproget, har hver funktion fra repository en dokumentationsside med en detaljeret beskrivelse af dem og eksempler på arbejde:
For at komme til siden skal du kopiere ovenstående objekt (funktion BLOB), indsætte det i inputlinjen og derefter køre funktionen - den er allerede indbygget i Wolfram-sproget og understøttet som standard startende med :
Det skal her bemærkes, at ved behandling Du behøver for eksempel ikke at oprette et "billedbehandlingsbibliotek" - da vi allerede har implementeret en konsistent og omhyggeligt algoritmisk måde i Wolfram-sproget , som umiddelbart kan behandles af forskellige grafiske sprogfunktioner:
Det håber jeg med støtten , som er vokset og udvidet (baseret på Wolfram-sproget) i løbet af de sidste årtier. Wolfram-funktionsopbevaringen vil give mulighed for i en overskuelig fremtid at udvide rækken af (muligvis potentielt betydelige, specialiserede inden for forskellige videnskabs- og teknologiområder) funktioner betydeligt på sproget. Dermed bliver det muligt at bruge både sprogets indhold (dets indbyggede funktioner) og , som implementeres ud fra sproget. (Det skal bemærkes her, at Wolfram-sproget allerede har mere end ).
Funktioner fra lageret kan indeholde små eller store stykker kode skrevet i Wolfram-sproget. Det kan for eksempel være opkald . Det unikke ved denne tilgang er, at når du borer ned til funktionalitet på brugerniveau, vil der ikke være nogen potentielle uoverensstemmelser, fordi tilgangen er bygget oven på den konsistente struktur i Wolfram-sproget - og hver funktion vil automatisk fungere korrekt - præcis som hun burde.
Skallen og programmeringsstrukturen i Wolfram Feature Repository er designet, så alle kan bidrage til den fælles sag på den mest enkle og bekvemme måde for dem - faktisk bare . Indbyggede automatiske funktioner giver dig mulighed for at tjekke nye funktioner tilføjet til lageret for at sikre deres integration i sproget. Vores virksomhed satser på den brede vifte af brugere, der kan integrere deres funktioner i sproget, frem for på den store kompleksitet af nye funktioner – og selvom der er en gennemgangsproces, insisterer vi ikke på noget som f.eks. eller strenge standarder for fuldstændigheden og pålideligheden af nye brugerfunktioner, i modsætning til den mere strenge test af funktioner indbygget i det kernesprog, vi anvender.
Der er mange afvejninger og detaljer i denne tilgang, men vores mål er at optimere Wolfram feature repository både til brugeroplevelsen og for at sikre, at nye brugerfunktioner bidrager meningsfuldt til udviklingen af sproget. Efterhånden som vi vokser, er jeg ikke i tvivl om, at vi bliver nødt til at opfinde nye metoder til at behandle og validere funktioner indbygget i depotet, ikke mindst til at organisere et stort antal funktioner og finde dem, som brugerne har brug for. Det er dog opmuntrende, at den vej, vi har valgt, er en god start. jeg personligt til den oprindelige database. Mange af dem er baseret på kode, som jeg personligt har udviklet i et stykke tid. Og det tog mig kun et par minutter at skubbe dem til depotet. Nu hvor de er i depotet, kan jeg endelig - straks og til enhver tid - bruge disse funktioner efter behov, uden at skulle bekymre mig om at søge efter filer, downloade pakker mv.
Øge effektiviteten og samtidig reducere omkostningerne
Selv før internettet var der måder at dele Wolfram Language-kode på (vores første store centraliserede projekt var , skabt til Mathematica i 1991 baseret på cd-rom osv.). Naturligvis er den foreslåede tilgang til implementering baseret på Wolfram-funktionsopbevaringen et mere kraftfuldt og pålideligt værktøj til implementering af ovenstående opgaver.
I over 30 år har vores virksomhed arbejdet flittigt for at bevare integriteten af Wolfram-sprogstrukturen, og dette er afgørende for at sikre, at Wolfram-sproget ikke blot bliver et programmeringssprog, men også et . Og således er essensen af tilgangen til implementering af Wolfram-funktionsopbevaringen at bruge en samlet tilgang til programmering og udvikling af nye funktioner, der tilføjes sekventielt og passer ind i sprogets rammer, så det kan udvikle sig og udvikle sig sammen.
Forskellige beregningsprocesser forekommer i implementeringsstrukturen af hver funktion. Det skal her bemærkes, at det er nødvendigt, at funktionen har et klart og ensartet udseende og visuel læsbarhed for brugeren. I denne sammenhæng præsenteres de indbyggede funktioner i Wolfram-sproget med mere end 6000 sekventielle eksempler på, hvordan man korrekt programmerer funktioner (disse er vores som omfatter ). Hvad denne tilgang i sidste ende gør, at Wolfram-funktionsarkivet er i stand til at fungere godt, er Wolfram-sprogets strukturelle karakter med dets store antal yderligere og varierede biblioteker, der allerede er indbygget i sproget. Hvis du for eksempel har en funktion, der behandler billeder, eller Eller og eller nogle andre - deres konsekvente symbolske repræsentation findes allerede i sproget, og takket være dette bliver din funktion straks kompatibel med andre funktioner i sproget.
At skabe et lager, der faktisk fungerer godt, er en interessant metaprogrammeringsopgave. For eksempel vil et overskud af begrænsninger i programmet ikke tillade opnåelse af den nødvendige forening og universalitet af algoritmen. Ligesom med et utilstrækkeligt antal funktionelle begrænsninger, vil du ikke være i stand til at implementere en tilstrækkelig korrekt sekvens af algoritmeudførelse. Adskillige tidligere eksempler på implementering af et kompromis af disse tilgange, implementeret af vores virksomhed, fungerede ganske stabilt - disse er: , lanceret i 2007 og kører nu online online med over 12000 brugerinteraktive demoer. I der er mere end 600 færdige databaser, der kan bruges i Wolfram-sproget, og fyldes op med nye neurale netværk næsten hver uge (der er allerede 118 af dem nu), og de er straks forbundet via funktionen på Wolfram-sproget.
Alle ovenstående eksempler har et grundlæggende træk - de genstande og funktioner, der er indsamlet i projektet, har en meget høj grad af strukturering og fordeling af processer. Naturligvis kan detaljerne i strukturen af, hvad der er en demo eller et neuralt netværk eller noget andet, variere meget, men den grundlæggende struktur for ethvert nuværende depot forbliver altid den samme. Så hvad er din mening, kære bruger, om at oprette et sådant lager, der tilføjer udvidelser til Wolfram-sproget? Wolfram-sproget er designet til at være ekstremt fleksibelt, så det kan udvides og ændres på enhver måde. Denne omstændighed er ekstremt vigtig for evnen til hurtigt at skabe forskellige store softwareprojekter i Wolfram-sproget. Det skal her bemærkes, at efterhånden som sprogets fleksibilitet øges, vil omkostningerne ved projekter, der gennemføres på et sådant sprog, uundgåeligt stige. Dette skyldes det faktum, at jo mere brugeren bruger et sådant sprog, jo mere dedikeret funktionalitet får han, men vi skal ikke glemme, at denne tilgang også kan have negative sider i forhold til manglende evne til at sikre konsistent konsistens af programmoduler.
Der er et almindeligt problem med biblioteker i traditionelle programmeringssprog - hvis du for eksempel bruger et bibliotek, vil koden fungere korrekt, men hvis du forsøger at bruge flere biblioteker, er der ingen garanti for, at de vil interagere korrekt med hinanden . Også i traditionelle programmeringssprog - i modsætning til et fuldgyldigt computersprog - er der ingen måde at garantere tilstedeværelsen af konsistente indbyggede repræsentationer for andre funktioner eller datatyper end deres grundlæggende strukturer. Men i virkeligheden er problemet endnu større, end det ser ud ved første øjekast: hvis man bygger en storstilet vertikal af funktionalitet, så er det uden de enorme omkostninger ved centraliseret projektprogrammering, som vi lægger i Wolfram-sproget, umuligt at opnå konsistens. Det er derfor vigtigt, at alle softwaremoduler altid fungerer korrekt sammen.
Så ideen bag Wolfram feature repository er at undgå problemet skitseret ovenfor ved blot at tilføje udvidelser til sproget i relativt små stykker kode via individuelle funktioner, der er nemmere at udvikle som sammenhængende moduler. Når det er sagt, er der programmeringsfunktioner, der ikke kan gøres praktiske ved hjælp af individuelle funktioner (og vores virksomhed planlægger at frigive en optimeret programmeringsalgoritme i den nærmeste fremtid for at hjælpe med at implementere softwarepakker i stor skala). Men baseret på de funktioner, der allerede er indbygget i Wolfram-sproget, er der mange programmeringsmuligheder, som implementeres baseret på individuelle funktioner. Ideen her er, at det med en relativt lille programmeringsindsats er muligt at skabe en række nye og meget brugbare funktioner, der vil give tilstrækkelig sammenhæng til designet, de vil være godt koordinerede med hinanden, og også udover dette, vil nemt og bredt kunne bruges i sproget i fremtiden.
Denne tilgang er naturligvis et kompromis. Hvis en større pakke blev implementeret, kunne man forestille sig en helt ny verden af funktionalitet, der ville være ekstremt kraftfuld og nyttig. Hvis der er behov for at få ny funktionalitet, der passer til alt det andet, men du ikke er villig til at bruge mange kræfter på at udvikle projektet, kan det desværre medføre en reduktion af omfanget af dit projekt. Ideen bag Wolfram feature repository er at give funktionalitet til en definerende del af et projekt; denne tilgang vil tilføje kraftfuld funktionalitet og samtidig gøre det nemmere at opretholde en god konsistens i et programmeringsprojekt.
Hjælp med at tilføje brugerdefinerede funktioner til funktionslageret
Vores team har arbejdet hårdt for at gøre det nemt for brugere at bidrage til Wolfram-lagerets funktioner. På skrivebordet (allerede i ), Du kan blot gå gennem hovedmenuens faner sekventielt: Fil > Ny > RepositoryItem > Function Repository Item, og du får "" (programmæssigt inde i arbejdsbordet. Du kan også bruge den analoge funktion - ):
Der er to hovedtrin, du skal udføre: For det første skal du faktisk skrive koden for din funktion ned og for det andet nedskrive dokumentation, der illustrerer, hvordan din funktion skal fungere.
Klik på knappen "Åbn prøve" øverst for at se et eksempel på, hvad du skal gøre:
I det væsentlige forsøger du at skabe noget, der ligner en indbygget funktion i Wolfram-sproget. Bortset fra at den kan noget meget mere specifikt end en indbygget funktion. Samtidig vil forventningerne til dens fuldstændighed og pålidelighed være meget lavere.
Du skal give din funktion et navn, der følger Wolfram-sprogets retningslinjer for navngivning af funktioner. Derudover skal du udvikle dokumentation for din funktion, svarende til sprogets indbyggede funktioner. Jeg vil tale mere om dette senere. Indtil videre skal du blot bemærke, at der i rækken af knapper øverst i definitionsnotebook-filen er en knap , som forklarer, hvad du skal gøre, og en Tools-knap, som giver værktøjer til at formatere din funktions dokumentation.
Når du er sikker på, at alt er udfyldt korrekt, og du er klar, skal du klikke på knappen "Kontroller". Det er helt normalt, at du ikke har fundet ud af alle detaljerne endnu. Så "Check"-funktionen vil automatisk køre og udføre en masse stil- og konsistenstjek. Ofte vil den straks bede dig om at bekræfte og acceptere rettelserne (for eksempel: "Denne linje skal slutte med et kolon", og det vil bede dig om at indtaste et kolon). Nogle gange vil hun bede dig om at tilføje eller ændre noget selv. Vi vil konstant tilføje nye funktioner til den automatiske funktionalitet af Check-knappen, men grundlæggende er dens formål at sikre, at alt, hvad du sender til feature-lageret, allerede følger så mange stilretningslinjer som muligt.
Så efter at have kørt "Check", kan du bruge "Preview". "Preview" opretter en forhåndsvisning af den dokumentationsside, du har defineret for din funktion. Du kan også oprette en forhåndsvisning af en fil, der er oprettet på din computer, eller for en fil, der er placeret i skylageret. Hvis du af en eller anden grund ikke er tilfreds med det, du ser i forhåndsvisningen, skal du blot gå tilbage og foretage de nødvendige rettelser og derefter klikke på Preview-knappen igen.
Nu er du klar til at skubbe din funktion ind i depotet. Implementeringsknappen giver dig fire muligheder:
Det vigtige i dette trin er, at du kan indsende din funktion til Wolfram-funktionsopbevaringen, så den er tilgængelig for alle. Samtidig kan du også placere din funktion til et begrænset antal brugere. For eksempel kan du oprette en funktion, der hostes lokalt på din computer, så den er tilgængelig, når du bruger den pågældende computer. Eller du kan poste det i din , så den er tilgængelig for dig, når du er forbundet til skyen. Du kan også være vært for (implementere) funktionen offentligt via din cloud-konto. Det vil ikke være i det centrale Wolfram-funktionsopbevaring, men du vil være i stand til at give nogen en URL, der giver dem mulighed for at få din funktion fra din konto. (I fremtiden vil vi også understøtte centrale depoter i hele vores virksomhed.)
Så lad os sige, at du rent faktisk vil indsende din funktion til Wolfram-funktions videnbase. For at gøre dette skal du klikke på knappen "Send" til depotet. Så hvad sker der så i øjeblikket? Din ansøgning sættes straks i kø til gennemgang og godkendelse af vores dedikerede team af kuratorer.
Efterhånden som din ansøgning skrider frem gennem godkendelsesprocessen (som typisk tager flere dage), vil du modtage meddelelser om dens status og eventuelt forslag til fremtidig brug. Men når din funktion er godkendt, vil den straks blive offentliggjort til Wolfram Feature Repository og vil være tilgængelig for alle at bruge. (Og dette vises i og så videre)
Hvad skal der være i lageret?
Det skal bemærkes, at vores virksomhed har meget høje standarder for fuldstændighed, pålidelighed og overordnet kvalitet, og af de 6000+ funktioner, som vi allerede har indbygget i Wolfram-sproget i løbet af de sidste 30+ år, opfylder alle ovenstående krav. Målet med Wolfram Function Repository er at bruge al den struktur og funktionalitet, der allerede findes i Wolfram-sproget for at tilføje så mange lettere funktioner (det vil sige funktioner med højere ydeevne) som muligt.
Selvfølgelig skal funktioner i Wolfram-funktionsarkivet være i overensstemmelse med Wolfram-sprogets designprincipper – så de fuldt ud kan interagere med andre funktioner og brugernes forventninger til, hvordan funktionen skal fungere korrekt. Funktionerne behøver dog ikke at være af samme fuldstændighed eller pålidelighed.
I Wolfram-sprogets indbyggede funktioner arbejder vi hårdt på at gøre programmeringsfunktioner så generelle som muligt. Når det er sagt, når der i Wolfram-funktionsopbevaringen er der ikke noget galt med at have en funktion i det, der simpelthen håndterer en meget specifik, men nyttig sag. For eksempel funktionen kan modtage filer i ét bestemt format og oprette mail på én bestemt måde. opretter diagrammer med kun bestemte farver og mærkning osv.
Et andet punkt relateret til de indbyggede funktioner er, at vores virksomhed gør alt for at håndtere alle atypiske sager, at håndtere forkert input, og så videre. I et funktionsdepot er det helt normalt, at der er en speciel funktion, der håndterer hovedsagerne om at løse et problem og ignorerer alle andre.
Den åbenlyse pointe er, at det er bedre at have funktioner, der gør mere og gør det bedre, men optimering til et funktionslager - i modsætning til de indbyggede funktioner i Wolfram-sproget - burde have flere funktioner bundtet med flere funktioner i stedet for at dykke ned i implementeringsprocesserne for hver specifik funktion.
Lad os nu se på et eksempel på testfunktioner i et lager. Konsistensforventninger til sådanne funktioner er naturligvis meget lavere end for indbyggede sprogfunktioner. Dette gælder især i tilfælde, hvor funktioner afhænger af eksterne ressourcer såsom API'er, er det vigtigt konstant at udføre konsistente tests, hvilket automatisk sker inden for verifikationsalgoritmerne. I nb-filen kan du eksplicit specificere definitioner (i afsnittet Yderligere oplysninger) og angive så mange tests som defineret af enten input- og output-strenge eller fuldtegnsobjekter af typen , så meget som du finder passende. Derudover forsøger systemet konstant at gøre de dokumentationseksempler, du giver, til en verifikationsproces (og nogle gange kan dette være ret ressourcekrævende, for eksempel for en funktion, hvis resultat afhænger af tilfældige tal eller tidspunktet på dagen).
Som følge heraf vil funktionsarkivet have en række implementeringskompleksiteter. Nogle vil kun være en enkelt linje kode, andre kan involvere tusinder eller titusinder af linjer, sandsynligvis ved at bruge mange hjælpefunktioner. Hvornår er det værd at tilføje en funktion, der kræver meget lidt kode at definere? Dybest set, hvis der er en funktion , som brugere let ville forstå, hvis de så det i et stykke kode, så kan det allerede tilføjes. Ellers er det nok bedre bare at tilføje koden til dit program igen, hver gang du skal bruge det.
Hovedformålet med et funktionslager (som navnet antyder) er at introducere nye funktioner i sproget. Hvis du vil tilføje nye data eller , brug . Men hvad hvis du vil introducere nye typer objekter til dine beregninger?
Der er faktisk to måder. Du ønsker måske at introducere en ny objekttype, som vil blive brugt i nye funktioner i funktionslageret. Og i dette tilfælde kan du altid bare skrive dens symbolske repræsentation ned og bruge den, når du indtaster eller udskriver funktioner i et funktionslager.
Men hvad nu hvis du vil repræsentere et objekt og derefter definere, gennem eksisterende funktioner i Wolfram-sproget, at du vil arbejde med det? Wolfram-sproget har altid haft en letvægtsmekanisme til dette, kaldet . Med nogle begrænsninger (især for funktioner, der ), giver et funktionslager dig mulighed for blot at repræsentere en funktion og definere værdier for den. (At hæve forventningen om konsistens, når der skabes et nyt større design, der er fuldt integreret i Wolfram-sproget, er generelt en meget vigtig procedure, der ikke kan opnås ved blot at øge omkostningerne ved projektet, og det er noget, vores virksomhed gør som en del af projekter for langsigtet udvikling af sproget er denne opgave ikke et mål, der er sat som en del af udviklingen af depotet).
Så hvad kan der være i funktionskoden i et funktionslager? , selvfølgelig (i hvert fald hvis det ikke repræsenterer for og ydelsen af selve programmet, som et computermiljø) samt enhver funktion fra funktionslageret. Der er dog andre funktionaliteter: en funktion i et funktionslager kan kalde en API eller i Eller . Selvfølgelig er der nogle risici forbundet med dette. På grund af det faktum, at der ikke er nogen garantier for, at API'et ikke ændres, og funktionen i funktionslageret holder op med at virke. For at hjælpe med at identificere problemer som dette er der en note på dokumentationssiden (i Krav-sektionen) for enhver funktion, der er afhængig af mere end blot indbygget Wolfram Language-funktionalitet. (Selvfølgelig, når det kommer til rigtige data, kan der være problemer selv med denne funktionalitet - fordi data fra den virkelige verden ændrer sig konstant, og nogle gange ændres endda deres definitioner og struktur).
Skal al kode til Wolfram feature repository skrives i Wolfram? Bestemt, koden inde i den eksterne API bør ikke skrives på Wolfram-sproget, som ikke engang laver sprogkoden. Faktisk, hvis du finder en funktion i næsten ethvert eksternt sprog eller bibliotek, kan du oprette en indpakning, der giver dig mulighed for at bruge den i Wolfram-funktionsopbevaringen. (Normalt skal du bruge de indbyggede funktioner til dette eller i Wolfram sprogkode.)
Så hvad er meningen med at gøre dette? I det væsentlige giver dette dig mulighed for at bruge hele det integrerede Wolfram Language-system og hele dets samlede sæt af softwarefunktioner. Hvis du henter basisimplementeringen fra et eksternt bibliotek eller sprog, kan du bruge den rige symbolske struktur i Wolfram-sproget til at skabe en praktisk funktion på øverste niveau, der giver brugerne mulighed for nemt at bruge enhver funktionalitet, der allerede er implementeret. Dette burde i det mindste være muligt i en ideel verden, hvor alle byggestenene til indlæsning af biblioteker osv. eksisterer, i hvilket tilfælde de ville blive håndteret automatisk af Wolfram-sproget. (Det skal bemærkes, at der i praksis kan være problemer med specifikt computersystem, og cloud storage kan udgøre yderligere sikkerhedsproblemer).
I øvrigt, når man først ser på typiske eksterne biblioteker, virker de ofte for komplekse til at blive dækket i nogle få funktioner, men i mange tilfælde kommer meget af kompleksiteten fra at skabe den infrastruktur, der er nødvendig for biblioteket og alle funktioner til at støtte det. Men når man bruger Wolfram-sproget, er infrastrukturen typisk allerede indbygget i pakkerne, og det er derfor ikke nødvendigt at eksponere alle disse supportfunktioner i detaljer, men kun oprette funktioner til de "øverste" applikationsspecifikke funktioner i biblioteket .
"Økosystem" af videnbasen
Hvis du har skrevet funktioner, som du bruger regelmæssigt, så send dem til Wolfram Function Repository! Hvis der ikke kommer noget mere ud af dette (sprogudvikling), så vil det selv da være meget mere bekvemt for dig at bruge funktionerne til personlig brug. Det er dog logisk at antage, at hvis du bruger funktionerne regelmæssigt, vil måske andre brugere også finde dem nyttige.
Du kan naturligvis komme i en situation, hvor du ikke er i stand til - eller ikke ønsker - at dele dine funktioner eller i tilfælde af at få adgang til private informationsressourcer. Selv i sådanne tilfælde kan du blot implementere funktionerne på din egen cloud-konto, adgang til dem. (Hvis din organisation har , så vil den snart være i stand til at være vært for sit eget private funktionslager, som kan administreres fra din organisation og indstille, om visninger skal tvinges til at blive vist af tredjepartsbrugere.)
De funktioner, du sender til Wolfram-funktionsarkivet, behøver ikke at være perfekte; de skal bare være nyttige. Dette er lidt ligesom "Fejl"-sektionen i klassisk Unix-dokumentation - i "Definitions-sektionen" er der en "Author's Notes"-sektion, hvor du kan beskrive begrænsninger, problemer osv., som du allerede kender til din funktion. Derudover, når du indsender din funktion til lageret, kan du tilføje indsendelsesnoter, som vil blive læst af et dedikeret team af kuratorer.
Når en funktion er udgivet, har dens side altid to links i bunden: ""Og"" Hvis du vedhæfter en note (f.eks. fortæl mig om fejl), kan du markere afkrydsningsfeltet, der siger, at din besked og kontaktoplysninger skal deles med forfatteren.
Nogle gange vil du bare bruge funktioner fra Wolfram-funktionsarkivet, såsom indbyggede funktioner, uden at se på deres kode. Men hvis du vil tage et kig indenfor, er der altid en Notesblok-knap øverst. Klik på den, og du får din egen kopi af den originale definitionsnotesbog, der blev indsendt til funktionslageret. Nogle gange kan du bare bruge det som eksempel til dine behov. Samtidig kan du også udvikle din egen modifikation af denne funktion. Du vil måske poste disse funktioner, du har fundet fra lageret på din computer eller i din bladlusskylagerkonto, måske vil du indsende dem til funktionsvidenbasen, måske som en forbedret, udvidet version af den originale funktion.
I fremtiden planlægger vi at understøtte Git-stil forking til feature repositories, men indtil videre forsøger vi at holde det enkelt, og vi har altid kun én accepteret version af hver funktion indbygget i sproget. Oftere end ikke (medmindre udviklere opgiver at vedligeholde de funktioner, de har udviklet og reagerer på brugerindsendelser), tager den oprindelige forfatter af funktionen kontrol over opdateringer til den og indsender nye versioner, som derefter gennemgås, og hvis de består gennemgangsprocessen , udgivet på sproget.
Lad os overveje spørgsmålet om, hvordan "versionering" af udviklede funktioner fungerer. Lige nu, når du bruger en funktion fra funktionslageret, vil dens definition blive gemt permanent på din computer (eller på din skykonto, hvis du bruger skyen). Hvis en ny version af en funktion er tilgængelig, vil du, næste gang du bruger den, modtage en besked om dette. Og hvis du vil opdatere funktionen til en ny version, kan du gøre det ved hjælp af kommandoen . ("Funktionsklatten" gemmer faktisk flere versionsoplysninger, og vi planlægger at gøre dette mere tilgængeligt for vores brugere i fremtiden.)
En af de smukke ting ved Wolfram Function Repository er, at ethvert Wolfram Language-program, hvor som helst, kan bruge funktioner fra det. Hvis et program dukker op i en notesblok, er det ofte praktisk at formatere depotfunktionerne som letlæselige "funktionsbinære objekt"-funktioner (måske med et passende versionssæt).
Du kan altid få adgang til enhver funktion i funktionsarkivet ved hjælp af tekst . Og dette er meget praktisk, hvis du skriver kode eller scripts direkte til Wolfram Engine, for eksempel med (Det skal især bemærkes, at funktionsarkivet er fuldt kompatibelt med ).
Hvordan fungerer det?
Inde i funktionerne i Wolfram repository er dette muligt ved at bruge nøjagtig det samme baser, som i (datalager, , osv.), ligesom alle andre Wolfram-systemressourcer, i sidste ende baseret på funktion .
Overvej :
Indeni kan du se nogle oplysninger ved hjælp af funktionen :
Hvordan fungerer opsætning af en ressourcefunktion? Den enkleste er en rent lokal sag. Her er et eksempel, der tager en funktion (i dette tilfælde kun en ren funktion) og definerer den som en ressourcefunktion for en given programsession:
Når du har lavet definitionen, kan du bruge ressourcefunktionen:
Bemærk, at der er et sort ikon i denne funktionsblok . Det betyder, at BLOB-funktionen refererer til den in-memory-ressourcefunktion, der er defineret for den aktuelle session. En ressourcefunktion, der er permanent gemt på din computer eller cloud-konto, har et gråt ikon . Og der er et orange ikon for en officiel ressourcefunktion i Wolfram Feature Repository .
Så hvad sker der, når du bruger menuen Udvid i Definition Notebook? For det første tager den alle definitionerne i notesblokken og skaber en symbolsk ud fra dem ). (Og hvis du bruger en tekstbaseret IDE eller et program, kan du også udtrykkeligt oprette )
Lokal implementering af en funktion fra et lager på din computer udføres ved hjælp af kommandoen for et ressourceobjekt at gemme det som på dit filsystem. Implementering til en cloud-konto udføres ved hjælp af kommandoen for et ressourceobjekt, og en offentlig cloud-implementering er . I alle tilfælde bruges også til at registrere ressourcefunktionens navn, så vil arbejde.
Hvis du klikker på knappen Send for et funktionslager, hvad sker der under det kaldet på et ressourceobjekt. (Og hvis du bruger en tekstinputgrænseflade, kan du også ringe direkte.)
Som standard foretages indsendelser under det navn, der er knyttet til dit Wolfram ID. Men hvis du sender en ansøgning på vegne af et udviklingsteam eller en organisation, kan du det og i stedet bruge det som navn til at interagere med dine synspunkter.
Når du har indsendt nogen af dine funktioner til funktionsvidenbasen, sættes den i kø til gennemgang. Hvis du modtager kommentarer som svar, vil de normalt være i form af en tekstfil med yderligere "kommentarceller" tilføjet. Du kan altid tjekke status for din ansøgning ved at besøge . Men når din funktion er godkendt, vil du blive underrettet (via e-mail), og din funktion vil blive sendt til Wolfram-funktionsarkivet.
Nogle finesser på arbejdet
Ved første øjekast kan det se ud som om du bare kan tage en definitionsnotesbog og lægge den ordret ind i et funktionslager, men der er faktisk en hel del finesser involveret - og håndtering af dem kræver noget ret kompleks meta-programmering, håndtering af symbolsk behandling som koden, der definerer funktionen, og selve Notesblok er defineret. Det meste af dette sker internt, bag kulisserne, men det kan have nogle implikationer, der er værd at forstå, hvis du skal bidrage til videnbasen om funktioner.
Første umiddelbare subtilitet: Når du udfylder Definition Notebook, kan du blot henvise til din funktion overalt ved at bruge et navn som f.eks. MyFunction, som ligner et almindeligt navn for en funktion i Wolfram-sproget, men for funktionsopbevaringsdokumentation erstattes dette er, hvad brugerne rent faktisk vil bruge, når de arbejder med funktionen.
Den anden finesse: Når du opretter en ressourcefunktion fra Definition Notebook, skal alle afhængigheder involveret i funktionsdefinitionen fanges og eksplicit inkluderes. Men for at sikre, at definitionerne forbliver modulære, skal du sætte alt i en unik . (Selvfølgelig, , er i funktionslageret.)
Typisk vil du aldrig se noget spor af den kode, der blev brugt til at konfigurere dette navneområde. Men hvis du af en eller anden grund kalder et underudført symbol inde i din funktion, så vil du se, at dette symbol er i funktionens interne kontekst. Men når du behandler Definition Notepad, er i det mindste det symbol, der svarer til selve funktionen som en funktionel BLOB frem for en rå karakter i den interne kontekst.
Funktionsarkivet er til at definere nye funktioner. Og disse funktioner kan have muligheder. Ofte er disse parametre (f.eks. eller ) vil kunne bruges til indbyggede funktioner, såvel som til dem, som der allerede findes indbyggede symboler for. Men nogle gange kan en ny funktion kræve nye muligheder. For at opretholde modularitet skal disse parametre være symboler defineret i en unik intern kontekst (eller noget i retning af hele ressourcefunktioner, det vil sige sig selv). For nemheds skyld giver funktionslageret dig mulighed for at definere nye muligheder i strengdefinitioner. Og for brugerens bekvemmelighed er disse definitioner (forudsat at de brugte и ) behandles også, så parametre ved brug af funktioner kan angives ikke kun som strenge, men også som globale symboler med de samme navne.
De fleste funktioner gør simpelthen, hvad de skal gøre, hver gang de kaldes, men nogle funktioner skal initialiseres, før de kan køre i en bestemt session - og for at løse dette problem er der en "Initialisering"-sektion i Definition-sektionen.
Funktioner fra et lager kan bruge andre funktioner, der allerede er i lageret; for at opsætte definitioner for et funktionslager, der omfatter to (eller flere) funktioner, der refererer til hinanden, skal du implementere dem i din programsession, så du kan reference som på dem , så kan du oprette de kombinationer af disse funktioner, du har brug for, eksempler (jeg forstod ikke) og tilføje en ny funktion til depotet baseret på dem, der allerede er postet tidligere. (eller allerede eller tidligere – begge ord er klodsede)
Udviklingsmuligheder. Hvad skal der ske, når depotet bliver rigtig stort?
I dag lancerer vi netop Wolfram Feature Repository, men med tiden forventer vi, at dets størrelse og funktionalitet kan stige dramatisk, og efterhånden som det vokser i udvikling, vil der være forskellige problemer, som vi allerede forudser kan opstå.
Det første problem vedrører funktionsnavne og deres unikke karakter. Funktionsarkivet er designet på en sådan måde, at du ligesom de indbyggede funktioner i Wolfram-sproget kan referere til enhver given funktion blot ved at angive dens navn. Men det betyder uundgåeligt, at funktionsnavne skal være globalt unikke på tværs af depotet, så der f.eks. kun kan være ét .
Dette kan umiddelbart virke som et stort problem, men det er værd at indse, at det dybest set er det samme problem som for ting som internetdomæner eller håndtag på sociale medier. Og faktum er, at systemet simpelthen skal have en registrator - og det er en af de roller, som vores virksomhed vil udføre for Wolfram-funktions videnbase. (For private versioner af et repository kan deres registratorer være administratorer.) Et internetdomæne kan naturligvis registreres uden at have noget på sig, men i et funktionsdepot kan et funktionsnavn kun registreres, hvis der er en egentlig definition af funktionen.
En del af vores rolle i styringen af Wolfram-funktions vidensbase er at sikre, at det navn, der er valgt til en funktion, er logisk i betragtning af funktionens definition, og at det følger Wolfram Language-navngivningskonventioner. Vi har over 30 års erfaring med at navngive indbyggede funktioner i Wolfram-sproget, og vores team af kuratorer vil også bringe denne erfaring til funktionsarkivet. Selvfølgelig er der altid undtagelser. For eksempel kan det virke at foretrække at have et kort navn til en funktion, men det er bedre at "forsvare" med et længere, mere specifikt navn, fordi du er mindre tilbøjelig til at støde på nogen, der ønsker at lave et lignende funktionsnavn i fremtiden .
(Det skal bemærkes her, at blot tilføjelse af et medlems-tag for at tvetydige funktioner ikke vil have den tilsigtede effekt. For medmindre du insisterer på altid at tildele et tag, bliver du nødt til at definere et standard-tag for en given funktion og også tildele forfatter-tags , hvilket igen ville kræve global koordinering.)
Efterhånden som videnbasen af Wolfram-funktioner vokser, er et af de problemer, der sandsynligvis vil opstå, opdagelsen af funktioner, som systemet giver (og definitionsfiler kan indeholde nøgleord osv.). For indbyggede funktioner i Wolfram-sproget er der alle mulige krydshenvisninger i dokumentationen for at hjælpe med at "annoncere" funktionerne. Funktioner i et funktionslager kan referere til indbyggede funktioner. Men hvad med den anden vej rundt? For at gøre dette skal vi eksperimentere med forskellige designs for at afsløre lagerfunktioner på dokumentationssider for indbyggede funktioner.
Til indbyggede funktioner i Wolfram-sproget er der et såkaldt detektionslag leveret af , som giver organiserede lister over funktioner relateret til specifikke områder. Det er altid svært at afbalancere man-sider korrekt, og efterhånden som Wolfram-sproget vokser, skal man-sider ofte reorganiseres fuldstændigt. Det er ret nemt at placere funktioner fra et lager i brede kategorier, og endda at opdele disse kategorier konsekvent, men det er meget mere værdifuldt at have ordentligt organiserede sprogreferencesider. Det er endnu ikke klart, hvordan man bedst kan oprette dem for hele funktionsvidenbasen. For eksempel, i funktionslageret kan enhver poste en webside, der indeholder deres "valg" fra lageret:
Wolfram funktion repository er konfigureret som et persistent funktion repository, hvor enhver funktion i det altid vil fungere. Naturligvis kan nye versioner af funktioner blive tilgængelige, og vi forventer, at nogle funktioner naturligvis vil blive forældede med tiden. Funktionerne vil fungere, hvis de bruges i programmer, men deres dokumentationssider vil linke til nye, mere avancerede funktioner.
Wolfram Feature Repository er designet til at hjælpe dig med hurtigt at opdage nye funktioner og lære nye måder at bruge Wolfram-sproget på. Vi er meget optimistiske om, at noget af det, der er blevet udforsket i funktionsarkivet, med tiden vil give mening til at blive indbyggede dele af kernen i Wolfram-sproget. I løbet af det sidste årti har vi haft et lignende sæt . Og en af erfaringerne fra denne erfaring er, at opnåelse af de standarder for kvalitet og konsistens, som vi fokuserer på i alt, der er indbygget i Wolfram-sproget, kræver en masse arbejde, hvilket ofte er sværere end den indledende indsats for at implementere ideen. Alligevel kan en funktion i funktionsvidenbasen tjene som et meget nyttigt proof of concept for en fremtidig funktion, der i sidste ende kan indbygges i Wolfram-sproget.
Det vigtigste her er, at en funktion i et funktionsdepot er noget, der er tilgængeligt for enhver bruger at bruge lige nu. Det er muligt, at en modersmålsfunktion kunne være meget bedre og mere effektiv, men et funktionslager ville give brugerne adgang til alle de nye funktioner med det samme. Og, vigtigst af alt, giver dette koncept alle mulighed for at tilføje nye funktioner, de ønsker.
Tidligere i Wolfram-sprogets historie ville denne idé ikke have fungeret så godt, som den har gjort, men på dette stadie er der lagt så mange kræfter i sproget og en så dyb forståelse af sprogets designprincipper, at det nu virker meget muligt for et stort fællesskab af brugere at tilføje funktioner, der vil opretholde designkonsistens for at gøre dem nyttige for en bred vifte af brugere.
Der er en utrolig ånd af talent(?) i Wolfram Language-brugerfællesskabet. (Selvfølgelig inkluderer dette fællesskab mange førende R&D-eksperter inden for en række forskellige områder.) Jeg håber, at Wolfram Feature Repository vil give en effektiv platform til at låse op og formidle denne talentånd. Kun sammen kan vi skabe noget, der markant vil udvide det område, som Wolfram-sprogcomputerparadigmet kan anvendes til.
I mere end 30 år er vi nået langt med Wolfram-sproget. Lad os nu gå endnu længere sammen. Jeg opfordrer kraftigt alle respekterede brugere af Wolfram-sproget rundt om i verden til at bruge funktionslageret som en platform for dette, såvel som det nye softwareprojekt som Free Wolfram Engine for Developers.
Kilde: www.habr.com