I 1980'erne var den nemmeste måde at starte en nørdekamp på at forkynde, at dit yndlingsprogrammeringssprog var bedst. C, Pascal, Lisp, Fortran? Programmører tilbragte timer med at forklare nøjagtigt, hvorfor deres særlige måde at skabe en klausul, hvis-så-ellers, var bedre end din måde.
Det var dengang. I dag er kampe, der involverer syntaks og struktur, stort set forbi, fordi verden er gået sammen på nogle få enkle standarder. Forskellene mellem semikolonerne, krøllede parenteser og hvad der ikke er i C, Java og JavaScript er mindre. Interessante debatter om typning og lukning eksisterer stadig, men de fleste er svære, fordi automatisering lukker kløften. Hvis du ikke kan lide at specificere en datatype, er der en god chance for, at computeren kan udlede præcis, hvad du mente. Hvis din chef vil have JavaScript, men du kan lide Java, konverterer en cross-compiler al din statisk typede Java til minificeret JavaScript, klar til at køre i en browser. Hvorfor kæmpe, når teknologien har ryggen?
I dag er den interessante handling i rammer. Da jeg satte mig sammen med andre fakultetsmedlemmer på Johns Hopkins University for at planlægge et nyt kursus, dominerede rammer samtalen. Er Angular bedre end Ember? Er Node.js alt det?
Vi designede et undersøgelseskursus, der skulle undersøge arkitekturen for de vigtigste softwarepakker, der er grundlaget for Internettet. Dette var centrum for handlingen, værdig til et undersøgelseskursus, der ville udforske arkitekturen for de vigtigste softwarepakker, der omgiver nutidens internet.
I denne forstand er rammer de nye programmeringssprog. Det er her, de nyeste ideer, filosofier og praktiske anvendelser af moderne kodning findes. Nogle flammer ud, men mange bliver de nye grundlæggende byggesten til programmering. Her er syv facetter, der fremmer rammetrenden - og gør rammer til det nye yndlingssted for nørdkampe.
Mest kodning strenger sammen API'er
Der var en tid, hvor det at skrive software betød at implementere al din viden om programmeringssprog for at presse mest ud af koden. Det var fornuftigt at mestre pointerne, funktionerne og omfanget - kompleksiteten af koden afhængede af at gøre det rigtige. I disse dage håndterer automatisering meget af dette. Hvis du efterlader værdiløse udsagn i koden, skal du ikke bekymre dig. Compileren fjerner død kode. Hvis du lader pekere hænge, vil skraldespanden sandsynligvis finde ud af det.
Plus, kodningen er anderledes nu. Den fleste kode er nu en lang række API-opkald. Der er lejlighedsvis omformatering af dataene mellem API-opkald, men selv disse job håndteres normalt af andre API'er. Et heldigt par får skrive smart, bit-banging, pointer-jongleringskode til tarmene på vores maskiner, men de fleste af os arbejder med de højere lag. Vi kører simpelthen rør mellem API'er.
På grund af dette er det vigtigere at forstå, hvordan en API opfører sig, og hvad den kan gøre. Hvilke datastrukturer accepterer den? Hvordan opfører algoritmerne sig, når datasættet bliver større? Spørgsmål som disse er mere centrale i nutidens programmering end spørgsmål om syntaks eller sprog. Faktisk er der nu en række værktøjer, der gør det nemt at kalde en rutine på et sprog fra et andet. Det er relativt nemt at linke C-biblioteker til f.eks. Java-kode. At forstå API'erne er det der betyder noget.
Skulderne af giganter er værd at stå på
Forestil dig, at du er blevet en discipel af Erlang eller et andet nyt sprog. Du beslutter, at det giver den bedste platform til at skrive en stabil, bug-fri app. Dette er en god stemning, men det kan tage år for dig at omskrive al den tilgængelige kode til Java eller PHP til dit seneste valgte sprog. Sikker på, din kode kan vise sig at være dramatisk bedre, men er det ekstra tid værd?
Rammer lader os udnytte det hårde arbejde fra dem, der kom foran os. Vi kan ikke lide den arkitektur, de valgte, og vi kan diskutere implementeringsdetaljer, men det er mere effektivt at kvæle vores klager og finde en måde at leve med forskellene på. Det er så meget lettere at arve alt det gode og dårlige ved kodebasen gennem en ramme. At tage macho-ruten ved at skrive alt selv på dit nye yndlingssprog i stedet for en af dens mere populære rammer, giver dig ikke mulighed for at nyde cremen fra dit nye valg så hurtigt som det ville være at udsætte rammeproducenterne og deres API'er.
At kende arkitekturen er det der betyder noget, ikke syntaksen
Når det meste af kodningen strenger sammen API-opkald, er der ikke meget fordel ved at lære sprogets idiosynkrasier. Sikker på, du kan blive ekspert på, hvordan Java initialiserer statiske felter i objekterne, men du ville være meget bedre tjent med at finde ud af, hvordan du kan udnytte kraften i Lucene eller JavaDB eller en anden bunke kode. Du kan tilbringe måneder med at grotte optimeringsrutinerne for Objective-C-kompilatorer, men at lære ind og ud i det nyeste Apple-kernebibliotek vil virkelig få din kode til at skrige. Du får meget mere at lære de krævende detaljer i rammen end syntaksen for det sprog, som rammen hviler på.
Det meste af vores kode tilbringer det meste af sin tid i bibliotekernes indre sløjfer. At få detaljerne i sproget korrekt kan hjælpe, men at vide, hvad der foregår i bibliotekerne, kan betale sig dramatisk.
Algoritmer dominerer
At lære et programmeringssprog kan hjælpe dig med at jonglere med de data, der er gemt i variablerne, men det tager dig kun så langt. Den virkelige forhindring er at få algoritmerne korrekte, og de defineres normalt og implementeres af rammerne.
Mange programmører forstår, at det er farligt og spildende at bruge tid på at implementere standardalgoritmer og datastrukturer. Sikker på, at du muligvis kan indstille det lidt til dine behov, men du risikerer at lave subtile fejl. Rammer er blevet testet bredt gennem årene. De repræsenterer vores kollektive investering i en softwareinfrastruktur. Der er ikke mange eksempler på, hvornår det giver mening at "gå ud af nettet", smide andres hårde arbejde til side og bygge en algoritmisk kabine med dine egne to hænder.
Den rigtige tilgang er at studere rammerne og lære at bruge dem til din bedste fordel. Hvis du vælger den forkerte datastruktur, kan du gøre et lineært job til et, der tager en tid, der er en kvadratisk funktion af inputstørrelsen. Det er et stort besvær, når du bliver viral.
