nicht angemeldet
[...]
Ich ziehe daraus die Erkenntnis, man sollte einen Kompromiß, der Performance und Wartbarkeit unter Einbeziehung der Applikationsanforderungen optimal vereint, schließen.
Ja, sehe ich auch so, Du mußt halt abwägen, was im konkreten Fall die größten Prioritäten genießt.
Früher war das ganz anders. Funktionen, die sich während des Programmablaufs selbst verändern, waren da ganz normal. Da wurde jeder Taktzyklus genau durchgerechnet. Da wäre es einfach undenkbar gewesen, Zugeständnisse in Richtung Lesbarkeit oder Wartbarkeit des Codes zu machen. Das genaue Gegenteil von OOP heute.
Das klingt so, als hättest Du nicht nur in Assembler, sondern hardwarenah, technisch oder zeitkritisch programmiert?
Halt die alten Sachen. 6502, Motorola ... Damals war Assembler und Maschinensprache ein Synonym. Hardwarenah war das sowieso.
Selbstmodifizierter Code ist ansonsten nämlich der Killer beim Bugfixen und späterem Warten von Code.
Ist klar.
Und bei kaufmännischen Anwendungen, z.B. in COBOL, geht's bereits in Richtung Wartbarkeit und nicht Rausquetschen des letzten Quentchens Performance der aktuellen Prozessorarchitektur. Wenn man mal überlegt, daß Softwaresysteme durchaus mehrere Jahrzehnte (!) genutzt werden...
Nick
Performance und Wartbarkeit stehen sich leider oft diametral entgegen. Ein Kompromiß klingt mir (für heutige Verhältnisse) auch am vernüntigsten.
Der Martin