sciencetalk

Waarom? Persoonlijk sta ik nogal twijfelachtig tegenover programmeertalen waar je niet zo maar eventjes een (bijvoorkeur interactieve, single-pass) compiler voor kunt schrijven.

Feit is dat als je 1 compiler hebt, je je geen zorgen moet maken of je programma's wel bij iedereen op dezelfde manier gaan werken of niet.

Feit is dat als je 1 compiler hebt, je je geen zorgen moet maken of je programma's wel bij iedereen op dezelfde manier gaan werken of niet.

Dus c++ is een slechte taal omdat er meer dan 1 compiler is en onderlinge compilers ook wel verschillen hebben?

Dus c++ is een slechte taal omdat er meer dan 1 compiler is en onderlinge compilers ook wel verschillen hebben?

Dat heb ik nooit gezegd, ik zie er gewoon tegenop eerst de beste compiler te zoeken, in een of andere fanboywereld terecht te komen over wie de beste compiler heeft, terwijl het veel makkelijker zou zijn gewoon 1 compiler te hebben die aan alle standaarden voldoet.

Feit is dat als je 1 compiler hebt, je je geen zorgen moet maken of je programma's wel bij iedereen op dezelfde manier gaan werken of niet.

C++ is een helder omschreven standaard. Aan een C++ source code kan eenduidig worden afgeleid wat er precies moet gebeuren. Als iemand een compiler maakt die die C++ source omzet tot een programma wat iets anders doet, klopt zijn compiler niet en kunnen we dat strikt genomen dus geen C++ compiler noemen.

Dat verschillende C++ compilers verschillende programma's outputten zit hem in zaken als optimalisatie: de ene compiler kan bijvoorbeeld een efficiënter (kleiner of sneller) programma produceren dan de ander. Maar dat heeft niets met de taal te maken, en logisch/functioneel gezien doen die verschillende programma's wel degelijk hetzelfde.

Feit is dat als je 1 compiler hebt, je je geen zorgen moet maken of je programma's wel bij iedereen op dezelfde manier gaan werken of niet.

Daar kunnen twee dingen aan ten grondslag liggen: (1) een onduidelijke of mogelijk niet eens bestaande standaard voor de taal [Ruby bijvoorbeeld] of (2) dat een bepaalde versie niet voldoet aan de standaard definitie.

Je zult je in geval van low-level talen zoals C (en verwanten) altijd rekening moeten houden met implementatie verschillen; dit zijn hoofdzakelijk verschillen die niet in de taal zijn vast gelegd en men zou het dus onduidelijkheden kunnen noemen. Maar je wilt dit ook niet vastleggen.

Hoeveel CPU's zijn er? Hoeveel cores hebben de cpus? Is de cpu big of little endian? Hoeveel registers zijn er en hoe groot zijn deze? Wat is de word-size (het kleinste hoeveelheid direct adresseerbaar geheugen)? Hoe is het geheugen uiteindelijk ingedeeld? Ook de implementatie van standaard bibliotheken en menig OS details beïnvloeden de run time performance en vaak zelfs het gedrag van een programma.

De keuze van een compiler is in verhouding triviaal eenvoudig te noemen, voor de meeste platformen en talen zijn er maar een paar beschikbaar.

Aanvullend: En dit alles staat nog helemaal los van de keuze van programmeertaal, niet-standaard bibliotheken, frameworks en meer. Vooral de keuze van programmeertaal moet passend zijn voor wat men wel ontwikkelen.

C is weinig meer dan portable assembly, en dat is meestal een beetje te low level. C en vergelijkbare talen zijn prima als men slechts een variatie op een bekende software schrijft (Bijvoorbeeld een CRUD tool of zo) maar zodra men een programma moet schrijven waarbij niemand een idee heeft hoe het uiteindelijk er uit moet komen te zien (original research) dan zou ik persoonlijk een iets hogere level, Multi-paradigm, (meta)taal kiezen en daarin min of meer een (voor het probleem) passende programmeertaal ontwikkelen. (Language Oriented Programming).

Het doet er volgens mij ook weinig toe, iedereen die zich technisch verdiept in compilers is vroeg of laat in staat om zelf een compiler te schrijven.

Iedereen die lang genoeg (meer dan 10000 uur) programmeert zal vanzelf eens een compiler/interpreter schrijven (Ook al herkend niet iedereen direct dat ze dit gedaan hebben).