Scirptsprachen: Was ist besser für die Webentwicklung, Python oder PHP und wo sind die Unterschiede?

DEvent schrieb:

árn[y]ék schrieb:

Du hast den Sinn von Interpretersprachen nicht wirklich verstanden, huh?

Was hindert es einen Apache-Server den Php-Code den ich ihm vorwerfe zu compilieren, das compilierte dann zu cachen und jedesmal wenn es gebraucht wird auszufuehren? Aber nein das geht ja nicht, denn Php ist per Definition eine Interpretersprache und wir wollen doch keine Definitionen kaputt machen

Das, worauf sich meine Aussage bezog, war der Sinn der Interpretersprache. Damit meinte ich hauptsächlich (okay, das ich jetzt stark eingrenzend, aber man weiß, wie es gemeint ist), die Dynamik in der Entwicklung. Du änderst ein Skript, und es läuft, ohne dass du es jedes Mal rekompilieren musst.

Wenn nun der Apache meint, er muss das Script kompilieren und cachen, dann führt er dennoch eine Überprüfung durch, ob sich das Skript seit dem Zeitpunkt des Kompilierens geändert hat. Falls ja, wird es neu kompiliert und gecached. Das, was ich mit "Sinn" meinte (die Dynamik) hat sich für den Programmierer (und den Endanwender) also in keinster Weise verändert. Where's the problem?

DEvent

~john schrieb:

DEvent schrieb:

Man kann auch in Php einen sauberen Code schreiben, man muss es halt wollen.

PHP hat leider eine lange Historie der Unsicherheitsphilosophie. Bei PHP4 hätte der Unfug "Register Globals" abgeschafft werden müssen. Wer solche fundamentalen Designfehler in einer Programmierumgebung bestehen läßt, dem ist wirklich nicht mehr zu helfen. Ich kann niemanden verstehen, der mit so einem ***** freiwillig Programme schreiben will.

Register Globals kann man doch an und aus schalten wie man will?

~john schrieb:

Selbst bei vorsichtigster Programmierung ist man bei PHP eben nicht sicher, daß nicht irgend ein Pfuscher, der Komponenten für PHP liefert, nicht wieder irgend einen Exploit aus Unwissenheit in PHP eingebaut hat.

Was soll das heisen? Das Php was fuer Code von dritten Personen kann?

Also ich hab ja gleich mit php5 angefangen, also kann ich fuer php4 nicht mitreden. Ich weis nicht was ihr habt, laut der Liste http://bugs.php.net/bugstats.php?phpver=5
ist 0 critical und fuer jede Lib ist max 8 Fehler, im Durchschnitt ca. Fehler. Dazu ist php Opensource und hat eine riesengrosse Comunnity, das heist Fehler werden sehr schnell bekannt und werden sehr schnell behoben.

Median life of a report: 1 day 17 hours 12 minutes 58 seconds

Was man oft meint, wenn man PHP kritisiert, sind die früher doch sehr drastisch gewesenen Lecks.

Ein Beispiel:
Die Funktion htmlentities() (oder ...spechialchars(), bin mir nicht ganz sicher) hatte ein Leck, dass es ermöglichte, mit manipuliertem Code beliebige Anweisungen auf dem Hostrechner ausführen zu lassen. Besonders bei einer Funktion wie htmlentities() - die ja gerade dafür gedacht ist, mit nicht gefilterten Parametern aufgerufen zu werden! - sind solche Möglichkeiten der Code Injection nicht tolerierbar!

Noch ein Beispiel? Kein Problem.
Die Upload-Funktion von PHP hatte einmal einen Bug, der recht lange Zeit unentdeckt blieb. Damit konnte man mit nahezu jedem x-beliebigem Uploadformular, das via PHP ausgewertet wurde, Code einschleusen.

Solche Digne sind es, an die man denkt, wenn man bei PHP die Sicherheit kritisiert. Sicher, nun könnte man sagen, dass die momentane Version (5.2) weitgehend sicher ist. Aber genau das dachte man bei den älteren PHP-Version auch, bis das Gegenteil bewiesen wurde.

Das Problem bei PHP ist wohl eher: Ist der Ruf mal ruiniert, lebt sich's ...

*john 0

DEvent schrieb:

Register Globals kann man doch an und aus schalten wie man will?

So etwas DARF gar nicht in einer Laufzeitumgebung existieren! Die Frage nach der Konfigurierbarkeit stellt sich erst gar nicht, denn ES MUSS IMMER ABGESCHALTET SEIN. Es ist einfach nur skandalös, daß es überhaupt in die Sprache eingebaut wurde, es ist vollkommen unverständlich, daß es in PHP4 und PHP5 übernommen wurde. In PHP6 soll es aus der Laufzeitumgebung entfernt werden. Das hätte man schon beim Auftreten des ersten Exploits zu Zeiten von PHP3 tun MÜSSEN.

DEvent schrieb:

Was soll das heisen? Das Php was fuer Code von dritten Personen kann?

Eindeutig ja, denn in PHP sind viele sicherheitsrelevanten Funktionen nicht vorgeschrieben sondern abschaltbar oder nur durch explizites Aktivieren zu nutzen. So etwas ist eindeutig ein Designfehler.

Dazu ist php Opensource und hat eine riesengrosse Comunnity, das heist Fehler werden sehr schnell bekannt und werden sehr schnell behoben.

Aha, daher existiert "register globals" seit etlichen Jahren? In den letzten 5 Jahren war dieser Dreck wohl für 50% der Exploits gegen PHP-Anwendungen verantwortlich. Auch so ein Evergreen: SQL Injection. Wobei das eher ein Fehler von MySQL ist. Z.B. PostgreSQL bietet seit Release 7.4 eine sichere Query-Funktion in der C-Library an, die es bei MySQL immer noch nicht gibt. Die Kombination LAMP steht halt für einige Designfehler, die vermeidbar gewesen wären.

~john schrieb:

In PHP6 soll es aus der Laufzeitumgebung entfernt werden. Das hätte man schon beim Auftreten des ersten Exploits zu Zeiten von PHP3 tun MÜSSEN.

Bereits in PHP 5.3

~john schrieb:

Auch so ein Evergreen: SQL Injection. Wobei das eher ein Fehler von MySQL ist. Z.B. PostgreSQL bietet seit Release 7.4 eine sichere Query-Funktion in der C-Library an, die es bei MySQL immer noch nicht gibt. Die Kombination LAMP steht halt für einige Designfehler, die vermeidbar gewesen wären.

Wobei man sagen muss, dass SQL-Injections bei Verwendung vernünftiger Wrapper (Stichwort Prepared Statements) ohnehin obsolete sind. Wenn man will, kann man schon saubere Anwendungen mit vernünftiger DB-Anbindung schreiben. PHP ist einfach schlampig in der Hinsicht, dass die "guten" Wege fast immer verbaut sind, während die "schlechten" offenstehen und noch dazu in 15 von 16 Einsteigerbüchern gelehrt werden ...

DEvent schrieb:

PHP(>5): Auch ziemlich mächtig, da es wahnsinnig viele Ressourcen gibt und die Sprache bereits einen riesigen Funktionsumfang enthält. Aber genau da liegt auch das bereits angesprochene Problem: Sehr unaufgeräumt.

Wieso unaufgeraumt? Alle PDF Functions sind mit PDF_, alle Image Functions mit image..., alle MySQL Functions mit mysql_ usw.

Wenn ich bei den PDF und Image Funktionen Redunanz habe, also Funktionen die das gleiche tun, aber auch genauso gut als eine Funktion generalisiert werden könnten, dann ist das unaufgeräumt.

Idealerweise gibt es eine Generic Klasse, die dann PDF und Image Klasse erbt und ihre speziellen Funktionen, falls noch notwendig, hinzufügt.
DAS wäre dann aufgeräumt.

Pyhton schrieb:

Idealerweise gibt es eine Generic Klasse, die dann PDF und Image Klasse erbt und ihre speziellen Funktionen, falls noch notwendig, hinzufügt.
DAS wäre dann aufgeräumt.

Das setzte allerdings voraus, dass sowohl die PDF- als auch die Image-Klassen integraler Bestandteil von PHP seien. Sind sie aber nicht. Die Image-Funktionen kommen aus der gdlib und die PDF-Funktionen aus einer anderen Bibliothek. Es sind voneinander unabhängige Erweiterungen der Funktionalität von PHP (nicht der Sprache selbst!).

Du kannst auch nicht sagen, C++ sei nicht aufgeräumt, weil wxWidgets und Qt - die ja im Wesentlichen (im Sinne einer GUI) das gleiche machen - nicht von ein und derselben Klasse abgeleitet sind.

árn[y]ék schrieb:

Pyhton schrieb:

Idealerweise gibt es eine Generic Klasse, die dann PDF und Image Klasse erbt und ihre speziellen Funktionen, falls noch notwendig, hinzufügt.
DAS wäre dann aufgeräumt.

Das setzte allerdings voraus, dass sowohl die PDF- als auch die Image-Klassen integraler Bestandteil von PHP seien. Sind sie aber nicht. Die Image-Funktionen kommen aus der gdlib und die PDF-Funktionen aus einer anderen Bibliothek. Es sind voneinander unabhängige Erweiterungen der Funktionalität von PHP (nicht der Sprache selbst!).

Du kannst auch nicht sagen, C++ sei nicht aufgeräumt, weil wxWidgets und Qt - die ja im Wesentlichen (im Sinne einer GUI) das gleiche machen - nicht von ein und derselben Klasse abgeleitet sind.

tja, ohne jetzt mal nen Flamewar vom Zaun zu brechen, ABER: In .NET (ASP.NET) sowie C# ist das alles von Haus aus dabei

Kenner des ASP.NET schrieb:

tja, ohne jetzt mal nen Flamewar vom Zaun zu brechen, ABER: In .NET (ASP.NET) sowie C# ist das alles von Haus aus dabei

Und in Java.

Wie sieht's denn bei Python aus?

ronny

bei python ist das ganze noch nicht in die stdlib eingeflossen

jedoch sind alle frameworks über den cheeseshop verfügbar

außerdem gibt es auch für python einen standard auf dem alle aufbauen sollten (WSGI)