Overleg:Compiler

De tekst doet denken dat de een Class bestand een executable is, terwijl dit niet zo is. GCC staat dacht ik voor voor GNU C Compiler en (dacht ik) enkel C compileren. g++ kan C++ compileren dacht ik. Wilinckx 16 jul 2003 19:59 (CEST)

Vertaalfunctie??

De zin:

Een compiler is feitelijk de implementatie op een computer van een vertaalfunctie in wiskundige zin; een functie die woorden uit de formele invoertaal afbeeldt op woorden uit de formele uitvoertaal.

lijkt me niet correct. Soieso weet ik niet wat een "vertaalfnctie in wiskundige zin" is, maar het is zeker niet zo dat een compiler een afbeelding is van een verzameling woorden in een andere verzameling woorden.Nijdam 30 sep 2005 22:43 (CEST)

Zekers wel, als je een compiler in een functionele programmeertaal zou schrijven, dan zou je de uitvoer van de compiler als functie van de invoer gedefinieerd hebben. En het is niet louter theoretisch; er zijn daadwerkelijk compilers in functionele programmeertalen geschreven.

In wiskundige zin klopt het ook; de definitie zegt dat een functie een domein op een bereik afbeeld; de verzameling van invoerprogramma's is het domein, de verzameling van uitvoerprogramma' het bereik. Danielm 30 sep 2005 23:09 (CEST)

Er zijn vele input symbolen en vele outputsymbolen. Bovendien is een compiler toestands-georienteerd (statefull), wat een wiskundige functie niet is. Ik vind niet dat de vermelding op deze manier zinvol is.Kleuske 1 okt 2005 16:01 (CEST)

Ik denk dat de betekenis van een compiler meer is dan de afbeelding die de verzameling van alle correcte programma's in de ene taal afbeeldt op de verzameling van (alle correcte?) programma's in een andere taal. Bovendien vind ik het vergezocht de prograama's op te vatten als woorden in zo'n formele taal. Ik heb het gevoel dat hier tamelijk kunstmatig gepoogd wordt het wiskundigge begrip "afbeelding" er bij te slepen. Daarnaast bljf ik nog problemen hebben met de term "wikundige vertaalfunctie"; de term "vertaalfunctie" bestaat als zodanig niet in de wiskunde. Dat de een de afbeelding ziet als het toevoegen van hele programma's in verschillende talen aan elkaar en een ander van het afbeelden van expressie's op elkaar spreekt al boekdelen. Dat het op een bepaald abstract niveau zou kloppen geloof ik absoluut niet, en ik kan een expressie ook niet zien als een verzameling woorden.Nijdam 1 okt 2005 16:04 (CEST)

(Bewerkingsconflict, gelijktijdig met Danielm geschreven) Er is sprake van twee formele talen, en van een vertaalslag (afbeelding) van expressies uit de ene formele taal in expressies in de andere. Het woord woord is misschien wat minder geschikt dan het woord expressie hier, maar op een bepaald abstract niveau klopt het toch wel, lijkt me, als je een expressie ziet als een verzameling woorden.

Flyingbird 30 sep 2005 23:14 (CEST)

Met deze definitie veeg je een aantal belangrijke taken van de compiler onder water: toetsen van correctheid, bijvoorbeeld, uitvoeren van constant-expressies, optimalisatie, etc. Ik weet niet wat het duidelijk moet maken.Kleuske 1 okt 2005 16:01 (CEST)

Dat zijn taken die ook door de compiler worden gedaan, ja. Voeg het vooral toe, als je vindt dat het in de intro van het artikel thuishoort! De vertaalfunctie is m.i. het hart van de compiler. Flyingbird 1 okt 2005 19:32 (CEST)

als je zegt dat een compiler een veredelde assembler is dan is er lijkt me wel sprake van een vertaler. Aleichem 1 okt 2005 16:11 (CEST)

Opmerkingen op nieuwe versie

@Colitem: Ik heb een paar opmerkingen jouw nieuwe versie van dit artikel.

1. Om maar bij het goede te beginnen: Die nieuwe paragraaf Onstaansgeschiedenis vind ik interessant en een goede toevoeging.
2. Bronnen. Op mijn overlegpagina beloofde je "zeer toegankelijke gewichtige bronnen", maar wat ik zie is:
   • Twee keer een glossary van Lenovo waarin pareltjes te vinden zijn als "When compiling source code into executable instructions, common file extensions such as EXE or DLL (Double Linked List [sic]) will be produced [...]. For example, applications written using C++ will produce an EXE file type while C# builds produce DLL files instead.", die niet bepaald een positieve indruk van de expertise van de schrijver achterlaten.
   • Een anderhalf uur durende Youtube-lezing. Zal vast iemand zijn die weet waar hij over praat, maar ik ga geen anderhalf uur zoeken naar de beweringen die in de tekst gebruikt worden.
   • Productpagina's waar bedrijven hun eigen producten beschrijven en aanprijzen.
   • Veel nieuwssites (i.p.v. technologiesites), waaronder Tweakers.net, een site die ik ook niet als gezaghebbend op het gebied van compilers zou kwalificeren, en een krantenartikel achter een betaalmuur.
   • Overigens, die "AI Memo 39 - The new compiler" die jij op 2008 dateert, werd blijkens de laatste pagina reeds in 1995 gedigitaliseerd. Er staat verder geen datum op, maar ik neem aan dat het in ieder geval ouder is dan dat boek uit 1962 van dezelfde auteurs over hetzelfde onderwerp.
3. Definitie. In de eerste zin wordt een compiler als volgt gedefinieerd: "Een compiler [...] is een computerprogramma dat voor mensen leesbare broncode vertaalt naar uitvoerbare instructies in machinetaal." Twintig jaar geleden zou ik met deze definitie zondermeer tevreden zijn (voor een inleidende definitie, in ieder geval), maar tegenwoordig zouden veel dingen die in het dagelijks leven "compiler" worden genoemd buiten de boot vallen: alles wat bijvoorbeeld naar Javascript of Javascript+HTML of bytecode compileert, dus de Typescript-compiler, de Angular-compiler, de Java- en C#-compilers, allemaal geen compilers volgens deze definitie.
4. Verder heel veel fouten en verkeerd begrepen bronnen. Bijvoorbeeld:
   • Taalfouten, taalfouten, taalfouten, taalfouten...
   • De compiler vindt syntaxfouten, niet een debugger of een linter. Een linter analyseert de code om runtime-fouten (niet syntaxfouten) te proberen te vinden en een debugger wordt gebruikt om een (reeds gecompileerd) programma stap voor stap uit te voeren om zo achter de oorzaak van fouten te komen.
   • Exception handling heeft niks met compilefouten maar met runtime-fouten te maken, en vaak zelfs met runtime-fouten die geen bugs zijn, zoals foute gebruikersinvoer, corrupte bestanten, uitvallende internetverbindingen, enz.
   • Die Fortran-compiler van Intel is een C, C++ en Fortran-compiler. En bovendien gebruikt hij geen kunstmatige intelligentie en de bron die je erbij vemeldt beweert dat ook niet.
   • Een programmeertaal en een compiler zijn weliswaar niet hetzelfde, en in principe zou het zo kunnen zijn dat voor een programmeertaal zowel een compiler als een interpreter bestaat, maar in de praktijk worden programmeertalen ontwikkeld om ofwel gecompileerd ofwel geinterpreteerd te worden. De zin "Beide werken het efficiëntst met programmeertalen zoals C, C++ en Java." (onder het kopje Voor- en nadelen) snap ik dus niet, want C, C++ en Java zijn nu juist programmeertalen die in de praktijk alleen maar gecompileerd worden.
   • Ik heb geen flauw idee wat je met die "diverse toepassingen" wilt. De bron is dat anderhalf uur durende YouTube-filmpje dat ik niet ga bekijken, dus wat die Gábor Horváth wel beweerd heeft weet ik niet, maar wie "cascading style sheets", "configuratiebestanden" en "extensible markup language" (a.k.a. XML) in een lijst toepassingen van compilers opneemt, die moet ergens iets niet begrepen en een uitspraak uit zijn context gerukt hebben. Nu kan ik heel veel redenen bij elkaar fantaseren wat al die dingen met compilers te maken zouden kunnen hebben, maar geen daarvan verklaart waarom dan in de volgende zin JavaScript genoemd wordt.

Hoopje (overleg) 24 feb 2024 13:50 (CET)

Over "AI Memo 39 - The new compiler" => deze bron komt vanuit de Engelse Wikipedia. Dat zal waarschijnlijk een soort certificaat zijn dat officieel bewijst dat zij de eerste waren. Oorspronkelijk kwam het door een gepubliceerde memo over de stelling van The Binary Tree. Dit zou hebben bijgedragen om dat te bekomen. Waarop ze ook erkend worden aan de software te hebben meegewerkt.

De introtekst: Veel verschil is er niet. Javascript wordt met een ingebouwde interpreter uitgevoerd. Het proces daarvoor is enkel met een compiler. De modules, componenten en TypeScript in Angular is ook een hogere programmeertaal. Een compilatie naar Javascript is eigenlijk machinetaal omdat dit rechtstreeks geïnterpreteerd kan worden door een browser. En dit is niet dezelfde output als je dat handmatig zou coderen.

"Exception Handling" heeft maar één taak: het programma beëindigen als er iets fout gaat. Een programmeur kan dit opvangen om zo het programma meer onder controle te krijgen. Dat wordt evenzeer gebruikt in de broncode van een compiler. Om alle fouten compact te vergaren is dat de enige mogelijkheid in een programmeersysteem.

"Exception handling" is ook NIET hetzelfde als een Exception! Exeption is het product van een Exception handling. Exception handling betekent de management ervan!

Een linter detecteert wel degelijk syntaxfouten en programmeerfouten. Probeer maar eens te schrijven => stringt name = "colitem". De linter zal "stringt" markeren omdat deze programmeerinstructie een fout bevat. Een linter is een tool voor de IDE. Dat is ABSOLUUT niet at runtime.

Je zegt: "Een linter analyseert de code om runtime-fouten te proberen te vinden"? Dat kan niet! Een runtimefout (crasht) treedt op wanneer bijvoorbeeld een array out of range gaat. Zijn er maar 5 elementen aanwezig in een array, maar je vraagt een 6de op, dan krijg je een runtimefout (als je dat niet eerst laat checken). Dit kan GEEN enkele tool detecteren omdat het systeem niet weet dat iemand dat gaat doen in toekomst. Dan moet dat met een unittest gebeuren.

Bij een debugger moet er ook eerst gecompileerd worden. Deze kan tijdens het opbouwen ook cyntaxfouten vinden. Alles moet gecompileerd worden en dat vertaalt zich in "diverse toepassingen". Enkele toepassingen waar dat nodig is. Bv.: zonder compiler kan men niet eens Windows besturingssysteem installeren.

Ik geef toe "Ontwikkelingsomgeving" staat wat veralgemeend. Maar in detail weergeven daar is een artikel voor. Een linter en een debugger zijn allebei foutopsporingstools. Linter = Niet At runtime. Debugger = At runtime.

Je haalt het begrip debugger en debuggen door elkaar. De bekendste debugger is een internetbrowser (inspecteren => debugger: daar staan alle files om uit te voeren via interpreter). Een debugger is een tool dat geschreven broncode realiseert en uitvoert in een testomgeving. Zodoende dat de broncode kan gecheckt worden op bugs alvorens te deployen. Tijdens het draaien van de debugger kunnen er zich runtimefouten voordoen. Dat wil zeggen, de compiler begreep de code maar de debugger (of server) kan het niet uitvoeren. Dan is dat louter de schuld van de programmeur. Een aanpassing dringt zich dan op! Debuggen daarentegen is het volgen van de code via logging.

Die opmerking over "glossary van Lenovo", wat wilt ge daar eigenlijk mee bereiken? Dat uw mening meer doorweegt dan een computer gigant?

Je schreef: "De zin "Beide werken het efficiëntst met programmeertalen zoals C, C++ en Java." (onder het kopje Voor- en nadelen) snap ik dus niet, want C, C++ en Java zijn nu juist programmeertalen die in de praktijk alleen maar gecompileerd worden." => ik zal dat zeker eens bekijken. Op het eerste zicht omdat deze de beste (lagere) programmeertalen zijn qua performance.

Ik versta uw ongenoegen eigenlijk niet. Als er iemand alles door elkaar haalt, dan ben jij dat wel. Je begint ook van "Een programmeertaal en een compiler zijn weliswaar niet hetzelfde...". Tja, waarom jij dat aanhaalt is mij echt een raadsel. Er staat in mijn introtekst "Een veelgebruikte programmeertaal voor het ontwikkelen van een compiler is bijvoorbeeld C++". Er staat daar letterlijk dat de ene met de andere wordt gemaakt. Dan zal het inderdaad zeker niet hetzelfde zijn.

Ik zal de bronnen en alles evalueren en ook alles meenemen. Maar vind uw argumenten globaal echt wel aan het haar getrokken en niet onderbouwd. Colitem (overleg) 25 feb 2024 01:52 (CET)

1. Colitem: "Over "AI Memo 39 - The new compiler" => deze bron komt vanuit de Engelse Wikipedia. ... Waarop ze ook erkend worden aan de software te hebben meegewerkt."
   Die AI Memo 39 wordt op de Engelse Wikipedia helemaal niet gebruikt. (Ook niet in de recente geschiedenis.) Het is gewoon een interne memo in de afdeling waar die twee werkzaam waren om hun nieuwe LISP-compiler te beschrijven. Wat dat met certificaten en "The Binary Tree" te maken heeft, begrijp ik niet.
2. Colitem: "De introtekst: Veel verschil is er niet. ... En dit is niet dezelfde output als je dat handmatig zou coderen."
   JavaScript is niet hetzelfde als machinetaal. Hele volkstammen hebben zonder hulp gigantische applicaties direct in JavaScript gemaakt. Het is dus een voor mensen leesbare, hogere programmeertaal. Als je wilt zeggen dat een compiler van de ene naar de andere hogere programmeertaal vertaalt (waarvan de tweede een ietsje lager niveau heeft dan de eerste), waarom doe je dat dan niet gewoon zonder te proberen bestaande woorden een andere betekenis te geven?
3. Colitem: "Exception Handling" heeft maar één taak:...Exception handling betekent de management ervan!"
   Ja, een compiler kan ook exception handling gebruiken. Het is tenslotte ook gewoon een applicatie die invoer naar uitvoer omzet. Compilers gebruiken misschien ook functies, klassen, methoden, variabelen, lussen, if-then-else, ... Dat betekent niet dat dat allemaal relevant om hier in het artikel te noemen.
4. Colitem: "Een linter detecteert wel degelijk syntaxfouten en programmeerfouten."
   Als je een IDE gebruikt is inderdaad niet meer zo duidelijk welke tool welke foutmeldingen genereert, omdat het allemaal dezelfde tool is. Maar jouw bron (ik herhaal: JOUW BRON), die productpagina van Microsoft (die je dus blijkbaar niet gelezen of niet begrepen hebt), geeft een screenshot met de fouten die door die linter ontdekt worden ("arithmetic overflow", "accidental copy", ...). Dat zijn allemaal runtime-fouten, geen compile-time fouten.
   Colitem: "Dat is ABSOLUUT niet at runtime."
   Een linter geeft die fouten inderdaad aan tijdens het ontwikkelen, niet tijden het uitvoeren van het programma. Dat heet statische analyse (link): proberen mogelijke run-timefouten te vinden voordat het programma daadwerkelijk wordt uitgevoerd. Er bestaan zeer veel programmeertools die statische analyse uitvoeren, voor zeer veel verschillende programmeertalen. Dat is niks nieuws en niks bijzonders meer, dus het verbaast me dat dit jou als zelfverklaarde compiler-expert uitgelegd moet worden.
5. Colitem: "Bij een debugger moet er ook eerst gecompileerd worden."
   Inderdaad, die debugger gebruikt het resultaat van de compiler. Als er syntaxfouten in de code zitten, dan faalt de compiler al en dan begint die debugger niet eens met zijn werk. Kortom, het is gewoon onzin dat een debugger syntaxfouten vindt.
6. Colitem: "De bekendste debugger is een internetbrowser".
   Ik zou eerder zeggen dat die internetbrowser een debugger bevat en niet dat die internetbrowser een debugger is. Maar okee, in ieder geval gaat het hier over compilers en niet over 1) JavaScript en 2) debuggers die JavaScript-scripts kunnen debuggen.
7. Colitem: "Je haalt het begrip debugger en debuggen door elkaar. [...] Debuggen daarentegen is het volgen van de code via logging."
   Nee, debuggen is heel algemeen fouten opsporen en fixen. Dat kan met logging, maar het kan ook door een debugger te gebruiken. En ik heb geen debugger nodig om een programma uit te voeren alvorens het te deployen. Dat kan ik gewoon doen door het programma uit te voeren voordat ik het gedeployed heb. Die debugger gebruik ik om het programma te onderbreken, stap-voor-stap te doorlopen, en de inhoud van de variabelen / het geheugen te inspecteren, om zo na te gaan wat er precies fout gaat. Jij bent hier degene die dingen door elkaar haalt.
8. Colitem: "Die opmerking over "glossary van Lenovo", wat wilt ge daar eigenlijk mee bereiken? Dat uw mening meer doorweegt dan een computer gigant?"
   Ik had in mijn vorige bijdrage een stukje uit die Lenovo-glossary gekopieerd. Dat jij niet begrijpt waarom die tekst zo grappig was, is veelzeggend. Dat je blijkbaar vindt dat die tekst nu geen onzin meer is omdat het op de website van een computergigant staat, is beangstigend. Maar goed, omdat je het blijkbaar zelf niet zag: 1) DLL staat niet voor double linked list, 2) met C++ kan ik ook DLLs maken, en 3) met C# kan ik ook EXEs maken, en 4) EXE en DLL zijn sowieso Windows-only.
9. Colitem: "Ik versta uw ongenoegen eigenlijk niet. ... Dan zal het inderdaad zeker niet hetzelfde zijn."
   Dat een programmeertaal en compiler niet hetzelfde zijn, schreef ik omdat je in je eerste bijdrage op mijn overlegpagina mij (ten onrechte) leek te verwijten dat ik die twee door elkaar haal. Ik begrijp overigens ook niet waarom je het de hele tijd hebt over de programmeertaal waarin die compiler geschreven is, terwijl het belangrijkste nu juist de programmeertaal is die de compiler compileert. Het is tegenwoordig een trend dat die twee hetzelfde zijn (Rust-compiler geschreven in Rust, Java-compiler geschreven in Java, TypeScript-compiler geschreven in TypeScript), maar dat is zeker niet noodzakelijk. Zo is de GNU Fortran compiler in C++ geschreven. Die GNU Fortran compiler is in de eerste plaats een Fortran-compiler, niet een in C++ geschreven compiler.
10. In het algemeen vind ik, dat wie een artikel op Wikipedia (her)schrijft, een zekere ervaring moet hebben in het beschreven onderwerp. Dat is niet alleen nodig vanwege de kennis die je zelf hebt, maar ook omdat je die ervaring nodig hebt om bronnen te begrijpen, juist te interpreteren, en de kwaliteit ervan te beoordelen. En sorry dat ik het moet zeggen, maar uit de dingen die je in het artikel schrijft, maar ook uit jouw overlegbijdragen, blijkt wat mij betreft dat jij die ervaring niet genoeg bezit. Dat is niet erg, het is tenslotte een gespecialiseerd onderwerp. Maar schrijf dan over iets anders.

Hoopje (overleg) 25 feb 2024 10:47 (CET)

Je loopt hoog op met jezelf. Je neemt een zeer hautaine houding aan. Dat is niet de bedoeling van Wikipedia. Ik heb twee hogeschool diploma's in programmeren en wens een deftige discussie hierover. En ik heb dat nog nooit aangegeven omdat dit NIET het CONCEPT is van Wikipedia. Wat jij stelt is niet wat in de richtlijnen staan van Wikipedia. Iedereen heeft evenveel recht om iets aan te passen. Het is nu eenmaal gekend onder programmeurs dat men niet gauw eens zijn met elkaar, maar die laatste blok is niet de uitweg die ik wil bewandelen. Er moet enige respect zijn. Als je je aangevallen voelde verontschuldig ik mij bij deze, want we zijn met twee. Die geschiedenis gaat over self-compiler: de bron is en:Self-hosting_(compilers). The Binary Tree was belangrijk. Dat een node steeds uit nul of twee bestaat. Dat zorgt immers altijd voor een uitweg. Dus 1 kan niet tot een beslissing leiden. Dat was de memo. In deze heeft grote gevolgen gehad in het programmeren. (Dat komt van een live conference, en staat daardoor ook niet vermeld). Dat een compiler in bv. C++ is geschreven, is een belangrijk iets. Want daar komt die bootstrappen (wat een proces is) bij kijken. Het enige wat ik wou is alles tot mij nemen en dan het artikel aanscherpen om toch zoveel mogelijk op één lijn te komen. Dus ik doe niet meer mee aan deze discussie maar zal toch jouw punten mee laten wegen om dat op één lijn te krijgen. Dit kan bijvoorbeeld door wat algemener te zijn met mindere technische aspecten. Want het zijn deze aspecten die een struikelblok vormen hier. Hier en daar ook wat meer details om beter te kaderen. Een programmeur is vooral opgeleid om oplossingen naar vore te schuiven en niet andere te kleineren. Colitem (overleg) 25 feb 2024 16:56 (CET)

Het enige wat ik gedaan heb, is jouw fouten op te noemen. Dat kan je onaardig of "hautain" van mij vinden, maar we zitten hier niet in een theekransje, we zijn een encyclopedie aan het schrijven. Dan is het hopelijk toegestaan mensen op hun fouten aan te spreken. Ik verontschuldig mij voor die een of twee sarcastische opmerkingen die er tussen staan, maar nadrukkelijk niet ervoor een lijstje van jouw fouten gemaakt te hebben.

Ik heb ook niet het idee heel onaardig tegen je geweest te zijn. Mijn muis bewoog zich dit weekend meerdere malen naar de "ongedaan maken"-knop, maar uit respect voor het werk dat je in het artikel gestoken hebt heb ik tot nu toe nog niet erop geklikt, om jou de kans te geven op mijn opmerkingen te reageren en zelf je fouten te verbeteren. Jammer dat je zegt niet meer mee te doen aan deze discussie, want dit is een samenwerkingsproject en bij samenwerking hoort overleg. Zonder overleg zal ik jouw fouten dus gewoon rücksichtslos terug moeten draaien of verwijderen. Hoopje (overleg) 26 feb 2024 07:44 (CET)

Ik heb geen probleem als je iets wijzigt of verwijdert. T is van en voor iedereen. Als gij vindt dat dit daar niet thuishoort pas het aan of verwijder het gewoon. Maar zo een tralala in de overlegpagina, alsof je mij gewoon in een slecht daglicht wil zetten omdat ik dat heb aangepast. Dat gebeurt vaak bij mensen die iets bewaken; al meermaals ervaren. Maar sommige zaken waren echt niet goed. Uw aanpak was allerminst overleggend te noemen. Bovendien was er geen enkele referentie aanwezig enkel een technische informatie (die door zijn technische aard de compiler-definitie anders benadert). Je hebt op een bepaald moment over een linter zitten discuteren, terwijl daarnaast een referentie staat naar de software gigant Microsoft. Daar wordt een kleine animatie afgespeeld die toont wat het juist doet. (Maar goed, ik accepteer uw kijk op de zaak; maar wikipedia volgt referenties). En niets zegt dat ik zonder fouten MOET schrijven. Ik, jij en iedereen kunnen en mogen fouten maken en iets verkeerd opvatten. De volgende zal het wel corrigeren.

Maar goed ik accepteer ook jouw excuses. Ik denk dat we bij deze dat beter achter ons laten en richten op de toekomst. Er zou nog een onderwerp (kopje) moeten komen met de veelzijdigheid van de compiler. En dat is uw verhaal, je spoorde daar telkens op aan. Geschreven in C++ maar compileert C++, Maar C++ compileert ook andere, ook andere taal die gebruik maken van C++ moet een compiler of assembler hebben, om te starten met bootstrappen, maar ook kan een programmeertaal eigen definitieve compiler hebben, etc. Dat is nuttig om in te voegen. Maar lopen alvorens te stappen had ook geen zin. Dit zou nu mijn volgende stap zijn die ik aan jou overlaat. Denk ook eens na om toepassingen te geven die volgens jou wel relevant zijn. Zodat mensen zich daar een idee kunnen bij vormen in de praktijk.

Om de goede vrede te bewaren heb ik besloten Bootstrappen (compilers) niet aan te passen. Van mij mag je die oude titel terugzetten. De reden is, ik heb geen zin om terug de huid vol gescholden te krijgen. Want de tekst die je hebt verwijderd bij voor -en nadelen heeft daar alles mee te maken. Net omdat dit een compilerende taal is, is dat de beste kandidaat om zichzelf te compileren en te hosten. Dat is het kip en ei probleem. Een kip kan zichzelf niet maken om daarna een ei te leggen. Dat is wat een compiler wel kan, maar er zijn natuurlijk voorwaarden aan verbonden. Dat is hetzelfde als: "Om iemand te leren rijden moet je eerst zelf kunnen rijden". Daarom heb ik beslist dat niet aan te passen want je ziet me toch maar als iemand die geen verstand van zaken heeft. Dan ga ik mezelf dat ook niet aandoen terug al die bagger over mij heen te krijgen. Een soort zelfbescherming. Ik laat dat aan u over om dat op punt te stellen. Colitem (overleg) 26 feb 2024 14:33 (CET)

Introtekst werd terug gemanipuleerd naar een versie wat niet compileren is. Formele taal naar formele taal is TRANSPILEREN! Dat was het grootste probleem met dit artikel. Ik heb hiervoor 14 bronnen ingevoegd om u van het tegendeel te bewijzen en je hebt die bronnen merendeels genegeerd. Meer nog, je hebt dragonboek gebruikt om iets te staven wat in het boek helemaal niet gezegd wordt (Figuur 1.1 tot 1.4 legt uit wat target language juist is voor het boek).

Aan de andere kant tracht je de portabiliteit aan banden te leggen. Maar dat is niet de juiste manier. Een compiler heeft sinds 1977 drie taken: compileren, porteren en transpileren. Houd dit gescheiden! Compileren is echt alleen naar Intermediate Language (IL) en machinecode! En IL speelt ook een belangrijke rol voor portable compiler (dus de veelzijdigheid). IL is pas opgekomen in de jaren 80.

Ik kan het niet genoeg benadrukken: hetgeen jij bij het woord compiler voorstelt zijn zaken die een compiler naast compiler nog kan doen. Dat is niet de hoofdzaak. Een compiler dient in de eerste plaats om een programma uit te kunnen voeren. Daarna kan een compiler zaken vereenvoudigen door minder werk te moeten doen door te porteren en te transpileren. Dat staat zwart op wit in de documentatie van GNU Compiler Collection uitgelegd. Je zult geen enkele gewichtige referenties vinden die dat anders uitlegt. Het boek dragon is een goed boek. Maar wees alert met een boek. De terminologie is vaak verschillend van boek tot boek. Wij brengen het volledige plaatje, maar de belangrijkste zaken moeten eerst komen. Daarna opbouwen tot geporteerde compiler. Je zei al eens dat bijna elke compiler naast de boot valt met mijn introtekst. Dat is omdat je je op het verkeerde focust en geen onderscheid maakt. Maar het artikel was verre van klaar. Ik zei toch, de veelzijdigheid moet nog aan bod komen.

Ik hoop dat je deze keer een betere aanpak organiseert. Het was niet altijd binnen de Universele Gedragscode van wikipedia (opscheppen, mij laag inschatten, emotionele toer het is niet erg dat...). Als je je afvraagt, wat doet dat daar en waarom wordt dat gezegd. Vraag het mij dan gewoon en we beslissen na elk onze argumenten te hebben gegeven hoe het verder moet. (als dat een groot issue is). Ik weet, er zijn bepaalde veranderingen die jij anders voorstelden. Zoals een bytecode. Jij zei dat is een objectcode maar geen IR. Je zult je toch moeten herzien en aanvaarden dat dit wel een High IR (HIR) is. Je kan dit zien bij de gegeven bron van een universiteit. Maar bovenal, de presentatie is gebaseerd op het boek Dragon die jij aangaf. Snap je? Sommige zaken zijn soms gewoon anders dan je aanvankelijk denkt. Dat is bij mij ook zo. Ik geef toe, dat ik met die C++ wel wat zaken heb verwoord in de intro die niet relevant waren.

Aangezien ik in Vlaanderen woon, heb ik soms andere zinsopbouw dan een Nederlander. Ik weet dat sommige woorden soms in een ander betekenis worden gebruikt. Dat botst soms wel eens. Ik aanvaard meestal de veranderingen. Al zijn ze soms wat raar voor mij. Zolang context niet wijzigt ben ik tevreden. Tenzij dat de fout gegrond is uiteraard, dan moet het veranderen. Maar dan graag wel een referentie zwart op wit gewenst dat effectief geverifieerd werd; ik moet dat ook doen. Colitem (overleg) 22 mrt 2024 03:35 (CET)

Ik ga hier niet reageren op jouw overlegbijdrage hierboven, maar alleen uitleggen waarom ik al jouw bijdragen van vandaag ga terugdraaien.

1. Je klopt je op de borst over al jouw bronnen, maar de bronnen die je gebruikt ondersteunen je beweringen niet. Ik noem een voorbeeld. De volgende twee zinnen heb ik letterlijk uit het artikel gekopieerd: "Compilers met portabiliteit kunnen naast compileren ook transpileren en porteren.[8][9] Moderne compilers hebben hedendaags meestal een hoge portabiliteit en interoperabiliteit om verschillende technologieën te bundelen tot één proces.[2][10]." Twee zinnen. Het eerste zinnetje is klinklare onzin, het tweede zinnetje is nietszeggende managementbingo. Beide hebben twee bronnen. Hoe kan dat? Nu, [8] en [9] zijn artikeltjes uit een woordenlijst die uitleggen wat "transpiler" en "port" betekenen, ze ondersteunen de zin helemaal niet, hoewel je dat we suggereert. De bronnen bij het tweede zinnetje komen uit de jaren zeventig (en zeggen dus niets over "moderne compilers") en beschrijven technologische vooruitgang uit die tijd. Ze ondersteunen de zin waar ze achter staan dus ook niet.
2. Je begrijpt je bronnen niet. Zo hebben veel van jouw bronnen het over "portable" compilers, en om de een of andere reden denk je dat woord nu overal te moeten gebruiken. Een geporteerde compiler is simpelweg een compiler voor platform A die later overgezet is naar een compiler voor platform B. Dat is handig, omdat je dan bij het schrijven van compiler B niet helemaal bij nul hoeft te beginnen. Een geporteerde compiler kan niets wat een niet-geporteerde compiler niet kan. Maar jij schrijft onzin als "Een geporteerde compiler kan beide efficiënt combineren en is voorzien van extensie die het mogelijk maakt te werken in een nieuwe ontwikkelomgeving of programmeertaal zonder het programma te moeten herschrijven." (weer met twee verkeerd begrepen bronnen erachter).
3. Je hebt geen flauw idee waar je het over hebt. Onder het kopje porteren las ik "Dit gaat vaak gepaard met het wijzigen van de formele taal (de broncode) om door de target compiler terug gecompileerd te worden." Ik had (en heb) geen flauw idee wat dat betekent, dus was ik benieuwd naar de bron die erachter staat. Dat bleek een interessant hoofdstukje over porteren te zijn. Niet geheel verrassend werden verschillen in endianness als mogelijk probleem bij het porteren genoemd. Toen las ik jouw tekst verder en las: "Dit levert geen nieuwe broncode op maar tussenliggende endianness-code." Toen wist ik dat je jouw bron gelezen, maar niet begrepen hebt, want dat is echt de grootst mogelijke onzin.

Ik denk dat je beter een ander onderwerp kunt kiezen om over te schrijven. Dit wordt niks. Hoopje (overleg) 22 mrt 2024 20:29 (CET)