Door Anoniem: Je bereikt veel meer als je die developers die de hele tijd zitten te wachten op een compile vervangt door mensen
die eerst nadenken, dan code schrijven en aan het eind een compile doen waarbij het vrij snel goed is.
Je kunt C vrij snel zonder optimalisatie compileren. Dat is het probleem niet.
Pas bij een release compile met optimalisatie kost het veel tijd. Verder is het meer theorie dan werkelijkheid. Ik denk niet dat jij een developer bent.
Dat kun jij denken maar ik was al bezig met het maken van software toen er nog geen PC'tjes waren.
Mijn eerste software maakte ik op "schrapkaarten" (een soort ponskaarten) en die leverde je dan in en je kreeg een of
twee dagen later het resultaat. Weet je, dan leer je het op een andere manier. Dan leer je dat je eerst moet denken
over het probleem wat je wilt oplossen en dan pas aan het programmeren gaat. En als het resultaat niet klopt dan zet
je er niet blind ergens +1 bij en drukt op compile and run, maar dan ga je uitzoeken waarom het niet werkt.
Dat is ook hoe ik het (later) geleerd heb van mensen die in die tijd software development doceerden. Geen gepruts
om zichtbare probleempjes op te lossen maar nadenken over het algorithme en over loop-invarianten. Iets maken
waarvan het bij doorlezen duidelijk is waarom het wel of niet werkt, niet door het steeds maar te "testen".
Het werk wat ik de eerste jaren deed was op systemen waar echt niet genoeg capaciteit was om de hele dag te
compileren. Als je een "make" deed dan keek na een tijdje iedereen om omdat de editor trager was. Compilaties
van het hele pakket werden in de nacht gedaan.
Maar parallel daaraan ontstonden de eerste IDE's zoals UCSD Pascal, Turbo Pascal e.d.
Daar zag je een heel ander soort programmeur. Degene die twee of drie statements veranderde en weer compile
deed. En daar zat een totaal eigen soort bugs aan vast, want die mensen snapten niet dat je met testen nooit kon
garanderen dat een programma foutvrij is.