nicht angemeldet
Hallo,
Ihre hackermäßige Natur führt zudem häufig zu schlechterer Lesbarkeit und Wartbarkeit der Programme.
... ich in genau diesem Punkt entschieden widerspreche. Nach meiner Erfahrung ist Programmcode, der bewusst auf optimale Performance getrimmt ist, meistens sogar besser lesbar und verständlich, weil er "straightforward" ist, weil er ohne Umschweife auf den Punkt kommt.
Ein Hack ist für mich ...
Moment, da reden wir von unterschiedlichen Dingen. Ich stimme dir zu, was die Charakterisierung von Hacks angeht. Aber unter "ihre hackermäßige Natur" verstehe ich etwas ganz anderes - nämlich eine sehr zielstrebige, kompakte und meist schlecht bis gar nicht dokumentierte Art zu programmieren.
Mir ist leider keine bessere Eindeutschung des englischen Adjektivs "hackish" eingefallen, vielleicht hätte ich es einfach benutzen sollen. Performance-Tweaks die ich im Voraus auf Verdacht einbaue sind meistens eben sehr "hackish", in dem zuvor genannten Sinne, dass sie von einer idealisierten Implementierung abrücken und einen Aspekt der Programmiersprache ausnutzen, der hoffentlich zu erhöhter Performance führt.
Diese Charakteristik ist es auch, die C den Ruf eingebracht hat sehr schnell und resourcensparend zu sein. C setzt exzessiv auf die manuellen Optimierungsfähigkeiten der Programmierer und bietet ihm dafür sehr viele lowlevel Routinen an, um bspw. direkten Einfluss auf das Speicherlayout nehmen zu können.
Stimmt, aber all das ist transparent und klar dokumentiert und damit weit vom Begriff "Hack" entfernt.
Hacks sind sogar meistens sehr gut dokumentiert, anders wäre ihre Einsatz häufig gar nicht zu rechtfertigen. Das sehe ich deshalb nicht als Auschlusskriterium.
Per se ist C nämlich eine eher langsame Sprache, zumindest in dem Sinne, dass der Compiler vergleichsweise wenig Möglichkeiten hat automatisiert Optimierungspotenzial zu erkennen und auszuschöpfen.
Einige Compiler können das allerdings beeindruckend gut. Ich habe mir vor 15..20 Jahren oft beim Debuggen den Assembler-Code angesehen, den damals der Borland-C-Compiler produziert hat, und war gelegentlich beeindruckt von den Optimierungen, die der an meinem Code noch vorgenommen hat.
Meine Relativierung bezog sich auf das theoretische Potenzial, dass den Compilern höherer aber eben auch restriktiverer Programmiersprachen innewohnt. Haskell hat zum Beispiel durch die Vermeidung von Nebenwirkungen sehr weit fortgeschrittene Möglichkeiten den Programmablauf zu variieren: Dadurch können sehr starke Parallelisierungseffekte erzielt werden oder Teilprogramme auf Verdacht schon vor ihrer Nutzung ausgewertet werden. Das ist allein aufgrund der Semantik von C in keinem vergleichbaren Maße möglich. Dafür geht ein Haskell-Programmierer einen starken Tradeoff zu Lasten der Vorhersehbarkeit der Performance seiner Programme ein, während ein C-Programmierer die Auswirkungen einzelner Programmabschnitte relativ einfach abschätzen kann. Und natürlich ist der C-Compiler einer der am weitesten entwickelten Compiler der Welt, der auch von einem starken ökonomischen Interesse voran getrieben wird. Ich habe den C-Compiler und die Optimierungsstrategien, die er implementiert, in keiner Weise herunterspielen wollen, weil ich sie im Detail ja auch gar nicht kenne. Ich habe vorrangig den Aspekt automatisierbarer Performanceoptimierung als Alternative zu manuellen Optimierungstechniken ins Spiel bringen wollen. Das ist mir nun hoffentlich besser gelungen.
Der Martin