Hei, Habr! Jeg presenterer for din oppmerksomhet en oversettelse av Stephen Wolframs innlegg .
Forutsetninger for konsistensen til Wolfram-språket
I dag står vi på terskelen til store prestasjoner sammen med programmeringsspråket . For bare tre uker siden lanserte vi for å hjelpe brukerne våre med å integrere Wolfram-språket i deres store programvareprosjekter. I dag lanserer vi , for å tilby en koordinert plattform for funksjoner som er opprettet for å utvide Wolfram-språket, og vi åpner også et arkiv med funksjoner for alle som kan bidra til utviklingen av programvareproduktet vårt.
Wolfram Function Repository er noe som er muliggjort av den unike naturen til Wolfram Language, ikke bare som et programmeringsspråk, men også som et . I tradisjonelle programmeringsspråk innebærer å legge til betydelig ny funksjonalitet vanligvis å lage hele tilleggsbiblioteker som kanskje eller kanskje ikke fungerer når de brukes sammen. Imidlertid på Wolfram-språket , at det er mulig å utvide funksjonaliteten betydelig ved ganske enkelt å legge til nye funksjoner som umiddelbart integreres i den helhetlige strukturen til hele språket.
For eksempel inneholder Wolfram-funksjonsrepositoriet allerede strukturert i 26 tematiske kategorier:
Likeledes mer enn , innebygd i Wolfram-språket, har hver funksjon fra depotet en dokumentasjonsside med en detaljert beskrivelse av dem og eksempler på arbeid:
For å komme til siden, kopier objektet ovenfor (funksjon BLOB), lim det inn i inndatalinjen og kjør deretter funksjonen - den er allerede innebygd i Wolfram-språket og støttes som standard fra :
Det skal her bemerkes at ved behandling Du trenger for eksempel ikke å sette opp et "bildebehandlingsbibliotek" - siden vi allerede har implementert en konsistent og nøye algoritmisk måte i Wolfram-språket , som umiddelbart kan behandles av ulike grafiske språkfunksjoner:
Jeg håper det med støtten , som har vokst og ekspandert (basert på Wolfram-språket) i løpet av de siste tiårene. Wolfram-funksjonsdepotet vil i overskuelig fremtid tillate betydelig utvidelse av spekteret av (muligens potensielt betydelige, spesialisert innen ulike felt av vitenskap og teknologi) tilgjengelige på språket. Dermed blir det mulig å bruke både innholdet i språket (dets innebygde funksjoner) og , som implementeres basert på språket. (Det skal bemerkes her at Wolfram Language allerede har mer enn ).
Funksjoner fra depotet kan inneholde små eller store stykker kode skrevet i Wolfram-språket. Dette kan for eksempel være samtaler . Det unike med denne tilnærmingen er at når du driller ned til funksjonalitet på brukernivå, vil det ikke være noen potensielle inkonsekvenser fordi tilnærmingen er bygget på toppen av den konsistente strukturen til Wolfram Language - og hver funksjon vil automatisk fungere korrekt - akkurat som ment. hun burde.
Skallet og programmeringsstrukturen til Wolfram Feature Repository er utformet slik at alle kan bidra til fellessaken på den enkleste og mest praktiske måten for dem – faktisk bare . Innebygde automatiske funksjoner lar deg sjekke nye funksjoner som er lagt til depotet for å sikre at de er integrert i språket. Vårt firma satser på det brede spekteret av brukere som kan integrere funksjonene sine i språket, snarere enn på den store kompleksiteten til nye funksjoner - og selv om det er en gjennomgangsprosess, insisterer vi ikke på noe lignende eller strenge standarder for fullstendigheten og påliteligheten til nye brukerfunksjoner, i motsetning til den mer strenge testingen av funksjoner innebygd i kjernespråket vi bruker.
Det er mange avveininger og detaljer i denne tilnærmingen, men målet vårt er å optimalisere Wolfram-funksjonsdepotet både for brukeropplevelsen og for å sikre at nye brukerfunksjoner bidrar meningsfullt til utviklingen av språket. Etter hvert som vi vokser er jeg ikke i tvil om at vi må finne opp nye metoder for å behandle og validere funksjoner innebygd i depotet, ikke minst for å organisere et stort antall funksjoner og finne de som brukerne trenger. Det er imidlertid oppmuntrende at veien vi har valgt er en god start. jeg personlig til den opprinnelige databasen. Mange av dem er basert på kode som jeg personlig har utviklet lenge. Og det tok meg bare noen få minutter å presse dem til depotet. Nå som de er i depotet, kan jeg endelig – umiddelbart og når som helst – bruke disse funksjonene etter behov, uten å måtte bekymre meg for å søke etter filer, laste ned pakker osv.
Øke effektiviteten samtidig som kostnadene reduseres
Selv før Internett var det måter å dele Wolfram Language-kode på (vårt første store sentraliserte prosjekt var , opprettet for Mathematica i 1991 basert på CD-ROM, etc.). Selvfølgelig er tilnærmingen som er foreslått for implementering basert på Wolfram-funksjonsdepotet et kraftigere og mer pålitelig verktøy for å implementere oppgavene ovenfor.
I over 30 år har selskapet vårt jobbet iherdig for å opprettholde integriteten til Wolfram-språkstrukturen, og dette er avgjørende for å sikre at Wolfram-språket ikke bare blir et programmeringsspråk, men også et . Og dermed er essensen av tilnærmingen for å implementere Wolfram-funksjonsrepositoriet å bruke en enhetlig tilnærming til programmering og utvikling av nye funksjoner som legges til sekvensielt og passer inn i rammeverket til språket slik at det kan utvikle seg og utvikle seg sammen.
Ulike beregningsprosesser forekommer i implementeringsstrukturen til hver funksjon. Det skal her bemerkes at det er nødvendig at funksjonen har et tydelig og enhetlig utseende og visuell lesbarhet for brukeren. I denne sammenhengen presenteres de innebygde funksjonene til Wolfram Language med mer enn 6000 sekvensielle eksempler på hvordan du kan programmere funksjoner riktig (dette er våre som inkluderer ). Det som denne tilnærmingen til syvende og sist gjør at Wolfram-funksjonsarkivet er i stand til å yte godt, er den strukturelle naturen til Wolfram-språket, med dets store antall ekstra og varierte biblioteker som allerede er innebygd i språket. Hvis du for eksempel har en funksjon som behandler bilder, eller Eller Og eller noen andre - deres konsekvente symbolske representasjon finnes allerede i språket, og takket være dette blir funksjonen din umiddelbart kompatibel med andre funksjoner i språket.
Å lage et depot som faktisk fungerer bra er en interessant metaprogrammeringsoppgave. For eksempel vil et overskudd av restriksjoner i programmet ikke tillate å oppnå den nødvendige foreningen og universaliteten til algoritmen. Akkurat som med et utilstrekkelig antall funksjonelle begrensninger, vil du ikke være i stand til å implementere en tilstrekkelig korrekt sekvens av algoritmekjøring. Flere tidligere eksempler på implementering av et kompromiss av disse tilnærmingene, implementert av selskapet vårt, fungerte ganske stabilt - disse er: , lansert i 2007 og kjører nå online online med over 12000 XNUMX brukerinteraktive demoer. I det er mer enn 600 ferdige databaser som kan brukes i Wolfram-språket, og fylles opp med nye nevrale nettverk nesten hver uke (det er allerede 118 av dem nå) og de kobles umiddelbart sammen via funksjonen på Wolfram-språket.
Alle eksemplene ovenfor har et grunnleggende trekk - objektene og funksjonene samlet i prosjektet har en meget høy grad av strukturering og distribusjon av prosesser. Selvfølgelig kan detaljene i strukturen til det som er en demo eller et nevralt nettverk eller noe annet variere sterkt, men den grunnleggende strukturen for ethvert nåværende depot forblir alltid den samme. Så hva er din mening, kjære bruker, om å lage et slikt depot som legger til utvidelser til Wolfram-språket? Wolfram-språket er designet for å være ekstremt fleksibelt, så det kan utvides og endres på alle måter. Denne omstendigheten er ekstremt viktig for muligheten til raskt å lage ulike storskala programvareprosjekter i Wolfram-språket. Det skal her bemerkes at etter hvert som fleksibiliteten til språket øker, vil kostnadene for prosjekter implementert på et slikt språk uunngåelig øke. Dette skyldes det faktum at jo mer brukeren bruker et slikt språk, desto mer dedikert funksjonalitet får han, men vi bør ikke glemme at denne tilnærmingen også kan ha negative sider når det gjelder manglende evne til å sikre konsistent konsistens av programmoduler.
Det er et vanlig problem med biblioteker i tradisjonelle programmeringsspråk - hvis du for eksempel bruker ett bibliotek, vil koden fungere riktig, men hvis du prøver å bruke flere biblioteker, er det ingen garanti for at de vil samhandle riktig med hverandre . Dessuten, i tradisjonelle programmeringsspråk - i motsetning til et fullverdig dataspråk - er det ingen måte å garantere tilstedeværelsen av konsistente innebygde representasjoner for andre funksjoner eller datatyper enn deres grunnleggende strukturer. Men faktisk er problemet enda større enn det ser ut ved første øyekast: hvis man bygger en storskala funksjonalitetsvertikal, så uten de enorme kostnadene ved sentralisert prosjektprogrammering som vi legger inn i Wolfram-språket, er det umulig å oppnå konsistens. Det er derfor viktig at alle programvaremoduler alltid fungerer riktig sammen.
Så ideen bak Wolfram-funksjonsdepotet er å unngå problemet skissert ovenfor ved ganske enkelt å legge til utvidelser til språket i relativt små stykker kode via individuelle funksjoner som er lettere å utvikle som sammenhengende moduler. Når det er sagt, er det programmeringsfunksjoner som ikke kan gjøres praktiske ved å bruke individuelle funksjoner (og selskapet vårt planlegger å lansere en optimalisert programmeringsalgoritme i nær fremtid for å hjelpe med å implementere programvarepakker i stor skala). Men basert på funksjonene som allerede er innebygd i Wolfram-språket, er det mange programmeringsmuligheter som implementeres basert på individuelle funksjoner. Tanken her er at med relativt lite programmeringsinnsats er det mulig å lage en rekke nye og svært nyttige funksjoner som vil gi tilstrekkelig sammenheng til designet, de vil være godt koordinert med hverandre, og i tillegg til dette vil de vil enkelt og mye kunne brukes i språket i fremtiden.
Denne tilnærmingen er selvfølgelig et kompromiss. Hvis en større pakke ble implementert, kunne man tenke seg en helt ny verden av funksjonalitet som ville være ekstremt kraftig og nyttig. Dersom det er behov for å få ny funksjonalitet som vil passe inn med alt annet, men du ikke er villig til å bruke mye krefter på å utvikle prosjektet, kan dette dessverre føre til reduksjon i omfanget av ditt prosjekt. Ideen bak Wolfram-funksjonsdepotet er å gi funksjonalitet til en definerende del av et prosjekt; denne tilnærmingen vil legge til kraftig funksjonalitet samtidig som det gjør det lettere å opprettholde god konsistens i et programmeringsprosjekt.
Hjelp til å legge til egendefinerte funksjoner i funksjonslageret
Teamet vårt har jobbet hardt for å gjøre det enkelt for brukere å bidra til Wolfram-repository-funksjonene. På skrivebordet (allerede i ), Du kan ganske enkelt gå gjennom hovedmeny-fanene sekvensielt: Fil > Ny > RepositoryItem > Function Repository Item og du vil få "" (programmatisk inne på arbeidsbenken. Du kan også bruke den analoge funksjonen - ):
Det er to hovedtrinn du må utføre: For det første, skriv ned koden for funksjonen din, og for det andre, skriv ned dokumentasjon som illustrerer hvordan funksjonen din skal fungere.
Klikk på "Åpne prøve"-knappen øverst for å se et eksempel på hva du må gjøre:
I hovedsak prøver du å lage noe som ligner på en innebygd funksjon i Wolfram-språket. Bortsett fra at den kan gjøre noe mye mer spesifikt enn en innebygd funksjon. Samtidig vil forventningene til dens fullstendighet og pålitelighet være mye lavere.
Du må gi funksjonen din et navn som følger Wolfram Languages retningslinjer for funksjonsnavn. I tillegg må du utvikle dokumentasjon for funksjonen din, i likhet med de innebygde funksjonene i språket. Jeg skal snakke om dette mer detaljert senere. For nå, bare legg merke til at i raden med knapper øverst i definisjonsnotatbokfilen er det en knapp , som forklarer hva du skal gjøre, og en Verktøy-knapp, som gir verktøy for å formatere funksjonens dokumentasjon.
Når du er sikker på at alt er fylt ut riktig og du er klar, klikker du på "Sjekk"-knappen. Det er helt normalt at du ikke har funnet ut av alle detaljene ennå. Så "Sjekk"-funksjonen vil automatisk kjøre og utføre mange stil- og konsistenssjekker. Ofte vil den umiddelbart be deg om å bekrefte og godta korrigeringene (for eksempel: "Denne linjen må slutte med et kolon," og det vil be deg om å angi et kolon). Noen ganger vil hun be deg om å legge til eller endre noe selv. Vi vil stadig legge til nye funksjoner til den automatiske funksjonaliteten til Sjekk-knappen, men i utgangspunktet er formålet å sikre at alt du sender inn til funksjonslageret allerede følger så mange stilretningslinjer som mulig.
Så, etter å ha kjørt "Sjekk", kan du bruke "Forhåndsvisning". "Forhåndsvisning" lager en forhåndsvisning av dokumentasjonssiden du definerte for funksjonen din. Du kan også lage en forhåndsvisning for en fil som er opprettet på datamaskinen din, eller for en fil som ligger i skylagring. Hvis du av en eller annen grunn ikke er fornøyd med det du ser i forhåndsvisningen, går du bare tilbake og gjør de nødvendige rettelsene, og klikker deretter på Forhåndsvisning-knappen igjen.
Nå er du klar til å skyve funksjonen din inn i depotet. Distribuer-knappen gir deg fire alternativer:
Det viktige ved dette trinnet er at du kan sende inn funksjonen din til Wolfram-funksjonsrepositoriet slik at den er tilgjengelig for alle. Samtidig kan du også plassere funksjonen din for et begrenset antall brukere. Du kan for eksempel opprette en funksjon som er vert lokalt på datamaskinen din, slik at den er tilgjengelig når du bruker den aktuelle datamaskinen. Eller du kan legge det ut i din , slik at den er tilgjengelig for deg når du er koblet til skyen. Du kan også være vert for (distribuere) funksjonen offentlig gjennom skykontoen din. Det vil ikke være i det sentrale Wolfram-funksjonslageret, men du vil kunne gi noen en URL som lar dem få funksjonen din fra kontoen din. (I fremtiden vil vi også støtte sentrale depoter i hele selskapet vårt.)
Så la oss si at du faktisk vil sende inn funksjonen din til Wolfram-funksjonens kunnskapsbase. For å gjøre dette, klikker du på "Send"-knappen til depotet. Så hva er det som skjer i øyeblikket? Søknaden din står umiddelbart i kø for gjennomgang og godkjenning av vårt dedikerte team av kuratorer.
Etter hvert som søknaden din går gjennom godkjenningsprosessen (som vanligvis tar flere dager), vil du motta kommunikasjon angående statusen og muligens forslag til fremtidig bruk. Men når funksjonen din er godkjent, vil den umiddelbart publiseres til Wolfram Feature Repository og vil være tilgjengelig for alle å bruke. (Og dette vil vises i og så videre)
Hva skal være på lageret?
Det skal bemerkes at selskapet vårt har svært høye standarder for fullstendighet, pålitelighet og generell kvalitet, og av de 6000+ funksjonene som vi allerede har bygget inn i Wolfram-språket i løpet av de siste 30+ årene, oppfyller alle kravene ovenfor. Målet med Wolfram Function Repository er å bruke all strukturen og funksjonaliteten som allerede finnes i Wolfram Language for å legge til så mange lettere funksjoner (det vil si funksjoner med høyere ytelse) som mulig.
Selvfølgelig må funksjoner i Wolfram-funksjonsrepositoriet samsvare med designprinsippene til Wolfram Language – slik at de fullt ut kan samhandle med andre funksjoner og brukernes forventninger til hvordan funksjonen skal fungere riktig. Funksjonene trenger imidlertid ikke å være like fullstendige eller pålitelige.
I de innebygde funksjonene til Wolfram-språket jobber vi hardt for å gjøre programmeringsfunksjoner så generelle som mulig. Når det er sagt, når i Wolfram-funksjonsrepositoriet er det ingenting galt med å ha en funksjon i den som rett og slett håndterer en veldig spesifikk, men nyttig sak. For eksempel funksjonen kan motta filer i ett spesifikt format og lage e-post på en bestemt måte. lager diagrammer med bare bestemte farger og merking osv.
Et annet poeng knyttet til de innebygde funksjonene er at selskapet vårt gjør alt vi kan for å håndtere alle atypiske saker, for å håndtere feil inndata korrekt, og så videre. I et funksjonslager er det helt normalt at det finnes en spesiell funksjon som håndterer hovedsakene med å løse et problem og ignorerer alle andre.
Det åpenbare poenget er at det er bedre å ha funksjoner som gjør mer og gjør det bedre, men optimalisering for et funksjonsdepot – i motsetning til de innebygde funksjonene i Wolfram-språket – bør ha flere funksjoner sammen med flere funksjoner i stedet for å fordype seg i implementeringsprosessene for hver spesifikke funksjon.
La oss nå se på et eksempel på testing av funksjoner i et depot. Konsistensforventningene til slike funksjoner er naturlig nok mye lavere enn for innebygde språkfunksjoner. Dette gjelder spesielt i tilfeller hvor funksjoner er avhengige av eksterne ressurser som APIer, er det viktig å hele tiden gjennomføre konsistente tester, noe som automatisk skjer innenfor verifikasjonsalgoritmene. I nb-filen kan du eksplisitt spesifisere definisjoner (i tilleggsinformasjonsseksjonen) og spesifisere så mange tester som definert av enten input- og output-strenger eller heltegnsobjekter av typen , så mye du finner passende. I tillegg prøver systemet hele tiden å gjøre dokumentasjonseksemplene du gir til en verifiseringsprosess (og noen ganger kan dette være ganske ressurskrevende, for eksempel for en funksjon hvis resultat avhenger av tilfeldige tall eller tidspunktet på dagen).
Som et resultat vil funksjonsrepositoriet ha en rekke implementeringskompleksiteter. Noen vil bare være en enkelt linje med kode, andre kan involvere tusenvis eller titusenvis av linjer, sannsynligvis ved å bruke mange hjelpefunksjoner. Når er det verdt å legge til en funksjon som krever svært lite kode for å definere? I utgangspunktet, hvis det er for en funksjon , som brukere lett ville forstå hvis de så det i et stykke kode, så kan det allerede legges til. Ellers er det sannsynligvis bedre å bare legge til koden på nytt i programmet hver gang du skal bruke den.
Hovedformålet med et funksjonsdepot (som navnet antyder) er å introdusere nye funksjoner i språket. Hvis du vil legge til nye data eller , bruk . Men hva om du vil introdusere nye typer objekter for beregningene dine?
Det er faktisk to måter. Det kan være lurt å introdusere en ny objekttype som skal brukes i nye funksjoner i funksjonslageret. Og i dette tilfellet kan du alltid bare skrive ned dens symbolske representasjon og bruke den når du legger inn eller skriver ut funksjoner i et funksjonslager.
Men hva om du vil representere et objekt og deretter definere, gjennom eksisterende funksjoner i Wolfram-språket, at du vil jobbe med det? Wolfram-språket har alltid hatt en lettvektsmekanisme for dette, kalt . Med noen begrensninger (spesielt for funksjoner som ), lar et funksjonslager deg ganske enkelt representere en funksjon og definere verdier for den. (Å heve forventningen om konsistens når man lager et nytt hoveddesign som er fullt integrert gjennom Wolfram Language er generelt en svært viktig prosedyre som ikke kan oppnås ved å bare øke kostnadene for prosjektet og er noe selskapet vårt gjør som en del av prosjekter for langsiktig utvikling av språket er ikke denne oppgaven et mål som er satt som en del av utviklingen av depotet).
Så, hva kan være i funksjonskoden i et funksjonslager? , selvfølgelig (i hvert fall hvis det ikke representerer for og ytelsen til selve programmet, som et datamiljø) samt enhver funksjon fra funksjonslageret. Imidlertid er det andre funksjoner: en funksjon i et funksjonslager kan kalle et API, eller i Eller . Selvfølgelig er det noen risiko forbundet med dette. På grunn av det faktum at det ikke er noen garantier for at API ikke endres, og funksjonen i funksjonsbutikken slutter å fungere. For å hjelpe med å identifisere problemer som dette, er det en merknad på dokumentasjonssiden (i Krav-delen) for alle funksjoner som er avhengige av mer enn bare innebygd Wolfram Language-funksjonalitet. (Selvfølgelig, når det kommer til ekte data, kan det være problemer selv med denne funksjonaliteten - fordi data fra den virkelige verden endrer seg konstant, og noen ganger endres til og med definisjoner og struktur.)
Bør all kode for Wolfram-funksjonsrepositoriet skrives i Wolfram? Absolutt, koden i den eksterne API-en bør ikke skrives på Wolfram-språket, som ikke engang lager språkkoden. Faktisk, hvis du finner en funksjon på nesten hvilket som helst eksternt språk eller bibliotek, kan du lage en innpakning som lar deg bruke den i Wolfram-funksjonsrepositoriet. (Vanligvis bør du bruke de innebygde funksjonene for dette eller i Wolfram språkkode.)
Så hva er vitsen med å gjøre dette? I hovedsak lar dette deg bruke hele det integrerte Wolfram Language-systemet og hele dets enhetlige sett med programvarefunksjoner. Hvis du får basisimplementeringen fra et eksternt bibliotek eller språk, kan du bruke den rike symbolske strukturen til Wolfram Language for å lage en praktisk toppnivåfunksjon som lar brukere enkelt bruke alle funksjoner som allerede er implementert. I det minste bør dette være gjennomførbart i en ideell verden der alle byggesteinene til lasting av biblioteker osv. eksisterer, i så fall vil de bli håndtert automatisk av Wolfram-språket. (Det skal bemerkes at det i praksis kan være problemer med spesifikt datasystem, og skylagring kan utgjøre ytterligere sikkerhetsproblemer).
Forresten, når du først ser på typiske eksterne biblioteker, virker de ofte for komplekse til å dekkes i bare noen få funksjoner, men i mange tilfeller kommer mye av kompleksiteten fra å lage infrastrukturen som trengs for biblioteket og alle funksjonene til å støtte det. Men når du bruker Wolfram-språket, er infrastrukturen vanligvis allerede innebygd i pakkene, og det er derfor ikke nødvendig å eksponere alle disse støttefunksjonene i detalj, men bare lage funksjoner for de "øverste" applikasjonsspesifikke funksjonene i biblioteket .
"Økosystem" av kunnskapsbasen
Hvis du har skrevet funksjoner som du bruker regelmessig, send dem til Wolfram Function Repository! Hvis det ikke kommer noe mer ut av dette (språkutvikling), vil det selv da være mye mer praktisk for deg å bruke funksjonene til personlig bruk. Det er imidlertid logisk å anta at hvis du bruker funksjonene regelmessig, vil kanskje andre brukere også finne dem nyttige.
Naturligvis kan du komme i en situasjon hvor du ikke er i stand til - eller ikke ønsker - å dele funksjonene dine eller i tilfelle du får tilgang til private informasjonsressurser. Selv i slike tilfeller kan du ganske enkelt distribuere funksjonene i din egen skykonto, tilgang til dem. (Hvis organisasjonen din har , så vil den snart være vert for sitt eget private funksjonslager, som kan administreres fra organisasjonen din og angi om visninger skal tvinges til å ses av tredjepartsbrukere eller ikke.)
Funksjonene du sender til Wolfram-funksjonsrepositoriet trenger ikke å være perfekte; de må bare være nyttige. Dette er litt som "Feil"-delen i klassisk Unix-dokumentasjon - i "Definisjonsdelen" er det en "Author's Notes"-seksjon hvor du kan beskrive begrensninger, problemer osv. som du allerede vet om funksjonen din. I tillegg, når du sender inn funksjonen din til depotet, kan du legge til innsendingsnotater som vil bli lest av et dedikert team med kuratorer.
Når en funksjon er publisert, har siden alltid to lenker nederst: ""Og"" Hvis du legger ved et notat (f.eks. fortell meg om feil), kan du merke av i boksen som sier at du vil at meldingen og kontaktinformasjonen din skal deles med forfatteren.
Noen ganger vil du bare bruke funksjoner fra Wolfram-funksjonsarkivet, for eksempel innebygde funksjoner, uten å se på koden deres. Men hvis du vil ta en titt på innsiden, er det alltid en Notisblokk-knapp øverst. Klikk på den og du vil få din egen kopi av den originale definisjonsnotatboken som ble sendt til funksjonslageret. Noen ganger kan du bare bruke det som et eksempel for dine behov. Samtidig kan du også utvikle din egen modifikasjon av denne funksjonen. Det kan være lurt å legge ut disse funksjonene du fant fra depotet på datamaskinen din eller i lagringskontoen for bladlussky, kanskje du vil sende dem til funksjonskunnskapsbasen, kanskje som en forbedret, utvidet versjon av den opprinnelige funksjonen.
I fremtiden planlegger vi å støtte Git-stil forking for funksjonslagre, men foreløpig prøver vi å holde det enkelt, og vi har alltid bare én akseptert versjon av hver funksjon innebygd i språket. Oftere enn ikke (med mindre utviklere gir opp å vedlikeholde funksjonene de har utviklet og svarer på brukerinnsendinger), tar den opprinnelige forfatteren av funksjonen kontroll over oppdateringer til den og sender inn nye versjoner, som deretter vurderes, og hvis de består gjennomgangsprosessen , utgitt på språket.
La oss vurdere spørsmålet om hvordan "versjon" av utviklede funksjoner fungerer. Akkurat nå, når du bruker en funksjon fra funksjonslageret, vil dens definisjon bli permanent lagret på datamaskinen din (eller i skykontoen din hvis du bruker skyen). Hvis en ny versjon av en funksjon er tilgjengelig, vil du neste gang du bruker den motta en melding som varsler deg om dette. Og hvis du vil oppdatere funksjonen til en ny versjon, kan du gjøre det ved å bruke kommandoen . («Funksjonsblokken» lagrer faktisk mer versjonsinformasjon, og vi planlegger å gjøre dette mer tilgjengelig for brukerne våre i fremtiden.)
En av de vakre tingene med Wolfram Function Repository er at et hvilket som helst Wolfram Language-program, hvor som helst, kan bruke funksjoner fra det. Hvis et program dukker opp i en notisblokk, er det ofte praktisk å formatere depotfunksjonene som lettleste "funksjonsbinære objekt"-funksjoner (kanskje med et passende versjonssett).
Du kan alltid få tilgang til hvilken som helst funksjon i funksjonslageret ved hjelp av tekst . Og dette er veldig praktisk hvis du skriver kode eller skript direkte for Wolfram Engine, for eksempel med (det bør spesielt bemerkes at funksjonsrepositoriet er fullt kompatibelt med ).
Hvordan virker det?
Inne i funksjonene i Wolfram-depotet er dette mulig ved å bruke nøyaktig det samme baser, som i (datalager, , etc.), som alle andre Wolfram-systemressurser, til syvende og sist basert på funksjon .
Vurdere :
Inne kan du se litt informasjon ved hjelp av funksjonen :
Hvordan fungerer det å sette opp en ressursfunksjon? Den enkleste er en rent lokal sak. Her er et eksempel som tar en funksjon (i dette tilfellet bare en ren funksjon) og definerer den som en ressursfunksjon for en gitt programøkt:
Når du har laget definisjonen, kan du bruke ressursfunksjonen:
Merk at det er et svart ikon i denne funksjonsblokken . Dette betyr at BLOB-funksjonen refererer til ressursfunksjonen i minnet som er definert for gjeldende økt. En ressursfunksjon som er permanent lagret på datamaskinen eller skykontoen din har et grått ikon . Og det er et oransje ikon for en offisiell ressursfunksjon i Wolfram Feature Repository .
Så hva skjer når du bruker Utvid-menyen i Definition Notebook? Først tar den alle definisjonene i notisblokken og skaper en symbolsk fra dem ). (Og hvis du bruker en tekstbasert IDE eller et program, kan du også eksplisitt opprette )
Lokal distribusjon av en funksjon fra et depot på datamaskinen din utføres ved hjelp av kommandoen for et ressursobjekt å lagre det som på filsystemet ditt. Distribusjon til en skykonto gjøres ved å bruke kommandoen for et ressursobjekt, og en offentlig skydistribusjon er . I alle tilfeller også brukt til å registrere ressursfunksjonens navn, så skal jobbe.
Hvis du klikker på Send-knappen for et funksjonslager, hva skjer under det kalt på et ressursobjekt. (Og hvis du bruker et tekstinntastingsgrensesnitt, kan du også ringe direkte.)
Som standard gjøres innsendinger under navnet knyttet til din Wolfram-ID. Men hvis du sender inn en søknad på vegne av et utviklingsteam eller en organisasjon, kan du og bruk det i stedet som navn for å samhandle med synspunktene dine.
Etter at du har sendt inn noen av funksjonene dine til funksjonskunnskapsbasen, vil den stå i kø for gjennomgang. Hvis du mottar kommentarer som svar, vil de vanligvis være i form av en tekstfil med ytterligere "kommentarceller" lagt til. Du kan alltid sjekke status for søknaden din ved å gå til . Men når funksjonen din er godkjent, vil du bli varslet (via e-post) og funksjonen din vil bli lagt ut i Wolfram-funksjonsarkivet.
Noen finesser på jobben
Ved første øyekast kan det virke som om du bare kan ta en definisjonsnotisbok og legge den ordrett inn i et funksjonslager, men det er faktisk ganske mange finesser involvert - og å håndtere dem krever ganske kompleks metaprogrammering, håndtering av symbolsk behandling som koden som definerer funksjonen, og selve Notisblokken er definert. Det meste av dette skjer internt, bak kulissene, men det kan ha noen implikasjoner som er verdt å forstå hvis du skal bidra til funksjonskunnskapsbasen.
Første umiddelbare subtilitet: Når du fyller ut Definition Notebook, kan du ganske enkelt referere til funksjonen din overalt ved å bruke et navn som MyFunction, som ser ut som et vanlig navn for en funksjon i Wolfram-språket, men for dokumentasjon av funksjonslager er dette erstattet er hva brukerne faktisk vil bruke når de jobber med funksjonen.
Den andre subtiliteten: når du oppretter en ressursfunksjon fra Definition Notebook, må alle avhengigheter som er involvert i funksjonsdefinisjonen fanges opp og eksplisitt inkluderes. Men for å sikre at definisjonene forblir modulære, må du sette alt i en unik . (Selvfølgelig, , er i funksjonslageret.)
Vanligvis vil du aldri se spor av koden som brukes til å konfigurere dette navneområdet. Men hvis du av en eller annen grunn kaller et underutført symbol inne i funksjonen din, vil du se at dette symbolet er i funksjonens interne kontekst. Men når du behandler Definition Notepad, er i det minste symbolet som tilsvarer selve funksjonen som en funksjonell BLOB fremfor en rå karakter i den interne konteksten.
Funksjonsrepositoriet er for å definere nye funksjoner. Og disse funksjonene kan ha alternativer. Ofte er disse parametrene (f.eks. eller ) vil kunne brukes til innebygde funksjoner, samt for de som det allerede finnes innebygde symboler for. Men noen ganger kan en ny funksjon kreve nye alternativer. For å opprettholde modularitet, må disse parameterne være symboler definert i en unik intern kontekst (eller noe sånt som hele ressursfunksjoner, det vil si seg selv). For enkelhets skyld lar funksjonsrepositoriet deg definere nye alternativer i strengdefinisjoner. Og for brukerens bekvemmelighet, disse definisjonene (forutsatt at de brukte и ) behandles også slik at ved bruk av funksjoner kan parametere spesifiseres ikke bare som strenger, men også som globale symboler med samme navn.
De fleste funksjoner gjør rett og slett det de skal gjøre hver gang de kalles, men noen funksjoner må initialiseres før de kan kjøres i en bestemt sesjon – og for å løse dette problemet er det en «Initialisering»-del i Definisjonsdelen.
Funksjoner fra et depot kan bruke andre funksjoner som allerede er i depotet; for å sette opp definisjoner for et funksjonslager som inkluderer to (eller flere) funksjoner som refererer til hverandre, må du distribuere dem i programøkten slik at du kan referanse som på dem , så kan du lage kombinasjonene av disse funksjonene du trenger, eksempler (jeg forsto ikke) og legge til en ny funksjon til depotet basert på de som allerede er lagt ut tidligere. (eller allerede eller tidligere – begge ordene er klønete)
Utviklingsutsikter. Hva bør skje når depotet blir virkelig stort?
I dag lanserer vi nettopp Wolfram Feature Repository, men over tid forventer vi at størrelsen og funksjonaliteten kan øke dramatisk, og etter hvert som den vokser i utvikling vil det være ulike problemer som vi allerede forventer kan oppstå.
Det første problemet gjelder funksjonsnavn og deres unikhet. Funksjonsdepotet er utformet på en slik måte at du, i likhet med de innebygde funksjonene i Wolfram-språket, kan referere til en gitt funksjon ganske enkelt ved å spesifisere navnet. Men dette betyr uunngåelig at funksjonsnavn må være globalt unike på tvers av depotet, slik at det for eksempel bare kan være ett .
Dette kan virke som et stort problem i begynnelsen, men det er verdt å innse at det i utgangspunktet er det samme problemet som for ting som internettdomener eller sosiale medier-håndtak. Og faktum er at systemet rett og slett må ha en registrar - og dette er en av rollene som vårt selskap vil utføre for Wolfram-funksjonens kunnskapsbase. (For private versjoner av et arkiv kan deres registrarer være administratorer.) Et internettdomene kan selvfølgelig registreres uten å ha noe på det, men i et funksjonsregister kan et funksjonsnavn kun registreres dersom det er en faktisk definisjon av funksjonen.
En del av vår rolle i å administrere Wolfram-funksjonens kunnskapsbase er å sikre at navnet som er valgt for en funksjon er logisk gitt funksjonens definisjon og at det følger Wolfram Language-navnekonvensjoner. Vi har over 30 års erfaring med å navngi innebygde funksjoner i Wolfram-språket, og vårt team av kuratorer vil også bringe denne erfaringen til funksjonsarkivet. Selvfølgelig er det alltid unntak. For eksempel kan det virke å foretrekke å ha et kort navn for en funksjon, men det er bedre å "forsvare" med et lengre, mer spesifikt navn fordi det er mindre sannsynlig at du møter noen som ønsker å lage et lignende funksjonsnavn i fremtiden .
(Det skal bemerkes her at det å bare legge til en medlemskode for å gjøre funksjoner tvetydig vil ikke ha den tiltenkte effekten. For med mindre du insisterer på å alltid tilordne en tag, må du definere en standardkode for en gitt funksjon, og også tildele forfattertagger , som igjen ville kreve global koordinering.)
Etter hvert som kunnskapsbasen til Wolfram-funksjoner vokser, er et av problemene som sannsynligvis vil oppstå oppdagelsen av funksjoner, som systemet gir (og definisjonsfiler kan inneholde nøkkelord osv.). For innebygde funksjoner i Wolfram-språket er det alle slags kryssreferanser i dokumentasjonen for å hjelpe med å "annonsere" funksjonene. Funksjoner i et funksjonslager kan referere til innebygde funksjoner. Men hva med omvendt? For å gjøre dette, skal vi eksperimentere med forskjellige design for å avsløre depotfunksjoner på dokumentasjonssider for innebygde funksjoner.
For innebygde funksjoner i Wolfram-språket er det et såkalt deteksjonslag levert av , som gir organiserte lister over funksjoner relatert til bestemte områder. Det er alltid vanskelig å balansere man-sider på riktig måte, og etter hvert som Wolfram-språket vokser, må man-sider ofte omorganiseres fullstendig. Det er ganske enkelt å sette funksjoner fra et depot i brede kategorier, og til og med å dele disse kategoriene ned konsekvent, men det er mye mer verdifullt å ha riktig organiserte språkreferansesider. Det er ennå ikke klart hvordan man best kan lage dem for hele funksjonskunnskapsbasen. For eksempel, i funksjonslageret kan hvem som helst legge ut en nettside som inneholder deres "valg" fra depotet:
Wolfram-funksjonsrepositoriet er konfigurert som et vedvarende funksjonsdepot, der enhver funksjon i det alltid vil fungere. Selvfølgelig kan nye versjoner av funksjoner bli tilgjengelige, og vi forventer at noen funksjoner selvfølgelig vil bli foreldet over tid. Funksjonene vil fungere hvis de brukes i programmer, men dokumentasjonssidene deres vil lenke til nye, mer avanserte funksjoner.
Wolfram Feature Repository er utviklet for å hjelpe deg raskt å oppdage nye funksjoner og lære nye måter å bruke Wolfram-språket på. Vi er veldig optimistiske på at noe av det som har blitt utforsket i funksjonsrepositoriet til slutt vil være fornuftig å bli innebygde deler av kjernen Wolfram Language. I løpet av det siste tiåret har vi hatt et lignende sett . Og en av lærdommene fra denne erfaringen er at å oppnå standardene for kvalitet og konsistens som vi fokuserer på i alt innebygd i Wolfram-språket krever mye arbeid, som ofte er vanskeligere enn den første innsatsen for å implementere ideen. Likevel kan en funksjon i funksjonskunnskapsbasen tjene som et veldig nyttig konseptbevis for en fremtidig funksjon som til slutt kan bygges inn i Wolfram-språket.
Det viktigste her er at en funksjon i et funksjonslager er noe som er tilgjengelig for hver bruker å bruke akkurat nå. Det er mulig at en morsmålsfunksjon kan være mye bedre og mer effektiv, men et funksjonslager vil tillate brukere å få tilgang til alle de nye funksjonene med en gang. Og viktigst av alt, dette konseptet lar alle legge til nye funksjoner de ønsker.
Tidligere i Wolfram-språkets historie ville ikke denne ideen ha fungert så bra som den har gjort, men på dette stadiet er det lagt ned så mye innsats i språket, og en så dyp forståelse av språkdesignprinsipper, at det nå virker veldig mulig for et stort fellesskap av brukere å legge til funksjoner som vil opprettholde designkonsistens for å gjøre dem nyttige for et bredt spekter av brukere.
Det er en utrolig ånd av talent(?) i brukerfellesskapet for Wolfram Language. (Selvfølgelig inkluderer dette fellesskapet mange ledende FoU-folk innen en rekke felt.) Jeg håper at Wolfram Feature Repository vil gi en effektiv plattform for å låse opp og spre denne talentånden. Bare sammen kan vi skape noe som betydelig utvider området som Wolfram-språklig databehandlingsparadigmet kan brukes på.
På mer enn 30 år har vi kommet langt med Wolfram-språket. Nå sammen, la oss gå enda lenger. Jeg oppfordrer sterkt alle respekterte brukere av Wolfram-språket rundt om i verden til å bruke det funksjonelle depotet som en plattform for dette, samt det nye programvareprosjektet som Free Wolfram Engine for Developers.
Kilde: www.habr.com