Tuurlijk iedere verandering is geen verbetering. Daarom zweren velen bij de grammofoonplaat ipv een Cd om over Mp3 nog maar te zwijgen.

Mooie theorie.

Maar de praktijk is dat programmeurs tegenwoordig zelf zulke megagrote projekten op de rails zetten, dat ze bijna geen zicht meer hebben op de vraag of de software wel zo soepel draait als dat dat zou kunnen.
Moderne software wordt het meest vertraagd door:
- slechte zoekalgoritmes
- onnodige wachttijden.

Juist omdat de machines tegenwoordig zo snel zijn, wordt het programmeurs erg makkelijk gemaakt om software af te leven die een fikse belasting op de CPU legt, terwijl er enorm efficiënte tree searches zijn.
Met multithreading, wat nu heel erg hot is, wordt dat niet veel beter maar juist veel erger, omdat er bijna niemand is die weet hoe je de vermogens van meerdere cpu's maximaal kunt "uitnutten".

.NET is geen substituut voor goed programmeerwerk. Het staat of valt met goed begrijpen waar je mee bezig bent, en waarom.

Met een ding heeft hij natuurlijk wel gelijk .
Hoe hoger de programmeertaal dus hoe dichter het bij de menselijk taal staat , hoe verder het van de machinetaal staat .
Vaak staan in die hogere programmeer talen ook insctructies die je voor die bewerking niet nodig heb , en toch mee worden gecompileerd.
Wil je daar van af terug naar programmeren in machinetaal .
Maar wie kan dat nog ?
De spreuk moet dan ook zijn "Kort en Korrect Programeren."

Kwaliteit en efficiency zijn heel verschillende dingen. "Appels en peren"-verhaal.

Ach, ja, toendertijd hadden we computertjes, waarvan we de geheugen grootte in KB maten, ik denk daarbij aan de Sinclair machientjes, zoals de ZX81. Ik had ook nog een CP/M machine van 48KB.

@5 Wat dacht je van een "mini" met 32K RAM ter waarde van Fl 150.000,- ?

Mwah, vergeet niet dat in machinetaal programmeren gewoon te duur is geworden. Het op snelheid optimaliseren van een programma loont door de hoge kloksnelheid van processors nauwelijks nog de moeite, ik heb het nog wel gedaan met Turbo Pascal 6 op een XT met 10 MHz, en dan kon je met veel werk de verwerkingstijd nog wel eens vele seconden korter krijgen, en bij een programma dat vaak wordt uitgevoerd tikt dat wel aan. Maar nu kost het optimaliseren gewoon meer tijd dan je er ooit mee terugverdient. En dan praat ik nog over optimaliseren met een hogere programmeertaal, bij assembler wordt het helemaal belachelijk.

Programmeren in assembler is leuk hoor, maar wie gaat al die code lopen intikken? Ook in hogere programmertalen zoals C++ kun je heel efficient code schrijven. Een kwestie van gestructureerd kunnen programmeren (een kunst, die uiteraard niet iedere programmeur even goed beheerst, maar dat was 20 jaar geleden ook al zo, dus niets nieuws onder de zon). Bovendien scheer je wel heel erg makkelijk software over een kam. Ik ken genoeg specialistische maar ook mainstream applicaties die in de loop der tijd een stuk gebruikersvriendelijk en krachtiger geworden zijn. Bij software gaat het simpelweg om return on investment. Kortom, ik vind dit verhaal behoorlijk de plank misslaat. Als je dergelijke stellingen poneert, kom dan ook met een paar praktische voorbeelden.