Machines kennen geen Engels
Toen ik voor het eerst de C-taal op school leerde, was er iets dat ik niet het meest begreep. ‘Waarom wordt mijn code niet meteen uitgevoerd, maar moet deze het vervelende proces van bouwen en compileren doorlopen?’
Python start meteen als je code schrijft en op Enter drukt, maar Java en C vereisen tijdrovende stappen. Toen ik een student was, dacht ik gewoon: ‘Elke taal heeft een andere grammatica.’ Toen je op de toets verscheen, hoefde je alleen maar te antwoorden: ‘C is een gecompileerde taal, Python is een geïnterpreteerde taal’.
Toen ik echter met back-endservers werkte die in de praktijk grote hoeveelheden verkeer verwerken, realiseerde ik me dat dit simpele verschil een enorme barrière vormde die de prestaties en implementatiesnelheid van het systeem bepaalde. De elegante code die ik schreef was in feite gewoon een onbekende vreemde taal voor de onwetende en gewetensvolle werker, de CPU.
Wat is ‘Build’ in vredesnaam?
Wat is een build precies? Hoe verschilt dit van simpelweg “opslaan”?
De broncode die we hebben geschreven (.java, .c) is eigenlijk slechts een tekstbestand. Het is een ‘tekst’ die zelfs gelezen kan worden als deze met kladblok wordt geopend. Computers (CPU’s) kunnen echter niet lezen. Je kunt alleen weten of er elektriciteit stroomt (1) of niet (0).
Build is een uitgebreid pakketproces dat het ‘tekstbestand’ dat we hebben geschreven, omzet in een ‘uitvoerbaar bestand (.exe, .class, .jar) dat door een computer kan worden uitgevoerd.
Met andere woorden: als de broncode een ‘kookrecept (papier)’ is, is build het proces van het bijsnijden en braden van de ingrediënten volgens het recept en het serveren van een ‘afgemaakt gerecht (voedsel)’. Hoe vaak je het recept (code) ook wijzigt, als je het niet opnieuw kookt (bouwt), blijft het koude eten dat je gisteren hebt gemaakt op tafel staan (server).
Werkinstructies voor digitaal distributiecentrum
Om dit complexe proces te begrijpen, vergelijkt u de binnenkant van een computer met een gigantisch digitaal logistiek centrum.
Hier is de CPU een werker die ongelooflijk snel is, maar geen flexibiliteit kent. Deze medewerker kan alleen werkinstructies lezen die machinetaal (0 en 1) worden genoemd.
Het schrijven van code in Java of Python is het proces van het creëren van een ‘werkhandleiding’ om aan werknemers te geven. Maar het probleem is dat we deze handleiding in het Engels (programmeertaal) schrijven. De werknemer kent geen Engels. We hebben dus vertalers nodig. Het lot van een taal hangt af van deze vertaalmethode.
1. Compiler: Professionele vertaler die vooraf vertaalt
2. Tolk: Realtime simultaantolk
[Codeverificatie] Het blote gezicht van machinetaal verifiëren
Ik kan het niet echt voelen door het alleen maar te horen. Laten we visueel controleren of Python echt regel voor regel vertaalt en hoe de code die de machine ziet eruit ziet.
Python heeft een module genaamd dis (Disassembler). Hiermee kun je zien welke instructies intern worden opgesplitst in Python-code wanneer deze wordt uitgevoerd.
import dis
def my_function():
a = 10
b = 20
print(a + b)
# Controleer naar welke machinecode (bytecode) Python-code wordt omgezet
print("--- Python Bytecode Verification ---")
dis.dis(my_function)
Wanneer u deze code uitvoert, worden de volgende buitenaardse talen uitgevoerd.
5 0 LOAD_CONST 1 (10)
2 STORE_FAST 0 (a)
6 4 LOAD_CONST 2 (20)
6 STORE_FAST 1 (b)
7 8 LOAD_GLOBAL 0 (print)
10 LOAD_FAST 0 (a)
12 LOAD_FAST 1 (b)
14 BINARY_ADD
16 CALL_FUNCTION 1
18 POP_TOP
20 LOAD_CONST 0 (None)
22 RETURN_VALUE
Analyse:
Aan de andere kant wordt de C-taal, wanneer deze wordt gecompileerd, direct vertaald in de daadwerkelijke CPU-assembleertaal, zoals MOV EAX, 10 (zet 10 in het EAX-register). Omdat er geen middenmanagers zijn, zit er niets anders op dan snel te zijn.
Afweging in de praktijk: welke moet je kiezen?
Toen ik een student was, was het het beste om me op mijn gemak te voelen. In plaats van de C-taal, die compilatiefouten bevat, gaf ik de voorkeur aan Python of JavaScript, die gemakkelijk kunnen worden geschreven en uitgevoerd. In de praktijk moet er echter een felle afweging worden gemaakt tussen stabiliteit en productiviteit.
1. Angst voor runtimefouten (zwakte van de tolk)Het meest angstaanjagende bij het bouwen van een server met Python is dat de server om 3 uur ’s nachts stopt vanwege een enkele typefout. De tolk is pas op de hoogte van de fout als deze wordt uitgevoerd (het punt waarop de code wordt uitgevoerd). Aan de andere kant vraagt Java (gecompileerde taal): “Ik heb hier een typefout gemaakt?” bij het bouwen van code. En hij vertelt het mij. Deze nauwkeurigheid bij het opsporen van fouten vóór implementatie wordt een redder in grootschalige projecten.
2. Saaie bouwtijd (zwakte van de compiler) Aan de andere kant, als een Java-project groeit, kan het enkele minuten duren om een enkele regel code aan te passen en te controleren (Gradle Build…). Dit is de reden waarom Python overweldigend wordt gebruikt in de vroege stadia van startups, waar snelle aanpassingen en implementaties van cruciaal belang zijn, of bij taken die onmiddellijke resultaten vereisen, zoals data-analyse.
Concluderend: Theorie wordt een wapen
We weten nu dat het ‘build and compile’-proces en de manier waarop code wordt vertaald van taal tot taal varieert. In theorie zou het kiezen van de beste taal, afhankelijk van de aard van uw project, het juiste antwoord zijn.
Maar de realiteit was niet zo vriendelijk. Het bedrijf waar ik bij kwam had al een vaste technologie, en hoewel ik als Java-ontwikkelaar aan de slag ging, moest ik in aanraking komen met Python, JavaScript en zelfs Android XML.
Paradoxaal genoeg waren het deze ‘basistheorieën’ die ik vandaag heb geleerd wat mij heeft gered van dit verwarrende veld van ‘allesetende ontwikkeling’. Dit komt omdat, hoewel de schil van de taal anders is, de principes die erin werken hetzelfde zijn.
De volgende keer zal ik het hebben over mijn praktische ervaring over hoe ik ‘diep in één taal (Java) ben gedoken om andere talen te targeten’ en waarom de basis belangrijk is om te voorkomen dat ik een slaaf van het raamwerk word.