Ein Troll, der behauptet, mit VisualStudio als integrierter Entwicklungsumgebung und C# als Programmiersprache lassen sich leichter GUI-Programme für Windows schreiben, als mit Python, insbesondere wenn man sie ohne kompliziertes Setup weitergeben möchte, ist zwar immer noch ein Troll, kann aber dennoch recht haben.
Natürlich kann man darauf hinweisen, dass ich mit VisualStudio unter Linux oder OS/X nichts werden kann, das mir Windows egal ist, dann ich für eine plattformübergreifende GUI-Lösung auch zu Kompromissen bereit bin, aber das greift den Kern der Aussage nicht an.
Was sie noch am stärken angreift, IMHO, ist der die eigene Seriosität untergrabende überschwängliche Gebrauch von Smilies, die auch über eine pampige Art zu diskutieren nicht hinwegtäuschen, oder der Versuch, absichtlich falsch aus "A < C" und "B < C" ein "A = B" ("Ich bin Napoleon") ableiten wollen - was offensichtlich nur dann funktioniert, wenn |C| = 1 gilt.
Ist C# die bessere Programmiersprache? Zumindest C# könnte man ja dank Mono auch auf anderen Plattformen einsetzen und ich meine, dort gibt es auch Gtk# (neben dem wohl abgebrochenen Versuch, WinForms zu portieren) als GUI-Bibliothek. Ansonsten geht ja die neue Mono-Firma von Miguel den Weg, lieber für Android, iOS und Mac OS spezielle C#-Bindings anzubieten, weil sie daran glauben, dass C# die überlegene Sprache ist.
C# zusammen mit VS bildet jedenfalls eine Einheit, die auf jahrelanger Erfahrung mit VisualBasic und Delphi als RAD-Tools (also Werkzeugen zur schnellen Entwicklung typischer datenbank-zentrischer Desktop-Anwendungen) aufbauen kann und da schon ziemlich das beste ist, was man so bekommen kann. Irgendwann will ich auch noch mal den MonoDeveloper ausprobieren - mal gucken, wie weit sie da gekommen sind.
Ich denke nicht, dass Python + Editor + GUI-Bibliothek der Wahl (und sei es Qt und seinem GUI-Builder) da heran kommen. Dafür ist die Einarbeitungszeit in C# auch deutlich höher und natürlich auch in die Windows-Bibliotheken, wo man sich ja erst mal entscheiden muss, ob man noch den WinForms-Weg geht oder auf WPF mit XAML setzt oder gleich auf Metro.
Ich denke, Python ist für den Anfänger, Hobbyisten und Amateur (im Sinne einer Person, die es einfach ohne zwingenden Grund liebt, etwas zu tun, nicht in dem Sinne, dass sie keine Ahnung hat) die bessere Wahl als C#. C# zielt IMHO eher auf die Profi-Liga, Leute, die Software bauen müssen, egal ob sie es lieben oder nicht. Denen sind andere Dinge wichtig, als vielleicht die Eleganz einer Sprache oder die korrekte politische Aussage. Sie wollen einfach so schnell wie möglich fertig sein. Das kann eine gute Einstellung sein oder eine sehr fatale, doch das ist eine ganz andere Diskiussion.
Statt WinForms und C# könnte man übrigens auch Swing und Java sagen, das ist ungefähr der gleiche Stand der Technik, nur waren die GUI-Builder für Swing nie so gut wie die für VisualBasic (was hauptsächlich daran lang, dass Swing "komische" Layout-Manager benutzt und offenbar niemand bei NextStep richtig abgeguckt hat) und da Java schlechter an diese Art der Software-Entwicklung angepasst ist, als C# (ich sage nur Properties und Events), ist es da ein bisschen aufwendiger.
XAML war der (ehrenwerte) Versuch von Microsoft, einen flexibleren und damit mächtigeren Ansatz der GUI-Entwicklung zu fahren. Einfach die Technologie der frühen 80er ein bisschen zu modernisieren. Da wurde der ganze Kram nämlich erfunden und hat sich nur unwesentlich weiterentwickelt.
Im übrigen hat Flex einen sehr ähnlichen Ansatz verfolgt (oder verfolgt ihn noch, was ich nicht weiß, weil ich gerade nicht verfolge, wie es Flex gerade so geht). Flex und XAML haben neben einer Möglichkeit GUIs flexibel und deklarativ zu bauen, insbesondere insbesondere beide die Möglichkeit, Attribute von Modellen automatisch an GUI-Elemente zu binden, sodass MVC wirklich so funktioniert, wie ursprünglich gedacht (und wie Smalltalk es Anfang/Mitte der 90er konnte). Unter flexibel verstehe ich übrigens die konsequente Anwendung des Kompositum-Patterns, wo UIs aus Elementen zusammengesetzt sind, die wieder aus anderen Elementen bestehen. Eine Liste oder Button hat nicht einfach einen String als Label bzw. Zeilentext, sondern wieder ein Element, z.B. ein Label, oder ein Image oder aber auch beliebig komplexe Elemente. Dafür war Mitte der 90er der Computer noch zu langsam (was Smalltalk nicht abgehalten hat, diesen Ansatz dennoch zu fahren, wodurch auch der Ruf zustande kam, es sei langsam), aber aber heutzutage kein Problem ist. iOS und Android folgen ebenfalls diesen Ansatz (und Android 2.x ist wieder zu langsam), allerdings nicht immer ganz so konsequent wie Flex oder WPF - eine horizontal scrollende Tabelle statt der normalen vertikal scrollenden ist z.B. bei iOS ein echter Akt, der nicht hätte sein müssen, finde ich.
Tk und Wx wirken dagegen jedenfalls antiquiert und unflexibel, weil sie auf dem Modell von Motif oder dem alten Win32-API aufbauen, was IMHO nicht mehr zeitgemäß ist. Zu Qt kann ich leider keine fundierte Aussage treffen, das kenne ich nicht gut genug.
Nach dieser langen Vorrede kann ich also durchaus nachvollziehen, wenn man Tk und Wx zusammen mit Python als veraltet ansieht. Hinzu kommt das schwerer zu verstehende Handling von Unicode von Python 2 und das eine oder andere archaische Konstrukt und die Notwendigkeit, bei Python ganz klassisch die Bibliothek auswendig zu lernen, wenn man damit flüssig arbeiten will, statt sich bei VisualStudio und C# jeden API-Call inklusive ausführlicher Dokumentation per IntelliSense vorbeten zu lassen und "educated guessing" zu betreiben.
Zu Pyobjc und Cocoa (die GUI-Bibliothek von OS/X) kann ich übrigens sagen, dass das IMHO "worst of both worlds" ist. Da wird die Eleganz des Smalltalk-artigen Objective-C-APIs in durch Unterstriche getrennte Python-Wortmonster mutiert, man muss sich um die Speicherverwaltung mit init, alloc und release kümmern und dennoch immer Objective-C-Code lesen, um die Dokumentation zu verstehen. Debuggen geht auch nicht wirklich.
Auch Cocoa, das ja nun schon fast 20 Jahre alt ist, wenn man erkennt, dass das fast unverändert NextStep ist, hat einiges an "cruft" angesetzt, dennoch mag zumindest ich Objective-C und für iOS mit CocoaTouch, welches eine ganze Ecke moderner und flexibler ist (da es auf CoreAnimation aufbaut) und wo man seit Xcode 4.2 und LLVM 3.0 nun auch die Bürde der manuellen Speicherverwaltung zu 99% losgeworden ist, macht einfach Spaß.
Außer man will z.B. mit regulären Ausdrücken mal in wenigen Zeilen (wenige Zeilen geht nie) etwas parsen oder hat auf einmal eine Funktion doch nur als C-API und muss da dann wieder eine Welt der Pointer-Schmerzen betreten. Die Klassenbibliotheken Foundation und CocoaTouch gehören jedenfalls die besten, die mir in meinen 20 Jahren Software-Entwicklungserfahrung bislang untergekommen sind. Man darf sich allerdings nicht an doch recht langen Konstrukten wie "[NSString stringWithContentOfURL:[NSURL URLWithString:@"..."]]" stören, und muss auch akzeptiert haben, dass durch das C Erbe einiges ein bisschen archaisch wirkt - gleichzeitig ist es mir zumindest dadurch aber auch wieder vertraut
Ach noch was: Häufig liegt übrigens ein Vorteil darin, dass man nicht wählen kann und damit auch nicht wählen muss. Bei Windows ist es einfach immer VisualStudio, bei OS/X immer Xcode und ähnliches gilt auch für die Bibliotheken. Nicht wie bei Python, wo einem Neuling dann gleich erst mal 10 Vorschläge für Editoren oder GUI-Rahmenwerke unterbreitet werden, die dann eh immer in eine Diskussion "vi" vs. "emacs" o.ä. abgleiten. Die Qual der Wahl hat schon etwas Wahres.
Das Microsoft mit Windows 8 und "Metro Style Apps" für Desktop, Tablet und Phone ausschließlich oder auch nur als Schwerpunkt auf JavaScript setzt, halte ich für ein Missverständnis. Ja, es geht jetzt auch und das ist gut so, denn es öffnet einer großen Gemeinde von Web-Entwicklern (von denen viele gerade genug programmieren können, um kleinere Änderungen an JQuery-Plugins vornehmen zu können) eine neue Plattform und Microsoft braucht diese dringend, damit sie noch einen Fuß in der Tablet und Mobile-Welt fassen können, bevor der Markt zwischen iOS und Android aufgeteilt ist.
Doch JavaScript ist einfach nicht die Sprache, mit der man größere Projekte stemmen will. IMHO. Der Ansatz von Google mit Dart ist da eigentlich schon richtig (wenn auch die Sprache total langweilig ist) und es ist schade, dass Dart aus politischen Gründen und nicht aus technischen bis aufs Blut bekämpft wird - auch von Microsoft.
Und selbst wenn Microsoft jetzt sagt, du kannst JS und HTML und CSS und so weiter benutzen, musst du es nicht bei Wasser und Brot, spricht im Texteditor machen, denn sie bieten ausgezeichnete Werkzeuge, namentlich Expression Blend und eben VisualStudio, mit denen man grafisch das Metro-UI entwerfen kann und dann in gewohnter VisualBasic-Manier hier und da mal ein par Zeilen Code für einen Event-Listener einfügt, der dann im wesentlichen eine Bibliotheksfunktion aufruft. Zusammen mit einer mächtigen Bibliothek macht das die Programmierung einfach und schnell - und natürlich 100% Windows-spezifisch, was ja auch im Interesse von Microsoft ist.
Nicht ohne Grund ist Metro so total anders, dass man nicht einfach mal sein vorhandenes Android- oder iOS-Programm nehmen und dafür neu bauen kann. Also muss man's nativ für Metro bauen und überlegt sich danach dann vielleicht zweimal, man wirklich noch andere Plattformen unterstützen will. Und irgendwann ist dann Metro die dominierende Plattform, weil eben einheitlich auf Xbox, dem Telefon, dem Tablet, im Auto, auf dem Fernseher und meinetwegen auch im intelligenten Kühlschrank, das Microsoft es dann ein zweites mal geschafft hat.
Stefan