Welche Programmiersprache für aktive Internetseiten?

[foslrtf]

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?

[Datentyp]

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.

[bele]

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

[;fricky]

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.

[noobLolo]

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

1. langsamer,
2. aufwendiger,
3. eine Neuerfindung einer bereits bestehenden Loesung und
4. 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.

[BasicMan01]

Was war denn an "Ich sag nur als Beispiel mysql_real_escape_string" so falsch zu verstehen? ... Ja Substantive sind ja net so wichtig. Das nächste mal lass ich das Wort "Beispiel" weg
Aber wie dem auch sei, prepared Statements sind in PHP auch kein Problem.
Datenbankunabhängige Programmierung ... aha .. soso ... Kein Problem für PHP, ich sag nur PDO. PHP wäre schon lange verschwunden, wenn die sich auf die faule Haut legen würden und die Sprache net weiterentwickeln würden.

[PRIEST]

Kennt jemand performance vergleiche zwischen PHP, Python und Ruby (on rails)?

[Shade Of Mine]

PRIEST schrieb:

Kennt jemand performance vergleiche zwischen PHP, Python und Ruby (on rails)?

Relativ irrelevant, da es auf die Skalierbarkeit ankommt. Man hat für jede Sprache sowieso Opcode caches, so dass es nur in den wenigsten Fällen wirklich relevant wird in welcher Sprache der Code geschrieben ist.

Aber schau zB mal hier:
http://www.alrond.com/en/2007/jan/25/performance-test-of-6-leading-frameworks/

Prinzipiell ist Performance aber keine Frage der Sprache sondern eine des Frameworks. Für optimale Performance braucht man dann sowieso ein eigenes Framework... Und die Performance kommt im Web aus Caches.