Fast alle KDE Software ist in C++ geschrieben. Neuerdings kommt im GUI Bereich auch QtQuick hinzu - da war übrigens KMail einer der ersten Anwendungsfälle. Marble und KStars sind auch beide in C++ geschrieben
Ich frage mich daher was deine Aussage soll. Ich als Entwickler eines in C++ geschriebenen Fenstermanagers kann nicht an dem in C++ geschriebenen E-Mail Frameworks arbeiten, da mir schlicht die Kompetenz dazu fehlt. Genauso haben halt E-Mail Framework Entwickler keine Ahnung von Fenstermanagement (das könnte ich nun mit Quellen beweisen).
Von C++ Entwickler am So, 19. August 2012 um 01:12 #
> Ich als Entwickler eines in C++ geschriebenen Fenstermanagers kann nicht an dem in C++ geschriebenen E-Mail Frameworks arbeiten, da mir schlicht die Kompetenz dazu fehlt.
Dann bist du unflexibel.
Also ich kann, ich arbeite mich in den zusätzlichen Stoff, sofern vorhanden, einfach ein und gut ist.
Zumal eigentlich jeder Informatiker ein Grundgerüst in Sachen E-Mails und der dazu entsprechenden RFC haben sollte, der Rest ist trivial. Insbesondere wenn es nur darum geht Bugs zu beheben und nicht neue Features einzubauen.
Ja nee ist klar. Wenn Du Herzprobleme hast, kannst Du ja auch zu einem Zahnarzt gehen, der ist ja auch Mediziner. Was solls, kann er sich doch bei Deiner Bypass-OP erst einmal einarbeiten...
Die Sprache ist doch nicht das Problem, sondern die Problem Domäne - wer das nicht verstanden hat ist eben kein guter Informatiker! Natürlich kann man sich in diese einarbeiten, aber das verlangt eben Zeit und Motivation. Und wenn man für etwas nicht bezahlt wird, dann ist ersteres meist knapp und letzteres rein intrinsisch. Insofern ist die Annahme, dass KDE Entwickler einfach mal so universell Bugs fixen ziemlich naiv und weltfremd.
Von C++ Entwickler am So, 19. August 2012 um 02:40 #
Wenn du nen Unfall hast, dann operiert dich ein Arzt des Krankenhaus am Herz, der Niere oder sonst wo.
Im übrigen hinkt dein Vergleich, denn wie ich bereits sagte, gehört Rechnernetze zum Grundstudium eines Informatikstudiums. Das ist also keine Schwerpunktwahl wie bei einem Arzt der seinen Schwerpunkt auf Zahnarzt setzt.
> Insofern ist die Annahme, dass KDE Entwickler einfach mal so universell Bugs fixen ziemlich naiv und weltfremd.
Nö, denn wie ich bereits sagte, müssen keine neuen Features eingeführt werden, sondern Bugs gefixt werden. Das ist also C++ Code, bei dem der Großteil des Codes schon existiert und bei den Grundbausteinen von der Schleife bis zur IF Bedingung oder typischen bekannten Algorithmen unterschiedet sich kein Code.
Das was du sagst, ist in etwa so, als könnte ein Kind, welches nur Lego Burgen baut, keine Schiffe aus Lego Bausteinen bauen.
Die Software besteht aus Millionen Code-Zeilen. Da kann man sich nicht einfach so einarbeiten. Jedes Projekt hat eine andere Struktur und andere Schwierigkeiten. Das sollte man in Grundstudium gelernt haben.
Falls du meinst, dass es so einfach ist behebe den Bug doch selbst!
Von C++ Entwickler am So, 19. August 2012 um 06:14 #
Offenbar ist nicht jeder talentiert, das sehe ich an deiner Antwort.
Der erste Schritt ist ein Debugger, damit findet man schon die Stelle, wo das Programm aussteigt, sofern der Bug reproduzierbar ist. Und OO Code ist eine große Hilfe, wenn er denn gut designed wurde, so daß ein guter Progger sich hier eigentlich gut zurecht finden sollte.
So manche Cracker haben es da schwerer, denn denen steht kein Original C++ Code zur Verfügung.
Mit einem Debugger findest du crashes, super, das ist aber nur ein mögliches Problem. Um den Crash zu finden brauch ich keinen Debugger, da reicht auch der Crash Report der Users. Und was hat man wenn man die Stelle gefunden hat? Richtig die Stelle Code an der es abraucht. Das hilft bei der Problemlösung ziemlich wenig wenn man die Materie nicht kennt - und das ist genau was hier ausgesagt wurde.
Ich gib dir jetzt mal einen Crash Fix als Beispiel. Ein Crash bei dem wir etwa zwei Jahre lang nicht wussten wie man ihn auslösen kann. Wir wussten die Zeile wo es abraucht, aber nicht warum. Zuletzt nach einigen Code-Änderung hätte dir ein Debugger nicht mal mehr den Crash gezeigt, da es ein vom Timing abhängiges Problem war - upps Debugger verändern ja das Verhalten von Anwendungen. Ohne tiefes Verständnis des internen Aufbaus der Anwendung wäre dieser Crash nicht behebbar gewesen und den Ansatz den ich gewählt hatte, war ein Schuss ins Blaue basierend auf Annahmen, die ich ableiten konnte aus meinem Wissen über den internen Aufbau der Anwendung und das Verhalten im fraglichen Zeitraum.
Ich wage sehr zu bezweifeln, dass ein nicht Domain Experte dieses Problem hätte identifizieren können (den Weg das Problem zu reproduzieren hatte ich auch selbst aus Wissen über die Anwendung abgeleitet), noch dass er auf den Lösungsansatz gekommen wäre, noch dass er ihn hätte umsetzen können. Immerhin wir als Experten der Anwendungen haben Monate gebraucht einen Weg zu finden den Crash zu reproduzieren.
Von C++ Entwickler am So, 19. August 2012 um 16:34 #
Immerhin wir als Experten der Anwendungen haben Monate gebraucht einen Weg zu finden den Crash zu reproduzieren.
Erkennst du hier deinen Denkfehler nicht?
Du schreibst "Experten der Anwendung". Eben, ein Experte der Anwendung ist nicht zwangsläufig auch ein Experte der RFCs, Gesetzesvorschriften und Normen in diesem Bereich, etwas, was du ja zu Beginn hier angeführt hast, daß man das brauchen würde, um den C++ Code zu fixen. Siehe deine Worte:
Ich als Entwickler eines in C++ geschriebenen Fenstermanagers kann nicht an dem in C++ geschriebenen E-Mail Frameworks arbeiten, da mir schlicht die Kompetenz dazu fehlt.
Es ist also ein Code wie jeder andere, der eine bestimmte Anwendung bildet. Für die Anwendung arbeitet man sich kurz ein, bei gegebenen UML Diagramm sollte das recht effizient möglich sein, ansonsten nimmt man eben den Code und dann kann ein guter C++ Entwickler auch das Problem fixen.
Denn das Problem hat nichts mit RFCs, Gesetzevorschriften oder Normen oder speziellen Softwarebereichen zu tun, sondern es ist schlichtweg nur C++ Code.
Die Grundlagen die einem Programm zugrunde liegen sind überall gleich, die Spezialisierung fängt erst da an, wo du Experten in umzusetzenden Gestezesvorschriften, RFCs oder Normen benötigst und das braucht man nicht zum Bug fixen, sondern für nur neue Features.
nun ok du hast vollkommen Recht ich bin ein absoluter Idiot. Ich verstehe gar nicht warum ich mehr als ein Jahr gebraucht habe bis ich KWin intern verstanden habe und ich verstehe noch viel weniger warum ich nach all den Jahren und sogar mittlerweile als Maintainer immer noch Bereiche gibt von denen ich keine Ahnung habe.
Ich hätte mich wohl besser mal kurz in den Quellcode einarbeiten müssen oder ich bin einfach ein zu schlechter Programmierer.
Nun zu der RFC Geschichte. Klar wenn ich bei KWin Bugs behebe brauche ich dafür keine RFC, trotzdem hab ich hier einen kompletten Stapel mit ausgedruckten Spezifikationen, die ich immer mal wieder zur Rate ziehe. Muss manchmal schon sein, wenn sich die GTK Anwendungen anders verhalten als die Qt Anwendungen. Da muss man halt schon mal die Specs lesen. Aber klar braucht man ja nicht, der C++ Code ist natürlich völlig ausreichend.
Schon mal gesehen, dass ein RFC buggy ist oder von Servern falsch umgesetzt wird? Die Software, die ich während meiner Masterthesis geschrieben habe, ist am Ende daran gescheitert, dass die GoogleMail Server einen RFC falsch bzw. gar nicht implementiert hatten. Aber klar das Lesen des Quellcodes hätte das Problem sicherlich behoben.
"Die Software, die ich während meiner Masterthesis geschrieben habe, ist am Ende daran gescheitert, dass die GoogleMail Server einen RFC falsch bzw. gar nicht implementiert hatten."
Und jetzt? Musst Du die "Diplomarbeit" noch einmal schreiben?
Es ist schon lustig, was Du als "C++ Entwickler" so für wage Thesen vertrittst. Ich habe in meinem Informatikstudium niemals ein RFC in einer VL durchgekaut oder mich sonst wie näher mit Mail-Protokollen befasst. War das also dann kein "richtiges" Informatikstudium? Das solltest Du meiner Uni mal schreiben
Zu dem Finden von Bugs hatte Martin ja schon einiges geschrieben. Ich will aber noch mal herausstellen, dass *speziell* das Fixen von Bugs tiefgreifende Kenntnis des Codes und Erfahrung in der Domäne voraussetzt. Das Coden von neuen Funktionalitäten ist da fast einfacher, sofern Du Dich auf vorhandenes stützen kannst. Das "nur" Bug fixen ist also kein "nur", sondern geht mit der von mir dargestellten Kausalkette (Coden in der Freizeit, intrinsische Motivation) einher. Und daher bleibst Deine Ansicht weltfremd.
Im übrigen kannst Du meine These gerne ignorieren - in der Realität indes zeigt es sich doch, dass der Status quo genau so ist, wie ich ihn ableite. Und den kannst Du nicht wegdiskutieren...
Zudem verunglimpfst Du meine Beispiele. Bei der Technologie "Lego" ist es eben künstlich anzunehmen, dass es dort spezielle Domänen gäbe, bei denen jemand keine universelle Kompetenz haben kann. Im Bereich "Technic" ist es aber in der Tat so, dass Du sicherlich Probleme hast, gewisse Funktionalität zu implementieren, wenn Du damit noch keine Erfahrung hast. Denn auch bei Lego gibt es gewisse "Design Pattern" und zudem musst Du von der Existenz von Teilen wissen, wenn von diesen die Machbarkeit abhängt - das geht ohne Erfahrung einfach nicht. Davon abgesehen ist das aber auch kein Bug fixen, denn so stark kann man bei Lego wohl kaum Tätigkeiten abstrahieren
Mein Arzt Gleichnis ist einfach gut - Du kannst aber auch gerne einen Elektriker nehmen. Der eine kann ein Haus verkabeln, der andere mein TV Gerät oder meine Waschmaschine reparieren. Es ist schon weltfremd anzunehmen, dass beide so mir nichts dir nichts austauschbar wären. Fachkompetenz erwirbt man sich durch Zeit, die man in einer Domäne tätig ist; das kann man nicht mit Pauschalaussagen a la "C++ ist das wichtige, wer das kann, kann alles" wegfegen.
Deine Aussagen zu Bugs und Deiner Unfähigkeit Bildnisse zu interpretieren lassen mich aber auch daran zweifeln, ob Du wirklich Ahnung von der Materie des Softwareentwicklung hast. Einen coolen Nickname kann sich hier ja jeder zulegen
Von C++ Entwickler am So, 19. August 2012 um 16:50 #
Ich habe in meinem Informatikstudium niemals ein RFC in einer VL durchgekaut oder mich sonst wie näher mit Mail-Protokollen befasst.
Tja, ein Studium umfaßt nunmal auch Eigenarbeit zu Hause.
Ich habe mir die RFCs zum HTTP und FTP Protokoll, sowie zu denen eines E-Mail Programms alle durchgelesen, unser Prof hat uns das sogar auch empfohlen und stell dir vor, in meiner Studierzeit habe ich auch die RFCs zu VoIP durchgelesen.
Wenn du das nicht gemacht hast, dann ist das schlecht, weil es aussagt, daß du während deinem Studium dich nicht besonders tief in die Materie eingearbeitet hast, sondern gerademal das allernötigste gemacht hast nur um Scheine zu bestehen.
dass *speziell* das Fixen von Bugs tiefgreifende Kenntnis des Codes
Siehe mein erstes Posting, man arbeitet sich kurz ein und verschafft sich einen Überblick, die meisten Bugs kann man damit erschlagen.
und Erfahrung in der Domäne voraussetzt.
Nö, das eben nicht, Siehe oben.
Wenn ich an einem Programm für z.B. Elektroniklayout einen Bug fixen möchte, dann muß ich weder die VDE Vorschriften noch die Pin-Abstände von diversen ICs wissen, möglicherweise brauche ich nichtmal ein tieferes Verständnis in der Elektrotechnik, denn dieses Wissen brauche ich nur dann, wenn ich neue Features in die Software einarbeiten will und nicht zum Fixen eines Bugs.
Das fixen von Bugs ist in 99 % der Fälle nur das Fixen von Programmierfehlern, also der Programmierung an sich und alles was damit zu tun hat. Im prinzip also die Grundlagen, die Grundbausteine und Algorithmen.
Das Coden von neuen Funktionalitäten ist da fast einfacher, sofern Du Dich auf vorhandenes stützen kannst.
Ne, eben nicht. Wenn ich an einer Schaltungssimulation für Elektronik neue Features einbauen will, dann brauche ich in den meisten Fällen ein tieferes Verständnis in der Elektrotechnik.
Bei Programmen für die Medizin wird das nicht anders sein, was meinst denn du, warum es in der Informatik extra Studiengänge wie Wirtschafts-, Medizin- oder Bioinformatik gibt?
Das erschaffen von völlig neuen Features erfordert also wesentlich mehr Hintergrundwissen, als für das reine fixen von Bugs. Für das fixen von Bugs reicht reines Programmiererwissen.
Du kannst aber auch gerne einen Elektriker nehmen. Der eine kann ein Haus verkabeln, der andere mein TV Gerät oder meine Waschmaschine reparieren.
Offenbar kennst du den Unterschied zwischen einem Elektriker und einem Elektroniker nicht.
Deine Hausverkabelung ist Elektrik. Das TV Gerät ist reine Elektronik. Und die Waschmaschine wohl so ein Zwischending zwischen Elektronik und Mechatronic.
Das fixen von Bugs ist in 99 % der Fälle nur das Fixen von Programmierfehlern, also der Programmierung an sich und alles was damit zu tun hat. Im prinzip also die Grundlagen, die Grundbausteine und Algorithmen.
Glaubst du allen Ernstes, dass zum Beispiel die Probleme bei Akonadi oder Nepomuk (worüber dieser Thread ja ist) simple Programmierfehler sind? Ach wäre das schön wenn dem so wäre...
Glaubst du den Fehler den ich weiter oben beschrieb, war ein simpler Progammierfehler? Glaubst du allen Ernstes, dass man Fehler in Nepomuk beheben kann ohne Wissen von RDF? Oder Fehler in KWin ohne Wissen von Fenstermanagement und Compositing?
Wenn ja, dann bitte ich dich doch in die freie Software Entwicklung einzusteigen. Du scheinst ein Genie zu sein, wie ich es so noch nicht gesehen habe. Freue mich schon in Zukunft weniger Bugs zu haben
Und nun gehe ich erst mal einen Unit Test schreiben für einen Fehler den ich noch nicht ganz verstehe.
Tja, ein Studium umfaßt nunmal auch Eigenarbeit zu Hause.
Ich habe mir die RFCs zum HTTP und FTP Protokoll, sowie zu denen eines E-Mail Programms alle durchgelesen, unser Prof hat uns das sogar auch empfohlen und stell dir vor, in meiner Studierzeit habe ich auch die RFCs zu VoIP durchgelesen.
Wenn du das nicht gemacht hast, dann ist das schlecht, weil es aussagt, daß du während deinem Studium dich nicht besonders tief in die Materie eingearbeitet hast, sondern gerademal das allernötigste gemacht hast nur um Scheine zu bestehen.
LOL! Schon mal daran gedacht, dass es nicht jeden Informatiker nach solchen Dingen gelüstet? HTTP nehme ich gerne als gegeben hin, ebenso POP3 usw. Ich kenne natürlich einige Grundlagen, aber das *stumpfe* Durchlesen von RFCs bringt genauso viel wie das eines Lexikons - außer, man hat ein eidetisches Gedächtnis.
Hast Du Dich mal mit semantischen Technologien auseinander gesetzt? Ontologien, OWL, SPARQL? Es ließen sich sicherlich genügend Themenfelder finden, von denen Du keine oder wenig fundierte Ahnung hast - deswegen abzuleiten, dass jemand zu wenig Interesse an der Gesamtmaterie hat und nur das "nötigste" für seine Scheine getan hat, ist sagenhaft dümmlich! Als dermaßen vor Selbstwusstsein strotzendem Informatik-Gott , der gerne ex catedra redet und seine Meinung als Naturgesetz darstellt, hätte ich ein wenig mehr Intelligenz erwartet...
Ad "Elektroniker vs Elektriker": Du hast Recht, ich war da zu unpräzise. Offenbar ist der Oberbegriff der des Elektronikers - Elektriker ist da wohl eher Volksmund. Allerdings ändert das nichts an meinem Bild, denn offensichtlich bezeichnet man eben doch beide *Spezialisierungen* mit einem Begriff. Zudem bleibt das Ärzte Gleichnis immer noch so stehen, ohne dass Du es auch nur ansatzweise entkräften konntest (Wie auch!?! Es stimmt eben )
Deine Weltsicht auf Bugs ist dermaßen eingeschränkt, dass ich immer noch denke, dass Du eher noch ein Student bist, der nur kleinere und kürzere Projekte realisiert hast. Bugs umfassen so viel mehr als simple Programmierfehler! Und genau das sind einfach diejenigen, deren Ursache sich nur *schwer* aufspüren und ggf. auch beheben lässt. Wer das auf "Man muss nur C++ kennen" reduziert, ist einfach nicht ernst zu nehmen.
Und nein, neue Features können sehr viel einfacher sein, als einen Bug zu fixen. Oftmals sind es Kompositionen von vorhandenen Komponenten; was muss ich da für ein tiefgreifendes Verständnis für die Software im Kern haben? Ich habe mir auch schon mal kleine Erweiterungen für Gimp geschrieben - meinst Du ernsthaft, dass ich mir dafür Wissen um den Code von Gimp oder Grafikverarbeitung i.A. hätte aneignen müssen? Gleiches gilt für Scribus, dort sogar *direkt* im Code, den ich um eine Funktion in der Python-API erweitert habe. Dank Doku zur API muss man sich nur die Funktionen zusammenstellen, die man benötigt... alles viel trivialer, als einen Programmfehler auszumerzen.
Natürlich können neue Funktionen auch sehr schwierig zu implementieren sein! Aber im Gegensatz zu Bugs besteht hierbei die *Möglichkeit*, dass das einfach funktioniert.
Fast alle KDE Software ist in C++ geschrieben. Neuerdings kommt im GUI Bereich auch QtQuick hinzu - da war übrigens KMail einer der ersten Anwendungsfälle. Marble und KStars sind auch beide in C++ geschrieben
Ich frage mich daher was deine Aussage soll. Ich als Entwickler eines in C++ geschriebenen Fenstermanagers kann nicht an dem in C++ geschriebenen E-Mail Frameworks arbeiten, da mir schlicht die Kompetenz dazu fehlt. Genauso haben halt E-Mail Framework Entwickler keine Ahnung von Fenstermanagement (das könnte ich nun mit Quellen beweisen).
> Ich als Entwickler eines in C++ geschriebenen Fenstermanagers kann nicht an dem in C++ geschriebenen E-Mail Frameworks arbeiten, da mir schlicht die Kompetenz dazu fehlt.
Dann bist du unflexibel.
Also ich kann, ich arbeite mich in den zusätzlichen Stoff, sofern vorhanden, einfach ein und gut ist.
Zumal eigentlich jeder Informatiker ein Grundgerüst in Sachen E-Mails und der dazu entsprechenden RFC haben sollte, der Rest ist trivial. Insbesondere wenn es nur darum geht Bugs zu beheben und nicht neue Features einzubauen.
Ja nee ist klar. Wenn Du Herzprobleme hast, kannst Du ja auch zu einem Zahnarzt gehen, der ist ja auch Mediziner. Was solls, kann er sich doch bei Deiner Bypass-OP erst einmal einarbeiten...
Die Sprache ist doch nicht das Problem, sondern die Problem Domäne - wer das nicht verstanden hat ist eben kein guter Informatiker! Natürlich kann man sich in diese einarbeiten, aber das verlangt eben Zeit und Motivation. Und wenn man für etwas nicht bezahlt wird, dann ist ersteres meist knapp und letzteres rein intrinsisch. Insofern ist die Annahme, dass KDE Entwickler einfach mal so universell Bugs fixen ziemlich naiv und weltfremd.
Wenn du nen Unfall hast, dann operiert dich ein Arzt des Krankenhaus am Herz, der Niere oder sonst wo.
Im übrigen hinkt dein Vergleich, denn wie ich bereits sagte, gehört Rechnernetze zum Grundstudium eines Informatikstudiums.
Das ist also keine Schwerpunktwahl wie bei einem Arzt der seinen Schwerpunkt auf Zahnarzt setzt.
> Insofern ist die Annahme, dass KDE Entwickler einfach mal so universell Bugs fixen ziemlich naiv und weltfremd.
Nö, denn wie ich bereits sagte, müssen keine neuen Features eingeführt werden, sondern Bugs gefixt werden.
Das ist also C++ Code, bei dem der Großteil des Codes schon existiert und bei den Grundbausteinen von der Schleife bis zur IF Bedingung oder typischen bekannten Algorithmen unterschiedet sich kein Code.
Das was du sagst, ist in etwa so, als könnte ein Kind, welches nur Lego Burgen baut, keine Schiffe aus Lego Bausteinen bauen.
Die Software besteht aus Millionen Code-Zeilen. Da kann man sich nicht einfach so einarbeiten. Jedes Projekt hat eine andere Struktur und andere Schwierigkeiten. Das sollte man in Grundstudium gelernt haben.
Falls du meinst, dass es so einfach ist behebe den Bug doch selbst!
Offenbar ist nicht jeder talentiert, das sehe ich an deiner Antwort.
Der erste Schritt ist ein Debugger, damit findet man schon die Stelle, wo das Programm aussteigt, sofern der Bug reproduzierbar ist.
Und OO Code ist eine große Hilfe, wenn er denn gut designed wurde, so daß ein guter Progger sich hier eigentlich gut zurecht finden sollte.
So manche Cracker haben es da schwerer, denn denen steht kein Original C++ Code zur Verfügung.
Sorry, aber was du schreibst ist ziemlich naiv.
Mit einem Debugger findest du crashes, super, das ist aber nur ein mögliches Problem. Um den Crash zu finden brauch ich keinen Debugger, da reicht auch der Crash Report der Users. Und was hat man wenn man die Stelle gefunden hat? Richtig die Stelle Code an der es abraucht. Das hilft bei der Problemlösung ziemlich wenig wenn man die Materie nicht kennt - und das ist genau was hier ausgesagt wurde.
Ich gib dir jetzt mal einen Crash Fix als Beispiel. Ein Crash bei dem wir etwa zwei Jahre lang nicht wussten wie man ihn auslösen kann. Wir wussten die Zeile wo es abraucht, aber nicht warum. Zuletzt nach einigen Code-Änderung hätte dir ein Debugger nicht mal mehr den Crash gezeigt, da es ein vom Timing abhängiges Problem war - upps Debugger verändern ja das Verhalten von Anwendungen. Ohne tiefes Verständnis des internen Aufbaus der Anwendung wäre dieser Crash nicht behebbar gewesen und den Ansatz den ich gewählt hatte, war ein Schuss ins Blaue basierend auf Annahmen, die ich ableiten konnte aus meinem Wissen über den internen Aufbau der Anwendung und das Verhalten im fraglichen Zeitraum.
Ich wage sehr zu bezweifeln, dass ein nicht Domain Experte dieses Problem hätte identifizieren können (den Weg das Problem zu reproduzieren hatte ich auch selbst aus Wissen über die Anwendung abgeleitet), noch dass er auf den Lösungsansatz gekommen wäre, noch dass er ihn hätte umsetzen können. Immerhin wir als Experten der Anwendungen haben Monate gebraucht einen Weg zu finden den Crash zu reproduzieren.
Erkennst du hier deinen Denkfehler nicht?
Du schreibst "Experten der Anwendung".
Eben, ein Experte der Anwendung ist nicht zwangsläufig auch ein Experte der RFCs, Gesetzesvorschriften und Normen in diesem Bereich, etwas, was du ja zu Beginn hier angeführt hast, daß man das brauchen würde, um den C++ Code zu fixen.
Siehe deine Worte:
Es ist also ein Code wie jeder andere, der eine bestimmte Anwendung bildet.
Für die Anwendung arbeitet man sich kurz ein, bei gegebenen UML Diagramm sollte das recht effizient möglich sein, ansonsten nimmt man eben den Code und dann kann ein guter C++ Entwickler auch das Problem fixen.
Denn das Problem hat nichts mit RFCs, Gesetzevorschriften oder Normen oder speziellen Softwarebereichen zu tun, sondern es ist schlichtweg nur C++ Code.
Die Grundlagen die einem Programm zugrunde liegen sind überall gleich, die Spezialisierung fängt erst da an, wo du Experten in umzusetzenden Gestezesvorschriften, RFCs oder Normen benötigst und das braucht man nicht zum Bug fixen, sondern für nur neue Features.
nun ok du hast vollkommen Recht ich bin ein absoluter Idiot. Ich verstehe gar nicht warum ich mehr als ein Jahr gebraucht habe bis ich KWin intern verstanden habe und ich verstehe noch viel weniger warum ich nach all den Jahren und sogar mittlerweile als Maintainer immer noch Bereiche gibt von denen ich keine Ahnung habe.
Ich hätte mich wohl besser mal kurz in den Quellcode einarbeiten müssen oder ich bin einfach ein zu schlechter Programmierer.
Nun zu der RFC Geschichte. Klar wenn ich bei KWin Bugs behebe brauche ich dafür keine RFC, trotzdem hab ich hier einen kompletten Stapel mit ausgedruckten Spezifikationen, die ich immer mal wieder zur Rate ziehe. Muss manchmal schon sein, wenn sich die GTK Anwendungen anders verhalten als die Qt Anwendungen. Da muss man halt schon mal die Specs lesen. Aber klar braucht man ja nicht, der C++ Code ist natürlich völlig ausreichend.
Schon mal gesehen, dass ein RFC buggy ist oder von Servern falsch umgesetzt wird? Die Software, die ich während meiner Masterthesis geschrieben habe, ist am Ende daran gescheitert, dass die GoogleMail Server einen RFC falsch bzw. gar nicht implementiert hatten. Aber klar das Lesen des Quellcodes hätte das Problem sicherlich behoben.
"Die Software, die ich während meiner Masterthesis geschrieben habe, ist am Ende daran gescheitert, dass die GoogleMail Server einen RFC falsch bzw. gar nicht implementiert hatten."
Und jetzt?
Musst Du die "Diplomarbeit" noch einmal schreiben?
Nein, natürlich nicht. Ich hab das ganze mal im Blog zusammengefasst. Ausführlich auch hier.
68 Euro? Da finde ich die Nutzung des openSUSE Buldservice aber wesentlich origineller.
Aber klar doch! Der Unfallarzt operiert alles! Wenn Du ihn nett bittest, saugt er Dir vielleicht auch noch Fett ab und korrigiert die Nase.
Schon lange nicht mehr in der Notaufnahme gewesen, oder? Selbst die Autoren von "Emergency Room" hatten mehr Ahnung als Du.
Es ist schon lustig, was Du als "C++ Entwickler" so für wage Thesen vertrittst. Ich habe in meinem Informatikstudium niemals ein RFC in einer VL durchgekaut oder mich sonst wie näher mit Mail-Protokollen befasst. War das also dann kein "richtiges" Informatikstudium? Das solltest Du meiner Uni mal schreiben
Zu dem Finden von Bugs hatte Martin ja schon einiges geschrieben. Ich will aber noch mal herausstellen, dass *speziell* das Fixen von Bugs tiefgreifende Kenntnis des Codes und Erfahrung in der Domäne voraussetzt. Das Coden von neuen Funktionalitäten ist da fast einfacher, sofern Du Dich auf vorhandenes stützen kannst. Das "nur" Bug fixen ist also kein "nur", sondern geht mit der von mir dargestellten Kausalkette (Coden in der Freizeit, intrinsische Motivation) einher. Und daher bleibst Deine Ansicht weltfremd.
Im übrigen kannst Du meine These gerne ignorieren - in der Realität indes zeigt es sich doch, dass der Status quo genau so ist, wie ich ihn ableite. Und den kannst Du nicht wegdiskutieren...
Zudem verunglimpfst Du meine Beispiele. Bei der Technologie "Lego" ist es eben künstlich anzunehmen, dass es dort spezielle Domänen gäbe, bei denen jemand keine universelle Kompetenz haben kann. Im Bereich "Technic" ist es aber in der Tat so, dass Du sicherlich Probleme hast, gewisse Funktionalität zu implementieren, wenn Du damit noch keine Erfahrung hast. Denn auch bei Lego gibt es gewisse "Design Pattern" und zudem musst Du von der Existenz von Teilen wissen, wenn von diesen die Machbarkeit abhängt - das geht ohne Erfahrung einfach nicht. Davon abgesehen ist das aber auch kein Bug fixen, denn so stark kann man bei Lego wohl kaum Tätigkeiten abstrahieren
Mein Arzt Gleichnis ist einfach gut - Du kannst aber auch gerne einen Elektriker nehmen. Der eine kann ein Haus verkabeln, der andere mein TV Gerät oder meine Waschmaschine reparieren. Es ist schon weltfremd anzunehmen, dass beide so mir nichts dir nichts austauschbar wären. Fachkompetenz erwirbt man sich durch Zeit, die man in einer Domäne tätig ist; das kann man nicht mit Pauschalaussagen a la "C++ ist das wichtige, wer das kann, kann alles" wegfegen.
Deine Aussagen zu Bugs und Deiner Unfähigkeit Bildnisse zu interpretieren lassen mich aber auch daran zweifeln, ob Du wirklich Ahnung von der Materie des Softwareentwicklung hast. Einen coolen Nickname kann sich hier ja jeder zulegen
Tja, ein Studium umfaßt nunmal auch Eigenarbeit zu Hause.
Ich habe mir die RFCs zum HTTP und FTP Protokoll, sowie zu denen eines E-Mail Programms alle durchgelesen, unser Prof hat uns das sogar auch empfohlen und stell dir vor, in meiner Studierzeit habe ich auch die RFCs zu VoIP durchgelesen.
Wenn du das nicht gemacht hast, dann ist das schlecht, weil es aussagt, daß du während deinem Studium dich nicht besonders tief in die Materie eingearbeitet hast, sondern gerademal das allernötigste gemacht hast nur um Scheine zu bestehen.
Siehe mein erstes Posting, man arbeitet sich kurz ein und verschafft sich einen Überblick, die meisten Bugs kann man damit erschlagen.
Nö, das eben nicht, Siehe oben.
Wenn ich an einem Programm für z.B. Elektroniklayout einen Bug fixen möchte, dann muß ich weder die VDE Vorschriften noch die Pin-Abstände von diversen ICs wissen, möglicherweise brauche ich nichtmal ein tieferes Verständnis in der Elektrotechnik, denn dieses Wissen brauche ich nur dann, wenn ich neue Features in die Software einarbeiten will und nicht zum Fixen eines Bugs.
Das fixen von Bugs ist in 99 % der Fälle nur das Fixen von Programmierfehlern, also der Programmierung an sich und alles was damit zu tun hat. Im prinzip also die Grundlagen, die Grundbausteine und Algorithmen.
Ne, eben nicht.
Wenn ich an einer Schaltungssimulation für Elektronik neue Features einbauen will, dann brauche ich in den meisten Fällen ein tieferes Verständnis in der Elektrotechnik.
Bei Programmen für die Medizin wird das nicht anders sein, was meinst denn du, warum es in der Informatik extra Studiengänge wie Wirtschafts-, Medizin- oder Bioinformatik gibt?
Das erschaffen von völlig neuen Features erfordert also wesentlich mehr Hintergrundwissen, als für das reine fixen von Bugs.
Für das fixen von Bugs reicht reines Programmiererwissen.
Offenbar kennst du den Unterschied zwischen einem Elektriker und einem Elektroniker nicht.
Deine Hausverkabelung ist Elektrik.
Das TV Gerät ist reine Elektronik.
Und die Waschmaschine wohl so ein Zwischending zwischen Elektronik und Mechatronic.
Glaubst du allen Ernstes, dass zum Beispiel die Probleme bei Akonadi oder Nepomuk (worüber dieser Thread ja ist) simple Programmierfehler sind? Ach wäre das schön wenn dem so wäre...
Glaubst du den Fehler den ich weiter oben beschrieb, war ein simpler Progammierfehler? Glaubst du allen Ernstes, dass man Fehler in Nepomuk beheben kann ohne Wissen von RDF? Oder Fehler in KWin ohne Wissen von Fenstermanagement und Compositing?
Wenn ja, dann bitte ich dich doch in die freie Software Entwicklung einzusteigen. Du scheinst ein Genie zu sein, wie ich es so noch nicht gesehen habe. Freue mich schon in Zukunft weniger Bugs zu haben
Und nun gehe ich erst mal einen Unit Test schreiben für einen Fehler den ich noch nicht ganz verstehe.
Hast Du Dich mal mit semantischen Technologien auseinander gesetzt? Ontologien, OWL, SPARQL? Es ließen sich sicherlich genügend Themenfelder finden, von denen Du keine oder wenig fundierte Ahnung hast - deswegen abzuleiten, dass jemand zu wenig Interesse an der Gesamtmaterie hat und nur das "nötigste" für seine Scheine getan hat, ist sagenhaft dümmlich! Als dermaßen vor Selbstwusstsein strotzendem Informatik-Gott , der gerne ex catedra redet und seine Meinung als Naturgesetz darstellt, hätte ich ein wenig mehr Intelligenz erwartet...
Ad "Elektroniker vs Elektriker": Du hast Recht, ich war da zu unpräzise. Offenbar ist der Oberbegriff der des Elektronikers - Elektriker ist da wohl eher Volksmund. Allerdings ändert das nichts an meinem Bild, denn offensichtlich bezeichnet man eben doch beide *Spezialisierungen* mit einem Begriff. Zudem bleibt das Ärzte Gleichnis immer noch so stehen, ohne dass Du es auch nur ansatzweise entkräften konntest
(Wie auch!?! Es stimmt eben 
)
Deine Weltsicht auf Bugs ist dermaßen eingeschränkt, dass ich immer noch denke, dass Du eher noch ein Student bist, der nur kleinere und kürzere Projekte realisiert hast. Bugs umfassen so viel mehr als simple Programmierfehler! Und genau das sind einfach diejenigen, deren Ursache sich nur *schwer* aufspüren und ggf. auch beheben lässt. Wer das auf "Man muss nur C++ kennen" reduziert, ist einfach nicht ernst zu nehmen.
Und nein, neue Features können sehr viel einfacher sein, als einen Bug zu fixen. Oftmals sind es Kompositionen von vorhandenen Komponenten; was muss ich da für ein tiefgreifendes Verständnis für die Software im Kern haben? Ich habe mir auch schon mal kleine Erweiterungen für Gimp geschrieben - meinst Du ernsthaft, dass ich mir dafür Wissen um den Code von Gimp oder Grafikverarbeitung i.A. hätte aneignen müssen? Gleiches gilt für Scribus, dort sogar *direkt* im Code, den ich um eine Funktion in der Python-API erweitert habe. Dank Doku zur API muss man sich nur die Funktionen zusammenstellen, die man benötigt... alles viel trivialer, als einen Programmfehler auszumerzen.
Natürlich können neue Funktionen auch sehr schwierig zu implementieren sein! Aber im Gegensatz zu Bugs besteht hierbei die *Möglichkeit*, dass das einfach funktioniert.