In de jaren tachtig was de makkelijkste manier om een nerdruzie te beginnen, te verkondigen dat je favoriete programmeertaal de beste was. C, Pascal, Lisp, Fortran? Programmeurs spendeerden uren om precies uit te leggen waarom hun manier van een if-then-else clausule maken superieur was aan jouw manier.
Dat was toen. Tegenwoordig is de strijd om syntaxis en structuur grotendeels gestreden omdat de wereld het eens is geworden over een paar eenvoudige standaarden. De verschillen tussen de puntkomma’s, accolades en wat al niet meer in C, Java en JavaScript zijn klein. Interessante debatten over typen en sluiten bestaan nog steeds, maar de meeste zijn betwistbaar omdat automatisering de kloof dicht. Als je er niet van houdt om een datatype op te geven, is de kans groot dat de computer precies kan afleiden wat je bedoelde. Als je baas JavaScript wil, maar jij houdt van Java, zal een cross-compiler al je statisch getypte Java omzetten in geminificeerde JavaScript, klaar om in een browser te draaien. Waarom vechten als de technologie ons steunt?
Heden ten dage zit de interessante actie in frameworks. Toen ik met andere faculteitsleden aan de Johns Hopkins University rond de tafel ging zitten om een nieuwe cursus uit te stippelen, domineerden frameworks het gesprek. Is Angular beter dan Ember? Is Node.js dat allemaal?
We ontwierpen een overzichtscursus die de architectuur zou onderzoeken van de belangrijkste softwarepakketten die de basis vormen van het internet. Dit was het middelpunt van de actie, waardig van een overzichtscursus die de architectuur zou verkennen van de belangrijkste softwarepakketten die het internet vandaag de dag omringen.
In deze zin zijn frameworks de nieuwe programmeertalen. Ze zijn de plaats waar de nieuwste ideeën, filosofieën en praktische aspecten van het moderne coderen worden gevonden. Sommige flakkeren uit, maar vele worden de nieuwe fundamentele bouwstenen van het programmeren. Hier zijn zeven facetten die de frameworktrend aanwakkeren – en die van frameworks de nieuwe favoriete broedplaats voor nerdgevechten maken.
De meeste codering is het aan elkaar rijgen van API’s
Er was een tijd dat het schrijven van software betekende dat je al je kennis van de programmeertaal moest inzetten om het maximale uit de code te halen. Het was zinvol om de complexiteit van pointers, functies en scope onder de knie te krijgen — de kwaliteit van de code hing af van het doen van de juiste dingen. Tegenwoordig handelt automatisering veel van dit af. Als je waardeloze statements in de code laat staan, maak je dan geen zorgen. De compiler verwijdert de dode code. Als je pointers laat bungelen, zal de garbage collector het waarschijnlijk wel uitzoeken.
Daar komt bij dat de praktijk van het coderen nu anders is. De meeste code is nu een lange lijn van API calls. Er is af en toe een herformattering van de gegevens tussen API aanroepen, maar zelfs die taken worden meestal afgehandeld door andere API’s. Een paar gelukkigen mogen slimme, bit-banging, pointer-juggling code schrijven voor de ingewanden van onze machines, maar de meesten van ons werken met de hogere lagen.
Daarom is het belangrijker om te begrijpen hoe een API zich gedraagt en wat hij kan doen. Welke gegevensstructuren accepteert hij? Hoe gedragen de algoritmen zich als de dataset groter wordt? Vragen als deze staan meer centraal bij het programmeren van vandaag dan vragen over syntaxis of taal. Er zijn nu inderdaad een aantal hulpmiddelen die het eenvoudig maken om een routine in een taal vanuit een andere taal aan te roepen. Het is bijvoorbeeld relatief eenvoudig om C bibliotheken te koppelen aan Java code. Het gaat erom dat je de API’s begrijpt.
De schouders van reuzen zijn het waard om op te staan
Stel je voor dat je een discipel bent geworden van Erlang of een andere nieuwe taal. Je besluit dat dit het beste platform is om een stabiele, bugvrije app te schrijven. Dat is een mooi gevoel, maar het kan jaren duren voordat je alle code die beschikbaar is voor Java of PHP hebt herschreven in de taal van je nieuwste keuze. Natuurlijk, je code kan veel beter worden, maar is dat de extra tijd waard?
Frameworks laten ons profiteren van het harde werk van degenen die ons voorgingen. We kunnen het oneens zijn met de architectuur die zij hebben gekozen en we kunnen ruzie maken over implementatiedetails, maar het is efficiënter om onze klachten te smoren en een manier te vinden om met de verschillen te leven. Het is zo veel gemakkelijker om alle goede en slechte dingen van de code te erven via een framework. Als je de macho-route kiest door alles zelf te schrijven in je favoriete nieuwe taal in plaats van in een van de populairdere frameworks, kun je niet zo snel van de crème de la crème van je nieuwe keuze genieten als wanneer je je zou richten naar de frameworkmakers en hun API’s.
Kennis van de architectuur is wat telt, niet de syntax
Wanneer het grootste deel van de codering bestaat uit het aan elkaar rijgen van API-calls, is er niet veel voordeel te halen uit het leren van de eigenaardigheden van de taal. Zeker, je kunt een expert worden in hoe Java statische velden in objecten initialiseert, maar je kunt veel beter uitzoeken hoe je de kracht van Lucene of JavaDB of een andere hoop code kunt benutten. Je zou maanden kunnen spenderen aan het doorgronden van de optimaliseringsroutines van Objective-C compilers, maar het leren van de ins en outs van de nieuwste Apple core library zal je code echt laten gillen. Je komt veel verder met het leren van de pietepeuterige details van het framework dan de syntax van de taal waarop het framework rust.
Het grootste deel van onze code brengt de meeste tijd door in de binnenste lussen van bibliotheken. De details van de taal beheersen kan helpen, maar weten wat er in de bibliotheken gebeurt kan veel opleveren.
Algoritmen domineren
Een programmeertaal leren kan je helpen jongleren met de gegevens die in de variabelen zitten, maar daarmee kom je niet ver. De echte hindernis is om de algoritmes goed te krijgen, en die zijn meestal gedefinieerd en geïmplementeerd door de frameworks.
Veel programmeurs begrijpen dat het gevaarlijk en verspillend is om tijd te besteden aan het herimplementeren van standaard algoritmes en datastructuren. Je kunt het misschien een beetje afstemmen op je eigen behoeften, maar je loopt het risico subtiele fouten te maken. Frameworks zijn door de jaren heen uitvoerig getest. Ze vertegenwoordigen onze collectieve investering in een software-infrastructuur. Er zijn niet veel voorbeelden van wanneer het zinvol is om “van het net af te gaan”, het harde werk van anderen aan de kant te schuiven en met je eigen handen een algoritmische hut te bouwen.
De juiste aanpak is om de frameworks te bestuderen en te leren hoe je ze in je eigen voordeel kunt gebruiken. Als je de verkeerde datastructuur kiest, kun je een lineaire klus veranderen in een klus die een kwadratische functie is van de grootte van de invoer. Dat is een groot probleem als je eenmaal viral gaat.