@lunar
XAML ist auch noch weiterhin im Boot. Aber das neue Metro-Framework setzt daneben auf HTML5, CSS, JS und - man hoere und staune - auf COM. Soviel zur CLI...
Siehe zB hier (nix besonderes, nur aus dem Netz gefischt):
http://msdn.microsoft.com/en-us/library ... 11386.aspx
Natuerlich hat MS nicht einfach den "alten" Technologien komplett den Hahn abgedreht - aber die Vorzeichen stehen unguenstig, Silverlight laeuft ja zB auch aus.
Die hohe Kunst der Rhetorik
-
lunar
@deets: Interessant. Was COM angeht: Bist Du sicher, dass COM wirklich essentieller Teil dieses Frameworks wird, oder nicht einfach nur noch zur Anbindung an alte APIs und Bibliotheken angeboten wird. Ich kann mir wirklich gar nicht vorstellen, dass Microsoft COM nochmal aktiv nutzen möchte.
-
deets
@lunar
http://www.heise.de/developer/artikel/W ... 44071.html
Ich denke das Ziel ARM hat viel damit zu tun.
http://www.heise.de/developer/artikel/W ... 44071.html
Ich denke das Ziel ARM hat viel damit zu tun.
@deets
ok ich beweis euch jetzt dass ich napoleon bin: :DDDDD
dazu ist eine einfach mathematische gleichung nötig: A = B ; B = C ; C = A
Napoleon ist ein Mensch;
Ich bin ein Mensch
=> Napoleon ist ich :DDDD
Das war die Redekunst der Sophisten. Wer das nicht kennt , den bezeichne ich getrost mal als unwissend. Müsste jeder kennen, der sich ein bisschen für kultur etc. interessiert. Also
ok ich beweis euch jetzt dass ich napoleon bin: :DDDDD
dazu ist eine einfach mathematische gleichung nötig: A = B ; B = C ; C = A
Napoleon ist ein Mensch;
Ich bin ein Mensch
=> Napoleon ist ich :DDDD
Das war die Redekunst der Sophisten. Wer das nicht kennt , den bezeichne ich getrost mal als unwissend. Müsste jeder kennen, der sich ein bisschen für kultur etc. interessiert. Also
Und jetzt kommt der Softwareentwickler her und stellt fest, dass besagter Sophist == und isinstance() fälschlicherweise gleichsetzt.Newcomer hat geschrieben:A = B ; B = C ; C = A
Napoleon ist ein Mensch;
Ich bin ein Mensch
=> Napoleon ist ich :DDDD
Das war die Redekunst der Sophisten.
-
Leonidas
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Das ist ja mal totaler Quark. Gerade C# benötigt das .NET-Framework als Dependency und das ist ein vielfaches größer als der Python-interpreter und die jeweiligen Zusatzlibs die man so brauchen könnte. Letztendlich ist dein Argument: Weil ich das .NET-Framework ausgeführt habe, kann ich C#-EXE-Dateien starten. Analog dazu: weil ich den Python-Interpreter installiert habe, kann ich Python-PY-Dateien starten.Newcomer hat geschrieben:Tja also was ich bisher so bei meinen C# Codes gesehen habe, kann ich auch ohne Installation die exe datei starten.
Huch, in welcher Sprache wird empfohlen GUIs ohne Layout Management zu machen? Visual Basic 6, anno 1998, aber sonst? Und C hat in der "standard Lib" keine grafischen Oberflächen, was ist denn das für ein Vergleich?Newcomer hat geschrieben:weil es Zeit in Anspruch nimmt, die man lieber woanders reinstecken möchte als in die Integration eines Layout Managment. Naja jeder hat seine eigene Meinung. Die C Ecke sagt wieder was anderes als die Python Ecke genauso wie die Java Ecke usw. Ich denke C ist in der grafischen Oberflächenprogrammierung python weit überlegen ( Der Standart Lib wohlgemerkt)
Also reden klappt bei dir, aber am überzeugen solltest du noch arbeiten, weil bisher hast du uns eher überzeugt dass du kein bischen Ahnung hast. Außer das war jetzt deine Intention, na dann Gratulation, das ist dir gelungen.Newcomer hat geschrieben:Das ist nämlich Rhetorik, die fiese Kunst des Redens und Überzeugens, auch ohne ein bisschen Ahnung.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
-
deets
Du hast einen Term vergessen:Newcomer hat geschrieben:@deets
ok ich beweis euch jetzt dass ich napoleon bin: :DDDDD
dazu ist eine einfach mathematische gleichung nötig: A = B ; B = C ; C = A
Napoleon ist ein Mensch;
Ich bin ein Mensch
=> Napoleon ist ich :DDDD
Das war die Redekunst der Sophisten. Wer das nicht kennt , den bezeichne ich getrost mal als unwissend. Müsste jeder kennen, der sich ein bisschen für kultur etc. interessiert. Also
A = Vollpfosten
Schon hat die Gleichung Sinn!
Aber jetzt mal im Ernst: bei dir und der Rhetorik verhaelt es sich genau so, wie bei dir und dem Programmieren: du weisst, dass es in kundigen Haenden ein tolles Werkzeug ist.
Beherrschen tust du keines davon.
Nach wie vor bist du ein Argument dafuer schuldig, warum man in Python nicht gut GUI entwickeln kann. Dein "rhetorisches" Meister- bzw. Feuerwerk war doch als Ablenkung gedacht, bis dir dazu was einfaellt. Jetzt sind schon diverse Stunden vergangen - ist es langsam mal so weit?
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
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
-
deets
@sma
Interessanter Post. Der TL;DR davon - korrigiere mich wenn ich falsch liege - ist: Wer professionell unter Windows entwickelt, greift besser zu der MS-Toolchain, oder zumindest einer integrierten Umgebung wie Delphi.
So absolut steht das natuerlich schon mal alleine deswegen nicht fest, weil zB plattformunabhaengigkeit gewuenscht ist. Meine Firma muss zB OSX & Windows bedienen - und hat dazu ihr eigenes Toolkit entwickelt.
Aber selbst wenn wir das mal ausser Acht lassen, finde ich das Argument nicht schluessig. So ist allen modernen GUI-Toolkits gemein (ich rede jetzt hier von Qt, XAML & Cocoa), dass sie GUI-Deklaration streng trennen vom Code - durch ueblicherweise XML-Dateien, die dann irgendwie automatisch weiterverarbeitet werden, oder gleich Grundlage der GUI sind.
Ob ich nun aber in der IDE durch Doppelklick oder F-irgendwas in den Designer huepfe, oder ueber Alt-Tab - das ist fuer mich kein qualitativer Unterschied. Bleibt die Frage, ob Daten-Bindung (das Qt leider nicht kennt, dafuer aber ein ausgefeiltes Model-View-Konzept) und strengere Typisierung mit all ihren Komplexitaeten den Vorteil von Python als Sprache aufwiegt, in der ich viel flexibler bin.
Ich habe noch nicht mit C# und Visual Studio gearbeitet - aber gerade mal ein bisschen Tutorials geschaut. Die entscheidende Magie scheint ja nun schlicht, boilerplate fuer Event-Code zu generieren. Kenne ich noch von VB6, und Dingen wie Macromedia Director.
Und mich nervt sowas eher. Letztlich besteht das programmieren aus so viel mehr, als sich das bisschen Boilerplate zu sparen. Und falls mir nix entgangen ist, dann ist zB XCode + Interface Builder in dieser Beziehung aehnlich. Dort musst du auch deine actions selbst schreiben - erst dann erkennt der IB sie. Im dynamischen Python muss man das dann zweimal machen, einmal im IB, einmal in Python. Aber das kostet mich 20 Sekunden.
Langer Rede, kurzer Sinn: ja, Python kommt nicht mit so viel Umgebung wie eine Visuelle IDE. Und wer neu beginnt, mit dem Ziel, eine GUI-Anwendung zu schreiben, fuer den mag C# in VS die bessere Wahl sein.
Wer aber schon Python beherrscht, und jetzt eben GUI-Entwicklung betreiben will - und das war das Szenario des OP - dann kann man das, und man kann es IMHO kompetitiv. Auch professionnell - da moechte ich naemlich eigentlich keinen grossen Unterschied machen.
Das, was Python einem aufgrund der fehlenden Typdeklarationen nimmt, gleicht es durch flexibleres + ausdrucksstaerkeres Programmieren mehr als aus. Wenn ich das nicht so sehen wuerde - egal in welchem Kontext - dann wuerde ich es erst gar nicht verwenden.
Zu deinen PyObjc Bemerkungen kann ich nur sagen, dass wir da unterschiedlicher Ansicht sind - aesthetisch habe ich mit PyObjc keine Probleme, mir gehen die eckigen Klammern bei ObjC deutlich mehr auf den Zeiger (vor allem, weil ich dazu erstmal *vor* den Bezeichner muss, anstatt Methodenaufrufe einfach verketten zu koennen), und dein Debugging-Argument kann ich nicht nachvollziehen - bei mir funktioniert der pdb tadellos. Und auch das Speichermanagement ist einfacher, schliesslich wird GC verwandt (die jetzt ja wohl erst vernuenftig in ObjC laeuft). Aehnliches gilt fuer Exceptions.
Ich habe in PyObjc jedenfalls schon komplexere Anwendungen mit Anbindung von Dingen wie OpenCV und QTKit und so weiter gemacht, und war sehr zufrieden damit, nur das, was wirklich C/C++ sein musst, ueber ein ObjC-Framework, welches ich in PyObjc eingeladen habe, abhandeln zu koennnen. Und den ganzen Rest (zB jede Menge custom views) per Python.
Interessanter Post. Der TL;DR davon - korrigiere mich wenn ich falsch liege - ist: Wer professionell unter Windows entwickelt, greift besser zu der MS-Toolchain, oder zumindest einer integrierten Umgebung wie Delphi.
So absolut steht das natuerlich schon mal alleine deswegen nicht fest, weil zB plattformunabhaengigkeit gewuenscht ist. Meine Firma muss zB OSX & Windows bedienen - und hat dazu ihr eigenes Toolkit entwickelt.
Aber selbst wenn wir das mal ausser Acht lassen, finde ich das Argument nicht schluessig. So ist allen modernen GUI-Toolkits gemein (ich rede jetzt hier von Qt, XAML & Cocoa), dass sie GUI-Deklaration streng trennen vom Code - durch ueblicherweise XML-Dateien, die dann irgendwie automatisch weiterverarbeitet werden, oder gleich Grundlage der GUI sind.
Ob ich nun aber in der IDE durch Doppelklick oder F-irgendwas in den Designer huepfe, oder ueber Alt-Tab - das ist fuer mich kein qualitativer Unterschied. Bleibt die Frage, ob Daten-Bindung (das Qt leider nicht kennt, dafuer aber ein ausgefeiltes Model-View-Konzept) und strengere Typisierung mit all ihren Komplexitaeten den Vorteil von Python als Sprache aufwiegt, in der ich viel flexibler bin.
Ich habe noch nicht mit C# und Visual Studio gearbeitet - aber gerade mal ein bisschen Tutorials geschaut. Die entscheidende Magie scheint ja nun schlicht, boilerplate fuer Event-Code zu generieren. Kenne ich noch von VB6, und Dingen wie Macromedia Director.
Und mich nervt sowas eher. Letztlich besteht das programmieren aus so viel mehr, als sich das bisschen Boilerplate zu sparen. Und falls mir nix entgangen ist, dann ist zB XCode + Interface Builder in dieser Beziehung aehnlich. Dort musst du auch deine actions selbst schreiben - erst dann erkennt der IB sie. Im dynamischen Python muss man das dann zweimal machen, einmal im IB, einmal in Python. Aber das kostet mich 20 Sekunden.
Langer Rede, kurzer Sinn: ja, Python kommt nicht mit so viel Umgebung wie eine Visuelle IDE. Und wer neu beginnt, mit dem Ziel, eine GUI-Anwendung zu schreiben, fuer den mag C# in VS die bessere Wahl sein.
Wer aber schon Python beherrscht, und jetzt eben GUI-Entwicklung betreiben will - und das war das Szenario des OP - dann kann man das, und man kann es IMHO kompetitiv. Auch professionnell - da moechte ich naemlich eigentlich keinen grossen Unterschied machen.
Das, was Python einem aufgrund der fehlenden Typdeklarationen nimmt, gleicht es durch flexibleres + ausdrucksstaerkeres Programmieren mehr als aus. Wenn ich das nicht so sehen wuerde - egal in welchem Kontext - dann wuerde ich es erst gar nicht verwenden.
Zu deinen PyObjc Bemerkungen kann ich nur sagen, dass wir da unterschiedlicher Ansicht sind - aesthetisch habe ich mit PyObjc keine Probleme, mir gehen die eckigen Klammern bei ObjC deutlich mehr auf den Zeiger (vor allem, weil ich dazu erstmal *vor* den Bezeichner muss, anstatt Methodenaufrufe einfach verketten zu koennen), und dein Debugging-Argument kann ich nicht nachvollziehen - bei mir funktioniert der pdb tadellos. Und auch das Speichermanagement ist einfacher, schliesslich wird GC verwandt (die jetzt ja wohl erst vernuenftig in ObjC laeuft). Aehnliches gilt fuer Exceptions.
Ich habe in PyObjc jedenfalls schon komplexere Anwendungen mit Anbindung von Dingen wie OpenCV und QTKit und so weiter gemacht, und war sehr zufrieden damit, nur das, was wirklich C/C++ sein musst, ueber ein ObjC-Framework, welches ich in PyObjc eingeladen habe, abhandeln zu koennnen. Und den ganzen Rest (zB jede Menge custom views) per Python.
-
deets
Gerade gefunden, und es passt so schoen zu der Rhetorik von unserem lieben Newcomer:
http://www.smbc-comics.com/index.php?db ... 1397#comic
http://www.smbc-comics.com/index.php?db ... 1397#comic
-
lunar
@deets: Zwischen C# und Python besteht im Bezug auf Ausdrucksstärke und Flexibilität weniger Unterschied, als man annehmen mag, vor allem weitaus weniger Unterschied als zwischen Java und Python. Im Gegensatz zu Java hat C# lokale Typinferenz, echte Methodenreferenzen, Lambdas, und insbesondere LINQ. Dank letzterem kann man so manches Konstrukt aus Python mit lediglich syntaktischen Änderungen nach C# übertragen, "x = (spam(e) for e in eggs if e.size > 10)" wird beispielsweise zu "var x = (from e in eggs where e.size > 10 select spam(e)". Klar, es gibt immer noch hässliche geschweifte Klammern und unnötige Semikola, aber dafür hat man ja die IDE oder zumindest einen guten Editor. Ich glaube, als Python-Entwickler kommt man mit C# gut zurecht, jedenfalls um Welten besser als mit Java oder C++. Persönlich halte ich C# in der aktuellen Version für eine bis auf kleine Ausnahmen gelungene Sprache.
Ansonsten gehe ich mit sma, und sage aus eigener Erfahrung ebenfalls, dass man unter Windows mit VisualStudio und .NET wesentlich besser bedient ist als mit Python. Selbst wenn man Python schon kann. Ich sage das nicht gerne, denn ich halte Python für eine gute Sprache, und Qt für ein hervorragendes Toolkit (allemal besser als Winforms und XAML), doch die schönste Sprache und das beste Toolkit brauchen auch vernünftige Werkzeuge, und das beginnt eben schon bei so scheinbar trivialen Dingen wie dem Deployment. In VS ist ein Standard-Installer für ein Projekt samt Abhängigkeiten in zwei, drei Klicks erstellt, in Python dagegen muss man den Kampf mit py2exe, distutils und weiß Gott noch was aufnehmen, um eine GUI-Anwendung vernünftig verteilen zu können. Selbst unter Linux gibt es für Python keine einfache, und erst recht keine standardisierte Möglichkeit, GUI-Anwendungen zu verteilen. distutils reicht nicht. Womit man auch wieder die Qual der Wahl hat, und viel Zeit mit Dingen verbringen muss, die mit dem Projekt selbst eigentlich überhaupt nichts zu tun haben.
Ansonsten gehe ich mit sma, und sage aus eigener Erfahrung ebenfalls, dass man unter Windows mit VisualStudio und .NET wesentlich besser bedient ist als mit Python. Selbst wenn man Python schon kann. Ich sage das nicht gerne, denn ich halte Python für eine gute Sprache, und Qt für ein hervorragendes Toolkit (allemal besser als Winforms und XAML), doch die schönste Sprache und das beste Toolkit brauchen auch vernünftige Werkzeuge, und das beginnt eben schon bei so scheinbar trivialen Dingen wie dem Deployment. In VS ist ein Standard-Installer für ein Projekt samt Abhängigkeiten in zwei, drei Klicks erstellt, in Python dagegen muss man den Kampf mit py2exe, distutils und weiß Gott noch was aufnehmen, um eine GUI-Anwendung vernünftig verteilen zu können. Selbst unter Linux gibt es für Python keine einfache, und erst recht keine standardisierte Möglichkeit, GUI-Anwendungen zu verteilen. distutils reicht nicht. Womit man auch wieder die Qual der Wahl hat, und viel Zeit mit Dingen verbringen muss, die mit dem Projekt selbst eigentlich überhaupt nichts zu tun haben.
@deets & alle anderen
Das ist einfach nur lächerlich, was ihr da veranstaltet. Mein erster Beitrag war auf Seite 4, jetzt sind wir auf seite 6 gelandet. Ihr schreibt also tatsächlich 2 ganze Seiten, gespickt mit Beleidigungen etc., nur um mir zu beweisen, dass man mit Python besser herumkommt als mit C. Oh gott, Oh gott, ich habe gesagt, dass man mit C besser GUIs programmieren kann als mit Python. *Hände vors Gesicht*.
Und was die Rhetorik anbetrifft, habe ich jemals behauptet sie zu beherrschen?? ( Habe ich das?). NEIN. Dafür, dass ich Python in ca. 1 Monat nur am Wochenende gelernt habe (mit einem Buch, dass sich Python für Kids nennt!!!!) kann ich schon ganz gut programmieren. Also bitte, ihr die am Tag 10h mindestens vorm Pc sitzen, irgendwelche dummen Beiträge von vermeintlich dummen Menschen kommentieren, bei euch ist es kein Wunder, dass ihr besser proggen könnt als ich. (Obwohl das weiß ich nicht, von sma und deets hab ich bsp. noch nie ein ganzes Programm zu Gesicht bekommen).
TUT MIR LEID ICH WOLLTE EUCH NICHT VERLETZEN, INDEM ICH GESAGT HABE: HEY PYTHON IST C EIN STÜCKCHEN UNTERLEGEN
Das ist einfach nur lächerlich, was ihr da veranstaltet. Mein erster Beitrag war auf Seite 4, jetzt sind wir auf seite 6 gelandet. Ihr schreibt also tatsächlich 2 ganze Seiten, gespickt mit Beleidigungen etc., nur um mir zu beweisen, dass man mit Python besser herumkommt als mit C. Oh gott, Oh gott, ich habe gesagt, dass man mit C besser GUIs programmieren kann als mit Python. *Hände vors Gesicht*.
Und was die Rhetorik anbetrifft, habe ich jemals behauptet sie zu beherrschen?? ( Habe ich das?). NEIN. Dafür, dass ich Python in ca. 1 Monat nur am Wochenende gelernt habe (mit einem Buch, dass sich Python für Kids nennt!!!!) kann ich schon ganz gut programmieren. Also bitte, ihr die am Tag 10h mindestens vorm Pc sitzen, irgendwelche dummen Beiträge von vermeintlich dummen Menschen kommentieren, bei euch ist es kein Wunder, dass ihr besser proggen könnt als ich. (Obwohl das weiß ich nicht, von sma und deets hab ich bsp. noch nie ein ganzes Programm zu Gesicht bekommen).
TUT MIR LEID ICH WOLLTE EUCH NICHT VERLETZEN, INDEM ICH GESAGT HABE: HEY PYTHON IST C EIN STÜCKCHEN UNTERLEGEN
-
Leonidas
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Inzwischen weiß ich gar nicht mehr wovon du sprichst. Von C? Von C#?Newcomer hat geschrieben:Das ist einfach nur lächerlich, was ihr da veranstaltet. Mein erster Beitrag war auf Seite 4, jetzt sind wir auf seite 6 gelandet. Ihr schreibt also tatsächlich 2 ganze Seiten, gespickt mit Beleidigungen etc., nur um mir zu beweisen, dass man mit Python besser herumkommt als mit C. Oh gott, Oh gott, ich habe gesagt, dass man mit C besser GUIs programmieren kann als mit Python. *Hände vors Gesicht*.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
-
deets
@Newcomer
Seit 2 Seiten versuchst du uns zu erzaehlen, was fuer ein begnadeter Rhetoriker du bist, der, auch wenn er ahnungslos ist, uns alles verkaufen kann. Und jetzt mit einem mal hast du das alles nicht gesagt. Nee, klar.
Seit 2 Seiten versuchst du uns zu erzaehlen, was fuer ein begnadeter Rhetoriker du bist, der, auch wenn er ahnungslos ist, uns alles verkaufen kann. Und jetzt mit einem mal hast du das alles nicht gesagt. Nee, klar.
-
Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
Das fragte ich ja auch schon vor x SeitenLeonidas hat geschrieben: Inzwischen weiß ich gar nicht mehr wovon du sprichst. Von C? Von C#?
Aha. Wieso lässt Du das "#" dann konsequent weg? Ist das auch Teil Deiner begnadeten Rhetorik? Oder ist das der fehlenden Autocompletion außerhalb Deiner IDE geschuldet?Newcomer hat geschrieben: Von C#
Aber Dir ist schon klar, dass diese Zeichen einen gewaltigen Unterschied macht?
@sma & lunar: Interessante Argumente. Im Unterschied zu Newcomer kann man Euch jedoch fundierte Ahnung unterstellen und ihr greift inhaltlich tatsächlich diejenigen Dinge auf, die wirklich gewichtig sind in diesem Zusammenhang bzw. stellt diese umfassend dar. Newcomer rotzt einfach zu simpel gestrickte Thesen heraus, die er aus irgend welchen Heise-Diskussionen oder auf dem Schulhof aufgeschnappt hat. Da sind wir uns ja alle mal hoffentlich einige
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
assert encoding_kapiert
-
deets
@lunar
Die Erfahrungen mit Windows habe ich nicht (mehr). Erst recht nicht mit C#, und dass die Sprache deutlich besser als Java ist (alleine der Verzicht auf checked Exceptions....halleluja) ist mir auch bewusst.
Insofern hast du im Zweifel das Argument fuer Newcomer vollbracht, dass er selbst nicht in der Lage war zu liefern
Python hat ganz sicher Schwaechen beim packaging. Wobei ich da unter OSX mit py2app (und dem in meinen Augen eh ueberlegenen Ansatz von Bundles unter dem Mac) eigentlich keinen Grund zur Klage habe. Damit ist es sehr einfach, Projekte aus einem einzelnen, simplen setup.py zu erzeugen.
Aber py2exe & Co moegen da deutlich mehr nerven, damit habe ich nur Kleinstkram gemacht.
Umgekehrt habe ich in der vermeintlich schoenen XCode/ObjectiveC-Welt, in der man von 0 auf fertige Anwendung auch in 10 Klicks ist, doch auch groessere Kaempfe auszufechten gehabt, wenn die Anforderungen mal etwas erweitert waren - zB 3rd-Party-libraries mit auszulieferen. Da habe ich dann eine eigene Build-Phase mit einem hinterlegten Python-Skript schreiben muessen, um mit dem install_name_tool Referenzen umzuschreiben.
Das sind aber auch Probleme mit dem Loader/Linker gewesen, die C# nicht haben mag. Wenn MS dort also eine runde Loesung geschaffen hat, dann Hut ab.
Die Erfahrungen mit Windows habe ich nicht (mehr). Erst recht nicht mit C#, und dass die Sprache deutlich besser als Java ist (alleine der Verzicht auf checked Exceptions....halleluja) ist mir auch bewusst.
Insofern hast du im Zweifel das Argument fuer Newcomer vollbracht, dass er selbst nicht in der Lage war zu liefern
Python hat ganz sicher Schwaechen beim packaging. Wobei ich da unter OSX mit py2app (und dem in meinen Augen eh ueberlegenen Ansatz von Bundles unter dem Mac) eigentlich keinen Grund zur Klage habe. Damit ist es sehr einfach, Projekte aus einem einzelnen, simplen setup.py zu erzeugen.
Aber py2exe & Co moegen da deutlich mehr nerven, damit habe ich nur Kleinstkram gemacht.
Umgekehrt habe ich in der vermeintlich schoenen XCode/ObjectiveC-Welt, in der man von 0 auf fertige Anwendung auch in 10 Klicks ist, doch auch groessere Kaempfe auszufechten gehabt, wenn die Anforderungen mal etwas erweitert waren - zB 3rd-Party-libraries mit auszulieferen. Da habe ich dann eine eigene Build-Phase mit einem hinterlegten Python-Skript schreiben muessen, um mit dem install_name_tool Referenzen umzuschreiben.
Das sind aber auch Probleme mit dem Loader/Linker gewesen, die C# nicht haben mag. Wenn MS dort also eine runde Loesung geschaffen hat, dann Hut ab.
@ deets
Gib mir doch mal ein Beispiel mit Zitat, wo ich ganz ausdrücklich aussage ich sei ein begabter Rhetoriker. Was redet ihr für ein Unsinn. Ich denke mal ich kehre einem solchem unfreundlichem Forum den Rücken. ( Was ich jtschoch auch empfehlen würde, der ja bei ungefähr jedem Beitrag von euch gedemütigt wird.) Tschüss Leute, ich war mehr oder weniger erfreut eure Bekannschaft gemacht zu haben.
Gib mir doch mal ein Beispiel mit Zitat, wo ich ganz ausdrücklich aussage ich sei ein begabter Rhetoriker. Was redet ihr für ein Unsinn. Ich denke mal ich kehre einem solchem unfreundlichem Forum den Rücken. ( Was ich jtschoch auch empfehlen würde, der ja bei ungefähr jedem Beitrag von euch gedemütigt wird.) Tschüss Leute, ich war mehr oder weniger erfreut eure Bekannschaft gemacht zu haben.