Die Wahrheit ueber Generics
-
Lesenswerter Artikel:
[ Link aus rechtlichen Gründen entfernt ]
-
Gibt's den auch als nicht-Datei (html/text)?
-
cooky451 schrieb:
Gibt's den auch als nicht-Datei (html/text)?
Ja, oder als Comic/bilderbuch? -- Wäre ja auch mal ne Alternative für ne wissenschaftliche Arbeit.
@op: es ist vermutlich keine gute idee wenn du geschütztes material über deine dropbox öffentlich zugänglich machst...
-
Finde den Artikel kaum lesenswert...
// Zitat aus rechtlichen Gründen entfernt
Diese Erkenntnis betrifft doch im Generellen typisierte vs. untypisierte Sprachen. Außerdem fixiert sich die Studie viel zu sehr auf "developer productivity", wobei die meiste Zeit aber in gewachsenen Systemen mit Wartung und Fixing von altem Code vergeht.
MfG SideWinder
-
Hier der Link zum betreffenden Artikel: http://dl.acm.org/citation.cfm?doid=2509136.2509528
-
Der Artikel geht das Thema anhand von Java an. Ist das nicht etwas sinnfrei? Ich mein, für solch eine Untersuchung eine Sprache zu verwenden, bei der "Generics" nicht mehr bedeutet als dass der Compiler automatisch von und nach Object castet?
-
KuhTee schrieb:
Der Artikel geht das Thema anhand von Java an. Ist das nicht etwas sinnfrei? Ich mein, für solch eine Untersuchung eine Sprache zu verwenden, bei der "Generics" nicht mehr bedeutet als dass der Compiler automatisch von und nach Object castet?
Ist das ein Problem? Es geht doch vorrangig darum, was Generics mit dem Programmierer machen. Die Art und Weise wie diese Sprachfeature implementiert ist, ist da doch zweitrangig.
-
Es könnte ein Problem sein. Die Templates in C++ zB sind so fundamental anders als Generics in Java, daß die Verwendung und Wirkung auf die Entwickler auch entsprechend anders sind.
-
Warum soltle man C++-Templates Benchmarken, wenn man den Effekt von Generics analysieren will?
Wahrscheinlich wäre das Ergebnis mit Templates katastrophal.
-
Ich finde diese Studie generell unnütz (dämlich), denn es geht doch bei Generics darum, daß man besser Compilerfehler hat als Laufzeitfehler (wegen fehlerhaftem Cast).
-
Th69 schrieb:
Ich finde diese Studie generell unnütz (dämlich), denn es geht doch bei Generics darum, daß man besser Compilerfehler hat als Laufzeitfehler (wegen fehlerhaftem Cast).
Und warum ist das toll? Weil wir uns davon versprechen besseren Code in kürzerer Zeit zu entwickeln, sprich produktiver zu sein. Aus dieser Überlegung heraus ergibt sich also die These: die Verwendung von generics erhöht die Produktivität von Entwicklern. Und genau diese hypothese untersuchen die Autoren empirisch. Ich sehe jetzt nicht wieso das dann unnütz sein sollte. Weil man eh weiß was rauskommen sollte? Oder weil as anderes rausgekommen ist als erwartet?
-
Ich finde es völlig egal, ob die Produktivität von Entwicklern bei der Verwendung von Generics erhöht wird. Lieber länger für den Code zu brauchen, als in kurzer Zeit fehlerhaften Code zu produzieren!
-
@Jester
Die Idee der Studie ist grundsätzlich nicht schlecht.
Ich bin nur nicht sicher ob sie es so gut umgesetzt haben.z.B. was das "Fehler fixen" Beispiel angeht.
Wenn ich jmd. ein Programm gebe und sage "da is fehler drin, korrigiere den mal", und dann gucke wie lange die zum Finden & Fixen brauchen, dann misst man auch nur genau das: wie lange es gedauert hat einen Fehler, dessen Vorhandensein bereits feststeht, zu fixen. Und zwar von einem Entwickler, der das Projekt überhaupt nicht kennt.
Einer der Vorteile bei Compilerfehlern ist aber, dass sie früher auftreten als Laufzeitfehler, und daher auch früher gefixt werden. D.h. üblicherweise sofort nachdem der Code geschrieben wurde, und von den Leuten die den Code geschrieben haben. Daraus alleine entsteht eine wesentlich Zeitersparnis -- die diese Studie aber genau gar nicht messen konnte.
Weitere Kosten die bei Fehlern die erst später gefunden werden entstehen sind natürlich auch nicht erfasst. Also z.B. das was an Zeit dabei draufgeht dass eine Fehlerhafte Version in den Test geht (oder sogar produktiv geschaltet wurde weil der Fehler beim Testen übersehen wurde).Und was das Beispiel angeht wo die Entwickler mit Generics länger gebraucht haben als ohne... da würde mich der Code interessieren. Die Beschreibung klingt für mich ziemlich stark nach schlechtem Klassen-Design.
-
hustbaer schrieb:
@Jester
Die Idee der Studie ist grundsätzlich nicht schlecht.
Ich bin nur nicht sicher ob sie es so gut umgesetzt haben.Keine Frage, da kann man bestimmt was dran rumkritteln. Ich wollte nur aufzeigen, das sich hinzustellen und zu sagen "Das ist quatsch dieser Frage nachzugehen weil mit Generics ja besser sein muss" einfach kein Argument ist bzw. genau das Gegenteil von einer wissenschaftlichen Vorgehensweise.
@Th69:
Findest Du dass jemand der schnell fehlerhaften Code erstellen kann produktiv ist? Nicht? Können wir dann diese Kindergartenargumentation hinter uns lassen?
Die haben in kürzerer Zeit aber Code produziert, der die Testfälle bestanden hat, also zumindest in weiten Teilen korrekten Code, wofür die Leute mit Generics halt wohl länger gebraucht haben. Das kann man jetzt natürlich diskutieren, inwiefern die Ergebnisse aussagekräftig sind und ob das Setup dafür vernünftig war. Aber ich verstehe beim besten Willen nicht, wie man daraus zu dem Schluß "Das Rauszufinden ist eh unnützer Mist" kommen kann.
-
Jester schrieb:
Findest Du dass jemand der schnell fehlerhaften Code erstellen kann produktiv ist? Nicht?
Ist jetzt wohl offtopic, aber ich möchte erwähnen, dass ich mehrere Leute kenne, die schnell fehlerhaften Code produzieren und sich für sehr produktiv halten, z.B. ein alter Chef von mir. Da wird erstmal in 1-2 Tagen die Grundstruktur vom Projekt zusammengehackt ohne auch nur zu testen, obs kompiliert und dann an andere Mitarbeiter weitergegeben, die dann Wochen brauchen, um das tatsächlich zum Laufen zu bekommen und alle Fehler zu finden und Fälle zu lösen, an die der ursprüngliche Entwickler bei dem Prototyp überhapt nicht gedacht hat. Dann heißt es aber trotzdem, er hätte das Projekt in zwei Tagen geschrieben, und alle anderen wären unglaublich langsam und würden Wochen brauchen, um das noch so ein bisschen fertigzumachen.
-
Hallo Mechanics,
danke für deinen Beitrag - genau diese Art von "Programmierern" meine ich.
Und daher lieber die Hürde "Compiler" nehmen als einen fehlerhaften Code in Produktion gehen zu lassen (und die Fehlerbehandlung bei "Invalid Cast Exception" sieht dann meist so aus, daß einfach diese Exception (bzw. noch schlimmer alle Exceptions!) gefangen wird anstatt die Ursache zu beheben...
Ich habe noch mit C#/.NET 1 angefangen und weiß daher was für ein Segen dann die Einführung von Generics in C#/.NET 2 war.
