Welche Programmiersprache für aktive Internetseiten?

rüdiger

drakon schrieb:

Aber wieso findest du PHP die schlechteste Möglichkeit? Es ist weit verbreitet, gut unterstützt, bekannt, es gibt viele Bibliotheken dafür, gute Bücher usw.

Die Sprache ist extrem mies. Ein wilder mix aus C, Java, C++ und Perl. Man merkt einfach, dass die Entwickler keine Ahnung von Programmiersprachen hatten. Vielleicht kann man damit schnell etwas zusammen basteln, aber der entstehende Code ist oft extrem fehlerhaft (SQL-injections und Crosssitescripting Fehler sind ja gang und gäbe in PHP Software). Die Bibliotheken sind inkonsistent und viele Sachen sind ständig präsent. Ich hab genug PHP Code ertragen müssen in meinem Leben (ab und an bastel ich zB an der Forensoftware rum) und ich habe nie einen gut wartbaren, sauber geschriebenen PHP Code gesehen. PHP ist halt eine "ich fummel rum bis es mit den zwei Testfällen klappt und dann pack ich es auf einen Server"-Sprache. Das Gegenteil von Wartbarkeit und Sicherheit.

Aber auch der Interpreter enthält regelmäßig Sicherheitslücken, die dann extrem stümperhaft behoben werden. Siehe zB http://use.perl.org/~Aristotle/journal/33448

Oder die Unterstützung von Octalzahlen ist kaputt, weil die PHP Programmierer keine Ahnung haben: http://www.steike.com/code/php-must-die/

Und PHP ist ziemlich langsam, was ja auch nicht verwunderlich ist, da es von einer Firma entworfen wurde, die das Geld damit verdient hat einen Beschleuniger für PHP zu verkaufen...

Ne, so etwas will man einfach nicht benutzen.

Sqwan

Gerade PHP halte ich für die richtige Sprache. Sie ist kinderleicht.
Kein stress mit datentypen
Eine super einfache anbindung an SQL.
Free spaces gibts an jeder ecke.
In PHP gibbts fast nichts, was nicht geht.

Klar provoziert genau das Miserablen code.
Aber gerade der mix aus diesen vielen Sprachen macht PHP so interessant.
Das eingebaute Templatesystem ist super.
Man kann es in jeder erdenklichen art mit html mixen.

Also ich finde die Sprache einfach genial... ^^

schmidt-webdesign.net

Leider besitzt PHP neben unzähligen weiteren Mängeln/Unzulänglichkeiten keinen eigenen Bytecode-Cache, was ohne entsprechende Erweiterung bei jedem Aufruf einer Datei ein komplettes Parsen notwendig macht.

Wer mal ein Projekt in ASP.NET in der Programmiersprache C# realisiert hat, mag mit PHP nicht mehr arbeiten ...

Ich halte php auch für eine schlechte Möglichkeit, nimmt lieber ASP .NET/MONO

Sqwan

könnt ihr denn einen brauchbaren freehoster für sowas nennen?

Sqwan schrieb:

Gerade PHP halte ich für die richtige Sprache. Sie ist kinderleicht.
Kein stress mit datentypen
[...]

Nur weil PHP Datentypen vor dem Nutzer versteckt, heißt das nicht, dass es auf magische Weise keine Probleme damit gibt. Das heißt nur, dass PHP die Datentypen verwaltet und zwar so wie der Interpreter es will, nicht so wie der Programmierer will. Als gutes Beispiel kannst du dir ja rüdigers post anschauen.

Klar, einfache Skripte lassen sich schneller mal eben so zusammentippen und man muss sich nicht um Typisierung kümmern, solange keine Probleme auftauchen. Alles, was man für eine "qick and dirty" Lösung braucht. Für ernsthafte Massenprodukte ist das aber meiner Meinung nach meistens ein Nachteil.

schmidt-webdesign.net schrieb:

Wer mal ein Projekt in ASP.NET in der Programmiersprache C# realisiert hat, mag mit PHP nicht mehr arbeiten ...

Das ist eher andersrum ...

branleb

zum Thema freehoster: einfach mal google anschmeißen,
Ich persönlich habe aber bisher keinen freehoster gefunden, denn ich wirklich empfehlen kann. Man merkt halt doch, das die Angebote für Lau sind.

Man kann mit PHP durchaus sauberen, schönen Code schreiben. Und ich habe sogar schon welchen gesehen. Nur sobald PHP4 Konstrukte oder die sog. magic methods und ähnliches verwendet werden, wird es oft häßlich. Und leider sind es gerade diese Dinge, die einem Anfänger denken lassen: super praktisch! Erst bei größeren Projekte merkt man die fatalen Auswirkungen. Daher Tipp an jeden Anfänger:
- Sobald PHP4 Kompatibilität als "Feature" gepriesen wird, ist die Software schrott.
- Sobald magic methods angepriesen werden: Finger weg!
- Sobald über array-to-object conversion als "Feature" geredet wird: in die Mülltonne
- Auch wenn es PHP ermöglicht, typen zu missachten: Achtet selber drauf!

Dann ergibt sich (fast) automatisch wartbarer Code. Und viele Bugs vermeided man dadurch von vornherein.

Zumindest hab ich es so erlebt...

mfg

Sqwan

Als ich mal anfangen wollte ASP zu lernen ist das daran gescheitert das ich keinen Space für Lau dafür gefunden habe. Nicht mal nen schlechten.
Ich bin immer bereit sachen zu lernen. Zumal mir C als sprache eigendlich super gefällt. Aber wenn das nicht für Lau geht, geht mir die lust meistens schnell wieder verloren. Außerdem schätze ich sehr den absolut leichten umgang mit der Datenbank. Sowas hab ich schon mal in c/c++ versucht. Und ich hatte keine lust mehr weils so blöde war. Und dann diese diversen libs oder wie die dinger auch heißen, die man sich besorgen muss wenn man was programmieren will kotze mächtig an. Is jetzt auf consolenprogs bezogen da ich das online halt noch nicht testen konnte.

Auch für Java habe ich noch keinen free hoster gefunden...

rüdiger schrieb:

Die Sprache ist extrem mies.

ansichtssache. ich kenne eine sprache, die erheblich scheusslicher ist *fg*
viel wichtiger ist doch, dass man als anfänger mit PHP sofort klar kommt, ganz schnell was hinzaubern kann und dass fast jeder hoster PHP anbietet. PHP ist weit verbreitet und es gibt auch viel fertige, sehr brauchbare software, die in PHP geschrieben wurde. so schlecht, wie du meinst, kann es also garnicht sein.

Sqwan schrieb:

Außerdem schätze ich sehr den absolut leichten umgang mit der Datenbank. Sowas hab ich schon mal in c/c++ versucht. Und ich hatte keine lust mehr weils so blöde war.

tröste dich, es lag nicht an dir.

byto

Sqwan schrieb:

...

Auch für Java habe ich noch keinen free hoster gefunden...

Wozu brauchst Du einen Freehoster?

Während Entwicklung/ Test oder auch nur zum Rumspielen installiert man sich eh alles lokal und geht über localhost. Möchte man dann ernsthaft was produktiv schalten, braucht man sowieo einen vernünftigen Server.

Freehoster sind maximal für irgendwelche Kellerprojekte zu gebrauchen, die eh niemand aufruft.

php ist nicht so schlecht wie sein ruf, viele große websites basieren auf php, es bringt einfach von haus aus alles mit was für die web entwicklung benötigt wird, und du kannst in kürzester zeit dynamische websites erstellen, schlechte software ohne doku schreib ich dir in jeder sprache, das ist überhaupt kein problem;)

und für alles andere muß man sich eben ein bischen mit der programmierung beschäftigen, c ist doch auch nicht schlecht nur weil es weak typisiert ist, aber ja für jemanden der sich alles aus der hand nehmen lässt und sowas idioten sicheres wie java braucht, wird man nie überzeugen denn der ist sozusagen süchtig nach statischer typisierung

lg lolo

byto

Es hat doch niemand geschrieben, dass dynamisch getypte Sprachen schlecht sind. Das bezog sich einzig auf PHP.

drakon

byto schrieb:

Freehoster sind maximal für irgendwelche Kellerprojekte zu gebrauchen, die eh niemand aufruft.

Dem stimme ich zu. Und auch sonst kann man sich die paar Euro pro Jahr wirklich geben, auch wenn es halt nur ein einfacher Blog sein wird. (Anderseits machst du mal ne Webseite für ne Kleinfirma und hast bereits jemanden, der dir den Server bezahlt. :p)

BasicMan01

ich verwende hauptsächlich auch nur PHP. Besonders ist es leicht und man kann schnell dynamische Sachen umsetzen. Die restliche Zeit ist auch notwendig, um seine Seite in allen Browsern gut aussehen zu lassen.
Des weiteren ist jeder Programmierer selber Schuld, wenn er seine Software offen lässt wie ein Scheunentor. Gegen SQL-Injections gibts auch in PHP Möglichkeiten. Ich sag nur als Beispiel mysql_real_escape_string

tntnet

BasicMan01 schrieb:

ich verwende hauptsächlich auch nur PHP. Besonders ist es leicht und man kann schnell dynamische Sachen umsetzen. Die restliche Zeit ist auch notwendig, um seine Seite in allen Browsern gut aussehen zu lassen.
Des weiteren ist jeder Programmierer selber Schuld, wenn er seine Software offen lässt wie ein Scheunentor. Gegen SQL-Injections gibts auch in PHP Möglichkeiten. Ich sag nur als Beispiel mysql_real_escape_string

Meines erachtens ist so eine Technik wie die genannte mysql_real_escape_string nicht der richtige Weg, um SQL-Injections zu vermeiden. Die Funktion bringt gleich 2 Nachteile mit sich.

Zunächst einmal ist es mysql-Spezifisch. Ein Programm sollte so Datenbankunabhängig wie möglich gemacht werden.

Ausserdem sollte man lieber Prepared Statements verwenden. Diese sind mehr oder wenige statische SQL-Statements mit Platzhaltern für die Daten. Die Daten werden dabei dann intern getrennt vom eigentlichen SQL-String transportiert und nicht mit diesem geparst. Der Vorteil ist zum einen, dass hier SQL-Injections prinzipiell ausgeschlossen werden können und zum anderen bringt das eine bessere Performance. In der Regel ist das Parsen und Optimieren des Statements relativ teuer. Mit Prepared Statements wird dieses Parsen und Optimieren für ein Statement ein mal gemacht und das Statement kann dann beliebig oft benutzt werden.

Aber fragt mich nicht, welche APIs in PHP dafür zur Verfügung stehen. Ich verwende kein PHP.

Nico D.

tntnet schrieb:

Ich verwende kein PHP.

Dann frage ich mich, wie du zur folgenden Aussage kommen konntest:

Meines erachtens ist so eine Technik wie die genannte mysql_real_escape_string nicht der richtige Weg, um SQL-Injections zu vermeiden. Die Funktion bringt gleich 2 Nachteile mit sich.
[...]
Zunächst einmal ist es mysql-Spezifisch. Ein Programm sollte so Datenbankunabhängig wie möglich gemacht werden.

Und zudem frage ich mich, was der zweite Nachteil von mysql_real_escape_string sein soll, so heisst es doch auf php.net:

mysql_real_escape_string() ruft die Funktion mysql_real_escape_string der MySQL-Bibliothek auf, die folgende Zeichen mit einem Backslash ('\') versieht: \x00, \n, \r, \, ', " und \x1a.

Ich wuesste nicht, wie da noch SQL-Injektionen moeglich sein sollten. Vielleicht koenntest du mich aufklaeren?

PS: Dass bei Verwendung dieser Funktion auch MySQL verwendet werden muss, ist wohl jedem bekannt. Sonst wuerde kein mysql voran stehen.

tntnet

heini schrieb:

tntnet schrieb:

Ich verwende kein PHP.

Dann frage ich mich, wie du zur folgenden Aussage kommen konntest:

Meines erachtens ist so eine Technik wie die genannte mysql_real_escape_string nicht der richtige Weg, um SQL-Injections zu vermeiden. Die Funktion bringt gleich 2 Nachteile mit sich.
[...]
Zunächst einmal ist es mysql-Spezifisch. Ein Programm sollte so Datenbankunabhängig wie möglich gemacht werden.

Und zudem frage ich mich, was der zweite Nachteil von mysql_real_escape_string sein soll, so heisst es doch auf php.net:

mysql_real_escape_string() ruft die Funktion mysql_real_escape_string der MySQL-Bibliothek auf, die folgende Zeichen mit einem Backslash ('\') versieht: \x00, \n, \r, \, ', " und \x1a.

Ich wuesste nicht, wie da noch SQL-Injektionen moeglich sein sollten. Vielleicht koenntest du mich aufklaeren?

PS: Dass bei Verwendung dieser Funktion auch MySQL verwendet werden muss, ist wohl jedem bekannt. Sonst wuerde kein mysql voran stehen.

Ich verstehe Deinen Einwand nicht. Zunächst einmal muss ich kein PHP verwenden, um seine Nachteile zu kennen. Vielleicht verwende ich PHP ja nicht, weil ich seine Nachteile kenne.

Aber nun zu Deinen konkreten Einwänden.

Ich finde es einfach unschön, datenbankabhängige Funktionen zu verwenden. Und ich muss kein PHP-Kenner sein, um anzunehmen, dass mysql_real_escape_string nicht datenbankunabhänig ist. Ich habe einfach mal angenommen, dass hier eine Postgresql-spezifische-API angesprochen wird . In Perl werden Datenbanken beispielsweise mit DBI/DBD angesprochen. In Java wird JDBC verwendet. Und in anderen Sprachen finden sich auch datenbankunabhängige APIs. Ich bin halt bestrebt, auch datenbankunabhängige Lösungen zu finden. Dazu zählt mysql_real_escape_string nicht.

Der zweite Nachteil bezieht sich auf die leider oft verwendete Technik, SQL-Statements dynamisch zusammen zu bauen. Das ist prinzipiell Fehleranfällig. Als Entwickler muss man schon sehr aufpassen, dass man wirklich alles notwendige mit mysql_real_escape verarbeitet. Dieses mysql_real_escape sollte nicht die erste Lösung sein, sondern die letzte, wenn es wirklich nicht anders geht.

Nico D.

tntnet schrieb:

Der zweite Nachteil bezieht sich auf die leider oft verwendete Technik, SQL-Statements dynamisch zusammen zu bauen. Das ist prinzipiell Fehleranfällig. Als Entwickler muss man schon sehr aufpassen, dass man wirklich alles notwendige mit mysql_real_escape verarbeitet. Dieses mysql_real_escape sollte nicht die erste Lösung sein, sondern die letzte, wenn es wirklich nicht anders geht.

Keine Funktion der Welt kann vor Programmierfehlern schuetzen.

Ob PHP oder nicht, mag ja Geschmackssache sein. Aber man kann eine Funktion nicht als unsicher bezeichnen, wenn sie selbst es nicht ist, sondern die Moeglichkeit der Unsicherheit letztlich nur darin bestehen koennte, wenn der Programmierer Fehler macht. Dann ist das ein Fehler des Programmierers und nicht der Funktion.

Und wenn man MySQL verwendet, wuesste ich keinen Grund, weshalb man diese Funktion nicht nutzen sollte. Alles andere in PHP selbst zusammengefriemelte waere

langsamer,
aufwendiger,
eine Neuerfindung einer bereits bestehenden Loesung und
wieder fehleranfaelliger.

Ich kann ja nachvollziehen, welchen Standpunkt du vertrittst - und wenn man andere Datenbanksysteme einbinden moechte, macht eine Verwendung speziell dieser Funktion logischerweise keinen Sinn. Aber wenn man davon ausgeht, dass ausschliesslich MySQL verwendet wird, macht alles andere keinen Sinn.

Und diese Anmerkung allein war Grund meines Einwands.

zwutz

in PHP sind vier Abstraktionsebenen und diverse spezifische Funktionen diverser Datenbanksysteme implementiert[*]. Also daran sollte es in PHP nicht scheitern.

Aber nur, weil man keine Prepared-Statements verwendet, ist eine Datenbankanwendung nicht automatisch unsicher.