Sehe ich genauso. Gerade Inkscape and Gimp benötigen dringend mehr Entwickler.
Gut, die Sprache C mag nicht jedermans Sache sein, aber im Endeffekt ist ein 1-Mann Projekt dieser Größe einfach nur verschwendete Arbeitszeit. Würde mich wundern, wenn er es schafft mehr Entwickler zusammenzutrommeln als das Inkscape-Projekt.
Gut, die Sprache C mag nicht jedermans Sache sein, aber im Endeffekt ist ein 1-Mann Projekt dieser Größe einfach nur verschwendete Arbeitszeit. Würde mich wundern, wenn er es schafft mehr Entwickler zusammenzutrommeln als das Inkscape-Projekt.
Es ist seine Freizeit. Und mich würde es nicht wundern, wenn er es schafft, mehr Entwickler als Inkscape zusammenzutrommeln. Die Welt besteht nicht nur aus Linux. Unter Windows sind die Leute komfortable Sprachen, Toolkits und IDEs gewohnt und da hat niemand Lust, mit C und gtk zu programmieren. Außerdem integriert sich gimp unter Windows absolut nicht. Inkscape hab ich nicht probiert, aber wahrscheinlich integriert es sich genauso schlecht. Arbeit in Gimp und Inkscape zu stecken, ist meiner Meinung nach einfach Verschwendung, lieber eine saubere, neue Code-Base mit der Leute auch arbeiten wollen.
Sicher, ich gönn ihm den Spass ja. Es tut mir nur im Herzen weh, wenn man sich die Liste der gescheiterten Projekte anschaut, auf die er vermutlich landen wird.
Und mich würde es nicht wundern, wenn er es schafft, mehr Entwickler als Inkscape zusammenzutrommeln.
Mich schon.
Die Welt besteht nicht nur aus Linux.
Bei solchen OpenSource Projekten hauptsächlich schon. Sehen wir doch mal der Realität ins Auge. Unter Windows verwenden nur Idealisten Open Source Software. Der Rest verwendet Raubkopien bzw. die Firmen können die Investitionen für Software von der Steuer absetzen.
Unter Windows sind die Leute komfortable Sprachen, Toolkits und IDEs gewohnt und da hat niemand Lust, mit C und gtk zu programmieren.
Geb ich dir Recht. Meiner Meinung nach ist C/C++ ein Relikt aus dem letzten Jahrtausend. Natürlich gibt es Gründe, warum man manche Projekte in C/C++ schreiben muss/sollte. Die Masse der Standardsoftware wäre aber mit Java/.NET besser bedient.
Insofern hat er wenigstens eine Programmiersprache gewählt, die es ihm erlaubt sich auf die Logik zu konzentrieren und nicht auf die Suche nach Bugs in der Speicherverwaltung. Trotzdem gebe ich dem Projekt unterm Strich nicht viele Chancen.
Außerdem integriert sich gimp unter Windows absolut nicht. Inkscape hab ich nicht probiert, aber wahrscheinlich integriert es sich genauso schlecht.
Wie gesagt, die Masse seiner Benutzer und damit auch Entwickler wird aus dem Linux Umfeld kommen. Unter Windows/Mac gibt es bessere Alternativen, die entweder von der Steuer abgesetzt oder eben raubkopiert werden.
Arbeit in Gimp und Inkscape zu stecken, ist meiner Meinung nach einfach Verschwendung, lieber eine saubere, neue Code-Base mit der Leute auch arbeiten wollen.
Die ganze Arbeitszeit, die in GIMP/Inkscape geflossen ist, muss er erstmal wieder aufholen. Eine saubere Codebasis nützt nichts, wenn man niemanden findet der hilft - nicht bei einem Projekt dieser Grösse.
Ja, Gtk+ in C ist... halt C. Vala ist schön aber ich bemängle daran z.B. das Exception Handling. Zumal Vala C kompatibel bleiben muss weil es nach C kompiliert, kann es keine echten Exceptions haben sondern nur welche per output Parameter. D.h. man muss einen conditional branch über diesen output Parameter einbauen um zu prüfen ob ein Fehler passiert ist. Man könnte aber Exceptions so zu Binärcode/Assembler kompilieren, das nur im Fehlerfall, aber nicht im Normalfall, ein Overhead entsteht.
Ok, der Overhead mag nicht groß sein, aber in so Sachen bin ich ein wenig ein Purist. Heutzutage ist das Problem mit Exceptions schon gelöst, da wirkt so eine Sprache wie Vala schon ziemlich veraltet (in diesen einen Punkt; mag mich da in was Unwichtigen verbeißen).
Welche Funktionen werfen denn Exceptions? Funktionen, die IO betreiben, auf Dateien zugreifen, übers Netzwerk oder einen Message Bus kommunizieren, auf die Datenbank zugreifen. Du willst mir doch nicht erzählen, dass dort eine einzige (!) Przessorinstruktion (JNZ) auch nur irgendwie ins Gewicht fällt, während andere "hippe" und dynamische Programmiersprachen pro Methodenaufruf einen String-Lookup oder ähnliches machen?
Ich glaube du möchtest echt nicht wissen, was bei anderen Programmiersprachen alles unter der Haube passiert. Du könntest wahrscheinlich gar keine mehr benutzen
Naja ich hab ja nix davon, das in Vala das Exception Handling so funktioniert. Das Python/Ruby/JavaScript dynamisch sind, davon hat man sogar sehr viel. Wobei der Ansatz von RPython wohl ein sehr intelligenter ist.
Nicht schlecht nur unbrauchbar weil man bei Problemen und zum debugging wieder runter in das GTK-Gefrikel muss. Ne, dann lieber gleich das .NET-Original.
Auch nicht jeder hat Lust in Java zu entwickeln. Gerade Leute, die Grafikentwicklung betreiben sind kaum im Java-Umfeld anzutreffen, sondern im C und C++ Umfeld. Und Java-Programme werden ab einer bestimmten Größe wirklich fett und träge, nicht nur ein bißchen. Entwickler, die ihren eigenen Komfort über den Komfort ihrer Anwender stellen, finden bei mir kein Verständnis. Übrigens ist die Code-Basis von GIMP keineswegs "unsauber". Ich hab es mir mal angeschaut, und das ist extrem sauberer GObject/C Code, nach den Regeln dieser Kunst. Unsauber wäre es, wenn das Softwaredesign der Komponenten und Datenstrukturen nicht stimmen würde, der Code nicht gut strukturiert und wie Kraut und Rüben formatiert wäre, die Concerns nicht separiert, oder wenn der Speicher fehlerhaft verwaltet würde. Unsauber ist nicht damit gleichzusetzen, dass die verwendete Programmiersprache etwas wordier ist.
Auch nicht jeder hat Lust in Java zu entwickeln. Gerade Leute, die Grafikentwicklung betreiben sind kaum im Java-Umfeld anzutreffen, sondern im C und C++ Umfeld.
Einer der besten Ray-Tracer ist in Java geschrieben: http://sunflow.sourceforge.net/. Mein Kollege meint, der wäre deutlich besser als POVray. Wenn man einen Raytracer in Java schreiben kann, warum soll man dann kein Vektor-Zeichenprogramm in Java schreiben können. Und nicht jeder im Grafikbereich arbeitet mit C und C++, weil er die Sprachen so toll findet.
Und Java-Programme werden ab einer bestimmten Größe wirklich fett und träge, nicht nur ein bißchen.
Ich habe ein 100.000 Zeilen Java-Programm geschrieben, das sehr schnell ist. Warum sollten Java-Programme ab einer bestimmten Größe fett und träge werden?
Entwickler, die ihren eigenen Komfort über den Komfort ihrer Anwender stellen, finden bei mir kein Verständnis.
Du hast also kein Verständnis für Leute, die in ihrer Freizeit etwas tun wollen, was sie als angenehm empfinden? Außerdem müssen Programme auch nicht angenehmer für den Benutzer sein, wenn sie in C und gtk geschrieben sind, als wenn sie in Java geschrieben sind. Siehe gimp.
Übrigens ist die Code-Basis von GIMP keineswegs "unsauber". Ich hab es mir mal angeschaut, und das ist extrem sauberer GObject/C Code, nach den Regeln dieser Kunst.
Ich habe mir größere Teile des Codes durchgelesen und wenn du den Code als sauber empfindest, möchte ich nicht wissen, wie bei Dir unsauberer Code ausschaut. Objektorientiertes Programmieren in C ist einfach nur grottenhäßlich.
Unsauber wäre es, wenn das Softwaredesign der Komponenten und Datenstrukturen nicht stimmen würde, der Code nicht gut strukturiert und wie Kraut und Rüben formatiert wäre, die Concerns nicht separiert, oder wenn der Speicher fehlerhaft verwaltet würde. Unsauber ist nicht damit gleichzusetzen, dass die verwendete Programmiersprache etwas wordier ist.
Sorry, aber C ist einfach nicht für objektorientierte Programmierung geeignet, genauso wenig wie es sinnvoll ist, funktionale Programme in C++ zu schreiben. Natürlich geht das, aber der Code der dabei rauskommt ist einfach grottenhäßlich. Und ich denke, langfristig profitieren auch die User von sauberen, wartbaren Code, weil dadurch die Qualität der Appliktionen einfach steigt.
Ich habe mir größere Teile des Codes durchgelesen und wenn du den Code als sauber empfindest, möchte ich nicht wissen, wie bei Dir unsauberer Code ausschaut.
Objektorientiertes Programmieren in C ist einfach nur grottenhäßlich.
Was hat die gefühlte Bequemlichkeit, die syntaktische Optik oder Wordiness der verwendeten Programmiersprache mit _unsauberem_ Code zu tun? Genau, NICHTS. Lern erstmal das zu unterscheiden. Und bei dem GIMP-Sourcecode sieht man sofort, dass er von Entwicklern entwickelt ist, die genau wissen was sie tun.
Wenn man einen Raytracer in Java schreiben kann, warum soll man dann kein Vektor-Zeichenprogramm in Java schreiben können.
Das zeigt das du davon nicht viel verstehst. Raytracer müssen nicht performante Echtzeitgraphik anzeigen. Sie müssen nicht auf Graphikhardware zugreifen. Die Berechnungen eines Raytracers eignen sich gut für eine CPU. Ok, in den letzten Jahren hat sich mit den Graphikkarten einiges getan und mit GPGPU könnte man auch in Raytracern die Performance steigern. Aber die hinken da halt hinten nach, weil bis jetzt sich die Raytracer-Entwickler keine Gedanken um Graphikhardware machen mussten und somit sogar so Sprachen wie Java verwenden konnten.
Und was heißt überhaupt Sunflow ist "besser" als Povray? Es kann gut sein das es bessere Bilder liefert, aber wie lange braucht es dafür? Selbst wenn es bei der selben Bildqualität weniger lang benötigt oder bei der selben Länge ein besseres Bild liefert, dann würde es nur zeigen, dass die Sunflow Programmierer besser sind als die Povray Programmierer (und nicht, dass Java besser/genauso gut geeignet für Raytracer ist als Java).
Einer der besten Ray-Tracer ist in Java geschrieben: http://sunflow.sourceforge.net/. Mein Kollege meint, der wäre deutlich besser als POVray. Wenn man einen Raytracer in Java schreiben kann, warum soll man dann kein Vektor-Zeichenprogramm in Java schreiben können. Und nicht jeder im Grafikbereich arbeitet mit C und C++, weil er die Sprachen so toll findet.
So und ab hier wirds für dich zu einer Blamage, der Entwickler hat aufgrund der vielen Beschwerden über die Geschwindigkeit angekündigt Teile der Engine in C++ zu implementieren.
Meine Meinung zu diesen neusprachlichen Trollen ist:
man mosert an C C++ rum, weil man es nie richtig gelernt hat und keine Ahnung davon hat. Jemand der schon 10 Jahre professionell in C++ entwickelt wird mit jedem Problem fertig werden. Wer schon in internationalen Projekten gearbeitet hat wird auch genügend gute Tricks gelernt haben um ein Anwendung so zu entwickeln, das sie erweiterbar und zukunftsfähig ist.
Klar bietet sich bei vielen Projekten eine neue Sprache an, aber auch nur dann wenn man auch die Ahnung davon hat und genügend fähige Mitstreiter findet. Genauso gut gibts aber auch Projekte z.B. in PHP oder C# bei denen ein Haufen Anfänger rumfrickelt und dabei bei jedem Release ihre Schnittstellen ändern, weil sie von Anfang an falsch an das Projekt herangegangen sind.
Ne "One Man Show" bei der Größe eines Inkscape oder Gimp wird nie klappen, es sei denn er findet bald viele Interessierte. Für solche Projekte ist die Sprache relativ egal, hier benötigt man von Anfang an "Anwender", erfahrene Analytiker und Leute die was von Softwaredesign verstehen. Gerade im kommerziellen Bereich wird soviel Müll produziert, weil man Firma xy beauftragt, die keine Ahnung von der Materie haben, es keine ausreichende Kommunikation mit den Anwendern gibt. Da wird nur nach Lastenheft und Präferenz des Entwicklers gearbeitet.
Sehe ich genauso. Gerade Inkscape and Gimp benötigen dringend mehr Entwickler.
Gut, die Sprache C mag nicht jedermans Sache sein, aber im Endeffekt ist ein 1-Mann Projekt dieser Größe einfach nur verschwendete Arbeitszeit. Würde mich wundern, wenn er es schafft mehr Entwickler zusammenzutrommeln als das Inkscape-Projekt.
Gut, die Sprache C mag nicht jedermans Sache sein, aber im Endeffekt ist ein 1-Mann Projekt dieser Größe einfach nur verschwendete Arbeitszeit. Würde mich wundern, wenn er es schafft mehr Entwickler zusammenzutrommeln als das Inkscape-Projekt.
Es ist seine Freizeit. Und mich würde es nicht wundern, wenn er es schafft, mehr Entwickler als Inkscape zusammenzutrommeln. Die Welt besteht nicht nur aus Linux. Unter Windows sind die Leute komfortable Sprachen, Toolkits und IDEs gewohnt und da hat niemand Lust, mit C und gtk zu programmieren. Außerdem integriert sich gimp unter Windows absolut nicht. Inkscape hab ich nicht probiert, aber wahrscheinlich integriert es sich genauso schlecht. Arbeit in Gimp und Inkscape zu stecken, ist meiner Meinung nach einfach Verschwendung, lieber eine saubere, neue Code-Base mit der Leute auch arbeiten wollen.
Sicher, ich gönn ihm den Spass ja. Es tut mir nur im Herzen weh, wenn man sich die Liste der gescheiterten Projekte anschaut, auf die er vermutlich landen wird.
Mich schon.
Bei solchen OpenSource Projekten hauptsächlich schon. Sehen wir doch mal der Realität ins Auge. Unter Windows verwenden nur Idealisten Open Source Software. Der Rest verwendet Raubkopien bzw. die Firmen können die Investitionen für Software von der Steuer absetzen.
Geb ich dir Recht. Meiner Meinung nach ist C/C++ ein Relikt aus dem letzten Jahrtausend. Natürlich gibt es Gründe, warum man manche Projekte in C/C++ schreiben muss/sollte. Die Masse der Standardsoftware wäre aber mit Java/.NET besser bedient.
Insofern hat er wenigstens eine Programmiersprache gewählt, die es ihm erlaubt sich auf die Logik zu konzentrieren und nicht auf die Suche nach Bugs in der Speicherverwaltung. Trotzdem gebe ich dem Projekt unterm Strich nicht viele Chancen.
Wie gesagt, die Masse seiner Benutzer und damit auch Entwickler wird aus dem Linux Umfeld kommen. Unter Windows/Mac gibt es bessere Alternativen, die entweder von der Steuer abgesetzt oder eben raubkopiert werden.
Die ganze Arbeitszeit, die in GIMP/Inkscape geflossen ist, muss er erstmal wieder aufholen. Eine saubere Codebasis nützt nichts, wenn man niemanden findet der hilft - nicht bei einem Projekt dieser Grösse.
> Unter Windows sind die Leute komfortable Sprachen, Toolkits und IDEs
> gewohnt und da hat niemand Lust, mit C und gtk zu programmieren.
Das gilt auch für Linux. Das GTK-Gefrikel jagt einem kalte Schauer über den Rücken.
So schlecht ist Vala nicht.
Ja, Gtk+ in C ist... halt C. Vala ist schön aber ich bemängle daran z.B. das Exception Handling. Zumal Vala C kompatibel bleiben muss weil es nach C kompiliert, kann es keine echten Exceptions haben sondern nur welche per output Parameter. D.h. man muss einen conditional branch über diesen output Parameter einbauen um zu prüfen ob ein Fehler passiert ist. Man könnte aber Exceptions so zu Binärcode/Assembler kompilieren, das nur im Fehlerfall, aber nicht im Normalfall, ein Overhead entsteht.
Ok, der Overhead mag nicht groß sein, aber in so Sachen bin ich ein wenig ein Purist. Heutzutage ist das Problem mit Exceptions schon gelöst, da wirkt so eine Sprache wie Vala schon ziemlich veraltet (in diesen einen Punkt; mag mich da in was Unwichtigen verbeißen).
Welche Funktionen werfen denn Exceptions? Funktionen, die IO betreiben, auf Dateien zugreifen, übers Netzwerk oder einen Message Bus kommunizieren, auf die Datenbank zugreifen. Du willst mir doch nicht erzählen, dass dort eine einzige (!) Przessorinstruktion (JNZ) auch nur irgendwie ins Gewicht fällt, während andere "hippe" und dynamische Programmiersprachen pro Methodenaufruf einen String-Lookup oder ähnliches machen?
Stimmt wahrscheinlich eh, trotzdem finde ich's unschön.
Ich glaube du möchtest echt nicht wissen, was bei anderen Programmiersprachen alles unter der Haube passiert. Du könntest wahrscheinlich gar keine mehr benutzen
Naja ich hab ja nix davon, das in Vala das Exception Handling so funktioniert. Das Python/Ruby/JavaScript dynamisch sind, davon hat man sogar sehr viel. Wobei der Ansatz von RPython wohl ein sehr intelligenter ist.
Nicht schlecht nur unbrauchbar weil man bei Problemen und zum debugging wieder runter in das GTK-Gefrikel muss. Ne, dann lieber gleich das .NET-Original.
Debugge erstmal deine Orthographie.
Wenn du uns jetzt noch erklären kannst, warum .NET das Original zu GTK+, wären wir dir dankbar. Ach... du bist bloß ein Troll? Sowas.
Denke er bezieht sich damit auf Vala und hat damit nicht gänzlich unrecht.
Ich hasse WinForms, ich hasse es, ich hasse es, ich hasse es.
Gtk/Swing/QT ist mir da viel lieber.
Auch nicht jeder hat Lust in Java zu entwickeln. Gerade Leute, die Grafikentwicklung betreiben sind kaum im Java-Umfeld anzutreffen, sondern im C und C++ Umfeld. Und Java-Programme werden ab einer bestimmten Größe wirklich fett und träge, nicht nur ein bißchen. Entwickler, die ihren eigenen Komfort über den Komfort ihrer Anwender stellen, finden bei mir kein Verständnis. Übrigens ist die Code-Basis von GIMP keineswegs "unsauber". Ich hab es mir mal angeschaut, und das ist extrem sauberer GObject/C Code, nach den Regeln dieser Kunst. Unsauber wäre es, wenn das Softwaredesign der Komponenten und Datenstrukturen nicht stimmen würde, der Code nicht gut strukturiert und wie Kraut und Rüben formatiert wäre, die Concerns nicht separiert, oder wenn der Speicher fehlerhaft verwaltet würde. Unsauber ist nicht damit gleichzusetzen, dass die verwendete Programmiersprache etwas wordier ist.
Auch nicht jeder hat Lust in Java zu entwickeln. Gerade Leute, die Grafikentwicklung betreiben sind kaum im Java-Umfeld anzutreffen, sondern im C und C++ Umfeld.
Einer der besten Ray-Tracer ist in Java geschrieben: http://sunflow.sourceforge.net/. Mein Kollege meint, der wäre deutlich besser als POVray. Wenn man einen Raytracer in Java schreiben kann, warum soll man dann kein Vektor-Zeichenprogramm in Java schreiben können. Und nicht jeder im Grafikbereich arbeitet mit C und C++, weil er die Sprachen so toll findet.
Und Java-Programme werden ab einer bestimmten Größe wirklich fett und träge, nicht nur ein bißchen.
Ich habe ein 100.000 Zeilen Java-Programm geschrieben, das sehr schnell ist. Warum sollten Java-Programme ab einer bestimmten Größe fett und träge werden?
Entwickler, die ihren eigenen Komfort über den Komfort ihrer Anwender stellen, finden bei mir kein Verständnis.
Du hast also kein Verständnis für Leute, die in ihrer Freizeit etwas tun wollen, was sie als angenehm empfinden? Außerdem müssen Programme auch nicht angenehmer für den Benutzer sein, wenn sie in C und gtk geschrieben sind, als wenn sie in Java geschrieben sind. Siehe gimp.
Übrigens ist die Code-Basis von GIMP keineswegs "unsauber". Ich hab es mir mal angeschaut, und das ist extrem sauberer GObject/C Code, nach den Regeln dieser Kunst.
Ich habe mir größere Teile des Codes durchgelesen und wenn du den Code als sauber empfindest, möchte ich nicht wissen, wie bei Dir unsauberer Code ausschaut. Objektorientiertes Programmieren in C ist einfach nur grottenhäßlich.
Unsauber wäre es, wenn das Softwaredesign der Komponenten und Datenstrukturen nicht stimmen würde, der Code nicht gut strukturiert und wie Kraut und Rüben formatiert wäre, die Concerns nicht separiert, oder wenn der Speicher fehlerhaft verwaltet würde. Unsauber ist nicht damit gleichzusetzen, dass die verwendete Programmiersprache etwas wordier ist.
Sorry, aber C ist einfach nicht für objektorientierte Programmierung geeignet, genauso wenig wie es sinnvoll ist, funktionale Programme in C++ zu schreiben. Natürlich geht das, aber der Code der dabei rauskommt ist einfach grottenhäßlich. Und ich denke, langfristig profitieren auch die User von sauberen, wartbaren Code, weil dadurch die Qualität der Appliktionen einfach steigt.
Bitte, hier ist das Repository, zeig mir eine wirklich unsaubere Stelle:
http://git.gnome.org/browse/gimp/tree/
Was hat die gefühlte Bequemlichkeit, die syntaktische Optik oder Wordiness der verwendeten Programmiersprache mit _unsauberem_ Code zu tun? Genau, NICHTS. Lern erstmal das zu unterscheiden. Und bei dem GIMP-Sourcecode sieht man sofort, dass er von Entwicklern entwickelt ist, die genau wissen was sie tun.
Wenn man einen Raytracer in Java schreiben kann, warum soll man dann kein Vektor-Zeichenprogramm in Java schreiben können.
Das zeigt das du davon nicht viel verstehst. Raytracer müssen nicht performante Echtzeitgraphik anzeigen. Sie müssen nicht auf Graphikhardware zugreifen. Die Berechnungen eines Raytracers eignen sich gut für eine CPU. Ok, in den letzten Jahren hat sich mit den Graphikkarten einiges getan und mit GPGPU könnte man auch in Raytracern die Performance steigern. Aber die hinken da halt hinten nach, weil bis jetzt sich die Raytracer-Entwickler keine Gedanken um Graphikhardware machen mussten und somit sogar so Sprachen wie Java verwenden konnten.
Und was heißt überhaupt Sunflow ist "besser" als Povray? Es kann gut sein das es bessere Bilder liefert, aber wie lange braucht es dafür? Selbst wenn es bei der selben Bildqualität weniger lang benötigt oder bei der selben Länge ein besseres Bild liefert, dann würde es nur zeigen, dass die Sunflow Programmierer besser sind als die Povray Programmierer (und nicht, dass Java besser/genauso gut geeignet für Raytracer ist als Java).
Davon abgesehen: Warum soll POVRay so toll sein?
...genauso wenig wie es sinnvoll ist, funktionale Programme in C++ zu schreiben...
http://www.ibm.com/developerworks/aix/library/au-learningfc/index.html?ca=dgr-lnxw07FCPPdth-AIX
Das beweist, dass es möglich ist. Sinnvoll ist es deswegen nicht unbedingt.
Einer der besten Ray-Tracer ist in Java geschrieben: http://sunflow.sourceforge.net/. Mein Kollege meint, der wäre deutlich besser als POVray. Wenn man einen Raytracer in Java schreiben kann, warum soll man dann kein Vektor-Zeichenprogramm in Java schreiben können. Und nicht jeder im Grafikbereich arbeitet mit C und C++, weil er die Sprachen so toll findet.
So und ab hier wirds für dich zu einer Blamage, der Entwickler hat aufgrund der vielen Beschwerden über die Geschwindigkeit angekündigt Teile der Engine in C++ zu implementieren.
Meine Meinung zu diesen neusprachlichen Trollen ist:
man mosert an C C++ rum, weil man es nie richtig gelernt hat und keine Ahnung davon hat. Jemand der schon 10 Jahre professionell in C++ entwickelt wird mit jedem Problem fertig werden. Wer schon in internationalen Projekten gearbeitet hat wird auch genügend gute Tricks gelernt haben um ein Anwendung so zu entwickeln, das sie erweiterbar und zukunftsfähig ist.
Klar bietet sich bei vielen Projekten eine neue Sprache an, aber auch nur dann wenn man auch die Ahnung davon hat und genügend fähige Mitstreiter findet. Genauso gut gibts aber auch Projekte z.B. in PHP oder C# bei denen ein Haufen Anfänger rumfrickelt und dabei bei jedem Release ihre Schnittstellen ändern, weil sie von Anfang an falsch an das Projekt herangegangen sind.
Ne "One Man Show" bei der Größe eines Inkscape oder Gimp wird nie klappen, es sei denn er findet bald viele Interessierte. Für solche Projekte ist die Sprache relativ egal, hier benötigt man von Anfang an "Anwender", erfahrene Analytiker und Leute die was von Softwaredesign verstehen. Gerade im kommerziellen Bereich wird soviel Müll produziert, weil man Firma xy beauftragt, die keine Ahnung von der Materie haben, es keine ausreichende Kommunikation mit den Anwendern gibt. Da wird nur nach Lastenheft und Präferenz des Entwicklers gearbeitet.
Da es Vala und andere gute Sprachen, die GObject kapseln gibt, ist das mit C und GTK kein Argument.