On 30.12.2014 15:28, Lothar Kimmeringer wrote:
Am 30.12.2014 um 13:51 schrieb Renee B:
Also dann am Besten aufhören C zu programmieren weil es wohl nicht bekannt ist dass Pufferüberläufe passieren können? Tatsaechlich bin ich dieser Meinung. Ausser dem geschmaelertem Ego des Programmierers gibt es eigentlich keinen Grund, auf eine Managed Sprache zu verzichten, sei es C#, Java, etc. die von vornherein solche Dinge vermeidet. Auf Treiberebene programmieren heutzutage wirklich die wenigsten.
Dann auch aber auch Schluss mit C# (kann im unsicheren Kontext ebenfalls Pufferüberläufe haben), Java (Pufferüberläufe mittels JNI), Python, ... Perl hat keine Pufferüberläufe, dafür andere Probleme. Und auch C#, Java, ... haben noch andere Probleme.
Dass so etwas - richtig angewendet - Schreibarbeit spart (was zum Vorworf des "write only codes" im Vortrag wurde), mag sein, Sourcecodeoptimierung hat aber nur selten langfristig zu positiven Effekten gefuehrt.
Ich rede nicht vom "golfen", sondern von gezielt weniger Schreibarbeit. Bleiben wir beim "List flattening": methoden_aufruf( @alle_argumente ) ist kürzer als methoden_aufruf( $alle_argumente[0], $alle_argumente[1], $alle_argumente[2], ...) und besser lesbar, besser wartbar, ... Vor allem wenn die Methode eine beliebige Anzahl von Parametern akzeptiert. Ich gebe Dir absolut Recht, dass man sich nicht *zu kurz* fassen sollte.
Von Fehlern kann sich keiner frei machen. Was man machen kann ist viel zu testen um die Programmierer zu unterstützen. Da ist OTRS bei den Backendmodulen ganz gut dabei, was Frontendsachen bzw. Requesthandling angeht besteht noch Nachholbedarf. Mit GUIs habe ich zum Glueck nicht viel zu tun, daher bewege ich mich primaer im Bereich JUnit.
Du glücklicher. - Renée -- Perl / OTRS development: http://perl-services.de OTRS AddOn repository: http://opar.perl-services.de