Programmering

7 grunner til at rammeverk er de nye programmeringsspråkene

På 1980-tallet var den enkleste måten å starte en nerdekamp på å kunngjøre at favorittprogrammeringsspråket ditt var best. C, Pascal, Lisp, Fortran? Programmører brukte timer på å forklare nøyaktig hvorfor deres spesielle måte å lage en if-then-else-klausul var bedre enn din måte.

Det var da. I dag er kamper som involverer syntaks og struktur i stor grad over, fordi verden har gått sammen på noen få enkle standarder. Forskjellene mellom semikolonene, krøllete parentesene og hva som helst i C, Java og JavaScript er små. Interessante debatter om skriving og nedleggelser eksisterer fortsatt, men de fleste er vanskelige fordi automatisering tetter gapet. Hvis du ikke liker å spesifisere en datatype, er det stor sjanse for at datamaskinen vil kunne utlede nøyaktig hva du mente. Hvis sjefen din vil ha JavaScript, men du liker Java, vil en kryss-kompilator konvertere all din statisk typte Java til minifisert JavaScript, klar til å kjøre i en nettleser. Hvorfor kjempe når teknologien har ryggen?

I dag er den interessante handlingen i rammer. Da jeg satte meg ned med andre fakultetsmedlemmer ved Johns Hopkins University for å planlegge et nytt kurs, dominerte rammene samtalen. Er Angular bedre enn Ember? Er Node.js alt det?

Vi designet et undersøkelseskurs som skulle utforske arkitekturen til de viktigste programvarepakkene som er grunnlaget for Internett. Dette var sentrum for handlingen, verdig et undersøkelseskurs som ville utforske arkitekturen til de viktigste programvarepakkene som omgir dagens internett.

I denne forstand er rammeverk de nye programmeringsspråkene. De er der de nyeste ideene, filosofiene og det praktiske ved moderne koding finnes. Noen flammer ut, men mange blir de nye grunnleggende byggesteinene for programmering. Her er syv fasetter som fremmer rammetrenden - og gjør rammer til den nye favorittplassen for nerdkamp.

Mest koding strenger sammen API-er

Det var en tid da å skrive programvare betydde å distribuere all din kunnskap om programmeringsspråket for å presse mest mulig ut av koden. Det var fornuftig å mestre pekere, funksjoner og omfang - kvaliteten på koden var avhengig av å gjøre det rette. I disse dager håndterer automatisering mye av dette. Hvis du legger igjen verdiløse uttalelser i koden, ikke bekymre deg. Kompilatoren fjerner død kode. Hvis du lar pekere dingle, vil trolig søppeloppsamleren finne ut av det.

I tillegg er praksisen med koding annerledes nå. Mest kode er nå en lang rekke API-samtaler. Det er sporadisk omformatering av dataene mellom API-samtaler, men selv disse jobbene blir vanligvis håndtert av andre APIer. En heldig få får skrive smart, bit-banging, peker-sjongleringskode for tarmene til maskinene våre, men de fleste av oss jobber med de høyere lagene. Vi kjører ganske enkelt rør mellom APIer.

På grunn av dette er det viktigere å forstå hvordan en API oppfører seg og hva den kan gjøre. Hvilke datastrukturer godtar den? Hvordan oppfører algoritmene seg når datasettet blir større? Spørsmål som disse er mer sentrale i dagens programmering enn spørsmål om syntaks eller språk. Faktisk er det nå en rekke verktøy som gjør det enkelt å kalle en rutine på ett språk fra et annet. Det er for eksempel relativt enkelt å koble C-biblioteker til Java-kode. Å forstå APIene er det som betyr noe.

Skuldrene til kjemper er verdt å stå på

Tenk deg at du er blitt en disippel av Erlang eller et annet nytt språk. Du bestemmer deg for at den tilbyr den beste plattformen for å skrive en stabil, feilfri app. Dette er en fin følelse, men det kan ta flere år før du omskriver all tilgjengelig kode for Java eller PHP til det siste språket du velger. Visst, koden din kan vise seg å være dramatisk bedre, men er det verdt ekstra tid?

Framework lar oss utnytte det harde arbeidet til de som kom foran oss. Vi liker kanskje ikke arkitekturen de valgte, og vi kan krangle om implementeringsdetaljer, men det er mer effektivt å kvele våre klager og finne en måte å leve med forskjellene. Det er så mye lettere å arve alt godt og vondt i kodebasen gjennom et rammeverk. Å ta macho-ruten ved å skrive alt selv på ditt favoritt nye språk i stedet for en av de mer populære rammene, vil ikke tillate deg å glede deg over kremen av det nye valget ditt så raskt som det ville være å bare henvise til rammeprodusentene og deres APIer.

Å vite arkitekturen er det som betyr noe, ikke syntaksen

Når det meste av kodingen strenger sammen API-anrop, er det ikke mye fordel i å lære språket egenheter. Visst, du kan bli en ekspert på hvordan Java initialiserer statiske felt i objektene, men du vil være mye bedre å finne ut hvordan du kan utnytte kraften til Lucene eller JavaDB eller en annen haug med kode. Du kan tilbringe flere måneder med å ta del i de optimaliserende rutinene til Objective-C-kompilatorer, men å lære detaljene i det nyeste Apple-kjernebiblioteket vil virkelig få koden til å skrike. Du får mye mer å lære de kresne detaljene i rammeverket enn syntaksen til språket som rammeverket hviler på.

Det meste av koden vår tilbringer mesteparten av tiden i bibliotekens indre sløyfer. Å få detaljene i språket riktig kan hjelpe, men å vite hva som skjer i bibliotekene kan lønne seg dramatisk.

Algoritmer dominerer

Å lære et programmeringsspråk kan hjelpe deg med å jonglere med dataene som er stashed i variablene, men det tar deg bare så langt. Den virkelige hindringen er å få algoritmene riktige, og de blir vanligvis definert og implementert av rammene.

Mange programmerere forstår at det er farlig og bortkastet å bruke tid på å implementere standardalgoritmer og datastrukturer. Visst, du kan kanskje stille den litt etter dine behov, men du risikerer å gjøre subtile feil. Rammeverk har blitt testet mye gjennom årene. De representerer vår kollektive investering i en programvareinfrastruktur. Det er ikke mange eksempler på når det er fornuftig å "gå ut av nettet", kaste andres harde arbeid til side og bygge en algoritmisk hytte med dine egne to hender.

Den riktige tilnærmingen er å studere rammene og lære å bruke dem til din beste fordel. Hvis du velger feil datastruktur, kan du gjøre en lineær jobb til en som tar en tid som er en kvadratisk funksjon av inngangsstørrelsen. Det er et stort problem når du blir viral.

$config[zx-auto] not found$config[zx-overlay] not found