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

Uiii da hat aber jemand schon länger geschlafen.
Es gibt sogar schon PHP Compiler....

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

Im Übrigen behaupte ich genau das Gegenteil: PHP ist absolut überfüllt mit Dingen. Die Sprache ist aufgebläht wie kaum eine andere, der globale Namespace quillt über und eine echte Struktur fehlt dem Ganzen auch ...

Gut das das nur eine Behauptung ohne irgendwelche Grundlagen sind ....

Abgesehen davon, dass sich mein Beitrag auf den von user33 bezog:
http://www.php.net/quickref.php

Das hab ich auch anders gemeint kann ja nicht ahnen dass du das so interpretierst scheiß typumwandlung macht mir glatt nen int aus nem array ne ich meinte das eigentlich anders.

Aber es sind nicht nur die Namespaces die fehlen auch Mehrfachvererbung geht mir ab. Es gibt noch hunderte kleiner und großer dinge die stören aber so einfach ist das alles leider nicht einzubauen nehm ich an hab mich mit compiler und programmiersprachen design nur wenig beschäftigt

Ich persönlich mag Ruby on Rails sehr gerne. Leider unterstützt das so gut wie kein Hoster.

Ist sicher alles geschmacksache.

Was ich gut finde ist das ZendFramework das hat mich nun echt erstaunt hab das letzte mal drüber gelesen als es noch frühe alpha war aber jetzt hat es echt viele funktionen das erleichtert einem das leben echt
lese gerade die doku und bin echt beeindruckt bis jetzt sollten sich all jene die es noch nicht kennen anguggen und alle die nur ne frühe version gesehen haben auch denn es ist echt gut zumindest das was ich gesehen habe bis jetzt das ist echt groß geworden am anfang wars ja eher bescheiden

Man man man....
Wenn ich eins nich mag sind es Leute, die es nicht für nötig halten, "fremden" Plattformen eine Daseinsberechtigung einzuräumen. Aber was solls...

Aber ich muss sagen, dass auch mich bis jetzt keine von mir ausprobierte Plattform wirklich vom Hocker gehauen hat (bin aber auch nicht der professionelle Webentwickler, der schon alles in den Fingern hatte)...
(APS).net: Seeeeehhhr mächtig. Leider für jemanden, der nur mal schnell eine Seite mit ein wenigen dynamischen Inhalten erstellen will zu mächtig.
Die Behauptung, sich mit ASP.NET selbst einzuschrenken weil es zu wenige Server gäbe halte ich aber für eine Schutzbehauptung von jemand, der sich nicht genug informiert hat. Im Gegenteil - gerade durch .Net wird der Stellenwert dieser Plattform IMHO in den nächsten Jahren sicher weiter wachsen (gerade mit dem neuen Presentation Layer in .Net 3.x und allem, was dahinter hängt).
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. Aber dafür einfach zu lernen. Was mich an PHP stört sind zum einen die Tatsache, wie PHP mit Typen umgeht. Wenn die Sprache einem fröhlich einen int nach float, und dann zum String und daraus nach bool konvert, und das ohne mit der Wimper zu zucken, macht mir das ein wenig Angst. Noch schlimmer ist es, wenn man mit Objekten arbeitet. Da ist es, selbst bei sauberer Programmierung, nur eine Frage der Zeit, bis das mal in die Hose geht.

Ich träume ja von einer von einer ganz neuen Sprache, welche ausschließlich Objektorientiert und dazu noch typsicher ist und durch bestimmte Deklarationen auch direkt dynamischen Code (--> JS) erzeugt ohne dass man sich einer anderen Sprache bedienen bzw. andere Objekte erstellen muss. Leider fehlt mir die Zeit, für sowas mal einen eigenen Compiler/Interpreter zu bauen - also wird es wohl immer ein Traum bleiben

DEvent

Was mich an PHP stört sind zum einen die Tatsache, wie PHP mit Typen umgeht. Wenn die Sprache einem fröhlich einen int nach float, und dann zum String und daraus nach bool konvert, und das ohne mit der Wimper zu zucken, macht mir das ein wenig Angst. Noch schlimmer ist es, wenn man mit Objekten arbeitet. Da ist es, selbst bei sauberer Programmierung, nur eine Frage der Zeit, bis das mal in die Hose geht.

Das ist aber bei jeder Sprache so, die Dynamische Typen hat (z.b. Ruby). Ausserdem kann man bei Objekten den Typ festlegen, es gibt eine strikte Hierarchie, und es gibt Exceptions.

In der umfangreichen Bibliothek kann ich nur Vorteile sehen: Man braucht nicht fuer jeden Misst ein "require/include" zu schreiben oder ein Namespace. Beispiel die String-Bibliothek: Man kann einfach explore(str) schreiben, ohne zuvor eine String-Bibliothek einzubinden. Einen Namespace kann man ja wie in C simulieren, indem man prefixe Benutzt ( MeineLib_explore() ).

Mit Php5 kann man auch sehr guten OOP-Code schreiben, man muss es nur wollen. Php ist aehnlich wie C++ eine Multiparadigmen-Sprache.

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.

DEvent schrieb:

Was mich an PHP stört sind zum einen die Tatsache, wie PHP mit Typen umgeht. Wenn die Sprache einem fröhlich einen int nach float, und dann zum String und daraus nach bool konvert, und das ohne mit der Wimper zu zucken, macht mir das ein wenig Angst. Noch schlimmer ist es, wenn man mit Objekten arbeitet. Da ist es, selbst bei sauberer Programmierung, nur eine Frage der Zeit, bis das mal in die Hose geht.

Das ist aber bei jeder Sprache so, die Dynamische Typen hat (z.b. Ruby).

Das is völlig flasch! Du verwechselst dynamische mit schwacher Typisierung. Dynamisch sind zwar die meisten, aber PHP ist im Gegensatz zu Ruby schwach typisiert, das ist ja das Problem.

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.

LOL. Meinst Du das ernst?

ronny

ich habe bisher die besten erfahrungen mit python gemacht

es gibt zwar nicht so viel wie für php, dafür ist das meiste aber sehr gut
(was man von den meisten php sachen nicht behaupten darf)

mit ruby habe ich eher schlechte erfahrugen gemacht, da:

a) noch langsam (wird aber bis spätestens 2009 aufholen)
b) man bei rails doch ganz schön leiden muss, wenn man "von der schiene will"

darthdespotism

Ich habe mir neulich mal Django angesehen (Python Framework)

Sieht echt vielversprechend aus

@ DEvent:
Was ist das Problem mit den includes? Und wenn man »echte« Namensräume hat braucht man auch nicht mit Prefixen improvisieren

ronny

django ist nur für einfache crud sachen gut

alles was komplex ist, ist mit django qualvoll

DEvent

á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

Der Rest ist Geschmackssache. Ich mag es nicht fuer jede Funktion die ich verwenden will, erstmal eine Lib includieren zu muessen. Man kann auch in Php einen sauberen Code schreiben, man muss es halt wollen.

*john 0

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. 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.

Wenn man sich die Exploits für PHP selbst und für PHP Anwendungen anschaut, dann ist die Liste überproportional lang. Und leider ist das im Lauf der Zeit nicht wirklich besser geworden. Wer PHP freiwillig verwenden will soll das tun, nur zweifle ich an dessen Fähigkeiten als Programmierer.

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 ...