Fwd: Re: [Python-de] Noch eine php-Beobachtung
On Tuesday 18 May 2004 22:58, Hartmut Goebel wrote:
Vielleicht haben PHP'ler da für auch mehr Zeit, weil die Pyth'janer noch zu hause über ihrem Code sitzen und Unicode-Fehler suchen? Oder es ist einfach zu peinlich das bei Vorträgen das mophische Gesetz "alles was schiefgehen kann..." sich um Faktor 3 erhöht durch den Vorführefekt. So das das Programm immer dann mit ein Unicode-Fehler krepiert, wenn man der Weltöffentlichkeit demonstrieren will, wie toll die eigene Arbeit ist. Und ganz peinlich, wie in meinem Fall, das Prog nicht nur einfach abbricht - nein - sondern im Vordergrund das Terminal blockiert und nicht mal mehr ein Strg-d oder Strg-c den Interpreter stoppen kann und die Threads als Zombies den Lüfter der CPU auf Widerstandsfähigkeit testen. Soll ich das gesamte Programm jetzt in einen try-Block auf Unicode-Fehler abfangen ... try: print "das war die Eingabe des Users: " + eingabe except UnicodeError: print "Wir unterbrechen den Vortrag kurz für eine" print "Raucher- und "Kaffee-Pause!!" Sobald MONO rund läuft, werde ich mir mal ansehen wiefiel Zeit die MONO-Programmierer haben für Vorträge... MfG Olaf _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Zitat: http://www.joelonsoftware.com/items/2003/10/10.html """ Friday, October 10, 2003 When I discovered that the popular web development tool PHP has almost complete ignorance of character encoding issues, blithely using 8 bits for characters, making it darn near impossible to develop good international web applications, I thought, enough is enough. So I have an announcement to make: if you are a programmer working in 2003 and you don't know the basics of characters, character sets, encodings, and Unicode, and I catch you, I'm going to punish you by making you peel onions for 6 months in a submarine. I swear I will. """ Carl -- "Sie haben neue Mails!" - Die GMX Toolbar informiert Sie beim Surfen! Jetzt aktivieren unter http://www.gmx.net/info _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Am Mittwoch, 19. Mai 2004 06:41 schrieb Olaf 'Rübezahl' Radicke:
Was soll daran schiefgehen, ausser wenn Eingabe ein unicode-Objekt ist, welches sich nicht in Dein Console-Encoding übertragen lässt? :) bzw. andersherum gefragt, woher soll eingabe ein Unicode-Objekt sein, ausser wenn Du es explizit so erstellt hast? Meines Wissens nach (zumindest unter *nix) gibt raw_input() nie ein Unicode-Objekt zurück, also kanns kaum von einer normalen Eingabe kommen... Noch mal andersherum gefragt: Wenn Du eingabe schon auf ein Unicode-Objekt setzt, und Dir dann keine Gedanken machst, wie Du das sinnvoll ausgeben kannst (in Verbindung mit einem Nicht-Unicode string), dann ist was an Deinem Programm falsch, und nicht an Python. ;) Dass andere Sprachen sowas einfach mirnichts, dirnichts erlauben (siehe Perl...), ist denke ich ziemlich gefährlich... Heiko. _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
On Wednesday 19 May 2004 08:31, Heiko Wundram wrote:
War stark vereinfacht.
Das Problem ist das die Ausnahme immer nur zur Laufzeit festgestellt werden kann. Wenn das Prog startet heist es nicht, das es das tut was ich erwarte. Wenn ich Blöcke falsch setze, Klammernvergesse, unbekannte Namensräume benutze, bricht der Interpreter sofort ab. Ist ja auch sinnvoll. Niemand würde auf die Idee kommen zu sagen "Lass doch den Interpreter weiter laufen. Wenn der Programmierer ein Fehler macht, ist das halt sein Problem und nicht das von Python." Und wozu diese Typenfreiheit? Was ist der Vorteil? Ganz im Gegenteil: der Interpreter könnte ohne Typenfreihei sogar noch schneller sein. Der Preis ist (mir) auf die Dauer zu Hoch. Wenn Sun seine Java-Politik nicht ändert, denke ich das Mono quasi zur "Killer-Sprache" wird und das bieten kann, wo von Sun immer erzählt. Aber warten wir es ab... Olaf _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Hi,
Aeh, seit wann tut den ein compilat aus einer typstrengen sprache das? Der nachweis, das etwas durchcompiliert hat ja nur sehr begrenzten Wert - genau diese Erkenntnis steckt ja in der test-getriebenen Philosophie die von vielen Python-Protagonisten und auch Anderen (Stichwort XP) vertreten wird. Sich in eine Situation zu manoevrieren, in der man sein Programm vor den Augen anderer zum ersten mal aurprobiert ist immer gefaehrlich, unabhaengig von der Sprache.
Es gibt mit pychecker da ja eine durchaus sinnvolle Moeglichkeit, durch eine batchlauf vor Programmstart die groebsten Schnitzer zu vermeiden. Und auch dieses Argument hat nix mit python/dynamisch usw. zu tun - schliesslich compiliert man seinen code ja auch nicht vor den Augen der interessierten Anwesenden, um dann festzustellen das es nich geht.
Hier hast du aber was massiv missverstanden- python ist alles andere als typfrei. Das sind Sprachen wie php und perl. Was du meinst ist statisch-dynamische typisierung, und orthogonal dazu starke und schwache typisierung. Statische Typchecks in Sprachen wie java/c# koennen sicher eine Reihe von Fehlern aufdecken - aber eben laengst nicht alle, das sieht man schon an der riesen Menge Classcast-Exceptions die vorkommen. Und sie fuehren dazu , das der Entwickler hohen Aufwand treiben muss, um wiederverwendbares typgenau auszufaktorisieren _bevor_ er seine Bibliothek veroeffentlicht - siehe zB die Wahnsinns Typhierarchie bei Java im Bereich der IOStreams... Das verlaengert allen die Entwicklungszeit, und die ist meistens teuer.
Mono ist keine Sprache, sondern eine Laufzeitumgebung - so wie die JVM, fuer die man ja auch andere Sprachen bekommt, uA jython, aber auch andere. Irgendwo gabs mal ne Uebersicht. Unter dem Strich kann ich fuer mich selbst sagen, das ich in python wesentlich schneller und flexibler arbeite als mit java, was ich wirklich bis zum erbrechen betrieben habe. Und als Konsequnz sehe ich statische Typisierung als ein Mittel an, das zur Optimierung wertvolle Beitraege leisten kann und somit auch Sinn machen - aber nicht viel mehr. Und wenn man sieht, wie lange es gebraucht hat bis java stabile jit compiler bekekommen hat, dann denke ich das man python und zB psyco da noch etwas Zeit geben kann. Mal ganz ab davon, das performancekritisches a) selten genug vorkommt b) wenn doch, dann halt mit pyrex oder C in eine Extension ausgelagert wird. MfG Diez _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Zitat: http://www.joelonsoftware.com/items/2003/10/10.html """ Friday, October 10, 2003 When I discovered that the popular web development tool PHP has almost complete ignorance of character encoding issues, blithely using 8 bits for characters, making it darn near impossible to develop good international web applications, I thought, enough is enough. So I have an announcement to make: if you are a programmer working in 2003 and you don't know the basics of characters, character sets, encodings, and Unicode, and I catch you, I'm going to punish you by making you peel onions for 6 months in a submarine. I swear I will. """ Carl -- "Sie haben neue Mails!" - Die GMX Toolbar informiert Sie beim Surfen! Jetzt aktivieren unter http://www.gmx.net/info _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Am Mittwoch, 19. Mai 2004 06:41 schrieb Olaf 'Rübezahl' Radicke:
Was soll daran schiefgehen, ausser wenn Eingabe ein unicode-Objekt ist, welches sich nicht in Dein Console-Encoding übertragen lässt? :) bzw. andersherum gefragt, woher soll eingabe ein Unicode-Objekt sein, ausser wenn Du es explizit so erstellt hast? Meines Wissens nach (zumindest unter *nix) gibt raw_input() nie ein Unicode-Objekt zurück, also kanns kaum von einer normalen Eingabe kommen... Noch mal andersherum gefragt: Wenn Du eingabe schon auf ein Unicode-Objekt setzt, und Dir dann keine Gedanken machst, wie Du das sinnvoll ausgeben kannst (in Verbindung mit einem Nicht-Unicode string), dann ist was an Deinem Programm falsch, und nicht an Python. ;) Dass andere Sprachen sowas einfach mirnichts, dirnichts erlauben (siehe Perl...), ist denke ich ziemlich gefährlich... Heiko. _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
On Wednesday 19 May 2004 08:31, Heiko Wundram wrote:
War stark vereinfacht.
Das Problem ist das die Ausnahme immer nur zur Laufzeit festgestellt werden kann. Wenn das Prog startet heist es nicht, das es das tut was ich erwarte. Wenn ich Blöcke falsch setze, Klammernvergesse, unbekannte Namensräume benutze, bricht der Interpreter sofort ab. Ist ja auch sinnvoll. Niemand würde auf die Idee kommen zu sagen "Lass doch den Interpreter weiter laufen. Wenn der Programmierer ein Fehler macht, ist das halt sein Problem und nicht das von Python." Und wozu diese Typenfreiheit? Was ist der Vorteil? Ganz im Gegenteil: der Interpreter könnte ohne Typenfreihei sogar noch schneller sein. Der Preis ist (mir) auf die Dauer zu Hoch. Wenn Sun seine Java-Politik nicht ändert, denke ich das Mono quasi zur "Killer-Sprache" wird und das bieten kann, wo von Sun immer erzählt. Aber warten wir es ab... Olaf _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Hi,
Aeh, seit wann tut den ein compilat aus einer typstrengen sprache das? Der nachweis, das etwas durchcompiliert hat ja nur sehr begrenzten Wert - genau diese Erkenntnis steckt ja in der test-getriebenen Philosophie die von vielen Python-Protagonisten und auch Anderen (Stichwort XP) vertreten wird. Sich in eine Situation zu manoevrieren, in der man sein Programm vor den Augen anderer zum ersten mal aurprobiert ist immer gefaehrlich, unabhaengig von der Sprache.
Es gibt mit pychecker da ja eine durchaus sinnvolle Moeglichkeit, durch eine batchlauf vor Programmstart die groebsten Schnitzer zu vermeiden. Und auch dieses Argument hat nix mit python/dynamisch usw. zu tun - schliesslich compiliert man seinen code ja auch nicht vor den Augen der interessierten Anwesenden, um dann festzustellen das es nich geht.
Hier hast du aber was massiv missverstanden- python ist alles andere als typfrei. Das sind Sprachen wie php und perl. Was du meinst ist statisch-dynamische typisierung, und orthogonal dazu starke und schwache typisierung. Statische Typchecks in Sprachen wie java/c# koennen sicher eine Reihe von Fehlern aufdecken - aber eben laengst nicht alle, das sieht man schon an der riesen Menge Classcast-Exceptions die vorkommen. Und sie fuehren dazu , das der Entwickler hohen Aufwand treiben muss, um wiederverwendbares typgenau auszufaktorisieren _bevor_ er seine Bibliothek veroeffentlicht - siehe zB die Wahnsinns Typhierarchie bei Java im Bereich der IOStreams... Das verlaengert allen die Entwicklungszeit, und die ist meistens teuer.
Mono ist keine Sprache, sondern eine Laufzeitumgebung - so wie die JVM, fuer die man ja auch andere Sprachen bekommt, uA jython, aber auch andere. Irgendwo gabs mal ne Uebersicht. Unter dem Strich kann ich fuer mich selbst sagen, das ich in python wesentlich schneller und flexibler arbeite als mit java, was ich wirklich bis zum erbrechen betrieben habe. Und als Konsequnz sehe ich statische Typisierung als ein Mittel an, das zur Optimierung wertvolle Beitraege leisten kann und somit auch Sinn machen - aber nicht viel mehr. Und wenn man sieht, wie lange es gebraucht hat bis java stabile jit compiler bekekommen hat, dann denke ich das man python und zB psyco da noch etwas Zeit geben kann. Mal ganz ab davon, das performancekritisches a) selten genug vorkommt b) wenn doch, dann halt mit pyrex oder C in eine Extension ausgelagert wird. MfG Diez _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
participants (4)
-
Carl Kleffner -
Diez B. Roggisch -
Heiko Wundram -
Olaf 'Rübezahl' Radicke