nicht angemeldet
Moin!
Viel schwerwiegender ist, dass PHP einem mächtige Waffen in die Hand gibt, deren Sicherheitshebel durch die Aufschrift "sicher" ersetzt wurde, während ein interner Mechanismus selbständig entscheidet, welche Munition nun verwendet wird. Der Anwender kümmert sich nicht um sicherheitsrelevante Fragen, er kümmert sich nicht um die zugrundeliegende Mechanik. Er probiert einfach irgendwas aus, ohne sich der Konsequenzen bewusst zu sein, _und wird dank der Leichtigkeit der Sprache in keiner Weise behindert_. Nur allzu leicht resultiert daraus ein PHP-Chat mit einem PHP-User-online-Counter und anderem Quatsch.
Wie supersicher dagegen andere Sprachen "von Hause aus" sind, auch wenn sich jemand mit etwas mehr Programmiererfahrung an die Tastatur setzt, zeigen ja in schillernden Farben die ersten PERL-Skripte von Matt Wright. Der Mann war mit Sicherheit kein Anfänger, aber er hat es trotz Abwesenheit von PHP geschafft, unsichere Skripte herzustellen.
Dein Einwand, PHP wäre per se geeignet, unsichere Skripte zu schreiben, andere Sprachen wären da viel besser, stimmt nicht. Auch andere Sprachen machen es ihren Benutzern genauso leicht, unsicheren Blödsinn zu programmieren. Es liegt nicht an der Sprache, sondern am Programmierer und am Programmkonzept.
Dass PHP für Anfänger leichter zugänglich ist, belegen die Benutzerzahlen. PERL kackt da richtig ab, und alle anderen Möglichkeiten der CGI-Programmierung (C, C++, JSP, Python, ...) spielen in diesem Segment absolut keine Rolle.
Wenn du also von PHP abrätst, bedeutet das im Umkehrschluß, du rätst zu PERL (zumindest rätst du davon nicht ab, sondern stimmst bei Nachfragen eher zu). PERL ist genauso scheiße, wie PHP. Also ist dein Rat wenig hilfreich.
Dass PHP konzeptarm sei, kann ich nicht nachvollziehen. PHP ist eine Programmiersprache. Können Programmiersprachen per se ein Konzept haben? Wenn das so ist, dann hat PHP eindeutig das Konzept "Sei eine nützliche Programmiersprache für Webseiten". Und das wird vollkommen erfüllt - die vielen weborientierten Funktionen und Funktionalitäten von PHP beweisen es. Kritiker behaupten sogar, es seien zuviele Funktionen.
Wer gleichartige Funktionalität bei PERL haben will, darf sich auf das Abenteuer "Module" einlassen (bei denen immer das Problem ist, dass sie kein Bestandteil der zu nutzenden PERL-Installation sein müssen), oder den Kram komplett selbst schreiben. Mit extrem zweifelhaftem Erfolg, was die häufige Mißachtung des Moduls CGI (mutmaßlich trotz dessen Verfügbarkeit) und dessen mieserable Ersatzprogrammierung angeht.
Im Grund genommen ist PERL deswegen sogar noch viel schlechter, als PHP. PHP hat wenigstens eine genormte, funktionierende und bekannte Schnittstelle zu GET und POST-Daten. Bei PERL lebt der Wildwuchs.
Und sowas willst du ernsthaft empfehlen...
- Sven Rautenberg
Die SelfHTML-Developer sagen Dankeschön für aktuell 21335,05 Euro Spendengelder!